logo Parasoft 行业资讯(一) 我也要发布文档

从负面测试中排除负面因素



误解通常会导致测试人员对软件“破解”的评价不高。开发人员和利益相关者可能会称其为负面测试,但结果却是更好的产品,而且都是积极的。

测试人员是新软件的第一批用户,它们对于使其可用至关重要。最后,每个人都有提供最佳产品的相同目标,因此让测试人员探索和发现新的错误始终是一件好事——发现的错误越多越好!在软件开发生命周期的开始阶段,通过鼓励探索性测试,可以更早、更轻松地修复漏洞,从而更早地发现错误。

当然,我发现的许多错误都与功能要求无关。性能问题是一个常见的例子。在大多数情况下,需求并没有说明需要多长时间,但是测试人员可以很容易地判断出什么时候不合适。如果我不耐烦地等待我们的软件,那么我们的客户也会。而且,当我们仍然可以修复它时,您是否愿意从我这里而不是从客户那里听到?


我们到底在测试什么?


早上8点30分,我们的产品经理走进我们的办公室,问:“项目负责人在哪里?”

首席开发人员说:“他出去了。需要我们怎样帮助你?


“将数据库从MySQL迁移到MariaDB的用户故事的状态如何?”

首席开发人员回答:“我们之所以延后,是因为MySQL主表的某些关键元素不容易迁移到MariaDB。”

产品经理的语气立即变得更加清晰。“延后多少?几天,几周?

我们的主要开发人员如实回答:“至少还有四天。”

房间里寂静无声。最后,产品经理说:“你能告诉项目负责人来我办公室吗?我需要和他谈谈。”他转身离开。

显然,产品经理对我们的用户故事进度不满意,并且所有开发人员和测试人员现在都感到压力很大。

在当天晚些时候的计划会议中,团队考虑了所有可能的路径:幸福的道路、不愉快的道路以及边缘和边缘情况。之后,我坐在小隔间中测试用户故事,尽管大多数任务仍在进行中,但我还是决定进行一些负面测试。在好奇心的驱使下,我开始导航到与数据库更改无关的区域,并且发现了严重的缺陷。

此时,项目负责人从产品经理的办公室回来,他看上去并不高兴。我转到项目负责人并通知他,在执行负面测试时,我在登录页面中发现了一个严重错误。

“你正在测试用户故事以外的东西吗?”他回答。“请不要尝试使用有趣的负面内容来破坏应用程序。我们正在赶时间,我认为普通用户不会遇到该缺陷。

“好吧,”我说,“我将提交错误并继续执行之前的进度

不过,我私下里想知道:“普通用户”是谁或什么?


测试真实世界


仍然存在软件质量工程师破坏产品的误解。测试人员自己会惊呼:“看吗?我破解了该软件——当您单击此处时,它就崩溃了!

当然,他们并没有真正做到这一点。软件不会损坏;它只是按照它的设计和编码来做,不管是好是坏。

说到设计,另一个普遍的神话是,所有错误都是编码错误和编程错误,而实际上,大多数错误是在需求和设计期间引入的。软件质量工程师对系统进行调查,查看系统的功能,然后发现并报告软件损坏的位置和方式,并确定系统何时在负载或压力下出现故障,或者像任何用户一样在周围闲逛。

因此,测试人员有义务超越积极的幸福之路,并揭露不太幸福的事物。

积极的测试是在正确的时间单击正确的位置。用户不太可能只会这样做。用户在需要时单击所需的内容。我们无法使用户一直以相同的方式做相同的事情,因此我们不能依靠我们的自动化测试来涵盖人机交互。

这就是为什么我不喜欢负面测试一词的原因——它不是负面的!

我更喜欢“真实世界的测试”。每个用户都以独特的方式使用产品,我们不能将用户彼此进行比较,也不能期望他们使用相同的路径浏览应用程序。用户不会走幸福的路。用户不遵循说明,或者说实话,通常甚至都不阅读文档。用户习惯挑战产品。

因此,作为测试人员,对我们挑战产品也至关重要。我们必须改变测试方法,以找出产品的响应方式。出色的测试不仅限于表明产品可以产生预期的结果;这意味着在用户做某人没有预料到的事情时了解产品的功能。

作为软件质量工程师,我们的职责是像真实用户一样行动和思考。我们需要在测试计划之外进行测试并关闭脚本。开发人员和利益相关者可能会称其为负面测试,但结果却是更好的产品,而且都是积极的。


改变对话


任何软件都有潜在的风险,无法按预期运行,因此至关重要的一点是,至少要验证有人登录时该软件不会崩溃。当我在登录页面中发现错误时,我没有进行负面测试;我正在研究软件。

因此,我应该以积极的方式进行交流。我们的言语对他人如何看待和理解我们的工作有很大影响。

当我告诉项目负责人我在进行负面测试时发现了一个错误时,他的反应令人无法接受是可以理解的。如果我反而说:“当我测试登录页面时,我发现了一个严重的错误”他的反应可能是:“去存档该错误,稍后我们将对其进行研究。”

因此,我认为我们应该停止使用正面或负面的术语。相反,我们来谈谈“发现”和“调查”。它不那么混乱、更明确,并且避免了开发人员和管理人员说诸如“哦,您只是消极”之类的令人畏惧的潜在问题。

转移词汇帮助我改善了与利益相关者和开发人员之间的沟通。我可以看到方程式的另一个角度,并且我能够与开发人员进行交流,而不会遇到任何磨擦。现在,团队将我的工作视为积极改进产品,而不是消极地尝试破坏软件。

尝试将词汇表从“积极”和“否定”改为解释性更好的动词来解释您的探索。团队将更容易接受对话,他们甚至可能更珍视您的工作。