敏捷测试有何不同

在传统项目中，我们往往更习惯于去严格定义软件开发生命周期中的各个阶段。例如从制定发布计划和需求定义开始，最终以测试和延迟的发布结尾。对于测试来说，在传统项目中往往被破担任门卫的角色。

对于团队的领导，或者大部分项目干系人来说，测试往往被寄予期望承担项目质量控制的职责。然而在传统项目中这点很难做到，因为测试既不能控制代码如何编写，也不能控制开发人员测试他们的代码，但所有的质量把控却都被希望能压缩在开发之后的测试阶段圆满完成。

在敏捷项目中，测试人员不再坐在那里等待工作的降临，而是主动寻找在整个开发周期中都贡献价值的方式：与用户一起编写需求的测试用例，与开发人员一起寻找程序中的漏洞，聚焦使用覆盖面更广、更灵活的测试方法。在敏捷中，开发人员从来不超前于测试人员，因为一个功能在被测试之前处于“未完成”状态。

我们可以简单的总结出敏捷测试的几个特点：

1. 强调从客户的角度，即从使用系统的用户角度来测试系统。
2. 重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
3. 建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试。同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

组织挑战

接下来让我们看看，在敏捷转型的过程中，传统的测试团队，测试人员，甚至整个项目团队，会遇到哪些挑战。

• 文化挑战

  组织文化可以影响敏捷团队的成功。在我们开始实行敏捷转型的过程中，变化是无处不在的，这其中必然包括组织文化的冲突。组织文化的形成需要时间，并且一旦建立就很难改变。在这个过程中，团队的成员都会或多或少的抵触变化，遇到失败会很自然地产生怀疑。

  这就要求团队要学会引入并接受变化，在应对变化时，要认识到其负面影响，要能预见和接受混乱，并采取措施走出混乱。敏捷看似拥有很快的速度，但变化可以是循序渐进的，采用敏捷的新团队可以较慢的去实现一些新的实践，例如测试驱动开发等。

  

  ^{From:《敏捷软件测试：测试人员与敏捷团队的实践指南》}

• 团队构成

  敏捷项目团队是跨职能的，敏捷团队与传统的跨职能团队的区别就是敏捷是向整体团队运作的方向努力，但是不可避免的是每个成员都有出于他自己的背景，尤其是团队组建初期。不同背景的成员给团队带来的既有不好的地方也有好处，例如对自身角色的定位不清楚、成员之间沟通不顺畅。好处是不同背景的成员往往有着互补的思维，尤其对于测试人员来说，在敏捷团队的测试人员会感觉到自身拥有很明显的代表客户的特性，并会将自己在质量思想方面的影响带给团队的其他成员。

  很多团队都提过一个敏捷团队中测试与开发人员比例的问题。与其关注比例，团队应该更关心他们需要什么样的测试技能。每个团队的需求是不同的，尤其对于敏捷项目团队而言，敏捷和DevOps的运作方式，会让团队中的专业人员突破他们的技术领域，投入到其他活动中，因此对于测试人员和开发人员来说，需要考虑更多的角色之外的问题。这点可以从扩张团队时对人员的要求上来体现，同时也要注重对团队内部成员多方位技能的培养。

  

  ^{From:《敏捷软件测试：测试人员与敏捷团队的实践指南》}

• 迁移过程

  在敏捷转型的过程中，有很多内容不能很好的迁移到敏捷的模式中，在此我们主要来看看有哪些和测试有关的内容是我们需要迁移且容易出现问题的。

  首先是度量标准，这是一个存在争议的话题。不同的度量指标，所产生的价值是千差万别的，有可能我们浪费精力跟踪得来的指标最终只代表了一些数字，除了评估之外不会产生其他附加的价值，对团队的进步也起不到一定的帮助。因此，选择合适的度量指标，获得较高的度量投资回报率对团队起到的帮助的很大的。

  缺陷跟踪也是敏捷团队在项目转型过程中一个比较矛盾的地方，许多敏捷实践者认为，在敏捷项目开发的过程中发现和修补缺陷是开发人员的必要工作，发现了缺陷后立刻就会被修补，因此对于缺陷的跟踪和记录是没有必要的。对于测试人员而言，他们往往使用缺陷跟踪系统对缺陷进行跟踪管理，而缺陷跟踪系统不仅仅用于缺陷跟踪，还可以记录更多相关的信息，例如优先级，严重性，状态，负责人，关联的用例、需求，以及缺陷的描述和复现方式等。我们可以通过工具来简化传统项目中繁杂的管理工作，且可以实现更多更丰富的管理目标。

  华为云DevCloud提供专业的用例管理与缺陷跟踪管理工具。

  • 通过测试计划服务的测试管理功能，可以清晰的查看需求树中每一个需求所关联的测试用例。
  • 测试用例中提供用例的基本信息编辑与查询，用例执行结果、缺陷列表、操作历史等内容的查询。
  • 可直接在用例执行后，在用例界面新建缺陷或关联缺陷，实现缺陷与用例、用例与需求、需求与缺陷的闭环跟踪。

测试自动化

在敏捷和DevOps中，测试的自动化是必需的。我们需要用自动化的手段去管理关键的测试活动，并为开发提供必要的反馈。下面就让我们来看看测试自动化都包含哪些内容，以及如何做好测试自动化。

• 测试金字塔

  在开始测试自动化的内容之前，我们先来看一个经典的测试自动化的模型—测试金字塔。

  

  测试金字塔模型的目的是，指导团队从测试自动化中尽量以最低的投入获得最大的价值。金字塔展示了3个不同的自动化测试层次。

  最低的一层是基础，主要有单元测试、组建测试等面向技术的测试所构成，这一层也代表了大多数的自动化测试。在这一层中，测试用例的单元隔离性最好，定位分析问题最容易，使用的代价也最低。

  金字塔的中间一层包含了大多数用来支持团队的自动化业务测试。这些功能测试只在验证我们在做正确的事。

  金字塔的顶层很少使用自动化，因为他的运行效率最低，开发复杂度最高，测试ROI最低。

• 什么是测试自动化

  上文提到了很多自动化测试的手段，例如单元测试、API测试等等。这些是测试的执行部分，也就是把一些测试执行的人工测试手段通过工具做成自动化的测试过程。但是测试自动化不仅仅是只是执行部分，还包括了从环境的获取到生成测试数据、执行自动化测试、最终生成结果并提供反馈。如果测试结果有问题，系统会自动推给相关的人。最终自动生成测试报告，测试人员可以直接拿到测试结果。这整个闭环的过程才是测试自动化的最终组成。

  接下来让我们看看在DevCloud中，提供了哪些帮助我们完成测试自动化实践的工具：

  • 在测试管理上提供了包括上文提到的整体测试流程管理、测试的用例和需求、虚线能够双向可追溯。
  • 在自动化方面，提供了移动应用测试、API测试和性能测试。
    • 移动应用测试提供了对应用软件包进行系统化的兼容性测试，检测软件包是否有兼容性的问题，能够涵概多少用户。
    • 接口测试提供自动化的API测试工具，通过编写测试用例实现对API的自动化测试。
    • 性能测试可为用户模拟一些大并发的场景、提供多种加压策略，能够在测试过程中对于用户的吞吐量、响应时间、负载能力，整体进行结构分析。在测试完成后还提供多维度可视化的看板，能够详细了解测试执行的情况。