陶瓷网站源码,网页制作专业选择,长春一大网站,做公众好号的网站吗任何产品想要长期保持高质量运行#xff0c;集成测试正是实现这一目标必不可少的工具。
本文重点介绍集成测试实现的流程#xff0c;而非测试工具本身。我们的目的是聚焦于创建测试过程中你可能遇到的问题#xff0c;以便你能自主地推进工作。
缺陷的成本
细节决定成败集成测试正是实现这一目标必不可少的工具。
本文重点介绍集成测试实现的流程而非测试工具本身。我们的目的是聚焦于创建测试过程中你可能遇到的问题以便你能自主地推进工作。
缺陷的成本
细节决定成败在软件工程领域这一点尤为真实大多数缺陷都隐藏在细节之中。
然而你是否思考过缺陷究竟是什么或许你会不假思索地回答它是应用程序中的一个错误状态但你可能会感到惊讶因为这个定义并不准确实际上这是对应用程序运行不一致的定义。
确实缺陷表现为一种与预期不一致的行为但并非所有不一致的行为都是缺陷。两者之间的区别在于缺陷必须是外部可观察到的。理解这一点至关重要因为它能帮助我们避免编写无用的测试——这些测试可能会验证一个与预期不一致但并不构成缺陷的场景。 明确了缺陷的定义后你可能接下来会问自己的第二个问题是为什么不让缺陷逃逸并让用户去反馈呢
原因很简单你是否有过需要重做过去已完成任务的经历这难道不令人烦恼吗你需要重新投入进去努力回忆相关细节换句话说你的效率会降低而这种效率的降低是有代价的。
这就是为什么缺陷发现得越晚修复它的成本就越高的一个完美例证。在开发初期发现并修复缺陷比起在产品发布后由用户发现再进行修复所耗费的时间、资源和对用户信任度的影响都要小得多。因此通过集成测试等手段提前捕捉并解决缺陷对于控制成本、提高软件质量和用户满意度至关重要。 这一成本正是我们希望在缺陷尚且廉价且容易修复的早期就发现它们的原因。
验证你是否完成了任务而非你是否工作过。
关于测试我最讨厌的一句话之一就是“你测试过你的代码了吗”大多数开发者不喜欢这句话因为他们将测试视为一种被迫承担的任务而我之所以不喜欢这句话还有另一个原因这句话从根本上就是错误的
良好的意图有时也会导致糟糕的结果这句话就是一个典型例子。当你对另一位开发者说这句话时你的本意是好的提醒他们别忘了测试但你没有意识到的是你也正在引导他们走向一个误区。
在进行测试时你永远不能仅仅测试代码本身而应该测试代码运行是否符合预期。
它并不是检验你的程序是否完全没有缺陷而是检查测试预期与你的代码之间是否存在差距。
如果你基于代码来设计测试那么即使你的代码没有达到项目期望你也可能找不到任何缺陷因为两者是匹配的因此正确的做法是确保测试是基于项目的实际需求和预期结果来编写的而不是简单地验证代码逻辑本身。 那么我们应该测试什么呢
我们应该基于项目期望来进行测试确保测试是围绕这些期望展开的而绝不是在测试过程中揪住代码实现细节。
现在你或许会对如何测试项目期望以及这些期望是什么感到困惑。这就是我想要向你介绍的——验收标准Acceptance Criteria的原因。
制定规范
没有什么比面对着一张白纸完全不知道接下来该做什么更糟糕的了。而且可以肯定的是当你开始学习测试时这种感觉会经常出现。
不过我有一个好消息要告诉你有一种方法可以减少这种迷茫感那就是以一种特殊的方式编写规范这种方式被称为验收标准。
验收标准是一句简单的句子描述了应用程序中的一个原子行为这样就便于测试因为我们为每个场景都有了精确的指导。每个场景都会有一个精确描述它的验收标准这让测试变得更加直接和有针对性。 流程规范
与初学者常认为的不同编写测试和代码之间存在着一定的顺序。
并非不遵循这一顺序就无法进行但可能会使过程更加艰难且容易出错。
为此一种既实用又流行的开发方式是测试驱动开发Test Driven DevelopmentTDD。
然而这种实践也有些教条化作为初学者在各种规则间很容易迷失方向。
因此对初学者而言回归基础确保理解这一过程是非常重要的。
这是最重要的一开始没有采用完美的流程并不可耻罗马非一日建成你的测试技能也是如此。
相反最好专注于测试驱动开发的三个原则并以最适合自己的方式去应用它们。 第一条原则是在编写任何代码之前先实现测试。
这样做的目的是确保你不是在测试代码本身而是基于验收标准来设计测试。 第二条原则是在编写任何代码之前确保测试失败。
在小型项目中这可能没有太多意义但随着项目规模的扩大很难追踪某个问题是否已被其他部分解决。这个检查是为了确保之前没有完成相同的工作实施这段代码将为公司带来实际效益。 最后一条原则是一旦完成代码编写所有测试都应通过。
确保所有测试都能通过有助于我们跟踪应用程序中重要的内容并确保在将来重构或添加新功能时不会破坏任何现有功能。 AAA框架
为了实现一个场景我们有描述每个场景的验收标准但如何从一句描述转换成实际代码呢
第一步是确保验收标准是完整的为此我们需要了解测试的三个组成部分。
1. 我们要安排应用程序的状态确保每次运行时都有验收标准中明确规定的特定状态。这里的目的是每次运行测试时都拥有完全相同的状态确保我们能够复现它。
2. 接下来的步骤是执行我们想要测试的逻辑。
3. 最后一步是断言新的状态是我们预期的否则就让测试失败。 如你所猜测的那样如果了解AAA框架就会发现每个步骤都遵循了该框架的一个步骤并且为了明确定义验收标准它也需要遵循这三步。
快速识别并不总是简单因此设计了一种称为Gherkin的伪代码语言来解决这个问题。
在这个语言中每个验收标准至少应包含以下每个关键词一次 Given这个关键词与设置步骤相关联用于定义初始状态。 When这个关键词用于定义需要执行的逻辑。 Then这个关键词与断言步骤相关联确保测试在验证最终状态是否符合预期。
最后总结下
测试是复杂的但是通过遵循一些原则并妥善划分步骤可以实现有效的测试。
首先不能为了测试代码而测试应该关注代码预期。
然后遵循测试驱动开发的三条规则确保你为公司编写了真正有效的代码并且可以跟踪应用程序中哪些内容是重要的。
最后为了编写每个场景你需要遵循AAA框架确保没有遗漏Arrange、Act和Assert这三个步骤中的任何一个。
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走
这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你
