主题：如何定义测试流程 好的测试流程必须满足一柔一刚两种要求。其柔性的要求是：测试的所有活动能够被组织和定义的平滑高效，实施起来没有阻滞和混乱。而其刚性的要求是：组织中的每个人能够充分了解自己的工作输入条件和输出准则，大家既有检查上一步工作是否到位的权利，又有按时保质保量地完成工作的义务。
所谓开发过程中的正规化，核心就是科学的定义流程和严格的执行流程。一个测试项目成功的关键是各个环节能够环环相扣和紧密配合，这就要求测试流程必须定义的清晰科学。
一、柔性要求：流畅的测试流程
测试的所有活动能够被组织和定义的平滑高效，实施起来没有阻滞和混乱。
一个普通的版本测试过程中，会经历的一些活动：
新版本发布说明（Release Notes）
测试任务书（Task Description）
升级测试版本（Release Update）
问题验证（Error Verification）
基本功能测试（Release Test）
新功能测试（New Feature Test）
压力测试（Stress Test）
自由测试（Free Test）
问题报告（Error Report）
进度报告（Progress Report）
二、刚性要求：严格的测试规程
组织中的每个人能够充分了解自己工作的输入条件和输出准则，大家既有检查上一步工作是否到位的权利，又有按时保质保量地完成工作的义务。
输入条件：
（1）输入之一：测试用例（case）
测试用例必须简明扼要，分布均匀，不能有太多重复的用例，又不能有明显的疏漏。这些都需要在测试项目开始之前得到保证，指望测试执行阶段的自我修复是靠 不住的。所以需要根据需求跟踪矩阵来设计测试用例，同时建立定期评审的机制来弥补被忽略的功能点和根据实践中遇到的各种情况来更新补充测试用例。
（2）输入之二：测试分工
测试分工是为了让每个测试的执行者清楚地了解自己在何时应该做什么，有哪些具体的要求。测试经理在每轮测试之前进行详尽的任务细化并通过有效的沟通机制传达给团队中的每个成员，最正规的途径是下达书面的测试任务书（测试计划）给团队的每一个成员。
（3）输入之三：测试工具
对于测试工具的要求有两个。
第一是好用，在选择测试工具的时候要慎重和广泛的比较，要保证我们即将使用的工具确实能够帮助我们——可以制定一个规范的测试工具评审表，按照测试的需求把测试工具的表现做定量的评估。
第二是大家都会用，每个测试人员都必须了解自己需要用到的测试工具及其使用方法。——要制定完备的培训计划，让每位项目成员通过培训来学到工具的使用方 法和各种规则，同时测试的管理者应该能够一目了然的看到培训的组织和参加情况（签到表），避免因新加入的成员培训不及时而影响工作的质量。
（4）输入之四：提交物的模板（BUG提交工具）
模块化是让工作步调一致的捷径，它能让一个即使经验不够丰富的项目成员也能够在很短的时间内提交出质量不错的输出物。所以模板必须要简单清晰，尽量避免给使用者过多的自我发挥的空间，用形式来约束内容。
输出准则：
（1）输出之一：测试结果（用例执行结果）
测试结果的意义并不在于有没有人看，它的意义主要体现在，当测试的粒度均匀的情况下，能够定量地描述出当前软件的稳定程度。而且多轮测试的力度相同，那么可以从测试结果的通过率上可以看出软件功能实现的变化趋势。
要降低用例的“不可测率”，测试团队需要制定有针对性的工作流程来监控“不可测”的测试用例；对于长期“不可测”的测试用例即使封杀，使之不再占用测试人员的时间；对于短期“不可测”的测试用例，要及时快速的创造测试的条件，把测试的黑洞及时修补上。
（2）输出之二：问题报告（提交BUG的描述信息）
问题报告是测试工作最主要的输出物，必须做到清晰、详尽，提供尽可能多的信息。包括问题出现的软件版本、日期、测试人员的姓名和联系方式、问题的概要描述、重现概率、重现步骤、和先决条件、期望的输出和实际的输出等。
（3）输出之三：调试信息（Log日志）
调试信息是必不可少的，它能够帮助开发人员了解问题发生的时候系统在做些什么事情。在测试开始之前要对测试团队进行深入的培训，需要每个人都明确哪一类问题需要提交哪一类调试信息，获取调试信息的手段、工具、配置等。
（4）输出之四：模块测试报告
模块测试报告是很有价值的开发文档之一。第一条就是，报告的完成要及时，不能等新闻成了旧闻才看到事后诸葛亮似的报告。另外内容要既粗且细，粗 是为了迎合层次比较高的管理者；细是为了当读者有兴趣的时候，能够从报告中了解到足够详细的内容。此外模块测试报告中应当尽量提供：模块的稳定程度 （case通过率）、模块的稳定趋势（与上一个版本的case通过率做比较）、严重问题的列表。
（5）输出之五：修改验证（BUG修改验证）
对一般的开发团队来讲，衡量其绩效的一个重要指标就是改BUG的反应速度，而一个BUG的终结一定是以通过测试人员验证的时间为准。修改验证的 优先级永远都应该是测试人员案头优先级最高的任务。因为迟早对于此BUG的修改一定是会进入到产品基线中的，所以与其晚验证不如早验证，这样我们可以有更 多的时间测试那些可能由此修改带来的风险。
及早对修改进行验证，这一方面是对开发人员的支持，另一方面如果此修改不解决问题甚至带来了其他问题，及早验证能给开发人员更多的时间做进一步检查。
三、自我约束：测试过程评估
在测试过程中要对测试的过程有定期严格的评估，以便及时发现并纠正测试过程中出现的问题。
组织一个兼职的监督小组，成员包括测试项目组长，若干测试工程师和独立的软件QA，由他们按照事先约定的项目和内容定期评估测试过程。对测试质量的评估不仅仅要停留在一两个测试用例执行的结果上，更高层次的评估重点是评估测试过程的合理性和效率。
三张图表：测试工作流程图、宏观测试流程、项目评估方法
版权声明：本文出自 hellorenwei 的51Testing软件测试博客：http://www.51testing.com/?578951
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
《笑傲测试》笔记（前言+第一式：庐山面目）
《笑傲测试》笔记（第二式：蓬门始开）
《笑傲测试》笔记（第四式：矫如龙翔）