问题标签 [black-box]

我们即将得到一个罐头包装，该包装已根据我们的需要进行了修改。我是为它准备测试的团队的一员。它有一个 Oracle 后端，我相信它是用 C++ .NET 编写的。

我的问题是您会推荐哪些免费或开源测试工具。

谢谢

肯

我有一个 PS/2 触摸板，我想为它编写一个驱动程序（我只是一个网络人，所以这对我来说是一个陌生的领域）。触摸板带有一个 Windows XP 驱动程序，该驱动程序显然会发送消息以启用/禁用点击点击。我试图找出它正在发送什么消息，但我不知道如何开始。像“Syser Debugger”这样的软件可以工作吗？我想拦截发送到 PS/2 总线的传出消息。

假设单元测试由开发人员处理，QA 是否有任何理由了解产品如何工作的细节？我的意思是，他们是否需要知道后台发生了什么？他们是否应该在不使用普通 UI 的情况下测试产品的各个部分？例如，测试人员进入数据库并手动更改值以查看会发生什么是否有意义？

编辑：
假设我们正在使用一个供非开发人员使用的应用程序，我们不是在处理带有 API 的东西。

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

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

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

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

我看过相关的问题

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

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

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

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

黑盒测试

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

白盒测试

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

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

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

我正在尝试决定是使用 Rails 还是 Django 大师来为我创建一个 Web 应用程序。我被推荐使用 Django，因为它使用较少的“魔法”。然而，从我的角度来看，Rails 的“魔力”似乎是一件好事，因为它可以使我的承包商的开发更加简洁，从而减少我的计费时间。我知道 Django 的优势可能是更精细的控制，但我怎么知道我是否需要这个控制？“魔法”是否存在固有问题？

当我第一次开始研究 Rails 和 Django 时，我被 Django 开发人员带离 Rails，他们认为 Rails 是一个使用过多“魔法”（泄漏抽象）的黑盒子。在进一步探索 Rails 时，我想知道这是否是基于不知道如何在不使用脚手架的情况下在 Rails 中实现自定义的不知情假设。脚手架本身似乎隐藏了很多东西，但是一旦您了解了如何在没有它的情况下创建项目，Rails 似乎与 Django 一样具有高度可定制性。这是我的误解还是 Rails 的“魔术”批评者的误解？

我正在寻找一个测试框架来涵盖我们的黑盒集成测试。我们需要非开发人员可以编写脚本的东西（也不是 C# 单元测试类型的东西）。

我想到的最初场景是：

1. 恢复已知数据库
2. 运行 sql 代理作业 (ETL)
3. 针对输出数据库执行验证 sql 脚本

和

1. 运行 msi 安装
2. 检查文件夹/文件/RegKeys/Services/etc 的存在
3. 运行 msi 卸载

到目前为止，我还没有找到任何看起来合适的东西。我们将使用的主要是 UI 测试（Project White/etc），但不包括这些情况。或者基于单元测试框架的集成测试，我们还没有准备好推动我们的 QA 团队进行。

如果我找不到其他任何东西，我目前正在尝试为这部分测试滚动我们自己的内部工具。

反对白盒/API 测试，此处介绍

有很多面试，无论是针对开发人员还是 QA，都要求您进行测试。一个经典是从记事本测试保存对话框。

以下是我可以提出、分类和优先排序的测试列表：

[功能，高] - 对话框执行其用例 - 当用户执行“另存为”时出现，左侧的按钮工作，文件以给定的名称和编码保存，顶部按钮工作，取消按钮工作。

[功能，中等] - 保存到只读媒体 - 会弹出一个公平的错误吗？

[功能，中等] - 保存一个空文件

[功能，低] - 将文件另存为 .txt，但从名称中删除扩展名

[功能，高] - 确保对话框是模态的

[功能，高] - 确保目录导航和目录功能正常工作

[功能，高] - 上下文菜单选项工作

[load, low] - 导航到有大量（接近系统限制）.txt 文件的目录；将文件保存在那里

[load, low] - 导航到包含大量子目录的目录。将文件保存在那里。

[压力，低] - 导航到允许最大文件数的目录并尝试保存文件

[压力，低] - 使用文件句柄使系统饱和（模拟具有非常丰富的界面或处理泄漏的应用程序，如雅虎通）；对话框会弹出吗？

[压力，中等] - 尝试在磁盘空间不足时保存文件。

[压力，低] - 检查“导航到最后一个文件夹”按钮的深度

[压力，低] - 导航到包含大量目录的目录

[性能，低] - 测量显示对话框所需的时间

[性能，低] - 测量对话框使用的资源（内存、窗口句柄、I/O）；确保资源被释放

[可访问性，高] - 该对话框是否与 win 提供的可访问性工具兼容？（放大镜，叙述者）；例如，在选择大字体时菜单项可以很好地缩放

[可访问性和兼容性，中等] - 该对话框是否与提供可访问性功能的著名 3rd 方程序兼容？

[localization, high] - 对话框适用于其他语言环境

[localization, high] - 随机输入 UTF-8 和 ANSII 字母作为文件名

[本地化，中等] - 从右到左的语言环境

[兼容性] - 确保保存的文件可以被其他编辑工具打开，无论是什么编码

[可用性，高] - 询问用户是否确定要覆盖文件

你能再补充一些吗？或者评论这些？

我有一个可以由不同供应商实现的 API。我可以使用 API 发送和接收数据并获得不同的返回码。

我想要做的是能够以自动化的方式测试 API，并尽可能保持一切干净。没有真正做单元测试。这将用于测试/QA 设置。

我所做的是在 C# 中创建一个虚拟应用程序并使用 NUnit 创建一套测试。所以我有基于功能的不同类的所有测试，我可以启动 NUnit 并运行我的测试并查看我的结果。我喜欢我如何进行设置和拆卸。这使我可以让 API 进入已知状态。我也喜欢 NUnit 中的断言方法。

我不认为这是 NUnit 的意图，我希望大多数人在他们的应用程序中使用 NUnit 来测试他们自己的代码。我的问题是，我做的有多糟糕？什么会更好？