1、測試工作準備

測試負責人在軟件項目的需求階段開(kāi)始介入，逐步深入了解該項目的需求、設計過(guò)程，從而有針對性的編制測試計劃和測試大綱（測試方案、測試用例）。

2、測試計劃的制定

測試計劃的制定要與項目開(kāi)發(fā)的總體計劃相吻合；測試計劃中要充分考慮資源計劃（人員安排，設備分配、與其它部門(mén)的協(xié)調配合以及其它不確定的因素）等；測試計劃的制定還要考慮測試版本計劃，與開(kāi)發(fā)協(xié)調，按照版本生成計劃（多長(cháng)時(shí)間出一個(gè)版本），制定測試計劃

3、時(shí)間節點(diǎn)的控制（與開(kāi)發(fā)協(xié)調控制）

提測的時(shí)間是否在規定的時(shí)間內，如果未按照計劃的時(shí)間提測，則需要分析是否會(huì )對項目造成影響，會(huì )不會(huì )存在風(fēng)險。在計劃的時(shí)間內，保證測試用例全跑一遍，如果未按預計時(shí)間將所有的用例走一遍，則需分析原因。

4、需要評審

策劃完成的需求文檔必須讓開(kāi)發(fā)、測試、運營(yíng)進(jìn)行評審，提出異議意見(jiàn)并最終改掉。這種評審能發(fā)現需求的漏洞并提早改掉，提高整個(gè)研發(fā)過(guò)程的效率

5、用例評審

測試人員針對需求寫(xiě)出粗略的用例之后，讓產(chǎn)品、開(kāi)發(fā)、測試、運營(yíng)評審一遍、目的是發(fā)現需求的遺漏點(diǎn)，根據我們的經(jīng)驗，由于測試人員已經(jīng)思考了測試點(diǎn)，所以相當于是對需求的細化和剖析，這個(gè)評審環(huán)節還是能發(fā)現很多需求的漏洞。

6、開(kāi)發(fā)提測

測試人員事先發(fā)出冒煙測試用例，開(kāi)發(fā)完成后，讓開(kāi)發(fā)人員先根據冒煙用例進(jìn)行自測，自測通過(guò)了以后才提交給測試，然后測試再根據相同的用例做冒煙測試。這樣能提高開(kāi)發(fā)提測的質(zhì)量。

7、測試反饋

將測試中發(fā)現的Bug反饋給該項目負責人，由負責人對該Bug進(jìn)行定位，并由響應的開(kāi)發(fā)人員進(jìn)行修改，如果測試人員發(fā)送的Bug并非該測試模塊的Bug，由該負責人轉發(fā)給相應的負責人，并指派給對應開(kāi)發(fā)人員修改。測試結束后，測試過(guò)程中發(fā)現的所有Bug，都應將其統計匯總，標識出當前狀態(tài)，其中經(jīng)過(guò)再次測試已經(jīng)關(guān)閉的不在說(shuō)明，其它所有未關(guān)閉的均應說(shuō)明理由，并與開(kāi)發(fā)部門(mén)討論，由技術(shù)負責人給出結論（是否解決或延期解決），并要經(jīng)過(guò)技術(shù)副總審批。

8、測試分析

測試完畢，整理測試文檔，需要讓測試人員發(fā)一份測試報告，重點(diǎn)指出測試過(guò)程中發(fā)現的問(wèn)題，以及上線(xiàn)以后可能會(huì )出的質(zhì)量問(wèn)題，并說(shuō)明告知這些風(fēng)險，如果有因為時(shí)間不足，或者因為客觀(guān)條件限制導致測試不足的情況，一定要在這個(gè)環(huán)節說(shuō)明，這樣，如果上線(xiàn)以后出現問(wèn)題，大家也能理解測試

9、質(zhì)量目標

通過(guò)測試管理工作的加強，力求在測試階段盡可能多的發(fā)現軟件錯誤與缺陷，盡可能少的將問(wèn)題帶給用戶(hù)，確保軟件的質(zhì)量及其可靠性，提高用戶(hù)滿(mǎn)意程度，使作為質(zhì)量管理中心的質(zhì)量管理部真正的把好產(chǎn)品的質(zhì)量關(guān)，盡量在測試階段發(fā)現軟件錯誤和軟件缺陷。

10、線(xiàn)上問(wèn)題

對于線(xiàn)上發(fā)現的Bug，先重點(diǎn)分析這個(gè)線(xiàn)上Bug產(chǎn)生的原因、線(xiàn)上Bug的影響范圍，然后大家一起決定可以有哪些改進(jìn)措施可以避免同類(lèi)線(xiàn)上Bug再犯。這種改進(jìn)措施需要能真正落實(shí)的，如果是可有可無(wú)的改進(jìn)措施，就不要提了。這個(gè)措施可以讓大家一起剖析線(xiàn)上Bug的產(chǎn)生原因，一方面可以避免項目組認為都是測試的錯導致線(xiàn)上Bug，一方面，也發(fā)揮了測試人員質(zhì)量保證的角色，推動(dòng)流程讓質(zhì)量更好。