需求分析: 依据公司需要，测试人员可能会参与需求讨论，确定需求的可测试性，测试人员可跟踪需求文档编写进度以便熟悉业务和逻辑需求，待需求分析完毕，测试人员可根据需求拆分结果开始编写测试需求。

设计: 一般来说测试人员是不参与设计评审的，因此在编码开始之前，测试组可开始做一些测试的准备工作，比如确定测试需求，确立测试策略，规划测试阶段等等。

编码: 如果有可能，测试人员可参与配合开发人员的单元测试和代码走查，若上一阶段的设计写得详细，测试人员可根据详细设计文档开始着手编写测试用例的初稿，若设计文档只是概要，只能等开发人员在给出此版本的Demo后进行测试用例的编写，同时在此阶段，测试小组组长开始编写版本测试计划。

测试：完全属于测试组的工作，流程一般是这样的：1.第一轮测试，并提交BUG        2.待开发人员修改BUG完毕后，进行回归测试，回归测试的轮数可根据项目进度和测试退出标准来权衡   3.验证测试，版本发布前的最后一次测试，退出原则必须严格按照测试计划所述，若在版本发布日期还未达到测试退出标准，测试组负责人可立即与PM沟通，确认可否推迟发布，以保证该版本软件的质量。 

验收：在此阶段，意味着软件某一版本的结束，也就是可以交付客户使用，这时测试组要做的就是审视该阶段的工作，组长要提交测试报告，组员总结该阶段的测试经验和教训，以准备下一阶段的测试工作。

在此对上述提到的几个名词进行说明：

测试需求：其实也就是把需求细分的功能点转换成可测试的功能点，可在点子表格或word文档中进行管理，也在测试工具中管理，其中测试工具管理的好处就是，明晰显示测试需求的树状结构，层次分明，可自动生成测试需求覆盖率的统计数据，同时统计结果还可用文字报告和图表的形式呈现，等等。

测试用例：需求的下一步就是用例，而用例的依据就是需求，这里重要的是，如何把需求这样的业务描述转换成具体软件语言的描述，如同将需求转换成设计的问题一样，也可放在excel或word文档中管理，放在工具中管理的最大优点就是可以和需求关联起来，树状结构和需求的树状结构一致，层次明了，同时工具也可以导出到外部文件中，如excel、word、html等格式。最后统计测试用例执行结果时也可以自动产生结果。

测试计划：计划包括的内容大致包括本次测试目标、范围、跨度、人员安排，测试环境说明、测试退出原则，所谓测试退出原则，也就是结束测试的标志，一般来说，测试用例的执行结果、测试需求的覆盖率以及遗留BUG的数量和严重度是衡量是否可以结束本次测试的几个主要标准，当然具体量化的数据必须根据所测试软件版本的功能点多少、项目进度以及客户要求而定。需要说明的是，进行验收测试时，一般来说，如果遗留的轻微BUG数量超过10个或者严重BUG数量超过5个，组长就有理由与PM进行沟通以推迟发布时间。

提交BUG：这里很重要就涉及到缺陷管理，为什么要进行缺陷管理？最根本的就为了跟踪缺陷的解决情况，这对于编码结束后的系统是非常重要的，为了管理缺陷，可以用excel，但个人看来缺陷管理工具更好，无论此工具是B/S还是C/S，（BS可通过浏览器，CS安装客户端）都可以让项目组的相关人员很容易的见证缺陷的解决情况，并及时作出反应，同时还可以随时查看只与自己有关的缺陷信息。这里简单提下严重度和优先级的区别，所谓严重度，就是该缺陷的严重程度，这是与软件版本没有任何关系的，是缺陷本身属性决定的，所谓优先级，是根据项目进度和客户要求来定的，高严重度的缺陷因为暂时无法解决或者需求分析不明确等原因可能会被定为低优先级，遗留到下个版本再解决。总之严重度和优先级不是成正比的。

测试报告：相当于本次测试阶段结束后的一个总结，主要包括测试人员工作情况，测试用例执行结果，测试需求覆盖率，遗留缺陷数量、严重度以及缺陷其他信息，测试组建议和是否通过本次测试，等等。