写点什么

测试计划驱动开发模式 TPDD:一种比 TDD 更友好的开发模式

  • 2018-11-13
  • 本文字数:3920 字

    阅读完需:约 13 分钟

测试计划驱动开发模式TPDD:一种比TDD更友好的开发模式

你所在的开发团队使用 TDD 吗?


——想必很多人的回答是肯定的,与此同时,还有很多开发团队都 对外声明 在使用 TDD 开发模式。


之所以说是“对外声明”,是因为很多开发团队虽然号称使用的是 TDD 开发模式,实际开发过程中却无法满足 TDD 的要求。


实际上,测试驱动的开发模式确实有效,它将可能发生的问题用测试代码预先解决,只有通过测试代码后的代码才是可以接受。当前有很多公司都在应用 TDD,但 TDD 并不是一个开发者友好的开发模式,只是一个理想化的开发模式。

为什么 TDD 不是一个开发者友好的开发方式?

大家都知道 TDD 是什么,可是试问所有的开发者能保证每次开发过程中会满足 TDD 的要求吗?


听听大家的声音:

  • 测试也只是保证脑内想法转成代码的时候,逻辑自洽

  • Lots of people on the internet talk about how good TDD is, but people were afraid to say it wasn’t working for them.

  • 没有 deadline 的威胁,我很喜欢 TDD,但是过度测试是存在

  • 大多数程序员还不会写测试用例

  • 看起来容易,但是做起来难

  • Yes. TDD 该死。TDD 死了,T 才能正常 T,程序员做正常人,团队做正常团队。TDD 死,不是因为程序员达不到它的要求,是它没打算尊重程序员,尊重开发实际。TDD 本末倒置的价值观,非生产代码统治生产代码,没理解问题就想对问题高屋建瓴,TDD 是码农界的纳粹,流程方法论原教旨主义。

  • TDD 是否已死先不说,很多程序员连写出基本的整洁代码都做不到,还能指望他先写测试吗

  • 新手看到 TDD 会欢欣鼓舞,但是他们没有能力来实践。老手们在项目的压力下,早就麻木了,先写 case 还不如写好代码再补 case 呢,很多东西我还没时间想清楚,怎么写 case?不如先写个小功能先,边写边改

  • 其实我们所有一切的目的是为了快速的交付有价值,有质量的产品或者服务,赢得公司的生存和发展空间。为了达到这个目的,我们有很多种的手段。但手段不是目的。

  • 以国内的敏捷实践来讲,完全达不到 TDD 的要求

  • TDD 力量和问题都源自 test first。要能 test first,写代码之前要想得更清楚;代码得要有良好的可测试性

  • 导致其写的代码是为了满足测试的,而忽略了代码质量和实际需求

  • 不过,我还真是见过使用 TDD 开发的不错的项目,只不过那个项目比较简单了。更多的情况下,我看到的是教条式的生硬的 TDD,所以,不奇怪地听到了程序员们的抱怨——“自从用了 TDD,工作量更大了”。当然,这也不能怪他们,TDD 本来就是很难把控的方法。

  • 等等等等

来自于网络


我相信很多人都做不到,现在更多的开发者做的更多的是 Unit Test,就是写业务代码完了之后再写(单元)测试,而这个 Unit Testing 单元测试与 TDD 测试驱动开发 的结果一致,即两者都保证了功能通过了测试,两者结果一样为什么还给自己添麻烦,提前写测试代码呢?


还有些开发者由于水平不足;或是不会测试;有些项目非常紧急根本没时间做测试。


很多开发者都很反感 TDD,至少是在潜意识中很反感(除了自身每天用不着 TDD 那些人); 试想你在小时候,每天上学前妈妈都会在耳边絮叨都要你小心,然后告诉你每一步的步骤,每一步都要正确,有时候真的很烦,于是我们左耳朵进右耳朵出,就会不耐烦的说“好了,好了,我知道了”;程序员也是一样的,对于很繁琐的一些开发模式他们会糊弄过去,方法之一就是先写完业务代码,完成业务再说测试,写完后再写单元测试,把 TDD 给搪塞过去。


可是你知道你妈妈对你是好的,而且她在养你,所以就没说什么;程序员和公司的关系与之很相似,公司也在养你,它希望你写的代码是好的,是可靠的,所以它要求你用 TDD 的方式编写代码。


