编写测试用例？

一、编写测试用例？

以下是我的回答，编写测试用例是软件测试中非常重要的一环。通过编写合理的测试用例，可以全面覆盖软件的各种功能和场景，确保软件的质量和稳定性。首先，我们需要了解软件的功能和需求，明确测试的目标和范围。然后，我们可以采用不同的方法来编写测试用例，比如黑盒测试、白盒测试、灰盒测试等。在编写测试用例时，我们需要考虑各种输入和场景，包括正常情况、异常情况、边界条件、性能要求等。在编写测试用例时，还需要注意以下几点：测试用例应该具有可重复性，以便进行回归测试和自动化测试。测试用例应该具有可维护性，以便在需求变更时及时更新和调整。测试用例应该具有可扩展性，以便支持多种平台和环境。测试用例应该具有可读性，以便其他测试人员能够快速了解和执行测试。总之，编写测试用例是软件测试中不可或缺的一环，它可以帮助我们全面验证软件的功能和性能，发现潜在的问题和缺陷，提高软件的质量和稳定性。

二、写完测试用例后，怎么去执行测试用例？是靠人工点点点吗？还是用禅道去执行？

如果做手工测试的话，禅道中可以提交测试用例，然后自行测试，最后在禅道中进行提交管理。

不过，目前禅道也推出了自动化测试解决方案：

推出自研的开源自动化测试框架ZTF和通用数据生成器ZenData，加上禅道项目管理软件构成了专业的自动化测试解决方案，可以帮助用户实现规模化自动化测试，提升测试效率。

禅道、ZTF和ZenData相互独立又相辅相成，配合Jenkins持续集成平台，以及JUnit、Selenium等单元、自动化测试框架和工具，构成完整的自动化测试解决方案。

用户可使用Jenkins来驱动ZTF执行某种类型的自动化测试，测试过程中脚本通过访问ZenData生成的数据文件或API接口获取结构化的测试数据，从而实现数据和脚本的分离的目的。

三、如何编写测试用例？

带着问题学习是最高效的学习方法。

因此，在介绍如何编写测试用例之前，先看一个软件系统登录功能的测试（如下截图所示）：

要做这个登录页面的测试用例，你会从哪些方面思考进行测试呢？

看似简单的页面功能能够设计多少条测试用例完成较全面的测试呢？10条以内？20条？.......

那么在给出上述答案之前，先带大家熟悉一下什么是测试用例？测试用例有什么作用？ 然后在结合上述抛出的案例抛砖引玉一起讨论如何编写测试用例？

下面就是此文目录截图：

一、什么是测试用例

测试用例：为了特定的目的（证明软件存在某问题）而设计的一组由测试输入、执行条件、预期结果构成的文档

1、测试用例简单来说就是指导如何做测试的文档，该文档主要记录需要验证被测软件的是否满足需求

2、测试用例表现形式常见的有两种，可以以模板形式展示

1）一种是通过Excel直接编写

——大多数项目中都需要按照这种方式设计编写

2）一种是通过xmind直接整理测试点

——时间紧迫，项目没有强制要求时，可以设计测试点的形式编写 ——对于业务流程类的测试，也可以整理为测试点进行测试

3、设计及执行人员：测试工程师

4、用例的模板：描述编写用例核心内容，一般项目都有自己的设计用例的模板，常见测试用例模板可参照如下：

用例模板具体该如何撰写，可以看下这篇文章，堪称手把手教你如何写测试用例，强烈推荐看：

感觉测试用例好难写怎么办?

二.为什么要写测试用例

为什么要写测试用例，实际中产品出现问题，第一责任人首先想到的是测试为啥没有测到？

产品出现问题了，你为啥没有测出来呢？

当然，除了避免“甩锅和背锅”，其实写测试用例更重要的作用如下：

技术上将需求转化为具体可验证的指标
以文档的形式记录软件可能存在的问题
防止测试过程的活动出现遗漏，提高工作效率
测试工作量的展示

三.如何编写测试用例

既然写测试用例如此重要，那么如何更好的编写测试用例呢？个人认为需要满足如下几点：
- 常规思考，设身处地的从用户角度出发（比如：实际用户是这么使用的么，会不会遇到异常情况呢？）
- 测试理论方法的支撑（比如：根据需求设计测试用例时，能用到哪些常见的测试用例设计方法？）
- 产品的熟悉和经验的积累（比如：已经有过类型项目经验，曾经在某个方面有过问题，当时是如何处理的呢？）

上述的设计用例过程，有个前提，就是对于测试有耐心和毅力，加上日常有意识的思维训练，才会写出全面的用例。

1、常规思考

