3．分阶段制订测试计划方案

　　测试计划方案不是从头到尾一成不变的，应根据企业应用软件项目所处的不同阶段制订，不同的项目阶段所需的测试方法是不一致的。可以借鉴RBT理论关于基于需求的测试方法的最佳实践（参见链接）。

　　4．设计基于需求的复合测试用例

　　在很多情况下，单一的测试方法很难实现软件缺陷或错误的全面检查，在软件工程中使用最多的往往是组合多种测试方法的复合测试用例。例如黑盒测试和白盒测试两者的功能作用就可以互相弥补，实践中可以将两种测试方法组合起来设计复合测试用例。

　　5．妥善处理测试和设计之间的关系

　　测试是“破坏性”的，而开发却是“建设性”的。从行为学角度看，开发与测试是对立的。如果测试人员对开发人员的错误批评指责过多，容易导致双方的关系对立隔阂；如果测试人员对开发人员的错误疏忽怠慢，容易导致软件质量的隐形下降，实践中需要找到一个平衡点。

　　6．建立测试报告审批通报制度

　　建立测试报告审批通报制度对于提升软件质量具有明显作用。作为一名优秀的测试工程师，要养成书面起草测试工作报告的好习惯。将已经定位发现的缺陷或错误进行分析汇总，用统计数字、图表等方式说明缺陷或错误的根源，及时将测试工作报告提交上级主管领导审议，并通知研发设计人员，使设计人员做到对缺陷心中有数、控制有道，以防患于未然。

　　链接

　　基于需求的测试理论的五项最佳实践

　　1．转变“编码后进行测试”的传统观念。在软件编码开始之前的设计阶段就根据需求文档和设计文档开发出90%以上的测试用例，尽早发现和排除绝大部分的缺陷。

　　2．根据各项应用功能的优先级、重要性制订不同等级的测试方案、测试用例。重要的模块投入较多的测试资源（人力、时间、物资），次要的模块投入较少的测试资源。

　　3．尽早测试，频繁测试。测试进行得越早，缺陷发现越早，修复缺陷的代价越小；测试进行得越晚，缺陷发现越迟，修复缺陷的代价越大。

　　4．摒弃“经验至上”的想法。设计系统、严谨、合理的测试用例才能使测试达到实效。

　　5．加强对测试过程的监控跟踪。当用户需求发生变更时，软件需求文档和设计文档都随之发生变更，相应测试用例也应发生变更。要随时监控需求的变化，保证测试用例和用户需求的双向追溯统一。