黑盒测试方法论

最新推荐文章于 2024-04-24 15:18:04 发布

鳳舞酒天

最新推荐文章于 2024-04-24 15:18:04 发布

阅读量1.6k

点赞数

分类专栏： test 文章标签：单元测试测试工具 python

原文链接：https://www.zhihu.com/question/272193009

版权

test 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

作者：黑马程序员
链接：https://www.zhihu.com/question/272193009/answer/1869290084
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

一、测试用例的引入

首先要思考两个问题：什么是测试用例？测试用例的构成要素？

1.测试用例的定义

2.测试用例的构成要素

在实际工作中根据项目要求对用例设计要素可做调整，下图基本覆盖常见用例设计模板。

从上面两点可知：

测试用例的定义：软件测试的核心，为了特定的目的而设计的一组测试输入、执行条件、预期结果的输出文档；

测试用例构成要素：用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤预期结果。

二、黑盒测试用例设计方法

1.等价类

概念：在所有测试的数据中心，具有某种共同特征的数据子集

方法：

举例：

子例：固定电话号码测试

地区（3/4位）+电话号码（7/8位）

2.边界值

大量的错误是发生在输入或者输入范围的边界上，而不是输入范围的内部。

题目：输入的参数值必须大于等于0同时小于等于100的整数

正确代码：

num>-1或num>=0 num<101或num<=100

错误代码：

num>=-1或num>0 num<=101或num<100

边界值：选取正好等于、刚刚好大雨或者刚刚好小宇边界值作为测试数据。

举例：

例子：固定电话号码测试

地区码（3/4位）+电话号码（7/8位）

3.判定表法

使用等价类方法时对于输入域及输入域存在关联时无法覆盖

移动通信中，有这样的需求，若用户欠费或者停机则不允许主被呼叫。

案例：支付宝个人账户注册——验证用户名需求：第一项要求输入手机号或者电子邮箱作为账户名，第二项要求正确输入验证码，两项都验证成功后填写账户信息；但如果第一项校验不正确，则报错L（输入手机号或电子邮箱格式错误）；如果第二项验证不成功，则报错M（验证码输入错误）。

4.因果图法

判定表法设计用例——规则数：2的n次方（n是条件数）

条件数：4 —> 规则：16

条件数：5 —> 规则：32

条件数：6 —> 规则：64

条件数：7 —> 规则：128

………

因果图：

1、考虑所有输入/输出条件的相互制约关系以及组合关系

2、考虑输入条件之间的依赖关系

3、再根据分析的关系来转化为判定表的规则

5.状态迁移图法

状态迁移图：首先要找出所有的状态，然后再分析各个状态之间的转换条件和转换路径。然后从其状态迁移路径覆盖的角度来设计测试用例。（多用于协议测试）

测试步骤：

案例：飞机售票系统

客户向航空公司打电话预订机票，此时机票信息处于“预定”状态
顾客支付了机票费用之后，机票信息变为“已支付”状态
旅行当天达到机场，拿到机票后，机票信息变为“已出票”状态
登机检票后，机票信息变为“已使用”状态
在等级之前任何时间都可以取消自己的订票信息，如果已经支付了机票费用，还可以退款，取消后，订票信息处于“已取消”状态

抽取四条路径：

路径1：预订—已取消
路径2：预订—已支付—已取消
路径3：预订—已支付—已出票—已取消
路径4：预订—已支付—已出票—已使用

6.场景法

软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

重要概念：

基本流
备选流
（异常流）

场景1：基本流
场景2：基本流—备选流程1—基本流
场景3：基本流—备选流程2—基本流
场景4：基本流—异常流程1
场景5：基本流—备选流程2—异常流程2
场景6：基本流—备选流程1—备选流程2—异常流程2
场景7：基本流—备选流程1-备选流程2—基本流
场景8：基本流—备选流程1—异常流程1

案例：支付宝个人账户注册——验证用户名需求：第一项要求输入手机号或者电子邮箱作为账户名，第二项要求正确输入验证码，两项都验证成功后填写账户信息；但如果第一项校验不正确，则报错L（输入手机号或电子邮箱格式错误）；如果第二项验证不成功，则报错M（验证码输入错误）。

设计用例如下：