回归到开篇的问题，对于一个基本的登录页面，按照常规思路能否会想到如下截图的测试点呢？实际，这些测试点都是源于从用户角度出发，结合需求进行细化设计的过程。实际测试中是不是只有这些测试点呢？

2、学习积累

相信大多数测试工程师都能够想到上述基本的测试点，然在实际工作中面对的项目不同，设计测试用例的颗粒度也有不同的要求，如果针对上述登录的模块，更深入一层考虑呢？此时需要对产品的熟悉程度及测试经验的加持，而且这些点的设计是不断学习、熟悉项目、测试积累中得到的。

3、理论支撑

有了常规的思考，有了经验的积累，还需要理论的支撑。测试用例毕竟是通过人去思考设计，这个过程不可避免有疏漏。如何规避？实际就需要测试理论的支撑，个人认为深入思考设计用例不外乎以下两方面：

1）测试用例的设计方法

测试理论中很关键一块就是将需求拆分为具体的测试点，然后根据用例设计方法进行具体的设计，其中拆分需求的关键是熟悉需求，将文档中已有的描述内容，按照用户使用场景、个人测试经验的积累（如果有的话）、把大段的内容拆分成能够直接用用例设计方法的测试点，这样就直接可以通过简明扼要的文字描述转化为Excel的测试用例，在这个过程通俗理解就是拆分细化的过程，直到可以直接写用例验证一个具体的功能点即可。

其中熟知的设计用例方法有：

- 观察法

- 等价类、边界值

- 判定表、因果图

- 流程图、场景法

- 错误推测法等

2）测试设计的思路开拓

倘若按照需求将已有的描述信息都已经拆分完毕了，是不是就可以确保测试没有问题了呢？其实不然，在上述基础上如果还需要再拓展全面测试，还需要借助于软件质量模型的特性，从这些特性出发，给予测试用例设计者更多的思考空间。这样的设计就更加的全面可靠。

常见软件质量模型特性说明：

- 功能性：功能有没有，好不好用

- 性能效率：对应系统的资源耗费程度及响应时间

- 易用性：容易理解、学习、使用

- 兼容性：能够兼容不同的软硬件平台

- 可靠性：不易出问题，万一出问题容易恢复

- 安全性：对于用户的安全保障（外在的人生安全、内在的信息安全等）

- 可移植性：能否在不同环境条件下无故障运行

- 可维护性：对于后期的修复维护是否方便快捷

因此，对于上述登录功能，按照上述质量模型的思路指导，就得到如下的测试点：

用例实战：

面试官问:给你一个物件（花瓶、笔、桌子）你怎么测试？

(1)问题分析：无论是哪个物件,都从以下几个维度出发设计: 1、功能 2、UI 3、易用性 4、性能 5、安全 6、接口 7、兼容性 8、可移植 ....也可以适当缩减和增加（2）参考回答: 给你一个杯子你怎么测，至少写出20条测试用例1.功能测试：主要关注水杯基本功能1.1 水杯是否可以正常装水1.2 水杯是否可以正常喝水1.3 水杯是否有盖子，盖子是否可以正常盖住1.4 水杯是否有保温功能，保温功能是否正常保温1.5 水杯是否会漏水，盖住盖子拧紧后是否会漏水2.ui测试：主要关注水杯外观、颜色、设计等方面2.1 外观是否完整2.2 外观是否舒适2.3 颜色搭配及使用是否让人感到舒适2.2 杯子外观大小是否适中2.3 杯子是否有图案，图案是否易磨损3.易用性测试：主要关注水杯使用是否方便3.1 水杯喝水时否方便3.2 水杯拿起放下是否方便，这里会衍生到水杯形状的测试3.3 水杯装水是否方便3.4 水杯携带是否方方便3.5 水杯是否有防滑功能3.6 水杯装有低温或者高温水时，是否会让手感到不适4.性能测试：4.1 水杯装满水时，是否会漏出来4.2 水杯最大使用次数4.3 水杯的保温性是否达到要求4.4 水杯的耐寒性是否达到要求4.5 水杯的耐热性是否达到要求4.6 水杯掉落时，是否可以正常使用4.7 水杯长时间放置时，是否会发生泄露5.安全性测试：主要关注水杯外观和各种异常条件下是否释放有毒物质等5.1 当水杯装满热水时，水杯是否会烫手5.2 当水杯装上水后，是否会产生有毒物质5.3 把水杯放在零下环境时，是否会产生有毒物质5.4 把水杯放在高温环境时，是否会产生有毒物质6.接口（杯子没有想到怎么和接口关联起来）7.兼容性测试：主要关注水杯是否可以装其他液体，如果汁、汽油、酒精等8.可移植性测试：主要关注水杯放置环境等8.1 将水杯放在常温环境中，使用是否正常8.2 将水杯放在零下的环境中，使用是否正常8.3 将水杯放在高于正常温度的环境中，使用是否正常

