項目背景
某項目是一個OA管理系統（外包給一家南方公司），以JAVA為開發語言、VUE為前端架構、MySQL為後端資料庫管理系統。去年9月開始立項、開發，一直到今年6月中旬釋出，減除項目暫停期間，共曆經7個多月。
項目規模
該系統主要由六大子產品組成。項目成員有1名項目經理、1名開發經理、10餘位開發、2名測試。
項目測試情況
2021年11月份末，部門經理找到筆者，讓筆者到該OA系統項目做測試。由于要兼顧其他項目，每天有50%左右時間來做該系統的功能測試，大概持續1個月測試随項目暫停。
2022年3月底，再度接到部門經理的通知，要進行該項目的驗收測試。撸起袖子加油幹，先制定了項目驗收計劃。
接着找出編寫過的測試點、重新梳理，并在驗收測試過程中逐漸完善。測試點分為兩份，其中第一份覆寫全面，每個子產品功能粒度很細，而上線前時間有限不允許全面測試，覆寫了重點子產品主要業務流程即可。
驗收測試一共經曆了3輪，第一輪1次疊代，第二輪6次疊代，第三輪20次疊代，進行更為嚴格的測試。
項目測試過程中遇到的問題及小結
1. 保證送測版本的品質
第一輪驗收測試，執行了第一個子產品的41條測試用例，用時1周，測試用例執行失敗率高達21.95%,筆者當晚馬上向項目經理回報，并推測未來的bug數量将不少于80。後續的測試也證明了，bug數量确實是超了80，總數正好達100封頂。
項目經理在第二天即發出郵件通知外包方先進行内部測試，測試通過後再繼續驗收。随後外包方進行了内部測試，内部測試通過後筆者繼續進行驗收測試。項目經理的這個叫停決定很有效地保證了送測版本的品質，雙方都減輕了壓力，節約了時間。
小結一下：
(1)送測版本是需要制定一個标準的。在項目開始時要跟項目組約定，比如送測後已知bug數量超過N個，則打回版本停止測試。這裡N可以根據項目或團隊讨論決定。
(2)遇到了重要事情一定要向上級反應，直至推動事情的解決。
2. 重複的工作用selenium自動化測試替代
該OA系統中流程子產品是重點，主要涉及10張表單及流程，其中假别又分為11種假别類型。建立流程類是重複工作之一，除了下拉選擇流程類别，其他字段一樣，自然想到用到selenium自動化測試來解決。
其次是發起11種請假類型，除了請假類别下拉選擇，其他字段也一樣，同樣可用selenium自動化測試。第三，除了10張表單建立外，10張表單的審批功能也類似，可以用自動化腳本解決。筆者可以有更多的時間去做溝通、互動邏輯測試、測試資料分析、整理彙報等，效果還可以。
期間參加了一個前後端綜合測試訓練營，有效地改進了bug定位方法，給外包開發同學提供有用的bug接口參數響應資訊，收獲頗多。
小結：重複工作可以自動化。
3. 溝通以誠為本
外包公司派來一位前端同學，配合修改bug，并為外包内部開發人員和筆者中轉溝通。筆者本着以誠為本的态度，所謂金誠所至金石為開，除了bug截圖，對于不易再現或者雙方有分歧的地方，提供傳參和請求響應截圖、錄屏，能提供有助于定位bug解決bug的資訊全力提供，所有能用上的方法都用上。
最後要相信團隊的力量，項目組員終因測試的真誠而認真處理bug，最終一起保證項目的品質和傳遞。
4. 開發後期修複bug的成本永遠比前期高出許多
去年9月份至今年1月份期間，該系統已暴露的功能類bug100多，UI類bug100多，其中UI類bug基本解決，功能類bug遲遲未完全修複。直到驗收測試階段，緩慢地推進新bug的解決，系統趨近于穩定。
截止筆者寫稿時，尚有一個使用者體驗的問題在開發同學手中加班修複中，其餘九十多個bug已全部解決。從時間跨度看，如果在去年項目前期解決了，不至于在今年驗收階段，花整整2個月時間測試、修複。希望小夥伴們項目團隊可以引以為戒，在bug被暴露的時候就解決。這也很好地解釋了測試的準則之一“盡早測試盡早發現bug”的真谛~
5. 持之以恒
由于項目周期長，開發團隊新舊血液更換，時間長了業務容易遺忘、換了開發人員業務不熟悉不那麼快速上手，導緻測試過程中發現的bug，有的低級，有的反反複複激活。
很早筆者向項目經理透露，該項目功能多，邏輯複雜，上手需要一定的時間。後來從其他同僚得知該團隊的開發技術一般。個人覺得，相比需要有經驗的測試，該項目更需要有經驗的開發，開發品質在某種程度上決定了項目品質。
小結：這項馬拉松式的驗收測試，需要持之以恒的耐心、細心和責任心，也是我們測試同學的基本功~
最後：
1）關注+私信回複：“測試”，可以免費領取一份10G軟體測試工程師面試寶典文檔資料。以及相對應的視訊學習教程免費分享！，其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、接口測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、接口自動化測試、測試進階持續內建、測試架構開發測試架構、性能測試等。