功能測試吐槽

作為功能測試，我也分享下日常工作中功能測試值得吐槽的問題，由於工作時間不長且未進過大廠，不瞭解大公司的工作模式和流程，所以自己的方法和理解都是基於中小公司的工作經驗總結，應該適用於跟我一樣的小白，沒有各種高大上的左右移動，測開大佬們輕噴。

問題一：測試時間評估

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

• 臨時進入會議，需要你馬上給個估計時間場景：
• - 詢問開發所用的時間，將測試時間設定為開發時間的 50%、70% 或 80%（根據現場氛圍說自己的百分比）
• 流程較規範，測試先拿到需求文件進行評估：
• - 編寫完測試點，根據一條用例平均 5 分鐘的時間，然後根據一天實際能幹活的時間，例如用 6 小時去粗劣計算天數，越多越好（測試時間肯定會被壓縮）

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

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

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

• 需要當天確定的任務：
• - 緊急且重要、緊急但不重要、不緊急但重要、不緊急且不重要。四個級別分類任務，雖然老套，但是真的有用，事情一多時，人特別容易煩躁，這時候就需要一個指導思想
• 多個週期任務：
• - 依據截止日期， 根據任務的截止日期制定計劃。先處理最緊急的任務，確保不會因為延誤而影響專案進度

注意：任務多頂不住就求救，別硬撐，看過應屆生一個人測試著吃力不說，搞得老同事接鍋加班的。

問題三：需求不明確

這應該幾乎是所有功能測試都會遇到的問題，主要分為三種：1. 一句話需求，甚至需求文件寫在 txt 裡，就一句話，eg:【充值滿 XX 元獲得獎勵】（本人真實經歷）；2.抄襲的需求，同為差不多的功能，拿了其他產品的需求文件適當做了修改就發出給研發；3.全文字需求，無流程圖，無互動稿。

• 情況 1：（老實說這種型別的產品一般都是愣頭青，你要是把需求文件打回去，通常情況下只是從一句話需求變成十句話需求，解決不了問題，你還是要在時間內完成測試）
• - 測試這邊辛苦些，拿上述一句話的例子【充值滿 XX 元獲得獎勵】，列出不清晰的點：缺乏詳細活動規則說明、獎勵型別不明確、具體數值、活動觸發條件、使用者資格驗證條件、介面展示互動、獎勵發放的觸發時機等。
  • 與產品經理電話溝通，詢問有關背景、業務目標、關鍵功能、使用者期望等方面的問題，然後將列出的不清晰點發到大群並 @ 開發和產品，讓其在文件裡做補充。
  • 千萬別和產品私聊然後自己一個人確認需求，全部互動都要在大群。
• 情況 2：（通常拿來主義的產品都是很懶的，同時沒啥主見，甚至他會叫你去找他抄襲的那個產品聊，麻煩的點主要在於實際轉測後發現功能實現與文件不一致，開發給的原因是其中的業務邏輯或使用者需求不適用於當前專案）
• - 轉測後，讓產品提前先體驗，讓產品先滿意後再測試
  • 其他參考情況 1
• 情況 3：（通常這類產品還挺固執，認為自己描述得很清楚）
• - 解決方式基本和情況 1 一致

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

問題四：線上出現 bug

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

• 通常都是群裡忽然炸鍋，截圖出 bug 點，然後產品們嘰嘰喳喳
• - 冷靜點，群裡先發一句：“我定位下，看能不能復現”
  • 現網嘗試復現 bug，如果 bug 能百分百復現，@ 相關開發排查，併發出便於定位的相關的日誌和資訊
  • 測試環境嘗試復現，若能復現，查詢下測試用例有無覆蓋當前的場景【確保不是測試用例執行遺漏，執行遺漏和覆蓋遺漏是兩個不同的鍋，執行遺漏是態度問題，很嚴重的】
  • 如果是自己的鍋，記得表現出積極解決問題的態度，配合開發檢查修復狀態，並同步到大群，要將 bug 出現的原因和修復方法瞭解清楚，方便後續做覆盤和回答領導的詢問。
  • 如果是他人/環境的鍋，要表現出超級積極解決問題的態度，將 bug 原因和修復情況實時同步到大群

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

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

主要有幾點：

1. 測試日報中，阻塞測試進度 bug、偶現 bug、p0 級未解決 bug 需要標紅加粗放在測試報告醒目的地方。

2. 對於測試環境無法完美模擬現網環境的測試場景，需要在報告中標紅加粗體現（風險多說不虧）。

3. 測試進度根據測試用例執行的百分比來寫。

問題六：測試時間不足

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

• 開發延期：喜聞樂見的情況，鑑於經驗通常都是延期 1-0.5 天，所以測試時間評估一般都要在自己評估的時間上至少 +1 天，同時保持在開發轉測時間的前一天問下開發進度的習慣。如果開發給了進度不樂觀，及時同步給產品和測試領導，看產品是否可以調整時間或者領導這邊加測試人力。將測試壓力盡量提前告知，給測試領導和產品有調整分配的時間，不要依賴開發去反饋。

• 產品上線日期提前：沒有任何方法預防，一般大老闆開口了，測試領導比你還緊張，會積極詢問你測試進度情況和風險，你這邊要是沒把握，可以提出增加人力的要求。

• 需求變更：需求變更也是很常見的，特別是都轉測了，產品那逼還在每天最佳化更新他的需求文件。這裡需要預防一個坑：你要截圖儲存他轉測前的最後一次需求文件併發到大群 @ 相關人，防止後面現網出現需求不一致情況時，產品拿著他未同步且更新過的文件來興師問罪。到時你百口莫辯，特別是測試地位比較低的公司，產品修改需求是不跟測試及時同步的。時間上也以每次變動的大小產生的影響，記錄在測試報告上，規避背鍋的風險。

• 測試人力變動：原本兩個人測試的任務，因為其他原因變成一個人。這也是很常見的情況，特別是兩個人當初分好了測試範圍，你這邊只瞭解和評估了自己的範圍，對其他人那部分並不瞭解，無形之中增加了後期的測試壓力和時間。這種情況通常沒啥好的解決方法，記得要哭慘，要讓測試領導和產品去協調。別一個人傻傻硬撐瘋狂加班。

• 測試物料阻塞：電商型別的專案通常涉及一些消費券的申請和配置，同時這些券的使用還帶風控判斷。測試這邊要根據情況，轉測前提前溝通準備好測試物料，申請需要用的白名單和許可權，熟悉好對應的配置系統。防止正式轉測前，被一堆許可權和申請的事情嚴重拖延到進度。

• 複雜的業務邏輯：具體情況具體分析，根據經驗，面對複雜的業務邏輯，最好的方法就是編寫清晰、詳細的測試用例。對自己要有 B 數，評審階段感覺吃力就求救兵。

問題七：用例執行困難

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

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

問題九：測試資料陷阱

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

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

問題十：業務自動化實現

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

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

• 公司最好的方法就是跟隨大眾，自動化技術能力基本都是測試標配了，但是能把自動化設計好的估計沒幾個。

更多內容可以學習《測試工程師 Python 工具開發實戰》書籍、《大話效能測試 JMeter 實戰》書籍