不知道各位測試同學是否被開發同學的提測質量困擾過?在經歷了一個版本800多個bug,原計劃一個月測完,結果測了2個半月的痛苦經歷之后,對提測質量的把控進行了一定的思考。

  影響提測質量的原因有哪些?
  需求不夠完善
  項目復雜度高
  涉及多開發的協調問題
  開發人員經驗不足
  開發周期緊張
  開發人員自測不充分
  能夠改進提測質量的手段有哪些?
  完善的項目流程和過程管理
  充分的需求評審和開發設計評審
  充分的開發時間
  經驗豐富且高素質的開發同學
  夢想總是要有的,萬一實現了呢?
  但多數情況是:理想如此豐滿,現實卻很骨感。對于新項目、新產品,基本上是時間緊、任務重、無流程、缺規范。以上條件能剩下什么?即使最后一點,也無法保證每個開發同學都能達標。
  那么要保證開發的提測質量,還能剩下什么方法?只有一條:通過開發自測來保證。
  而通過開發自測來保證提測質量這件事情,在我看來主要有兩個關鍵因素:1.覆蓋度;2.執行力。
  覆蓋度
  跟確保產品質量依賴測試覆蓋度一樣,開發提測質量與自測case的覆蓋度緊密相關的。但用戶提測的自測case肯定不等同于正式測試的測試用例,那么該如何定義自測case呢?
  自測case應該由測試同學提供。
  開發同學提測后的接收方是測試同學,提測質量直接影響測試同學開展工作,因此自測case理應由測試同學給出。
  自測case的標準如何?
  要保證該模塊需求中要求的功能是否正確實現。
  要保證該模塊主要功能邏輯、主流程主路徑能否正常運行。
  要保證和該模塊耦合度較高的模塊,沒有明顯異常。
  要保證自測case通過后,不會有大塊的測試用例無法執行。(例如某個邏輯有30條測試用例需要執行,那么這個邏輯的生效性驗證就需要加入自測case;如果某個邏輯只有2~3條測試用例需要執行,那么這個邏輯的生效性驗證就可以考慮不用加入自測case)
  可以考慮在自測case中,增加一些測試認為容易出現bug的路徑。這個事情需要依賴測試經驗的積累。
  規定開發同學自測的環境、測試方法、版本等內容。讓開發同學自測時滿足測試同學的預期,避免產生不必要的問題??赡艹霈F的場景例如:
  開發自測時使用的是本地環境。
  開發自測只對自己的接口測試,而不是整個真實的環境串聯起來測試。
  開發使用debug版本自測而不是release版本自測。
  自測case的執行要保證通過提測的版本進行,不能使用接口測試。必須得帶著前后端一起測試。整體測試。
  針對質量較差的開發,可以增加自測case的數量級。如果某些開發同學的提測質量一直不高或者bug較多,可以在給他的自測case中多增加一些內容。但這么做之前需要跟開發同學或開發leader達成共識,這個過程中可以通過以下方式作為說服對方的輔助手段:
  開發同學提測質量低的實際案例。
  開發同學負責的模塊bug數量多的案例。
  執行力
  即開發同學自測時的執行力。這點,我們其實沒辦法保證,測試同學控制不了,也管理不了開發的行為。但這不意味著我們什么都不能做??梢杂貌捎靡韵聨追N輔助方式:
  通過提供自測case的格式,約束開發同學的行為。比如在自測case中,加入明確的測試結果一項,讓開發回復時必須填寫是否通過。
  通過郵件公示的方式,約束開發同學的執行力。開發的提測郵件中必須@開發leader、@項目負責人或@老板。
  針對提測質量較差的開發同學或新加入的開發同學,在其提測后增加測試驗收環節,確保開發同學自測到位。這過程發現實際效果與開發自測的反饋結果存在差異,需要及時反饋,當然需要@上一條中的那些能夠管控開發同學的負責人。
  如果提測時涉及多名開發同學(如需要前后端交互),那么需要約定好主負責人,自測由該主負責人進行,避免提測出現問題時各種扯皮。
  除上述兩方面外,我們還可以通過引入其他方驗證(如產品、交互、設計)的流程,然后再提交到測試環節,這樣能夠很有效的提升提測質量。
  雖然有上述心得的總結,但仍有一種情況是目前無法有效解決的,即:提測質量無法達到預期(甚至很差),但上線時間固定,因此無法按流程將提測打回,讓開發同學進行二次開發然后重新提測。這種情況下,仍然在大量的占用測試時間,壓縮測試工期。希望有好方法的同學們能夠分享自己的解決方案。