你看，这道面试题是不是就轻松解决了？

四、写在最后

此时的你再回过头来看看，还会认为登录这个百试不爽的功能就设计十几条甚至几十条测试用例了吗？显然不是那么简单，需要在熟悉需求基础上，进行拆分细化，将常规的思考、经验的积累、理论的支撑结合起来使用，最终才能转化为测试待验证的结果。

熟悉需求上第一步，在此基础上进行测试点的拆分细化，这个过程如果对于复杂一点的功能点，需要借助于测试用例的设计方法，对于页面级的测试点应用最多的不外乎是等价类、边界值。

仅仅熟悉了需要，还需要结合经验的积累，从质量模型的特性出发，进行全面的思考功能点的设计，是否出现遗漏的，是否有项目特殊要求的。

最后，用例的设计不是一蹴而就的事情，好的用例也是需要不断的练习，反复的修改评审，才能编写出卓越的用例。

如果文字看过后还觉得不过瘾，还可以看下面这篇知乎文章：

如何写出高效的软件测试用例？测试工程师都是怎么写测试用例的？有哪些比较好的测试用例管理工具？感觉测试用例好难写怎么办?

黑马测试还录制了6套测试用例设计方法的相关视频，需要者可以访问:

《实战项目带小白入职7-12k功能测试岗位，仅7小时【史上最快】》密码：yn8r本视频b站链接：https://www.bilibili.com/video/BV1kw411o756
《黑盒测试用例设计》密码：5k9c本视频b站链接：https://www.bilibili.com/video/BV1YT4y137WA
《白盒测试用例设计》密码：fj4k本视频b站链接：https://www.bilibili.com/video/BV1cC4y1s7Bx
《测试入门_9天黑马手工测试理论+实战完整分享_适合0基础》密码：1q2m 【前3天视频中就涉及测试用例，后6天就是手工测试实战】本视频b站链接：https://www.bilibili.com/video/BV1at4y1Y7AN
《移动端App测试_最新2020教学视频》密码：gpin【正有题主需要的app测试用例】本视频b站链接：https://www.bilibili.com/video/BV12o4y1k7Kb
《功能测试_6天黑马手工测试2021版》密码：ghpr本视频b站链接：https://www.bilibili.com/video/BV1QM4y137xX

码字不易，如果此文章对你有帮助的话，点个赞收个藏，给作者一个鼓励。也方便你下次能够快速查找。

---------------------------------------------------------------------------------------------------

最后，为方便大家自学软件测试，特意给大家准备了一份13G的超实用干货学习资源，涉及的内容非常全面。

包括软件学习路线图，黑马50多天的上课视频、16个突击实战项目，80余个软件测试用软件，37份测试文档，70个软件测试相关问题，40篇测试经验级文章，上千份测试真题分享,还有2020软件测试面试宝典，还有软件测试求职的各类精选简历，希望对大家有所帮助…..

2020软件测试学习路线图,内附视频教程+自学路线+工具+面试篇-黑马程序员技术交流社区

黑马精华知乎文章推荐

四、软件测试用例编写规范标准？

根据系统需求规范写系统测试用例感觉有点困难。

是因为这个时候功能描述还比较泛，感觉会感觉编写用例有点困难，这个时候编写的用例粒度可以比较粗，不用写的很细节（估计也写不出来很细）。

到了设计环节，功能点比较明确，用例也可以再细化。

在实际过程中，一般就是在需求阶段心里有个大概的测试策略，不会具体去写用例。只有到设计确定后，才有可能开始编写，为了简化工作量和预防需求变化用例又得重写的麻烦。

结合硬件的测试，编写用例和一般软件测试没啥区别，就是编写你要考虑的测试点，然后想想怎么测试（测试步骤和数据）

五、如何编写有效测试用例？

测试用例要达到最大覆盖软件系统的功能点。

测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。测试用例的设计应包括各种类型的测试用例。在设计测试用例的时候，除了满足系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受压力的能力等。测试用例的管理。使用测试用例管理系统对测试用例进行管理。

六、编写测试用例有哪些方法？

编写测试用例是软件测试中非常重要的一个环节，其目的是确保软件产品在各种情况下都能正常运行。以下是几种编写测试用例的方法：

1.边界值分析法：该方法将测试数据的边界作为测试用例的关键点，以测试边界值的处理是否准确。

