产品战略专家梁宁确认出席AICon北京站,分享AI时代下的商业逻辑与产品需求 了解详情
写点什么

测试计划驱动开发模式 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:203504

评论 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
回复
没有更多了
发现更多内容

阿里巴巴API返回值全解析:轻松掌握1688店铺商品信息

代码忍者

API 接口 pinduoduo API

配置 GreptimeDB 作为夜莺监控数据源,无缝替代 Prometheus/VictoriaMetrics

Greptime 格睿科技

Prometheus 时序数据库 Victoriametrics

应对市场和竞争对手变化的实用指南

爱吃小舅的鱼

市场 竞争 应对市场和竞争对手变化

鸿蒙网络编程系列41-仓颉版HttpRequest模拟登录示例

长弓三石

DevEco Studio 开发实例 HarmonyOS NEXT 网络与连接

ARB链挖矿DApp系统开发模式定制

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 公链开发 代币开发

未来已来:人工智能赋能软件开发新篇章

天津汇柏科技有限公司

人工智能 软件开发

从数据提取到管理:合合信息的智能文档处理全方位解析【合合信息智能文档处理百宝箱】

申公豹

人工智能

浅谈指标平台的价值:赋能企业决策、加速业务响应与提升技术效率

Aloudata

数据仓库 数据分析 指标平台

Sound Control for Mac 强大的音量控制软件

Rose

OmniGraffle Pro:绘图巅峰,设计卓越!

Rose

什么是触发器?

Chat2DB

MySQL 数据库 sql 开源

麦肯锡8步框架:提升你的问题解决能力

爱吃小舅的鱼

项目管理 项目

企业如何同时维护旧系统与开发新产品

爱吃小舅的鱼

维护旧系统与开发新产品

总计 30 万奖金,Spring AI Alibaba 应用框架挑战赛开赛

阿里巴巴云原生

阿里云 开源 云原生

百度智能云携手面壁智能,深化大模型端云协同合作

Geek_2d6073

Topaz Gigapixel AI破解版下载 Topaz Gigapixel AI安装包分享

Rose

IPQ5322 vs. IPQ9574: Choosing the Right Chipset for Enterprise Wi-Fi

wallyslilly

ipq9574 ipq5322

Serverless + AI 让应用开发更简单

阿里巴巴云原生

阿里云 Serverless 云原生

PDF如何一键转为PPT?10个好用的格式转换工具汇总!

职场工具箱

效率 效率工具 PPT 办公软件 AI生成PPT

Tampermonkey for Mac(油猴Safari浏览器插件)功能介绍

Rose

软件测试学习笔记丨测试平台的价值与体系

测试人

软件测试 测试平台

BOE(京东方)全新一代发光器件赋能iQOO 13 全面引领柔性显示行业性能新高度

爱极客侠

如何在汽车中构建一个时序数据库 (TSDB)?

Greptime 格睿科技

边缘计算 时序数据库 新能源汽车

【FAQ】HarmonyOS SDK 闭源开放能力 —Push Kit(5)

HarmonyOS SDK

HarmonyOS

从前线看IT集成项目:三年管理经验

爱吃小舅的鱼

项目管理 管理项目

网易伏羲:智能体驱动 未来可期 | 《天堂硅谷》杂志报道

网易伏羲

AI 网易伏羲 AI 人工智能

AI校园新星直通车再启动:Zilliz助您踏上开源舞台

Zilliz

AI 开源社区 Milvus Zilliz

论文领读|tDRO:面向大模型稠密检索的任务级分布鲁棒优化

澜舟孟子开源社区

人工智能 大模型 技术论文

BOE(京东方)2024年前三季度净利润三位数增长 “屏之物联”引领企业高质发展

科技热闻

App Cleaner & Uninstaller Pro for Mac(苹果应用程序清理卸载软件)

Rose

MindNode,一键开启思维整理新模式!

Rose

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