关于“敏捷测试”与“传统测试”的一些个人看法

       今天晚上，我们头突然说，领导叫做一个示例：写一个传统的测试用例，然后再写一个敏捷的测试用例。然后一下子我也愣住了，这能在写测试用例上表达测试在传统与敏捷的区别吗？

 

       结合InfoQ的一篇经典文章《什么是敏捷软件测试》，说一下我的看法，贴切地说是读后感。权当抛砖引玉，劳烦砖头砸得轻一点。

 

 

         

我觉得在写测试用例上体现不出二者的区别，敏捷测试更多的只是一种理念。

      传统的测试以验证为目的，即通过详尽的开发文档以及设计测试用例，通过尽可能完备的“覆盖”去发现问题，对开发阶段的成果进行验证（是开发阶段的下一个阶段）。

      敏捷测试贯穿整个开发过程，核心在于团队的沟通。开发与测试同步进行，要求建立高度可测试性，以及自动化测试。

      测试在敏捷中没有独立提出，不是不重要，而是它与敏捷核心价值相通的，敏捷开发周期的各个过程中都有体现（与开发人员、客户交流，可验证的测试胜过于面面俱到的文档、响应变化）。具体如何识别在敏捷中对测试进行检查，下面引自一篇网文的介绍，我觉得很确切，我们实施的时候可以相应地进行舍取。

 

项目	检查点	注释
团队	测试工程师是否与开发工程师建立了紧密联系？ 测试工程师是否与客户建立和紧密联系？	是否参加每日站立会议？是否与开发工程师可以展开随时的，面对面的，对等的讨论？ 是否保持和客户的良好沟通？是否和客户一起维护良好定义的验收测试？
反馈	项目是否建立了合适的验收测试？ 是否项目中每个人都能随时了解当前工作与可交付产品的距离？ 是否建立了针对开发质量的度量标准？ 开发工程师是否能够快速得到对提交代码的反馈？	使用Dashboard、燃尽图等方式展示当前工作与可交付产品之间的距离 建立单元测试覆盖率等度量指标 使用持续集成或频繁的构建让开发工程师快速得到提交代码的质量反馈
质量文化	是否建立了开发与测试工程师共享质量目标的原则？ 团队是否注重开发质量，并在工作中尽可能保证高的开发/代码质量？	共享质量目标意味着质量责任由所有工程师共同承担 不仅关注最终的产出，不断对代码进行重构，保证代码质量
开发测试	是否进行了充分的开发测试？ 是否设立了持续集成环境，并以持续集成的结果作为能够继续提交代码和发布的条件？ 是否建立了足够多的自动化测试，以及在设计时关注自动化测试的要求？	开发测试应该建立一定的测试覆盖率标准，例如，在单元测试这个级别上，建立60%或80%的覆盖率要求 通过使用TDD、BDD等技术，保证产品和代码的可测试性 建立足够多的自动化测试，保证测试能够满足快速迭代的要求

 

 引用文中一句：“质量文化”是基础，“团队”是敏捷软件测试得以实施的条件，“反馈”和“开发测试”则是敏捷软件测试的具体方法。

参照：《什么是敏捷软件测试》