本书是世界名著《Software TestAutomation》的姊妹篇，是自动化测试领域的至宝，是每一位测试人员都应该反复研读的一本书！它是Dorothy Gramham、Mark Fewster、LisaCrispin、AlanPage等30多位来自世界各地的自动化测试专家和大师的经验结晶，通过对30多个来自世界各行各业的经典测试案例的分析和研究，讲述了的自动化测试工具、技术、方法，以及自动化测试的实施、引导和管理，不仅包含大量实践，还包含很多失败的教训。让读者不仅能吸取前人留下的宝贵经验和远见卓识，少走弯路，还能更好地领会自动化测试的自然规律——无论是管理人员、测试人员，还是自动化测试人员，本书都非常有价值。

本书一共29个章节，文中只会展示一部分书籍的内容，书籍内容涵盖丰富，需要的朋友点击领取《自动化测试最佳实践》

目录介绍

• 第 0 章　案例研究反思 / 1

• 第 1 章　敏捷团队的自动化测试之旅：第一年 / 13

• 第 2 章　终极数据库自动化 / 25

• 第 3 章　移动到云端：TiP 的演化——在线的持续回归测试 / 37

• 第 4 章　Automator 的自动化 / 51

• 第 5 章　自动化人员自传：从主机到框架的自动化 / 60

• 第 6 章　项目 1：失败！项目 2：成功！ / 76

• 第 7 章　复杂政府系统的自动化测试 / 93

• 第 8 章　设备仿真框架 / 103

• 第 9 章　ESA 项目中基于模型的测试用例生成 / 112

• 第 10 章　10 年过去了，项目还在进行 / 127

• 第 11 章　凤凰在灰烬中重生 / 141

• 第 12 章　政府机构运作系统的自动化测试之旅 / 155

• 第 13 章　使用硬件接口的自动化可靠性测试 / 169

• 第 14 章　Android 应用的基于模型 GUI 测试 / 180

• 第 15 章　SAP 业务流程的自动化测试 / 197

• 第 16 章　SAP 实现的自动化测试 / 209

• 第 17 章　选择了错误的工具 / 228

• 第 18 章　市场交易系统的自动化测试：十年经验和三个框架 / 242

• 第 19 章　自动化测试不仅仅是回归测试：发挥创造性思维 / 253

• 第 20 章　医疗设备软件需要优秀的自动化软件测试 / 267

• 第 21 章　通过后门（通过支持手动测试）进行自动化 / 287

• 第 22 章　使用自动化测试为可移植性测试增值 / 305

• 第 23 章　保险公司中的自动化测试：感受我们测试的方法 / 313

• 第 24 章　使用测试猴子的冒险之旅 / 320

• 第 25 章　在 NATS 对 SYSTEM-OF-SYSTEMS 的自动化测试 / 330

• 第 26 章　对汽车电子系统进行自动化测试 / 340

• 第 27 章　宏伟目标、改变和测试转型 / 346

• 第 28 章　自动化探索测试：超越当前时代的例子 / 361

• 第 29 章　测试自动化的轶事 / 375

书籍内容介绍

第0章　案例研究反思

• 管理层问题/1

• 技术因素16

• 总结/12

第1章　敏捷团队的自动化测试之旅：第一年

• 本案例研究的背景/14

• 整个团队的承诺/14

• 建立自动化策略/15

• 利用验收测试驱动开发，使用FitNesse测试GUI / 18

• 使用增量方法/20

• 正确度量/20

• 华草图书

• 庆祝成功/21

• 引人工程冲刺/22

• 团队成功1/22

• 持续改进/24

第2章　终极数据库自动化

• 终极数据库自动化/ 25

• 本案例研究的背景/25

• 测试中的软件126

• 自动化测试的目标/27

• 开发内部测试工具128

第3章　移动到云端：TiP的演化——在线的持续回归测试

• 本案例研究的背景/38

• 将测试移到云端/39

• 如何实施TiP 141

• 每月服务评审记分卡样例143

• Exchange TiPv2--将 TiP迁移到Windows Azure云端/46

• 我们的心得147

第4章　Automator的自动化

• 本案例研究的背景:我的第- -份工作152

• 我的伟大构想/53

• -一个突破/54

第5章　自动化人员自传：从主机到框架的自动化

• 本案例研究的背景/61

• 主机绿屏自动化测试项目/63

• 主机和基于脚本工具的差异/65

• 使用新的基于脚本的工具166

• IBM Maximo的自动化测试170

第6章　项目1：失败！项目2：成功！

• 本案例研究的背景 177

• 项目1:失败177

• 项目2:成功178

• 下一个时间段: 真实地测试185

第7章　复杂政府系统的自动化测试

