软件测试52讲
茹炳晟
eBay中国研发中心，测试基础架构技术主管
立即订阅
13425 人已学习
课程目录
已完结 63 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从“小工”到“专家”，我的软件测试修炼之道
免费
测试基础知识篇 (11讲)
01 | 你真的懂测试吗？从“用户登录”测试谈起
02 | 如何设计一个“好的”测试用例？
03 | 什么是单元测试？如何做好单元测试？
04 | 为什么要做自动化测试？什么样的项目适合做自动化测试？
05 | 你知道软件开发各阶段都有哪些自动化测试技术吗？
06 | 你真的懂测试覆盖率吗？
07 | 如何高效填写软件缺陷报告？
08 | 以终为始，如何才能做好测试计划？
09 | 软件测试工程师的核心竞争力是什么？
10 | 软件测试工程师需要掌握的非测试知识有哪些？
11 | 互联网产品的测试策略应该如何设计？
GUI自动化测试篇 (10讲)
12 | 从0到1：你的第一个GUI自动化测试
13 | 效率为王：脚本与数据的解耦 + Page Object模型
14 | 更接近业务的抽象：让自动化测试脚本更好地描述业务
15 | 过不了的坎：聊聊GUI自动化过程中的测试数据
16 | 脑洞大开：GUI测试还能这么玩（Page Code Gen + Data Gen + Headless）？
17 | 精益求精：聊聊提高GUI测试稳定性的关键技术
18 | 眼前一亮：带你玩转GUI自动化的测试报告
19 | 真实的战场：如何在大型项目中设计GUI自动化测试策略
20 | 与时俱进：浅谈移动应用测试方法与思路
21 | 移动测试神器：带你玩转Appium
API自动化测试篇 (3讲)
22 | 从0到1：API测试怎么做？常用API测试工具简介
23 | 知其然知其所以然：聊聊API自动化测试框架的前世今生
24 | 紧跟时代步伐：微服务模式下API测试要怎么做？
代码测试篇 (3讲)
25 | 不破不立：掌握代码级测试的基本理念与方法
26 | 深入浅出之静态测试方法
27 | 深入浅出之动态测试方法
性能测试篇 (7讲)
28 | 带你一起解读不同视角的软件性能与性能指标
29 | 聊聊性能测试的基本方法与应用领域
30 | 工欲善其事必先利其器：后端性能测试工具原理与行业常用工具简介
31 | 工欲善其事必先利其器：前端性能测试工具原理与行业常用工具简介
32 | 无实例无真相：基于LoadRunner实现企业级服务器端性能测试的实践（上）
33 | 无实例无真相：基于LoadRunner实现企业级服务器端性能测试的实践（下）
34 | 站在巨人的肩膀：企业级实际性能测试案例与经验分享
测试数据准备篇 (4讲)
35 | 如何准备测试数据？
36 | 浅谈测试数据的痛点
37 | 测试数据的“银弹”- 统一测试数据平台（上）
38 | 测试数据的“银弹”- 统一测试数据平台（下）
测试基础架构篇 (4讲)
39 | 从小作坊到工厂：什么是Selenium Grid？如何搭建Selenium Grid？
40 | 从小工到专家：聊聊测试执行环境的架构设计（上）
41 | 从小工到专家：聊聊测试执行环境的架构设计（下）
42 | 实战：大型全球化电商的测试基础架构设计
测试新技术篇 (5讲)
43 | 发挥人的潜能：探索式测试
44 | 测试先行：测试驱动开发(TDD)
45 | 打蛇打七寸：精准测试
46 | 安全第一：渗透测试
47 | 用机器设计测试用例：基于模型的测试
测试人员的互联网架构核心知识篇 (5讲)
48 | 优秀的测试工程师为什么要懂大型网站的架构设计？
49 | 深入浅出网站高性能架构设计
50 | 深入浅出网站高可用架构设计
51 | 深入浅出网站伸缩性架构设计
52 | 深入浅出网站可扩展性架构设计
特别放送篇 (8讲)
测试专栏特别放送 | 答疑解惑第一期
测试专栏特别放送 | 答疑解惑第二期
测试专栏特别放送 | 答疑解惑第三期
测试专栏特别放送 | 答疑解惑第四期
测试专栏特别放送 | 答疑解惑第五期
测试专栏特别放送 | 答疑解惑第六期
测试专栏特别放送 | 答疑解惑第七期
测试专栏特别放送 | 浅谈全链路压测
测一测 (1讲)
测一测 | 这些软件测试题目，你都掌握了吗？
结束语 (1讲)
结束语 | 不是结束，而是开始
软件测试52讲
登录|注册
44 | 测试先行：测试驱动开发(TDD)
茹炳晟 2018-10-08
你好，我是茹炳晟。今天我和你分享的主题是“测试先行：测试驱动开发（TDD）”。
通过上一篇文章，我们已经深入理解了什么是探索式测试，以及如何用探索式测试开展具体的测试。今天我这次分享的目的，就是和你聊聊软件测试领域中的另一个很热门的话题：测试驱动开发，也就是 Test-Driven Development，通常简称为 TDD。
听上去有些迷惑是不是？测试怎么可能驱动开发呢？在传统软件的开发流程中，软件开发人员先开发好功能代码，再针对这些功能设计测试用例、实现测试脚本，以此保证开发的这些功能的正确性和稳定性。那么，TDD 从字面上理解就是要让测试先行，这又是怎么一回事呢？
确切地说，TDD 并不是一门技术，而是一种开发理念。它的核心思想，是在开发人员实现功能代码前，先设计好测试用例的代码，然后再根据测试用例的代码编写产品的功能代码，最终目的是让开发前设计的测试用例代码都能够顺利执行通过。
这样对于开发人员来说，他就需要参与到这个功能的完整设计过程中，而不是凭自己想象去开发一个功能。他有一个非常明确的目标，就是要让提前设计的测试用例都可以顺利通过，为此，他先实现测试用例要求的功能，再通过不断修改和完善，让产品代码可以满足测试用例，可以说是“小而美”的开发过程。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件测试52讲》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(21)
秦浩然虽然 TDD 并不适合所有项目，但是将 TDD 思想放大到整个开发流程上，我总结了一套开发流程，请大家参考。
所有人员参与需求评审 -> 测试人员编写测试用例 -> 所有人员参与用例评审 -> 开发人员按照测试用例进行编码 -> 开发人员执行用例，进行自测，所有用例通过后 -> 开发人员提测 -> 测试人员进行测试。
其中的好处个人觉得主要有两点：
1. 在编码前完成测试用例，可减少开发中需求变更带来的风险。因为在写测试用例的时候，会对需求进行深度分析，思考需求是否合理，在我的经验中，测试组一定会发现不合理的需求，如果这些不合理的需求在编码前就被发现，后面返工的几率就小很多；
2. 在自测环节，开发人员保证所有用例都通过，可以减少测试环节的轮次。因为如果提测质量太差，会增加测试人员和开发人员沟通成本，如果一些基本问题能在自测环节解决，那测试人员会有更多精力放在探索性测试、压力测试、整体功能回归等测试中。
总而言之，如果能达到“缩短发布周期，提高发布质量”的目的，都是好方法。2019-04-09 5 11
叶夏立tdd怎么样做才能落实到项目中，我觉得这才是核心问题，当然不是所有的项目都适合tdd。不知道茹老师是否能分享一下tdd落地推动的做法？作者回复: 很高的问题，首先就像你说的，不是所有的项目都适合tdd，而且采用tdd对测试人员的要求会很高。我的建议是一些小型的poc项目，或者是功能相对单一的微服务开发是比较适合tdd的。另外，要推动tdd，一定需要改革整个研发的流程，这个往往是十分困难的，也正是这个原因，实际开展tdd的项目也不是很多。
2018-10-08 3
刘海贤做到TDD这样的流程，目前国内我是不知道有哪些公司。另外，这样的研发改革，是不是开发可有可无了？因为实现这些功能测试同学都可以去完成了哈。。。2019-08-10 1
a坚果有一本书就是《测试驱动开发》，老外写的，使用python需要，TDD的思想开发的一个项目，对这方面有需要了解和学习的可以去看看。
欢迎大家关注我的微信公众号「软件测试艺术」，一起交流，一起学习。2019-06-07 1- 秦浩然确实要考虑项目的适用性，如果对于试水项目、用户需求不确定的，就不太合适了。后期需求频繁变更的话，测试的维护成本也是很高的。2019-04-08 1
我是谁tdd感觉就是详细的单元测试，那对于测试用例的项目建立，包括持续集成，都是由测试来做。开发人员是不是就不需要写单元测试了，那开发自测用测试人员写的测试用例吗，是拉去测试这边项目吗2019-02-18 1
涅槃Ls打卡44，国庆节后 好好学习作者回复: 支持打卡👍
2018-10-09 1
伪专家没有强的coding能力，不行的作者回复: 是的，tdd一定要求有很好的代码能力。
2018-10-08 1
仰望星空老师讲的很系统，每篇都听，几乎涵盖了测试的方方面面。有一点就是设计安全性方面的测试能否也讲一讲呢作者回复: 感谢支持，后面马上会有讲渗透测试的文章
2018-10-08 1
GzTDD这件事情实话我觉得应该是在开发自己对业务更加了解的情况下来做，现在的情况下“测试”驱动开发的话之前需要定义好规则尤其在GUI测试上，相对来说接口也还好因为前置条件是后端开发出接口文档，那么这个就是测试依据，也就是说能够先出用例，然后上持续集成平台让开发自己上测试服务自己进行测试 。在通过所有用例以后基本上也就能快测试了。2019-10-29
Kelly实施过程中2的测试不太理解怎么执行，此时开发代码都没写出来。2019-10-10- Geek_905bf9那么想问下，用例变成需求了，那么产品人员呢？需求文档呢？是不是就可以粗糙的写了呢？2019-07-10
wangq会不会增加代码量，延长代码开发周期？理论上讲整体交付时间应该不会影响甚至提前2019-07-10
口水窝对于TDD，我有两点要说。1是TDD对于测试人员的要求较高，至少要会百合测试，而且测试用例的粒度，是否有遗漏，测试用例代码通过率都有要求，这对于很多企业都觉得测试职业都是点点点的公司来说，根本做不到，而且从领导层面上都没有这个意识去落实的。2是TDD的推动要从领导层，甚至公司技术部的最高层从上而下去推动，这才是最难执行的，这一点也和作者想法一样，所以现实中很多无法实现。2019-05-17
subonatdd测试代码都是单元测试了吧作者回复: 都是直接面向代码的
2018-12-24
小老鼠您是不是把TDD、BDD、ATDD混在一起了😄作者回复: 本质上这三个是不同层面的东西，但是出发点和思路是异曲同工的
2018-11-29
郭小菜个人认为先写测试代码比较适合单一场景，如果是较为复杂业务场景先去写测试代码是很复杂的，测试代码的数量甚至多余系统代码2018-11-07
木宇寒影如果代码能力不高，测试驱动开发可以先从excel用例入手，先保证开发出的功能都是符合要求的2018-10-29
喵呜呀呵嘿🌈测试人员的综合能力强于开发人员，感觉TDD会更好推行也适合使用。相反则不然吧。2018-10-15
~黑凤梨~我们WEB项目也在要求做TDD，并将TDD与现有的CICD（其实只有CD）结合，不知道具体如何来管理TDD的test case那些东西。希望老师指点一下，谢谢。作者回复: 严格来说，前端项目不一定适合tdd，更适合的应该是bdd，当然和jenkins之类的工具结合本身的确是个好方法，这种情况下，测试用例也都需要通过代码仓库来集中版本化管理
2018-10-09
收起评论