軟體測試人員怎麼提高效率？

01-08

做了3年測試，從剛畢業只會看著用例測試，到現在做計劃做方案，從開發文檔中找BUG，從設計邏輯中找BUG，還要設計各種可能的場景測試案例，就怕漏測了出生產問題，也就找BUG定位問題的效率提高了，該做的事情並不會減少，效率也不會高到一個人頂3、4個的地步，感覺有點累了。
經常聽到有人說一個好的開發可以頂10個甚至更多，可以很快的把工作做完，從來沒見過有測試工程師這麼說。。。難道想做到一個頂10個只能轉開發了嗎

對於測試來說就是質量和進度的事情，如果可以更進一步的話就是需求的事情。

質量：你發現了別人發現不了的嚴重問題。保證客戶那裡沒有問題（需要你善於表現，不過你一直都這樣的話相信別人總會看到，我們團隊以前就有這樣的人，只要覺得有風險的模塊給他負責總是很放心），這樣不只抵10個吧

進度：自動化很牛逼的，就不用說了

產品：能夠直接知道產品經理一個功能毫無價值，或者偏離了方向。最後讓這個功能產生更大的價值。這樣也不只抵10個吧！

不要局限於自己當時的崗位，否則你就一直在該崗位呆著，盡量朝著自己感興趣的方向去擴展自己的工作。

筆者在自己的公眾號（軟體測試人生）分享過一篇文章，叫忘記你是一個測試人員吧！有興趣的可以看看（找到後查看歷史文章）。

去年選車的時候，看著滿街的奧迪寶馬，我在想為啥我就只能選福克斯呢（還是經典款），我想要的生活，最次最次的也是奧迪A4L。我日思夜想，結論仍然是工資太低了，於是，作為一個底層的測試工程師，我列了一個技術矩陣，包括：性能、安全、功能自動化三個維度，並給這些技能劃分出4個層次（比方說性能測試，入門你得懂些理論、起碼得能夠分析用戶真實的性能需求、多少有點自己的看法、能夠寫腳本、熟練幾個測試工具，初級你能夠了解一些主流的通訊協議、簡單的瓶頸定位。。這不是重點），大約估算了一下，大概所有維度都達到第三層時，所對應過去的崗位月薪，我也能開上A4L，事實上，小公司對於一個全方位發展的測試工程師還是比較捨得花錢的。

但是，問題就出在這裡。

如果我每一個方向都有所努力，在一定的時間以後當然能夠達到目標層次，但是過多的時間投入意味著實踐經驗會有所減少，而實踐經驗有所增加實際上會增加到達目標層次的時間，這是矛盾發展的，更何況還有三個維度。

解決方案就是，不要投入過多的時間去學習、但是也不要投入過多的時間去實踐，而是把過去已掌握的解決問題的能力向他人傳遞，由他人替你去學習實踐，說白了，就是帶團隊。如果樓主認為自己在功能測試方面做計劃、方案、甚至需求文檔的BUG都能找到（我確實沒有遇到過需求文檔能找到BUG的情況，畢竟需求那麼模稜兩可），為何不考慮通過 帶團隊 提高效率完成自我實現？

多分析，多思考
多溝通，弄清楚
積累工具，善用工具
抓重點，抓主要矛盾
不斷學習

測試效率一直都是軟體測試領域的熱門話題，我們覺得從以下幾點入手是解決這個問題的根本，雖然不一定及時有效：

1.解惑意識

在軟體測試的過程中最重要的還是要找出Bug，那麼發現一個Bug就是不斷提問的過程，作為一個高級的軟體測試工程師要學會識別問題並確認問題，更是要找出代碼中的問題。

2.全局意識

除了保證質量意外軟體測試這門工作更是要有全局意識，因為有的在局部看來很嚴重的問題放到全局是不值一提的，所以在發現Bug的過程中需要以大局為重。如果沒有良好的全局意識，那麼就可能遺漏某項重要的問題。

3.風險意識

風險意識就是我們平時掛在嘴邊的「預見性」，這就要求我們需要隨時識別風險、分析風險、解決風險。

4.收益意識和成本意識