TDD 看似有效,但是开发者的普遍不愿意做,并且很容易造假(很多人都是先写完代码,再写测试代码),而且无法监督开发者是否采用 TDD 这种开发模式,也就是说 TDD 是理想化的开发模式,如果要执行起来是最好不过的,但是真正严格执行的团队又有多少呢?确定所有的开发人员都严格执行吗?


由此得知,TDD 是非常理想化的开发模式,只有特定的程序员、团队、产品和公司才适合这种理想化的开发模式

除了 TDD,我们还有哪些替代方案?

有,目前有种开发模式正在被一些公司的部门使用,就是 Test Plan Driven Development,即测试计划驱动开发模式,或是 Test Pre-Requisition Driven Development,即测试前提驱动开发。

TPDD 到底是什么?

相比每次开发之前先写测试代码,我们可以让开发人员参与编写测试计划,也就是说,在收到项目需求时,开发者需要帮助测试人员根据项目需求思考测试计划,并起草 测试计划 A (或者叫做开发承诺-Development Promise),然后再进行开发。



由于开发者需要跟测试人员合作,开发者相对于测试人员更加了解项目需求,测试计划更多的依赖于开发者,而测试计划、开发承诺是受到审查的;所以也造不了假,对于团队 lead 负责人而言是可监控、可调查的。

适用对象

  • 不喜欢怎么 TDD 开发模式的开发者,和相关的团队和企业

  • 没有严格要求按照 TDD,然而对外声称使用 TDD 开发模式的开发者,和相关团队和企业

  • 执行了 TDD 这种开发模式,然而质量没有明显的提高的团队和企业

  • 使用 TDD 导致开发效率降低的团队和企业

  • 开发者不喜欢 TDD 这种开发模式,嫌麻烦,但是还想要保证代码质量的团队或企业

  • 开发者没有足够的能力进行 TDD 的团队和企业

  • 产品的截止日期很紧张的企业

  • 初创团队和企业

  • 正在上升期的团队和企业

  • 还没有应用 TDD 这种开发模式,但是准备使用 TDD 的团队或企业

什么是开发承诺和测试计划 A

开发承诺类似于 design doc,不过其中讲述了开发者必须完成的功能,需要做的功能以及可选做的功能,并且还提供了测试人员需要做的事情。


开发承诺 — 测试计划 A 如下所示:


  • Must Have – Critical Check Points

  • 必须要全部完成的功能点,不完成工作没有完成

  • 测试人员重点测试的功能点,并且 adhoc test,有能力的团队需要加入自动化测试

  • Need Have – Important Check Points

  • 重要的功能点,必须要完成绝大部分的功能,没有完成绝大部分,工作没有完成

  • 测试人员重点测试的功能点

  • Should Have – Optional Check Points

  • 可选的功能,开发者可选

  • 测试人员手动测试

开发承诺和测试计划 A 有什么作用?

  • 开发承诺 测试计划 A 的第一个作用是,开发者(测试者)对于任务的优先级有很清晰的认识

  • 为了给开发者自己看的(或是其他开发者,假如开发者离职或是请假,其他开发者就可以看测试计划迅速开发),作为开发时的指导手册,这样开发者的头绪就更加清晰,也知道任务的优先级----先做什么,后做什么。

  • 为了给测试人员看的,作为测试的指导手册,这样测试人员就知道什么功能需要重点测试、什么东西需要进行实验性的测试,以及什么功能需要实现测试自动化以便于加入到 CI 和 CD 之中。

  • 开发承诺 测试计划 A 的第二个作用是,承诺使开发者的开发过程更加小心

  • 将测试计划 A 交给测试人员和开发组长,利用心理学中“承诺”作用,使自己的言行和承诺一致。这样的话,开发人员就知道自己的 code 至少要满足什么条件,至少要过什么样的测试,所以开发时会更加小心,代码的质量和可靠性也会得到很高的提升。

  • 开发承诺 测试计划 A 的第三个作用是,促进测试人员的工作进度,使测试人员有更多的时间进行自动化、adhoc 测试或是运维方面的工作

  • 测试人员会根据测试计划 A 起草测试计划 B,只需要在测试计划 B 中添加如何进行测试即可。


