一、 測試的目的。
「測試是為發現錯誤而執行程式的過程。」
「乙個成功的測試用例」是發現程式中存在錯誤的測試用例。
二、 測試用例設計的原則
1）測試用例中乙個必需部分是對預期輸出進行定義。
2）測試用例的編寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況。
3）檢查程式是否「未做其應該做的」僅是測試的一半，測試的另一半是檢查程是否「做了其不應該做的」。
4）程式某部分存在更多錯誤的可能性，與該部分已發現錯誤的數量成正比。
5）窮舉輸入測試和窮舉路徑測試不可取。
三、人工檢查的錯誤列表參照
包括資料引用錯誤、運算錯誤、資料宣告錯誤、控制流程錯誤、輸入輸出錯誤、介面錯誤、記憶體錯誤等。
1、資料引用錯誤
1）是否有引用的變數未賦值或未初始化？
2）下標的值是否在範圍之內？
3）記錄和結構的屬性是否匹配？
4）是否計算位串的位址？是否傳遞位串引數？
2、運算錯誤
1）是否存在非算術變數間的運算？
2）是否存在混合摸式的運算？
3）是否存在不同字長變數問的運算？
4）目標變數的大小是否小於賦值大小？
5）中間結果是否上溢或下溢？
6）是否存在二進位制的不精確度？
3、資料宣告錯誤
1）陣列和字串的初始化是否正確？
2）變數是否賦予了正確的長度，型別和儲存類？
3）是否所有的變數都已宣告？
4、控制流程錯誤
1）是否每個迴圈都終止了？
2）是否存在由於入口條件不滿足而跳過迴圈體？
3）可能的迴圈越界是否正確？
4）是否存在「僅差乙個」的迭代錯誤？
5、輸入輸出錯誤
1）檔案的屬性是否正確？檔案在使用前是否開啟使用後是否關閉？檔案結束條件是否被正確處理？
2） i/o語句是否符合格式規範？是否處理了i/o 錯誤？
3）緩衝大小與記錄大小是否配？
6、記憶體錯誤
1）為指標分配記憶體後，是否判斷指標是否為null？
2）指標使用前是否賦初值？
3）陣列或指標的下標是否越界？
4）記憶體申請和釋放是否匹配？
5）將指標所指向的記憶體釋放後，是否第一時間將指標置為null？（防止使用「野指標」）
6）是否將函式內部的區域性變數（分配在棧上）作為返回值？
四、 測試用例的設計
1、 白盒測試（邏輯覆蓋測試）
可靠性由高到低：多重條件覆蓋準則》判定/條件覆蓋準則》分支覆蓋》判定覆蓋》語句覆蓋
1）判定覆蓋：
要求每個判斷都必須有「是」和「否」的結果，而且每個入口點都必須至少被呼叫一次。
2）條件覆蓋
確保將乙個判斷中的每個條件的所有可能的結果至少執行一次。
3）判定/條件覆蓋準則
設計出充足的測試用例。將乙個判斷中的每個條件的所有可能的結果至少執行一次；將每個判斷的每個條件的所有可能的結果至少執行一次；將每個判斷的所有可能的結果至少執行一次；將每個入口點都至少呼叫一次。
4）多重條件覆蓋準則
要求編寫足夠多的測試用例，將每個判定中的所有可能的條件結果的組合，以及所有的入口點都至少執行一次。
2）生成測試用例
編寫測試用例，盡可能多地覆蓋尚未被涵蓋的有效等價類，直到所有的有效等價類都被測試用例覆蓋。
編寫測試用例，覆蓋乙個且僅乙個尚未被覆蓋的無效等價類，直到所有的無效等價類都被測試用例所覆蓋。（因為某些特定的輸入錯誤檢查可能會遮蔽或取代其他輸入錯誤檢查。）
3）不足：忽略了某些特定型別的高效測試用例。
3、 邊界值分析
1） 定義：是指輸入和輸出等價類中那些恰好處於邊界、或超過邊界、或在邊界以下的狀態。
2） 方法：
針對輸入條件規定的輸入值範圍的邊界設計測試用例，對剛剛越界的情況設計無效輸入測試用例。
針對輸入條件規定的輸入值的數量設計測試用例（如最小數量輸入值、最大數量輸入值，以及比最小數量少乙個、比最大數量多乙個的情況）。
如果程式的輸入或輸出是乙個有序序列（例如順序的檔案、線性列表或**），則應特別注意該序列的第乙個和最後乙個元素。
3） 不足：未對輸入條件的組合進行分析。
4、 因果圖
因果圖方法是乙個根據條件的組合而生成測試用例的系統性的方法。
1） 畫因果圖
2） 建立有限項的判定表
a、選擇乙個「果」作為當前狀態。
b、對因果圖進行回溯，查詢導致該「果」為1（根據約束條件）的所有「因」
的組合。
c、在判定表中為每個「因」的組合生成一列。
d、對於每種「因」的組合，判斷所有其它「果」的狀態，並放置在每一列中。
判定表的乙個重要目標：減少因果圖中的組合關係。它們排除了會導致生成低效測試用例的狀態。如果不能排除低效測試用例，那麼乙個因果關係複雜的大因果圖會生成天文數字的測試用例。
3） 最後乙個步驟，是將判定表轉化為測試用例。
5、 測試策略
一組合理的策略如下：
1. 如果規格說明中包含輸入條件組合的情況，應首先使用因果圖分析方法。
2. 在任何情況下都應使用邊界值分析方法。應記住，這是對輸入和輸出邊界
進行的分析。邊界值分析可以產生一系列補充的測試條件，但是，也正如
「因果圖分析」一節所述，多數甚至全部條件都可以被整合到因果圖分析
中。 3. 應為輸入和輸出確定有效和無效等價類，在必要情況下對上面確認的測試
用例進行補充。
4. 使用錯誤猜測技術增加更多的測試用例。
5. 針對上述測試用例集檢查程式的邏輯結構。應使用判定覆蓋、條件覆蓋、
判定/條件覆蓋或多重條件覆蓋準則（最後的乙個最為完整）。如果覆蓋準
則未能被前四個步驟中確定的測試用例所滿足，並且滿足準則也並非不可
能（由於程式的性質限制，某些條件的組合也許是不可能實現的），那麼增
加足夠數量的測試用例，以使覆蓋準則得到滿足。
（部分內容摘自glonford j.myors《軟體測試的藝術》一書）
軟體測試的藝術 讀書筆記 五
當程式無法實現其終端使用者的要求的合理功能時，就發生了乙個軟體錯誤 軟體開發過程 溝通有關最終程式的資訊，並將資訊從一種形式轉換到另一種形式。由於資訊的轉化，大部分軟體錯誤都可以歸結為資訊溝通和轉換時發生的故障 差錯 干擾。解決辦法 在產生需求和設計的時候每一步的輸出和上一步要的結果做驗證，驗證有不...
軟體測試的藝術 讀書筆記 七
類別描述 連線裝置硬體配置 網路速度 網路延時 偏遠地區網路可用性 服務可靠性 裝置多樣性 測試不同裝置web，android ios 測試的不同的語言版本 裝置的各種限制 優先的處理器和記憶體資源 不同螢幕尺寸 多作業系統 多工應用的這次 快取資料的大小 輸入裝置 觸控螢幕觸控筆 滑鼠鍵盤 按鍵滾...
軟體測試的藝術 讀書筆記 六
網際網路平台的開放性和易訪問性，使用者對 的期望很高，市場競爭激烈，如果無法提供快速響應和直觀的瀏覽 查詢功能 使用者就很有可能轉向競爭對手的 第一層 web層，顯示層或表示層，視覺化內容提供給終端使用者 第二層 業務層 處理業務流程，有事務處理，使用者身份鑑定，資料確認，程式日誌 等 第三層 資料...