用例1：第一项输入手机号，第二项验证码正确，进入填写账户信息页面
用例2：第一项输入电子邮箱，第二项验证码正确，进入填写账户信息页面
用例3：第一项输入不是手机号或者电子邮箱，报错L（输入手机号或者电子邮箱格式错误）
用例4：第一项输入手机号或者电子邮箱，第二项验证码错误，报错M（验证码输入错误）

7.正交实验法

正交实验设计方法：是由数理统计学科中正交实验方法进化出的一种测试多条件多输入的用例设计方法，从大量的（实验）数据（测试例）中挑选适量的，有代表性的点（例），从而合理地安排实验（测试）的一种科学实验设计方法。

条件：因子取值：水平。

正交实验设计方法步骤：

三、总结

5分钟 2个实例图解教会你写测试用例。

测试用例模板下方获取

这里为你准备了200G软件测试教程资料，以及100+的名企大厂测试开发内推资源，免费分享给你，点击下方链接立即获取：

免费领取：简历模板+面试技巧+用例模板+报告模板+自动化测试+性能测试+测试开发29 赞同 · 4 评论文章

今天不讲方法，只讲实例

首先看下面雪球APP的登录页面，这一个简单的页面，你觉得能写多少条测试用例？

是不是觉得最多十几条？

答案是100条以上！

我画图来告诉你为什么：

高清原图文末获取

这里汇总一下，单说账号密码登录模块，用例编写可以总结为下图：

高清原图文末获取

看到这里，是不是整个登录页面，全部写完，得个100条以上的用例？

需要上面图解和思维导图高清图的，文末自行获取。

之前做Android测试的时候，在测试音频媒体播放器的时候，我编写的测试用例非常的简单：

播放器正常开启、暂停、停止；
播放器在播放时切换下一首歌、上一首歌；
播放器在播放时突然停止，几种常用格式音频文件播放；

看似基本的功能都覆盖到了，然后也按照这个用例一直执行者，直到我看到了google工程师的测试用例，我就彻底跪了，为了方便阅读，我也做成图示：

--福利福利--

免费领取：简历模板+面试技巧+自动化+测开+性能+用例模板+核心教程资料

测试在职如何拿到20k+高薪offer？

--推荐阅读--

好的软件测试人员简历是什么样子的？113 赞同 · 26 评论回答

如何编写测试用例？158 赞同 · 18 评论回答

软件测试简历项目经验怎么写，没有项目经验？33 赞同 · 26 评论回答

怎么写测试用例？？？

测试用例是每个软件测试工程师入行的必备技能，也是比较考验我们测试思维以及测试基本功的一项任务。我们根据2W1H来描述我们编写用例的过程：

When:项目立项后，对项目进行需求分析后，开始着手编写测试用例；
Where:用例一般写在Excel或者是word里面，利用这两个文档对用例进行存档；
How：用例设计一般采用的方法有等价类、边界值、错误推测法以及场景法等。

一条完整的用例，一般包含如下信息：序号，功能模块，用例标题，前提条件，测试步骤，期望结果，实际结果，备注。对用例的元素进行整理，如下表所示：

针对上述测试用例关键信息字段的描述，我们来小试牛刀，针对注册功能模块来编写注册的测试用例：

此用例并不完整，只是抽取了一些比较典型的用例，一般新手编写测试用例，会采用如下的方式：

1）根据功能模块，把输入参数项从上到下分别罗列出来进行用例编写；

2）针对上述罗列出来的输入参数项分别用：等价类、边界值、错误推测法以及场景法设计测试用例。

所以上述用例，还有手机号码、密码的用例设计不完整，这里就留给大家自行去思考编写！

再出一道笔试题：70%测试员会遇到的笔试题，这样的测试用例，你会怎么做？

一、为什么要写测试用例？

或者说，写测试用例到底有什么用？

敲黑板！测试用例主要有以下六大作用：

方便理清测试思路，避免漏测
有助于测试工作量的评估
便于提前准备测试数据
相当于工作日志，把控测试工作进度
方便进行上线前的回归测试
便于测试工作的组织，提高测试效率，降低测试交接成本

所以，写测试用例是很有必要的！

那些没有写测试用例、或者说写测试用例没有用的，都是没有掌握测试用例的使用姿势。

