ps:个人学习笔记，非教学博文（本人菜鸡一个，没教学这功力TOT）

什么是测试用例？

 测试用例就是我们在测试时使用的文档，是测试工作的核心，是一组测试在对照时输入输出的标准，是软件需求的具体对照。
通过测试用例和需求的一 一对照我们可以确定我们的测试是否能完全的覆盖需求，是否有遗漏的地方。

测试用例有什么作用

1、检测软件是否满足客户需求
我们可以方便快捷的知道每一条测试用例对应的需求是什么，如果每一条测试用例通过了那么需求也就完全通过了。
2、体现一个测试人员的工作量
比如你一天可以执行50条测试用例，上级问你200条用例执行要多久？（答少了赶进度要加班，答多了会觉得你摸鱼，你懂我意思吧 (≖ ‿ ≖)✧ ）
3、展现测试用例的设计思路
测试用例是让我们更好的去设计规划我们的测试过程，在我们还对系统、对测试工作不太熟练的情况下，测试用例让我们能够化繁为简，有章可依的有效完成测试。
当然，再悲观一点，如果我们的项目发生了意外，上线出了问题，我们也可以通过追溯测试用例来发现自己的问题，补全自己的测试盲区。

测试用例包含哪些内容？

用例编号、用例名称、测试背景、前置条件、优先级、重要级、版本号、测试数据、测试步骤、预期结果、实际结果、编写人、执行人、备注等等…(根据公司文档规范来、没的话尽量多打磨一下文档,文档质量相当重要，好处多多，下图是个非常粗糙的例子)

相当于一个坐标轴，一条用例看下来力求开发、产品、需求、老板都能看懂，减少不必要沟通时间。
一般公司都有管理工具用照着工具来也行。

测试用例编写流程

1、需求分析

什么是需求

