隨筆-60 評論-117 文章-0 trackbacks-0

經常有這樣的經驗：想要學一樣東西，有一本關于它的厚厚的書擺在我面前。快速的翻了翻之后，又將它合上。然后無奈的嘆了口氣。是啊，到底該怎么下手呢？可當得知明天就要考這本書的時候，再打開，發現它們突然變得簡單了。只是自己想學的太多，時間有點不夠用……
軟件測試
定義：測試是為了發現錯誤而執行程序的過程。

目的：

為了尋找錯誤，并盡可能地為修正錯誤提供更多的信息。
為了證明軟件有錯誤，而不是證明軟件沒有錯誤。

作用：

發現并管理缺陷
度量質量
- 評價工作效率和效果
- 與其項目風險

原則：

座右銘：“盡早地和不斷地進行軟件測試”。
測試用例應由測試輸入數據和對應的語句輸入結果這兩部分組成。
程序員應避免檢查自己的程序。
在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。
充分注意測試中的群集現象。經驗表明，測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目成正比。
嚴格執行測試計劃，排除測試的隨意性。
應當對每一個測試結果作全面檢查。
妥善保存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。
所有的測試都應可追溯到客戶的需求。
應該在測試工作開始之前的較長時間就進行測試計劃。
pareto原則：測試發現的錯誤中80%很可能起源于20%的模塊中。
測試從“小模塊”開始，逐步轉向“大規模”。
窮舉測試是不可能的。

對象：

軟件包括程序、數據和文檔，軟件測試并不等于程序測試。
軟件測試應貫穿于軟件定義與開發的整個其間。
開發過程所得到的文檔，都應成為軟件測試的對象。
驗證與確認都屬于軟件測試，它包括對軟件分析、設計以及程序的驗證和確認。
- 驗證：是保證軟件符合產品描述的過程。
- 是保證軟件滿足用戶要求的過程。

缺陷：

軟件未達到產品描述表明的功能。
軟件出現了產品描述指明不會出現的錯誤。
軟件功能超出產品描述指明范圍。
軟件未達到產品描述雖未指出但應達到的目標。
軟件測試人員認為軟件難以理解、不易使用、運行速度緩慢、或者最終用戶認為不好。

缺陷產生的原因：

編寫代碼
設計
編寫產品描述
其他

特征：

軟件測試具有一定的風險：完全測試是不可能的，如果決定不去測試所有的情況，那就是選擇了風險。
軟件缺陷的寄生蟲性：找到的軟件缺陷越多，就說明軟件缺陷越多。
軟件測試的殺蟲劑現象：軟件測試越多，其免疫力越強的現象。
軟件測試的不修復原則：并非所有軟件缺陷都能修復。有些缺陷不需要修復：*沒有足夠的時間*不算真正的軟件缺陷* 修復的風險太大*不值得修復。

軟件測試方法、技術和策略
框架：

靜態測試方法
1. 人工測試方法
2. 計算機輔助靜態分析方法
動態測試方法
1. 白盒測試方法
2. 黑盒測試方法

靜態測試：
基本特征

對軟件進行分析、檢查和審閱，不實際運行被測試的軟件。
靜態測試約可找出30-70% 的邏輯設計錯誤。

比如說：對需求規格說明書、軟件設計說明書、原程序作檢查和審閱。

動態測試：
基本特征：
通過運行軟件來檢驗軟件的動態行為和運行結果的正確性。
兩個基本要素：

被測試程序
測試數據（測試用例）

動態測試方法流程

選取定義域有效值，或定義域外無效值
對已選取值決定預期的結果
用選取值執行程序
執行結果與對已選取值決定預期的結果相比，不吻合程序有錯。

白盒測試：

結構測試（玻璃盒測試）
對軟件的過程性細節做細致的檢查
可利用程序內的邏輯結構，設計或選擇測試用例，對程序的邏輯羅景警醒測試。

白盒測試方法：

邏輯覆蓋
- 語句覆蓋：被測程序中每個語句至少執行一次
- 判定覆蓋:使每個判定的真假分支都至少執行一次
- 條件覆蓋：每個語句至少執行一次，切實判定表達式中的每個條件都取到各種可能的結果
- 判定/條件覆蓋：判定每個條件的所有可能條件至少執行一次，同時每個判定的所有的可能判定結果至少執行一次。
- 條件組合覆蓋：所有可能的條件去之組合至少執行一次
控制結構測試
- 基本路徑測試：通過分析由控制構造的環路的復雜性，導出基本路徑集合，從而設計測試用例，保證這些路徑至少通過一次
- 條件測試：是檢查程序模塊中包含的邏輯條件。
- 循環測試：專注于測試循環結構的有效性
  - 簡單循環
  - 嵌套循環
  - 串接循環

黑盒測試：

功能測試（行為測試）
數據驅動測試
注重測試軟件的功能性需求
在程序借口進行測試，只檢查程序功能是否按規格說明書的規定
不深入代碼細節的測試

