軟件源代碼漏洞及缺陷掃描技術(shù)15小時(shí)-3 -1自主測(cè)試必要性

軟件源代碼漏洞及缺陷掃描技術(shù)代碼審核的范圍和內(nèi)容12自主測(cè)試的必要性1如何找出自己代碼中的漏洞2敏捷開(kāi)發(fā)模式代碼排查的優(yōu)勢(shì)3svn是對(duì)代碼進(jìn)行分成管理4結(jié)束56目錄軟件源代碼漏洞及缺陷掃描技術(shù)自主測(cè)試的必要性軟件測(cè)試技術(shù)軟件測(cè)試方法分類軟件測(cè)試技術(shù)評(píng)價(jià)標(biāo)準(zhǔn)軟件測(cè)試方法靜態(tài)分析測(cè)試技術(shù)靜態(tài)分析的局限性手工測(cè)試必要性代碼審查的內(nèi)容3軟件測(cè)試技術(shù)軟件測(cè)試技術(shù)5點(diǎn)擊此處添加腳注信息

1983年，IEEE將軟件測(cè)試定義為：通過(guò)人工或自動(dòng)方法運(yùn)行或測(cè)試某個(gè)系統(tǒng)的過(guò)程，目的在于檢測(cè)它是否滿足軟件規(guī)格需求或弄清楚實(shí)際結(jié)果與預(yù)期結(jié)果的不同之處。 在軟件生存周期中，軟件測(cè)試占有重要地位。據(jù)統(tǒng)計(jì)，軟件測(cè)試開(kāi)銷占軟件開(kāi)發(fā)總成本中的30%-50%。若把維護(hù)階段的測(cè)試工作也算在其中，將有50%的時(shí)間和50%以上的成本要花在軟件測(cè)試上。在軟件開(kāi)發(fā)過(guò)程中，軟件測(cè)試一直處于重要地位。軟件測(cè)試技術(shù)6點(diǎn)擊此處添加腳注信息

隨著軟件測(cè)試技術(shù)的蓬勃發(fā)展，更多企業(yè)轉(zhuǎn)向使用自動(dòng)化軟件測(cè)試工具，使用此類工具可提高軟件測(cè)試的效率，縮短軟件開(kāi)發(fā)周期，讓產(chǎn)品更快投放市場(chǎng)；提升軟件測(cè)試的深度，節(jié)省人力資源；完成手工測(cè)試不可能或很難完成的任務(wù)，如負(fù)載測(cè)試、壓力測(cè)試等。

當(dāng)然，我們并不是說(shuō)自動(dòng)化軟件測(cè)試是萬(wàn)能的，通常情況下，企業(yè)在開(kāi)發(fā)軟件的過(guò)程中都是采用手工測(cè)試與自動(dòng)化測(cè)試相結(jié)合的測(cè)試方法。軟件測(cè)試方法分類軟件測(cè)試方法分類8點(diǎn)擊此處添加腳注信息

按照是否需要執(zhí)行被測(cè)程序分類（動(dòng)態(tài)測(cè)試、靜態(tài)測(cè)試）；按照測(cè)試是否針對(duì)系統(tǒng)的具體算法和內(nèi)部結(jié)構(gòu)分類（黑盒測(cè)試、白盒測(cè)試）；按照測(cè)試在系統(tǒng)開(kāi)發(fā)中的作用（單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試、回歸測(cè)試）。軟件測(cè)試方法分類9點(diǎn)擊此處添加腳注信息

動(dòng)態(tài)方法是指通過(guò)運(yùn)行被測(cè)程序，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，并分析運(yùn)行效率和健壯性等性能，這種方法由三部分組成：構(gòu)造測(cè)試實(shí)例、執(zhí)行程序、分析程序的輸出結(jié)果。靜態(tài)測(cè)試不需要編譯或運(yùn)行程序，通過(guò)對(duì)程序源代碼進(jìn)行分析從而發(fā)現(xiàn)其中的編程錯(cuò)誤或缺陷。相比于其它程序分析方法，該方法具有自動(dòng)化程度高、檢測(cè)速度快、代碼覆蓋率高等優(yōu)勢(shì)。軟件測(cè)試方法分類10點(diǎn)擊此處添加腳注信息