• 本案例研究的背景193

• 自动化需求分析 194

• 我们的 自动化测试解决方案一自 动化测试和再测试/95

• 自 动化测试解决方案的应用1 101

第8章　设备仿真框架

• 本案例研究的背景/ 103

• 设备仿真框架的诞生/ 104

• 构建DSF 1 105

• 自动化目标/ 106

• 案例研究1 107

• 没有银弹/110

第9章　ESA项目中基于模型的测试用例生成

• 本案例研究的背景/113

• 基于模型的测试和测试用例生成1113

• 我们的应用: ESA多任务用户服务项目/116

• 学到的经验和教训/121

第10章　10年过去了，项目还在进行

• 本案例研究的背景:之前的故事1 128

• 每月进行自动化测试的保险报价系统1 128

• 接下来发生了什么/138

• 总结/138

第11章　凤凰在灰烬中重生

• 本案例研究的背景/141

• 凤凰的诞生/ 142

• 凤凰的死亡/144

• 凤凰的重生1 145.

• 凤凰的新生/ 148

第12章　政府机构运作系统的自动化测试之旅

• 本案例研究的背景1 156

• 该机构的自动化测试/ 156

• 2000-2008年/ 159.

• 三次巧合/162

• 在测试团队中完善能力/ 165

• 未来的方向:继续旅程1 166

• 总结/168

第13章　使用硬件接口的自动化可靠性测试

• 本案例的研究背景/170

• 采取措施的必要性/ 170

• 自动化测试启动(增量式方法)/171

• 来自管理层的支持/172

• 测试框架的进一步开发/174

• 部署并改进报告形式/ 177

• 总结/178

第14章　Android应用的基于模型gui测试

• 本案例研究的背景1 181

• 使用TEMA工具集的MBT / 182

• 应用行为建模/187

• 测试用例的生成1 190

• 连接和适配1 191

• 结果/194

• 总结/194

第15章　SAP业务流程的自动化测试

• 本案例研究的背景1 198

• 标准和最佳实践/200

• eCATT使用实例/203

• 总结/207

第16章　SAP实现的自动化测试

• 本案例研究的背景/210

• 项目概述/211

• 第1阶段:概念的证明/212

• 第2阶段:项目启动/217

• 总结1226

第17章　选择了错误的工具

• 本案例研究的背景1228

• (可能)早已存在的自动化测试1230

• 必要的决策:新工具还是主要维护成本/231

• 继续推进eggPlant工具/233

• 我们在eggPlant项目之后还将做什么1/239

• 总结/239

第18章　市场交易系统的自动化测试：十年经验和三个框架

• 本案例研究的背景/243

• 自动化测试框架1243

• 测试角色/245

• 抽象层1246

• 配置/248

• 成本和投资回报率/ 249

• 总结/251

第19章　自动化测试不仅仅是回归测试：发挥创造性思维

• 本案例研究的背景/254

• 任务自动化的两个故事1254

• 自动化测试用来支持手动探索式测试/258

• 自动化测试数据交互1260

• 自动化测试和监测/262

• 通过组合简单的工具模拟现实世界的负载1264

第20章　医疗设备软件需要优秀的自动化软件测试

• 本案例研究的背景/268

• 每个项目不同方法的比较127

• 项目HAMLET 1274

• 项目PHOENIX 1275

• 项目DOITYOURSELF /277

• 项目MINIWEB 1279

• 测试执行/280

• 结果报告/281

• 总结/283

第21章　通过后门（通过支持手动测试）进行自动化

• 本案例研究的背景/288

• 我们的技术解决方案/288

• 通过ISS测试站实现测试自动化/291

• 实现测试自动化/293

• 支持手动测试/296

• 新的手动测试过程/298

• 总结/302

第22章　使用自动化测试为可移植性测试增值

• 本案例研究的背景/306

• 可移植性测试:喜欢它或者讨厌他

• 将软件组合起来作为解决方案

• 总结/312

• 致谢/312

第23章　保险公司中的自动化测试：感受我们测试的方法

• 保险公司中的自动化测

• 本案例研究的背景/313

• 应用程序/314

• 目标/315

• 我们做的工作/315 .

• 教训/317

• 总结/318

第24章　使用测试猴子的冒险之旅

• 本案例研究的背景1320

• 自动化回归测试的局限性/321

• 则试猴子/322

• 实现测试猴子1324

• 使用测试猴子/325

• 收益和局限性/328

第25章　在NATS对SYSTEM-OF-SYSTEMS的自动化测试

• 本案例研究的背景/331

• 测试执行工具的集成/333

• 工具的试点项目/333

• 系统使用中(In-Service )的测试

• 实现/334

• 典型的脚本模板/336

