顛覆完美軟件：軟件測試必須知道的幾件事（讀書筆記4）

7、測試評估方法和測試誤區（第8章和第9章）

　　良好的測試是沒法確認的。可是咱們能夠經過不少方法，知道或估算出很差的測試是什麼樣的。識別出有關測試的主要誤區，能夠更好的進行測試。　　

　　測試的評估方法　

　　一、永遠沒法確切地知道良好的測試

　　完美的測試具備以下特色：a)它會檢測出一個系統中的全部缺陷；b)它永遠不會將不是缺陷的狀況判斷爲缺陷；3)它能讓咱們徹底確信它完成了a和b；d)針對咱們的須要，它能夠足夠迅速和廉價地實現a、b和c。你會發現完美的測試和很糟糕的測試具備驚人的類似性，一個很糟糕的測試也可能會知足a、b、c和d。

　　良好的測試是描述測試與某個實現之間的特定關係的屬性。咱們是沒法知道測試是良好的，可是咱們咱們能夠根據一些元信息知道測試是否糟糕。

　　二、根據事實來評估良好性

　　1）根據系統中缺陷的多少，來評估一組測試的良好性。

　　　　對這些缺陷進行追蹤，分析他們的具體使用狀況，能夠獲得一些信息。好比，測試有多好，以及好在哪些方面；未來能夠如何對測試加以改進；測試會常常遺漏哪一種缺陷。

　　2）根據長時間積累的缺陷，進行評估

　　3）其餘評估方法

　　　　將測試覆蓋範圍和故障理論進行比較；隨機改變測試來了解問題如何出現；對不一樣類型測試進行比較。

　　三、植入缺陷進行評估

　　　　插入已知的缺陷而不告訴測試人員，而後根據他們發現的這些已知缺陷來估算剩餘的缺陷數量。插入的缺陷是系統中天然產生，可是已經被開發人員在代碼審查或單元測試中解決了。

　　四、好的評估是統計性的

　　　　對良好性的估算只是一個估算。咱們只能從統計意義上估算良好性，由於咱們沒法確切地知道特定系統中由或者曾經有多少缺陷。

　　　　不少經理根據測試人員發現缺陷的數量來評價他們，這意味着低質的系統會讓測試人員看起來更好。這種缺陷的體系流行的緣由是：1）測試人員在解釋他們尋找缺陷的方法及他們的作法應該得到尊重的緣由方面作得不夠；2）經理和開發人員假定產品能夠工做的時候，沒有告訴測試人員關於產品的信息，好比應該從哪幾個方面來評定產品能夠正常工做。

　　五、其餘的估算方法

　　1）測試是否在名義上可以提供須要的信息？

　　2）測試是否進行了文檔記錄？

　　3）測試是不是真實的？有人能夠有意或無心的捏造測試數據和文檔嗎？

　　4）測試是否覆蓋了那些最重要的部分？不可能對全部路徑進行測試，但一組測試至少應該讓每行代碼都被訪問一次。

　　5）是否能夠看出測試和演示之間的區別？演示被設計用於讓系統看起來不錯。測試應該被設計用於讓系統表現出它真實的樣子。

　　6）測試報告是否表現出極強的可預測傾向，若是這樣，測試可能就過於表面化，或者報告中可能遺漏了某些重要信息。

　　7）不一樣類型的測試活動之間是否有不一致的地方？好比性能測試發現了功能性缺陷，可能意味着某個過程出了問題。

　　8）經理是明察秋毫嗎？測試經常會因爲存在一名由於專心而出名的好奇經理得以改進。

　　六、相關常識

　　1）須要考慮最終的測試目標，並思考如何得知本身將會須要哪些其餘信息。

　　2）不要已發現缺陷的數量來衡量測試人員，而要以得到信息的質量來評定。

　　3）瞭解正在測試的軟件結構有助於肯定要嘗試的特殊用例、細節特性和範圍，這些有助於縮小存在軟件能作什麼和它在實際使用中會作什麼的推理缺口。

　　4）測試過於瞭解產品內部結構也很差，因此測試最好能模擬那些初級用戶可能採用的行爲方式。

　　5）說明缺陷的估算數據應給出一個範圍（此版本中大約有30到40個缺陷），或者用統計分佈圖的方式。

　　6）發現大量缺陷會讓測試人員看起來工做的不錯，但會減緩測試的進度，下降測試的覆蓋範圍，或者同時致使兩種後果。由於安裝配置、缺陷調查和報告都會佔用測試設計和執行的時間。

　　測試的主要誤區

　　一、測試誤區

　　錯誤的想法會毀掉一個測試項目，這些誤區可能致使不良測試發生。

　　1）指責誤區

　　　　一些經理認爲，若是他們指責某我的，用責備的語氣和音量來講話，就可讓問題更快、更有效，也更高效地解決。這是不對的。