這個項目的測試人員是只有1個人還是有10個人？我們需要把溝通成本也算在裡面，有時候自動化並不是節約資源的測試方法，反倒會浪費資源。

5.協作意識和分享意識

在產品研發的過程中每一個環節都是環環相扣的，需求是構建，開發是實施，測試是檢測，而我們軟體測試人員需要和每一個環節溝通，所以這個時候協作就體現的尤為重要。並且要想擴大自己的思維深度最有效的途徑就是不斷的去獲取別人的想法，分享就是去獲取別人想法最有效的方法。

自動測試工程師敢這麼說。

影響測試效率的因素很多，比如

用例設計的效率。比如需求不穩定、不清晰、或者業務邏輯本身就比較複雜等。
用例評審的效率。其他人員不熟悉業務，導致評審效率和質量很低，溝通成本很高。
用例執行的效率。比如測試計劃制定的不合理，對測試覆蓋的不合理偏執追求。缺少必要的自動化測試。
缺陷更改周期長，修復率低。
測試環境更新複雜
.....

所以，一句話「提高測試效率」，有點兒空泛，題主可以提供更詳細的信息來加以討論。

對測試人員來說，高水平和低水平的主要差距不在量，而在質。

3個人的工作量你1個人相同時間就能完成，這當然算牛，但不應該是測試人員能力的主要衡量標準。

3個人做同一功能的測試，你能發現他們發現不了的問題，你能發現更嚴重的問題、更重要的問題。這才是你測試能力的主要衡量標準。

這需要對業務的深入了解、對功能實現方法細節的了解、嚴密的邏輯思維能力、正確的方法論。

所以題主不必太糾結自己的效率相比別人效率優勢不大的問題。

效率問題，用方法論、抽象能力和機器來解決。

另外一個，在工程里，提效率也必須想到成本，你如果設計能力非常強，輸出的用例質量很高，執行不過來也不要緊，僱傭一批低成本的測試執行者就好了。讓一個非常優秀的測試工程師去做一些常規的手工測試執行，肯定不是效率最大化的。

一個高水平的測試工程師，需要對質量管理有所了解，需要了解當前產品的整體質量，並分析出質量底下的根本原因，針對這些原因有應對的辦法。

好的質量不是測試測出來的，是需要每個環節的質量管理來提升的。

比如需求輸出的質量（需求評審、有效降低有關需求的溝通成本）

比如開發質量（單元測試、Mock測試、靜態代碼分析等）

比如持續集成的質量（日構建、代碼合規性檢查、自動部署）

測試環節的就不說了。

一句話，在質量上，需要有大局觀。需要對非測試環節有影響力，倒序推進研發流程的改進

1 精通你所測試的對象，其中包括該對象產品設計、呈現邏輯，甚至是底層實現，舉個例子，一個PHP網站系統的登錄和註冊，你知道登錄的整個流程嗎？你知道一個用戶在登錄時跟哪些系統有過數據關聯嗎？你知道用戶登錄時做了哪些判斷和校驗嗎？等等…如果你了解這個產品，清楚整個代碼架構的設計和實現，那麼你設計出來的測試用例在準度和效率上要遠遠超出你只知道這個登錄的頁面流程和交互

2 提高編碼能力，意味著你有能力把測試對象中可以自動化的部分通過編寫軟體或者腳本的形式，把你自己從繁瑣的手工測試中剝離出來，效率自然也就更高了

3 提高對日誌的認知，多看日誌，這是了解系統很好的一條途徑

手機碼字，暫時就想到這麼多，共勉！

怎麼不說一個坑爹的開發帶來三四個測試人員的工作量

只從自己找方法是效果不好的，你應該站在整個團隊思考問題。

會出現這種情況，說明測試工作都盡在測試工程師去完成，可以嘗試去反推研發做測試，方法是先和研發一起理順思路，達成一致認為研發做測試工作效率會更高，測試更多的做一個項目質量管理者，質量風險把控者，質量意識培訓者。這才能解放測試來做更多想做的專項、性能的事情，而不是不停的攬些重複無創造性的事情。

活生生的例子：我，一個測試對9個開發，大家也認可這種工作方式。

自動化與手工並行執行。可以用腳本或工具實現的回歸絕不用人力去實現。