前期假期結束，大家都度過了疫情以來難得的休閑假期，但因大風天氣頻發，部分高鐵線路出現線路懸挂異物，導緻部分火車晚點運作，進而引起北京西站出現了大量旅客滞留的情況，引發了大家的關注。對于火車晚點，大家都能了解，但對于北京西站的處理方式和應急做法，群眾就不見得了解了，大風刮飛地膜的事件不容易出，但相應的應急措施也需要預先想好。通過這個事件，聯想起我們軟體測試行業，哪些過程和活動是咱們需要提前想好應急措施的呢。
那麼就跟着我來一起梳理梳理，那些可以提前想到的“地膜”事件，以及我們能夠想到的應急措施，防止出現軟體測試領域的“旅客滞留”現象。
拿一個傳統的瀑布模型的資訊系統來說，軟體系統的生命周期分為需求分析、概要設計、詳細設計、編碼、測試及運作維護階段。軟體的測試工作是否隻在測試階段呢，并不是。現在都提倡軟體測試的提早介入，那為什麼要提早介入，多早算早呢，筆者認為從需求分析開始就可以介入了。下面就從軟體生命周期各個階段開始梳理。
（一）需求分析階段
這個階段的主要工作是确定軟體的功能性需求和非功能性需求，包括系統的功能、性能、安全、資料和界面展現要求，該階段形成軟體需求規格說明書。測試人員在本階段可以針對需求文檔來進行文檔檢查。一是需求可讀性，了解業務人員想要實作一個什麼功能，這個功能是否合理，現有系統是否有類似功能；二是需求完整性，檢查需求中是否較長的描述業務規則，業務之間是否有閉環流程，有沒有遺留在流程外的功能；三是需求詳盡程度，檢查系統的非功能需求是否有詳盡描述，是否包含了諸如性能要求、安全需求等非功能需求。這些需求不妨礙系統的功能實作，但功能的好壞直接影響系統的易用性、安全性等。通過對需求文檔的完整審視，我們可以大概了解該系統的目标使用者和客戶需求，系統的解決方案及業務價值。而我們在需求階段将這些潛在問題梳理清楚，能夠最大限度地減少項目返工的成本，大幅提高項目的成功率。
那麼這個階段潛在的“地膜”有哪些？又該如何應對呢？我們将其進行了如下梳理，形成《表1：需求階段的風險事件分析及應對措施》。
表1：需求階段的風險事件分析及應對措施
（二）概要設計、詳細設計階段
這個階段，開發人員要把需求分析階段确定的功能需求轉換成需要的軟體體系結構，體系結構中每個子產品對應一些功能需求，明确軟體由哪些子產品組成，子產品的層次接口和調用關系。還要确定系統的資料結構和資料庫結構，該階段形成概要設計說明書。詳細設計階段任務是将概要設計階段的每個子產品完成的功能進行具體描述，表示為精确的結構化的過程描述，對子產品的控制結構，先做什麼，後做什麼，條件判定，重複處理等進行表示和描述，形成詳細設計說明書。
在這個階段，測試人員一般開始進行測試計劃和方案的編寫，在方案編寫階段，我們需要對需求進行整體考慮，同時考慮測試時的一些特殊情況，梳理關聯系統，檢視必要的關注點是否已覆寫到，有以下幾點需要特别注意，我們挑選部分事件進行重點闡述，詳見《表2：設計階段的風險事件及應對措施》。
表2：設計階段的風險事件及應對措施
（三）編碼階段
該階段就是需求具體實作的過程了，在這個過程中，開發人員需要按照編碼規範對程式代碼進行檢查，我們測試人員在這個階段，就可以使用一些工具對程式進行另一種檢查了，比如我們可以利用jacoco工具，來檢視程式的覆寫度情況，通過自研的接口校驗工具，檢查接口對反向案例有沒有很好的校驗。我們還可以使用自動化工具，對界面進行自動化案例的設計。在這個階段，需要開發人員配合完成代碼插樁，實作代碼覆寫率的檢測；配合完成封包格式的編寫以及封包的擷取，并實作自研接口工具的反向檢測；配合完成界面要素的定制，實作自動化腳本的快速生成。總之，編碼階段，開發人員需要提前排雷，盡量避免将問題遺留到測試階段。
（四）測試階段
進入測試階段，即進入了測試人員的主戰場，在這個階段，我們需要關注的項就太多了，功能測試，性能測試，接口測試，自動化測試，安全測試（技術安全、業務安全），外聯第三方測試，相容性測試等等。測試人員需要關注的需求包括功能需求和非功能需求，還要再次關注關聯系統測試需求。針對每個類别的測試，測試人員前期已進行了梳理，形成了測試關注要點，對于這些可能的“地膜”，測試人員根據經驗已經一一列出，後續也會不斷更新。這裡重點選取一些流程管理方面可能會出現的“地膜”事件，如未按照流程進行操作，輕則是考核失分，重則是形成合規風險事件。
1、評審流程：
工作量評審→方案評審→案例評審→準入。
2、測試資料申請流程：
按照資料的脫敏程度，分級申請。比如全部脫敏資料，隻要組長級别的審批通過即可，部分脫敏的要上升一個層級，未脫敏的資料需要上升到老總級别審批，同時需要向相關安全部門報備，用完後及時清理。
以上測試資料，均需要在項目結項後一個月内清理。
3、環境申請及登記流程：
有常備測試環境的一定要在項目開展過程中使用常備環境，并進行登記。
無常備測試環境的需要在相關系統中提先進行申請。
同時還要確定測試環境中無敏感資訊留存。
4、案例設計：
需要充分考慮反向案例的情況，同時實作自動化測試的案例，還需要在案例中增加自動化的案例編号。
5、測試過程管理相關：
①在測試過程管理系統中建立完整的測試套件，包括冒煙測試套件，功能測試套件，業務安全測試套件。
②測試缺陷需要從測試案例發起，所有的案例均需在測試準出前執行完畢。
6、測試度量名額：測試度量
測試案例導入及時率：測試準入通過後7日内導入；
測試案例執行率：目标值100%；
緻命、嚴重級别缺陷占比，反向案例占比，平均每百測試案例缺陷發現數，測試執行通過率，測試自動化率等等。這些名額都需要關注并按要求完成。
（五） 運作維護階段
項目順利投産，進入運維階段，測試執行工作暫時告一段落，但測試工作并沒有結束，我們還需要跟蹤投産情況，同時關注系統上線後的運作情況。對于建立系統，需要收集系統的運作資料，以便後續的優化項目。我們可以根據運作情況來評估回歸測試的方式，也可以對後續優化性能測試政策、測試目标、測試場景等提供參考和支援。
通過上述對軟體測試過程的簡要梳理，相信大家對于測試過程中如何排雷和應急有了一定的認識，軟體測試是為資訊系統排雷的，那誰來為軟體測試的工作排雷呢，就需要我們大家積極思考，将類似的“地膜”事件一一找出，讓排雷工作不含雷。
最後邀請想提升實力的測試人一起學習
如果你的也有很多問題想要解決，你的測試職業規劃也需要一點光亮，你也想跟着大家一起分享探讨，我給你推薦一個「Python自動化測試學習交流群902061117」你缺的知識這裡有，你少的技能這裡有，你要的大牛也在這裡……
這些資料，對于【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你
關注我的微信公衆号【傷心的辣條】免費擷取~
送上一句話：
世界的模樣取決于你凝視它的目光，自己的價值取決于你的追求和心态，一切美好的願望，不在等待中擁有，而是在奮鬥中争取。
如果我的部落格對你有幫助、如果你喜歡我的部落格内容，請 “點贊” “評論” “收藏” 一鍵三連哦！
好文推薦：
轉行面試，跳槽面試，軟體測試人員都必須知道的這幾種面試技巧！
測試崗反複跳槽，跳着跳着就跳沒了…
軟體測試人員該學習 Python 的七個理由
App公共測試用例梳理
面試經：一線城市搬磚！又面軟體測試崗，5000就知足了…
35歲之後軟體測試工程師靠什麼養家？我能繼續做測試！