根據我的觀察，優秀的測試人員可以做的事情可以包括如下3點：

由單純的測試變成項目質量保證工作
持續集成探索和推動和自動化測試技術研究
測試相關工具的開發
1、我們先來講第一點，由單純的測試變成項目質量保證工作

測試，從狹義的角度來講，包括如下這些環節：
測試計劃和測試用例編寫－測試執行－質量報告書寫
測試人員一般會在開發階段就進行測試計劃和測試用例的編寫和準備工作；在測試階段，我們一般先會做功能測試，等項目功能基本穩定，bug較少了，就開始做兼容性測試、性能測試、安全性測試。兼容性測試保證了產品在多瀏覽器、APP在產品在不同機型下的兼容性；性能測試保證了產品在海量用戶大流量下的服務能力；安全測試能發現產品可能會被攻擊的各個隱患。做完了這些測試以後，人員發布質量報告，產品上線。

不過，優秀的測試人員需要向上遊和下遊拓展測試的領域，把自己放在“質量保障”的角色上，推動整個項目組一起保證質量，上遊的工作包括：

在產品剛立項、進行需求確認的時候，測試人員就會參與進去，仔細地Review需求，看需求是不是完整、有沒有漏洞，這個時候還沒有進入正式開發，修改需求對於項目組來說代價是最少的。在這個環節，測試人員憑借縝密的推演、發散性的思維，往往能發現很多需求的漏洞，提高了項目的整體效率。
另外，測試人員在完成測試計劃、測試用例以後，會邀請開發、策劃一起來評審測試用例，在這個環節，由於測試人員把每個需求如何細化測試都體現在了用例裏面，就相當於再次把需求分析了個透，往往還能發現很多需求的漏洞。這也是提早發現需求漏洞的有效環節。
我們知道，代碼的質量歸根結底是由開發保證的，測試做的工作，只是發現Bug讓開發修復。如果一個花瓶，一開始就是很完美的；另一花瓶經過了各種修補，看起來比較完美，大家覺得哪個花瓶比較好？當然是第一個花瓶。所以，測試人員應該站在質量保障的立場，想辦法跟項目組溝通、給開發提供工具，讓開發自己把質量保障工作做好。比較可行的一些方式是：提供一些手工用例讓開發自測；給一些自動化的接口和UI測試代碼讓開發自測；部署靜態代碼檢查工具，並推動開發分析和修改發現的問題；有一些做得好的項目已經實現了持續集成，也可以嘗試。
下遊的工作包括：

在產品完成了測試以後，就是發布的環節了，測試人員在發布的環節也能發揮作用，首先，測試人員為了部署測試環境，研究自動化部署的技術，可以把上線部署的環節也自動化，以前需要2個小時的部署環節壓縮到半個小時甚至更少，而且更加準確可靠。
如果有些版本修改比較多，上線的質量風險大，測試人員會跟產品一起制定灰度發布的方案並在技術上進行實現，讓版本先面向一小部分用戶開放，如果發現Bug了，影響的用戶也比較小，Bug改掉以後，再逐漸擴大用戶範圍。
另外，優秀的測試人員還會發動項目組的其他人一起來保證項目質量，比如推動開發進行代碼Review；引入冒煙自測流程，讓開發先自測以後再提交給測試做冒煙測試；通過在項目組分析Bug，讓開發提高自測，降低Bug數量等；引入策劃、交互、視覺在測試階段進行走查，等等各種措施。

2、持續集成探索和自動化測試技術研究

業界都在說持續集成，那持續集成究竟是個什麽鬼呢？

持續集成原本的意思是讓開發每提交一次代碼就自動化測試一次，如果自動化測試發現問題了，測試用例就會失敗，開發就會馬上發現這個失敗，並修改代碼。

要做到持續集成可有很多工作要做。

首先就是編譯環節，要把所有編譯的環節都自動化起來，開發每次提交代碼都能進行自動編譯；
編譯完成後，就是靜態代碼檢查的環節，通過靜態代碼檢查的工具檢查代碼的問題，比如，數據庫連接池沒有釋放，參數不匹配等。
靜態代碼檢查完成後，就是單元測試了，單元測試用例一般是開發人員或者測試人員編寫，或者開發和測試合作編寫，保證的是開發內部函數的正確性。一個健康的自動化測試方案中，單元測試用例的占比是最高的。
然後就是接口測試，一般保證的是後端開發提供給前端開發的HTTP接口，接口一般也比較穩定，用例比較容易維護，所以，接口測試的自動化占比也可以做到很高。
在接口測試的上層就是針對用戶界面的UI測試了，就像測試人員手工執行一樣，UI自動化測試能操作頁面的元素，完成自動化。不過，由於用戶界面常常要重構，所以我們常常會控制UI自動化測試的規模，只覆蓋主幹的用例。
優秀的測試人員可以把自己的工作盡量自動化，並用持續集成框架串起來，提高工作效率和質量。

3、測試相關工具的開發
優秀的測試人員會開發其他好用、趁手的工具來提高工作效率，比如數據自動生成、報表自動生成、報bug工具等。

其實歸根結底就是一句話：測試人員最核心的工作就是保障項目的質量，各類測試流程、技術、工具和平臺的發展讓我們可以更好地保證項目的質量。

原文地址：http://www.51test.space/archives/2157

成為一個優秀的測試工程師需要具備哪些知識和經驗？