软件测试工程师职能
文章目錄
- 前言
- 一、軟件測試工程師職責
- 二、思考如何才能保證項目質量
- 三、項目質量保證落地之測試左移
- 四、項目質量保證落地之測試右移
- 五、測試效能提升
- 六、結語
前言
以下文章提取于微信公眾號：測試小哥進階
做測試也有幾年時間了，也負責過很多大大小小的項目測試工作。以前一直覺得IT行業工作是份高大上的工作，但接觸后才發現這份工作并不那么高大上，還有點苦逼。
我們接觸到的每一款產品背后都有著一個或多個團隊的心血。每個成功的產品背后都有著一個成功的產品團隊，在團隊中，測試作為產品最后的一道門檻，測試的好壞取決了一個產品的用戶體驗度及舒適度。那么，作為測試的軟件測試工程師，我們該怎么保證一個產品的質量呢？我們今天來聊一聊這個。
一、軟件測試工程師職責
作為軟件測試工程師，對比軟件開發工程師，我們可以體現的工程在哪里呢？作為測試，難道真的只是單純的找找BUG嗎？如果是剛剛接觸測試這個行業，我肯定是這樣認為的，但是，這個只是其中的一小部分而已。
回到上個問題對比軟件開發工程師，我們可以體現的工程在哪里，對于這個問題，個人總結可以概述成二個要點：一是項目質量保證，二是測試效能提升。結合這二點去展開測試工作其實就是要求軟件測試工程師能夠把一個業務或者整塊業務的質量保證體系建立起來，這也是作為一個軟件測試工程師的職責。但是，在這里需要提一句，項目的質量保證不只是單單軟件測試的事，而是整個團隊的事。
那么，怎么才能做好這二方面呢？
二、思考如何才能保證項目質量
怎么保證一個項目的測試質量，這個問題貫穿了軟件測試的整個周期。
我們一般的測試流程都是：首先項目需求或者迭代需求都會對接到產品那邊，由產品設計具體的方案在需求評審。測試這邊呢參與需求評審，然后根據需求設計出對應的測試方案、測試腳本及排期，當然了，測試方案、測試腳本這些也是也進行評審的。然后等開發完畢提測后開始冒煙測試、探索性測試、提BUG、確認測試、回歸測試等測試，當測試通過后測試周期就算結束了。之后投入下一個項目或迭代繼續重復這樣的流程。
這樣的流程看起來有問題嗎？看起來是沒問題的。只不過測試會很被動。從這個流程我們可以看到有三個節點，一是產品、二是開發、三是測試。當產品需求質量差，開發質量差的時候測試只能被動接受，而被動接受的結果是測試會進行漫長痛苦的測試過程及因為質量差導致上線延期，甚至有可能一個問題在生產裸奔幾個月最后在涉及到相關業務的時候現場才發現，最后被現場的人質疑為什么這么簡單的問題都不能發現，你們測試的價值在哪里 ？其實這問題在大部分小公司及中型公司都是很容易見到的。
其實，這里最關鍵的節點還是產品。產品設計的需求是否與客戶一致取決了后面一系列流程的質量。舉一個常見的場景：當產品的需求管控能力、業務能力、設計能力、語言書寫等產品能力有限制時設計出來的需求可能是不完善的甚至是與目前系統功能重復的。這部分需求過了需求評審且開發已經開發完，測試用例也已經評審且在測試了，后面發現需求有問題或者不滿足條件需要在原有的基礎上不斷新增新的字段、規則、邏輯等。累加的越多，開發的效率、質量及測試的效率、質量都會逐步下降，這就造成了項目或者迭代的延期。好的一個產品，背后都有一個優秀的產品經理。
看到我上面的這個例子，可以看出不管是產品的需求質量還是開發的代碼質量測試都只能被動接受。那么，我們怎么把這種被動劃為主動呢？
目前比較好的一個模式是：測試左移及測試右移。下面我們來說說測試左移及右移。
三、項目質量保證落地之測試左移
我們先來看看什么是測試左移，測試左移就是在提測之前已經介入了測試。流程與上面基本一致，不一致的是在需求評審時不只是了解需求，更是要去評估需求的質量，分析需求的合理性以及完整性。在開發階段時參與設計方案的設計，了解開發的實現方式。因為很多開發可能只對他負責的那一塊熟悉，作為測試需要評估改動范圍以及是否有遺漏的模塊和系統。當然了，測試還可以通過提供測試用例或者自動化測試腳本的方式給開發，讓開發在設計時考慮地更全面，同時方便開發在提測前進行自測，有助于提高產品質量，畢竟越早發現問題，解決的成本就越低。測試人員還需要不斷地培養產品、開發人員的質量意識，同時提供必要的技術支持，協助產品、開發更好的進行測試，比如公共用例、測試工具、測試腳本等。
我們可以看到，在這種流程下，測試由被動化為了主動。這里有個常說的TDD概念，就是測試驅動開發。這樣，我們會發現提測的質量及效率都提高了，原本提測后還需要花一天的時間進行冒煙測試，現在可以有時間進行更多的探索性測試。
當測試完成后，測試活動就結束了嗎？肯定是不行的。為了檢驗測試團隊的質量保證體系質量，我們還需要進行測試右移。
四、項目質量保證落地之測試右移
那么，什么是測試右移呢？
測試右移是上線后測試人員還需要關注線上情況，不是功能上線測試人員的測試活動就結束了。通過線上監控和預警，及時發現問題并跟進解決，將影響范圍降到最低。在有些時候，其實應該在開發設計時就要考慮預警功能，系統層（如CPU、內存問題）、應用層（如響應時間）、業務層（如WMS的出庫、入庫等，金融系統的注冊率、交易量等）等出現異常的時候通過郵件等方式發出預警，相關人員才能知道哪里出了問題。技術人員要比業務人員先發現問題，如果業務人員已經發現業務量明顯下降，說明問題已經很嚴重了。
在測試右移的過程中，測試人員相當于推動劑和添加劑。可以推動開發需要補充監控預警功能，同時可以提供監控指標。除此之外，測試人員更需要關注線上業務及用戶使用情況，更多地關注用戶價值高、使用率高的功能，在用例中補充遺漏的場景，盡量多地覆蓋這些功能。甚至這里可以引入測試人員的績效管理，可以根據BUG量及BUG的一個嚴重等級引入KPI考核。
結合上面所述，我相信，就算不能完全解決產品的質量問題，但是也可以使產品的質量提升一個或者幾個等級。不管是測試左移還是測試右移，都是為產品質量服務。
那么，當項目的質量得到保證后怎么提升測試效率呢？接下來我們來說說測試效能提升。
五、測試效能提升
舉些例子：當開發自測需要造數據、開發自測完后測試冒煙測試不通過、新增功能后回歸老流程等。我們可以想想，如果我們手工的去處理這些東西耗費的時間有多少，是否可以把這部分時間花在更有價值的地方上？
那么，如何做到測試效能提升呢？我們可以分二方面來提高測試效能，一是測試能力，二是測試流程。
首先說說測試能力，我們可以合理引入自動化，以上述例子，我們可以把自動化用于在開發自測打包后的冒煙及回歸等可以利用自動化的場景下持續測試，利用Jenkins等持續集成工具進行持續測試。或者可以在原有的DevOps流程上銜接測試流程。在項目質量保證的大前提下，任何可以提升測試效率的工具都是好工具。除此之外，在測試過程中還要多寫、多累積一些通用的快捷腳本，比如當需要大批量回傳接口或者造大批量數據時，像這種情況跑腳本是不是比自己手動弄快的多。其實這些都是將自己轉換成測試能力的過程。
除了測試能力外，我們還可以關注當前的測試流程有哪些是可以不用的，如果在原有基礎上加其它東西的話會不會有什么新變化，這變化帶來的好處和壞處是什么。這些都是身為一個專業的測試人員去考慮的。
六、結語
在項目質量保證的大前提下，高效的完成測試工作及保證對應的質量。而怎么讓這個目標落地或優化，這才是軟件測試的工程。
那么，本篇文章內容就到這，各位覺得不錯的可以三連分享哦！886~
總結
- 上一篇： SwiftUI 文字转语音TTS 开发朗
- 下一篇： 美联航要买多达200架波音787，签下美