探索式测试实践之缺陷大扫除和结对测试

　　探索式测试的定义在我的blog都做了较多说明，其中也谈到了探索式测试在项目的实践方式，接下来会详细的说明其中来亮个实践方式的具体实施过程。

　　探索式测试四象限

　　探索式测试是一种测试风格和思考方式，它强调的是学习在测试过程中的作用。无论测试人员在做功能测试、性能测试、安全测试或其他类型的测试，都可以使用探索式测试的思维方法，来帮助自己找到初始测试设计未考虑到的危险区域。

　　探索式测试不只是在脚本测试后才开始，它可以应用于软件测试的各个阶段。作为一种测试风格，探索式测试可以使用适合当前情景的任何测试技术(包括脚本测试常应用的测试技术)。那为什么我们还要把探索式测试和脚本测试分开呢?这是因为探索式测试的优势来源于并行地实施测试学习、设计、执行和评估，来源于测试人员在此过程中的积极探索和主动调整，如果一再强调把探索式测试融合在脚本测试过程中，将不利于观察到探索式测试的内涵和潜在效果。

　　测试专家James Bach曾经对探索式测试(ET)和脚本测试(ST)在项目实践过程的变化进行了对比，请看图 1

　　从严格的脚本测试到自由式的探索式测试，James Bach做了如下解释：

　　最左边的Pure Scripted，是严格的按照测试用例来执行测试，而且测试用例非常详细，在项目测试过程中较少存在这种现象。

　　最右边的Freestyle ET，是自由式的探索式测试，在测试执行的时候不依赖于测试文档，只记录产品缺陷和风险除外;测试执行之前不需要任何特别的准备，比如测试设计。

　　这两种测试方式都是不常见的，有些走极端的倾向。在项目测试过程中，不可能完全采用Pure Scripted或Freestyle ET。比较好的办法是在项目中混合脚本测试和探索式测试，并在不同的项目中采取不同的混合方式来制定项目测试计划。在大部分的项目测试过程中，综合脚本测试和探索式测试的优点可以得到较好的效果。

　　目前许多测试团队以脚本测试为主导，偶尔在测试执行的时候发散性地去测试有疑惑的地方，但该发散性测试受经验、时间、功能特性、测试任务等众多因素影响，其结果无法跟踪，且经验不能传承。为了更好的组合脚本测试和探索式测试的优点，可以考虑尽量减少编写文档的时间，也可以考虑增加在测试执行时学习产品和技术的时间，从而带来更强的思维扩展性。

　　下面简单介绍如何组合脚本测试和探索式测试过程中需要用到的几个关键性的因素：

　　Vague Scripted：比较简要的测试用例，是对脚本测试(ST)的初步简化，可以理解为测试人员需要编写测试用例，(但不必编写详细的预期结果)。测试用例可以包含操作步骤，但描述比较简单，其目的是留下更多的空间给测试人员在测试执行的时候自由发挥。

　　Fragmentary test cases：使用一句话或几个词语描述的测试用例，类似于脚本测试中的测试用例标题。

　　Charters：探索式测试过程中使用到的一个非常清晰的任务列表，指出了要测试什么、怎么测试(强调策略，不是详细测试步骤)、寻找什么样的Bug、有哪些风险、要去检查什么文档等。

　　Roles：测试过程中确定每个测试人员一个独立的角色去测试产品的某个部分。由测试人员自己掌控测试任务的进度和质量。

　　接下来将说明在实际的项目测试过程中，如何组合探索式测试和脚本测试。

　　象限编号的顺序与不同形式的探索式测试实践没有直接关系。例如，在我们进行 “Freestyle ET”形式的探索式测试实践时，完全可以采纳结对测试(Pair Testing)的形式，或进行探索式测试之后采用全民分享(All Sharing)方式来分享更多的测试经验。探索式测试属于软件测试的上下文驱动学派(Context-Driven School)，具体采用何种方式来进行探索式测试实践，或如何组合多种实践方式都是依赖于项目当时的情境，也就是项目本身的上下文环境。

　　由于本文只对第四象限的两个方式进行详细说明，则其他象限的具体实践方式不在此说明。特别说明的是象限一和象限四是两个面向探索精神的实践方式，象限二和象限三是两个偏向于流程和系统性的实践方式。这里需要强调的是ET主导的实践方式也是有一定的项目流程的基础和系统性的思维路径的，本文不做详细的说明。

　　象限四中的测试实践方式是由三个非常具有探索性的小活动(接下来称为趣味性的实践方式)组成。Bug大扫除 (Bug Bash)在微软使用得非常普遍，且效果非常好。 结对测试(Pair Testing)是与结对编程相对应，由两名或多名测试人员在一起同时测试一个SUT，并相互给出建议和指令，共享通过使用系统得到的(隐含)信息，从而不断的积累系统知识和测试经验。全民分享(All Sharing)是测试执行前或执行后所进行团队分享的一个活动，具有不同背景和特长的测试人员分享自己发现Bug的思路，分享自己如何去测试软件，分享自己在某种测试类型上的策略。

　　缺陷大扫除

　　熟悉微软测试流程的测试人员应该都听说过缺陷大扫除(Bug Bash。它是一项短期的全员测试活动。在微软，许多开发团队会在里程碑(Milestone)的末期执行缺陷大扫除。程序员、测试员、程序经理、用户代表、市场人员在1~3天的窗口中，运用各自的技能和职业背景，集中精力来搜寻软件的缺陷。通常，每位参与者会获得一个小礼品，发现缺陷数目最多的冠军会获得一份大奖。

　　一般缺陷大扫除的组织者需要准备如下的内容：

　　l 活动对象：

　　l 活动时间：

　　l 测试环境：

　　l 如何访问：

　　l 测试数据：

　　l 项目功能：

　　l 问题反馈：

　　l 奖项设置：

　　l 已发现但在处理中的bug列表：

　　缺陷大扫除是常规测试的有效补充。测试团队将各个子系统连成业务系统，执行端到端(end-to-end)的系统测试，能够发现个人在子系统测试中难以发现的缺陷。此外，测试人员在测试不熟悉的子系统时，没有任何先入为主的“偏见”，往往能立即发现那些被“熟视无睹”的缺陷。而资深测试人员还可能发现一些初学者难以察觉的隐蔽问题。不过，相比找到的缺陷，我认为缺陷大扫除在以下两个方面更有价值：

原文转自：http://blog.sina.com.cn/s/blog_6cf812be01012h6l.html