測試方法：

等價劃分
邊界值分析
錯誤推測
其他方法

等價劃分：
基本思想：
將所有可能的輸入數據（有效的和無效的）劃分成若干個等價類，從每個等價類中只取一組數據作為測試數據。
基本步驟：

劃分輸入數據的等價類（有效和無效）
- 等價類：指某個輸入域的子集合，在該子集合中，個個輸入數據對于揭露程序中的錯誤是等效的。
涉及測試方案
- 不斷地覆蓋所有的有效等價類
- 不斷地覆蓋所有的無效等價類

劃分等價類的規則：

如果輸入條件規定了取值范圍，可定義一個有效等價類和兩個無效等價類。
如果輸入條件代表集合的某個元素，則可定義一個有效等價類和一個無效等價類。
如規定了輸入數據的一組值，且程序對不同輸入值作不同處理，則每個允許的輸入值是一個有效等價類，并有一個無效等價類（所有不允許的輸入值的集合）。
如果規定了輸入數據必須組遵循的規則，可確定一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。
如已劃分的等價類各元素在程序中的處理方式不同，則應將此等價類進一步劃分成更小的等價類。

邊界值分析：
通過關注于在某等價類的“邊緣”的數據而擴展了等價劃分。
與等價劃分的區別：

邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。
邊界值分析不僅考慮輸入條件，還要考慮輸入空間產生的測試情況。

邊界值分析的步驟：
確定邊界情況：

輸入等價類和輸出等價類的邊界，就應該著重測試的程序邊界的情況。
選取的測試數據應剛好等于，剛好小于鶴崗好大于邊界值。
聯合使用等價劃分和邊界值分析兩技術。

因果圖：

描述對于多種條件的組合，相應產生多個動作的形式。適合于檢查程序輸入條件的各種組合情況。

使用因果圖設計測試用例：

考慮了多個輸入之間的相互組合，相互制約關系。
能夠幫助我們按一定步驟，高效率地選擇測試用例，同時還能為我們指出，程序規格說明描述中存在著什么問題

利用因果圖導出測試用例的一般步驟

分析程序規格說明的描述中，哪些是原因，哪些是結果。
分析程序規格說明的描述中語義的內容，并將其表示城連接各個原因與各個結果的因果圖
在因果圖上使用若干個特殊的符號表明特定的約束條件
把因果圖轉換成判定表
把判定表中每一列表示的情況寫成測試用例

錯誤推測：
基本思想：

列舉程序中可能有的錯誤和容易發生的特殊情況，并且根據他們選擇測試方案

軟件測試模型：

v模型：按時間順序進行：用戶需求，需求分析與系統設計，概要設計，詳細設計，編碼，單元測試，集成測試，確認測試與系統測試，驗收測試
- 它是最具具有代表意義的測試模型
- 它是軟件開發瀑布模型的變種，它反映了測試活動與分析和設計的關系。
- 從左到右，描述了基本的開發過程和測試行為，非常明確的表明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發過程期間各階段的對應關系。
- 箭頭代表了時間方向，左邊下降的是開發過程各階段，與此相對應的是右邊上升的部分，即個測試過程的各個階段。
w模型
- v模型存在一定的局限性，它僅僅把測試過程作為在需求分析，概要設計，詳細設計及編碼之后的一個階段。容易使人理解為測試是軟件開發的最后的一個階段，主要是針對程序進行測試徐兆錯誤，而需求分析階段的隱藏的問題一直到后期的驗收測試才被發現。
- 在v模型中曾家軟件各開發階段應同步進行的測試，被演化為一種w模型。
- 開發是v，測試也是與此相重疊的v。
- 相比于v模型，w模型更科學。w模型可以說是前者自然而然的發展，它強調:測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求，功能和設計同樣要測試。
- 測試與開發是同步進行的，從而有利于僅在地發現問題。與需求為例，而不是等到最后才進行針對需求的驗收測試。
- 測試不僅僅是評定軟件的質量，測試還可以盡可能早的找出缺陷所在，從而幫助改進項目內部的質量。
x模型

軟件測試技術：
靜態測試的技術主要有：代碼走查，技術評審，代碼審查。
黑盒測試的技術主要有：功能測試，性能測試，攻擊測試。
回歸測試：程序修改或者版本更新以后，為了確保以前正確的能能和其他指標仍舊正確，而重新進行的測試。
測試過程分為：

單元測試：
- 檢驗程序最小單元有無錯誤。接口、數據結構、邊界、覆蓋、邏輯。檢驗單元編碼與設計是否吻合。
- 時機：編碼完成后，首先要實施的測試。
- 方法：靜態測試，白盒測試
- 責任：開發工程師
集成測試：
- 目標：檢驗組成系統的模塊節后有無錯誤。代碼實現的系統設計與需求定義是否吻合。
- 時機：主要的單元測試完成后，經常與單元測試同步進行。
- 方法：黑盒測試
- 責任：開發工程師，測試工程師
系統測試：