多少测试覆盖度才算足够

本文探讨了软件测试的合适程度,强调测试应根据软件类型、用途和目标受众来定制。建议包括记录测试流程、建立坚实的单元测试基础、进行充分的集成测试、执行关键用户旅程的端到端测试,并利用现场反馈不断改进测试策略。此外,还提到了性能、安全性和可访问性等其他测试层面的重要性。
摘要由CSDN通过智能技术生成

每个软件开发人员和团队都在努力解决的一个熟悉的问题是,“多少测试足以使软件版本合格?” 很大程度上取决于软件的类型、用途和目标受众。人们会期望一种比简单的智能手机手电筒应用程序更严格的测试商业搜索引擎的方法。然而,无论是什么应用,多少测试才足够的问题很难用明确的术语来回答。更好的方法是提供可用于定义最适合手头案例的认证过程和测试策略的考虑因素或经验法则。以下提示提供了一个有用的标准:

  • 记录您的流程或策略。
  • 有坚实的单元测试基础。
  • 不要吝啬集成测试。
  • 对关键用户旅程执行端到端测试。
  • 了解并实施其他测试层级。
  • 了解您的代码和功能覆盖范围。
  • 使用来自现场的反馈来改进您的流程。

记录您的流程或策略

如果您已经在测试您的产品,请记录整个过程。这对于能够为以后的版本重复测试并对其进行分析以进行进一步改进至关重要。如果这是您的第一个版本,最好有一个书面的测试计划或策略。事实上,任何产品设计都应该有书面的测试计划或策略。

有坚实的单元测试基础

一个很好的起点是编写伴随代码的单元测试。单元测试测试在功能单元级别编写的代码。对外部服务的依赖要么被模拟,要么被伪造。

模拟具有与生产依赖项相同的接口,但仅检查对象是否根据设定的期望使用和/或返回测试控制的值,而不是其正常功能的完整实现。

另一方面,a *fake是依赖项的浅层实现,但理想情况下应该没有它自己的依赖项。*Fakes 提供了比模拟更广泛的功能,并且应该由提供依赖项的生产版本的团队维护。这样,随着依赖项的发展,伪造者和单元测试编写者可以确信伪造品反映了生产依赖项的功能。

在包括 Google 在内的许多公司中,都有要求任何代码更改以使相应的单元测试用例通过的

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值