设计驱动测试PDF格式文档图书下载

第一部分 DDT vs.TDD 2

第1章 有人弄反了 2

DDT要解决的问题 2

很难知道什么时候完成 3

将测试放在后期代价更大 3

测试设计糟糕的代码很困难 3

用户级测试很容易被遗忘 4

开发人员变得自负 4

测试有时缺少目标 4

对DDT的与工具无关的快速概览 4

DDT的结构 5

DDT实战 6

TDD与DDT的不同之处 7

示例项目：Mapplet 2.0介绍 8

小结 10

第2章 使用TDD的Hello World 12

TDD的十大特性 12

10．测试驱动设计 12

9．完全没有文档 13

8．所有东西都是单元测试 13

7．TDD测试不是完全的单元测试 13

6．验收测试提供针对需求的反馈 13

5．TDD导致盲目自信的变更 13

4．设计在不断增长 14

3．有一些预先设计就可以了 14

2．TDD产生了大量测试 14

1．TDD实在太难了 14

使用TDD实现登录用例 14

理解需求 15

考虑设计 16

编写第一个测试先行的测试 17

编写登录检查代码从而使测试通过 21

创建模拟对象 22

从重构代码看设计的浮现 24

TDD中的验收测试 30

结论：TDD实在太难了 30

小结 31

第3章 使用DDT的Hello World 32

ICONIX/DDT的十大特性 32

10．DDT包含业务需求测试 32

9．DDT包含场景测试 33

8．测试是被设计驱动的 33

7．DDT包含控制器测试 33

6．DDT测试更灵活，更简单 33

5．DDT中的单元测试是“经典”的单元测试 33

4．DDT中的测试用例可以转换成测试代码 34

3．DDT测试用例指导测试计划 34

2．DDT测试对开发和测试团队都很有用 34

1．DDT可以消除重复工作 34

使用DDT实现登录 34

步骤1：创建健壮性图 36

步骤2：创建控制器测试 38

步骤3：添加场景 40

步骤4：将控制器测试用例转换成为类 42

步骤5：生成控制器测试代码 43

步骤6：绘制序列图 46

步骤7：创建单元测试用例 48

步骤8：填充测试代码 52

小结 56

第二部分 真实世界中的DDT:Mapplet 2.0旅游网站 59

第4章 Mapplet项目简介 59

ICONIX流程／DDT十大“To-Do”列表 60

10．创建架构 60

9．对需求达成共识并进行测试 61

8．从问题域驱动设计 63

7．使用UI故事板编写用例 65

6．编写场景测试验证用例 66

5．测试概要设计和详细设计 69

4．经常更新模型 69

3．保持测试脚本与需求同步 73

2．更新自动化测试 73

1．比较待发布版本和原始用例 74

小结 77

第5章 详细设计和单元测试 78

单元测试十大“To-Do”列表 79

10．从序列图开始 79

9．在设计中标识测试用例 81

8．为每个测试用例编写场景 82

7．聪明测试：避免重叠测试 84

6．把测试用例转换为UML类 85

5．编写单元测试和相关的代码 89

4．编写白盒单元测试 92

3．使用模拟对象框架 96

2．用单元测试测试算法逻辑 99

1．编写集成测试的独立套件 99

小结 100

第6章 概要设计和控制器测试 101

控制器测试十大“To-Do”列表 102

10．从健壮性图开始 102

9．为控制器标识测试用例 105

8．为每个测试用例定义一个或者多个场景 107

7．填写描述、输入和验收标准 110

6．生成测试类 110

5．实现测试代码 114

4．编写容易测试的代码 115

3．编写“灰盒”控制器测试 117

2．串联控制器测试 118

1．编写集成测试的独立套件 119

小结 120

第7章 验收测试：扩展用例场景 121

场景测试的十大“To-Do”列表 122

Mapplet用例 122

10．从一个叙述性用例开始 122

9．把这个用例转换成一个结构化的场景 125

8．确保涵盖所有的可选方案和意外场景 126

7．增加前置条件和后置条件，将每个场景分支连接起来 126

6．生成活动图来检查结构化场景 127

5．创建外部测试集来细化场景 128

4．把测试用例放进用例图 129

3．进入EA测试视图 129

2．根据需要细化场景 130

1．为测试团队生成测试计划文档 130

这个过程的精髓是 131

小结 134

第8章 验收测试：业务需求 135

十大需求测试“To-Do”列表 136

10．从一个域模型开始 136

9．编写业务需求测试 138

8．对需求进行建模和整理 138

7．从需求创建测试用例 139

6．与用户一起审查你的计划 141

5．编写手工测试脚本 143

4．编写自动化需求测试 143

