軟件測試原則

測試  原則 

測試原則

測試證明軟件存在缺陷

測試的本質是證明軟件存在缺陷，而不是軟件沒有缺陷。

人無完人，只要是人寫的代碼，肯定不能保證百分之百正確，除非特別簡單的功能。即便如此，也會存在各種環境問題，網絡問題等，更何況現在軟件原來越復雜，缺陷更是難以避免。

不可能執行窮盡測試

舉個很簡單的例子來說明，比如測試一個計算器功能里的加法，你可以嘗試1+1,1+2 ,1+3 ...你能把所有數組相加的情況都測試嗎，所以窮盡測試時不可能的，更別提是實際情況中，項目進度還有明確時間節點。截止日期。

測試應盡早啟動，盡早介入

這條很重要，但是對測試的要求也會更高。

先來講為什么要盡早啟動，舉例說明，軟件工程和蓋房子一樣，先也得設計，打好地基，試想假如設計階段，或者地基沒打好，你后面樓房蓋得越高，推到重來，或者回頭再去修改所耗費的成本也就越大，所以，測試要盡早介入。

系統測試階段

什么時候介入呢，對着需求文檔設計測試用例的時候，就開始測試了。軟件此時還在設計階段，測試站在質量和安全性角度，應該多多思考功能本身的可測試性，可靠性，完善用例的同時也可注意下 整個業務流程是否能形成完整的閉環。是否存在明顯的需求錯誤。

集成測試階段

還有一個場景，比如開發app時候，往往后端工程師 服務器先開發完成，此時無論ios還是android工程師都在開發中，等待更多接口完成，等待接口文檔。測試工程師此時便可以對着接口文檔，先進行服務器端的接口測試了。這樣聯調之前就可以先找到部分服務器缺陷，減少了前后端開發調試和糾錯時間。

單元測試階段

這個對測試來說有一定難度，多半還是開發人員自己完成，也就是每一個方法，類完成之后。自己對軟件的最小組成單元編寫測試代碼進行驗證。這就好像你蓋樓房，組成樓房的每一層階梯，每一塊磚頭質量先保證是好的。

缺陷存在群集現象（二八原則）

這個也是經驗之談了，一般認為，百分之80的缺陷集中出現在百分之20的核心功能區域。一旦你在某個功能模塊找到缺陷，相關附近功能多半也會存在問題。實戰中如何使用呢，寫缺陷報告的時候，做橫向對比，比對類似功能，相近模塊，版本，機型。指定回歸測試策略的時候，也可以重點測試。

殺蟲劑悖論

殺蟲劑悖論，很簡單，意思就是相同的功能，相同的用例，多次執行，后幾輪就慢慢找不到缺陷了。仿佛軟件對你的測試用例產生了抗葯性。所以，用例在每次執行完之后應該及時進行更新和維護，升級你的裝備。

不同測試活動依賴不同的測試背景

舉個例子來說明，你在金融公司測試，安全性就是第一位。電子商務測試，功能性則更加重要。

不存在缺陷的謬論

假如系統無法使用，或者系統不能完成客戶的需求和期望，發現和修改缺陷是沒有任何意義的。