问题标签 [white-box]

例如，我正在针对 CsvReader 编写测试。这是一个枚举和拆分文本行的简单类。它唯一存在的理由是忽略引号中的逗号。它不到一页。

通过“黑盒”测试课程，我检查了类似

• 如果文件不存在怎么办？
• 如果我没有文件的权限怎么办？
• 如果文件有非 Windows 换行符怎么办？

但实际上，所有这些都是 StreamReader 的事情。我的班级在没有对这些案例做任何事情的情况下工作。所以本质上，我的测试是捕捉 StreamReader 抛出的错误，以及框架处理的测试行为。感觉很多工作都白费了。

我看过相关的问题

• QA 是否应该从严格的黑盒角度进行测试？
• 严格捕获测试用例以进行单元测试

我的问题是，如果我使用我所知道的来避免这种工作，我是否错过了“玻璃盒”测试的意义？

你会说哪种类型的测试应该是重点（对于测试人员/质量保证人员），为什么？

来自维基百科的一组快速定义：

黑盒测试

• 以测试对象的外部视角推导出测试用例。这些测试可以是功能性的或非功能性的，尽管通常是功能性的。测试设计人员选择有效和无效输入并确定正确的输出。不知道测试对象的内部结构。

白盒测试

• 使用系统的内部视角来设计基于内部结构的测试用例。它需要编程技能来识别通过软件的所有路径。测试人员选择测试用例输入以通过代码练习路径并确定适当的输出。在电气硬件测试中，电路中的每个节点都可能被探测和测量；一个例子是在线测试（ICT）。

只是为了澄清一点，我意识到两者都很重要，但是通常它们在开发和质量检查之间是分开的。

内部知识对测试人员/QA 是否重要？我听说过使用这些知识进行测试可以让他们更好地测试问题的论点，但我也听说过这种知识会分散功能需求并促进“测试代码”而不是预期解决方案的论点。

我试图从一个与另一个的比较方面来理解它。

白盒测试是你可以看到代码的地方，而黑盒测试是你看不到代码的地方吗？

我必须找到这段代码的圈复杂度，然后提出一些白盒测试用例和黑盒测试用例。但是我在为代码制作 CFG 时遇到了麻烦。

也希望对测试用例有一些帮助。

必须检查一些公式是否提供正确的结果，这些公式是 VB 程序的一部分，单元测试这些公式的最佳工具\方法是什么？

我对 WhiteBox 测试世界比较陌生，需要帮助为我目前正在从事的 1 个项目设计测试计划。目前我只是在四处寻找可测试的代码，然后为此编写一些单元测试。我不知何故觉得这不是应该做的方式。请你给我一些建议，告诉我如何最好地为测试这个项目做好准备？我可以使用任何工具或测试计划模板吗？使用的语言是 C++，如果它会有所作为的话。

I am reading a book where I am getting stuck at few white box testing concepts. The article in the below link is taken exactly from the book. http://testdesigners.com/testingstyles/ControlFlowTesting.html

1. 'ON-Units' terminology is introduced first in the 'Decision Coverage' article without describing what it is. The article continues to use this term later which is hard without knowing what is the meaning of ON-Unit.

Questions - Is 'ON-Unit' a path that a decision takes or traverses ? How do one 'invoke' On units ?

2. In the example under 'Condition Coverage' DO K=0 TO 50 WHILE (J+K < QUEST)

The article goes to explain - "If one is using decision testing, the criterion can be satisfied by letting the loop run from K = 0 to 51, without ever exploring the circumstance where the WHILE clause becomes false"

Questions -

By the definition of decision coverage, the test cases should explore both the true and false branch of decisions at least once. In other words, K = 0 to 50 is not material because the While (J+K < Quest) is True branch and (J+K < QUEST) is false branch. Why does the article mention under decision coverage - Not exploring the While clause being false?

Also in the first part of the line in decision coverage, decision criterion is satisfied by letting the loop run from K = 0 to K = 51 that is just the true branch, decision criteria is not met alone by having a test case for True branch, why does the article say that this along is sufficient to meet the decision criteria?

假设我有三种方法，它们都非常相似，但输入类型不同：

这三个都使用相同的底层逻辑。例如：也许double版本是唯一比较数字的版本，而另外两个只是将它们的输入转换为double.

我们可以想象一些不同的单元测试：第一个输入更大，第二个更大，两个输入都是负数，等等。

我的问题

如果所有三种方法都有完整的测试集（黑盒，因为我们不假设核心实现是相同的）

或者

是否应该只对double版本进行大量测试而对其他两个版本进行轻微测试以验证参数转换（白盒测试，因为我们知道它们共享相同的实现并且已经在测试中进行了double测试）？

您好，我从一个班级打电话来测试我的产品，但是我不断收到此错误：“对象引用未设置为对象的实例。”

测试：

这里有什么问题？

抱歉发了这么长的帖子...

在被介绍给一个棕地项目时，我对某些单元测试集和思考什么有疑问。假设您有一个存储库类，包装了一个存储过程，并且在开发人员指南中，有一套特定的指导方针（规则），描述了应该如何构造这个类。该类可能如下所示：

现在，我当然会编写一些集成测试，测试 SP 是否可以被调用，以及行为是否符合预期。但是，我会编写单元测试来断言：

• 调用带有输入参数“someKey”的 SomeProfiler 的构造函数
• PersonStoredProcedure 的构造函数被称为
• 存储过程上的 addNameArgument 方法是用参数 personName 调用的
• 存储过程上的 addCityArgument 方法使用参数 cityName 调用
• 在存储过程上调用调用方法 -

如果是这样，除了行为之外，我可能会测试方法的整个结构。我最初的想法是它是矫枉过正的。然而，关于团队强制执行的编码实践，这些测试确保了统一且“正确”的结构，并且下一层被正确调用（从 DAL 到 DB，从 BLL 到 DAL 等）。

在我的例子中，这些类型的测试是针对应用程序的每一层执行的。

后续问题 - SomeProfiler 类的使用对我来说有点像约定 - 相反为此创建显式测试，是否可以通过使用静态代码分析或 unittest + 反射来创建约定样式的测试？

提前致谢。