• 得到的教训1/338

第26章　对汽车电子系统进行自动化测试

• 本案例研究的背景/341

• 自动化项目的目标/342

• 自动化项目的简史1/342

• 自动化项目的结果/344

• 总结/345

第27章　宏伟目标、改变和测试转型

• 本案例研究的背景/346

• 管理层的认可/347

• 构建自动化框架的故事/350

• 自动化测试框架的描述/352

• 测试环境/355 .

• 度量标准/356 .

• 总结/358

第28章　自动化探索测试：超越当前时代的例子

• 本案例研究的背景1 362

• 什么是故障管理工具1362

• 测试故障管理系统中的事务/363

• 用编程的方法结构化测试用例/365

• 思考自动化测试的新方式/365

• 测试故障管理系统的工作流/366

• 运行中生成测试/371

• 项目的冲刺阶段1372

• 发布之后/373

第29章　测试自动化的轶事

• 三个小故事/375

• 需要更多对自动化的理解1378

• 自动化测试的第一天1379

• 尝试开始实施自动化/384

• 与管理层作斗争/385

• 探索性测试自动化:数据库记录锁定/387

• 在嵌入式硬件-软件计算机环境中进行测试自动化所得到的教训/392

• 传染性的时钟/395

• 自动化系统的灵活性1 397

• 使用过多工具(跨部门的支持不够)的故事/398

• 成功的案例却有着意料之外的结局/401

• 合作能够克服资源的限制1404

• 取得了大规模成功的自动化过程1405

• 测试自动化并不总是像看上去那样1409

部分内容截图

【软件测试资料合集】

点击下方图片有惊喜，精美礼品等你来拿哦

---

前言：
✌ 作者简介：渴望力量的哈士奇 ✌，大家可以叫我 🐶哈士奇🐶 ，一位致力于 TFS 赋能的博主 ✌
🏆 CSDN博客专家认证、新星计划第三季全栈赛道 top_1 、华为云享专家、阿里云专家博主 🏆
📫 如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步👀
💬 人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。💬
🔥 如果感觉博主的文章还不错的话，还请👍关注、点赞、收藏三连支持👍一下博主哦

---

专栏系列（点击解锁）	学习路线指引	知识定位
🔥Python全栈白皮书🔥	零基础入门篇	以浅显易懂的方式轻松入门，让你彻底爱上Python的魅力。
	语法进阶篇	主要围绕多线程编程、正则表达式学习、含贴近实战的项目练习 。
	自动化办公篇	实现日常办公软件的自动化操作，节省时间、提高办公效率。
	自动化测试实战篇	从实战的角度出发，先人一步，快速转型测试开发工程师。
	数据库开发实战篇	更新中
	爬虫入门与实战	更新中
	数据分析篇	更新中
	前端入门+flask 全栈篇	更新中
	django+vue全栈篇	更新中
	拓展-人工智能入门	更新中
网络安全之路	踩坑篇	记录学习及演练过程中遇到的坑，便于后来居上者
	网安知识扫盲篇	三天打鱼，不深入了解原理，只会让你成为脚本小子。
	vulhub靶场漏洞复现	让漏洞复现变得简单，让安全研究者更加专注于漏洞原理本身。
	shell编程篇	不涉及linux基础，最终案例会偏向于安全加固方向。 [待完结]
	WEB漏洞攻防篇	2021年9月3日停止更新，转战先知社区等安全社区及小密圈
	渗透工具使用集锦	2021年9月3日停止更新，转战先知社区等安全社区及小密圈
点点点工程师	测试神器 - Charles	软件测试数据包抓包分析神器
	测试神器 - Fiddler	一文学会 fiddle ，学不会倒立吃翔，稀得！
	测试神器 - Jmeter	不仅是性能测试神器，更可用于搭建轻量级接口自动化测试框架。
	RobotFrameWork	Python实现的自动化测试利器，该篇章仅介绍UI自动化部分。
	Java实现UI自动化	文档写于2016年，Java实现的UI自动化，仍有借鉴意义。
	MonkeyRunner	该工具目前的应用场景已不多，文档已删，为了排版好看才留着。

---

---

就像大家在学习开发的时候，尽管我们已经知道了、学会了 python 的基本语法，但是要真正的开发一套接口、开发一个底层的时候仍然需要像 Django 这样的一套框架来支撑自己的代码，来提供相应的服务；

接口测试也是类似，如果仅仅使用脚本的话会有很多的限制，所以接口测试也需要用到这样的框架，其实这里所使用的框架与在开发中所使用的单元测试是非常类似的，比较常用的测试框架有两种，比较常见的就是 unittest 与 pytest 。

