TDD、BDD、ATDD都是什么、有什么区别?(下)
在《TDD、BDD、ATDD都是什么、有什么区别?(上)》一文中,探讨了探讨TDD、BDD和ATDD的概念。虽然TDD、BDD和ATDD都是软件开发中使用的测试方法,但它们在方法和重点上有所不同。
TDD、BDD和ATDD之间的主要区别在于关注点、抽象层级和协作。
1、关注点
TDD侧重于测试代码并确保它满足需求。BDD关注软件的行为,并确保它满足业务需求。ATDD关注于验收标准,并确保软件满足业务需求。
2、抽象层级
TDD专注于代码级别,并使用单元测试来验证代码的功能。BDD专注于功能级别,并使用场景来描述所需的行为。ATDD专注于验收标准,并使用验收测试来验证软件是否满足要求。
3、协作
TDD主要是一个以开发人员为中心的过程,包括编写测试和代码。BDD和ATDD涉及开发人员、测试人员和涉众之间的协作,以确保软件满足业务需求。
虽然这三种方法有一些相似之处,但它们在方法、范围和目的上有所不同。
1、范围
TDD专注于代码的开发和验证其行为的测试。这个过程从编写一个失败的测试用例开始,然后编写通过测试所需的最低数量的代码,然后重构代码。TDD确保代码在发布之前经过彻底测试并满足要求。
BDD将TDD的范围扩展到包括整个系统的行为。BDD关注的是系统的行为,而不是它的实现细节。BDD场景以一种称为Gherkin的特定格式编写,该格式使用Given When Then语法来描述系统行为的前提条件、操作和预期结果。这些场景作为系统的验收标准,确保团队正在构建正确的东西,并确保系统满足用户的需求。
ATDD侧重于系统的验收标准。该团队合作以自动测试的形式定义系统的验收标准。测试以所有利益相关者都可以访问的特定格式编写,并使用Given When Then语法来描述系统的预期行为。ATDD测试是系统的验收标准,确保团队正在构建正确的东西,并确保系统满足用户的需求。
2、术语
TDD使用术语词汇表,并专注于代码的行为。TDD测试是由开发人员编写的,旨在确保代码的行为符合预期。TDD测试通常使用与测试代码相同的编程语言编写。
BDD使用对业务友好的词汇表,并专注于系统的行为。BDD场景以一种称为Gherkin的特定格式编写,该格式使用Given When Then语法来描述系统行为的前提条件、操作和预期结果。BDD场景通常由业务分析师或产品所有者编写,他们对用户的需求和要求有深入的了解。
ATDD使用对业务友好的词汇表,并专注于系统的验收标准。ATDD测试以所有利益相关者都可以访问的特定格式编写,并使用Given When Then语法来描述系统的预期行为。ATDD测试通常由对用户的需求和要求有深入了解的业务分析师或产品所有者编写。
3、目的
TDD的目的是确保代码在发布之前经过彻底测试并满足要求。TDD测试作为代码的规范,帮助开发人员在开发周期的早期发现bug和缺陷。
BDD的目的是确保团队正在构建正确的东西,并且系统满足用户的需求。BDD场景作为系统的验收标准,确保团队正在构建正确的东西,并确保系统满足用户的需求。
ATDD的目的是确保团队正在构建正确的东西,并且系统满足用户的需求。ATDD测试是系统的验收标准,确保团队正在构建正确的东西,并确保系统满足用户的需求。ATDD测试还推动开发过程,确保代码在发布前经过测试并符合验收标准。
4、方法
TDD遵循自上而下的软件开发方法。它首先编写一个测试用例,然后编写通过该测试的代码。重复该循环,直到满足所有要求。TDD鼓励开发人员编写可测试和可维护的代码,从而获得更高质量的产品。
BDD遵循行为驱动的软件开发方法。它首先以场景的形式定义系统的期望行为,描述系统在不同情况下的行为。这些场景是用一种名为Gherkin的特定格式编写的,该格式使用Given When Then语法来描述系统行为的前提条件、操作和预期结果。BDD场景通常由业务分析师或产品所有者编写,他们对用户的需求和要求有深入的了解。
ATDD遵循与BDD类似的方法,但侧重于系统的验收标准。该团队合作以自动测试的形式定义系统的验收标准。测试以所有利益相关者都可以访问的特定格式编写,并使用Given When Then语法来描述系统的预期行为。ATDD测试通常由对用户的需求和要求有深入了解的业务分析师或产品所有者编写。
总结
测试驱动开发(TDD)、行为驱动开发(BDD)和验收测试驱动开发都是近年来流行的软件开发方法。虽然这三种方法都旨在提高软件质量和减少缺陷,但它们的方法、范围和目的各不相同。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
干货|EasyMR 基于 Kubernetes 应用的监控实践
在之前的内容中,我们深入探讨了 EasyMR 如何利用 Kubernetes 进行部署。大家已经了解到,在 EasyMR 的整体架构中,我们使用 Prometheus 进行节点和服务监控数据的采集、查询和存储。同时,Grafana 作为强大的可视化工具,将 Prometheus 中的监控数据以多样化的方式展示出来。 在本文中,我们将详细探讨在 EasyMR 中如何动态采集 Kubernetes 应用监控数据。 传统采集方案的痛点 在主机模式下,EasyMR 使用 Prometheus 监控的配置主要依赖于 static_configs 和 file_sd_configs。因为在这种部署方案下,节点与应用的稳定性较高,涉及到的变更与不确定性较小,除非出现节点宕机这样的极端情况,我们才需要手动去修改对应采集 Job 配置。 但是在云原生时代的背景下,监控作为可观察性实践中的关键部分,相对于传统架构下的系统和应用监控发生了一些重大的变化: · 微服务和应用容器化导致监控对象和指标的指数级增加 · 监控对象的生命周期更加短暂,导致监控数据量和复杂度成倍增加 通俗来说,就是我们的 Kuberne...
- 下一篇
不是 GPT4 用不起,而是本地运行 Mixtral-8x7B 更有性价比
当 GPT4 刚问世时,社区猜测它用了“多少亿个参数”才实现的如此惊人的性能。 但事实证明,GPT4 的创新不仅仅是“更多参数”。 它本质上是 8 个 GPT 3.5 模型一起工作。 这些模型中的每一个都针对不同的任务(即“专家”)进行了调整。 这称为“专家组合”(Mixture of Experts,缩写为 MoE)。 输入文本根据内容和所需任务会被分派给 8 个专家模型中的一个。 然后,小组中的其他专家模型会评估结果,从而改进未来的问题的分配。 Mistral AI 的 Mixtral 8x7B 是基于 8 个 Mistral-7B 模型的开源 MoE LLM。 借助 WasmEdge,你可以在任意设备上创建并运行该 LLM 的跨平台应用程序,包括自己的笔记本电脑、边缘设备和服务器。 在自己的设备上运行 Mixtral-8x7B 步骤1:通过以下命令行安装 WasmEdge。 curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | bash -s -- --plu...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Hadoop3单机部署,实现最简伪集群
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2配置默认Tomcat设置,开启更多高级功能