一、完善需求，并对需求做评审
原先项目的需求文档很不健全，而且更新也不及时。拿起需求看的时候，可能软件本身已经调整了n次，可是需求本身一次都没有更新。这就致使需求与实现完全脱节，测试人员无法根据需求来编写相应的测试文档。而为了应对迎头压来的工作任务，只有放弃文档，摸着石头过河。一切都凭借测试人员的经验及对业务知识的领悟来进行测试。这样做虽然解了燃眉之急，但是，当测试人员流动的时候，新加入的成员又需要很长一段时间来熟悉、摸索软件的业务功能点。无论对于公司，还是项目本身进度来说这都是不可接受的。要解决文档的问题，首先就得从源头抓起。为此，项目经理从需求开始抓起：要求提供完善的需求，并在需求完成之后进行评审。目的就是希望可以把设计缺陷消灭在需求阶段，省去很多不必要的麻烦评审会主要由项目经理主持，测试部全体成员负责评审，系统分析员负责解答相关问题。评审结束后，与会者提交相关的需求评审记录。根据需求评审记录，系统分析员进行相应的更新。
二、编写测试大纲，并对大纲进行评审
在需求更新后，测试设计人员提取相应的测试点，编写测试大纲。采取这样的流程主要是为了避免设计人员在设计之初就过分专注于细节，而忽略整体。设计人员可以在充分理解需求的基础上，提取测试点。理想状态下，就是测试大纲完全覆盖所有需求。
为了避免测试设计人员在设计上有所疏漏，在大纲完成之后，会再次召开评审会。大纲评审其实是同行评审，由测试人员共同参加，并针对各个测试点逐一探讨。评审后，提交相应的大纲评审记录，相关的测试人员对大纲进行修订。
?
编辑切换为居中 三、编写测试用例
根据修订后的测试大纲，测试设计人员开始设计测试用例。由于已经对需求进行了充分了解并提取了相应的测试点，测试用例设计起来相对容易且不易丢掉测试点。虽然用例设计很重要，但是由于时间因素不能进行同行评审。仅由测试执行人员参照大纲查找是否有遗漏的测试点。
四、执行测试，并提交缺陷
根据测试用例，测试人员执行测试。并根据内部缺陷标准判定并提交缺陷。开发开发对open的缺陷如无异议，则进行定位、修改;如果出现分歧，则召开缺陷评审会，由缺陷评审委员会确认该缺陷是否合理。
可以说这个测试流程能够执行下来，离不开公司领导的支持。但是，有好的流程，并不意味着就一定能取得好的工作效果。现在简单总结一下，有以下几点不足之处：
对于测试用例方面：
首先，遗漏部分测试点。虽然测试执行人员对用例进行检查，但是仍然出现测试点未覆盖的现象。其次，测试用例设计不够严谨，甚至出现错误的预期结果。其中有一部分原因是时间的问题，来不及进行检查。但是，毋庸置疑测试设计人员的责任占主要地位。作为一名测试人员，无论文档设计得如何，起码不能出现这样的失误。最后，就是书写不够仔细，错字、误用数据出现。
对于测试执行方面：
首先，测试执行人员未遵循用例进行测试执行。一部分原因是由于用例本身质量不高，可执行性欠佳;另一部分原因是测试执行人员对用例的不信任——部分可以归结为用例质量导致的问题，部分原因是对测试设计人员能力的不信任。其次，测试设计与测试执行分离，测试设计人员不参与测试执行。从一方面看，这样有助于明确责任分工;但是从另一方面看，也有一定的弊端。众所周知，测试不可能做到穷尽测试。当然，用例也不可能覆盖所有的路径，只能提取典型数据进行测试。如果测试设计人员参与执行工作，就能够对未覆盖的路径进行补充测试;并可以加深对业务逻辑的理解，更好地设计用例数据。再次，为了避免出现无文档的情况，应对随机测试的测试点做出记录，留待以后参考。最后，对于随机测试发现的缺陷，应该补充相应的用例充实到用例库中。
对于缺陷提交方面：
根据内部缺陷标准进行判定并提交，最后根据open和closed的缺陷总数整理测试报告，并进行发布版本的质量评定。由于有内部发布的标准，因此，对于一些不能重现的缺陷，如读取异常，将做删除处理。这样就存在一个问题：即不能重现的缺陷不算缺陷!一旦某天可以重现这个缺陷，将作为测试人员的遗漏进行考核。虽然不能重现不利于开发人员定位并修改，但是不等于这个缺陷未存在。个人意见不能重现的缺陷也应该保存，可以根据具体情况，不设置为open状态。作为备份数据，以供后来参考。
综上所述，投入大部分精力写出来的测试文档资料，参考价值并不大。如果不针对设计及执行方面做进一步改进，那么对测试流程的改进又将流于形式。目前，针对这些问题仅想到如下的解决方式：
1、测试设计人员间进行交叉评审，并提交相应的记录。根据评审结果，进一步完善文档。
2、测试设计人员依据大纲进行补充性测试，尽量采用用户数据模拟真实操作。
3、测试执行人员在测试初期依据测试用例进行测试，并适量做随机测试。测试后期，主要根据用例执行。
如需了解更多测试技术信息请关注：深圳多测师软件与技术服务有限公司
?