前言： 本篇文章更適用于敏捷開發(fā)的團(tuán)隊，如有不足，歡迎探討。 測試工作不僅僅要從產(chǎn)品的角度去保證產(chǎn)品質(zhì)量，還要完善研發(fā)流程，就像一條流水線工作，每個環(huán)節(jié)都不能出錯，才能生產(chǎn)出優(yōu)質(zhì)的產(chǎn)品。 本文所指開發(fā)周期15工作日左右，測試時間5天左右。 主要流程：

一、需求評審 由產(chǎn)品經(jīng)理發(fā)起，參會人：產(chǎn)品經(jīng)理、項目經(jīng)理、開發(fā)、測試，如有需要，提出需求方，如業(yè)務(wù)人員、運(yùn)營人員也可參與。產(chǎn)品經(jīng)理講解產(chǎn)品設(shè)計，主要包含用戶場景、業(yè)務(wù)流程、頁面設(shè)計、交互設(shè)計等。建議遵循互聯(lián)網(wǎng)人人都是產(chǎn)品經(jīng)理的理念，每個人提出自己認(rèn)為最好的實(shí)現(xiàn)方式，但最終還是由產(chǎn)品經(jīng)理定義。 （1）開發(fā)同事要從技術(shù)角度、和現(xiàn)有框架支撐情況評估各個功能是否可以實(shí)現(xiàn)，如不能實(shí)現(xiàn)，要與產(chǎn)品溝通折中方案。若產(chǎn)品一定要實(shí)現(xiàn)該功能，開發(fā)要給出時間，也就是開發(fā)成本。 （2）測試同事相對更了解整個系統(tǒng)的業(yè)務(wù)邏輯，要判斷每個功能的實(shí)現(xiàn)，是否與系統(tǒng)整體的使用習(xí)慣匹配，若差異較大，要提醒產(chǎn)品經(jīng)理，否則會讓用戶覺得系統(tǒng)邏輯混亂，使用困難。同時思考每個功能點(diǎn)的測試方法，如需要開發(fā)協(xié)助的，也要及時提出，讓開發(fā)做好后門，如果有測試點(diǎn)評審流程，也可以在測試點(diǎn)評審時提出。 （3）業(yè)務(wù)、運(yùn)營人員要確定產(chǎn)品設(shè)計是否符合需求，并認(rèn)真學(xué)習(xí)產(chǎn)品的使用。 評審過程中，產(chǎn)品經(jīng)理記錄要修改的地方，會后第一時間修改（建議當(dāng)天完成），然后發(fā)出需求郵件，進(jìn)入開發(fā)階段。 二、測試點(diǎn)編寫（開發(fā)階段） 該階段分為兩個部分，測試點(diǎn)編寫和測試開發(fā)。 測試點(diǎn)編寫和開發(fā)并行，個人建議不需要寫詳細(xì)的測試用例，測試點(diǎn)和測試用例的取舍，可另行探討。測試點(diǎn)編寫同時，要及時與產(chǎn)品溝通，有修改的地方，第一時間同步到開發(fā)。 測試點(diǎn)應(yīng)包含： （1）本次新增、修改功能點(diǎn)。 （2）可能影響到的功能的回歸 （3）系統(tǒng)重要功能回歸 如果有需要的話，進(jìn)行測試點(diǎn)評審，且要至少在提測前2天進(jìn)行，由測試人員發(fā)起，給開發(fā)人員緩沖的時間，產(chǎn)品、項目經(jīng)理、開發(fā)、測試參與，測試點(diǎn)評審重點(diǎn)要強(qiáng)調(diào)流程、異常處理、測試方法等，一定確保大家對產(chǎn)品的理解沒有偏差。測試人員記錄要修改的地方，會后第一時間修改（建議當(dāng)天完成），然后發(fā)出測試點(diǎn)郵件。 測試開發(fā)部分，根據(jù)項目實(shí)際情況安排工作，如自動化用例的持續(xù)集成、mock系統(tǒng)的開發(fā)等，個人認(rèn)為這些很重要，是提高測試從業(yè)者個人能力的重要環(huán)節(jié)。 三、提測 提測要求開發(fā)方滿足一定要求，要求可酌情而定。但至少要做到本次迭代的主要功能在測試環(huán)境可跑通，如果提測不通過，開發(fā)加班修改，當(dāng)天知道滿足提測要求為止。避免開發(fā)擠壓測試時間的情況發(fā)生。 四、測試階段 通常分為三輪： （1）第一輪，產(chǎn)品可滿足用戶場景，且主要流程可通。 （2）第二輪，進(jìn)行異常操作、兼容性等測試。 （3）第三輪，功能回歸。 如果測試人員在2人以上，建議進(jìn)行交叉測試。 測試階段可以對bug修復(fù)做一些要求，如： （1）提交bug后，開發(fā)做出響應(yīng)，比如在bug管理系統(tǒng)中，bug狀態(tài)處于處理中，若10分鐘內(nèi)沒響應(yīng)，測試人員應(yīng)提醒一下。 （2）對bug修復(fù)做出時間要求，如當(dāng)天某個時間點(diǎn)之前提出的bug，今天必須修復(fù)完成。時間點(diǎn)可根據(jù)具體情況定，我們是下午4點(diǎn)。 對于封版要求，各不相同，比如bug修復(fù)率達(dá)到95%以上；代碼覆蓋率100%等等，本人更傾向于x小時內(nèi)沒有嚴(yán)重問題產(chǎn)生才可以封版。封版前的多半都是回歸測試、冒煙測試階段，若此刻還有嚴(yán)重問題產(chǎn)生，證明第一輪、第二輪測試不充分，或者開發(fā)修復(fù)bug時未考慮周全，引出其他bug。針對封板要求，希望可以和大家討論一下，各取所長。如果未滿足封板要求，但項目要求必須上線，則需要將風(fēng)險體現(xiàn)到測試報告中。 封版前（可以是當(dāng)天下午），建議不修復(fù)bug，產(chǎn)品、項目經(jīng)理、測試人員一起評估，若一定要修復(fù)的，要謹(jǐn)慎修復(fù)并驗證，不修復(fù)的遺留到下一期處理。 五、封版、上線 封版和上線對于測試來說沒什么區(qū)別，最重要的是發(fā)布包不能變更，至于上線與否，根據(jù)公司情況而定，本人公司測試完成僅封版，上線時間由產(chǎn)品和開發(fā)決定，上線后通知測試，在正式環(huán)境驗證功能是否正常。 此時需要發(fā)測試報告，應(yīng)包含內(nèi)容： （1）結(jié)論：如測試通過、不通過（原因） （2）工時：人/時 （3）bug統(tǒng)計 （4）存在風(fēng)險 （5）附件：發(fā)布包 六、項目總結(jié) 由項目經(jīng)理發(fā)起，總結(jié)本次迭代中存在的問題及改進(jìn)措施。也可以收集在團(tuán)隊協(xié)作中，各個角色間是否對他人不滿意，并進(jìn)行疏導(dǎo)或改進(jìn)。 總結(jié)： 還有兩個本人認(rèn)為很重要的流程沒有加進(jìn)來，開發(fā)代碼review和功能驗收。對于大多數(shù)敏捷團(tuán)隊，因為各種原因，這兩個流程都會被省去。代碼review應(yīng)該加到提測前，益處多多，不贅述。功能驗收，應(yīng)該由需求提出方和產(chǎn)品功能驗收，以確保產(chǎn)品滿足需求，但此階段如果出問題，對整個項目來說都是致命的，即使功能上有出入，產(chǎn)品被打回的幾率還是很低，所以驗收流程對于敏捷開發(fā)似乎存在的意義不大。 會議發(fā)起者或項目經(jīng)理要適當(dāng)控制會議節(jié)奏，避免話題無限延伸的情況，做無意義的討論，浪費(fèi)時間。 項目經(jīng)理要將每個階段，至少精確到天，當(dāng)天差一丟丟能完成，就要加班，如果差很多，就要延期，并有明確的延期原因。 工欲善其事，必先利其器，本人更注重提測前的準(zhǔn)備工作，如需求評審、測試點(diǎn)編寫、測試點(diǎn)評審階段，統(tǒng)一思想，明確產(chǎn)品方向，準(zhǔn)備測試數(shù)據(jù)，保證測試方法可行，后期的工作會更順利。 任何流程的制定，可能最終都會變成“道理我們都懂，但實(shí)踐起來困難重重”，本人覺得我們至少要總結(jié)出一套高效、完善的工作流程，即使不能完整的執(zhí)行，但也要朝著正確的方向不懈的努力。

歡迎大家加入社群，交流經(jīng)驗。

VIPTEST社群（簡稱V社）是由一群熱心的測試行業(yè)志愿者自發(fā)組織形成的開放性測試同業(yè)聯(lián)盟。

掃上方二維碼，或加微信wangxin20317（本人）

種下一棵樹最好的時間是十年前，如果錯過就是現(xiàn)在。

轉(zhuǎn)載于:https://www.cnblogs.com/goldsking/p/9341719.html

總結(jié)

以上是生活随笔為你收集整理的【原创】6年测试经验，总结一下我心中的开发流程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。