参考:一旦我们做出了某种承诺,或是选择了某种立场,就会在个人和外部环境的压力下,迫使自己的言行与承诺保持一致,尽管这种行为有悖于自己的意愿。

TDD 和 TPDD 有什么区别?

TDD 的优缺点

TDD 是先写测试代码,判断业务代码是否可以通过测试代码。看似有效,但是开发者的普遍不愿意做,或是完成度很差,或是做了之后导致没有按时完成任务;并且很容易造假,很多人都是先写完代码,再写测试代码;或者测试代码质量不高;或是测试用例不好。


对于管理者而言,他们无法监督开发者是否有效的沿用 TDD 这种开发模式,完全体现不了 TDD 的优势。

TPDD 的优缺点

  1. 提高代码质量

  2. TPDD 是先写开发承诺,使开发者对测试用例和测试环境有清晰的认识,思维会更加清晰有条理;并且由于承诺的心理作用,开发者会潜移默化的提高代码质量。

  3. 可监控和不可造假

  4. 因为测试人员需要根据开发者的开发承诺编写测试计划,可以使管理者很直接的监督开发者是否采用 TPDD 这种开发模式(通过审查开发承诺),所以不可能造假。

  5. 有时间进行其他方面的提升,例如自动化、运维等

  6. 由于开发者和测试者已经将基本的开发承诺—测试计划 B 写出来了,对于测试者来说将会用更少的时间做功能的理解和测试的准备,这将给测试人员更多的时间进行 adhoc 测试、自动化测试或是运维功能的开发和维护。

  7. 更好的接受 TDD

  8. 由于开发者已经接触了测试,使用 TPDD 后的团队会更好的接受 TDD,这时 TPDD 又可以被称为 Test pre-requisition Driven Development

  9. 对开发者友好

  10. 相对于每次开发之前写测试代码,只需要与测试人员想出测试用例,对于开发者来说这是更加容易的

  11. 对测试人员友好

  12. 因为与开发者的直接合作,测试的准备的难度大大的降低,测试计划和测试用例的思考时间缩短,并且有时间空余去做一些自动化或是运维方面的工作。

  13. 对管理人员友好

  14. 由于开发承诺和测试计划的实体化,管理人员就可以提前进行审查,而不是等待开发结束后进行代码审查(code review)

参考链接

TDD is dead. Long live testing.

Is TDD Dead?

TDD(测试驱动开发)是否已死?

TDD并不是看上去的那么美

心理学参考 之 承诺和一致原理

作者介绍

臧嘉玮 Vigor Zang,TPDD 的发明者和布道者,主要研究方向为自动化系统和 Web Development。曾就职于 IBM Watson Commerce 组,主要负责自动化测试和前端开发,任职期间受 Watson Commerce Insight 组的邀请,负责测试流程和测试基础设施的建设,包括测试框架、测试工具和性能检测和预警系统的架构、开发和维护。


2018-11-13 07:203472

评论 5 条评论

发布
用户头像
程序员与生俱来不喜欢写TestPlan,喜欢Coding,TPDD可能也只是一种理想化的方案,实施过程中还是要需要管理者通过行政手段或绩效考核去驱动大家写好的TestPlan。另外,写TestPlan也是需要经过培训、训练和积累才行。每个程序员的主观意志和客观能力不同,写出来的TestPlan的质量也会不同。
2018-12-03 09:50
回复
您说的有道理,是的,基本所有的Development方法都是理想化的方案,程序员与生俱来不愿意跟一些不懂技术的交流(ATDD),程序员不愿意写测试(TDD),等等,他们只喜欢code。TPDD是开发人员引导测试人员的测试计划的实施,测试计划的还是属于测试人员主要负责的;开发人员参与到了测试计划初期的制定的过程中;再谈管理者的管理,我觉得在管理者素质很高(懂技术不添乱)的情况下,管理者的参与和监督对于产品开发是有利的,可以促使开发和测试变得更好,反之,则是有害的。当然了,我同意您的观点,有些程序员之间的能力差别实在是太大了,TDD对于程序员来说要求太严苛,TPDD是折中的一个选择。当然了,有这些标准比没有标准要强,不是么?
2018-12-03 17:01
回复
用户头像
历史性时刻到了,非常棒!
2018-11-13 12:41
回复
用户头像
这个跟 ATDD 有啥区别?
2018-11-13 11:16
回复
TPDD与ATDD有相似点,TPDD不仅将客户、测试者和开发者加入进来,它也将管理者(或Tech lead)参与进来,管理者通过TPDD可以更好的对测试用例和开发优先级进行管理,也可以将其作为KPI、OKR的标准。

