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

10、怎樣讓軟件更容易測試和更容易成功？（第15章）

　　當上一個項目失敗，須要考慮下一個項目應該如何改善。本章介紹幾種讓軟件更容易測試和更容易成功的方法。

　　一、軟件測試變得困難的緣由

　　從根本上來看，軟件測試變得更困難的緣由在於咱們變得更有野心。咱們但願有大型的軟件來完成更有效率更好的事情。

　　1.軟件越大，可能出現故障的地方就越多（故障數目）。

　　2.軟件越大，越難查明故障的緣由（查明花的時間）。

　　3.軟件越大，工廠爲維修而關閉，就會致使生產上更大的損失（損失的機會成本）。

　　二、讓測試更容易和成功的方法

　　2.1 讓系統儘量小

　　　　讓系統儘量小（可是不要太小）。讓需求受控，須要決策者或相關人來區分某件事對於產品是否真的是必需的。

　　2.2 讓「系統」模型是可擴展的

　　　　應該警醒地檢查你開發的簡單系統是如何與更大的、及其複雜的系統糾纏在一塊兒的。

　　2.3 增量構建有清晰接口的分立組件

　　　　例如就像「不要一次作全部事」策略所建議的，能夠採用增量方式進行構建，在完成一個部分的構建、測試和修復工做後再開始下一個部分。

　　　　增量構建是測試先行的思想，即開始構建每一個組件前先創建一組驗收測試。

　　2.4 減小進入產品的缺陷數目

　　　　測試的難度不只和從系統中去掉多少缺陷有關，還和他們什麼時候被去掉有關。通常而言，越早去掉一個缺陷，它形成的損失就越小。因此儘早開始測試，並貫穿整個開發過程。

　　三、相關常識

　　1.測試人員只是信息的提供者。他們並不作出有關交付的決定。

　　2.測試人員是「質量警察」，但他們不是法官、陪審團或立法者。　　

11、關於技術評審的一些建議（第16章）

　　儘早和儘量頻繁的對項目進行技術評審，對產品進行測試，能夠收穫意想不到的好處。

　　一、技術評審的好處和特性

　　1.1 經過投入大量腦力對一個系統進行測試的最簡單方法

　　1.2 技術評審能夠分析和記錄某些技術產品、例如代碼、設計或規格說明的優劣

　　1.3 技術評審也是一種測試，是一種白盒或「開盒」測試

　　1.4 技術評審能夠用於那些不能立刻經過機器來測試的項目內容

　　1.5 經過技術評審和機器測試二者結合能夠發現90%以上的缺陷

　　二、阻止技術評審的緣由

　　經過了解一些人阻止技術評審的緣由，不只能夠了解制造者思惟中的缺陷，還能發現對產品進行測試的方法。

　　2.1 「若是評審那個產品，會花太多時間」：問題多是產品的規模不適當，應該設法將它分解成幾個部分進行評審。

　　2.2 「產品沒法分解成能夠評審的多個部分」：產品是一堆沒法理解的東西，應將產品重建成能夠評審的對象。

　　2.3「除了做者，沒人能理解那些代碼」：這個產品須要被重建成可使用和維護的形式。

　　2.4「這是不證自明的」：是不證自明的，爲何不能花幾分鐘時間進行評審呢？

　　2.5「它過小了，不值得爲它操心。有什麼可能出錯的地方呢？」：若是小，評審能夠很是迅速而方便地告訴你哪裏有可能出錯。有些產品可能修改一行代碼，致使超過十幾億的損失。

　　2.6「如今要評審它已經太晚了」：當收到大堆缺陷時不要吃驚哦。

　　2.7「如今評審還太早」：若是進度計劃上說某些東西已經準備好要評審，但尚未準備好，那麼問題就是已經落後進度要求了。

　　2.8「沒錯，是評審的時候了，不過我還在修復裏面的缺陷」：若是一個產品有不少的缺陷，立刻評審它多是一個好想法，可能幫助某些遇到困難的開發人員。

