三年功能測試，測試工作吐槽

概述

大家好，我是洋子。有很多粉絲朋友目前還是在做功能測試，日常會遇到很多繁瑣，棘手的問題，今天分享一篇在testerhome社區的帖子《三年功能測試，測試工作吐槽》

原文鏈接https://testerhome.com/topics/38546

這篇文章基于中小公司的工作經驗，中小廠的測試流程往往沒有大廠那么規范，也會遇到很多挑戰，來看下他是怎么解決的

問題一：測試時間評估

這是一個工作日常經常需要回復的問題，理論上測試這邊要做出較科學合理的回復，那就要將
【需求變更】
【開發進度延誤】
【bug 修復不穩定】
【復雜業務流程】
【測試環境不穩定】
【上下游服務依賴】
【人員資源】
【是否引入新技術】
【回歸范圍】
等等不確定因素考慮進去，再多方溝通確定才能獲得相對合理的答案。但現實里一個功能測試會同時測試幾個項目，通常是最晚得知新需求的內容，需求評審會議都是被冷不丁拉入，然后產品劈里啪啦講完后就讓你給個測試時間，方便他安排工作。

臨時進入會議，需要你馬上給個估計時間場景：

【解決方法】詢問開發所用的時間，將測試時間設定為開發時間的 50%、70% 或 80%（根據現場氛圍說自己的百分比）

流程較規范，測試先拿到需求文檔進行評估：

【解決方法】編寫完測試點，根據一條用例平均 5 分鐘的時間，然后根據一天實際能干活的時間，例如用 6 小時去粗劣計算天數，越多越好（測試時間肯定會被壓縮）

注意：如果覺得系統很復雜，自己無法正確評估，拉上你的領導/組長一起判斷，千萬別不好意思或者覺得這樣顯得自己很差，我們是功能測試，要學會哭慘！，任務太難或者太多就讓組長拉多一個人來幫忙。同時測試這邊投入的人力數量需要告知下產品，防止那種一旦看到時間有盈余，就瘋狂后期加需求的產品。

問題二：同一時間需要完成多項測試任務

大多數功能測試的現狀應該差不多，通常是測試著 A 任務，就接到 B 任務的需求評審，已上線的 C 任務現網出現了些問題反饋需要你跟進，然后測試組自動化的任務 D 也要完成進度，最后 C 任務根據用戶的一些反饋做了功能整改，拉你評審和排期

需要當天確定的任務：

緊急且重要、緊急但不重要、不緊急但重要、不緊急且不重要。四個級別分類任務，雖然老套，但是真的有用，事情一多時，人特別容易煩躁，這時候就需要一個指導思想

多個周期任務：

依據截止日期，根據任務的截止日期制定計劃。先處理最緊急的任務，確保不會因為延誤而影響項目進度
注意：任務多頂不住就求救，別硬撐，看過應屆生一個人測試著吃力不說，搞得老同事接鍋加班的

問題三：需求不明確

這應該幾乎是所有功能測試都會遇到的問題，主要分為三種：

一句話需求，甚至需求文檔寫在 txt 里，就一句話，eg:【充值滿 XX 元獲得獎勵】（本人真實經歷）
抄襲的需求，同為差不多的功能，拿了其他產品的需求文檔適當做了修改就發出給研發
全文字需求，無流程圖無交互稿

情況一：一句話需求

老實說這種類型的產品一般都是愣頭青，你要是把需求文檔打回去，通常情況下只是從一句話需求變成十句話需求，解決不了問題，你還是要在時間內完成測試

測試這邊辛苦些，拿上述一句話的例子【充值滿 XX 元獲得獎勵】，列出不清晰的點：缺乏詳細活動規則說明、獎勵類型不明確、具體數值、活動觸發條件、用戶資格驗證條件、界面展示交互、獎勵發放的觸發時機等
與產品經理電話溝通，詢問有關背景、業務目標、關鍵功能、用戶期望等方面的問題，然后將列出的不清晰點發到大群并 @ 開發和產品，讓其在文檔里做補充
千萬別和產品私聊然后自己一個人確認需求，全部互動都要在大群

情況二：抄襲需求

通常拿來主義的產品都是很懶的，同時沒啥主見，甚至他會叫你去找他抄襲的那個產品聊，麻煩的點主要在于實際轉測后發現功能實現與文檔不一致，開發給的原因是其中的業務邏輯或用戶需求不適用于當前項目

轉測后，讓產品提前先體驗，讓產品先滿意后再測試
其他參考情況一

情況三：全文字需求

通常這類產品還挺固執，認為自己描述得很清楚

解決方式基本和情況 1 一致

注意：以上三種情況，務必都要告知自己的直屬領導，同時減少和產品的私聊，多在大群里聊，多留刷鍋的證據

問題四：線上出現 bug

線上出現 bug 時，大多第一時間會很慌，生怕是自己的鍋，所以步驟很重要，一方面防止非自己的鍋被人甩在身上，一方面要顯得自己是個負責的成熟測試

通常都是群里忽然炸鍋，截圖出 bug 點，然后產品們嘰嘰喳喳