二、传统的测试用例编写规范

一般写测试用例，大家习惯于用 「Excel（表格）」 或者 「Xmind（思维脑图）」。

一般用 Excel 要表达的元素有：用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、预期结果。

比如说，我们要测试一个“常规搜索关键词输入”的功能，我们用 Excel 来表达，类似下图所示：

假如我们用 Xmind 来编写测试用例，大概呈现成：

可以看到用 Excel 和 Xmind 去设计测试用例，粒度以及使用场景都不太相同。

「在一些功能比较单一、步骤简单、输入和预期比较明确的场景，可以采用 Excel 的风格去编写测试用例。」

「在一些功能比较繁杂、依赖测试人员的主观能动性的场景，可以采用 Xmind 的风格去编写测试用例。」

三、臻叔独创的测试用例编写模版

现在在互联网公司，产品迭代很快，功能也比较复杂。

如果用 Excel 去设计测试用例的话，会花费比 Xmind 更多的时间去编写，而且编辑维护、可读性等等，都比较差。

项目这么紧急，用 Excel 去写测试用例，显然是不合理的。

「所以用 Xmind 的方式去编写测试用例，在互联网测试圈子里面也是深得人心。」

「但是，在一些回归验证的场景，是可以用 Excel 去写测试用例的，我们习惯把回归用例当作上线 CheckList，逐条去验证，防止遗漏。」

小细节

日常测试工作，用 Xmind 去编写测试用例。
上线环节，用 Excel 去编写回归用例，确保万无一失。

那么，我们日常测试，「用 Xmind 编写测试用例时，需要注意些什么呢」？

「照抄产品需求文档没有必要的！」 这么做的坏处是：做了很多重复工作，而且思维容易被产品思维框住，有些不合理的地方或许难以发现。
「测试用例一定是可执行的！」
「测试用例并不是写得越多越好」。写得太多，可读性很差，也会无形之间给自己增加心理压力，而且根据二八原则，80%的bug都出现在20%的主流程上面。那异常测试做不做？当然要做！但是千万不要把异常测试作为重点，重点应该是站在用户的角度，优先保证核心主流程。
「测试用例要体现测试目标」，注意，这里不仅仅是预期，而是测试目标，要明白测试这条用例，到底目的是啥，产品功能和意图是否已经实现。
测试用例设计最好遵循金字塔原理，「尽量穷尽，完全独立，避免太多重复的用例」。
「测试用例千万要做好分等级」，优先重点。
根据测试用例逐条进行测试时，还可以在「测试用例上做一些标注」，标记测试情况。
测试用例不仅仅是用例，对于一些构造的「测试数据也可以在测试用例上体现出来」，方便后续回归验证。
「测试用例需要注明用例基本信息」，还可以记录一些文档的链接（比如需求文档、技术文档）等等。
「用尽可能少的用例，覆盖绝大部分的测试场景」。

所以，新式的测试用例，感觉不该叫测试用例，应该叫 「“测试日志”」 更加合适。

下面，我将把我是「如何构思和设计测试用例」，一步一步给大家呈现出来，是时候展示真正的技术了！

第一步，把测试用例的基本信息表示出来。

基本信息包含：「干系人、测试范围、用例说明、关联文档」等等信息。

有了这些信息，就可以把测试用例当成一个入口，提升查找相关文档的效率。

第二步，开始写测试用例。

这一块可以因人而异去设计，遵循几个原则：「不要照抄需求文档、设计的用例都是可执行的、用例做到分级、尽量穷尽，完全独立，避免太多重复的用例」。

设计用例的时候，最好可以从测试目标出发，再进行向下延展。

举个例子：

第三步，用例评审。

用例评审就是拉个会，喊上开发、产品和设计，针对编写好的测试用例进行评审。这个环节需要在开发提测之前进行。

主要目的：

沟通测试用例有没有遗漏的地方，评估当测试用例执行完，没有bug的情况下，是否可达到上线标准。
和开发约定好，在开发自测阶段，开发需要保证冒烟测试用例能够通过。冒烟用例通过基本上可以作为提测标准。
和开发、产品对接好上线前的验收标准。

第四步，执行用例。

一边执行用例，一边做好标记，方便查处bug之后，后续有针对性的去验证，而不是又从头把用例再走一遍，提升回归验证的效率。

