第二篇

现在发现，之前公司的流程是很规范。从测试介入的时间到测试的完成都是在外面的公司鲜有的。

1.项目立项——这个具体的工作是什么自己也不太清楚，只知道项目可以进行了。有项目资料调拨单，虽然在实际操作中可能是后补的，但是基本上控制了测试过程中需要的文件。如果发现文件不全测试就不能进行，最关键还是需求文档和实际文档，有时还有用户手册，客户自己的测试需求、测试计划、测试报告。

2.文档审查——就是把开发提供的齐全的文档进行检查，比如是否按模板，格式、有没有错别字，章节号是否正确，上下内容是否一致，还有相关文档的关联信息是否一致，也可以说是文文是否一致，文本一致。

3.代码审查——分为个人审查和会议审查，流程和功能实现上参照的时需求文档和设计文档，如有不一致应该及时记录，并派出是代码原因还是文档原因。再就是对编程语言的语句进行走差，这里可以借助一些工具，对于像if else、switch case default等得缺失进行提取，可以减轻测试人员的工作量。第一轮代码审查后提交代码缺陷，并进行一轮回归，然后出代码审查报告。一般情况下，经过人工代码审查可发现很多问题

4.测试计划\测试需求（测试大纲）——这个需要进行评审，制定详细的计划，限制各个阶段任务完成的时间，并对测试人员的职责进行详细的区分，还有测试过程中可能会遇见的风险进行分析。测试需求（测试大纲）——测试人员根据开发方提供的需求文档和设计文档（用户手册）收集测试点，以一种比较笼统的方式进行记录，一方面可以减少测试人员工作量，另一方面也为后续测试用例的设计提供了依据。

5.测试报告——当当当当，附件就是测试用例啦，软件缺陷啊，缺陷修正啊

6.回归测试报告——进行回归以后当然要出回归测试报告啦！要记记录新添的用例，删除的用例，修改的用例，以及相关模块已有的用例

7.测试报告评审，出评审意见啦！如果评审过不去，sorry，换个组，重新开始吧。不过一般是不会通不过的。