黑盒測(cè)試（又稱功能測(cè)試），是基于用戶說(shuō)明書的測(cè)試，主要檢測(cè)程序功能和性能上的問(wèn)題。已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，就可以進(jìn)行測(cè)試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。白盒測(cè)試（也稱為結(jié)構(gòu)測(cè)試），是基于程序的測(cè)試，要求對(duì)被測(cè)試的程序代碼進(jìn)行一定程度的覆蓋。已知產(chǎn)品的內(nèi)部工作過(guò)程，就可以通過(guò)測(cè)試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求。軟件測(cè)試方法分類11點(diǎn)擊此處添加腳注信息

單元測(cè)試主要測(cè)試軟件中的基本組成單元，如函數(shù)等，目的是檢查這些單元間的接口是否正確。集成測(cè)試在單元測(cè)試的基礎(chǔ)上，對(duì)子系統(tǒng)（由兩個(gè)或兩個(gè)以上單元集成的）進(jìn)行測(cè)試，目的在于檢查各子系統(tǒng)間的接口是否正確。系統(tǒng)測(cè)試則對(duì)經(jīng)集成過(guò)的系統(tǒng)進(jìn)行徹底測(cè)試，驗(yàn)證其性能是否符合要求。在軟件正式投入使用之前，通過(guò)客戶試用或發(fā)布Beta版軟件來(lái)驗(yàn)證軟件性能的過(guò)程，即所謂的驗(yàn)收測(cè)試?；貧w測(cè)試即是對(duì)軟件的維護(hù)過(guò)程，對(duì)驗(yàn)收測(cè)試階段發(fā)現(xiàn)的問(wèn)題進(jìn)行修改和驗(yàn)證，處理客訴其實(shí)就是實(shí)際應(yīng)用中的回歸測(cè)試的一種體現(xiàn)。當(dāng)然，針對(duì)單元測(cè)試、系統(tǒng)測(cè)試、驗(yàn)證測(cè)試和回歸測(cè)試的特點(diǎn)，它們又各自有相關(guān)的測(cè)試方法來(lái)保證其測(cè)試過(guò)程的順利進(jìn)行。軟件測(cè)試技術(shù)評(píng)價(jià)標(biāo)準(zhǔn)軟件測(cè)試技術(shù)評(píng)價(jià)標(biāo)準(zhǔn)13點(diǎn)擊此處添加腳注信息

在評(píng)價(jià)一種軟件測(cè)試技術(shù)的成熟度時(shí)，我們一般著重考慮以下幾方面特性：（1）缺陷模型是否成熟，即指此軟件測(cè)試技術(shù)缺陷模型的準(zhǔn)確性和完備性。這里準(zhǔn)確性指的是缺陷模型所描述的缺陷類型，能否準(zhǔn)確的描述軟件中實(shí)際存在的缺陷；完備性指的是缺陷模型能否描述軟件中存在的全部（或大多數(shù)）缺陷。（2）測(cè)試算法是否成熟，即指該算法能否自動(dòng)快速的檢測(cè)模型中的缺陷，并要求該算法的計(jì)算復(fù)雜度在多項(xiàng)式復(fù)雜度以內(nèi)。軟件測(cè)試技術(shù)評(píng)價(jià)標(biāo)準(zhǔn)14點(diǎn)擊此處添加腳注信息測(cè)試的評(píng)估活動(dòng)包括：

●確定實(shí)際測(cè)試執(zhí)行的有效性。執(zhí)行的是否完全？執(zhí)行失敗是否因?yàn)椴环锨爸脳l件？

●分析測(cè)試輸出以確定結(jié)果。在執(zhí)行測(cè)試過(guò)程中，你查看報(bào)告上已產(chǎn)生的數(shù)據(jù)來(lái)檢驗(yàn)該執(zhí)行是否是可接受的。

●查看合計(jì)的結(jié)果以檢查對(duì)測(cè)試計(jì)劃，測(cè)試輸入，配置等的覆蓋程度。這也可以被用來(lái)衡量測(cè)試的進(jìn)展和對(duì)分析的趨向。