3．导出需求测试用例 144

2．使测试用例可见 144

1．让你的团队参与其中！ 144

小结 145

第三部分 高级DDT 147

第9章 单元测试的反模式（反面案例） 147

末日圣殿（特指某一种代码） 148

大背景 148

HotelPriceCalculator类 149

支持类 151

服务类 152

反模式 154

10．复杂的构造函数 154

9．滥用类继承 155

8．静态微触发器 157

7．静态方法和变量 159

6．单例设计模式 160

5．紧耦合 162

4．UI代码里实现业务逻辑 164

3．滥用私有属性 165

2．声明为final的服务对象 166

1．热心的程序员开发的不成熟的功能 166

小结 167

第10章 为易于测试而设计 168

十大为测试而设计的“To-Do”列表 168

末日圣殿——彻底修正 169

用例——确定我们需要做什么 170

识别控制器测试 171

计算总价格测试 172

获取最新价格测试 172

为易于测试而设计 173

10．将初始化代码放在构造函数之外 173

9．慎用继承 174

8．避免使用静态初始化块 175

7．使用对象级别的方法和变量 176

6．避免使用单例设计模式 176

5．保持类解耦合 178

4．将业务逻辑放在UI代码之外 179

3．使用“黑盒”和“灰盒”测试 184

2．为常量预留“final”修饰符——通常需要避免修饰复杂类型（如Service Objects）为final 184

1．坚持使用用户用例和设计 185

Quote Hotel Price用例的详细设计 185

控制器测试：计算总价 186

控制器测试：获得最新价格的测试 187

重构设计和代码 187

小结 189

第11章 自动化的集成测试 190

十大集成测试“To-Do”列表 190

10．在概要设计里寻找测试模式 191

9．不要忘记安全性测试 192

安全性测试：SQL注入攻击 192

安全性测试：建立安全会话 193

8．决定编写哪个“等级”的集成测试 194

三个等级的不同点 194

了解编写哪个等级的集成测试 194

7．概要设计驱动单元／控制器级别的集成测试 195

6．从用例场景驱动场景测试 198

5．编写端到端场景测试 198

模拟一个场景中的步骤 199

共享测试数据库 199

Mapplet例子：“高级搜索”用例 201

Vanilla xUnit场景测试 201

4．使用“业务友好”型测试框架 202

3．将测试GUI代码作为场景测试的一部分 204

2．不要低估集成测试的难度 204

网络延迟 206

数据库元数据变化 206

随机变化的（又名“敏捷”）接口 206

远程系统中的bugs 207

阴雨天 207

1．不要低估集成测试的价值 207

编写集成测试的关键点 208

小结 209

第12章 单元测试算法 210

十大算法测试“To-Do”列表 211

10．从概要设计的控制器开始工作 211

9．将控制器扩展成算法设计 213

8．把图和域模型对应起来 214

7．分割那些看上去不止做一个检查的判断结点 214

6．为每个结点（活动和判断结点）建立一个测试用例 215

5．为每个测试用例定义测试场景，一组输入和期望结果 216

4．按照算法，从不同的源中创建输入数据 218

3．把逻辑流程对应到独立的方法和类上 219

2．编写“白盒”单元测试 223

1．在其他类型的设计图上使用DDT技术 232

小结 232

附录 爱丽丝漫游用例国 234

介绍 234

第1部分 235

爱丽丝在看书的时候睡着了 235

用例驱动开发的承诺 236

一种把用例文本和对象连接起来的分析模型 236

简洁且直接 236

《包含》还是《扩展》 236

我们迟到了！我们必须开始编码了！ 237

爱丽丝想知道如何才能把用例变成代码 237

抽象的……基本的 237

有点太过抽象了？ 237

目的中心化 238

我们真的打算为每个用例都指定这些东西吗？ 238

第2部分 239

爱丽丝口渴了 240

爱丽丝感到头晕 240

设想……（敬请约翰·列侬原谅，这首歌改编自他的作品） 240

结对编程意味着再也不用把需求写下来了 241

没时间去写需求了 242

你也许也会说“代码就是设计” 242

谁在乎用例？ 243

C3项目被中止了 243

一次且只有一次？ 244

没有写下需求之前，爱丽丝拒绝开始写代码 245

你因为预先设计而被定罪 246

CMM已经死了，砍掉她的脑袋！ 247

一些严肃的设计重构 247

第3部分 247

爱丽丝醒了 248

缩小“什么”和“如何”之间的距离 248

静态模型和动态模型被连接在了一起 248

行为被定位到序列图里 248

这里面的教训在于 249

尾声——乱七八糟的测试 250

索引 253

查看更多关于设计驱动测试的内容