軟件測試：
????????軟件測試，是一個過程或一系列過程．用來確認計算機代碼完成了其應該完成的功能不執行其不該有的操作。軟件應當是可預測且穩定的，不會給用戶帶來意外驚奇。更準確的說，“測試是為發現錯誤而執行程序的過程”。

軟件測試的重要原則：

編號	原則
0	軟件測試是為發現錯誤而執行程序的過程
1	測試用例中一個必需部分是對預期輸出或結果進行定義
2	程序員應避免測試自己編寫的程序
3	編寫軟件的組織不應當測試自已編寫的軟件
4	應當徹底檢查每個測試的執行結果
5	測試用例的編寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效 和未預料到的輸入情況
6	檢查程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程是 否“做了其不應該做的”
7	應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件
8	計劃測試工作時不應默許假定不會發現錯誤
9	程序某部分存在更多錯誤的可能性，與該部分已發現錯誤的數量成正比
10	軟件測試是一項極富創造性，極具智力的挑戰性的工作
11	一個好的測試用例具有較高的發現某個尚未發現的錯誤的可能性
12	一個成功的測試用例能夠發現某個尚未發現的錯誤

用于代碼檢查錯誤列表：

? ? ? ? 主要有八種：數據引用錯誤、數據聲明錯誤、數據運算錯誤、數據比較錯誤、控制流程錯誤、接口錯誤、輸入輸出錯誤、其他檢查；? ? ? ??

數據引用錯誤	運算錯誤
1.是否有引用的變量未賦值或未初始化？	1.是否存在非算術變量間的運算？
2.下標的值是否在范圍之內？	2.是否存在混合摸式的運算？
3.是否存在非整數下標？	3.是否存在不同字長變量問的運算？
4.是否存在虛調用？	4.目標變量的大小是否小于賦值大小？
5.當使用別名時屬性是否正確？	5.中間結果是否上溢或下溢？
6.記錄和結構的屬性是否匹配？	6.是否存住被 0 除？
7.是否計算位串的地址？是否傳遞位串參數？	7.是否存在二進制的不精確度？
8.基礎的存儲屬性是否正確？	8.變量的值是否超過了有意義的范圍？
9.跨過程的結構定義是否匹配？	9.操作符的優先順序是否被正確理解？
10.索引或下標操作是否有“僅差一個”的錯誤？	10.整數除法是否正確？
11.繼承需求是否得到滿足？

數據聲明錯誤	比較錯誤
1.是否所有的變量都已聲明？	1.是否存在不同類型變量間的比較？
2.默認的屬性是否被正確理解？	2.是否存在混合模式的比較運算？
3.數組和字符串的初始化是否正確？	3.比較運算符是否正確？
4.變量是否賦予了正確的長度，類型和存儲類？	4.布爾表達式是否正確？
5.初始化是否與存儲類相一致？	5.比較運算是是否與布爾表達式相混合？
6.是否有相似的變量名？	6.是否存在二進制小數的比較？
	7.操作符的優先順序是否被正確理解？
	8.編譯器對布爾表達武的計算方式是否被正確理解？

控制流程錯誤	輸入/輸出錯誤
1.是否超出了多條分支路徑？	1.文件的屬性是否正確？
2.是否每個循環都終止了？???????	2.0PEN 語句是否正確？
3.是否每個程序都終止了？	3.I/O 語句是否符合格式規范？
4.是否存在由于入口條件不滿足而跳過循環 體？	4.緩沖大小與記錄大小是否匹配？
5.可能的循環越界是否正確？	5.文件在使用前是否打開？
6.是否存在“僅差一個”的迭代錯誤？??????	6.文件在使用后是否關閉？
7.DO/END 語句是否匹配？	7.文件結束條件是否被正確處理？
8.是否存在不能窮盡的判斷？	8.是否處理了 I/O 錯誤？
9.輸出信息中是否有文字或語法錯誤？

接口錯誤	其他檢查
1.形參的數量是否等于實參的數量？	1.在交叉引用列表中是否存在未引用過的變量？
2.形參的量綱是否與實參的量綱相匹配？	2.屬性列表是否與預期的相一致？
3.形參的量綱是否與實參的量綱相匹配？	3.是否存在“警告”或“提示”信息？
4.傳遞給被調用模塊的實參個數是否等于其形參個數？	4.是否對輸入的合法性進行了檢查？
5.傳遞給被調用模塊的實參屬性是否與其形參屬性匹配？ ???????	5.是否遺漏了某個功能？
6.傳遞給被調用模塊的實參量綱是否與其形參量綱匹配？
7.調用內部函數的實參的數量、屬性，順序是否正確？
8.是否引用了與當前入口點無關的形參？
9.是否改變了某個原本僅為輸入值的形參？
10.全局變量的定義在模塊間是否一致？
11.常數是否以實參形式傳遞過？

測試方法：

黑盒測試	白盒測試
等價類劃分	語句覆蓋
邊界值分析	判定覆蓋
因果圖分析	條件覆蓋
錯誤測試	判定/條件覆蓋
	多重條件覆蓋