●評(píng)價(jià)本次測(cè)試的有效性等等。若是有需要還要向上司給出相應(yīng)的評(píng)價(jià)報(bào)告軟件測(cè)試方法軟件測(cè)試方法16點(diǎn)擊此處添加腳注信息

手工分析、動(dòng)態(tài)測(cè)試以及靜態(tài)測(cè)試是三種比較常見(jiàn)的檢測(cè)軟件漏洞的方法。其實(shí)在使用的過(guò)程中，它們并不是完全獨(dú)立的，其分工也不是很明確的。在大多數(shù)情況下它們是相互協(xié)作，共同幫助程序員檢測(cè)軟件中漏洞或編程錯(cuò)誤，提高軟件的可靠性和安全性。軟件測(cè)試方法17點(diǎn)擊此處添加腳注信息

手工分析是目前大多數(shù)安全研究人員使用的方法，并且很多軟件企業(yè)也在使用。如對(duì)C/C++程序最簡(jiǎn)單的分析一般都是先對(duì)系統(tǒng)中諸如get()和strcpy()等不安全的庫(kù)函數(shù)調(diào)用進(jìn)行審查，檢查函數(shù)中存在的邏輯問(wèn)題。

手工分析采用的方法通常也是多種多樣的，其中自上而下的方法是使用最多的。無(wú)論采用何種方法進(jìn)行手工分析，都是一件費(fèi)時(shí)且費(fèi)力的工作，尤其對(duì)大型系統(tǒng)代碼而言。即使有完全自動(dòng)化的軟件安全漏洞檢測(cè)技術(shù)，人工的參與也將是必不可少的。對(duì)靜態(tài)程序的分析結(jié)果進(jìn)行確認(rèn)以及動(dòng)態(tài)程序分析數(shù)據(jù)的構(gòu)造等，都離不開(kāi)人工的參與。軟件測(cè)試方法18點(diǎn)擊此處添加腳注信息

動(dòng)態(tài)測(cè)試需要實(shí)際運(yùn)行被測(cè)試程序，得到程序一次或多次執(zhí)行的信息。根據(jù)這些信息對(duì)特定的漏洞模型進(jìn)行檢測(cè)，其分析的結(jié)果是絕對(duì)精確的。如可以確定程序的哪條路徑被執(zhí)行，執(zhí)行了多長(zhǎng)時(shí)間等。動(dòng)態(tài)安全漏洞檢測(cè)在執(zhí)行程序代碼的同時(shí)也收集程序運(yùn)行時(shí)信息且判斷安全漏洞或者記錄程序執(zhí)行過(guò)程中的所有信息，之后將這些信息與漏洞模型匹配，從而查找軟件安全漏洞。在程序中插入代碼是動(dòng)態(tài)分析常用的方法，如輸出某個(gè)變量的值，將某條語(yǔ)句的執(zhí)行結(jié)果打印出來(lái)等。但是，動(dòng)態(tài)測(cè)試的結(jié)果具有不完整性，某次程序的執(zhí)行結(jié)果并不能代表程序以后的某種可能執(zhí)行結(jié)果。目前也有很多用于安全漏洞檢測(cè)的動(dòng)態(tài)測(cè)試手段，如運(yùn)行時(shí)監(jiān)測(cè)、信息流分析等。軟件測(cè)試方法19點(diǎn)擊此處添加腳注信息靜態(tài)測(cè)試在測(cè)試軟件時(shí)以不運(yùn)行被測(cè)軟件程序?yàn)榍疤?，主要測(cè)試程序源碼。靜態(tài)測(cè)試包括代碼審查、代碼走查、靜態(tài)結(jié)果分析、代碼質(zhì)量度量和文檔測(cè)試等。靜態(tài)分析是一種以不運(yùn)行被測(cè)程序?yàn)樘卣鞯能浖y(cè)試技術(shù)，查找源碼中可能存在的錯(cuò)誤或?qū)Τ绦虼a進(jìn)行評(píng)估。也許有人會(huì)認(rèn)為靜態(tài)分析作為動(dòng)態(tài)測(cè)試前對(duì)代碼的預(yù)處理，我們可以使用編譯器來(lái)代替。雖然編譯器能幫助我們找出一些錯(cuò)誤，但是卻無(wú)法把代碼中絕大多數(shù)的錯(cuò)誤都指出來(lái)。靜態(tài)分析測(cè)試技術(shù)靜態(tài)分析測(cè)試技術(shù)21點(diǎn)擊此處添加腳注信息