2.因果图法：该方法通过使用因果图找出所有可能的输入事件以及事件之间的相互影响，以便设计全面的测试用例。

3.等价类划分法：根据输入值的特性将测试数据分为一组等价类，并选用这些等价类中的数据作为测试用例。

4.错误推测法：通过分析已知的软件缺陷或经验，推测软件产品可能存在的缺陷并创建测试用例。

5.场景法：通过将相关的测试项组合成场景，测试整个系统是否能够正确运行。

6.符号意义法：将测试用例中的符号意义定义清楚，通过变量的取值来确定测试用例。

7.普通测试用例法：通过详细阅读需求文档和设计文档，根据其做出的描述编写合适的测试用例。

总结：在编写测试用例时，测试人员应该根据实际情况选用适当的方法来编写测试用例。测试用例编写应该考虑全面，确保测试的全覆盖。

七、怎么编写王者荣耀背包的测试用例？

没办法看到王者荣耀的策划案，不过背包用例不外乎几种操作，我对着背包界面写了个大概的检查点，实际上全部内容扩展出来应该有100多条，请根据实际情况增补。

背包界面的基本展示，进入、返回。

左侧的7个标签：全部、最近获得、道具、礼包、体验卡、局内表现、铭文，这些分类按钮是否能正常点击切换，每个物品的类别是否正确。点全部是不是所有物品都显示了，每个类型的该出现在哪的就出现在哪，某个分类里不应该出现其他分类的东西。

背包中每页显示多少个物品，背包为空的时候进入退出是否正常，少于一页是否能正常显示，多于一页是否能正常翻页。

背包中有多个物品种类时，排序是否正常（要和策划、开发确认默认的排序是什么），反复进入、退出、用掉一两种物品，排序是否会乱。

获得一个物品，检查这个物品是否正常放入背包，是否正确排序。在王者荣耀中，能够获得的物品包括：铭文、皮肤碎皮、英雄碎片、英雄体验卡、皮肤体验卡、双倍金币卡、双倍经验卡、改名卡、活动道具（喇叭、优惠券、限时播报和回城效果），每种写一条用例。

使用一个物品，这个物品还有剩余，检查物品数量是否-1。（以上所有物品都用一遍）

使用一个物品，这个物品全部被用完了，检查背包内的物品是否消失，排在后一位的物品是否自动填补这个物品的空位。

批量使用物品，但是不用完，检查物品数量，检查该物品的效果是否生效。

批量使用物品，当某种物品用完时，排在后一位的物品是否自动填补空位。

出售一个物品、批量卖出物品，照着使用物品的用例，把使用换成卖出再测一遍。

当物品是铭文时，装备、卸下、分解铭文，检查背包里的铭文内容是否正常变化。

物品叠加上限（如果有），这个要找开发确认，每一格最多叠加多少个，如果玩家有生之年能叠到上限，那么测一下达到上限时，再获得一个会怎样，是另开一格叠加，还是不再获得，必须用掉才能获得。（总之要有个处理方案，不能崩了客户端）

接上，物品叠加到上限后，用掉或卖掉几个，再重新获得，能不能正常叠加。

背包上限（如果有），同样找开发确认，背包一共有多少个格子，现有的道具种类能不能塞满格子，如果能塞满，那么测一下背包格子塞满的时候，再获得一种物品会怎样，是不是能正常提示背包满了？

接上，背包满了之后，用掉或卖掉一种物品，再获得这种物品或者其他物品，是不是能正常获得了。

八、蓝牙功能测试用例应该怎么去编写？

编写蓝牙功能测试用例需要根据蓝牙协议和功能特点，设计测试场景和测试步骤，涵盖连接、传输数据、断开等方面，并考虑不同设备和平台的兼容性。

测试用例应该具体明确，包括预期结果和实际结果的比对，以便发现问题和进行修复。同时，测试用例需要不断更新和完善，以适应不断变化的蓝牙技术和应用需求。

九、oa办公系统怎么编写测试的测试用例？

一、编写测试用例的原则测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。

测试用例编写应该遵循的原则： 1、测试用例要达到最大覆盖软件系统的功能点。测试工程师应该测试计划编写完成之后

十、测试用例是测试人员还是测试经理编写的？

现在公司一般情况下都是测试人员写的。

不过记得大学时候学软件测试这门课里好像有分专门写案例的和单纯执行测试案例的人，不过现在只执行不写用例的测试人员几乎不存在吧，要么是新手。

顶一下

(0)

踩一下

(0)

相关评论

我要评论: 用户名: 验证码:

上一篇：返回栏目

下一篇：everything如何设置http访问特定路径？