这里是一个例子。在上一份工作中，我们对一些报告有一些措辞宽松的要求，而对于运行临时报告则有一个数据集市（报告数据库）的一般要求。开发人员选择在数据集市的顶部实施（松散指定的）报告。
数据集市的模式与我们的事务数据库不同。有一个用于将数据从交易数据库传输到报告数据库的工具。该工具在服务器上运行，并且不是面向用户的。测试人员的任务是测试工具，而不是报告。
该工具是从SQL查询中删除的。测试人员的策略是读取每个查询，弄清楚应该执行的操作，然后编写一组测试来测试该查询的行为。因此，举例来说，假设查询的目的是从事务数据库中的表X中读取行，对数据进行摆弄，然后将结果写入报表数据库中的表Y中。测试人员将编写一个测试，该测试在表X中插入一些行，计算预期结果，运行该工具，然后验证表Y中是否显示预期行。
我一直想知道如果测试失败，将会发生什么：测试人员会质疑该工具是否存在问题，还是会认为测试错误？毕竟，该工具没有明确的要求。对于任何类型的白盒测试来说，这似乎都是一种风险，我想知道这种测试的维护成本是否合理。
#1 楼
很好的问题。我认为这属于“应用程序是其自己的规范”的标题。在没有要求或规范的情况下，了解应用程序应该做什么的最好方法是开始使用该应用程序。如果您实际上有权访问应用程序的代码，则可以将这种想法扩展到代码本身成为要求的地方。在您给出的示例中，如果测试失败，则需要打开与开发人员的通信通道（如果尚未打开）。向开发人员传达这些假设是什么，做了什么以及产生的输出是什么。然后，与开发人员进行对话可以确定该工具是否按预期运行，或者是否找到了“错误”。
我认为，在没有明确要求的情况下，回答原始问题，白色-如果可以使用AUT的内部部件，则盒装测试是一种比适当的工具更重要的工具。这确实是知道需要运行哪些测试用例的唯一方法。
评论
我完全同意向开发人员提供已完成的特定测试的建议。我们很少有要求，所以我做了很多白盒测试。在测试功能时，当我完成了100％的所有方案时，我会通过电子邮件将所有的测试方案（通过/失败结果）发送给开发人员，并询问他们是否考虑了任何测试方案我没有涵盖。我们拥有一支优秀的团队，具有出色的沟通能力，这对我们来说非常有效。
–劳拉·亨斯利（Laura Hensley）
2011年5月17日18:40
#2 楼
这里的问题不是白盒测试。问题是没有规范。这是领域知识和产品熟悉度真正重要的地方。仅通过阅读API来测试代码是否达到了预期目的（从开发人员的角度来看）的测试人员可能会遗漏各种问题，例如未与开发人员交流的业务需求。当我遇到这种情况时，我会与白盒测试同时进行三件事：
我要求确保没有错过任何规格撰写的内容
我经常提出问题-开发人员，项目经理，企业主。
我提出了许多问题，并提出了明显的要求。针对这些情况，我们的团队在Wiki规范的底部放置了一个“开放式问题”部分，然后我可以通过电子邮件将开发人员创建的该功能规范的该部分的链接发送给所有可能了解“隐藏需求”的人。 。如果开发人员未创建规范，我将制作自己的文档，其中包含“开放式问题”部分。
这种情况下进行白盒测试的风险在于，我可以更轻松地进行测试如果我没有自律或经验不足，无法更好地了解和错过未能成功传达给开发人员的业务需求，请忽略这些步骤。我还需要向开发人员和PM辩护，即使我可以“只看代码”也为什么需要执行这些步骤，但这通常并不困难。如果我只是黑盒测试，那么在完成这些步骤之前，我将根本无法取得任何进步，因此忽略这些步骤的风险很小。
不过，这并不是不进行白盒测试的原因。在这种特殊情况下，白盒测试的特殊优势在于，在我对产品的真正含义获得完整答案之前，我可以在测试上取得更大的进步。这是白盒测试的其他优点的补充，例如，找到开发人员知道的实现企业所有者不知道要求的功能（例如，监视和记录通常属于我们公司的此类） 。
评论
好答案，埃塞尔！我要补充一点，就是永远不会有没有要求的情况。即使没有明确编写，也存在要求。我以这种方式处理这种情况：strazzere.blogspot.com/2010/04/…
–乔·斯特拉泽（Joe Strazzere）
2011年5月24日18:05
不错的博客文章：）感谢您的评论，这很重要！
– Ethel Evans
2011年5月24日18:59
#3 楼
为什么不测试最终报告？这将使定义预期结果变得更加容易，并且还可以验证您的ETL工具。显然，对于稍后要讨论的某些取舍。我发现，仅在单独测试ETL工具时发现的问题是，数据集市DB模式（例如，星型模式）通常较麻烦比最终报告要阅读和理解（这是出于查询性能的原因）。因此，由于更容易出错，因此很难描述，读取和维护datamart中的数据断言/检查。可以验证最终报告的测试将更容易理解，并且更容易确定预期结果是什么，因为业务人员或客户将能够回答该问题。
权衡。这种方法有很多明显的缺点，它们与一次测试多个层而没有孤立地对其进行测试有关：
隔离错误是在ETL工具中还是在报表定义中。
报表定义错误可能会掩盖ETL工具中的错误。
反馈被延迟。
文本执行时间更长。
最后，由于需要分析报告文档，因此通常难以对报告进行自动化测试（表，图形）。
我们能够限制其中一些问题。例如，我们通过将对数据集市的断言缓慢地纳入端到端测试来限制了第一个问题。首先，我们进行了仅检查报告的端到端测试，并且当我们了解原始数据库和Datamart DB之间以及datamart DB和报告之间的关系时，我们能够在测试中包括更具体的检查点。现在，当测试失败时，我们可以说出在哪一层。
评论
我不太清楚您的问题是什么：白盒测试似乎不是问题，但是缺少可靠的测试oracle。测试人员为什么不能问产品经理故障是否是问题？测试人员为什么不能向产品经理询问有关报告用途的更多信息，以及哪些数据是报告的关键？@testerab谢谢。我更新了文本以反映出还需要临时报告，并且测试人员的任务是专门测试数据集市而不是报告。
这里的问题是开发人员可能得到了错误的规格并开发了错误的软件。然后，当测试人员实际发现错误时，开发人员就有机会说“这不是错误”