质量保证测试应该从一个严格的黑盒的角度来进行吗?

这取决于你编写的方法和软件类型。有不同种类的质量保证。如果软件应该是容错的,那么QA应该模拟故障。此外,了解产品的工作方式可以帮助QA思考潜在的问题案例并更彻底地测试它们。

另一方面,从用户的角度来看,了解产品是如何工作的可能会阻止QA完全测试。因此,也许首先应该在不了解内部情况的情况下设计基本测试,然后根据潜在问题进行更深入的测试。

当然,这取决于建筑。我在一个项目中工作,在这个项目中,DB层由一个完全独立的团队在不同的建筑中开发、管理和测试。他们的质量保证(qa)肯定会用数据来扭动,看看过程、查询等是否都在一系列测试条件下运行。

如果您在UI端,那么有两个级别,一个是简单的功能测试,对于这个测试,QA不需要应用程序的工作知识(所有这些知识都应该是自动化的),另一个是QA,它说明应用程序是否做它应该做的。对于第二种类型,如果QA团队知道它是如何工作的,那么它确实会有所帮助。它节省了大量时间,一开始就拒绝愚蠢的错误,但更重要的是,它们需要像用户一样的行为,并有端到端的用例,这些用例尝试了一些更复杂的重叠场景。为了设计这样的测试,他们必须对应用有很好的了解。

对于测试人员来说,尽可能多地了解软件的实现是完全有意义的。这将帮助他们更好地测试。

黑盒测试是一种有用且必要的技术,但是稍微了解一下在引擎盖下发生的事情,可以更容易地定义真正有趣的测试用例。

依赖开发人员的单元测试来满足您所有的白盒测试需求的问题是,总体而言,开发人员并不是非常彻底的测试人员,特别是在涉及到他们编写的代码时。

在我参与过的项目中,QA从用户的角度进行了测试,他们的测试是从满足需求的角度进行的。他们的测试是黑匣子测试。白盒测试由开发者完成。我们从未期望QA人员打开数据库查询工具并手动更改值。这是开发人员的单元测试的责任。

我认为这取决于您的QA团队在给定项目中所扮演的角色。我认为您可以提出这样一个论点:由数据库中存在的特定值引起的情况应该由测试用例表示,如果可以用这种方式表示,那么开发人员应该为这些情况编写(应该已经编写)单元测试。

如果您还使用代码检查来识别和修复缺陷,那么可能不需要将QA暴露在幕后。我认为有些项目可能有助于他们在用户体验之外测试代码,但是我可能会使用一个QA团队进行黑盒测试,而不是白盒或透明盒测试。

我认为混合方法很有效。如果您使用白盒测试(单元测试)和黑盒测试的组合,最终会得到更好的覆盖。每种方法都有其优点和缺点,但它们确实在一定程度上掩盖了另一种方法的缺点。

理解代码的内部工作方式将使您以某种方式进行测试,这并不总是发现某些问题的最佳方式。

我会说,有充分的理由让一个质量保证人员 不 详细了解应用程序的工作原理。质量保证人员的计算机能力水平应该与你的目标受众差不多。

原因很简单:QA人员越了解应用程序的构建方式,就越有可能避免常规用户遇到的正常可用性问题。

QA不仅仅是测试应用程序是否有效。它还应该是关于测试它是否可以被您的普通用户理解,从而实际可用。

更新
这太长了,无法放入评论框。

关于@testerab的问题。

我将QA定义为负责确保1的人员或团队。满足业务要求;和,2.应用程序关于这些要求的功能是无错误的。因此被称为“质量保证”。我认为属于QA的第三项只是可用性。

他们必须了解业务需求,这意味着他们应该与任何业务分析师和最终用户(如果有的话)携手合作。我曾与之合作过的最好的质量保证人员都是从这些领域雇佣来的。我见过的最差的QA成员是开发人员,或者是受过这样的培训。离开技术支持的人也倾向于成为优秀的QA成员,因为他们知道最终用户将尝试的垃圾类型。

有许多不同类型的应用程序。其中最常见的是光荣的数据输入。您有一些输入信息并按下按钮的屏幕。然后,信息被存储和/或路由到它需要去的任何地方。从MS Word到CRM的所有内容都属于这一类别。

因此,QA人员的工作是首先确保应用程序接受所需的输入并执行所需的功能。第二步是提交错误的输入,并验证应用程序以所需的方式响应。例如,它不会爆炸或让坏信息通过。自动化测试工具在这些情况下工作得很好。最后一部分是决定该函数是应该深埋三层菜单还是应该更容易实现。

以上任何一项都不要求QA人员读取代码或使用位进行旋转。

有些系统没有UI组件。对于这些,由开发人员提供一个测试工具,允许QA团队提交数据并审查结果。这包括Web服务和您可以想象的任何类型的EDI。

其他系统本身就是API。这些要求有足够知识的QA人员来实现这些API调用,或者要求开发人员提供方便地调用它们并记录结果的方法。在这种情况下,最好让QA团队自己进行编程,但同样地,不能访问底层代码。

检查实际代码的问题在于,它往往会使一个人只关注他们看到的内容。这很糟糕。相反,他们应该在精神上不受那些人为限制,这样他们就可以盲目地在一个文本框中键入“abc”,而这个文本框需要数字输入。

就为了知道要测试什么而“看到”代码而言,这是一个完全不同的问题,并且由经过培训的开发人员在代码审查设置中更好地解决了这个问题。这里的目的是识别可能的错误、最佳实践、安全故障等。由于QA人员需要有人成为一个活跃的开发人员,因此很少有人能够进行这种级别的分析。

关于SDDES:如果您的产品拥有或是API,或者DEVS用来构建其他事物的基础,那么您可能希望一个或多个专门致力于围绕它实现软件的人,以支持常规QA组。我对这个角色的必要性持怀疑态度,相信这可能是一个项目一个项目的决定。

我相信有两个组更适合测试API。这些是已经在实现的最终用户和构建它的公司中的其他开发人员。狗食现在是一种常见的做法,而且非常划算。毕竟,如果它不起作用,你可以确定它会很快修复。对于最终用户,只要他们把它看作是一个真正的对话,在这个对话中,开发团队是响应的,那么他们会很乐意为您“测试”它。

我经历过这三种情况,作为最终用户,我觉得访问原始开发人员对解决问题有很大的帮助。尤其是当他们也在使用产品时。对通常与这些项目相关的QA人员的误译量是可怕的。

总之,我与各种质量保证人员合作过。从那些你想知道他们是如何开车去工作的超级明星,他们非常擅长发现那些导致应用程序窒息的角落案例。

最优秀的学生的特点是:1.从来不是程序员;2.了解业务;3.准确了解最终用户每天所做的工作。4。真诚地关心那些受软件影响的人。

最差的特征包括:1.曾是程序员或认为自己是程序员;2.不了解业务;3.从未见过最终用户;4.经常用“白痴”这个词;5。沉迷于它的工作机制,而不是它是否可用。