在实际项目中，两者都可以使用。 unittest 相对而言有它自己的优势，就我们从头开始学习接口测试而言，可以先不去掌握 pytest 更多的封装和更多的功能，掌握好 Python 自带 unittest 单元测试框架就OK了。

接下来再这一章节，我们将三个角度来了解 unittest 框架。

🐳 unittest 框架的意义与特点

🐬 使用 unittest 的意义在哪里

• 为什么要使用 unittest ？
  • 因为在正式编写接口自动化测试用例的时候，如果像上一章节那样写，一般是针对一个接口或者一个流程建立一个 xxx.py 文件。
  • 一条用例封装成一个函数的情况下，在批量执行的过程中；如果说其中某一条数据出错了，那后面的用例可能就没有办法执行了，互相之间会产生影响。
  • 所以呢，使用 unittest 测试框架可以互不影响的执行用例，同时能够更灵活的进行执行的控制。

🐬 unittest 的特点

• unittest 测试框架应用在接口测试上的优点非常的显而易见，因为它是 python 自带的测试框架，无需再进行特殊的安装。
• 就像上面说的一样，在 unittest 测试框架下的测试用例的执行，可以互不干扰，同时能够更灵活的组织测试用例。
• unittest 和所有的单元测试框架一样，拥有丰富的比较完善的单元方法，能够帮助我们完成接口测试用例的验证工作。

🐳 unittest 框架的组成部分

• 第一部分：TestCase —> 用例对象，编写测试用例时要继承该类
• 第二部分：TestSuite —> 测试集（也叫做测试套件），它是一系列测试用例的集合。可以用来组织用例，也支持嵌套批量运行。
• 第三部分：TestLoader —> 用例加载器，是 unittest de 一种加载方式，可以向 TestSuite 中添加用例。
• 第四部分：TextTestRunner —> 用例执行器，输出的是类似文本的结果，一般都是以 TestSuite 为单位来执行测试用例。
• 第五部分：TestResult —> 测试结果。

我们需要学习的重点不是去深层的扒这些功能代码的逻辑，而是要学会这些功能的简单的使用即可。

🐳 完成一个简单的 unittest 用例脚本

OK，接下来我们就针对上一章节所写的关于旅游网的接口测试用例利用 unittest 进行该写。

PS：需要注意的地方，创建脚本文件时应选择 "Python unit test" 而不是我们平时所选择的 "Python file" ，并所有的文件名，必须以 "test_" 开头。创建完成后，会自动生成 "MyTestCase" 类、"test_something" 函数 以及主方法。 如下图：

---

---

---

下面就来尝试编写几条登录接口的测试 Case 吧。

代码示例如下：

import unittest
import requests


class TestAccount(unittest.TestCase):

    def test_login_normal(self):    # 正常的登录
        phone = "13770000000"
        password = "123456"

        url_login = "http://trip.imooc.zhaedu.com/api/accounts/user/login/"  # 登录API
        data_login = {"username": phone, "password": password}  # 定义登录API传入信息
        res_login = requests.post(url=url_login, data=data_login)
        print("登录信息:", res_login.text)
        cookies = requests.utils.dict_from_cookiejar(res_login.cookies)  # 获取 cookie
        print("登录cookies:", cookies)

    def test_login_abnormal(self):    # 不正常的登录
        phone = "13770000000"
        password = "12345678"         # 密码不正确

        url_login = "http://trip.imooc.zhaedu.com/api/accounts/user/login/"  # 登录API
        data_login = {"username": phone, "password": password}  # 定义登录API传入信息
        res_login = requests.post(url=url_login, data=data_login)
        print("登录信息:", res_login.text)
        cookies = requests.utils.dict_from_cookiejar(res_login.cookies)  # 获取 cookie
        print("登录cookies:", cookies)


if __name__ == '__main__':
    unittest.main()

上文中的脚本就是登录接口的两个测试用例，一个是正常登录的 Case ，另一个是密码错误的 Case 。

运行结果如下：

---

---

从上图中的执行结果来看我们发现了两点：

• 第一：Python unit test 文件的脚本是在 unittest 框架中运行的。

• 第二：两条登录的 Case 的运行顺序并不是按照我们写好的函数的顺序来执行的，这是因为 unittest 框架运行用例的顺序是按照用例名的 ASCII 码的书序来执行的。如果将 test_login_abnormal 函数名改为 test_login_wrong ，这样的话执行顺序就会发生改变，可以自己尝试一下。

---

当我们想要改变用例的顺序，或者说我们并不知道那个用例验证的是为真的结果，这个时候应该怎么样去做验证呢？这就涉及到了另外一个知识点，那就是 unittest 框架的断言，这个内容将在我们的下一章节为大家进行详细的介绍。

拜了个拜......

---

---