敏捷测试要求“交付可用产品”而非单纯的“发现缺 陷”
敏捷方法的特征
• 2001年在软件工程界首次出现“敏捷”。 • 敏捷方法最主要的两个特征：轻量和简单
– 包含最少的流程和文档，减少正式性。 – 做眼前能做的事情，而不去预测太远的未来 – 快速、增量的开发
• 开发方法要称之为敏捷，需要具备4个基本特征：
– 工具未必能生成所有满足要求的数据，但最快速 – 编程能生成所有需要的数据，但是可能是最复杂的、最慢的方式 – 应尽量考虑使用一些简单实用的工具，例如DataFactory
敏捷测试的弱点
• 在某些公司，由于各种原因，一个团队的 敏捷程度完全取决于和他们合作的部门或 公司的敏捷程度。 • 敏捷在无法改变周边的人、部门和公司的 做事方式的时候适用性不好。
8.2测试驱动开发(TDD)
• 一个高效的软件开发过程对软件开发人员 来说是至关重要的 • 测试驱动开发（TDD)是极限编程的重要特 点，它以不断的测试推动代码的开发，即 简化了代码，又保证了软件的质量
什么是测试驱动
测试驱动是一种开发形式： 测试驱动是一种开发形式： 1.首先要编写测试代码 首先要编写测试代码 2.除非存在相关测试，否则不编写任何的产 除非存在相关测试， 除非存在相关测试 品代码 3.由测试来决定需要编写什么样的代码 由测试来决定需要编写什么样的代码 4.要求维护一套详尽的测试集 要求维护一套详尽的测试集
TDD测试案例
• 第二个测试： Public void testFibonacci() { AssertEquals(0,Fib(0)); AssertEquals(1,Fib(1)); } Int Fib(int n) { if(n==0) return 0; return 1; }
TDD测试案例
《软件工程与软件测试技术》
韩智
第8章前沿测试技术
• 8.1敏捷测试技术 • 8.2测试驱动开发（TDD)
8.1敏捷测试技术
简而言之，敏捷测试是指在采用敏捷技术的项目 中开展的测试 同时，敏捷测试也意味着测试遵循敏捷的基本原 则，接纳敏捷的核心价值观（交流，简单，反馈， 勇气）
保持简单 以任务为导向，而不以过程或是角色为导向 通过沟通和反馈保证测试能够建立合适的质量标准 尽可能减少测试周期的时间需求
2.基于需求的测试用例设计
• 基于需求的用例场景来设计测试用例是最 直接有效的方法。 • 要把测试用例当成“活”的文档，在设计 测试用例方面应该把握敏捷的“及时响应 变更比遵循计划更有价值”这一原则 • 测试用例的设计也需要迭代，在软件开发 的不同阶段都要回捷测试用例设计
1. 2. 3. 4. 测试用例的粒度 基于需求的测试用例设计 测试用例的评价 测试用例数据生成的自动化
1.测试用例的粒度
• 测试用例可以很简单，也可以很复杂。 • 测试用例写的过于复杂或过于详细，会带来两个 问题：一个是效率问题，另一个是维护成本问题 • 测试用例写的过于简单，则可能失去了测试用例 的意义。 • 如何把握好粒度是测试用例设计的关键 • 测试用例是测试人员需要努力敏捷化的对象，要 想在测试用例的设计方面应用“能工作的软件比 全面的文档更有价值”这一敏捷原则，关键是要 考虑怎样保证设计出来的测试用例能够有效的工 作。
敏捷自动化的原则
• 测试自动化意味着使用工具支持测试项目的各个方面，而 不仅仅是测试执行方面 • 当测试自动化得到指定的程序员（tool smith-工具铁匠） 支持时，会不断的顺利的进行 • “工具铁匠”由测试员领导 • “工具铁匠”收集并应用各种各样的工具来支持测试 • “工具铁匠”帮助实现可测特性并“打造”工具以便利用 这些可测特性 • 组织实现测试自动化是为了完成某个短期的目标 • 避免盲目进行长期的自动化测试任务，而不是基于业务场 景的分析
TDD测试案例
Int Fib（int n） {
if(n==0) return 0; if(n<=2) return 1; return Fib(n-1)+Fib(n-2);
}
TDD的基本过程
1. 明确当前要完成的功能（可以记录成一个 TODO列表） 2. 快速完成针对此功能的测试用例编写 3. 测试代码编译不通过 4. 编写对应的功能代码 5. 测试通过 6. 对代码进行重构，并保证测试通过 7. 循环完成所有功能的开发。
TDD的原则
1.
•
测试隔离 一顶帽子
•
不同的代码的测试应该相互隔离。对一块代码的测试只考虑此代码的测试，不要考 虑其实现细节 开发人员应完成对应的工作时应保持注意力集中在当前工作上，保证头上只有一顶 帽子。 需要测试的功能点很多，在任何阶段想添加功能需求问题时，应把相关功能点加到 测试列表中
2. 3.
•
测试列表 测试驱动
•
4. 5.
•
先写断言 可测试性 及时重构 小步前进
•
要完成某个功能或类，首先应该编写测试代码，考虑其如何使用、如何测试，然后 再对其进行设计、编码 编写测试代码时，应首先编写对功能代码的判断用的断言语句，然后编写相应的辅 助语句
6. 7. 8.
把所有的规模大、复杂性高的工作，分解成小段任务来完成。
– 增量的：小版本，频繁发布 – 协作的：客户和开发人员之间紧密沟通，经常工作在 一起 – 直接的：方法本身是容易学习和修改的 – 适应性强的：能把刚刚发生的改变考虑进来
敏捷方法的特征
• 具备这些基本特征的敏捷方法包括：
– – – – – – – – – Adaptive Software Development (适应性软件开发) Agile Modeling(敏捷建模) Crystal family of methodologies（方法论透彻派） Dynamic systems Development Method（动态系统开 发方法） Extreme Programming（极限编程） Feature Driving Development（特性驱动方法） Internet-Speed Development（互联网速度开发） Pragmatic Programming（实用编程） Scrum（混乱方法）
• 测试用例的质量保证也需求综合使用各种 方法和手段 • 最敏捷的测试用例的检查方法应当属临时 的同行评审，这种方式体现了“个体和交 互比过程和工具更有价值” • 除了同行评审，还应该尽量使顾客参与到 测试用例的设计中来，体现“顾客的协作 比合同谈判更有价值”
4.测试用例数据生成的自动化
• 在测试用例设计方面最有可能实现自动化的，是测试用例 数据生成的自动化。 • 测试用例的输入参数有不同的类型、取值范围，全面覆盖 的值域可能会不可思议的广泛，需要科学的筛选出有代表 性的数据，可利用正交表或成对组合法设计数据。可以利 用一些工具，如TConfig、PICT等来产生这些数据 • 在性能测试方面，除了设计测试用例，还要准备大量的数 据，可以使用多种方式：编程生成、SQL语句生成、利用 工具生成。
TDD测试案例
• 继续添加代码 Public void testFibonacci() { int case[][]={{0,0},{1,1},{2,1}，{3，2}} for(int i=0;i<case.Length;i++) AssertEquals(case[i][1],Fib(case[I,0]); } 再测试，失败！ 解决！
TDD测试案例
• 针对Fibonacci数列的案例 • 第一个测试： Public void testFibonacci() { AssertEquals(0, Fib(0)); } • Fibonacci数列的第一个数是0，现在测试代码有了，先运 行一下测试，结果失败。因为还没有Fib（）这个函数 Int Fib(int n) { return 0; }
用最简单的方法避免重复，用表驱动 Public void testFibonacci() { int case[][]={{0,0},{1,1},{2,1}} for(int i=0;i<case.Length;i++) AssertEquals(case[i][1],Fib(case[I,0]); ]