软件测试流程改进的几点看法

　　一、完善需求，并对需求做评审

　　原先项目的需求文档很不健全，而且更新也不及时。拿起需求看的时候，可能软件本身已经调整了n次，可是需求本身一次都没有更新。这就致使需求与实现完全脱节，测试人员无法根据需求来编写相应的测试文档。而为了应对迎头压来的工作任务，只有放弃文档，摸着石头过河。一切都凭借测试人员的经验及对业务知识的领悟来进行测试。这样做虽然解了燃眉之急，但是，当测试人员流动的时候，新加入的成员又需要很长一段时间来熟悉、摸索软件的业务功能点。无论对于公司，还是项目本身进度来说这都是不可接受的。要解决文档的问题，首先就得从源头抓起。为此，项目经理从需求开始抓起：要求提供完善的需求，并在需求完成之后进行评审。目的就是希望可以把设计缺陷消灭在需求阶段，省去很多不必要的麻烦评审会主要由项目经理主持，测试部全体成员负责评审，系统分析员负责解答相关问题。评审结束后，与会者提交相关的需求评审记录。根据需求评审记录，系统分析员进行相应的更新。

　　二、编写测试大纲，并对大纲进行评审

　　在需求更新后，测试设计人员提取相应的测试点，编写测试大纲。采取这样的流程主要是为了避免设计人员在设计之初就过分专注于细节，而忽略整体。设计人员可以在充分理解需求的基础上，提取测试点。理想状态下，就是测试大纲完全覆盖所有需求。

　　为了避免测试设计人员在设计上有所疏漏，在大纲完成之后，会再次召开评审会。大纲评审其实是同行评审，由测试人员共同参加，并针对各个测试点逐一探讨。评审后，提交相应的大纲评审记录，相关的测试人员对大纲进行修订。