前言
作为一名测试新手，对于如何写测试用例很头疼，接触不到需求，只能站在用户的角度去测试，但是这样会导致无法对APP进行全方位的测试，这时候就需要测试用例了，但是不知道怎么写，求助！还有一个问题就是测试中发现的bug如何追踪？和开发人员的接触基本都是面对面的交流，没有很好的标准。
带着问题去学习是最有效的学习方法。
目录
1.什么是测试用例
2.为什么要写测试用例？
3.如何编写测试用例
因此在介绍如何编写测试用例之前，我们先来看一个软件系统登录功能的测试（如下图所示）：
针对这个登录页面做一个测试用例，测试的时候会考虑哪些方面？
对一个看似简单的页面功能进行全面测试，能设计多少个测试用例呢？少于10个？20个？......
所以在给出上述答案之前，我们先让大家熟悉一下什么是测试用例，测试用例是做什么的。然后根据上面的例子，我们来讨论一下如何编写测试用例。
以下为本文目录截图：
1.什么是测试用例
测试用例：为特定目的（证明软件中存在某个问题）而设计的由测试输入、执行条件、预期结果等组成的一组文档
1. 测试用例只是指导如何进行测试的文档，这个文档主要记录被测软件是否满足要求。
2.测试用例展现形式常见有两种，可以以模板的形式展示
1）一种是直接通过Excel书写
——大多数项目都需要这样设计和编写
2）一种是直接通过xmind来整理测试点
——当时间紧迫，项目没有强制要求时，可以以设计测试点的形式来写
——对于业务流程测试，也可以组织成测试点进行测试
3.设计实现人员：测试工程师
4. 用例模板：描述用例的核心内容，一般项目都有自己的用例设计模板，常见的测试用例模板如下：
为了支持新朋友们，我也分享了多年来精心整理的数百个学习资料和讲解视频，对初学者来说绝对有用，我都放在下面了，废话不多说，文章最后都可以免费领取哦~
2.为什么要写测试用例？
为什么要写测试用例？当产品出现问题的时候，第一负责人会想到为什么测试没检测出来？
产品有问题，你为什么不测试一下呢？
当然，编写测试用例除了避免“甩锅、承包”之外，更重要的作用还有：
3.如何编写测试用例
既然编写测试用例如此重要，那么如何才能更好地编写测试用例呢？我个人认为需要满足以下几点： - 常规思维，将自己置于用户的立场上（例如：实际用户是不是这样使用的，会不会遇到异常情况？） - 有测试理论和方法的支撑（例如：根据需求设计测试用例时，可以用哪些常见的测试用例设计方法？） - 对产品的熟悉和经验的积累（例如：曾经有过同类项目经验，在某一方面出现过问题，当时是如何处理？） 上述设计用例的过程，有一个前提条件，那就是对测试的耐心和恒心，加上日常有意识的思维训练，才能写出全面的用例。
1. 传统思维
回到开头的问题，一个基本的登录页面，你能按照常规思维想到下面截图所示的测试点吗？其实这些测试点都是从用户视角出发，结合需求进行详细设计的过程中得出的。实际测试中是不是只有这些测试点呢？
2.学习积累
相信大部分测试工程师都能想到上述这些基本的测试点。但在实际工作中，面对的项目不同，设计测试用例的粒度也有不同的要求。如果更深层次的考虑上述登录模块会怎么样？这时候就需要我们对产品比较熟悉，并且有测试经验了。这些点的设计都是通过不断的学习，熟悉项目，测试积累而得到的。
3.理论支持
有了常规思维和经验积累，还需要理论支撑。测试用例毕竟是人设计的，这个过程中难免有疏漏，如何避免？其实需要测试理论的支撑。个人认为对设计用例的深入思考，无非就是以下两个方面：
1）测试用例设计方法
测试理论的一个关键部分就是将需求拆分成具体的测试点，然后基于用例设计方法进行具体的设计。需求拆分的关键是熟悉需求，根据用户使用场景和个人测试经验（如果有的话），将文档中现有的描述拆分成可以直接使用用例设计方法设计的测试点。这样，简洁的文本描述就可以直接转换成Excel测试用例。这个过程可以大致理解为一个拆分和细化的过程，直到可以直接编写用例来验证特定的功能点。
其中，较为著名的设计用例方法有：
- 观察
- 等价类、边界值
- 决策表、因果图
- 流程图、情景方法
- 错误猜测方法等
2）测试设计思路的开发
如果现有的描述信息已经按照需求拆分好了，那能保证测试没有问题吗？
其实，如果需要在上述基础上拓展综合测试，也需要利用软件质量模型的特点，从这些特点出发，给测试用例设计者更多的思考空间，这样的设计才更加全面、可靠。
常见软件质量模型特征描述：
- 功能性：它有任何功能吗？是否易于使用？
- 性能效率：对应系统的资源消耗和响应时间
- 易于使用：易于理解、学习和使用
- 兼容性：兼容不同的软件和硬件平台
- 可靠性：不易出现问题，且一旦出现问题也易于恢复
- 安全性：用户安全（外部生命安全、内部信息安全等）
- 便携性：它能否在不同的环境条件下顺利运行？
- 可维护性：后期维修、维护是否方便、快捷？
因此，针对上述登录功能，遵循上述质量模型的指导，我们得到以下几个测试点：
4. 最后的想法
现在回过头来看，你还觉得一直运行良好的登录功能有几十个测试用例吗？显然没那么简单，需要根据对需求的熟悉程度进行拆分细化，结合常规思维、经验积累、理论支撑，最终转化为需要验证的测试结果。
第一步是熟悉需求，然后在此基础上进行测试点的拆分和细化。这个过程如果针对的是比较复杂的功能点，就要用到测试用例设计的方法。对于页面级别的测试点，最常用的就是等价类和边界值。
光是熟悉需求是不够的，还需要结合经验的积累，根据质量模型的特点，对功能点的设计进行综合考虑，看看是否有遗漏，是否有项目的特殊要求。
用例的设计并不是一朝一夕就能做到的，好的用例需要不断的实践，反复的修改和评审才能写出优秀的用例。
今天的分享就到此结束，大家有什么问题可以在评论区提问，如果我的文章对你有帮助的话，可以点赞支持一下哦。