[开发测试] 软件测试方式应该倾向哪一种？

１.测试驱动开发（Test-Driven Development）

测试驱动开发不同于传统测试开发，编写某个功能的代码之前先编写这个功能的测试代码，然后再编写使测试通过的代码功能。

通过测试来推动开发。

测试驱动开发帮助了代码简洁且可用，也是在软件开发中主流的测试方法。

单元测试也叫模块测试，是针对程序模块来进行测试的代码模块。

测试驱动开发中编写的测试代码就是单元测试。

所以，测试驱动开发中单元测试占很大一部分。

不过这也根据团队中对测试部分的指标决定，这个指标就是代码覆盖率。

代码覆盖是软件测试中的的一种度量，描述程序中源代码的测试比例。

一般来讲，这个要根据不同的任务和不同的团队指标来定，像 80% 或更多。

集成测试也叫组装测试。

在单元测试的基础上，将能运行的模块代码，按照设计要求组装成系统，进行集成测试。

端到端的测试是从应用程序流的角度进行测试，模拟用户真实使用场景，也可以称作自动化测试。

例如，用 puppeteer 模拟真实用户，来测试网页开发。

以上都是一些名词的简单介绍，后面会介绍它们之间的关系。

马丁（ Martin Fowler ）在他的文章中介绍了软件测试中的测试金字塔，如下。
在这里插入图片描述

传统上从端到端自动化测试相对容易，也就是从 UI 端开始进行测试。

相反，测试金字塔从下到上显示，随着我们的测试过程不断上移动，测试代码的编写成本很高且很耗时。

所有，这个模型主张通过做更多的单元测试来进行更多的自动化测试。

当发现一些端到端测试的问题，且单元测试也有问题的时候，应先修复单元测试。

这也对应了测试驱动开发的过程。

肯特（ Kent C. Dodds）在 2018 年发布了他们团队使用的模型，奖杯测试模型 。

这个模型更多的侧重于集成测试。

在单元测试与集成测试之间，奖杯模型提供了很好的平衡。

从测试能实现某个功能，到某个功能被直接使用。

这也增加了开发人员的信心和开发速度，减少了花费在单元测试上的时间。

比起更多的单元测试，奖杯模型更倾向测试开发人员的信心。

此外，不像单元测试那样有繁琐的测试代码的维护成本。

例如开发人员改变一个函数的功能，这模块的测试代码也要进行修改。

考虑到代码与模块间的耦合性，大多是单元测试代码可能是浪费的。

在这里插入图片描述

解释了这么多，终于到最后一部分了。

开发人员如何选择呢？

没有人会质疑测试软件是浪费时间，

所以使用无论哪种方式，目的是为了更有效率的进行测试。
没有哪种测试方式是绝对好的，这完全取决于开发人员要开发什么样的项目，以及项目目的是什么。

例如，肯特即便发布了他们的奖杯模型，也在他的演讲中表明，

集成测试更高效且产品回报率也更高（以不同模块之间能用为目的）。

但在他自己开源的一些小项目中，测试代码覆盖率接近100 % 也就是单元测试占比更多。
寻找平衡

测试人员可能编写更多的单元测试在一个只影响 0.1% 用户的功能上，导致整体开发进度减慢。

相反，甲方可能更关注开发的软件能不能用，按时交付。

所以要根据不同软件项目周期和要求，选择不同的测试方式。