記一個質量極差的測試工具——請重視手工測試，自動化測試不是銀彈

新年伊始，又想吐槽一番。

 

背景；我在一個作自動化的持續集成測試的組。

咱們隔壁有一個作測試工具的組。半年前咱們隔壁組作了一個工具，具備代碼分支管理、靜態分析、不一樣級別的單元測試、集成測試等功能，

這個工具被老闆看中，強制讓全部部門使用這個工具來提交代碼。不用這個工具提交的代碼將不能合入產品代碼的主分支。使用這個工具提交的代碼會自動去編譯、打包、進行各層測試。

 

你們使用以後，發現這個工具爛透了。有無數的嚴重BUG。（好比提交上去的代碼不能打包成功，等等。）

我每次提交代碼使用這個工具須要浪費大約8小時時間來解決他的bug致使的問題，才能最終把咱們要提交的代碼提交上去。

 

接着，隔壁組對這個工具的開發陷入了泥潭。

工具質量極差，被用戶（各個其餘須要提交代碼的部門）提了不少BUG。

不得不中止開發新功能，去改BUG。改BUG時又引入新BUG，致使用戶提交了更多的BUG。

 

---

 

 

這個時候，工具組的人和上頭的老闆才意識到這個東西這樣作下去不行。

這工具須要測試。

因而找了個自動化測試架構師，帶了一羣實習生來作自動化測試。

他們把該工具的API拿出來，封裝了一套自動化測試關鍵字。寫了一些自動化測試腳本。

但願創建一套持續集成測試系統來對這個系統作自動化迴歸接口測試。

 

這時咱們組的老闆有意向把這個系統的測試工具接過來 （就由於咱們組是專門作持續集成測試的？），因而來諮詢咱們的意見。

 

---

 

 

我想說，錯了，這個方向徹底錯了。

這個項目註定會在泥潭裏越陷越深。

這個項目中有不少錯誤：

1. 開發之初毫無測試意識。做爲一個測試工具開發組，好歹算半個測試人員，竟然沒有一點測試的意識。不配備任何測試人員地去寫一個影響很大的工具。

2. 沒有單元測試。值得一提的是咱們的全部產品代碼都有或多或少的單元測試。因此沒有單元測試，在咱們這裏確定是一個錯誤。

3. 沒有分析過這個系統的風險和各類外部依賴之間的關係。結果開發出的測試工具依賴多個不穩定的外部系統或服務。致使原本質量就差的工具顯得質量更垃圾了。

4. 當發現須要測試時錯誤地選擇了自動化測試。大家須要的是一個熟悉產品，熟悉需求的，合格的手工測試人員。

    以手工迴歸測試執行的慢爲理由拒絕手工測試。這正是這個組最大的錯誤。

　合格的測試人員，掌握快速測試的思想，使用合適的工具，徹底能夠把任何複雜系統的測試時間降下來。在最短期內發現最嚴重問題。

5. 他們最終也沒有意識到測試人員須要瞭解需求。找了徹底不瞭解需求的實習生來作自動化測試。固然了，這個工具也壓根沒有需求文檔。

這時若是是一個合格的測試人員，咱們會先去學習、瞭解這個系統，而後本身整理出這個系統的需求。以此爲依據來進行測試。

可是，顯然，因爲咱們公司所有都是自動化測試人員，並無一個合格的手工測試人員。

即便我能夠作，我也不肯意去加入這個爛攤子。

6. 自動化測試來不及解決這個系統的質量問題。

諷刺的是，他這個工具自己是一個持續集成測試工具。他們想要咱們來搭一個持續集成測試工具的持續集成測試系統。真是一個笑話。到時候咱們這個持續集成系統搭好了又一堆BUG誰再搭一個來測咱們的系統？

並且這個時間線也拉得太長了，這套自動化API測試即便搭起來也是好久之後了，寫腳本的人又不懂用戶需求，根本不能寫出有實際意義的腳本。也就是說，即便測試全PASS，也不表明系統真的沒問題。

7. 測試人員不是救火隊員。你的系統質量已經爛成一坨了，請不要妄想此時引入一兩個測試人員來背黑鍋。因此這種狀況下，我是絕對不肯意接這個活的。

並且手工測試人員的地位之低真是使人驚訝。

 

能改善這種垃圾系統的質量的測試人員都是真正的高手，他們卻想把這種高人看成打下手的人放進項目組，作夢呢。

 

我就只能不屑地笑笑，而後告訴他們，這個系統病入膏肓沒救了。

 

---

 

最後這一切又印證了我對測試工具/自動胡測試的見解：測試工具和自動化測試腳本自己的質量是最須要保證的。

請把三流開發人員從這個作自動化和作工具的隊伍中踢出去，最起碼也找一些二流的開發來作。另外，請找一個一流的架構，從一開始就減小這個系統的BUG產生可能性。

而不是找三流的架構加三流的開發，做出一堆垃圾再去找測試背鍋。