需求就是客户需要的东西和对那个东西的要求。
一般通过以下三个方面入手：
1、业务需求----满足业务
2、用户需求----满足用户习惯。
3、功能需求----满足功能要求。
测试：主要对业务需求进行分析，怎样验证软件是否满足客户的需求。（更深层次需求分析交给产品经理 OVO ）
测试是万金油，各方面知道得越多越好 (╯#-_-)╯~~~~~~~~~~~~~~~~~╧═╧
PS: 没需求？需求模糊？参考同类产品、整理已有需求逐一和产品经理确认（还是参考同类型产品）
我会告诉你博文内容也是我参考某些教学课程整理的？ ╭(●｀∀´●)╯

2、提取测试点

什么是测试点

测试点就是通过需求分析后得出的具体测试内容

测试点对用例设计的好处

快速：根据测试点快速的编写用例。
覆盖：完整覆盖需求。
ps:有个需求覆盖率，用例覆盖率概念，可以度量测试完整性。
（问：进度怎么样？答：完成90%刚调试好测试机 (￣ε(#￣) ）
方法：快速定位要用的测试方法。
细节：展现需求细节，加深对项目的理解。
ps:文档测试也是测试中相当重要的一环，啥？文档测什么？（脑补打撸啊撸时顺风好兄弟，逆风***。需求评审重要性）

3、测试用例编写方法

穷举法

列出测试所有可能逐条进行测试（数值有限的时候方便这么干）

等价类划分法&边界值

举个栗子：ヘ(￣ω￣ヘ)
测试一个2位数以内加法计算器。
测试需求：测试两个参数的值相加后的结果是否正确
条件：输入值在-99到99之间，大于或小于这个区间应被拒绝，并显示错误信息
这里我们要是用穷举法：
第一个参数-99到99（199个参数）+第二个参数-99到99（199个参数）
大概要执行39601次测试 ( ﹁ ﹁ )，执行起来会死人的对吧

于是！ 我们！ 用等价类划分法！
就是根据这些参数给它们分个类，然后每一类测一次！！
初步我们可以分为3类（3个等价类）比参数条件小的（1）、在参数条件内的（2）、比参数条件大（3）
然后我们根据这3个等价类列个表：有效等价类（2）、无效等价类（1）、无效等价类（3）
当然要谨慎！还要进一步细化！细分化有效等价类（2）为：
第一个参数是正数或负数。
第二个参数为正数或负数
最后归纳总结：我们至少要测试5类数据类型
1、正数+正数
2、负数+负数
3、负数+正数
4、小于条件参数
5、大于条件参数
这样我们就只用测试5条用例就可以基本达到测试目的！(`･ω･´)
PS—（还有细化空间比如我在无效里填ABC、填汉字、填空的等等）
说得比较复杂，实际就是个分类然后一类里面测一下。
要注意的问题
1、不但要考虑有效等价类，也要考虑无效等价类
2、仔细划分、审查划分
3、过于粗略可能会漏掉软件缺陷（客户会做一些奇奇怪怪的骚操作！）
4、要组织评审（集思广益(≖ ‿ ≖)✧）

边界值分析法&等价类

然后上面计算器测试评审通过，测试通过，上线了，然后出问题了 (┙>∧<)┙へ┻┻
客户在有效等价类范围里使用出现报错！
边界值分析法
是一种补充等价类划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。
实践证明：在设计测试用例时，对边界附近的处理必须有足够的重视，为检验边检附近的处理专门设计测试用例，常常取得良好的测试效果。
边界值设计的原则
如果输入条件规定了取值范围，应以该范围的边界内及刚刚超过范围的边界外的值作为测试用例
如以a和b为边界，测试用例应当包含a和b及略大于a和略小于b的值


好的，等价类+边界值情侣组合编写完毕，我们介绍下一对 ξ (ˉ▽￣～)

因果图&判定表

因果图法就是从程序规格说明书的描述中找出因（输入条件）和果（输出结果或程序状态的改变）
将因果图转换为判定表，为决策表中的每一列设计一个测试用例
这种方法考虑了输入情况的各种组合以及各个输入情况之间的相互制约关系

判定表&因果图

判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的工具。
在程序设计发展初，判定表就已被当做编写程序的辅助工具。它可以把复杂的逻辑关系和多种条件组合的情况表达的既具体又明确。

场景法

猜错法

就是靠经验、直觉加运气猜。
不推荐，玄不救非.╮(﹀_﹀”)╭
原理：依靠直觉去猜测哪些地方出现问题，依靠丰富的经验去分析哪些地方容易被开发忽略，快速得到测试的结果。
杀虫剂怪事：长期共事下来开发可能非常了解你的测试习惯，然后编程时着重考虑你会测试的方面。然后你就很难发现问题。就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。（所以咱们要么知（姿）识（势）多花样多各种测试方法策略，要么换其他测试轮岗，避免思维定势，找不出缺陷让开发没加班收入 OVO）

测试用例评审

简单来说就是对用例进行检查
评审包括同行评审、小组评审、部门评审、三方评审

测试评审的意义

1、发现用例的不足
2、方便测试人员改进用例
3、达到在测试时提高测试质量的目的

测试评审的流程

测试用例的管理

如何管理用例

1、原始的excel管理
2、专业的管理系统

ALM（QC）：功能强大，搭建复杂，要收钱。（┬＿┬）
成本: ★★★★★
可扩展性:★★★★★
易用性：★★★★
功能： ★★★★★
禅道：具有专业版、免费版，专业版花钱可根据需求定制 ｡◕‿◕｡
成本: ★★★
可扩展性:★★★
易用性：★★★
功能： ★★★
Jira:
成本: ★★★★
可扩展性:★★★
易用性：★★
功能： ★★★

打完收工~求赞求指正求补充，谢谢！

最后

以上就是想人陪春天为你收集整理的如何写好测试用例什么是测试用例？测试用例有什么作用测试用例包含哪些内容？测试用例编写流程测试用例评审测试用例的管理的全部内容，希望文章能够帮你解决如何写好测试用例什么是测试用例？测试用例有什么作用测试用例包含哪些内容？测试用例编写流程测试用例评审测试用例的管理所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。