软件测试方式应该倾向哪一种？
１.测试驱动开发（Test-Driven Development）
测试驱动开发不同于传统测试开发，编写某个功能的代码之前先编写这个功能的测试代码，然后再编写使测试通过的代码功能。
通过测试来推动开发。
测试驱动开发帮助了代码简洁且可用，也是在软件开发中主流的测试方法。
２.单元测试（Unit Test）
单元测试也叫模块测试，是针对程序模块来进行测试的代码模块。
测试驱动开发中编写的测试代码就是单元测试。
所以，测试驱动开发中单元测试占很大一部分。
不过这也根据团队中对测试部分的指标决定，这个指标就是代码覆盖率。
3.代码覆盖（Code Coverage）
代码覆盖是软件测试中的的一种度量，描述程序中源代码的测试比例。
一般来讲，这个要根据不同的任务和不同的团队指标来定，像 80% 或更多。
4.集成测试（Integeration Test）
集成测试也叫组装测试。
在单元测试的基础上，将能运行的模块代码，按照设计要求组装成系统，进行集成测试。
5. 端到端的测试（End to End Test）
端到端的测试是从应用程序流的角度进行测试，模拟用户真实使用场景，也可以称作自动化测试。
例如，用 puppeteer 模拟真实用户，来测试网页开发。
以上都是一些名词的简单介绍，后面会介绍它们之间的关系。
6. 金字塔测试模型
马丁（ Martin Fowler ）在他的文章中介绍了软件测试中的测试金字塔，如下。
传统上从端到端自动化测试相对容易，也就是从 UI 端开始进行测试。
相反，测试金字塔从下到上显示，随着我们的测试过程不断上移动，测试代码的编写成本很高且很耗时。
所有，这个模型主张通过做更多的单元测试来进行更多的自动化测试。
当发现一些端到端测试的问题，且单元测试也有问题的时候，应先修复单元测试。
这也对应了测试驱动开发的过程。
7. 奖杯测试模型
肯特（ Kent C. Dodds）在 2018 年发布了他们团队使用的模型，奖杯测试模型 。
这个模型更多的侧重于集成测试。
在单元测试与集成测试之间，奖杯模型提供了很好的平衡。
从测试能实现某个功能，到某个功能被直接使用。
这也增加了开发人员的信心和开发速度，减少了花费在单元测试上的时间。
比起更多的单元测试，奖杯模型更倾向测试开发人员的信心。
此外，不像单元测试那样有繁琐的测试代码的维护成本。
例如开发人员改变一个函数的功能，这模块的测试代码也要进行修改。
考虑到代码与模块间的耦合性，大多是单元测试代码可能是浪费的。
8.如何选择？
解释了这么多，终于到最后一部分了。
开发人员如何选择呢？
- 没有人会质疑测试软件是浪费时间，所以使用无论哪种方式，目的是为了更有效率的进行测试。
- 没有哪种测试方式是绝对好的，这完全取决于开发人员要开发什么样的项目，以及项目目的是什么。例如，肯特即便发布了他们的奖杯模型，也在他的演讲中表明，集成测试更高效且产品回报率也更高（以不同模块之间能用为目的）。但在他自己开源的一些小项目中，测试代码覆盖率接近100 % 也就是单元测试占比更多。
- 寻找平衡测试人员可能编写更多的单元测试在一个只影响 0.1% 用户的功能上，导致整体开发进度减慢。相反，甲方可能更关注开发的软件能不能用，按时交付。所以要根据不同软件项目周期和要求，选择不同的测试方式。
我是迪文，如果你喜欢这篇文章，点赞收藏是对我最大的鼓励。
版权归原作者 Steven迪文 所有， 如有侵权，请联系我们删除。