軟件測試的7個基本原則

畢生所學，得到最重要的東西是一種以原則為基礎(chǔ)的生活方式，是它幫助我發(fā)現(xiàn)真相是什么，并據(jù)此如何行動。
– Ray Dalio《原則》

原則(Principles )，是每個人在行事中所遵循的準則。每個人都有自己的原則，或成人，或尚處襁褓。軟件測試也有一套原則讓每位軟件測試從業(yè)人員去遵循，這些原則是前輩們前仆后繼在無數(shù)的坑坑洼洼中總結(jié)出來的。

軟件測試的原則是指幫助測試團隊有效地利用他們的時間和精力來發(fā)現(xiàn)測試項目的隱藏bug的指導(dǎo)方針。從實際的實踐和研究中，研究了以下 7 條軟件測試的基本原則，以便測試人員在軟件測試領(lǐng)域廣泛應(yīng)用。

原則一：測試證明軟件存在缺陷

Testing shows presence of defects
時至今日，依然有不少人容易犯錯：沒有發(fā)現(xiàn)錯誤的測試說明軟件沒有缺陷。
這個原則可以用另一種方式來描述: 測試的本質(zhì)是證明軟件存在缺陷，而不是軟件沒有任何缺陷。
測試只能證明軟件是存在缺陷的（證偽），而不是證明軟件是沒有缺陷的（證實）。

軟件測試只能找出應(yīng)用程序或軟件中存在的缺陷，測試是為了輔助開發(fā)，降低缺陷存在的可能性而開展的活動，即便對產(chǎn)品或者應(yīng)用程序進行了多次的、比較徹底的測試都沒有發(fā)現(xiàn)任何缺陷，也不能證明軟件是100%完美的。

原則二：窮盡測試是不可能的

Exhaustive testing is impossible
測試數(shù)據(jù)、輸入和測試場景的所有組合是不可能的，因為它需要大量的時間。相反，測試團隊只能專注于一些重要的指標，例如：設(shè)置測試策略的風險和優(yōu)先級。一般來說，項目周期里永遠不可能允許測試團隊在項目中進行大量有效的組合測試。
比如測試一個簡單的計算器，你可以嘗試1+1,1+2,1+3,1+n……，但是時間上允許你把所有的數(shù)字都考慮進去做詳盡測試嗎？顯然是不可能的，從功能本身出發(fā)也算是多余操作。
隨著系統(tǒng)承載業(yè)務(wù)多，代碼規(guī)模也越龐大，算法邏輯復(fù)雜度也越高。要讓測試完全覆蓋是不可能的。那難道不測？非也！我們可以采取以下策略：
1、精準測試：改動什么測什么；
2、二八原則：只測重點；
3、等價劃分；
等等

原則三：盡早介入測試

Testing Early
這條很重要，但是對測試的要求也會更高。
“早期的鳥兒有蟲吃”或者是“早起的蟲子被鳥吃”，對，說的就是這個理兒，早，是我們解決問題的有效辦法。
必須盡早介入測試活動，為軟件開發(fā)的下一階段做好準備。只要生成產(chǎn)品需求或文檔，測試人員甚至就可以開始測試。

據(jù)調(diào)查，缺陷的修復(fù)成本與其發(fā)現(xiàn)時間成反比，且越晚修復(fù)其修復(fù)成本將會成指數(shù)級增長。

顯然，從一開始就解決問題總是更容易、更便宜，而不是如果發(fā)現(xiàn)錯誤太晚就改變整個系統(tǒng)。因此，通過早期測試，測試人員可以檢測到錯誤，并幫助開發(fā)團隊以更少的成本和精力解決問題。
另外，盡早介入測試，測試人員能夠更全面的了解需求和項目整體進度，知己知彼百戰(zhàn)不殆，說的就是這個理兒。
盡早介入測試原則與測試左移和測試前移具有異曲同工之妙。

原則四：缺陷具有集群性

