在传统的软件行业中，每一个版本的迭代周期少则半年，多则几年。一个版本中如此多的功能最终发布，测试是如何进行质量的保障的呢，我将以我经历的一个项目版本为案例，讲述这个过程中的测试流程。
我们常说测试要尽早的介入到项目中去，从需求开始测试。在这个项目中，需求的测试，我们这边是针对每一个需求单的评审，具体负责该单据的测试人员都要求做需求评审的问题记录跟踪表，要求需求评审中要提出对于该需求单的疑问，不合理的地方要求指出来，在评审会议后要发布需求评审问题记录表给参与该单据的评审人员，并附上结果是否评审通过，还是需要再次评审。
需求文档评审通过后，需求单会入到需求池，并指定该需求单的期望版本号。然后会生成待设计任务单，设计人员在设计了该需求单后，会召开设计评审会议，这时测试也要参与到设计评审，对该设计单的每一个表结构，数据设计流向要清晰，遇到问题也要当场指出。此时的设计问题评审记录由具体负责该单据的开发人员填写并发布。
在设计单评审通过后，会生成待开发任务单，此时开发进行该单据的开发；测试现在就是依据之前的评审通过的需求文档、设计文档作为输入进行测试设计。我们再做测试设计的时候，会设计两类的测试用例，一类是功能测试用例，另一类是业务场景测试用例。而功能的测试用例，我们往往是先通过思维导图将功能点进行拆分，形成一颗功能树，然后按照测试设计方法进行功能的测试用例设计并填入到用例模板中，我们设计用例要求每一个设计到页面展示的结果数据都要自己预先写好sql语句，这么做的目的是一方面检验自己对于该单据的数据流向是否清晰，另一方面也便于在测试执行时，方面我们快速执行。业务场景的测试用例我们是首先要求用visio画出流程图，然后根据预定义的输入不同展开不同的流程场景设计。
用例设计完成后，我们会根据需求单的复杂度，来决定是进行会议评审还是会签评审，会议评审往往会整个测试组都参与，并邀请需求单的负责人、设计单负责人和开发负责人，逐条的对我们的测试用例进行评审；而会签评审则是通过邮件的方式发送给上述成员，成员通过本地评审并给予邮件回复。在用例评审通过后，我们会将用例上传到SVN进行备份。
当开发完成了该单据的开发后，此时是需求人员会在开发的机器上验收这个单据，需求验收的角度主要是该需求单的业务逻辑和UI表现正确，不检查数据的正确性。需求验收通过后，会转入到测试执行，然后我们依据评审通过的测试用例进行执行，并提相应的缺陷单。在该单据所有的缺陷单回归测试完成后关闭后，这一个需求单的功能测试也就结束了。