????????等價類劃分：將程序所有可能的輸入數據(有效的和無效的)劃分成若干個等價類。然后從每個部分中選取具有代表性的數據當做測試用例進行合理的分類,測試用例由有效等價類和無效等價類的代表組成,從而保證測試用例具有完整性和代表性。 ????????邊界值分析：是指輸入和輸出等價類中那些恰好處于邊界、或超過邊界、或在邊界以下的狀態。

????????因果圖分析：從用自然語言書寫的程序規格說明的描述中找出因（輸入條件）和果（輸出或程序狀態的改變），可以通過因果圖轉換為???????判定表，從而設計相應的測試用例。
????????錯誤測試：指接到具體的程序之后，他們利用直覺和經驗猜測出錯的可能類型， 然后編寫測試用例來暴露這些錯誤。

合理的測試策略：

????????1. 如果規格說明中包含輸入條件組合的情況，應首先使用因果圖分析方法。
????????2. 在任何情況下都應使用邊界值分析方法，邊界值分析可以產生一系列補充的測試條件，但是，也正如“因果圖分析”一節所述，多數甚至全部條件都可以被整合到因果圖分析中。
????????3. 應為輸入和輸出確定有效和無效等價類，在必要情況下對上面確認的測試用例進行補充。
????????4. 使用錯誤猜測技術增加更多的測試用例。
????????5. 針對上述測試用例集檢查程序的邏輯結構。應使用判定覆蓋、條件覆蓋、判定/條件覆蓋或多重條件覆蓋準則（最后的一個最為完整）。如果覆蓋準則未能被前四個步驟中確定的測試用例所滿足，并且滿足準則也并非不可能（由于程序的性質限制，某些條件的組合也許是不可能實現的），那么增加足夠數量的測試用例，以使覆蓋準則得到滿足。

????????上述策略并不能保證可以發現所有的錯誤，但實踐證明這是一個合理的折中方案。

? ? ? ?

好的測試計劃應包括：

????????1. 目標。必須定義每個測試階段的目標。
????????2. 結束準則。必須制定準則以規定每個測試階段何時可以結束。一般兩條準則：1. 用完了安排的測試時間后，測試使結束。 2. 當執行完所有測試用例都未發現錯誤，測試便結束。也就是說，當所有的測試用例不成功時便結束。
????????3. 進度。每個階段都須有時間表。應指出何時設計、編寫和執行測試用例，某些軟件技術，如極限編程，要求在程序編碼開始之前就設計測試用例和單元測試。
????????4. 責任。對于每一個階段，應當確定誰來設計、編寫和驗證測試用例，誰來修改發現的軟件錯誤。由于在大型項目中討論特定的測試結果是否代表錯誤時，有可能出現爭端，因此還需要確定一名仲裁者。
????????5. 測試用例庫及標準。在大型項目中，用于確定、編寫以及存儲測試用例的系統方法是必須的。
????????6. 工具。必須確定需要使用的測試工具，包括計劃由誰來開發或采購、如何使用工具以及何時需要使用工具。
????????7. 計算機時間。計劃每個測試階段所需的計算機時間，包括用來編譯應用程序的服務器（如果需要的話）、用來進行安裝測試所需的桌面計算機、用來運行基于 web 應用程序的 web 服務器、聯網的設備（如果需要的話）等等。
???????????????8. 硬件配置。如果需要特別的硬件配置或設備，則需要一份計劃來描述該需求，該如何滿足需求以及何時需要滿足。
????????9. 集成。測試計劃的一部分是定義程序如何組裝在一起的方法（例如自頂向下的增量測試）。一個系統如果包含大的子系統或程序，可按增量的方式組裝在一起，例如可以使用自頂向下或自底向上的方法，但是這些構造塊是程序或子系統，而不是模塊。如果是這種情況，就需要一個系統集成計劃。系統集成計劃規定了系統集成的順序、系統每個版本的功能以及編寫“腳手架”代碼以模擬不存在的部件的職責分工。
????????10. 跟蹤步驟。必須跟蹤測試進行中的方方面面，包括對錯誤易發模塊的定位，以及有關進度、資源和結束準則的進展估計。
????????11. 調試步驟。必須制定上報已發現錯誤、跟蹤錯誤修改進程以及將修改部分加入系統中去的機制。調試計劃中還應包括進度、責任分工、工具以及計算機時間/資源等。
????????12. 回歸測試。回歸測試在對程序作了功能改進或進行了修改之后進行，其目的是判斷程序的改動是否引起了程序其他方面的退步。回歸測試通常重新執行測試用例中的某個子集。回歸測試很重要，因為對程序的改動和對錯誤的糾正要比原來的程序代碼更容易出錯（與報紙排版錯誤很相似，這些錯誤通常由于最后所做的編輯改動而引起的，而不是修改先前版本而引起的）。回歸測試計劃規定了測試人員、測試方法和測試時間，它也是必須的。

測試相關名詞：

