注解

本文讨论了非常规但有用的测试形式，并总结了七年来开发测试的结果。

为什么需要组件测试？

毕竟，有一些单元测试可以详细测试组件的内脏。 他们彻底验证了该组件是否按照开发人员的意图工作。 但这通常是对纽扣的检查，而不是西服整体的摆放位置。 并非总是程序员所构想的行为与客户想要的行为相吻合。

还有例如验收测试。 并且它们消除了所有这些缺点。 但是，不幸的是，他们正在引入新的。 它们很慢，通常不稳定，通常驯服。 但是，它们仅表示问题，而不是将其本地化。

显然，需要进行中间测试，这将是单元测试和验收测试之间的黄金平均值。 这个中间立场可能是组件测试。

什么是组件测试？

这些是针对公共组件API的测试。 因此，它们以与组件相同的语言编写。 测试目的：

• 验证组件是否符合您的合同
• 检查合规性
  后者尤其重要，因为 单元测试通常是根据开发人员的期望编写的，但是这里您需要检查客户的期望。

显然，当您拥有带有扩展接口的专用组件时，组件测试才有意义。 例如，动态库或COM对象。 然后，组件测试将发挥最大的作用。

k检验的优点：

• 稳定发展。 显然，对公共接口的全面检查使您可以将组件保持为或多或少有效的形式。
• 准确定位问题。 即使组件测试本身非常通用，也可以随时对其进行深度调试，以快速获取战斗代码。 在这种情况下，测试环境将最小化并自动配置。
• 与大量开发人员一起加速开发。 程序员被称为像马。 如果一匹马拉着一辆容量为1升的推车。 s。，然后拉八匹马，容量仅约4升。 s 并且向团队中添加另一个开发人员（尤其是在项目结束时）通常不仅不会加速，而且会减慢速度。 虽然增加一个组件测试开发人员总是一个加号，但因为它相对独立于团队而行动：它（主要是外部）进行测试，加快构建的生成速度，优化程序集文件等。
• 澄清（然后验证）客户需求。 由于组件测试的开发人员与实现无关，因此他受“我自己知道如何做”效果的影响较小。 在需求不明确的情况下，普通开发人员倾向于这样做很方便（更有趣，更快，更容易）。 在这种情况下，ct开发人员倾向于指定客户的确切期望。
• 相对稳定且相对较快 （与通过用户界面进行的手动测试和自动测试相比）。

K检验的缺点：

• 开发和支持的时间。 显然，如果部分时间用于编写组件测试，则该产品的Alpha版本将在以后出现。 总体上会有收益吗？ 会尽快发布吗？ 这是一个好问题。 我的看法：在使用组件测试进行开发时，该版本将在大约同一时间发布。 但是-谣言较少，时间可预测。 开发时间自然会增加，错误修复和稳定化的时间会减少。 由于第二部分很难预测，因此减少它会对处理量和麻烦产生有益的影响。 但是，这只是我的经验，实际情况可能有所不同。 分配给组件测试的时间可能会被浪费在复制现有单元测试上。
• 互换性较差。 角色分离可以提高效率，但会降低互换性。 开发人员很少想深入进行组件测试，因为组件测试可以具有（或模拟）相当复杂的环境。 组件测试的开发人员远远不了解战斗代码，因此可以轻松进行编辑。
• 烦人的重复。 有了良好的单元测试，组件测试通常往往是多余的。 这既烦人又质疑他们的需求。 协调单元计划和组件测试会有所帮助，但通常不会完全消除重复。
• 需要遵循正确的工作流程。 收到需求后，应将任务同时放在测试的开发人员和测试的开发人员上。 然后他们大约同时完成工作。 该组件将通过测试运行，迅速发现并纠正错误，并使用或多或少的成品退出市场。 在这种情况下，组件测试的好处将最大化。 但是，经常会发生这样的情况：截止日期很长，所有的截止时间都被放弃，只写了代码，而组件却被送去进行手动测试而不进行测试。 然后他们才邀请测试的开发者-他们说没有测试的代码已经发布并不好，我们应该添加它们。 在这种情况下，大多数错误是由手动测试人员发现的，开发人员盲目地进行更正（或手动测试更改），而事实后测试则仅发现少量错误（对作者的道德产生负面影响）。 这种使用组件测试的做法充其量是没有用的，并且很难对此加以保证。
• 合适的人很少。 一方面，组件测试的开发人员应该能够使用组件的语言（例如C ++）编写代码。 此外，如果用于启动组件的环境广泛，则代码可能会非常复杂。 另一方面，能够细致地测试别人的作品。 这样的人不是很多，他们通常会立即去开发者那里。 但是仍然有这样的人，以及关于他们的下一部分。

