小白们需知的测试流程

首先，你需要知道的是，项目立项开始，是否有《需求说明文档》（也就是《需求说明书》）？

如果有，那么前期以此为准开展评审，再审以及最终确认。

由于需求评审阶段各个部门及人员所采集的信息不同，但最终都必须达成一致，如果需求确认后，不同部门的工作内容也就明确，开发来说主要确定开发语言，数据库，同时需要输出概要设计和详细设计文档（包括功能的概述，逻辑的整理，建模等），一般服务器等配置这个阶段也可以开始着手做，产品需要根据需求设计原型图及demo。 测试在此阶段需要做的就是确认需求是否都是明确的，是否都是可测的，逻辑是否都是合理的等等，应及时反馈需求中存在缺陷，作为测试负责人需要做的就是工作的记录用时多少个工作日，都干了什么？得到什么结果？是否有遗漏？组员是否都参与？是否对过程中的输出项已经熟悉并认同等等。 在公司大流程以及部门规范前提下，当前的工作是否已经可以结束并进入下一阶段？和其他部门是否达成共识？ 有不明确项要及时发起会议，会议过程中要做好会议记录，会议结束发送参会人员确认，同时明确分工，截止时间等，目前公司是team leader和主管去，谁去无所谓，重要的信息的共享和及时传达，人家带你就去，不带就算了，他们得给你详细文档，如果没有文档的话，就功能点细节你得多交流。

刚才说那么多等到该确认的都已确认，作为负责人来说接下来就该准备测试计划了，编写出完整的测试计划，有测试覆盖面，人员安排，工作评估，异常事件处理，结果总结，文档交付，组织评审及最终确认，测试人员就按着测试负责人的计划来进行工作，测试用例的编写（一般都有模版），测试环境的准备，缺陷管理规范和缺陷工具等，理论上用例也需要发起会议评审，分内部和外部直到最终确认，以上都是你有了《需求说明文档》之后，以此为基准开展的前期的测试准备工作，也就是未接到测试版本之前需要做的，理论上测试计划不怎么可靠，因为过程中发生什么谁也无法预料，但是好的计划前期的确可以说明一些事，无非就是设备调用，人员安排，测试覆盖面和深度以及一些特殊情况说明，切记所有的信息的传递及确认一切以邮件为准，为了避免日后的麻烦千万不要认同口头答复。

接下来就是接收版本开始测试，这时候前阶段的准备就可以发挥作用了。

作为测试负责人，接收测试版本后可以安排测试，首先就是冒烟测试，验证当前版本是否满足后续测试，满足则发邮件说明，不满足也同样发邮件说明并打回该版本，这个过程基本是已经规范好的，没什么特别说明。

说完有《需求说明文档》的公司，下面说没有《需求说明文档》的公司

目前大多数公司都这样，在这类公司工作说白了就是干活，别跟人家提流程、文档和规范，人家要么不了解、要么压根就不知道，第一，时间不允许，没空搞那些，既然答应多久能给出产品，那么为了能在相应的时间内完成产品，一般情况下需求人员也是刚弄明白需求，就召集开发人员进行口头讲解，然后开发人员就直接进行开发，若在开发中有不明确的，就再来问需求人员，边开发便询问需求人员；第二，怕麻烦，几句话能讲清楚的事何必麻烦的进行文档的编辑，万一需求变动大，那岂不是三天两头进行需求文档的编辑，需求变动大又能怎样，这时候需求人员又从新讲解，开发人员又接着从新编写代码；第三，老板及管理层只看结果，测试的存在性极低，存在也是为别的部门背锅。以上的情况决定了测试获取信息的不全面，受阻，这样的情况可能大多数人会选择离职或者破罐子破摔，每种环境的存在都有其合理性，当然这样的环境也可以锻炼人，为了自保，工作还得认真的做，他们乱自己不能乱，信息获取不全面可以直接去问，不要怕麻烦，沟通也要有技巧，不要撕破脸（也可以撕破脸，那就是你准备要离开的时候）。有测试任务，先确认任务的目的，内容以及异常情况，一切搞清楚发邮件，来编写测试计划，说明测试时长，测试覆盖范围，异常因素影响测试的等等。