軟件測試的藝術(shù)?

?第一章?????? 一次自評價測試 所謂軟件測試，就是一個過程或一系列過程，用來確認計算機代碼完成了其應(yīng)該完成的功能，不執(zhí)行其不該有的操作。?

?第二章?????? 軟件測試的心理學和經(jīng)濟學 2.1 軟件測試的心理學 測試的定義：測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 2.2軟件測試的經(jīng)濟學 2.2.1 黑盒測試 黑盒測試是一種重要的測試策略，又稱為數(shù)據(jù)驅(qū)動的測試或輸入/輸出驅(qū)動的測試。使用這種測試方法時，將程序視為一個黑盒子。測試目標與程序的內(nèi)部機制和結(jié)構(gòu)完全無關(guān)。而是將重點集中放在發(fā)現(xiàn)程序不按其規(guī)范正確運行的環(huán)境條件。 窮舉輸入測試 ?2.2.2 白盒測試 或稱邏輯驅(qū)動的測試，允許我們檢查程序的內(nèi)部結(jié)構(gòu)。這種測試策略對程序的邏輯結(jié)構(gòu)進行檢查，從中獲取測試數(shù)據(jù)。 窮舉路徑測試 2.3 軟件測試的原則 原則1：測試用例中一個必需部分是對預(yù)期輸出或結(jié)果的定義 原則2：程序員應(yīng)當避免測試自己編寫的程序 原則3：編寫軟件的組織不應(yīng)當測試自己編寫的軟件 更經(jīng)濟的方法是由客觀,獨立的第三方進行測試。 原則4：應(yīng)當徹底檢查每個測試的執(zhí)行結(jié)果 原則5：測試用例的編寫不僅應(yīng)當根據(jù)有效和預(yù)期的輸入情況，而且也應(yīng)當根據(jù)無效和未預(yù)料到的輸入情況。 原則6：檢查程序是否“未做其應(yīng)該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應(yīng)該做的”。 原則7：應(yīng)避免測試用例用后即棄，除非軟件本身就是一個一次性的軟件 原則8：計劃測試工作時不應(yīng)默許假定不會發(fā)現(xiàn)錯誤 原則9:程序某部分存在更多錯誤的可能性，與該部分已發(fā)現(xiàn)錯誤的數(shù)量成正比 原則10：軟件測試是一項極富創(chuàng)造性、極具智力挑戰(zhàn)性的工作 2.4 小結(jié) 在閱讀本書接下來的內(nèi)容時，請牢記以下三個重要的測試原則： 軟件測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程 一個好的測試用例具有較高的發(fā)現(xiàn)某個尚未發(fā)現(xiàn)的錯誤的可能性 一個成功的測試用例能夠發(fā)現(xiàn)某個尚未發(fā)現(xiàn)的錯誤

?第三章?????? 代碼檢查、走查與評審 3.1 代碼檢查和走查 代碼檢查和走查都要求人們組成一個小組來閱讀或直觀檢查特定的程序。無論采用哪種方法，參加者都需要完成一些準備工作。準備工作的高潮就是在參加者會議上進行的所謂“頭腦風暴會”。目標是找出錯誤，但不必找出改正錯誤的方法。 3.2 代碼檢查 所謂代碼檢查，是以組為單位閱讀代碼，它是一系列規(guī)程和錯誤檢查技術(shù)的集合。對代碼的檢查的大多數(shù)討論都集中在規(guī)程、所要填寫的表格等。 代碼檢查小組 3.3 用于代碼檢查的錯誤列表 3.3.1 數(shù)據(jù)引用錯誤 3.3.2 數(shù)據(jù)聲明錯誤 3.3.3 運算錯誤 3.3.4 比較錯誤 3.3.5 控制流程錯誤 3.3.6 接口錯誤 3.3.7 輸入/輸出錯誤 3.4 代碼走查 代碼走查會議的規(guī)程與代碼檢查不相同，代碼走查的參與者“使用了計算機” 3.5 桌面檢查 單人進行代碼檢查 3.6 同行評分

?第四章? 測試用例的設(shè)計 ??????? 4.1 白盒測試 ??????? 4.1.1 邏輯覆蓋測試 ??????? 判定覆蓋和條件覆蓋 ??????? 4.1.2 等價劃分 ??????? 4.1.4 邊界值分析 ??????? 4.1.5 因果圖 ??????? 4.2 錯誤猜測 ??????? 依賴于直覺的非正規(guī)的過程?