冷靜點，群里先發一句：“我定位下，看能不能復現”
現網嘗試復現 bug，如果 bug 能百分百復現，@ 相關開發排查，并發出便于定位的相關的日志和信息
測試環境嘗試復現，若能復現，查詢下測試用例有無覆蓋當前的場景【確保不是測試用例執行遺漏，執行遺漏和覆蓋遺漏是兩個不同的鍋，執行遺漏是態度問題，很嚴重的】
如果是自己的鍋，記得表現出積極解決問題的態度，配合開發檢查修復狀態，并同步到大群，要將 bug 出現的原因和修復方法了解清楚，方便后續做復盤和回答領導的詢問。
如果是他人/環境的鍋，要表現出超級積極解決問題的態度，將 bug 原因和修復情況實時同步到大群

注意：遇到線上 bug，一定不要急著瘋狂甩鍋和疊buff（這個在測試階段時就要上的護甲，測試報告提示風險和大群聊天記錄），要表現出先解決問題的態度，同時搜索對自己有利的條件。

問題五：測試報告風險規避

主要有幾點：

測試日報中，阻塞測試進度 bug、偶現 bug、p0 級未解決 bug 需要標紅加粗放在測試報告醒目的地方
對于測試環境無法完美模擬現網環境的測試場景，需要在報告中標紅加粗體現（風險多說不虧）
測試進度根據測試用例執行的百分比來寫

問題六：測試時間不足

造成測試時間壓力的通常有以下幾種：開發時間延期、產品上線日期提前【大 boss 給的壓力】、需求變更、測試人力資源變動、測試物料阻塞、復雜的業務邏輯。通常遇到時間不足，最好的解決方式還是加人，其他的只能前期進行預防```

開發延期：喜聞樂見的情況，鑒于經驗通常都是延期 1-0.5 天，所以測試時間評估一般都要在自己評估的時間上至少 +1 天，同時保持在開發轉測時間的前一天問下開發進度的習慣。如果開發給了進度不樂觀，及時同步給產品和測試領導，看產品是否可以調整時間或者領導這邊加測試人力。將測試壓力盡量提前告知，給測試領導和產品有調整分配的時間，不要依賴開發去反饋
產品上線日期提前：沒有任何方法預防，一般大老板開口了，測試領導比你還緊張，會積極詢問你測試進度情況和風險，你這邊要是沒把握，可以提出增加人力的要求。
需求變更：需求變更也是很常見的，特別是都轉測了，產品那逼還在每天優化更新他的需求文檔。這里需要預防一個坑：你要截圖保存他轉測前的最后一次需求文檔并發到大群 @ 相關人，防止后面現網出現需求不一致情況時，產品拿著他未同步且更新過的文檔來興師問罪。到時你百口莫辯，特別是測試地位比較低的公司，產品修改需求是不跟測試及時同步的。時間上也以每次變動的大小產生的影響，記錄在測試報告上，規避背鍋的風險。
測試人力變動：原本兩個人測試的任務，因為其他原因變成一個人。這也是很常見的情況，特別是兩個人當初分好了測試范圍，你這邊只了解和評估了自己的范圍，對其他人那部分并不了解，無形之中增加了后期的測試壓力和時間。這種情況通常沒啥好的解決方法，記得要哭慘，要讓測試領導和產品去協調。別一個人傻傻的硬撐瘋狂加班
測試物料阻塞：電商類型的項目通常涉及一些消費券的申請和配置，同時這些券的使用還帶風控判斷。測試這邊要根據情況，轉測前提前溝通準備好測試物料，申請需要用的白名單和權限，熟悉好對應的配置系統。防止正式轉測前，被一堆權限和申請的事情嚴重拖延到進度。
復雜的業務邏輯：具體情況具體分析，根據經驗，面對復雜的業務邏輯，最好的方法就是編寫清晰、詳細的測試用例。對自己要有 B 數，評審階段感覺吃力就求救兵

問題七：用例執行困難

用例執行困難，通常是開發質量差導致

目前感覺最好的辦法：轉測前，出一份冒煙用例給開發，通過冒煙用例后才能轉測，否則主流程測試阻塞，只要代碼有大改動，基本都要重新測。測試地位比較低的公司，可以把這個流程安利給測試領導和產品，讓領導去推動

問題八：測試數據陷阱

常出現于前端開發，轉測時給你的 mock 數據與實際現網數據結構不匹配，如果你是比較擅長 mock 數據和做代碼 review 的，通常還挺容易踩這種坑，拿著這個錯誤的數據模板做了多個邊界值和數據類型變化測試，代碼對每個數據的處理邏輯也是正確的。然后發布到現網就報錯無法交互

對開發要保持懷疑的態度：驗證環節需要接入現網數據去看測試頁面的響應是否正確

問題九：業務自動化實現

很多公司的業務通常都是未經探討直接強行自動化的，UI 自動化能阻止就阻止，阻止不了就加入。對于接口/ui 自動化，老實說我一直覺得最好的提效方式就是找個市面上商業化的自動化平臺工具，直接買來就用（面過一個國企，他們就是這樣干的），都不用投入什么人力，付費工具那點錢對公司來說也不多，測試這邊還能把精力放在業務上，有需求就給技術方提，這才是最好的提效方式。

可惜現在都要抽出一部分人力去搞這種做完很少人用且不好用的平臺，搞笑的是這些平臺的技術難點都集中在前后端框架業務實現，反而能在業務中起到多大作用的考慮倒是最低的，基本還是走的請求返回再斷言那套，或者更魔幻點的 UI 自動化都給你加上 AI 賦能尋找控件。。。。。其實大部分都是把實現過程復雜化，然后起作用的還是你用最原始的 pytest+request 組合去斷言那套