咨询电话

首页 > 最新资讯 > 正文

你没有足够的测试,你永远不会! 置顶

发表于2017-03-10 09:49:34 次查看

你永远不会有足够的测试来捕获所有可能出错的测试 - 但是通过正确的测试策略和设计,你可以生产出高质量的软件。

 

 

问任何软件开发商,如果他们的应用程序有足够的测试和机会,他们会说不。通常,他们会觉得他们必须证明这种缺乏测试的理由。

为什么这是规范,我们应该怎么做呢?

测试的问题

软件团队越来越面临着提供高质量软件的压力,同时仍然领先于竞争对手。发布buggy软件和用户将很快切换 - 但缺乏竞争对手提供的功能,你将有吸引新用户的麻烦。

Buggy软件

软件测试的传统观点是,早期你可以找到一个bug,更便宜的是修复。如果开发者在编写代码后不久发现了一个错误,他们可以快速修复它; 如果在生产中发现错误,则需要诊断,修复并重新验证和发布软件,这可能是一个昂贵的过程。

无论您是执行单元测试,集成测试还是系统测试,都必须在成本和测试提供的价值之间取得平衡。

单元测试

单元测试旨在将代码分解成小的逻辑单元,然后与其余代码隔离测试该功能。它通常由开发人员执行,并允许他们验证他们的代码按照他们的期望工作,以及测试在后续测试阶段难以生成的边界情况。

许多软件团队非常重视编写很多单元测试,因为早期捕获错误可以节省时间和金钱。然而,这些测试写入很费时,通常难以理解和维护,而且太低级别无法捕获代码库中的逻辑错误。

集成测试

应用程序的各个模块可以集成在一起并作为一组进行测试 - 这是集成测试。在这个级别,可以在上下文中测试整个特征,并发现逻辑错误。当代码重构时,集成测试可能很脆弱,并且可能需要花费大量的精力来解决。与单元测试一样,它们的写入代价很高,并不一定非常适合查找边缘情况。

系统测试

一旦所有软件已经写入,系统测试就会执行。其目的是确保整个系统按预期运行,可用,稳定和安全。这通常涉及许多手动特别测试以及自动测试,这使得难以在每个版本上执行一致的测试。这使得bug更容易通过裂缝滑动。

触动平衡

测试困难,软件复杂。无论你做多少测试,总是会有错误,找到自己的方式到你的发布。那么,什么是最好的测试策略?

许多软件团队试图测量正在进行的测试; 这可能导致无用的测试策略,如在单元测试中100%线覆盖。即使实现了良好的覆盖,您可能正在测试错误的行为,测试本身可能是错误的或没有实际验证结果的预期。

为了提出一个有用的测试策略,提高你的代码的质量,你首先必须回答这个问题,“我想要我的测试实现什么?”这个问题的答案可以很大程度上取决于上下文例如在自驾车上的错误比在游戏中的错误更多),但通常的答案是,你想要的最终用户经历的几个错误,没有严重的缺陷,可能会影响安全性或完整性。

自驾车臭虫

以下是在创建测试策略时应考虑的一些事项。

专注于什么是重要的

更多的测试不一定等同于更少的错误,但是针对测试工作在正确的地方可以使代码质量真正的区别。下面是一些测试可以产生影响的领域的例子:

  • 复杂逻辑。 在逻辑非常复杂或复杂的区域中的错误可能是微妙和难以诊断,回归很难发现。这些区域应进行更详尽的测试。

  • 公共可访问接口。 确保可以公开访问的接口只做他们打算做的事情。这包括验证请求是否经过适当验证,以避免接口返回比预期更多的信息或以无意的方式修改数据。

  • 高影响代码。在对用户有最大影响的领域进行重点测试。小百分比的用户使用的功能可能不如核心功能测试重要。

损伤控制设计

最终的bug会发生,但是当他们做你想控制的影响。您可以在代码级别执行此操作,例如在适当的情况下处理异常,或在设计级别,例如在修改数据库时使用事务。思考当错误发生时会发生什么,有助于减少错误发生时的严重性。

监视Bug

一旦你的软件在野外,你怎么知道你的测试策略是否工作,如何监控用户的体验?错误监视(例如  Bugsnag)允许您查看发生的错误,并根据特定错误具有的影响程度决定需要修复的内容。您可以专注于固定在生产中实际重要的边缘案例,这在测试期间可能很难发现。

监控bug

您可以使用错误监视功能在出现问题时获得早期警告,这意味着您可以在对用户造成太大干扰之前修复这些问题,甚至在影响显着的情况下甚至还原发布。

软件中的错误是不可避免的,但是能够立即获得关于您的软件在发布后的性能的反馈是有效测试策略中有价值的最后一道防线。

最后的想法

软件是一个复杂的,协作的工作,试图用尽可能少的缺陷生产它是耗时和昂贵的。你永远不会有足够的测试来捕获可能出错的一切,但通过正确的测试策略和设计,你将能够生产出高质量的软件,而不会因为编写和维护太多的测试而陷入困境。

 

在线客服
  • 点击这里给我发消息
  • 点击这里给我发消息
  • 微信扫一扫
  • 官方微信