目錄???????
簡述
2.1 無法對軟體進行完全的測驗
2.1.1 無法進行完全測驗的原因
2.1.2 結論
2.2 為什么軟體測驗是個復雜的活動
2.2.1 軟體測驗的復雜性
2.3 軟體測驗的經濟性
2.3.1 注意點
2.3.2 軟體測驗的作業原則
2.3.3 最佳測驗量?
2.3.4 影響測驗量的主要因素
2.4 軟體測驗方法
2.4.1 軟體測驗方法的分類
2.4.2 從三個角度分析，對方法進行分類
2.4.3 (動/靜)態測驗方法的具體理解
2.4.5 人工測驗和自動化測驗
簡述
本章先簡單介紹了軟體開發程序的三個階段：定義階段、開發階段、檢驗交付與維護階段，軟體開發程序中的活動與角色，軟體開發的開發模型有線性順序模型、原型模型、快速開發模型、演化軟體程序模型等，軟體開發與軟體測驗的關系等，并介紹了軟體測驗的七潭訓本原則，軟體測驗方法常用有：靜態測驗、動態測驗、白盒測驗、黑盒測驗、灰盒測驗、人工測驗、自動化測驗、模型檢測、胃煙測驗、隨機測驗等，最后介紹了軟體測驗的五種程序模型...
2.1 無法對軟體進行完全的測驗
2.1.1 無法進行完全測驗的原因
該例也只是對有效的例子進行了測驗，對不符合要求的測驗用例并沒有驗證，即軟體測驗，不僅要測驗所有合法的輸入是否給出了正確的結果，也要對那些不合法的但是有可能的輸入進行測驗，
用 “白盒測驗” 來說明第二點，“白盒測驗” 是窮舉路徑的測驗，
上述例子雖然回圈次數不多，但是路徑數太多了，導致無法對軟體進行完全的測驗，
2.1.2 結論
·測驗不能證明一個軟體是正確的，只能證明其是錯誤的，
·無法對軟體進行完全的測驗，
2.2 為什么軟體測驗是個復雜的活動
2.2.1 軟體測驗的復雜性
軟體測驗關鍵是要進行正確的判斷和合理的取舍，根據風險分析決定哪些故障必須修復，哪些故障可以不修復，通常，不能修復的軟體故障有如下幾條：
· 沒有足夠的時間修復（可能是軟體功能太多或者進度問題）
· 修復的風險較大
· 不值得修復（主要指不常用的功能中的一些故障或對運行影響不大的故障）
· 可不算作故障的一些缺陷
2.3 軟體測驗的經濟性
2.3.1 注意點
a. 要根據程式的重要性和可能故障造成的損失來決定測驗要達到什么樣的程度，
b. 要認真研究測驗策略，一定要用盡可能少的測驗用例發現盡可能多的測驗缺陷，
2.3.2 軟體測驗的作業原則
2.3.3 最佳測驗量
2.3.4 影響測驗量的主要因素
2.4 軟體測驗方法
2.4.1 軟體測驗方法的分類
單元測驗
集成測驗
確認測驗
系統測驗
驗收測驗
2.4.2 從三個角度分析，對方法進行分類
· 從是否需要執行被調程式的角度 分為：
· 從測驗是否針對系統的內部結構和具體實作的演算法角度 分為：
· 從測驗部分的主體的角度 分為：
*不應過多在意方法的類別，應確實理解每個方法的含義和適用范圍
2.4.3 (動/靜)態測驗方法的具體理解
第一種方法：代碼檢查（看的是問題的本身，比動態測驗更加有效，但耗費的人力和時間也很多）
第二種方法：靜態結構分析（主要以圖形的方式表示程式的內部結構，比如呼叫函式）
第三種方法：代碼質量度量（一般來說程式的復雜度越高，更容易出錯）
動態測驗分為：
· 功能確認與介面測驗
· 覆寫率測驗
· 性能分析
· 記憶體分析
2.4.4 (黑/白)盒測驗方法的具體理解與優劣比較
一般分別用在 系統測驗階段 和 單元測驗階段
2.4.5 人工測驗和自動化測驗
Tips：自動化測驗不可能完全實作自動化，離不開人的智力把控，但能替代人完成一些繁瑣或者不可能通過手工達到的事情，它的優點是在某些方面能提高測驗效率，特別是在違規測驗和某些性能測驗，
· 總結：在實際測驗中，應該綜合各種方法集成綜合測驗
后續補充...
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/297245.html
標籤：其他