1。測試進入時間
項目需求分析完成,用戶需求說明書發布時進入。(需求分析是由PM或者專職人員進行的,用戶需求說明書的編寫也同樣)
2。項目開發設階段
。保╅喿x,理解和分析用戶需求說明書,與PM討論需求模糊,不理解的地方;提煉測試需求和測試內容。(如果你想要認真編寫測試需求,建議在需求update的同時跟蹤修改你的測試需求,測試需求與需求分析關聯,以便后期跟蹤。個人認為測試需求越詳細,對后面的工作指導的作用越大)
。玻└鶕椖坑媱澮约皽y試內容,確定每一個測試階段的工作進度安排。(這個是由PM決定的,相信每個公司都有這樣的計劃,畢竟那么多Build)
。常┚帉測試計劃初稿。(這個一般都是老員工的工作,至少在我們公司PM只做需求和管理)
。矗┚帉測試用例(一般會出一個prototype,根據計劃和需求來編寫)
3。項目編碼階段
。保└鶕浖O計說明書,完成具體的測試計劃。(這個上面已經說了)
。玻└鶕浖O計說明書,完善測試用例。(這個也是比較重要的,如果你不了解軟件的設計,很多內部情況都沒有辦法具體描述出來。所以測試也不是那么容易的……)
。矗┲贫ǖ谝浑A段的測試內容。(相當于一個計劃,測試人員根據測試進度安排)
。担校,開發和測試共同確定第一階段的產品質量。(開會,開會)
4。執行測試階段(前面都是準備,現在才是實際操作~~)
。保模牛停峡蓽y試性的測試。(也就是冒煙測試啦)
。玻﹫绦袦y試用例
。常┚帉缺陷報告(缺陷報告的編寫學問也比較大,這里不討論)
。矗┨顚懝ぷ魅罩荆ㄟ@個是公司規定的……)
。担┨峤划斍半A段的測試報告。(每一個build一個報告,真的累啊……)
。叮┩晟茰y試用例。
。罚校,開發和測試進行當前階段產品的質量評審以及下一階段的測試工作評審。(又要開會啦)
。福┲贫ㄏ乱浑A段的測試內容。(還是開會)
。梗校,開發和測試共同確認下一階段產品的質量標準。(繼續開會)
5。用戶接收階段
。保┲噩F,確認用戶使用時出現的錯誤。
。玻┚帉懹脩羰謨
。常┚帉懝芾韱T手冊
6。運行維護階段
。保┲噩F,確認用戶反饋回來的缺陷
。玻├斫庑滦枨
。常回歸測試(其實回歸測試每一個Build都會做的,放到最后只是覺得一個流程應該是重復的……)
文章來源于領測軟件測試網 http://www.k11sc111.com/