軟件測試的這些事你知道嗎？

1、前言

---

1. 做爲開發人員，咱們都知道咱們應該測試咱們的代碼。咱們應該寫單元測試，但這也一般是咱們發現沒時間時跳過的第一步。
2. 做爲團隊的領導者或者管理者咱們都知道測試是必要的，可是當截止日期臨近的時候，咱們傾向於減小測試，而把更多的重點放到編碼上。這樣看測試領域彷佛很緊張。咱們都知道測試對咱們是有利的，可是一旦項目面臨壓力時咱們就再也不測試了。

2、咱們爲何測試?

---

• Edsger W Dijkstra說過:測試能夠用來找到顯式的缺陷（bug），可是沒法顯示潛伏的軟件缺陷（bug）。這意味着測試不能百分百保證你的軟件沒有缺陷（bug），可是它確實頗有幫助。

• 咱們也能夠換種說法，若是咱們不進行測試咱們幾乎能夠百分百保證咱們的軟件會有缺陷（bug），除非咱們是在編寫像「hello world！」那樣簡單的程序。可是即便這麼簡單的程序你也會測試，由於一旦你輸入完你的代碼你就會很好奇它的輸出是否是真的是「hello world！」。

• 而這就是第一類形式的測試，也是咱們一直在作的: 手工測試. 咱們編寫程序，而後啓動它去檢驗運行結果。 對於一個簡單的「hello world」這多是足夠的，可是對於複雜度更高的程序這可能會致使時間的浪費，這是對一個已知的行爲結果集的手工重複。這難道不是咱們發明計算機的初衷嗎?

• 對於「hello world」這不是大問題，可是當你建立一個 web應用時，測試場景是在翻頁十次，點擊某些按鈕，在大量表單中輸入（正確的）數據以後再測試某些特定條件，你就看到自動化會節省大量的時間。若是你能經過測試運行器（testrunner）直接執行你想要測試的函數，而不是必須花費半分鐘手工執行到那個函數，你會節省不少時間！但這也意味着咱們須要多一點點編程，而更多的編程意味着更多的時間和精力。因此它會花費更多的時間而你的項目可能所以完工的晚些。

3、也許未必

---

讓咱們建立一個控制檯應用程序來計算最大公約數(GCD)的兩個整數。有不少方法能夠解決這個問題，但爲簡單起見，咱們將

1.輸入兩個整數

2.無論其算法怎麼樣，計算一下 GCD

3.顯示輸出讓咱們瀏覽一下正常的開發週期。

咱們一般寫一個 main() 函數，獲得了兩個整數，以及調用一個函數來計算一下 GCD，而後顯示結果。測試。在你的控制檯中輸入 2 個整數會花一些時間，這將變得至關無聊，若是你須要屢次重複你的代碼。這也很容易在控制檯應用程序中輸入出錯，致使程序崩潰。這意味着你必須從新啓動程序，輸入兩位數，而後再次驗證結果。請你要記住，咱們討論的是一個控制檯應用程序，只須要兩個輸入值，不須要點擊(在 web 應用程序中)，咱們已經看到，這將須要花費一些時間。

而後，咱們極可能會想要測試一些更多意味着重啓程序的值，進入兩位數（正確地），而後測試。。。因此咱們即便看到也不會當即這樣作，由於它要花費太多的時間。Edge 案例將會被遺忘，錯誤只會在生產中被發現！此外，當咱們改變一些咱們須要再次運行全部的測試(手動)，使用一個被遺忘的，或者使用快捷鍵的高風險的測試。在那兒，不會有跟蹤咱們的測試工做。不寫入日誌文件，在整個測試期間，除非你增長這個你作的事情列表工做(手動)。

4、消極反饋循環

---

一般，當項目（由於某種緣由）延期了，則容易陷入一種消極反饋循環。有時咱們會先決定跳過編寫測試代碼，而這則會形成狀況以下圖所示：

項目延期，形成咱們不得不去編寫更多的代碼。因此與其「浪費時間」去不停地測試代碼，不如不停地去開發項目。而這樣作的結果就是代碼質量進一步降低，並最終（或早或晚）致使返工。返工又一般會在最有限的時間裏變得十分緊急（有些人叫這種現象爲「墨菲是個樂天派！」）。其實返工什麼也改變不了，項目如今只會進一步被延遲。很奇怪吧，咱們編寫越多的代碼，咱們的項目完工越晚。一種經常使用應對措施是讓更多的開發人員被參與到項目的研發中，然而這樣的做用也只是加重消極反饋循環而已。

若項目缺少測試，在驗收和生產環境時，一般用戶則會發現許多 bug，這將會快速地下降用戶對項目的信任度，從而產生消極反饋。這種反饋傳遞給（工做過分的）開發人員，就形成開發人員「疲勞」現象。後果就是開發人員工做積極性降低，開發人員離職，……，項目又進一步延遲了。

5、打破消極循環

---

我想你已經想到有一個辦法能夠解決這種現象。讓咱們來繪製一幅不一樣的場景：咱們能夠從一個理想計劃「項目按時完工」開始。咱們開發代碼，而後當即測試它。測試最好是自動化（編碼實現）的，這樣咱們能夠輕鬆有效的去執行它們。咱們把開發和測試緊密的結合在一塊兒，每一個開發測試循環能夠很快速的執行。當一個開發測試循環結束時咱們有信心保證代碼質量是很高的，由於它已經經過了測試。並且用戶由於發現缺陷（bug）的數目變少而對咱們繼續高度信任。即便他們發現了一個缺陷（這依然是有可能的），咱們也能夠擴充咱們的測試集合，去避免相關缺陷的重現。如此下去，返工將再也不是必須的，項目得有繼續。若是咱們的項目已經延期了，就須要咱們花些時間來採用這種方法論。對新功能的凍結也許是必須的。中止開發新的代碼，取而代之去爲最嚴重的（惱人的－清晰的－高代價的）缺陷編寫測試。

項目延期的狀況下再去爲你完整的代碼庫編寫測試是不可行的，只針對其中的一些部分就能夠，不要去浪費你的時間。可是要記住其它部分也仍是須要編寫測試的。我在這種狀況下會去找出最嚴重的問題（劃分優先級），而後爲它們編寫測試。以後「快速」修改代碼就會變的更容易，而且能夠保證在修改其餘部分是它不會出錯。自動化測試能夠很頻繁的執行，從而下降了缺陷（bug）重現的風險。大講臺，最實用的 IT 職業在線學習平臺。好了，如今能夠開始去有效的強健咱們項目了

上面這些一般會要求進行代碼重構，從而使它可測試化。

6、總結

---

大部分的項目中，會考慮測試和編碼之間的平衡。不過我但願你們都能清楚，測試實際上是項目的加速器，而不是在浪費時間。我這裏也有不少軟件測試方面的學習資料提供，須要的話能夠加我QQ：1363134450（記得備註噢！）