目前已釋出了兩個報告，大家關注度不是很高，可能最關心的自動化方面的內容沒出現，那今天我們就來分析一下本次調研的重頭戲：自動化測試的現狀。

1. 國內軟體測試團隊居然有一半沒采用探索式測試，雖然早在2006年探索式測試（Exploratory Testing, ET）就相對比較成熟，有明確的思想、方法、操作過程和管理。ET最早出現在1983年，相對明確的概念是1995年。如果不清楚ET，可以參考：探索式測試的歷史（History of Definitions of ET）和 究竟什麼是敏捷測試和探索式測試？ 相對ET，ST（Scripted Testing, 基於指令碼的測試）則相對比較傳統。開發關鍵性軟體產品的團隊，可以採用ST方式為主，ET為輔，目前這部分佔到三分之一，期望結果應該佔到60%以上，與期望結果差距較大

2. 研發團隊過去一年自動化功能測試總體模式呈現“橄欖球模式”，兩頭（UT、UI）小、中間（API）大，也還算良性。API測試排在第一，其次就是UI（使用者介面）測試，單元測試（UT）最低，如果UI和UT的結果互換一下更好。從理想的金字塔模式看，UT應該最高，然後是API、最後是UI。程式碼的自動化測試沒有障礙，而且程式碼每天都在改。介面測試的自動化投入少、效益大，應大力提倡，但一方面要求API穩定，因為它的改動會造成較大的影響。

從調查結果看，前端和後端沒有明顯差別，但從理論上看，後端也是自動化測試的重點區域，可以達到90%以上。

3. 對於自動化投入（或理解為RoI）模式，有近一半人不瞭解，這樣很正常，工程師們關注技術，叫幹活就幹活，可能不關注投入產出，而關注RoI的，多數是管理者。但進入軟體研發這一行，也需要了解，更應該關注自己做的工作是否值得有較大的投入。除了上面第2項已經介紹的金字塔、橄欖球兩種模式，冰淇淋模式是和金字塔模式相反，是要擯棄的，佔得比重和橄欖球模式接近。紙杯蛋糕模式，UI偏多，雖然可以理解，但也是不鼓勵。調查結果明顯偏高，紙杯蛋糕模式高出橄欖球模式不少，和金字塔模式接近。

4. 功能自動化測試實施不理想

下面是國際調查的結果

5. 過去一年軟體專案，對單元測試程式碼行覆蓋率沒有要求的，接近60%，單元測試非常不理想。要求達到行全覆蓋的不到5%，大於80%算合理的要求，也只有13%。

6.  API自動化測試工具主要採用JMeter，其次就是自己開發的工具，Postman和SoupUI也有較高的使用率。

7.  Web功能自動化測試工具主要採用Selenium+WebDriver，超過一半，其次也是自己開發的工具，多數web測試工具沒什麼市場。“其它”佔了三分之一，需要進一步調查，或大家留言推薦。

8. 移動應用自動化測試工具主要採用Appium，接近一半（44%），“其它”佔的比重較大，高於40%，需要進一步調查，或大家留言推薦。官方的Espresso應用很低，Calabash更低，但還是希望大家多關注這兩個工具。

9.  效能測試工具相對集中，開源的屬JMeter，商業工具屬LoadRunner，幾乎沒有對手，“其它”佔的比重相對不高（18.4%）。對於特殊的應用，就需要自己開發（21%）。Gatling用於web測試挺好，只是熟悉scala指令碼語言的工程師不多，但掌握Scala不難。

10.  安全性測試工具太多，分佈比較廣，“其它”佔的比重很高（66%），其中也包括許多人不用安全性測試工具，做安全性測試的人數，比效能測試要低不少，不清楚選哪一個。為了搞清楚安全性測試工具情況，搞了一個新調查（https://zh.surveymonkey.com/r/TT8S3N2），由於是國外網站，速度非常慢，看來還要移到國內網站在進行調查，到時需要大家支援。

11. 測試管理與缺陷管理工具相對集中到——JIRA和禪道，自己開發和“其它”佔的比重接近，大約23%。

12. 自己團隊未來1-2年會加強的測試工作主要集中在“自動化測試”和“開發技術”的提升上。自動化測試的確不能讓人滿意，差不多有一半團隊作為2018年的工作重點，希望明年調查時，自動化測試有所改善。

大家看了這個報告，有什麼感受？歡迎留言討論！

第四份報告，我們就這12項內容，再次進行傳統IT公司和新型網際網路公司進行比較分析，看看究竟它們有何差異。

參考：