????????black-box testing（黑盒測試）將程序視為一個整體、且忽略其內部結構的測試方法。單純從軟件的規格說明中獲取測試數據。 ????????bottom-up testing（自底向上的測試）增量模塊測試的一種形式，首先測試底層模塊，再測試調用模塊等等。 ????????boundary-value analysis（邊界值分析），一種黑盒測試方法，重點在于程序輸 t 入區間的邊界區域。 ????????branch coverage（分支覆蓋）參見“判定覆蓋”。 ????????cause-effect graphing（因果圖分析）使用簡化的數字邏輯電路圖（組合邏輯網絡）輔助生成一組高效測試用例的技術。 ????????code inspection（代碼檢查）一套供小組代碼閱讀的規程和錯誤檢查枝術，作為檢查錯誤的測試周期的一部分，通常使用一份常見錯誤的列表來對照代碼。 ????????condition coverage（條件覆蓋）白盒測試的一項準則，要求編寫足夠數量的測試用例，確保將一個判斷中的每個條件的所有可能的結果至少執行一次。 ????????data-driven testing （數據驅動測試）參見“黑盒測試”。 ????????decision/condition coverage （判定／條件覆蓋）自盒測試的一項準則，要求編寫足夠數量的測試用例，確保將每個判斷中的每個條件的所有可能的結果至少執行一次，將每個判斷的所有可能的結果至少執行一次，將每個入口點都至少調用一次。 ????????decision coverage（判定覆蓋）白盒測試的一項準則。要求編寫足夠數量的測試用例，確保每一個判斷都至少有一個為真和為假的輸出結果。 ????????desk checking（桌面檢查）一種將代碼審查和走查技術結合起來，在用戶桌面上執行程序的技術。 ????????equivalence partitioning（等價類劃分）一種黑盒測試技術，其中每個測試用例都必須體現盡可能多的不同的輸入情況，以最大限度地減少全部用例的數量。應該盡量將程序輸入范圍劃分為等價類，這樣類中某個輸入數據的測試結果等同于同類中所有輸入數據的測試結果。 ????????exhaustive input testing（窮舉輸入測試）黑盒測試的一項準則，通過將每個可能的輸入條件都作為測試用例，盡量發現程序中的所有錯誤。 ????????external specification（外部規格說明）從某個相關系統部件用戶的角度對程序功能的精確描述。 ????????facility testing（能力測試）系統測試的一種類型，判斷目標文檔提及的每一項能力（或功能）是否都實現了。不要混淆能力測試與功能測試。 ????????function testing（功能測試）發現程序與其外部規格說明之間存在不一致的過程。 ????????incremental testing（增量測試）模塊測試的一種形式，將待測模塊與已測模塊組裝在一起進行測試。 ????????input/output testing（輸入／輸出測試）參見“，象盒淚 11 試”。 ????????logical-driven testing（邏輯驅動測試）參見“白盒測試”。 ????????multi-condition coverage（多重條件覆蓋）白盒測試的一項準則，要求編寫足夠數量的測試用例，確保每個判定中的所有可能的條件結果的組合，以及所有的入口點都至少執行一次。 ????????nonincremental testing（非增量測試）模塊測試的一種形式，每個模塊單獨進行測試。 ????????performance testing（性能測試）系統測試的一種形式，盡量證明程序不能滿足特定的指標，如在特定負載和配置環境下的響應時間和吞吐率。 ????????random-input testing（隨機輸入測試）在所有可能的輸入值中隨機選取一個子集來對程序進行測試的過程。
????????security testing（安全性測試）系統測試的一種形式，用以考驗程序或系統的安全保密機制。 ????????stress testing（強度測試）系統測試的一種形式，使程序經受高負載或強度。高強度是指在很短的時間間隔內達到的數據或操作的數量峰值。因特網應用系統通常需要進行強度測試，因為會有大量用戶并發訪問系統。 ????????system testing（系統測試）高級測試的一種形式，將系統或程序與其初始目標進行比較。為了完成系統測試，需要一套書面的可度量的目標。 ????????testing（測試）為了發現錯誤而執行程序（或具體的程序單元）的過程。top-down testing（自頂向下的測試）增量模塊測試的一種形式，首先測試初始模塊，再測試下一個子模塊等等。 ????????usability testing（易用性測試）系統測試的一種形式，測試程序的人機界面。通常要檢查的部件包括界面布局、界面色彩、輸出格式、輸入字段、程序流程、拼寫等等。 ????????volume testing（容量測試）系統測試的一種形式，使用大容量的數據檢驗程序能否處理目標文檔中規定數據容量。容量測試與強度測試并不相同。 ????????walkthrough（走查）一套供小組代碼閱讀的規程和錯誤檢查技術，作為檢查錯誤的測試周期的一部分。通常一個小組的人起到“計算機”的作用，執行一個小的測試用例集。 ????????white-box testing（白盒測試）一種檢查程序內部結構的測試類型。

??????????????????????

總結

以上是生活随笔為你收集整理的软件测试的艺术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。