　　2）窮舉測試誤區

　　　　經理認爲的窮舉測試是對全部可能性進行測試。而真正的「窮舉測試」是指測試人員在測試方面已經筋疲力盡的時候。

　　3）「測試產生質量」誤區

　　　　質量是整個開發過程的產物。而測試主要仍是收集信息，產品質量的提升須要看經理對測試反饋的信息的態度。是當即進行修復仍是進行忽視無論。

　　4）分解誤區

　　　　開發人員對模塊進行單元測試，測試人員對接口進行系統測試。若是開發人員認爲對模塊進行的測試，就表明測試了整個系統。就犯了分解誤區。

　　5）合成誤區

　　　　測試人員認爲對系統總體進行測試，那麼組成該系統的各個部分進行了測試。就犯了合成誤區。

　　6）「全部測試都相同」誤區

　　　　開發人員測試單個模塊，測試人員測試系統。經過進行兩種不一樣類型測試，能夠肯定需求，目的和實現之間是否同樣。

　　7）「隨便哪一個笨蛋均可以測試」誤區

　　　　開發人員對模塊的測試老是探索性的，先前測試的結果會對未來的測試產生很大影響。測試人員應從開發人員那裏瞭解測試背後的動機，測試人員能夠根據有關產品和測試的最新信息來充實實際進行的測試。

　　二、相關常識

　　1）指責也許能夠帶來短時間效果，可是它帶來的長期後果可能不會有益的。

　　2）測試問題一般要求進行更多分析，尤爲是你發現本身正在指責別人時。

　　3）若是要求進行「窮舉測試」，獲得的就是測試人員以不一樣方式進行欺騙，對他們的經理進行隱瞞，直至最終的反叛。

　　4）認爲系統測試能夠捕獲全部缺陷，而將單元測試看成冗餘的加以忽略。忽略了單元測試，後期可能花更長的時間和成本進行測試。

　　5）質量是整個開發過程的產物。不良的測試會致使不良的質量，可是良好的測試並不必定能致使良好的質量，除非整個開發過程的其餘部分都是恰當的而且獲得了正確的執行。

8、如何反駁測試就是敲鍵盤的行爲（第10章）

　　敲擊鍵盤的行爲不是測試，那麼什麼樣的行爲纔是測試呢？

　　測試的真正工做室腦力活動。若是你敲擊鍵盤的時候沒有思考，你就不是在進行測試。若是你在思考可是沒有敲擊鍵盤，你可能仍是在測試。

　　做者給出總結：一種行爲要成爲測試，無論他是否包括了敲擊鍵盤，都須要尋找會對行爲產生影響的信息。

　　一、毫無目的的敲擊鍵盤不是測試

　　　　若是隻是收集關於某種特性的信息，並不知道對這些信息作什麼用，那麼就不是測試。

　　二、對公司進行測試（白手套測試）

　　　　去任意一家公司作測試工程師以前，都須要問問這個公司有沒有對測試過程進行定義，有沒有相關文檔。

　　三、開發人員本身測試（狗食測試）

　　　　開發人員在發佈軟件以前，會有不少的方式對本身的產品進行測試。在編寫軟件時，查看是否有語法錯誤，是否是知足功能性需求。在編寫軟件後，應經過使用本身的產品進行測試。

　　四、對測試人員進行測試

　　　　對測試人員是否可以勝任工做進行測試，讓兩我的同時測試一個產品的相同部分，看最終結果。

　　五、無心識狀況下的測試

　　　　生活中，咱們可能對不少東西的使用進行測試。好比，喝一口湯，若是很差喝就不會再喝；固然你也會向，錢已經花了，難喝也要喝掉吧。只要你使用測試的結果，並作出與風險的決定，那麼就是在測試。

　　六、演示不是測試

　　　　演示被設計用於讓系統看起來不錯。測試應該被設計用於讓系統表現出它真實的樣子。

　　七、相關常識

　　1）計算機只會作你要它作的事，而不會管這是否是你真正想作的事。

　　2）能夠構建或者安裝某些工具來得知系統的哪些部分歷來沒有被任何測試接觸過。

　　3）代碼覆蓋測試不能代表全部功能都被測底測試過。要分析測試的相關性和全面性，才能肯定是否已經進行了完全的測試。即，要進行思考。

　　4）要清楚過程文檔和測試過程：過程就是你實際上作的事，而過程文檔則描述了某人但願你作的事，是理想狀況。大多數過程根本沒有任何文檔，不然，咱們會被無窮無盡的文檔壓垮。咱們最好將寶貴的時間用於對過程，也就是對人們實際上作的事進行觀察。利用節約下來的時間決定將少數的那幾個過程用準確的文檔備份下來。