測試流程與測試人員配置的一點感想

　　從去年秋冬季節來到這個地方，直至明天正式離開，說起來也在這個霸氣威武的bd大廈呆了挺久的一段時間了。
　　與周圍的那些rd、qa、pm等相處下來雖然不至於說是親如一家，但至少也算是有點感情了，所以在這裡對之前工作中的一些基礎測試流程和人員方面的東西做一個總結，以此來紀念我在大廈的日子。———題記
　　初到大廈拿到第一份testcase的時候，我的第一感覺是意外；第二感覺是懵；第三感覺是雲裡霧裡的繞啊繞，也繞不出一個結果來。
　　當時的那份testcase，說實話，真心看不懂，尤其是對於我一個剛過來工作，需求業務都還沒有一點點印象的人來說。一條case中可以有多個等價 類、可以有多個組合，預期結果中可以有多個操作步驟混合預期結果；並且沒有相關的業務操作步驟來說明如何做，並且整體case模組有十幾個，但是找下去很 多模組又似乎不是我們要測試的，當時我就震驚了，並且我的小夥伴們也震驚了。
　　關於testcase，大部分公司都有自己的一套標準來約束如何寫，如何劃分功能模組和優先順序。但是不管怎麼劃分，以下這幾點總是不能變的。
　　必須具有較強的可讀性、可操作性；這個的標準就是你直接拉一個對這個專案需求和業務完全不懂的人過來照著你的case能夠執行下去，不會有太多偏差和卡殼的地方。
　　儘量從使用者視角出發去寫case，只有當使用者視角不能覆蓋之後才考慮採用程式碼邏輯去描述；這一點可以保證你所寫出的case能夠被更多的人順利執行，畢竟case不是一個人的case，他是所有參與進測試的同學們都必須要看的。
　　必須具有比較清晰明確的層級分佈關係；很多專案都沒有足夠的時間讓你過完全部的case，並且很多時候版本改動的地方並不需要執行全部的case，這時候良好的分級關係case就能夠更合理有效的完成功能測試和覆蓋測試。
　　case分級要合理。如果不合理，在過case的時候相信很多人都會有種想死的感覺：多了自己累的要死，但是感覺沒什麼用；少了自己心裡又沒底。在這裡簡單套用個以前江姐老大的分級依據：P0、P1、P2的比例大概為25%、30%、45%
　　之後就是測試流程。剛到的時候我問過deRon流程的事，結果他說就是rd開發完後提交給我們測試，我們測試完了發測試報告，絲毫感受不到流程控制的 因素在其中。及至後面，專案中增加了daily build之後，每日測試雖說緩解了測試專案中測試介入時間較晚的問題，但是也暴露了很多其他問題，在下面做一個簡單總結：
　　daily build的測試重點。首先，daily build的意義在於把以前的測試晚介入提前到了開發週期內，而在開發週期內，發現bug的數量和保證功能的效率是最快的；但是傳統的測試流程中，每個 daily build輪次中都必須對全功能case做以覆蓋。那麼et的bug發現和case覆蓋這兩個地方就需要做以側重，目前的要求上是測試於case覆蓋，但 實際上執行的時候更多是前期側重於et的bug發現，在daily build後期逐漸偏向於case覆蓋；
　　daily build的測試任務。目前的case有600+條，P0和P1的合起來就佔了400+條，每次執行下去都需要一個人天的工作時間；但是我們的測試任務要 求，每兩個版本之間就要過一次P0P1的case，然後還要對之前修改過的部分和新功能做一個et測試，算下來，兩個人一整天的時間都不夠的。所以，實際 測試結果就是我們所提交的測試報告這些中都沒有了P0和P1的case；
　　需求不清，這個是目前最大的通病了，onSite和正式員工之間的交流和溝通的問題。也許需求bd的正式員工是清楚的，因為每次過下一階段需求的時候 只有他們在開會，但是實際上到了測試設計和測試執行的時候卻都是些苦逼的非正式的onSite的孩子們在幹。所以需求不清導致的修改點不明，從而不停的確 認需求，再返工測試。造成的結果就是：很多時間浪費了，很多人也迷茫了，很多心也有想法了。
　　判定標準比較模糊。
　　最後就是人員配置的問題。目前android端有2個人全部人力參與測試，另外還有2個半人力投入。
　　這種情況下呢，就是半人力投入的人員對於需求不熟，對於業務不是很精深，但是在測試工作劃分上卻是直接一刀切。這就使得半人力的在工作時間上大大延 長，因為他要花很多時間去反覆確認一個問題，甚至有誤報的情況；而對於需求熟悉的人卻很多時間都花在了基礎ui部分的case執行上。
　　於是，經常能看到工作不能按時完成或者整理不能按照預期結果來實現。
　　針對上面的這些情況，提出一點自己的看法，或許有幫助，或許有所參考，總歸能有點好處就是最好的。
　　需求方面及時向測試執行的onsite孩子們公開，從源頭上節省反覆確認需求的時間；
　　目前大版本週期有三週，小版本週期有兩週；那麼daily build測試重點就可以大致如下劃分：大版本前兩週做修改點et測試和測試設計，後一週做case覆蓋和穩定性覆蓋等測試；小版本前三天做et，後兩天 做覆蓋。當然，這個時間不是固定的，具體以新功能開發完成的時間點為準。
　　測試case要及時更新維護，並且加上修改記錄。以免得本身人員流動比較大的onsite孩子們過來後還得花好幾天時間去理解這些case寫的是啥
　　測試人員配置上，新手主要負責ui邏輯互動和功能覆蓋，以便於快速熟悉業務和完成基本功能；熟悉業務邏輯的則可以進行深層次的et測試或者相關的覆蓋測試，以滿足測試深度。總之就是讓新手做力所能及的事，讓老手做老手應該做的事情。這樣就能儘可能的節省時間。
本文轉自：