系统测试的参与时机有讲究

测试按照阶段可分为三类：单元测试、集成测试、系统测试。软件行业中，我们作为测试人员接触最多的应该是系统测试。单元测试和集成测试在代码编写阶段就可以由开发人员自行完成，或者由专门测试人员来完成测试。但由于有些公司不太重视这两个阶段测试人员的配备，或者难以找到合适的测试人员，系统测试人员的参与时机就显得格外讲究。

 

一般而言，系统测试人员大多不太精通编程语言，所以系统测试人员能介入单元测试的可能性几乎为0，介入集成测试的可能性是有的，但也非常有限。为了弥补这些缺陷，很多公司采取迭代式的开发模型，边开发边测试，每开发一个新特性就走一遍开发流程，所有新特性完成后再进行一次完整的回归测试。这时候，系统测试人员就需要尽早参与到开发流程，只有这样才可以保证软件开发不偏离基线，软件质量得以保障。

 

一，系统需求评审时，测试要参与进来。一两个资深的测试人员的参与可以使需求文档的编写更加符合规范，需求更加明确。这为后面测试案例的编写确定大的范围。使测试人员对新特性有了初步理解；

 

二，系统进行总体设计时，各个特性会被细化成各个模块，具体的设计规格也随之形成，各个模块的关系也逐渐明确。测试人员通过参与评审，可以进一步明确设计规格，消除模糊地带；对于一时还不能明确的部分，进行记录并在后面合适时机进行明确。

 

三，开发人员编写代码时，测试人员也进入用例的编写。这个时候测试人员既要完成用例设计，又要完成单个特性的测试，工作量较大，时间也不会太长。但也有个好处，可以边测试边写用例，不但可以尽可能地完善测试用例，还可以发现很多设计缺陷。

 

三，新特性测试完毕，一般在流程上都会进入一个新的里程碑，各个公司的叫法各异。到了这个阶段便可以进入大规模的回归测试，而这个时候测试用例也已经比较完善，代码设计也基本完成，剩余的工作就是修改代码。

 

看到优势了吗？这中并发的工作流程，体现出来的不仅是效率，更多的是“协作”。协作是项目运行成功的基础。一个项目中，不同团队完成了高频沟通，代码质量从头到尾都受到了监督和测试，如果组织得当，产品的保质、准时交付并不难。