通過(guò)掃描程序源碼，靜態(tài)分析能解決很多問(wèn)題，如類型檢查、風(fēng)格檢查、程序理解、程序驗(yàn)證、屬性檢查、Bug查找及安全審查等。靜態(tài)分析測(cè)試技術(shù)22點(diǎn)擊此處添加腳注信息

類型檢查是大多數(shù)程序員所熟悉的，也是最廣泛的靜態(tài)分析的應(yīng)用形式。但很多程序員并沒(méi)給與類型檢查足夠的關(guān)注。畢竟，類型的相關(guān)規(guī)則一般是由編程語(yǔ)言定義的，且由編譯器強(qiáng)制執(zhí)行。因此，在什么時(shí)候執(zhí)行分析及如何運(yùn)作等這類問(wèn)題上，程序員幾乎沒(méi)有話語(yǔ)權(quán)。即便如此，類型檢查仍是一種靜態(tài)分析，能夠消除全部類別的編程錯(cuò)誤。如可防止程序員意外地給對(duì)象變量賦整型值。類型檢查捕獲錯(cuò)誤的能力有局限性，同其他的靜態(tài)分析技術(shù)一樣，類型檢查也有誤報(bào)和漏報(bào)的情況。但是，程序員很少會(huì)抱怨某個(gè)類型檢查工具用起來(lái)不理想。靜態(tài)分析測(cè)試技術(shù)23點(diǎn)擊此處添加腳注信息

風(fēng)格檢查也屬于靜態(tài)分析，注重表面上的東西。相比與類型檢查，風(fēng)格檢查程序強(qiáng)制執(zhí)行的規(guī)則更加嚴(yán)格。這些規(guī)則與空格、命名、注釋、程序結(jié)構(gòu)等相關(guān)。風(fēng)格檢查程序發(fā)現(xiàn)往往是影響代碼可讀性和可維護(hù)性的錯(cuò)誤，并不能發(fā)現(xiàn)程序在運(yùn)行時(shí)可能會(huì)發(fā)生的錯(cuò)誤。隨著計(jì)算機(jī)技術(shù)的發(fā)展，某些編譯器已經(jīng)實(shí)現(xiàn)了可選的風(fēng)格檢查功能。在項(xiàng)目開(kāi)始采用風(fēng)格檢查是最容易的，而中途采用風(fēng)格檢查是很困難的。在項(xiàng)目開(kāi)始之后，僅僅為了減少風(fēng)格檢查程序的輸出，而重新檢查一遍代碼以對(duì)代碼進(jìn)行調(diào)整，是不劃算的往往以很大的麻煩作為代價(jià)。靜態(tài)分析測(cè)試技術(shù)24點(diǎn)擊此處添加腳注信息 Bug查找工具關(guān)注的是指出程序中哪些地方在以程序員設(shè)想之外的方式運(yùn)轉(zhuǎn)。大多數(shù)bug查找工具易于使用，它們會(huì)預(yù)先備有一套規(guī)則，用來(lái)描述代碼中經(jīng)常會(huì)存在的bug的一些模式。bug查找工具關(guān)注的是產(chǎn)生較少的誤報(bào)，即使會(huì)有較高的漏報(bào)率。靜態(tài)分析測(cè)試技術(shù)25點(diǎn)擊此處添加腳注信息

在實(shí)際使用中，靜態(tài)代碼分析比動(dòng)態(tài)測(cè)試更有效率，能更快速地找到缺陷。按經(jīng)驗(yàn)估算，一般能發(fā)現(xiàn)30%-70%的邏輯設(shè)計(jì)和編碼錯(cuò)誤?，F(xiàn)有的靜態(tài)分析測(cè)試方法主要有：數(shù)據(jù)流分析、類型推斷、約束分析等等。靜態(tài)分析測(cè)試技術(shù)26點(diǎn)擊此處添加腳注信息各種靜態(tài)分析方法的比較靜態(tài)分析的局限性靜態(tài)分析的局限性28點(diǎn)擊此處添加腳注信息

