2

I am wondering whether there are some design patterns on programming to make programs easier for white-box testing. I am not talking about Unit Test, but higher level testing, such as white-box based functional testing, system testing or some boundary testing.

For example:

  1. For GUI based program, we can reserve a hidden switch to read inputs from a text file instead of GUI.

  2. For some HTTP based C/S application, providing a parameter to disable the gzip option during package transmit which make it easier to use Fiddler to change the HTTP package.

Any other patterns or principles?

4

2 回答 2

0

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

想想你的测试策略

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

我认为维基百科关于软件测试的文章中的“测试方法”和“测试级别”部分可能会帮助您推断出您想要什么样的测试。

测试仍然是代码

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

按原样使用构建

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

  • 他们可能无法以微妙的方式可靠地再现假定的交互。“测试快捷方式”可能不会像普通用户那样触发完全相同的事情。每次提交对代码和测试的更改时，您必须非常 100% 确定您正在绕过什么（及其影响）。

  • 测试需要好的设计。如果测试某些东西让您感到痛苦，您是否考虑过质疑您的设计？测试某些东西只是以脚本的方式使用它。使用您的产品不应该是痛苦的。（然而，测试的脚本在某些环境中可能会很痛苦。是的，我知道。）对于单元测试尤其如此。

  • 总有一些不经意的程序员可能会认为将测试快捷方式转变为实际、合法、正常的用例是个好主意。这有一切都可以南下，特别是如果他假设那段代码和其他代码一样经过深思熟虑（通常不是）。

于 2012-05-20T10:26:38.253 回答
0

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

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

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

于 2013-02-14T13:18:45.287 回答