好吧,我是一名黑匣子测试员,我不认为是开箱即用的。我只是在考虑快乐的道路,因此我想改善。我总是读到,测试人员应该具有出色的批判性和分析能力,并且应该开箱即用。那么,可以使用这种思维方式的一些实际例子/场景是什么?例如,我正在测试基于Web的EIS应用程序。

预先感谢!

评论

在文本字段中尝试Ctrl + Backspace。尝试将unicode和二进制数据粘贴到任何地方。确认Tab,Shift + Tab,Ctrl + A,Home,End,Page Up,Page Down等以一致的方式在您希望他们执行某项操作的任何地方工作。尝试使用Chrome或Firefox的inspect元素更改下拉列表的值,然后尝试发送无效/不可能的数据,看看它是否阻止了您。尝试使用Unicode数字(en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms)和土耳其语I(moserware.com/2008/02/does-your-code-pass-turkey-test.html)。尝试点击垃圾邮件。

答案为“我如何跳出框框思考”?是“想尽一切办法。然后,尝试提出清单上没有的内容。”换句话说,突破默认思维方式的诀窍是确定思维方式是什么,然后尝试其他思维方式。

穿越单向路时,您会同时看到两个方向吗?

#1 楼

除了已经列出的好建议之外,还有一些建议:


寻找该软件不应该做的事情。让它做。
它是基于Web的,因此如果它通过多屏操作中途丢失了网络/互联网,会发生什么?
在规范/用户故事中查找单词,例如“应该”,“始终”,“从不”等。这些表示涉及规则的条件。现在看看这些规则的边缘会发生什么。在极限内会发生什么?恰好在极限?仅仅在它外面吗?
使用EIS之类的东西,您将要处理许多组合在规则中的复杂变体。设置您可以想到的规则中最荒谬的组合,即您怀疑任何人实际上会做的事情。怎么了?
扮演角色。假设您是圣诞老人公司(Santa Claus,Inc.)的首席执行官,并且想知道今年是否需要购买额外的烟囱破损保险。还是假装是一个心怀不满的会计师,出于某种原因想要破坏CFO的财务预测。或者假装是CEO的5岁女儿,因为爸爸忘记了注销,所以想看到屏幕上出现的漂亮浮华的东西。等等...
具有破坏性。在交易中杀死系统。怎么了? (实际上,我在这里很认真。在我工作过的一个地方,我们不得不重建数据并清除损坏的数据,因为当客户的用户想要将该计算机用于其他用途时,它们只会杀死打算永久运行的进程。
了解墨菲的软件定律,然后加以利用。
将“哈姆雷特”的整个文本粘贴到备注字段中并保存。 QA讨厌您的肮脏技巧,整洁技巧和其他文章。他为狡猾的测试人员提供了一些不错的建议。
如果系统允许您执行某项操作,则不管您是否应该这样做。 >这包括运行真正的大规模数据爬网。
和SQL注入。

您应该通过一些练习来发现假设(包括您的假设)中的差距变得更容易。

评论


很棒的建议。我特别喜欢关于人物角色和墨菲定律的想法:-)

– dzieciou
2014年3月27日在18:25

来到这里寻求答案

–amazpyel
2014年3月27日在22:03

“如果通过多屏操作中途丢失了网络/互联网,会发生什么?” -或更改IP地址?例如手机/平板电脑/笔记本电脑切换WiFi <->移动数据?

–pgs
15年3月30日在23:12

#2 楼

欢迎使用Eddy的SQA。

我没有测试您的软件的经验,所以我没有适合您应用程序的实际场景。而且我所知道的场景对于我测试过的软件来说很典型,因此无论如何它们对您来说都是无用的。但是,我有很多一般的技巧或技术可以让我大开眼界。如果您的客户,其他测试人员和涉众报告了生产中发现的错误,则您可能会学到很多有关应用程序可能出问题的信息。不要只是阅读它们。尝试重现它们。参与到为它们验证修补程序中,或帮助开发人员找出根本原因。从清单中学习。互联网,如果充满了清单和无效输入测试的示例。不要心地学习它们。选择其中一些并尝试您的应用程序。考虑其他可能无效的输入案例。
了解应用程序的来龙去脉。一方面,尝试了解客户如何使用您的应用程序,他们背后的业务场景是什么。另一方面,尝试了解系统的体系结构以及数据如何从最终用户流经系统的所有模块。这是为了学习将用户视为系统的一部分,以便您能够回答特定模块中的故障会对用户造成多大的影响。
阅读好书。我强烈建议阅读“软件测试的经验教训”中的“像测试人员一样思考”一章。它将告诉您如何浏览应用程序,如何提出有关应用程序的问题,如何在应用程序和需求中发现逻辑上的矛盾等等。