　　2.9「咱們不能評審它，由於咱們不清楚它應該要解決什麼問題」：爲何要構建呢？可能產品的規格文檔並無被理解清楚，評審建議是「扔掉它，不要浪費錢」。

　　2.10「咱們的問題說明，並無針對咱們正在解決的問題」：繼續工做以前要先得到問題說明。

　　2.11「咱們不清楚正在解決什麼問題，由於咱們一邊前進一邊定義問題」：可能開發者並不理解敏捷開發。

　　2.12「咱們須要花幾周時間來爲評審作準備」：尚未生產出須要測試/評審的可交付產品。真正的開發過程有一條基本原則：你應該一直在生產這些東西，你沒有生產他們，你就沒有實施整個過程。

　　2.13「咱們不但願別人看着咱們作事，由於咱們的人過於敏感」：多是錯誤的人正在處理這個產品，多是對他們的管理不善。

　　2.14「你無法評審它的性能，由於咱們只有構建了它之後才能知道它的性能，而後咱們能夠優化它，因此這不會是個問題」：繼續進行評審並提問，產品表現正常嗎？怎麼優化的？

　　2.15「咱們一準備好就會讓你知道」：評審結束。緣由是產品尚未完成。

　　2.16「咱們這些構建者已經在內部評審過了，因此再次評審時浪費時間」：產品完成的很好，再次評審不會花不少時間，並保證構建者以外的其餘人能夠理解他。

　　2.17「咱們之前評審過相似的東西」：你能夠更爲迅速的評審這個新的。也能夠對兩次評審的結果加以比較，得到額外信息。

　　2.18「你和你那些評審者在這個領域沒有很充分的資格。實際上，惟一有資格的人都在這個項目中」：項目以外的人沒有有資格的評審者，這個產品可能不能維護，且會有嚴重安全問題。

　　2.19「這裏真的沒有什麼新東西；都是可重用的代碼」：這樣，評審會快而美好。只要咱們對每一個可重用部件的狀態及其接口都有記錄良好的證據。

　　2.20「若是你按照指示作，就不能出錯」：這種警告意味着，構建者不知道用戶沒按照指示作會發生什麼事情。

　　2.21「咱們[測試][常識][演示]了它，並且它工做得不錯」：問題在於對「不錯」的定義，比較模糊的廢話。

　　2.22「它工做了」：意味着「沒有讓這個產品失效，並且咱們也沒有讓它運行很長時間或者在差異很大的條件下運行。」

　　2.23「根本沒有任何問題」：對他評審也沒有任何問題。

　　2.24「咱們歷來沒有遇到過困難」：對構建者是好事，對構建者以外的人是否也這麼幸運嗎？

　　2.25「咱們不知道它如此糟糕要進行評審」：不要將評審看成對你認爲可能很差的工做的懲罰。對產品評審應該是標準的、廣泛的過程。它暗示的因該是產品的質量的重要性。因此要求對你的工做進行評審意味着你的工做室重要的。任何找這個接口的人都沒有理解評審所扮演的角色。要不就是你的公司確實是用評審做爲懲罰。

　　2.26「咱們不知道咱們須要評審它」：你不瞭解你的開發過程。修正它的方法是培訓和交流。

　　2.27「咱們的進度稍微有點落後，因此尚未準備好，不過咱們但願能有運氣使進度遇上來」：軟件開發中不能靠運氣。

　　2.28「咱們認爲咱們的工做作得不是很好，並且咱們不想讓管理層知道」：評審每每代表這些產品並不想構建者所但願的那麼好，可是也麼有他們擔憂的那麼差。

　　2.29「咱們不想和那些過程狂合做」：若是評審成爲政治的演練，那些愛管閒事的人但願經過它來表現本身的力量。應該對評審系統進行評審。

　　三、首先對最差的部分進行評審可讓人瞭解缺陷的嚴重性

　　　　最迅速的評審方法是對「最差的」部分先評審。這樣能夠簡單的要求每名評審者從他或她發現的最差的問題開始處理，而後再處理相對次要的問題。例如，程序中使用了有瑕疵的算法，再去關心界面上的拼寫錯誤就沒有意義了。

