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