评论


“软件测试中的经验教训”-很棒的书。

–乔·斯特拉泽(Joe Strazzere)
2014年3月27日在16:57

#3 楼

有一个叫Michael Hunter的人,名字叫“ The Braidy Tester”。他曾(或可能仍在)Microsoft担任测试人员。他写了一篇很好的指南来测试不愉快的道路-叫做You You Not Done Yet(pdf),虽然它的主要重点是台式机应用程序,但它也得到了更广泛的应用。我只摘录了部分标题:

输入法
除非...您已经测试过以下输入法,否则您还没有完成测试:
(8个要点)
警报
您尚未完成测试,除非…已搜索出应用程序可以显示的所有
警报,警告和错误消息以及对话框
检查了以下内容:
(15个项目要点)
文本输入字段
您尚未完成测试,除非...您已经为每个文本输入字段发现了以下边界条件
(20个项目要点)
平台
除非尚未考虑以下内容,否则您尚未完成测试:...已考虑要包含在哪个平台中以及要包含在哪个平台中从测试矩阵中删除。
(谈论桌面平台,但是浏览器绝对是
对Web应用程序的考虑!)
性能和压力
除非您没有完成测试, ..you
了解您的应用程序的性能特征以及产品在压力下变形的方式。
(18个要点)文档,a)确保正确无误,b)帮助
生成测试用例。
(19个要点)

这是一个非常有用的资源。如果您向开发人员展示它,他们可能会得出结论,那就是写工作软件是不可能的,这应该是一个很好的体验。

#4 楼

这里有很多很好的答案-尤其是特定的示例,因此我想补充说明一下,成为一般而言更“开箱即用”的测试人员。如果您是一名测试人员,则希望您已经具有与生俱来的好奇心,需要了解原因并加以推动。即使您没有花很多时间进行探索性测试,我认为重要的是培养能够以独特的方式破坏事物,找到最遥远的极端情况的技能。有两种方法可以这样做:


向他人学习。从此页面的响应中提供的列表中学习。使用现有的文档和回归步骤(并确保您更新和维护这些资源,以便它们仍然有用)。研究并应用广泛的(例如边界测试)和特定的(例如,有很多示例可以测试登录或注册页面的所有示例)。
使用您的经验。研究将使您走得更远。但是,关于这个职业的最好的事情之一是,做得越久,只要记住使用沿途所见的东西,就可以对这种特殊技能有更好的了解。在我尝试破坏某些东西的最初工作完成之后,我对以前发现的错误进行了一次脑力清查,发现在这里可能是可行的。记忆力十足,因此请确保您提交的错误报告良好,以便您可以轻松地搜索过去的发现并将其应用于当前情况。我无法告诉您多少年前看起来像我两年前从事的项目类似,而对Jira的快速搜索最终使我对要测试的内容有了很好的理解-在很多情况下,相同的结果也会结束坏了。我还喜欢跟踪发现的“非常酷”的错误,并鼓励我的团队也这样做。偶尔查看这些内容,并与其他质量保证成员共享这些内容,可以帮助每个人发挥其“开箱即用”的肌肉。

#5 楼

您可以做的一件事是开始“破坏事情”,并测试应用程序处理故障模式的能力。例如,您可以在会话期间编辑或删除Cookie。

要指导您的故障模式测试,您可以构建“故障模式影响分析”,它实质上是一个电子表格,列出了可能发生故障的各种原因-如果发生故障的可能性和严重性。 br />
祝你好运

#6 楼

教别人跳出框框思考是很好,不可能的。您必须开始做的事情是考虑以下内容:


如果我将它放在两岁的孩子的手中会发生什么
某人出于恶意目的使用该软件
如果完全不了解该软件的人使用该软件会发生什么

这些应该是您的出发点。每种情况的一个很好的例子:


在以前的项目中,多次单击项目会多次提交它们。不好。
该项目具有管理员权限,您可以使用该项目打开IE。再次使具有管理员权限的任何内容(包括cmd.exe)访问都没有好处。这增加了软件内的风险。虽然不是典型的缺陷,但可以改进的地方。


#7 楼

这里的关键问题是时间和精力的分配。对于非常微小的微不足道的嵌入式控制器而言,如果您尝试枚举它们,那么您可以测试的东西将迅速达到数十亿万亿美元。随机考虑一些凉爽而聪明的模糊事物来进行测试可能会让人心满意足,但是您这样做可能并不能帮助任何人。实际上,鉴于您有限的时间预算,您实际上可能会受到伤害。

更好的方法是:

1)我有多少时间可用,有多少测试可以我在那段时间里表演吗?

2)鉴于所涉及的“总覆盖率”非常小,那段时间我可以测试的最有价值的东西是什么?

第二个非常困难,并且会根据您在开发路径中的位置而变化。例如,在程序的早期,您将希望确定特定的测试,这些测试如果失败将消除产品的大部分功能(整个子系统完全无法使用)您当然不想摆弄如果尚未验证所有主要子系统都已启动并正在运行,请在产品的某个晦涩的角落进行一些巧妙的“开箱即用”测试。

该程序可以通过所有主要功能的预定义测试,并且您有更多时间(此阶段很少有项目进行),那么您可能会开始发挥创造力。但是,即使到那时,焦点仍应该集中在对客户重要的事情上进行仔细的考虑,并以某种优先顺序进行攻击。尽管大多数FMEA材料都是以硬件为重点的,但是您当然也可以提供一个合理,简单的框架来检查您的软件系统。我通常建议这样的内容:

A)列出所有功能较高的输入(获取海水温度)
B)列出所有输出(转向命令舵,打印天气报告,火警警报)
C)列出转换,即:将输入转化为输出的功能大块
D)列出软件的基础平台服务取决于。

然后遍历此列表,然后询问“如果该物品完全丢失,我的顾客会发生什么”或(通常更糟!)如果该物品在那里但错误。

浏览该列表,可以了解到客户受到的伤害有多严重。将多余的时间集中在清单上最严重的影响最严重的项目上。对于这些项目,请执行其他所有人提到的所有事情。尝试使其失败。压力测试。利用your的创造力。

希望这会有所帮助,

David Hetherington

#8 楼

想一想用户所做的愚蠢/砍肉的事情,然后再去做,想想在现实世界中与真实的人发生的事情:


断电,信号丢失,电话,门钟声,会议都可以打断表格的填写-如果您在晚上上班前先将表格填写一半,然后在早晨尝试完成,会发生什么情况?
我最喜欢开发人员讨厌的Web测试是登录作为一个用户,开始填写表单,在另一个窗口中以其他用户身份登录,运行查询或调用表单,返回到原始窗口,然后单击提交,并使用其他浏览器进行编辑。 -如果需要检查前几页中的内容,人们有时会做确切的事情-应该指明行为是什么?
年长的或实验性的浏览器通常能够产生缓慢或共享Web的有趣结果连接,防火墙等。曾经有一个网站演示过,在配备19英寸XGA显示屏和T1连接的Mac上看起来很花哨-我让他们在带有VGA的9600波特连接的PC上进行尝试。
非常受欢迎的做法是安装屏幕阅读器,关闭显示器,然后尝试仅通过键盘使用该系统-开发人员可能会诅咒您,但仅在美国,估计有600万以上的盲人或视力障碍的成年人就不会这么做。
尝试转向降低显示器上的颜色或更改显示设置以模拟色盲-是否使表格无法使用?(大约8%的男性,但只有0.5%的女性在某种程度上处于色盲状态)。 >尝试不回答二进制问题-如果某人不愿回答或正在过渡中,即使是男性/女性也可能是一个问题-出生时与我现在最喜欢的问性别问卷的答案可能有所不同。是“尽可能频繁地”。


#9 楼

我相信,要查找良好的错误或更多的错误,您:


,您需要深入了解功能,并且您应该了解应用程序的所有来龙去脉。<领域知识也至关重要。
尝试用不正确的数据攻击应用程序。
对应用程序进行压力测试。
进行否定测试。

更多信息可以查找错误的示例。