前言：
测试一个新功能时，最重要的一个步骤就是编写测试用例，测试用例写好了，那么后面的测试工作基本就非常顺利了，那么怎样提高测试用例的质量呢？
【文章末尾给大家准备了大量的福利】
充分理解需求
拿到测试需求后，不应该拿到什么就是什么，需求上怎么写就怎么做，要有自己的见解。
举个例子来说，某个网站年终大促，要搞个优惠活动，有两种优惠方式：
- 第一种是店铺自己发的优惠，两件8折、3件7折；
- 另一种是平台提供的优惠，满100-10、200-30。
测试人员A拿到这个需求后，发现非常简单，迅速的就将测试用例编写完了，如图
乍一看是没有问题的，所有情况也都考虑到了，但是仔细研究的话会发现，其中漏掉了好多场景。
测试人员B拿到这个需求后，发现有好多不明确的地方。
比如说，两种优惠同时满足的时候，优先使用哪种优惠，优惠可不可以叠加使用，店铺发放的优惠只针对当前店铺吗，一个账号每种优惠是不是只能使用一次等等。
带着这些问题，测试人员B就会与需求人员去沟通，等需求了解透彻之后，开始编写测试用例，对上面的补充用例如下：
所以说提高测试用例质量的一条重要途径就是挖掘潜在需求，只有将需求了解透彻之后，才能提高测试用例的覆盖率。
参照其他同类型网站和功能
如果一个新功能，你之前没有接触和了解过，完全没有头绪的话，不妨借鉴一下同类型的网站上的类似需求，通过实践来帮助自己理解这个需求。
虚心求教
编写完测试用例后，让老员工来指导一下，是否有需要改进的地方，毕竟老员工的工作经验丰富，对容易出现bug的地方比较敏感，看有没有漏掉的地方。
而且老员工一般对项目都已经非常熟悉了，通过跟他们沟通之后，可能自己也会发现一些不容易想到的点。
站在使用者角度看问题
功能的最终使用者是客户，我们要站在客户的角度来测试。
比如说我们做了一个搜索产品的功能，作为测试人员我们会考虑：支持模糊搜索，可以搜索产品名、产品编码，可以按照产品颜色搜索等等。
那么如果站在用户的角度，他们最关心的是什么呢？是搜索的速度、使用起来方便等等。
所以站在客户的角度看问题能让我们收获更高的满意度。
测试用例步骤清晰
测试用例步骤一定要清晰，让不懂测试的人看了也能执行。
我们在写测试用例时，一定要将所有信息都描述清楚。
比如说上面的最后一条用例，执行这条用例的条件是：该用户已经参与过优惠活动。这个一定要写清楚，不然容易造成测试用例错误的执行结果。
那么，一份高质量测试用例的形成，会包含哪些因素和步骤呢？
测试用例是测试设计的一个产出物，它直接体现测试设计的思想，一份漂亮的测试用例不仅仅是设计思路的优秀体现，更是便于流转和执行，具有可读性、传递性。
首先，我们要一份测试用例例模板，模板可以将测试用例的结构形式固定化、标准化，对编写者启引导作用，保证一份测试用例数据完整。
其次，测试用例的目标、可读、简洁是从各个属性所填的内容散发出来的。
1、用例编号
用例编号就是测试用例文档中一个代号，需全局唯一，我们可以通过代号快速找到测试用例。
用例编号的书写，建议是项目名_模块名_001，我们可以通过编号快速知道一个项目有多少用例，项目中一个模块有多少用例。
2、用例标题
目的:概述测试用例的主要内容，明确用例意图
在做用例评审时，通过浏览一个模块的用例标题，能快速判断有没有遗漏功能;通过浏览一个功能用例标题，能快速判断出有没有遗漏正常或异常case。
一个测试用例的好坏，一半体现在测试用例标题上。
一个好用例的标题，书写方式有三种：
一：一句完整的话(不超过30个汉字)
二：功能简报形式例：电影详情页-返回例：栏目-发布例：电影-添加
三：按条件/状态例：发起转码-无源媒体文件例：发起转码-有源媒体文件例：鉴权-已订购产品已过期例：鉴权-已订购产品未过期例：鉴权-未订购产品
3、预置条件
预置条件-测试用例能执行的前提条件。可以是到达某一状态，也可以是一些配置。
书写要求：一个简洁的结果。
用户已成功登陆自动审核的开关已关不需要写是怎么登陆的/如何将开关关掉的。
4、测试步骤
测试步骤是指如何执行用例，先做什么后做什么，是有顺序的概念在的。步骤和用例的目标需要是一致的，任意一个偏离目标整个case就是无意义的。
书写要求：可执行的操作，功能用例步骤不大于7，流程用例步骤随业务而定-这里不做限制。
(1) 采集电影[check1]
(2) 预处理电影[check2]
(3) 审核电影[check3]
(4) 发布电影[check4]
5、预期结果
预期结果是和测试步骤一一对应的，有几个检查点，就需要有几个结果。预期结果需要是可检查的，可从三个方面进行校验：
一：界面(结果会直接显示在界面上的)
二：数据库(有些数据只会存于数据库中)
三：磁盘(文件数据需具体到磁盘上看是否存在，数据是否正确)
书写要求：和测试步骤中check点一一对应，检查点>=1个
6、测试数据
测试数据：测试时使用到的数据。
书写要求：可用电影。
不用写到实际数据，在测试添加电影功能时，不需要写具体电影、导演、演员、宣传图片。
具体的数据-可以在数据准备时做好，如符合规格的图片(海报、图标、剧照)，符合码率的媒体文件(正片和预览片)。
最后，测试用例整体是有逻辑的-需要有用例设计的魂。
编写测试用例的两个途径
1)先有用例设计，从整个产品/项目出发，先确定测试范围、测试目标，再细化范围到具体对象->具体功能，确定设计用例技术和测试方法，再来编写用例。
2) 测试执行后-通过Bug反推 修改补充用例。
两者相结合才会产出一份高质量且有效的测试用例，理论->实践->理论过程。
附上编写测试用例常见问题
1、用例标题意图不明确2、用例中引用其他用例3、用例中包含过多的细节4、用例中出现笼统的词反复、多次确定反复的具体次数确定一个反复的范围长时间确定长时间的具体时间确定一个长时间的范围大量确定具体的数据量从需求/规格中中参照值5、用例中步骤不可执行6、用例中期望结果不可验证
最后就是用例的预期结果，一定要将所有涉及到的结果都列出来，不然执行测试的时候容易将要验证的点漏掉。
一份高质量的测试用例如何养成？
测试一个新功能时，最重要的一个步骤就是编写测试用例，测试用例写好了，那么后面的测试工作基本就非常顺利了，那么怎样提高测试用例的质量呢？
充分理解需求
拿到测试需求后，不应该拿到什么就是什么，需求上怎么写就怎么做，要有自己的见解。
举个例子来说，某个网站年终大促，要搞个优惠活动，有两种优惠方式：
- 第一种是店铺自己发的优惠，两件8折、3件7折；
- 另一种是平台提供的优惠，满100-10、200-30。
测试人员A拿到这个需求后，发现非常简单，迅速的就将测试用例编写完了，如图
乍一看是没有问题的，所有情况也都考虑到了，但是仔细研究的话会发现，其中漏掉了好多场景。
测试人员B拿到这个需求后，发现有好多不明确的地方。
比如说，两种优惠同时满足的时候，优先使用哪种优惠，优惠可不可以叠加使用，店铺发放的优惠只针对当前店铺吗，一个账号每种优惠是不是只能使用一次等等。
带着这些问题，测试人员B就会与需求人员去沟通，等需求了解透彻之后，开始编写测试用例，对上面的补充用例如下：
所以说提高测试用例质量的一条重要途径就是挖掘潜在需求，只有将需求了解透彻之后，才能提高测试用例的覆盖率。
参照其他同类型网站和功能
如果一个新功能，你之前没有接触和了解过，完全没有头绪的话，不妨借鉴一下同类型的网站上的类似需求，通过实践来帮助自己理解这个需求。
虚心求教
编写完测试用例后，让老员工来指导一下，是否有需要改进的地方，毕竟老员工的工作经验丰富，对容易出现bug的地方比较敏感，看有没有漏掉的地方。
而且老员工一般对项目都已经非常熟悉了，通过跟他们沟通之后，可能自己也会发现一些不容易想到的点。
站在使用者角度看问题
功能的最终使用者是客户，我们要站在客户的角度来测试。
比如说我们做了一个搜索产品的功能，作为测试人员我们会考虑：支持模糊搜索，可以搜索产品名、产品编码，可以按照产品颜色搜索等等。
那么如果站在用户的角度，他们最关心的是什么呢？是搜索的速度、使用起来方便等等。
所以站在客户的角度看问题能让我们收获更高的满意度。
测试用例步骤清晰
测试用例步骤一定要清晰，让不懂测试的人看了也能执行。
我们在写测试用例时，一定要将所有信息都描述清楚。
比如说上面的最后一条用例，执行这条用例的条件是：该用户已经参与过优惠活动。这个一定要写清楚，不然容易造成测试用例错误的执行结果。
那么，一份高质量测试用例的形成，会包含哪些因素和步骤呢？
测试用例是测试设计的一个产出物，它直接体现测试设计的思想，一份漂亮的测试用例不仅仅是设计思路的优秀体现，更是便于流转和执行，具有可读性、传递性。
首先，我们要一份测试用例例模板，模板可以将测试用例的结构形式固定化、标准化，对编写者启引导作用，保证一份测试用例数据完整。
其次，测试用例的目标、可读、简洁是从各个属性所填的内容散发出来的。
1、用例编号
用例编号就是测试用例文档中一个代号，需全局唯一，我们可以通过代号快速找到测试用例。
用例编号的书写，建议是项目名_模块名_001，我们可以通过编号快速知道一个项目有多少用例，项目中一个模块有多少用例。
2、用例标题
目的:概述测试用例的主要内容，明确用例意图
在做用例评审时，通过浏览一个模块的用例标题，能快速判断有没有遗漏功能;通过浏览一个功能用例标题，能快速判断出有没有遗漏正常或异常case。
一个测试用例的好坏，一半体现在测试用例标题上。
一个好用例的标题，书写方式有三种：
一：一句完整的话(不超过30个汉字)
二：功能简报形式例：电影详情页-返回例：栏目-发布例：电影-添加
三：按条件/状态例：发起转码-无源媒体文件例：发起转码-有源媒体文件例：鉴权-已订购产品已过期例：鉴权-已订购产品未过期例：鉴权-未订购产品
3、预置条件
预置条件-测试用例能执行的前提条件。可以是到达某一状态，也可以是一些配置。
书写要求：一个简洁的结果。
用户已成功登陆自动审核的开关已关不需要写是怎么登陆的/如何将开关关掉的。
4、测试步骤
测试步骤是指如何执行用例，先做什么后做什么，是有顺序的概念在的。步骤和用例的目标需要是一致的，任意一个偏离目标整个case就是无意义的。
书写要求：可执行的操作，功能用例步骤不大于7，流程用例步骤随业务而定-这里不做限制。
(1) 采集电影[check1]
(2) 预处理电影[check2]
(3) 审核电影[check3]
(4) 发布电影[check4]
5、预期结果
预期结果是和测试步骤一一对应的，有几个检查点，就需要有几个结果。预期结果需要是可检查的，可从三个方面进行校验：
一：界面(结果会直接显示在界面上的)
二：数据库(有些数据只会存于数据库中)
三：磁盘(文件数据需具体到磁盘上看是否存在，数据是否正确)
书写要求：和测试步骤中check点一一对应，检查点>=1个
6、测试数据
测试数据：测试时使用到的数据。
书写要求：可用电影。
不用写到实际数据，在测试添加电影功能时，不需要写具体电影、导演、演员、宣传图片。
具体的数据-可以在数据准备时做好，如符合规格的图片(海报、图标、剧照)，符合码率的媒体文件(正片和预览片)。
最后，测试用例整体是有逻辑的-需要有用例设计的魂。
编写测试用例的两个途径
1)先有用例设计，从整个产品/项目出发，先确定测试范围、测试目标，再细化范围到具体对象->具体功能，确定设计用例技术和测试方法，再来编写用例。
2) 测试执行后-通过Bug反推 修改补充用例。
两者相结合才会产出一份高质量且有效的测试用例，理论->实践->理论过程。
附上编写测试用例常见问题
1、用例标题意图不明确2、用例中引用其他用例3、用例中包含过多的细节4、用例中出现笼统的词反复、多次确定反复的具体次数确定一个反复的范围长时间确定长时间的具体时间确定一个长时间的范围大量确定具体的数据量从需求/规格中中参照值5、用例中步骤不可执行6、用例中期望结果不可验证
最后就是用例的预期结果，一定要将所有涉及到的结果都列出来，不然执行测试的时候容易将要验证的点漏掉。
重点：学习资料学习当然离不开资料，这里当然也给你们准备了600G的学习资料
需要的私我关键字【000】免费获取哦 注意关键字是：000
全套软件测试自动化测试教学视频
300G教程资料下载【视频教程+PPT+项目源码】
全套软件测试自动化测试大厂面经
python自动化测试++全套模板+性能测试
听说关注我并三连的铁汁都已经升职加薪暴富了哦！！！！