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

　　從去年秋冬季節來到這個地方，直至明天正式離開，提及來也在這個霸氣威武的bd大廈呆了挺久的一段時間了。 　　與周圍的那些rd、qa、pm等相處下來雖然不至於說是親如一家，但至少也算是有點感情了，因此在這裏對以前工做中的一些基礎測試流程和人員方面的東西作一個總結，以此來記念我在大廈的日子。———題記 　　初到大廈拿到第一份testcase的時候，個人第一感受是意外；第二感受是懵；第三感受是雲裏霧裏的繞啊繞，也繞不出一個結果來。 　　當時的那份testcase，說實話，真心看不懂，尤爲是對於我一個剛過來工做，需求業務都尚未一點點印象的人來講。一條case中能夠有多個等價 類、能夠有多個組合，預期結果中能夠有多個操做步驟混合預期結果；而且沒有相關的業務操做步驟來講明如何作，而且總體case模塊有十幾個，可是找下去很 多模塊又彷佛不是咱們要測試的，當時我就震驚了，而且個人小夥伴們也震驚了。 　　關於testcase，大部分公司都有本身的一套標準來約束如何寫，如何劃分功能模塊和優先級。可是無論怎麼劃分，如下這幾點老是不能變的。 　　必須具備較強的可讀性、可操做性；這個的標準就是你直接拉一個對這個項目需求和業務徹底不懂的人過來照着你的case可以執行下去，不會有太多誤差和卡殼的地方。 　　儘可能從用戶視角出發去寫case，只有當用戶視角不能覆蓋以後才考慮採用代碼邏輯去描述；這一點能夠保證你所寫出的case可以被更多的人順利執行，畢竟case不是一我的的case，他是全部參與進測試的同窗們都必需要看的。 　　必須具備比較清晰明確的層級分佈關係；不少項目都沒有足夠的時間讓你過徹底部的case，而且不少時候版本改動的地方並不須要執行所有的case，這時候良好的分級關係case就可以更合理有效的完成功能測試和覆蓋測試。 　　case分級要合理。若是不合理，在過case的時候相信不少人都會有種想死的感受：多了本身累的要死，可是感受沒什麼用；少了本身內心又沒底。在這裏簡單套用個之前江姐老大的分級依據：P0、P一、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測試或者相關的覆蓋測試，以知足測試深度。總之就是讓新手作力所能及的事，讓老手作老手應該作的事情。這樣就能儘量的節省時間。