現(xiàn)有的靜態(tài)分析工具的共同缺點(diǎn)是產(chǎn)生的無(wú)用信息太多，尤其是產(chǎn)生太多的誤報(bào)。簡(jiǎn)單的說(shuō)誤報(bào)是指一種情況，程序中實(shí)際不存在某問(wèn)題，而靜態(tài)分析工具卻報(bào)告了此問(wèn)題。大量的誤報(bào)無(wú)疑會(huì)帶來(lái)很多困難。閱讀長(zhǎng)長(zhǎng)的誤報(bào)列表，這種體力勞動(dòng)不僅費(fèi)時(shí)而且費(fèi)力。但是，為了防止遺漏掉隱藏在列表中的重要結(jié)果，又不得不對(duì)其進(jìn)行查看。誤報(bào)顯然是令人不快的，但是從安全的角度來(lái)講，漏報(bào)問(wèn)題更為嚴(yán)重。如果程序中存在問(wèn)題，而靜態(tài)分析工具卻沒(méi)有報(bào)告這個(gè)問(wèn)題，那么就產(chǎn)生了漏報(bào)問(wèn)題。作為誤報(bào)的代價(jià)，我們需要花時(shí)間和精力對(duì)長(zhǎng)長(zhǎng)的誤報(bào)列表進(jìn)行結(jié)果審查，而漏報(bào)的代價(jià)就遠(yuǎn)遠(yuǎn)超過(guò)了這些。漏報(bào)使得我們會(huì)一直活在一種安全的假象中。這種假象是由漏報(bào)安全問(wèn)題的分析工具產(chǎn)生的，它使得表面上看起來(lái)一切都很好，而事實(shí)卻并非如此，問(wèn)題是存在的。手工測(cè)試必要性手工測(cè)試必要性30點(diǎn)擊此處添加腳注信息

在軟件行業(yè)，自動(dòng)化測(cè)試已經(jīng)行之多年，有些領(lǐng)域甚至已經(jīng)有幾十年歷史了，但為什么軟件發(fā)布到最終用戶手里時(shí)還會(huì)出問(wèn)題？這是因?yàn)樽詣?dòng)化測(cè)試和開(kāi)發(fā)人員所做的其他測(cè)試都有某些共通的問(wèn)題。手工測(cè)試必要性31點(diǎn)擊此處添加腳注信息

首先是運(yùn)行環(huán)境，代碼運(yùn)行的環(huán)境是一個(gè)測(cè)試環(huán)境，而不是一個(gè)真實(shí)的用戶環(huán)境。因?yàn)樽詣?dòng)化測(cè)試代碼并不非常可靠（畢竟，它也屬于軟件的范疇），所以基本不會(huì)使用客戶的真實(shí)數(shù)據(jù)庫(kù)來(lái)運(yùn)行自動(dòng)化測(cè)試代碼。如果自動(dòng)化測(cè)試需要在數(shù)據(jù)庫(kù)中刪除或添加一些數(shù)據(jù)，想象一下哪個(gè)客戶愿意在他們的真實(shí)數(shù)據(jù)庫(kù)中運(yùn)行這些代碼？自動(dòng)化測(cè)試還有一個(gè)致命弱點(diǎn)就是“預(yù)言家難題”（oracleproblem），至今尚無(wú)解決方案。手工測(cè)試必要性32點(diǎn)擊此處添加腳注信息