?第五章?????? 模塊（單元）測試 模塊測試（單元測試）是對程序中的單個子程序或子程序或過程進行測試的過程，也就是說，一開始并不是對整個程序進行測試，而是首先將注意力集中在對構(gòu)成程序的較小模塊的測試方面。 5.1 測試用例設(shè)計 模塊測試的測試用例的設(shè)計過程如下:使用一種或多種白盒測試方法分析模塊的邏輯結(jié)構(gòu)，然后使用黑盒測試方法對照模塊的規(guī)格說明以補充測試用例。 5.2 增量測試 非增量測試或者崩潰測試：先獨立地測試每個模塊，然后再將這些模塊組裝成完整的程序。 增量測試或集成：將下一步要測試的模塊組裝成測試完成的模塊集合中，然后再進行測試。 增量測試更能發(fā)現(xiàn)問題，非增量測試更便于獨立執(zhí)行 5.3 自頂向下測試與自底向上測試 5．3.1? 自頂向下的測試 自頂向下的測試是從程序的頂部或初始模塊開始。測試開始之后，挑選哪一個后續(xù)模塊進行增量測試沒有惟一正確的方法；唯一的原則是：要成為合乎條件的下一個模塊，至少一個該模塊的從屬模塊（調(diào)用它的模塊）事先經(jīng)過了測試。 5.3.2 自底向上的測試 自底向上的策略開始于程序中的終端模塊（此類模塊不再調(diào)用其他任何模塊）。測試完這些模塊后，同樣沒有最佳的方法來挑選要進行增量測試的下一個模塊；惟一正確的原則是，要成為合乎條件的下一個模塊，該模塊所有的從屬模塊（它調(diào)用的模塊）都已經(jīng)事先經(jīng)過了測試。 5.4 執(zhí)行測試 使用自動化測試工具可以使測試過程中的枯燥勞動減至最小。舉例來說，現(xiàn)在已有測試工具可以降低我們對驅(qū)動模塊的需求。流程分析工具可以列舉出程序中的路徑，找出從未被執(zhí)行的語句(“不可達”代碼)，以及找出變量在賦值前被使用的實例。

?第六章?????? 更高級別的測試 6.1 功能測試 功能測試是一個試圖發(fā)現(xiàn)程序與其外部規(guī)格說明之間存在不一致的過程，外部規(guī)格說明是一份從最終用戶的角度對程序行為的精確描述。 6.2 系統(tǒng)測試 系統(tǒng)測試特定的目的是將系統(tǒng)或程序與其初始目標進行比較 6.2.1 能力測試 判斷目標文檔提及的每一項能力是否都確實已經(jīng)實現(xiàn)。能力測試的過程是逐條語句地檢查目標文檔，當某條語句定義了一個“要做什么”，就判斷程序是否滿足。 6.2.2 容量測試 容量測試的目的是為了證明程序不能處理目標文檔中規(guī)定的數(shù)據(jù)容量。 6.2.3 強度測試 高強度是指在很短的時間間隔內(nèi)達到的數(shù)據(jù)或操作的數(shù)量峰值。 6.2.4 易用性測試 程序是否易于使用？ 6.2.5 安全性測試 6.2.6 性能測試 6.2.7 存儲測試 軟件偶爾會有存儲目標，舉例來說，可能描述了程序使用的內(nèi)存和輔存的容量，以及臨時文件或溢出文件的大小。 6.2.8 配置測試 比如在多種操作系統(tǒng)下 6.2.9 兼容性/配置/轉(zhuǎn)換測試 6.2.10 安裝測試 6.2.11 可靠性測試 6.2.12 可恢復性測試 6.2.13 適用性測試 6.2.14. 文檔測試 6.2.15 過程測試 在系統(tǒng)測試中，必須對所有已規(guī)定的人工過程，如系統(tǒng)操作員，數(shù)據(jù)庫管理員或最終用戶的操作過程進行測試。 6.2.16 系統(tǒng)測試的執(zhí)行 系統(tǒng)測試的執(zhí)行人思考問題的方式必須與最終用戶相同 6.3 驗收測試 驗收測試是將程序與其最初的需求及最終用戶當前的需要進行比較的過程。 6.4 安裝測試 6.5 測試的計劃與控制 一個良好的測試計劃應(yīng)包括： 1.目標? 2.結(jié)束準則 3.進度 4.責任 5.測試用例庫及標準 6.工具7.計算機時間 8. 硬件配置9.集成 10.跟蹤步驟 11.調(diào)試步驟 12.回歸測試 ???????? 6.6 測試結(jié)束準則 ???????? 對于功能測試和系統(tǒng)測試而言，結(jié)束準則可能是發(fā)現(xiàn)了既定數(shù)量的錯誤，或用完了計劃的時間，再出現(xiàn)什么都不管，但條件是錯誤分析與時間圖的對比表明測試的效率已很低了。?

?第七章? 調(diào)試 ?????? 調(diào)試是執(zhí)行一次成功的測試之后所要進行的工作。調(diào)試是一個包含兩個步驟的過程，從執(zhí)行了一個成功的測試用例，發(fā)現(xiàn)了一個問題之后開始。第一步，確定程序中可疑錯誤的準確性質(zhì)和位置；第二步，修改錯誤。 ?????? 7.1 暴力法調(diào)試 ?????? 7.2 歸納法調(diào)試 ?? ????7.3 演繹法調(diào)試 ?????? 7.4 回溯法調(diào)試 ?????? 7.5 測試法調(diào)試 ?????? 7.6 調(diào)試的原則 ?????? 7.6.1 定位錯誤的原則 ?????? 7.6.2 修改錯誤的技術(shù) ?????? 7.7 錯誤分析

?第八章? 極限測試 在測試之前設(shè)計好所有的測試用例