脚本宝典收集整理的这篇文章主要介绍了测试用例怎么写？，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

一.简介

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

假如开发了一个APP，就光从账户登录页面来看，怎么保证用户使用的时候没有BUG呢？就需要测试人员进行全方面的测试，确保在各种情况下不会出错

要做这个登录页面的测试用例，你会从哪些方面思考进行测试呢？看似简单的页面功能能够设计多少条测试用例完成较全面的测试呢？10条以内？20条？.......

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

测试用例表现形式常见的有两种，可以以模板形式展示 一种是通过Excel直接编写，大多数项目中都需要按照这种方式设计编写

一种是通过xmind直接整理测试点，适合时间紧迫，项目没有强制要求时，可以设计测试点的形式编写。对于业务流程类的测试，也可以整理为测试点进行测试。

二.为什么写测试用例

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

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

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

三.如何编写测试用例

既然写测试用例如此重要，那么如何更好的编写测试用例呢？个人认为需要满足如下几点：

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

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

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

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

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

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

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

• 观察法
• 等价类、边界值
• 判定表、因果图
• 流程图、场景法
• 错误推测法等

测试设计的思路开拓 倘若按照需求将已有的描述信息都已经拆分完毕了，是不是就可以确保测试没有问题了呢？

其实不然，在上述基础上如果还需要再拓展全面测试，还需要借助于软件质量模型的特性，从这些特性出发，给予测试用例设计者更多的思考空间。这样的设计就更加的全面可靠。

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

• 功能性：功能有没有，好不好用
• 性能效率：对应系统的资源耗费程度及响应时间
• 易用性：容易理解、学习、使用
• 兼容性：能够兼容不同的软硬件平台
• 可靠性：不易出问题，万一出问题容易恢复
• 安全性：对于用户的安全保障（外在的人生安全、内在的信息安全等）
• 可移植性：能否在不同环境条件下无故障运行
• 可维护性：对于后期的修复维护是否方便快捷

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

四.总结

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

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

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

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

脚本宝典总结

以上是脚本宝典为你收集整理的测试用例怎么写？全部内容，希望文章能够帮你解决测试用例怎么写？所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。