前言
作为一个测试新人，刚开始接触测试，对于怎么写测试用例很头疼，无法接触需求，只能根据站在用户的角度去做测试，但是这样情况会导致不能全方位的测试APP，这种情况就需要一份测试用例了，但是不会写，求指教！还有就是测试出来的bug该如何追踪？与开发的接触基本上面对面的交流，没有很好的一个规范
?因此，在介绍如何编写测试用例之前，先看一个软件系统登录功能的测试（如下截图所示）：
?
要做这个登录页面的测试用例，你会从哪些方面思考进行测试呢？
看似简单的页面功能能够设计多少条测试用例完成较全面的测试呢？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.可移植性测试：
主要关注水杯放置环境等
6.1 将水杯放在常温环境中，使用是否正常
6.2 将水杯放在零下的环境中，使用是否正常
6.3 将水杯放在高于正常温度的环境中，使用是否正常
你看，这道面试题是不是就轻松解决了？
四、写在最后
此时的你再回过头来看看，还会认为登录这个百试不爽的功能就设计十几条甚至几十条测试用例了吗？显然不是那么简单，需要在熟悉需求基础上，进行拆分细化，将常规的思考、经验的积累、理论的支撑结合起来使用，最终才能转化为测试待验证的结果。
熟悉需求上第一步，在此基础上进行测试点的拆分细化，这个过程如果对于复杂一点的功能点，需要借助于测试用例的设计方法，对于页面级的测试点应用最多的不外乎是等价类、边界值。
仅仅熟悉了需要，还需要结合经验的积累，从质量模型的特性出发，进行全面的思考功能点的设计，是否出现遗漏的，是否有项目特殊要求的。
最后，用例的设计不是一蹴而就的事情，好的用例也是需要不断的练习，反复的修改评审，才能编写出卓越的用例。
下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！
最后： 可以在公众号：程序员小濠?！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！喜欢软件测试的小伙伴们，可以加入我们的测试技术交流扣扣群：779450660里面有各种软件测试资源和技术讨论）