【原创】6年测试经验,总结一下我心中的开发流程
生活随笔
收集整理的這篇文章主要介紹了
【原创】6年测试经验,总结一下我心中的开发流程
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
前言: 本篇文章更適用于敏捷開發的團隊,如有不足,歡迎探討。 測試工作不僅僅要從產品的角度去保證產品質量,還要完善研發流程,就像一條流水線工作,每個環節都不能出錯,才能生產出優質的產品。 本文所指開發周期15工作日左右,測試時間5天左右。 主要流程: 一、需求評審 由產品經理發起,參會人:產品經理、項目經理、開發、測試,如有需要,提出需求方,如業務人員、運營人員也可參與。產品經理講解產品設計,主要包含用戶場景、業務流程、頁面設計、交互設計等。建議遵循互聯網人人都是產品經理的理念,每個人提出自己認為最好的實現方式,但最終還是由產品經理定義。 (1)開發同事要從技術角度、和現有框架支撐情況評估各個功能是否可以實現,如不能實現,要與產品溝通折中方案。若產品一定要實現該功能,開發要給出時間,也就是開發成本。 (2)測試同事相對更了解整個系統的業務邏輯,要判斷每個功能的實現,是否與系統整體的使用習慣匹配,若差異較大,要提醒產品經理,否則會讓用戶覺得系統邏輯混亂,使用困難。同時思考每個功能點的測試方法,如需要開發協助的,也要及時提出,讓開發做好后門,如果有測試點評審流程,也可以在測試點評審時提出。 (3)業務、運營人員要確定產品設計是否符合需求,并認真學習產品的使用。 評審過程中,產品經理記錄要修改的地方,會后第一時間修改(建議當天完成),然后發出需求郵件,進入開發階段。 二、測試點編寫(開發階段) 該階段分為兩個部分,測試點編寫和測試開發。 測試點編寫和開發并行,個人建議不需要寫詳細的測試用例,測試點和測試用例的取舍,可另行探討。測試點編寫同時,要及時與產品溝通,有修改的地方,第一時間同步到開發。 測試點應包含: (1)本次新增、修改功能點。 (2)可能影響到的功能的回歸 (3)系統重要功能回歸 如果有需要的話,進行測試點評審,且要至少在提測前2天進行,由測試人員發起,給開發人員緩沖的時間,產品、項目經理、開發、測試參與,測試點評審重點要強調流程、異常處理、測試方法等,一定確保大家對產品的理解沒有偏差。測試人員記錄要修改的地方,會后第一時間修改(建議當天完成),然后發出測試點郵件。 測試開發部分,根據項目實際情況安排工作,如自動化用例的持續集成、mock系統的開發等,個人認為這些很重要,是提高測試從業者個人能力的重要環節。 三、提測 提測要求開發方滿足一定要求,要求可酌情而定。但至少要做到本次迭代的主要功能在測試環境可跑通,如果提測不通過,開發加班修改,當天知道滿足提測要求為止。避免開發擠壓測試時間的情況發生。 四、測試階段 通常分為三輪: (1)第一輪,產品可滿足用戶場景,且主要流程可通。 (2)第二輪,進行異常操作、兼容性等測試。 (3)第三輪,功能回歸。 如果測試人員在2人以上,建議進行交叉測試。 測試階段可以對bug修復做一些要求,如: (1)提交bug后,開發做出響應,比如在bug管理系統中,bug狀態處于處理中,若10分鐘內沒響應,測試人員應提醒一下。 (2)對bug修復做出時間要求,如當天某個時間點之前提出的bug,今天必須修復完成。時間點可根據具體情況定,我們是下午4點。 對于封版要求,各不相同,比如bug修復率達到95%以上;代碼覆蓋率100%等等,本人更傾向于x小時內沒有嚴重問題產生才可以封版。封版前的多半都是回歸測試、冒煙測試階段,若此刻還有嚴重問題產生,證明第一輪、第二輪測試不充分,或者開發修復bug時未考慮周全,引出其他bug。針對封板要求,希望可以和大家討論一下,各取所長。如果未滿足封板要求,但項目要求必須上線,則需要將風險體現到測試報告中。 封版前(可以是當天下午),建議不修復bug,產品、項目經理、測試人員一起評估,若一定要修復的,要謹慎修復并驗證,不修復的遺留到下一期處理。 五、封版、上線 封版和上線對于測試來說沒什么區別,最重要的是發布包不能變更,至于上線與否,根據公司情況而定,本人公司測試完成僅封版,上線時間由產品和開發決定,上線后通知測試,在正式環境驗證功能是否正常。 此時需要發測試報告,應包含內容: (1)結論:如測試通過、不通過(原因) (2)工時:人/時 (3)bug統計 (4)存在風險 (5)附件:發布包 六、項目總結 由項目經理發起,總結本次迭代中存在的問題及改進措施。也可以收集在團隊協作中,各個角色間是否對他人不滿意,并進行疏導或改進。 總結: 還有兩個本人認為很重要的流程沒有加進來,開發代碼review和功能驗收。對于大多數敏捷團隊,因為各種原因,這兩個流程都會被省去。代碼review應該加到提測前,益處多多,不贅述。功能驗收,應該由需求提出方和產品功能驗收,以確保產品滿足需求,但此階段如果出問題,對整個項目來說都是致命的,即使功能上有出入,產品被打回的幾率還是很低,所以驗收流程對于敏捷開發似乎存在的意義不大。 會議發起者或項目經理要適當控制會議節奏,避免話題無限延伸的情況,做無意義的討論,浪費時間。 項目經理要將每個階段,至少精確到天,當天差一丟丟能完成,就要加班,如果差很多,就要延期,并有明確的延期原因。 工欲善其事,必先利其器,本人更注重提測前的準備工作,如需求評審、測試點編寫、測試點評審階段,統一思想,明確產品方向,準備測試數據,保證測試方法可行,后期的工作會更順利。 任何流程的制定,可能最終都會變成“道理我們都懂,但實踐起來困難重重”,本人覺得我們至少要總結出一套高效、完善的工作流程,即使不能完整的執行,但也要朝著正確的方向不懈的努力。
歡迎大家加入社群,交流經驗。
VIPTEST社群(簡稱V社)是由一群熱心的測試行業志愿者自發組織形成的開放性測試同業聯盟。
種下一棵樹最好的時間是十年前,如果錯過就是現在。
轉載于:https://www.cnblogs.com/goldsking/p/9341719.html
總結
以上是生活随笔為你收集整理的【原创】6年测试经验,总结一下我心中的开发流程的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: a标签操作
- 下一篇: hibernate框架学习第二天:核心A