另外，对于测试过程中，用到的一些测试数据，也可以直接在用例上标注出来，提高后续回归测试的效率。

「当测试完毕，达到上线标准之后，我们需要准备一份 CheckList，在上线当天使用」。

CheckList 比较强调步骤性，所以适合用 Excel 去表达。

上线无小事，一定得谨慎！

所以，知道怎么写测试用例了么？

下面是闲聊时间，臻叔想和大家一起聊聊三个很现实的问题：

「没时间写测试用例怎么办？」
「全量的测试用例是否有必要？」
「测试用例应当如何保存？」

四、没时间写测试用例怎么办？

身处互联网公司，项目时间紧，三天两头就要上线一个新功能，这是常态。

有的测试老司机在这种情况下，就放弃写测试用例，直接上手就测，其实这是很不好的习惯。

写测试用例不是面子工程，没有必要追求极致，写得像满分作文一样。

「其实写测试用例最主要的作用，就是帮助测试人员提升工作效率」，

一方面，通过写测试用例可以对需求更加熟悉，脑子理顺；

另一方面，测试用例可以更好的指导你进行测试工作，尤其是你做好测试标记之后，对于后续验bug很有必要。

不写测试用例，不应该拿时间紧作为借口。

「我们应该根据需求的重要程度、难易程度来评定要不要写测试用例。」

如果是一些紧急且重要的需求，那肯定要写测试用例；如果只是一句话的需求、几个文案的改动，那这种不写测试用例也罢。

都是成年人了，应该要有判断力。

五、全量测试用例是否有必要？

以前入职一家新公司，导师总会要求新员工去写一份全量的测试用例，或者说丢一份很全的用例给新员工去阅读，说是帮助新员工更好的熟悉系统。

但是工作久了，我发现这对于新员工的培养，并不能起到什么效果，反而让新员工产生厌烦的心理。

写一份全量的测试用例是没有意义的，就像你让一个小学生去背字典一样，毫无意义。

「那怎样让新员工更好的融入到工作当中，快速上手呢？」

最好的办法就是将心比心，你「把自己所有的文档分门别类，多画点系统架构图、流程图，新员工培养手册等等，把这些给到新员工」，我觉得是比丢一个全量测试用例给一个测试新手更有用。

六、测试用例应当如何保存？

当然不是随手一丢，仍垃圾桶。

如果公司有条件的话，可以有个用例平台，把项目-需求-测试用例进行关联，后续遇到bug，都可以有迹可循，方便总结和回溯。

如果公司没有那么好的条件，可以用gitlab进行维护，进行版本控制。

字节跳动推出了飞书，里面的飞书文档也是特别香的，自带文档管理功能，而且还有飞书脑图可以替代 Xmind 进行测试用例编写，也是一种不错的保存测试用例的方案。

>>测试前：

1）对测试目的有一个清晰的认知

无论是对任何软件或是模块，编写测试用例前，一定要弄清原始需求。最好能与提出测试需求者有一次比较清晰的交流，这样避免又测试遗漏点。

2）熟悉产品的功能测试点

编写测试用例，一定要覆盖所有需求点，这是我们最基本的工作，一名测试人员专业度的体现。对于功能测试需求，一定要细化到每一个使用细节，并通过测试用例展现出来。

3）熟悉模块原理，避免“互相影响”问题的产生

熟悉模块原理后，注意易于分析软件模块的关联性问题。对于一款软件来说，尤其是大型软件，需要由多个模块共同组合而成。而在测试是，你会发现，软件越大，耦合越大，“互相影响”的可能性就会越高。在设计用例时，如果我们单单从模块本身考虑，不注重“共同作用”的问题，很可能会对其他模块造成“意外伤害”。

4）关注用户场景问题和上网问题

在设计测试用例前，我们还应考虑应用安装在不同设备上，是否会产生使用用户场景不同，而获得的体验不同的问题。另外，网速对软件使用本身也会造成影响，在设计用例时，也需要考虑在内。

5）不可马虎的关键测试用例设计

在写测试用例时，还有一个值得注意的就是关键测试用例。何为关键测试用例？你可以把它看成是对系统最重要的功能测试用例。

