假设单元测试由开发人员处理，QA 是否有任何理由了解产品如何工作的细节？我的意思是，他们是否需要知道后台发生了什么？他们是否应该在不使用普通 UI 的情况下测试产品的各个部分？例如，测试人员进入数据库并手动更改值以查看会发生什么是否有意义？
编辑：
假设我们正在使用一个供非开发人员使用的应用程序，我们不是在处理带有 API 的东西。
tloach
问问题
800 次
7 回答
3
这取决于您编写的方法和软件类型。有不同类型的 QA。如果软件应该是容错的，QA 应该模拟故障。此外，了解产品的工作原理可以帮助 QA 考虑潜在的问题案例并更彻底地测试它们。
另一方面，了解产品的工作原理可能会阻止 QA 从用户的角度进行完全测试。因此，也许首先应该在不了解内部结构的情况下设计基本测试，然后根据潜在问题进行更深入的测试。
于 2008-10-02T19:48:32.787 回答
2
当然，这取决于架构。我在一个项目中工作，其中 db 层由不同建筑物中的一个完全独立的团队开发、管理和测试。他们的 QA 肯定会使用数据来查看程序、查询等是否都在一系列测试条件下运行。
如果你在 UI 端，那么有两个级别，一个是简单的功能测试，QA 不需要应用程序的工作知识（并且所有这些都应该是自动化的），然后是 QA，它说明应用程序是否做它应该做的事情。对于第二种情况，如果 QA 团队知道它是如何工作的，那真的很有帮助。一开始就拒绝愚蠢的错误可以节省大量时间，但更重要的是，它们需要像用户一样行事，并且有端到端的用例来尝试一些更复杂的覆盖场景。要设计这样的测试，他们必须对应用程序有很好的了解。
于 2008-10-02T19:47:30.480 回答
2
测试人员尽可能多地了解软件的实现是绝对有意义的。这将帮助他们更好地测试。
黑盒测试是一种有用且必要的技术，但对幕后发生的事情有所了解可以更容易地定义真正有趣的测试用例。
依赖开发人员的单元测试来满足所有白盒测试需求的问题在于，总的来说，开发人员并不是非常彻底的测试人员，尤其是在他们编写的代码方面。
于 2008-10-02T19:49:38.073 回答
1
在我参与的项目中，QA 从用户的角度进行测试，他们的测试是从满足需求的角度进行的。他们的测试是黑盒测试。白盒测试由开发人员完成。我们从没想过 QA 人员会打开数据库查询工具并手动更改值。这是开发人员单元测试的职责。
于 2008-10-02T19:49:38.243 回答
1
我认为这取决于您的 QA 团队在给定项目中所扮演的角色。我认为您可以提出一个论点，即由数据库中存在的特定值引起的情况应该由测试用例表示，如果它们可以用这种方式表示，那么开发人员应该为这些情况编写（应该编写）单元测试.
如果您还使用代码检查来识别和修复缺陷，则可能没有必要将 QA 暴露给幕后的任何内容。我想有些项目可能对他们在用户体验之外测试代码有所帮助，但我可能会使用 QA 团队进行黑盒测试，而不是白盒或明盒测试。
于 2008-10-02T19:51:55.790 回答
0
我想说，QA 人员完全有理由不了解您的应用程序如何工作的详细内部知识。QA 人员的计算机能力应与您的目标受众大致相同。
原因很简单：QA 人员对您的应用程序的构建方式了解得越多，他们就越有可能避免普通用户遇到的正常可用性问题。
QA 不仅仅是测试应用程序是否有效。它还应该是关于测试您的普通用户是否可以理解并因此实际可用。
更新
这太长了，无法放入评论框中。
关于@testerab 的问题。
我将 QA 定义为负责确保 1. 满足业务需求的个人或团队；并且，2. 与这些要求相关的应用程序功能没有错误。因此，绰号“质量保证”。我认为属于 QA 的第三个项目就是可用性。
他们必须了解业务需求，这意味着他们应该与任何业务分析师和最终用户（如果有的话）携手合作。与我共事过的最好的 QA 成员都是从这些领域聘用的。我见过的最差的 QA 成员是开发人员，或者接受过这样的培训。从技术支持离职的人也倾向于成为优秀的 QA 成员，因为他们确切地知道最终用户会尝试的垃圾类型。
有许多不同类别的应用程序。其中最常见的是美化数据输入。您有一些屏幕可以输入信息并按下按钮。然后将信息存储和/或路由到它需要去的任何地方。从 MS Word 到 CRM 的一切都属于这一类。
因此，QA 人员的工作是首先确保应用程序将接受所需的输入并执行所需的功能。第二步是提交错误的输入并验证应用程序以所需的方式响应。例如，它不会爆炸或允许不良信息通过。自动化测试工具在这些情况下工作得很好。最后一部分是决定该功能是否应该隐藏在三个菜单级别深处，还是应该更容易获得。
以上都不需要质量检查人员阅读代码或玩弄比特。
有些系统没有 UI 组件。对于这些，由开发人员提供一个测试工具，允许 QA 团队提交数据并审查结果。这涵盖了 Web 服务和您可以想象的任何类型的 EDI。
其他系统本身就是 API。这些要求要么有足够知识的 QA 人员自己实现此类 API 调用，要么需要开发人员提供轻松调用它们并记录结果的方法。在这种情况下，最好 QA 团队可以自己进行编程，但同样不能访问底层代码。
审查实际代码的问题在于它往往会导致人们只关注他们所看到的内容。这是不好的。相反，他们应该在精神上摆脱那些人为的限制，以便他们可以在需要输入数字的文本框中盲目地键入“ABC”。
至于“查看”代码以便知道要测试什么，这是一个完全不同的问题，并且在代码审查设置中由训练有素的开发人员更好地解决。这里的目的是识别可能的错误、最佳实践、安全故障等。QA 人员很少能够进行这种级别的分析，因为它需要有人成为活跃的开发人员。
关于 SDET：如果您的产品拥有或现在是开发人员用来构建其他东西的 API 或基础，那么您可能需要一个或多个人专门围绕它实施软件，以支持常规 QA 小组。我对这个角色的必要性持观望态度，并相信这可能是一个逐个项目的决策。
我相信有两个小组更有资格测试 API。这些是已经在实施的最终用户以及构建它的公司中的其他开发人员。狗食现在是一种常见的做法，而且非常划算。毕竟，如果它不起作用，您可以确定它会很快得到修复。对于最终用户，只要他们将其视为开发团队响应的真实对话，他们就会很乐意为您“测试”它。
我经历过这三种情况，作为最终用户，我觉得可以访问原始开发人员对于解决问题有很长的路要走。特别是当他们也在使用该产品时。通常与这些项目相关的 QA 人员的误译数量非常可怕。
总而言之，我与各种 QA 人员共事过。从您想知道他们如何设法开车上班的超级明星到非常善于发现导致应用程序阻塞的那些极端情况的超级明星。
最好的人的特点是： 1. 从来不是程序员；2.了解业务；3. 准确了解最终用户每天所做的事情。4. 真诚地关心那些使用该软件的人。
最差的特征包括： 1. 曾经是程序员或认为他们是程序员；2. 不懂业务；3. 从未见过最终用户；4. 过于频繁地使用“白痴”这个词；5. 关注它的工作原理，而不是它是否可用。
于 2008-10-02T20:02:41.193 回答
0
我认为混合方法效果很好。如果您结合使用白盒测试（单元测试）和黑盒测试，您最终会获得更好的覆盖率。每个都有其优点和缺点，但它们确实部分掩盖了另一个的弱点。
了解代码的内部工作原理会导致您以某种方式进行测试，这并不总是发现某些问题的最佳方式。
于 2008-10-02T20:04:41.983 回答