Defect Clustering
之前聽過一種理論，二八原則，即：80%的錯誤是由20%的模塊引起的。
缺陷聚類指的是在幾個模塊中發(fā)現(xiàn)了大部分缺陷。這一原則要求測試團隊利用自己的知識和經(jīng)驗，確定要測試的潛在模塊。這一預(yù)測有助于節(jié)省時間和精力，因為團隊只需要關(guān)注那些 “敏感” 領(lǐng)域。
然而，這種方法也有缺點: 一旦測試人員只專注于所有團隊的一小塊區(qū)域，他們可能會錯過其他區(qū)域的錯誤。

原則五：殺蟲劑悖論

Pesticide Paradox

當我們反復(fù)使用相同的殺蟲劑的時候，會有少量害蟲產(chǎn)生免疫而存活下來，使得殺蟲劑失去藥效。

殺蟲劑悖論是指測試人員一直使用相同的方法或手段去重復(fù)測試，這些測試只適用于一些有限的模塊，而不是整個系統(tǒng)。這種測試可能很難發(fā)現(xiàn)bug，甚至無法發(fā)現(xiàn)bug。因此，為了涵蓋項目的各個部分，它要求測試團隊經(jīng)常審查和更新測試用例。

原則六：測試是上下文相關(guān)的

Testing is context dependent
各種產(chǎn)品或項目包含不同的元素、特征和要求。因此，測試人員不能對不同的項目應(yīng)用相同的測試方法。例如，銀行行業(yè)的應(yīng)用程序應(yīng)該比娛樂軟件需要做更多的測試。

原則七：無錯誤謬論

Absence of error - Fallacy
在 原則一：測試顯示軟件存在缺陷 中說明，測試是為了降低缺陷存在的可能性而開展的活動，即便多次測試都沒有發(fā)現(xiàn)任何缺陷，也不能證明軟件是完美的。

軟件測試不僅僅是為了找出Bug而存在的活動，而是還需要確認軟件是否滿足用戶的期望和需求，如果產(chǎn)品不能滿足用戶的需求，即使沒有出現(xiàn)任何缺陷，這個產(chǎn)品也是失敗的。

“沒有錯誤” 并不是我們的追求，在互聯(lián)網(wǎng)時代，始終快速給用戶創(chuàng)造最大的價值才是我們孜孜不倦的追求。

上述原則是由 Rex Black 、 Erick Van Veenendaal 和 Dorothy Graham 的研究 “軟件測試基礎(chǔ)” (ISTQB 認證) 總結(jié)的。這些原則可以作為大多數(shù)測試項目的核心指南。然而，如上所述，每個產(chǎn)品或項目都包含非常不同的因素和需求，需要各種測試方法。測試人員應(yīng)該利用他們的經(jīng)驗和知識來決定和平衡這些方法。

Appium往期教程：

1. Appium移動端自動化測試--基礎(chǔ)預(yù)熱
2. Appium移動端自動化測試--搭建測試環(huán)境
3. Appium移動端自動化測試--錄制測試用例并運行
4. Appium移動端自動化測試--使用IDE編輯并強化腳本
5. Appium移動端自動化測試--控件定位方法
   
6. Appium移動端自動化測試--元素操作與觸摸動作
   
7. Appium移動端自動化測試--搭建模擬器和真機環(huán)境
   
8. Appium移動端自動化測試--測試用例改造
   
9. Appium移動端自動化測試--capability使用和常用設(shè)備交互命令

文章合集

Selenium?|?Appium??|?Jenkins??|??Jmeter?

軟件測試方法匯總?|?Postman接口參數(shù)化?|?測試用例設(shè)計?|?安卓APP抓包

視頻教程

Selenium?|?Appium?|?Jenkins?|?Jmeter

微信群：
軟件自動化測試交流群已創(chuàng)建，公號回復(fù)入群即可獲取入群二維碼。

自動化測試框架，你知道幾種？