　　四、如何說服別人進行評審

　　技術評審能夠投入不多時間提供大量重要的早期信息。別人很難相信能夠經過如此簡單的方法得到那麼多的信息。

　　1.可讓構建者經歷一次完整的對各個部分的評審，讓他們瞭解評審結果的產生。

　　2.能夠先開始測試，讓測試結果來講明這些問題本應該經過評審來發現的。

　　3.須要將即時結果評審交給管理層，讓他們決定是否要浪費時間來召集一次正式的評審。

　　五、測試人員也是有價值的評審者

　　測試人員不只能在評審過程當中找到缺陷，還能夠從評審經歷中學到一些東西。

　　1.經過觀察開發人員可能產生的存在瑕疵的思惟模式，測試人員能夠了解如何設定更好的測試。

　　2.經過較早地對規格說明書進行評審，測試人員能夠更早了解到他們測試計劃的範圍。

　　3.經過熟悉設計，測試人員能夠加快檢測缺陷的過程，而後幫助查明他們。

　　4.經過參加評審，測試人員能夠學習如何能對他們本身的測試用例、測試設計、測試驅動程序和工具進行更好的評審。

　　5.測試人員參加評審，與那些單純坐等開發人員交給他們一些東西進行測試的人相比，他們能夠更快地進入項目。

　　六、相關常識

　　1.一個項目沒有包含常常性的技術評審的過程，那麼不管機器測試過程有多好，它都不可能超過正常水平。

　　2.要培養一種氣氛，讓每次評審成爲對全部參與者都有益的經歷。

　　3.不能爲節省時間而省掉評審。錯誤是致使損失項目時間的首要緣由。省掉評審總會讓項目花掉更多的時間。

　　4.只要在設計系統的時候考慮了它的可測試行，那麼在開始運行任何測試以前，就能夠節約至少一半的測試成本。

　　5.評審中須要包含測試人員：a.測試人員能夠提供他們獨特的視角，提升評審的有效性；b.測試人員也須要每次評審提供的教育機會。

　　6.沒有認識到學習的價值：學習是評審中最有價值的部分。　

12、測試中由別人和本身所帶來的欺詐有哪些？（第17章和第18章）

　　當本身想快速清除缺陷和交付產品時，要特別注意別人推薦的測試工具，可能這個工具就是一個欺詐。當咱們但願全部事情都進展順利，可能也是對本身的一種欺騙。

　　一、第三方測試工具引起的欺詐

　　1.1 測試工具欺詐場景

　　咱們在測試中會用到測試工具輔助咱們進行測試，測試工具並非萬能的，當某些軟件提供者給你提供測試工具時，要當心其中的欺騙性。

　　1）當他們在給你演示工具的優越性時，你要知道這並非在測試，只是在證實某個已經設計好的觀點。

　　2）當你要購買的測試工具備不少證書或者證實材料時，也不能保證這個測試工具很好。

　　3）當軟件的訂價很高時，也不能說明這個測試工具的優點。

　　4）當提供商宣稱工具能夠測試不少項目時。不要相信。工具只是工具，他們須要會思考的人進行有意義的操做。

　　1.2 如何避免測試工具引起的欺詐

　　這些欺詐方法老是承諾坐享其成。惟一可以坐享其成的只有後悔。若是某件事好德不像是真的，那它可能就不是真的。

　　二、自我忘卻型欺詐

　　有不少欺詐時咱們無心中忘卻而犯下，當咱們但願讓全部事情都進展順利，可能就會生產一些不真實的數據。

　　1）推遲文檔化

　　　　測試人員不及時對測試缺陷和測試數據進行記錄

　　2）測試報告不明確

　　　　測試人員所提供的測試報告的含義不是很明確，你不知道他提供的測試報告的意思。

　　3）僞造測試報告

　　　　測試人員經過不報告缺陷來幫助開發人員。

　　4）不能區分數量和質量

　　　　進行大量測試和發現大量的缺陷，不意味着進行測試的質量有多好。　

　　5）過度關注報告的形式