对于静态测试的方法，我们在这里需要推广 RUP 的 Use Case，这是个很好的分析需求的方法，也是测试人员作为静态测试的使用的方法之一。对产品长期战略和业务的熟悉可以帮助测试人员更好的理解团队的用例设计，视图、模块等，也能够通过对比分析，直接找出某些设计中的缺陷，以提高设计的质量。项目的开发前期阶段，设计是占有非常重要的比例，而设计是直接影响产品质量的环节，因而确保这一阶段的质量对产品的品质提高起到决定性作用。针对开发出来的用例，设计者对用例的描述通常故事情节比较简单，缺乏完备和逻辑的缜密。而开发和测试需要的是详细的设计，这个用例设计和各种辅助的逻辑应该将用例定义的清晰和明确，例如边界条件，例外条件，数据的格式和其他性能指标的界定等等都需要涵盖。因此，测试人员应该领导团队帮助明确出用例更多的细节。比如，在一次设计用例讨论中，设计者提出“我需要一个 Overlayer”。那么测试人员应该要问：“如何打开这样一个 Overlayer，如何关闭？”“这个 Overlayer 需要多大平面尺寸，是否支持调整，是否支持对屏幕大小的自动适应”，“Overlayer 的打开和关闭是否需要有动态渐变的效果？”，“Overlayer 的是否需要滚动条？”，等等。

        这个过程能够帮助团队发现早期的设计缺陷，通过发现问题，并定制新的设计方案，团队也通过这个过程，更好的了解了测试的重要性，也摒除了可能存在的对需求的种种“假设”，因而更加明确了团队的目标和方向。这是个非常关键的过程。尤其是对测试人员而言，任何“假设“都是有害的，所以一定需要把不清楚和模棱两可的问题从一开始就理清楚。

敏捷测试的计划与管理

        做好了测试的思想准备，并了解如何从需求开发出测试用例，敏捷测试人员接着需要做的就是参考产品需求和团队的设计制定和计划测试任务和各种测试活动，即测试策略和测试计划的制定。每个迭代敏捷开发都将关系产品的功能点和非功能点的需求作为产品的 Backlog 编入待开发的序列，敏捷团队从中会选择适量的 Backlog 项目来作为当前迭代的 Backlog 去实现。测试人员同样根据需要制定出相应的测试工作，并罗列于团队的 Backlog 项目中，承诺了在迭代结束时可以做好的足够的测试工作。

        对于测试计划中的 confirmative 测试，这部分必须做到高质量的按时完成。而对于 Investigative 部分，我们应该适量的计划到当前迭代中，切忌不要做 over commit。

        接着，测试人员需要撰写测试用例和测试脚本了。测试用例的撰写和传统测试基本没什么差异，按照已有的模式撰写就好了。笔者的测试团队，使用了 XML 文件格式保存所有测试用例，原因主要是沿用了测试团队原有的习惯，而同时也因为 XML 测试用例能够更好的匹配自动化测试的需要，并且便于更新。测试脚本是自动化测试的产物，敏捷开发周期短，变化多，很难拿到一个稳定的产品再开始做自动化。而自动化脚本的设计自然要避免去测试不稳定部分，开始的迭代周期几乎百废待兴，自动化作用不大，到了中期，笔者的团队自动化测试才稍成气候。

        测试人员需要的是在根据测试策略开发出这相应脚本和用例，需要把握测试范围，与计划和测试策略一致，测试也要量力而行，做到足够的测试，保障迭代的正常退出就很好了。

敏捷测试的活动时间表

        通过实施上述的敏捷测试原则，测试团队可以逐渐形成符合自身特点的敏捷测试流程、敏捷测试最佳实践，久而久之形成独立的敏捷团队文化。以笔者所在团队为例，历时 1 年，经历 12 个迭代后，我们逐渐形成了一套可以遵循测试活动时间表。我将他放到文章的最后，这张表包含了敏捷测试团队的各项活动安排和必要的前提与进入条件。在这张表中，测试团队较早的涉入，较早的开展测试，以及各项相关工作，并与设计和开发人员紧密的合作，它确保了测试团队乃至整个敏捷团队的工作的按期完成，是值得向大家推荐一种最佳实践。因为篇幅关系，这里仅对其做简单的描述。

        第一周的工作如先前所讲，做静态测试，确定测试策略和制定可行的测试计划，划定测试范围。这个阶段的前提是敏捷团队确定了当下迭代周期内需要完成的 Backlog 项目。

        第二周的工作是准备开始测试的执行，因此要准备好测试用例和测试环境。特别的是，测试人员是根据需求和团队讨论、设计出的用例来开发测试用例的。虽然测试用例的细节程度不能与传统开发中针对已经开发完的产品、产品开发文档开发的测试用例相比，相反，许多细节，尤其是还未由团队最终确定的内容仍是待定状态；但是，这些细节并非影响测试的用例设计，相反它不但简洁、易懂，也拥有很好的灵活度，它能够实时响应各种变化。而且，测试用例记录了大量的待定部分，它时刻在测试人员的脑中，测试人员用这种方式简单的告知团队，我们还有未完成的设计和未定的方案，测试用例帮助团队对产品的理解同步于此。

        第三周的第三天，第一个可以执行的 Build 已经能够发布了（这个前提需要开发人员的密切配合）我们开始功能测试了。到第三周周末，一部分功能测试已经完成，大部分关键功能得到验证。

        第四周我们要结束测试，包括 Confirmative 的测试部分和 Investigative 的测试。在迭代验收之前团队要通力合作解决各种能够解决的问题，保障 Backlog 的如期完成。这里有一个问题值得再次提出来和大家讨论，或许曾在敏捷项目中的许多人也都遇到了，那就是出现了一些质量缺陷没有来得及在迭代退出前完全解决的现象。那是不是说明测试不能够退出呢？笔者的回答是“不”。迭代的验收时间即是迭代退出时间，也是测试团队必须退出的时间。在实施中，我们将这些来不及解决的质量缺陷分成三类，一类是“希望能够解决”的质量缺陷，这部分未解决质量缺陷将要成为新一轮迭代的“将做事宜”，甚至可能作为新一轮迭代的需求做到 Backlog 里。第二部分是“必须解决”，这部分因为直接关系到最基本，最关键的功能，这样的质量缺陷必须被立刻解决，否则就必须承认本次迭代的失败了。第三部分是“不再重要的” 质量缺陷，这部分质量缺陷可以因为技术的不可实现，对客户产生较小的影响或者考虑到不久因为代码重构，这样的问题不在存在的理由，经过团队和 STAKEHOLDER 的批准可以置成“推迟解决”，待日后解决或者定义到产品的版本说明文档中。

结束语

        在本文中，我们承接了敏捷测试最佳实践系列文章的第一篇，将前文的敏捷原则融入到敏捷测试的实践活动中来。本文所讲的实践围绕“人”和“过程”两个重点展开，指出敏捷活动的主体仍然是“人”，是“敏捷团队”。笔者给出了一种基于 Scrum 敏捷开发模式下的敏捷测试团队组织结构。接着，讲述了这支团队的敏捷测试“过程”。因实践本身是对原则和方法的具体定制，不同的实施背景，敏捷活动的具体表现形式各异。所以，本文始终倾向于提供给您一个可以借鉴的并已经实施成功的敏捷测试“过程和方法”，并与您分享实践经验。