举个例子：对于手机里的计算器来说，如果他不能执行“3+3=？”这个问题，那么基本这个软件也就“废了”。

所以，系统的用途决定了关键测试用例的内容。也就是说，关键测试用例必须服务于系统，并且要符合系统用途的要求。包括“正向”要求，比如“3+3”问题。当然，也会包括“逆向”要求。比如在输入银行密码时，一般最多可以错3次，否则就吞卡处理了。

>>编写测试用例时：

1）构建测试用例框架

一个测试用例框架的构建，往往反映了一个测试人员对软件产品的熟知度，以及整体思路的专业度。而用例框架也是从大到小划分下来，依次是：UI界面、功能、容错、兼容、性能等几个大类。我们需要根据软件的逻辑等，将每个大类划分成小类，后细分到测试点。

2）测试步骤的设计

测试用例可以写的很详细，也可以写的比较简单。这当然取决于公司的要求，也取决于软件本身的复杂程度。

关于这个问题，我想说两点心得体会：一是如果步骤过于粗糙很容易出现漏测问题；二是写的过于细致，可能耗时耗力，并且会限制执行人员的思维。

所以，在设计用例时，一定要把握好详细程度的分寸，符合产品本身的整体特点即可。

>>测试用例设计方法及思考

软件测试用例的基本要素，包括：测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。测试用例设计常用的7种方法，包括：等价类、边界值、场景设计法、判定表、因果图、正交法、错误猜测法。

关于上述2个内容，我们之前的内容中已经讲解了，再此就不赘述了。不清楚的同学可以翻看我们之前的内容，或者上百度查找，都是可以的。

下面说说我关于测试用例设计的一些思考。

1）切记产品测试的主要目标

测试新手们先思考一下产品测试的本质是什么。

笔者以为，产品测试的本质是发现功能、流程、界面等现存的产品问题，而不是提出功能或界面的产品优化方案。不知道大家认不认可？

虽然我们的工作也包含给出功能或界面的优化建议，但毕竟，这不是我们的主要任务。根据我的亲身经历，我认为，测试新手往往容易出现这种“本末倒置”的行为。即，花大量时间去思考如何优化，而非找出产品所隐含的bug。

为什么会这样呢？笔者以为，这主要是由2个原因造成的。

一是产品本身存在的优化空间很大。试想，如果你拿到一款完全不符合时下主流风格的产品，是否也会想给他提各种优化意见？这就不难理解测试新手在遇到一款设计界面糟糕的产品时，容易出现跑偏的问题了。

另一个是思维方式没有及时转变。对于测试新手来说，基于对固有事物的认知，我们往往会带有策划思维，或者追求“圆满性”思维看问题，这两问题也容易造成本末倒置的问题。

所以，对于测试人员来说，我们必须谨记测试目标，坚持以‘提bug为主，提需求为辅’的状态，来确保我们的工作进度与审美之间的两不误。

2）注意用词精准问题

作为软件上线前的最后一道工序，软件测试既是对产品质量的检测，也是对普通用户的负责。因此，协助开发人员查漏补缺是我们的常态。这就不得不提到沟通问题了。

之所以笔者要写用词精准问题，主要也是为了解决由于沟通不到位，造成测试人员与开发人员“剑拔弩张”的问题。那么，日常工作我们应该如何合理的提问呢？笔者以为，可以用这个方法来描述问题：产品漏洞是什么+问题在哪里+严重程度+解决办法或意见。

例如，邮箱登录页面有一个bug。当我在密码栏输入“777777”时，无论原密码是什么，都能打开这个邮箱。这个类似于“万能钥匙”的密码可能会导致邮箱信息泄露，非常严重，请在1-2个工作日内解决。建议检查对应区域代码条件设置是否出现遗漏。

鳳舞酒天

关注

0
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
黑盒测试方法论

作者：黑马程序员链接：https://www.zhihu.com/question/272193009/answer/1869290084来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。一、测试用例的引入首先要思考两个问题：什么是测试用例？测试用例的构成要素？1.测试用例的定义2.测试用例的构成要素在实际工作中根据项目要求对用例设计要素可做调整，下图基本覆盖常见用例设计模板。从上面两点可知：测试用例的定义：软件测试的核心.
复制链接

扫一扫