TPDD完全可以和ATDD一起使用。

有一个情况,ATDD在有些情况很难实施,就是业务客户和开发者、测试者没法直接的进行交流,而是一些tech lead或是manager与之交流,还是有点mis-communication的问题,而TPDD恰巧解决了该问题,即,通过管理者的介入和监管。
展开
2018-11-13 12:25
回复
没有更多了
发现更多内容

IPQ9574-Four M.2 Connectors Platform|Wallys Industrial WIFI7 Solution

wallyslilly

WiFi7 ipq9574

schema registry口令认证配置

Shen-Xmas

kafka Bigdata dba schema schema registry

科兴未来|中国•湖州海外青创大赛全面开启!

科兴未来News

环保 #双创赛事# 新能源行业 湖州

2023银川市等级保护测评中心地址在哪里?有几家?

行云管家

等保 等保测评 等级测评 银川

软件测试/测试开发丨Python内置库学习笔记

测试人

Python 软件测试 io 科学计算 内置库

低代码渲染那些事

阿里技术

低代码 渲染

LED广告机的市场趋势和发展前景

Dylan

媒体 广告 数字 LED显示屏 市场

VLDB2023|方略:一个交互式的规则研发系统

AI Infra

程序员 AI 开发者 AI大模型 大模型时代

mysql

ltc

MySQL

HTML5 游戏开发实战 | 推箱子

TiAmo

html html5 6 月 优质更文活动

一文读懂火山引擎A/B测试的实验类型(3)——多链接实验

字节跳动数据平台

对线面试官-Redis(内存消耗的问题)

派大星

Java 面试

AIGC+任务管理|给既定目标一个“精准打击”

TE智库

人工智能 任务管理 AIGC 生成式AI

【网易云信】已开源!网易云信的热点探测平台实践

网易智企

开源 热点探测

第十四届夏季达沃斯论坛|英特尔王锐:AI驱动工业元宇宙,释放数实融合无穷潜力

E科讯

从Kafka中学习高性能系统如何设计 | 京东云技术团队

京东科技开发者

云计算 kafka 高性能 企业号 6 月 PK 榜

融云出海:TikTok 百亿美元投向东南亚,巨头将如何影响市场格局

融云 RongCloud

产品 运维 出海 市场 通讯

幂律智能联合智谱AI发布千亿参数级法律垂直大模型PowerLawGLM

人称T客

G1垃圾回收参数调优及MySQL虚引用造成GC时间过长分析 | 京东云技术团队

京东科技开发者

MySQL G1 GC 企业号 6 月 PK 榜

Gateway 实现网关聚合查询

2756

英特尔宣布极光超级计算机安装完成,将于2023年末正式上线!

E科讯

https 原理分析进阶-模拟https通信过程

蓝胖子的编程梦

https TLS SSL证书 ssl SSL/TLS 协议

inBuilder今日分享丨开源许可协议简介

inBuilder低代码平台

推荐几款可以大幅提高开发效率的vscode插件 | 京东云技术团队

京东科技开发者

Vue 前端 vscode

一文搞定PCB元器件的布局布线

华秋PCB

元器件 PCB 布局 PCB设计 布线

什么是HTML?

TiAmo

html html5 6 月 优质更文活动

(信息化,数字化,智能化)这是三种不同的概念吗?

优秀

数字化 信息化 智能化

用华为云低代码Astro Zero10分钟搭建 “图书馆数据可视化大屏” 应用

华为云PaaS服务小智

软件开发 低代码 华为云

聊聊测试团队的基础架构建设

老张

质量保障 基础设施建设 基础架构

行业首个多重节律照明!三翼鸟“亮”在哪?

脑极体

智能照明

基于OpenHarmony开发的玻璃拟态天气应用(3)构建天气组件并实现毛玻璃效果

路北路陈

前端 HarmonyOS OpenHarmony应用开发 6 月 优质更文活动

测试计划驱动开发模式TPDD:一种比TDD更友好的开发模式_软件工程_臧嘉玮_InfoQ精选文章