使白盒测试更容易的编程设计模式？答案

【问题标题】：Design patterns on programming to make white-box testing easier?使白盒测试更容易的编程设计模式？
【发布时间】：2012-05-19 12:54:47
【问题描述】：

我想知道是否有一些编程设计模式可以使程序更容易进行白盒测试。我不是在谈论单元测试，而是更高级别的测试，例如基于白盒的功能测试、系统测试或一些边界测试。

例如：

还有其他模式或原则吗？

【问题讨论】：

您已经掌握了它。这是关于将测试点注入处理（输入和输出），以便您可以自动化。您可能会争辩说，像 auto 这样的东西会比一个更好，而代理会比 2 更好。它只是更高抽象级别的模块化。自动化集成测试..

【解决方案1】：

我不知道我是否完全明白你的问题，但是：

想想你的测试策略

换句话说，你必须知道你在什么情况下测试什么（整个系统，只是这个模块/类/函数/什么等等）（当我给它无效的输入时，当用户这样做并且然后，等等）以及为什么该测试足够重要以供考虑（这是一种常见用途，它测试边界条件等）。

我认为Wikipedia article on software testing 中的“测试方法”和“测试级别”部分可能会帮助您了解您想要什么样的测试。

您的测试应该与您的应用程序代码保持相同的工程质量水平。在这方面，应用所有有助于解决问题的模式，但仅此而已！

我个人认为，出于多种原因，仅为测试而创建秘密戳洞是一个坏主意。仅举几例：

它们可能无法以微妙的方式可靠地重现假定的交互。 “测试快捷方式”可能不会像普通用户那样触发完全相同的事情。每次提交对代码和测试的更改时，您都必须非常 100% 确定要绕过的内容（及其影响）。
测试需要良好的设计。如果测试某些东西让您感到痛苦，您是否考虑过质疑您的设计？测试某些东西只是以脚本的方式使用它。使用您的产品不应该是痛苦的。（但是，在某些环境中，测试脚本可能会很痛苦。是的，我知道。）对于单元测试尤其如此。
总有一些不经意的程序员可能认为将测试快捷方式转变为实际、合法、正常的用例是个好主意。这一切都变得很糟糕，特别是如果他假设那段代码和其他代码一样经过深思熟虑（通常不是这样）。

【讨论】：

感谢 pkoch 的回答。
感谢 pkoch 的回答。我遇到的问题是，我们现在的项目已经开发了好几年，而且很复杂，而且设计得不好。它从 GUI 获取数据并从 Web 服务器发送/接收数据。现在除了 GUI 之外几乎不可能自动化测试脚本，但是基于 GUI 的自动化比 API 驱动有很多不稳定的问题。所以我试图从头开始为一个新项目找到一些指导方针，以避免我们现在遇到的这种问题。
如果代码库有很多质量问题，我建议您从典型用法的黑盒测试开始。但是，对于新项目，我会建议您进行彻底的单元测试、必要时的集成测试以及彻底的系统测试或自动化用户验收测试（像 Cucumber 之类的东西）。
现实情况是我们的项目进展很快，开发人员总是急于完成需求，他们不做单元测试（他们认为收益不值得付出代价）并且不太关心白盒测试，但是作为一个QA，我们正在尝试尽可能地覆盖所有更改的代码，尤其是一些边界或异常情况，但是对于这种情况，几乎不可能触发它们GUI 或常规操作。因此，我试图找到一些可以使测试或编写自动化脚本更容易的良好做法。
例如，如果可以从文本文件中读取数据，我可以在其中放入一些意想不到的数据，这很难从GUI触发。

【解决方案2】：

我发现的白盒测试最有用的领域之一是多线程问题的极端情况。只有压力测试+祈祷，或者您尝试通过添加延迟和信号量来覆盖测试以让事情发生。

但我怀疑是否存在测试用例模式。模式只对非常精确定义的情况有用。只要记住 Gamma 对原始模式书的编码有多接近。

其他一切都只是讲故事，分享经验很重要，但不是模式。

【讨论】：