（4）输入之四：提交物的模板（BUG提交工具）
模块化是让工作步调一致的捷径，它能让一个即使经验不够丰富的项目成员也能够在很短的时间内提交出质量不错的输出物。所以模板必须要简单清晰，尽量避免给使用者过多的自我发挥的空间，用形式来约束内容。
输出准则：
（1）输出之一：测试结果（用例执行结果）
测试结果的意义并不在于有没有人看，它的意义主要体现在，当测试的粒度均匀的情况下，能够定量地描述出当前软件的稳定程度。而且多轮测试的力度相同，那么可以从测试结果的通过率上可以看出软件功能实现的变化趋势。
要降低用例的“不可测率”，测试团队需要制定有针对性的工作流程来监控“不可测”的测试用例；对于长期“不可测”的测试用例即使封杀，使之不再占用测试人员的时间；对于短期“不可测”的测试用例，要及时快速的创造测试的条件，把测试的黑洞及时修补上。
（2）输出之二：问题报告（提交BUG的描述信息）
问题报告是测试工作最主要的输出物，必须做到清晰、详尽，提供尽可能多的信息。包括问题出现的软件版本、日期、测试人员的姓名和联系方式、问题的概要描述、重现概率、重现步骤、和先决条件、期望的输出和实际的输出等。
（3）输出之三：调试信息（Log日志）
调试信息是必不可少的，它能够帮助开发人员了解问题发生的时候系统在做些什么事情。在测试开始之前要对测试团队进行深入的培训，需要每个人都明确哪一类问题需要提交哪一类调试信息，获取调试信息的手段、工具、配置等。
（4）输出之四：模块测试报告
模块测试报告是很有价值的开发文档之一。第一条就是，报告的完成要及时，不能等新闻成了旧闻才看到事后诸葛亮似的报告。另外内容要既粗且细，粗是为了迎合层次比较高的管理者；细是为了当读者有兴趣的时候，能够从报告中了解到足够详细的内容。此外模块测试报告中应当尽量提供：模块的稳定程度（case通过率）、模块的稳定趋势（与上一个版本的case通过率做比较）、严重问题的列表。
（5）输出之五：修改验证（BUG修改验证）
对一般的开发团队来讲，衡量其绩效的一个重要指标就是改BUG的反应速度，而一个BUG的终结一定是以通过测试人员验证的时间为准。修改验证的优先级永远都应该是测试人员案头优先级最高的任务。因为迟早对于此BUG的修改一定是会进入到产品基线中的，所以与其晚验证不如早验证，这样我们可以有更多的时间测试那些可能由此修改带来的风险。
及早对修改进行验证，这一方面是对开发人员的支持，另一方面如果此修改不解决问题甚至带来了其他问题，及早验证能给开发人员更多的时间做进一步检查。
三、自我约束：测试过程评估
在测试过程中要对测试的过程有定期严格的评估，以便及时发现并纠正测试过程中出现的问题。
组织一个兼职的监督小组，成员包括测试项目组长，若干测试工程师和独立的软件QA，由他们按照事先约定的项目和内容定期评估测试过程。对测试质量的评估不仅仅要停留在一两个测试用例执行的结果上，更高层次的评估重点是评估测试过程的合理性和效率。
三张图表：测试工作流程图、宏观测试流程、项目评估方法
版权声明：本文出自 hellorenwei 的51Testing软件测试博客：http://www.51testing.com/?578951
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