這里的“預(yù)言家難題”（oracleproblem）指的是測(cè)試中最艱巨的任務(wù)之一，就是在運(yùn)行一個(gè)測(cè)試用例時(shí)，如何才能知道被測(cè)試軟件確實(shí)完成了它應(yīng)該完成的任務(wù)？被測(cè)試軟件是否輸出了正確的結(jié)果？在運(yùn)行過(guò)程中，是否帶來(lái)任何副作用？如何才能確信這一點(diǎn)？如果給定一個(gè)用戶環(huán)境，特定的數(shù)據(jù)配置和輸入順序，是否存在一個(gè)“預(yù)言家”可以根據(jù)這些情況做出這樣的斷言：“軟件確實(shí)做了，也只做了它所應(yīng)該做的事”？現(xiàn)實(shí)情況下，往往由于軟件的設(shè)計(jì)規(guī)格說(shuō)明書（spec）并不完整，或者根本沒(méi)有，這導(dǎo)致軟件的測(cè)試人員也沒(méi)有辦法做這個(gè)斷言。手工測(cè)試必要性33點(diǎn)擊此處添加腳注信息

缺少這樣一個(gè)預(yù)言家，自動(dòng)化測(cè)試就只能找到那些最極端的問(wèn)題，比如程序崩潰（crash）、死機(jī)（hang）或突發(fā)異常（exception）的情況。因?yàn)樽詣?dòng)化測(cè)試本身就是一個(gè)軟件，所以不僅被測(cè)試的軟件會(huì)崩潰，測(cè)試代碼也常常會(huì)發(fā)生崩潰。那些比較微妙或復(fù)雜的錯(cuò)誤便如此這般被略過(guò)了?？纯吹?章就知道，有多少這樣的關(guān)鍵錯(cuò)誤躲過(guò)了測(cè)試，悄悄地溜入正式發(fā)布的代碼。自動(dòng)化確實(shí)很重要，但光靠它還不夠，過(guò)度依賴自動(dòng)化測(cè)試會(huì)為程序的最終成功帶來(lái)隱患。手工測(cè)試必要性34點(diǎn)擊此處添加腳注信息

現(xiàn)在，測(cè)試人員該怎么辦呢？如果測(cè)試人員不能依靠開(kāi)發(fā)人員的缺陷預(yù)防工具和自動(dòng)化手段，他們還能寄希望于什么呢？唯一的答案就是手工測(cè)試。代碼審查的內(nèi)容代碼審查的內(nèi)容36點(diǎn)擊此處添加腳注信息

代碼注釋：開(kāi)發(fā)人員，特別是沒(méi)有經(jīng)驗(yàn)的初級(jí)程序員，往往忽視注釋的重要性，造成更個(gè)程序的易讀性大大減低，給后續(xù)的維護(hù)和升級(jí)帶來(lái)極大的困難。詳細(xì)、清晰的注釋，可以是團(tuán)隊(duì)內(nèi)部的其它成員在看代碼時(shí)不需要看具體的代碼實(shí)現(xiàn)，瀏覽一下注釋就知道代碼要實(shí)現(xiàn)的功能了，節(jié)省了很多人的時(shí)間，從而提高了團(tuán)隊(duì)工作效率；代碼審查的內(nèi)容37點(diǎn)擊此處添加腳注信息

結(jié)構(gòu)問(wèn)題：MVC的分層不清晰和命名不規(guī)范，重復(fù)拷貝代碼（不封裝函數(shù)，不用Template/泛型??），函數(shù)過(guò)長(zhǎng)（超過(guò)一屏幕就叫過(guò)長(zhǎng)），錯(cuò)誤封裝（不恰當(dāng)?shù)膒ublic/不用Interface/不內(nèi)聚）；強(qiáng)耦合，分層不當(dāng)（多個(gè)無(wú)關(guān)類置于一個(gè)文件，多個(gè)無(wú)關(guān)方法置于一個(gè)類）；不恰當(dāng)?shù)拿?；以上?wèn)題都將影響系統(tǒng)的可擴(kuò)展性。

在此強(qiáng)調(diào)一下MVC分層審查重要性，好的分層式設(shè)計(jì)可以達(dá)至如下目的：可以很容易的用新的實(shí)現(xiàn)來(lái)替換原有層次的實(shí)現(xiàn)，可以降低層與層之間的依賴，利于各層邏輯的復(fù)用，達(dá)到分散關(guān)注、松散耦合、邏輯復(fù)用、標(biāo)準(zhǔn)定義?？梢越档拖到y(tǒng)升級(jí)的成本，同時(shí)可以增強(qiáng)系統(tǒng)的