經(jīng)常有這樣的經(jīng)驗:想要學一樣東西,有一本關(guān)于它的厚厚的書擺在我面前。快速的翻了翻之后,又將它合上。然后無奈的嘆了口氣。是啊,到底該怎么下手呢?可當?shù)弥魈炀鸵歼@本書的時候,再打開,發(fā)現(xiàn)它們突然變得簡單了。只是自己想學的太多,時間有點不夠用……
軟件測試
定義:測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。
目的:
- 為了尋找錯誤,并盡可能地為修正錯誤提供更多的信息。
- 為了證明軟件有錯誤,而不是證明軟件沒有錯誤。
作用:
- 發(fā)現(xiàn)并管理缺陷
- 度量質(zhì)量
- 評價工作效率和效果
- 與其項目風險
原則:
- 座右銘:“盡早地和不斷地進行軟件測試”。
- 測試用例應由測試輸入數(shù)據(jù)和對應的語句輸入結(jié)果這兩部分組成。
- 程序員應避免檢查自己的程序。
- 在設(shè)計測試用例時,應當包括合理的輸入條件和不合理的輸入條件。
- 充分注意測試中的群集現(xiàn)象。經(jīng)驗表明,測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目成正比。
- 嚴格執(zhí)行測試計劃,排除測試的隨意性。
- 應當對每一個測試結(jié)果作全面檢查。
- 妥善保存測試計劃,測試用例,出錯統(tǒng)計和最終分析報告,為維護提供方便。
- 所有的測試都應可追溯到客戶的需求。
- 應該在測試工作開始之前的較長時間就進行測試計劃。
- pareto原則:測試發(fā)現(xiàn)的錯誤中80%很可能起源于20%的模塊中。
- 測試從“小模塊”開始,逐步轉(zhuǎn)向“大規(guī)模”。
- 窮舉測試是不可能的。
對象:
- 軟件包括程序、數(shù)據(jù)和文檔,軟件測試并不等于程序測試。
- 軟件測試應貫穿于軟件定義與開發(fā)的整個其間。
- 開發(fā)過程所得到的文檔,都應成為軟件測試的對象。
- 驗證與確認都屬于軟件測試,它 包括對軟件分析、設(shè)計以及程序的驗證和確認。
- 驗證:是保證軟件符合產(chǎn)品描述的過程。
- 是保證軟件滿足用戶要求的過程。
缺陷:
- 軟件未達到產(chǎn)品描述表明的功能。
- 軟件出現(xiàn)了產(chǎn)品描述指明不會出現(xiàn)的錯誤。
- 軟件功能超出產(chǎn)品描述指明范圍。
- 軟件未達到產(chǎn)品描述雖未指出但應達到的目標。
- 軟件測試人員認為軟件難以理解、不易使用、運行速度緩慢、或者最終用戶認為不好。
缺陷產(chǎn)生的原因:
- 編寫代碼
- 設(shè)計
- 編寫產(chǎn)品描述
- 其他
特征:
- 軟件測試具有一定的風險:完全測試是不可能的,如果決定不去測試所有的情況,那就是選擇了風險。
- 軟件缺陷的寄生蟲性:找到的軟件缺陷越多,就說明軟件缺陷越多。
- 軟件測試的殺蟲劑現(xiàn)象:軟件測試越多,其免疫力越強的現(xiàn)象。
- 軟件測試的不修復原則 :并非所有軟件缺陷都能修復。有些缺陷不需要修復:*沒有足夠的時間*不算真正的軟件缺陷* 修復的風險太大*不值得修復。
軟件測試方法、技術(shù)和策略
框架:
- 靜態(tài)測試方法
- 人工測試方法
- 計算機輔助靜態(tài)分析方法
- 動態(tài)測試方法
- 白盒測試方法
- 黑盒測試方法
靜態(tài)測試:
基本特征
- 對軟件進行分析、檢查和審閱,不實際運行被測試的軟件。
- 靜態(tài)測試約可找出30-70% 的邏輯設(shè)計錯誤 。
比如說:對需求規(guī)格說明書、軟件設(shè)計說明書、原程序作檢查和審閱。
動態(tài)測試:
基本特征:
通過運行軟件來檢驗軟件的動態(tài)行為和運行結(jié)果的正確性。
兩個基本要素:
- 被測試程序
- 測試數(shù)據(jù)(測試用例)
動態(tài)測試方法流程
- 選取定義域有效值,或定義域外無效值
- 對已選取值決定預期的結(jié)果
- 用選取值執(zhí)行程序
- 執(zhí)行結(jié)果與對已選取值決定預期的結(jié)果相比,不吻合程序有錯。
白盒測試:
- 結(jié)構(gòu)測試(玻璃盒測試)
- 對軟件的過程性細節(jié)做細致的檢查
- 可利用程序內(nèi)的邏輯結(jié)構(gòu),設(shè)計或選擇測試用例,對程序的邏輯羅景警醒測試。
白盒測試方法:
- 邏輯覆蓋
- 語句覆蓋:被測程序中每個語句至少執(zhí)行一次
- 判定覆蓋:使每個判定的真假分支都至少執(zhí)行一次
- 條件覆蓋:每個語句至少執(zhí)行一次,切實判定表達式中的每個條件都取到各種可能的結(jié)果
- 判定/條件覆蓋:判定每個條件的所有可能條件至少執(zhí)行一次,同時每個判定的所有的可能判定結(jié)果至少執(zhí)行一次。
- 條件組合覆蓋:所有可能的條件去之組合至少執(zhí)行一次
- 控制結(jié)構(gòu)測試
- 基本路徑測試:通過分析由控制構(gòu)造的環(huán)路的復雜性,導出基本路徑集合,從而設(shè)計測試用例,保證這些路徑至少通過一次
- 條件測試:是檢查程序模塊中包含的邏輯條件。
- 循環(huán)測試:專注于測試循環(huán)結(jié)構(gòu)的有效性
- 簡單循環(huán)
- 嵌套循環(huán)
- 串接循環(huán)
黑盒測試:
- 功能測試(行為測試)
- 數(shù)據(jù)驅(qū)動測試
- 注重測試軟件的功能性需求
- 在程序借口進行測試,只檢查程序功能是否按規(guī)格說明書的規(guī)定
- 不深入代碼細節(jié)的測試
測試方法:
- 等價劃分
- 邊界值分析
- 錯誤推測
- 其他方法
等價劃分:
基本思想:
將所有可能的輸入數(shù)據(jù)(有效的和無效的)劃分成若干個等價類,從每個等價類中只取一組數(shù)據(jù)作為測試數(shù)據(jù)。
基本步驟:
- 劃分輸入數(shù)據(jù)的等價類(有效和無效)
- 等價類:指某個輸入域的子集合,在該子集合中,個個輸入數(shù)據(jù)對于揭露程序中的錯誤是等效的。
- 涉及測試方案
- 不斷地覆蓋所有的有效等價類
- 不斷地覆蓋所有的無效等價類
劃分等價類的規(guī)則:
- 如果輸入條件規(guī)定了取值范圍,可定義一個有效等價類和兩個無效等價類。
- 如果輸入條件代表集合的某個元素,則可定義一個有效等價類和一個無效等價類。
- 如規(guī)定了輸入數(shù)據(jù)的一組值, 且程序?qū)Σ煌斎胫底鞑煌幚恚瑒t每個允許的輸入值是一個有效等價類,并有一個無效等價類(所有不允許的輸入值的集合)。
- 如果規(guī)定了輸入數(shù)據(jù)必須組遵循的規(guī)則,可確定一個有效等價類(符合規(guī)則)和若干個無效等價類(從不同角度違反規(guī)則)。
- 如已劃分的等價類各元素在程序中的處理方式不同,則應將此等價類進一步劃分成更小的等價類。
邊界值分析:
通過關(guān)注于在某等價類的“邊緣”的數(shù)據(jù)而擴展了等價劃分。
與等價劃分的區(qū)別:
- 邊界值分析不是從某等價類中隨便挑一個作為代表, 而是使這個等價類的每個邊界都要作為測試條件。
- 邊界值分析不僅考慮輸入條件,還要考慮輸入空間產(chǎn)生的測試情況。
邊界值分析的步驟:
確定邊界情況:
- 輸入等價類和輸出等價類的邊界,就應該著重測試的程序邊界的情況。
- 選取的測試數(shù)據(jù)應剛好等于,剛好小于鶴崗好大于邊界值。
- 聯(lián)合使用等價劃分和邊界值分析兩技術(shù)。
因果圖:
- 描述對于多種條件的組合,相應產(chǎn)生多個動作的形式。適合于檢查程序輸入條件的各種組合情況。
使用因果圖設(shè)計測試用例:
- 考慮了多個輸入之間的相互組合,相互制約關(guān)系。
- 能夠幫助我們按一定步驟,高效率地選擇測試用例,同時還能為我們指出, 程序規(guī)格說明描述中存在著什么問題
利用因果圖導出測試用例的一般步驟
- 分析程序規(guī)格說明的描述中,哪些是原因,哪些是結(jié)果。
- 分析程序規(guī)格說明的描述中語義的內(nèi)容,并將其表示城連接各個原因與各個結(jié)果的因果圖
- 在因果圖上使用若干個特殊的符號表明特定的約束條件
- 把因果圖轉(zhuǎn)換成判定表
- 把判定表中每一列表示的情況寫成測試用例
錯誤推測:
基本思想:
- 列舉程序中可能有的錯誤和容易發(fā)生的特殊情況,并且根據(jù)他們選擇測試方案
軟件測試模型:
- v模型:按時間順序進行:用戶需求,需求分析與系統(tǒng)設(shè)計,概要設(shè)計,詳細設(shè)計,編碼,單元測試,集成測試,確認測試與系統(tǒng)測試,驗收測試
- 它是最具具有代表意義的測試模型
- 它是軟件開發(fā)瀑布模型的變種,它反映了測試活動與分析和設(shè)計的關(guān)系。
- 從左到右,描述了基本的開發(fā)過程和測試行為,非常明確的表明了測試過程中存在的不同級別,并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應關(guān)系。
- 箭頭代表了時間方向 ,左邊下降的是開發(fā)過程各階段,與此相對應的是右邊上升的部分,即個測試過程的各個階段。
- w模型
- v模型存在一定的局限性,它僅僅把測試過程作為在需求分析,概要設(shè)計,詳細設(shè)計及編碼之后的一個階段。容易使人理解為測試是軟件開發(fā)的最后的一個階段,主要是針對程序進行測試徐兆錯誤,而需求分析階段的隱藏的問題一直到后期的驗收測試才被發(fā)現(xiàn)。
- 在v模型中曾家軟件各開發(fā)階段應同步進行的測試,被演化為一種w模型。
- 開發(fā)是v,測試也是與此相重疊的v。
- 相比于v模型,w模型更科學。w模型可以說是前者自然而然的發(fā)展,它強調(diào):測試伴隨著整個軟件開發(fā)周期,而且測試的對象不僅僅是程序,需求,功能和設(shè)計同樣要測試。
- 測試與開發(fā)是同步進行的,從而有利于僅在地發(fā)現(xiàn)問題。與需求為例,而不是等到最后才進行針對需求的驗收測試。
- 測試不僅僅是評定軟件的質(zhì)量,測試還可以盡可能早的找出缺陷所在,從而幫助改進項目內(nèi)部的質(zhì)量。
- x模型
軟件測試技術(shù):
靜態(tài)測試的技術(shù)主要有:代碼走查,技術(shù)評審,代碼審查。
黑盒測試的技術(shù)主要有:功能測試,性能測試,攻擊測試。
回歸測試:程序修改或者版本更新以后,為了確保以前正確的能能和其他指標仍舊正確,而重新進行的測試。
測試過程分為:
- 單元測試:
- 檢驗程序最小單元有無錯誤。接口、數(shù)據(jù)結(jié)構(gòu)、邊界、覆蓋、邏輯。檢驗單元編碼與設(shè)計是否吻合。
- 時機:編碼完成后,首先要實施的測試。
- 方法:靜態(tài)測試,白盒測試
- 責任:開發(fā)工程師
- 集成測試:
- 目標:檢驗組成系統(tǒng)的模塊節(jié)后有無錯誤。代碼實現(xiàn)的系統(tǒng)設(shè)計與需求定義是否吻合。
- 時機:主要的單元測試完成后,經(jīng)常與單元測試同步進行。
- 方法:黑盒測試
- 責任:開發(fā)工程師,測試工程師
- 系統(tǒng)測試:
- 目標:檢驗組成整個系統(tǒng)的代碼、以及系統(tǒng)的軟硬件配合有無錯誤
- 代碼實現(xiàn)的系統(tǒng)與用戶需求是否吻合
- 檢驗系統(tǒng)的文檔等各種是否完整、有效
- 模擬驗收測試的要求,檢察系統(tǒng)是否符合用戶的驗收標準
- 時機:多數(shù)集成測試完成后
- 方法:黑盒測試
- 責任:測試工程師
- 系統(tǒng)測試----穩(wěn)定期測試
- 目標:度量是否可以結(jié)束測試
- 時機:傳統(tǒng)的系統(tǒng)測試完成后
- 方法:黑盒測試
- 責任:測試工程師
- 驗收測試:
- 目標:使客戶驗收簽字,系統(tǒng)是否符合事先約定的驗收標準。
- 時機:系統(tǒng)測試完成后,在項目組開來開發(fā)和測試工作已經(jīng)全部完成,可以交付使用。
- 方法:黑盒測試
- 責任:產(chǎn)品經(jīng)理或其他高級經(jīng)理,開發(fā)工程師,測試工程師,用戶。
- 回歸測試:
- 目標:驗證程序修改或者版本更新以后,以前正確的功能和其他指標仍舊正確。
- 時機:每次錯誤修改之后,或者版本更新之后。
- 方法:白盒測試,黑盒測試
- 責任:開發(fā)工程師,測試工程師
- 缺陷跟蹤:
- 目標:確保所有發(fā)現(xiàn)的錯誤被正確記錄、分發(fā)、評估、關(guān)閉、統(tǒng)計
- 時機:從錯誤發(fā)現(xiàn)開始到錯誤關(guān)閉為止,每次錯誤裝袋修改之后。
- 方法:缺陷跟蹤系統(tǒng)
- 責任:開發(fā)工程師,測試工程師,測試經(jīng)理,用戶