总结1

组件测试是很好的，但前提是您具有所有条件：广泛的公共API，正确的工作流程和团队中合适的人员。

成为SDET感觉如何？

显然，SDET（测试软件开发工程师）是编写组件测试的理想人选。 他知道如何编写代码，并且知道如何在测试中思考。 它还提供了第二种意见，这也提高了测试和代码的质量。 所有这些听起来很有趣且很诱人-也许您已经想成为其中一员。 在这里，我将简要介绍一下SDET的工作与纯开发人员的工作有何不同。

使用SDET的优势：

• 新代码。 SDET几乎总是从头开始编写测试。 通常，环境是从头开始编写的。 它非常好，为创造力提供了很大的空间。
• 对遗留代码的依赖性低。 不管战斗代码多么可怕，都可以胜任而精美地对其进行测试。 当然，设计不良的代码会产生难看的测试，但是仍然可以使它们比代码本身好一个数量级。
• 重构更加频繁。 测试更改的危险性要小得多，因此，它们的使用频率更高。 这是处理错误并练习通过重构编写干净代码的好机会。
• 批判性思维的发展。 自动测试是关于如何破解他人代码的有趣搜索。 而且，搜索不是愚蠢的，不是坐在外面，也不是在戳戳，而是借助逻辑，组合学和发现漏洞的能力。 另外，一旦创建了支票，它将继续为您持续工作。
• 开发测试代码的能力。 在面对面的战斗训练中，他们经常说一些引导性的话：“现在我们只用脚工作；现在我们只用头工作。” 仅使用一种机制（在我们的示例中为自动测试）可以使您精通它。
• 谣言数量较少。 周末，SDET的拉动幅度要小得多。 他们不必紧急去修复关键的错误。 好吧，他们犯严重错误的机会要低得多。

使用SDET的缺点：

• 低编码复杂度。 测试代码通常仍然比战斗代码简单。 每次测试的前提条件，调用战斗代码，后置条件等。 用于创建环境的代码更加复杂，但仍无法解决。 选择最佳算法，设计复杂的数据结构，建立类层次结构-通常所有这些都由测试开发人员通过。
• 经验越来越缓慢 。 测试开发人员陷入困境的情况的多样性和复杂性要少得多。 组装线故障，红色测试，有时甚至是转储-这是您通常必须使用的主要设置。 开发人员面临的问题更加复杂：从链接和汇编的变体开始，到针对特定客户的小故障和精心制作的转储，最后在编译器和第三方库中发现错误。 不仅...
• 测试风格与开发人员的主要区别。 通常，SDET更喜欢紧凑的表达测试，该测试允许您仅用几行就可以创建一个复杂的环境，并且样式中的原子检查是相等/不相等的（也就是说，是否满足要求）。 有时涉及到它的DSL。 简而言之，开发人员更喜欢对环境进行微调的测试以及对程序行为各个方面进行的众多测试，这导致了相当多的行测试。 有时涉及复制粘贴（在这种情况下，即使是最好的开发人员也不会考虑过错误）。 在这里，您可以讨论很长的时间，甚至撰写另一篇文章，但是事实是，当开发人员尝试修改SDET测试时（反之亦然），通常会导致冗长而很少有成果的讨论。
• 以下是“等级”。 也许是由于更简单的代码和更少的责任，但最终并不重要。 通常就是这样。
• 搬到新位置比较困难。 SDET可能会在额头上引起问题：您编写测试已经很久了，也就是说，实际上您只是调用了函数并比较了结果-您可以编写真实的代码吗？ 您知道该语言的所有陷阱吗？ 您解决了复杂的问题吗？ 您是否需要拆卸华丽的错误或转储？ 有多线程经验吗？ 毕竟，您有抱负吗？

总结2

作为一个从事开发人员多年的人，然后去了SDET几年，然后又回到了开发领域，我可以说以下几点。

我强烈建议您将SDET花费至少一两年。 对于任何开发人员来说，这都是非常有益的体验。 但是在我看来，呆在那里并不值得。