?
隨著敏捷開發模式的流行，版本交付周期縮短，測驗工期壓縮，一線測驗工程師不僅作業節奏加快，而且作業量也在加大，但是，我們的成長速度似乎越來越慢，這是為什么呢？大環境下，我們都陷入了一個非成長型的惡性回圈，隨著專案迭代頻率加快，回圈的回歸測驗和發布執行等作業不斷地消耗著我們的精力和成長動力，我們都想跳出這個回圈，卻并沒有那么順利，
那么，我們就這樣躺平么？當然不行，我們必須繼續探索跳出這個惡性死回圈的方法，本文想從測驗檔案的整理說起，分享測驗成長的探索之路，
一、 傳統測驗檔案
傳統的測驗檔案一般包括：測驗計劃、測驗用例、測驗缺陷和測驗報告，測驗計劃檔案整理了測驗的排期，測驗用例檔案整理了具體的測驗點，測驗缺陷檔案記錄了測驗程序的Bug，測驗報告整理了測驗結果，如圖2-1，我們可以發現，整理這些檔案其實還是局限于系統測驗這個節點，我們的關注點還是停留在測驗執行這個回圈中，或許，我們可以嘗試跳出這個傳統思維，從整個軟體生命周期來關注如何整理測驗檔案，
二、 探索型測驗檔案
如果從整個軟體生命周期來關注測驗檔案的整理，我們可以關注哪些內容？關注這些內容能讓我們有哪些成長？
2.1 檔案內容
如圖2-1所示，此測驗檔案包含以下六類資訊：需求分析、需求開發方案設計、需求開發、需求測驗、需求發布和其他需求資訊，本文將此測驗檔案定義為探索型測驗檔案，探索型測驗檔案不再只是關注系統測驗節點的相關檔案，而是以整個需求開發生命周期的視角來收集所有有利于測驗保障作業和測驗能力提升的檔案，具體細分內容可看下圖，或者可從原文獲取上述腦圖檔案，
2.2 關注理由
相對于以往關注的測驗檔案，探索型測驗檔案能夠幫助我們逐漸了解到軟體生命周期的全貌，知己知彼，百戰不殆，只有了解別人在做什么，才能更好地與人溝通和協作，只有了解整個專案各個節點在做什么，才能從測驗執行者的回圈中跳出，提高對整個專案的質量意識和把控能力，
需求分析中，除了關注《需求檔案》的內容，我們也可以關注《UI/UX設計檔案》，界面和互動設計內容其實也是需求的一部分，我們需要關注并補充測驗用例，同時，我們還可以關注《埋點設計檔案》，埋點像是一個產品的眼睛，我們需要保障其合理且正確，關注埋點質量，也提高了我們關注產品最終業務質量的意識，
需求開發方案設計中，除了關注《介面設計檔案》，我們還可以更深入了解《資料庫設計檔案》，這樣能幫助測驗工程師更深入學習到系統的資料流，如果我們還想更清晰學習需求的實作邏輯，我們可以了解《服務端需求實作方案檔案》和《客戶端需求實作方案檔案》，了解這些內容不僅能提升我們的黑盒測驗技巧，也能幫助我們學習和掌味訓盒測驗和白盒測驗，
需求開發階段，似乎和我們測驗工程師沒什么關系，但是實際上我們可以關注專案代碼倉庫地址，開發的每一次代碼提交都會記錄在倉庫中，我們可以關注提交記錄和提交說明，當然我們也可以對著開發提交的資訊說明試著熟悉代碼，這樣就可以提升我們的代碼閱讀能力，
需求測驗中，《測驗用例檔案》、《測驗缺陷檔案》和《測驗報告檔案》是我們關注的基本內容，這里就不贅述，
需求發布中，我們可以關注需求相關的配置資訊，避免后續自己或者他人出現配置錯誤，同時，我們也學習和掌握發布策略和回滾策略，這兩部分其實包含很多優秀的思想，能夠幫助我們了解到更巧妙的質量保障方案，
其他需求資訊中，我們可以記錄需求相關負責人，有利于快速找到對應負責人，我們可以補充需求的測驗地址（資源）資訊，幫助自己或者其他人員快速在測驗環境進行驗證，在需求啟動前期，我們也可以從整個專案的維度整理好《需求排期表》，包括需求計劃（實際）評審時間、（前端/服務端）開發計劃（實際）提測時間、測驗計劃（實際）完成時間和專案結束時間等，這樣一旦專案在測驗前各個階段出現延期風險時我們就能感知到并暴露風險，
三、 總結
對于探索型測驗檔案來說，其內容并不局限于上文，其內容可以根據具體業務動態變化，但是其核心思路可以是不變的，以需求為根節點，將整個專案程序中有利于測驗保障作業和測驗能力提升的資訊匯總到一起，
如果你的團隊并沒有產出上述檔案或者你對上述檔案還并不熟悉，沒有關系，你并不需求現在掌味訓者要求你的團隊產出所有，但是，你需要先有意識從專案維度去整理探索型測驗檔案是可以幫助你成長的，然后你只管嘗試，或許，會有意想不到的識訓，
作者簡介：Chaofan，愛測角成員之一，專注探索和分享軟體質量保障，
原文地址：《漫談測驗成長之探索——測驗檔案》
如果覺得本文對你有幫助，可以點個??支持一下，
?
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/501792.html
標籤：其他