軟體測試你需要知道的事（一） 概述

標籤：ar   io   os   sp   strong   on   資料   bs   cti   

軟體測試是描述一種用來促進評鑑軟體的正確性、完整性、安全性和品質的過程。軟體測試的經典定義是：在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體品質，並對其是否能滿足設計要求進行評估的過程。軟體測試也從客觀無關聯的角度提供一個關於所測軟體的一個概覽，從而可以對軟體所存在的風險有一個客觀的認識。

軟體測試所感興趣的一些測試屬性：

• 是否達到設計需求
• 對各種輸入是否返回正確的值
• 回應時間是否可以接受
• 可用性
• 是否能在預想的環境中正確運行

通常情況，由於所測軟體的小的組件、組成部分幾乎是無窮的，而軟體測試會採用可行的策略，在有限的時間跟資源裡面，去選擇性地測試。所以，軟體測試是為了找bug而對程式進行選擇性針對性的測試。換句話說，軟體測試是無法窮盡測試的。

在典型的瀑布開發流程中，軟體測試在程式可以部分執行的時候就積極引入，比如單元測試。相對而言，在敏捷開發中，需求、編程跟測試通常都是並發進行的。

缺陷跟錯誤（Defects & failures）

不是所有的軟體缺陷都是由編碼錯誤造成的。通常缺陷如果所處的位置越處於瀑布的頂端，則造成的損失越大，如需求中的分歧或者不清晰。所以越早發現缺陷越有利於缺陷的改正。需求中的分歧通常是指一些非功能性的需求，如程式的可測性，可維護性，易用性，效能以及安全性。

軟體錯誤（failure, fault, bug）通常是由於程式員的失誤造成軟體的輸出達不到預期要求。但是不是所有的程式錯誤都會造成軟體輸出與預期不一致。比如一段永遠不會被調用的代碼中含有程式錯誤。還有一種程式錯誤是運行環境改變造成的，比如你更換了硬體，作業系統等。

組合式輸入

軟體測試不可能把所有的可能的輸入都測試一遍，所以進行有選擇性的組合輸入是很有必要的。這樣可以使得使用者用盡量少的測試案例去擴大測試覆蓋度。比較常見的輸入組合有邊界值法，等價類別法，決策表法，因果圖等。

經濟因素

從圖表中也很容易看出缺陷或者是錯誤發現的越早，則修複它所花費的代價越小。反之，發現的越晚，則花費越大。

Cost to fix a defect		Time detected
		Requirements	Architecture	Construction	System test	Post-release
Time introduced	Requirements	1×	3×	5–10×	10×	10–100×
	Architecture	–	1×	10×	15×	25–100×
	Construction	–	–	1×	10×	10–25×

 

測試人員

80年代以前，測試人員統稱軟體測試員（software tester），而之後才有了更加精細的分工。如測試經理，測試組長，測試設計師，測試員，自動化測試員，測試管理員。

曆史階段

• 1956年及以前：面向調試的測試
• 1957-1978：面向證明的測試
• 1979-1982：面向破壞的測試
• 1983-1987：面向評估的測試
• 1988- 現在：面向預防的測試

測試工件

軟體測試工程中會產生的工件（產物）。

1. 測試計劃：測試說明書。
2. 文檔追蹤表：記錄測試過程中文檔的變動。也做版本控制用
3. 測試案例：根據需求而設計的測試一個具體事務的流程。包含了輸入跟期望輸出。複雜的測試案例可能會包含多個分支，根據不同的前提條件輸入，得到不同的結果。
4. 測試指令碼：用自動化工具，根據測試案例建立的測試指令碼，主要用來進行迴歸測試。
5. 測試組：一組測試案例的集合。比如一個模組的測試案例。
6. 測試資料
7. 測試載入器

 

軟體測試你需要知道的事（一） 概述