如何写出漂亮的测试用例
2022-09-30 15:34:56 3 举报
AI智能生成
登录查看完整内容
如何写出漂亮的测试用例,区分测试点和测试用例的不同?测试用例的评估?测试用例执行情况和产品质量关系?
作者其他创作
大纲/内容
问题1:这些测试点在内容上有重复,存在冗余。问题2: 一些测试点的测试输入不明确,不知道测试时要测试哪些。问题3:总是在搭相似的环境,做类似的操作。问题4:测试点描述得太粗,不知道是不是测对了。
测试点是测试者在测试时需要关注的地方。虽然我们在分析测试点时,会使用各种测试方法,但这些方法在思路和操作上都是不同的,一些方法得到的测试点要细一些、具体 一些,一些方法得到的测试点粗一些、泛一些是非常正常的。另外,谁也不能保证这些测 试点之间不会重复或是相互包含。如果我们的测试就是按照这样一份粗细不一、深浅不明、 关系不清的说明书来进行的,又怎么不会陷入既冗余又不足的困境中呢?而测试用例是在测试点“加工”的基础上得到的。首先把测试点“去重”(去掉重复的 内容)、“合并”(把太细的测试点合并起来)、“细化”(把太泛的测试点说清楚、说具体),然 后再确定各个测试点的测试条件、测试数据和输出结果。如果说测试点还只是一些散乱的测试思路的集合,那么测试用例就是一份真正能够指导测试的测试说明书。
测试点不等于测试用例,这是我们首先需要认识到的
扩展
补充测试用例
设计基础测试用例
建模
测试用例设计流程
编号 测试分类 用例标题 用例等级 前置条件 测试数据 操作步骤 期望结果 执行结果 备注
一般包含以下几项(可根据公司需要做裁剪或添加):
首先确定一个标准的模板
示例图
只有当测试用例标题是一个完整的句子时,读者才能完整地了解这个测试用例的意图。
测试用例标题要是一个完整易懂的句子
如果你有对比就会发现,使用条件来作为测试用例标题,和使用参数相比,前者更能 突出设计这个测试用例的目标,也易于读者理解测试用例的设计意图,也更易于维护。可见,在描述测试用例标题时,更适合用条件,而不是参数。参数更适合在测试用例模板中的测试数据部分体现,不要把它们罗列在测试用例标题中。
用条件而不是参数来描述测试用例标题
我们在写测试用例的时候,应该对涉及的每个参数给出确定的值。
如果一个用例中包含有多个参数,用例中应该是每个参数的取值
引用测试用例会给后期用例的修改、维护和移植带来麻烦。我们会在测试用例中引用另外一个测试用例,在很大程度上是因为用例在执行中存在 先后关系,即测试用例2一定会在测试用例1之后执行。这时我们可以考虑这样来编写测 试用例:把测试用例1和测试用例2合并成一个大的测试用例。可以把测试用例1的主要内容放到测试用例2的预置条件中。
不要在测试用例中引用别的测试用例
用例执行者应该是专业人士,测试用例不必写得面面俱到。
避免测试用例中包含过多的用户接口细节
明确测试步骤和预期结果的对应关系
例如一明确次数:1 .测试用例中需要反复、多次操作的描述方法问题1:反复执行接口 up/down的操作解决方法1:在测试用例中确定反复的具体次数。修改1:反复执行接口 up/down操作100次。解决方法2:也可以为测试用例确定一个反复的范围。修改2:反复执行接口 up/down操作至少100次。解决方法3:如果反复多次执行某个操作多次后,会出现某种特定的效果(例如内存会 升高到某个特别值),但是需要反复执行多少次这样的操作却并不确定,可以这样描述。修改3:反复执行接口叩/down操作,直至系统内存值达到最大值的45%O
例如二明确时间:问题2:系统长时间转发HTTP业务。解决方法1:在测试用例中确定长时间的测试时长。修改1:系统持续转发HTTP业务24小时。解决方法2:也可以为测试用例确定一个长时间的测试时间范围。修改2:系统持续转发HTTP业务至少24小时。
示例三明确数量:3.测试用例中需要大量操作的描述方法问题3:大量用户同时连接服务器。解决方法1:需要确定大量的具体数量,如1000、2000修改1: 2000个用户同时连接服务器。解决方法2:可以以产品规格作为大量的参照值,如满规格、系统支持数的50%。修改2:满规格用户同时连接服务器。
我们在描述测试步骤时,需要尽量避免那些笼统的表述方式,如“反复”“长时间” “大 量”等。因为这样描述,不同的测试执行者的理解会有所不同。比如“反复”,有人会认为 执行两次就是反复了,有人可能会认为要执行至少10次,这样就会造成测试执行上的差 异,很可能会达不到测试的效果。
避免在测试步骤中使用笼统的词
写出漂亮的测试用例
测试过程评估分析的对象是测试用例、测试方法和测试投入。(这里主要重点是说测试用例评估,测试方法和投入不做重点说明)为什么进行产品质量评估还需要对测试过程进行分析呢?试想对一个产品测试来说:1.有充分完备的测试用例和没有测试用例进行随机测试相比,哪一种测试的结果更 可靠?2.使用了多种测试方法与测试方法单一相比,哪一种测试结果更有助于进行产品质量评估?3.有经验的测试人员、充足的测试投入与没有经验的测试人员、测试投入不足相比, 哪种测试情况更有利于测试目标的实现呢?可见,对测试过程进行评估,对产品质量评估而言十分重要。不仅如此,如果我们能够在测试之前就对测试过程进行计划,还能帮助我们更好地进行测试,更好地完成产品的测试目标。
试用例因为产品开发(一般是指缺陷)、测试(如测试环境不具备) 等原因,无法被执行的测试用例。
1.测试阻塞
可以执行,但是因为进度、人力或其他原因等还没有被执行的测试用例。
2.未执行
1.测试用例执行率。
首次执行通过率
测试用例累积执行通过率可以帮助我们评估产品在发布时的质量。一般说来,测试用例累积执行通过率越高,说明当前的版本质量可能已经达到了基本要求,可以考虑发布。
累积通过率
2.测试用例执行通过率。
我们希望“通过测试用例发现的缺陷”和“发散测试,也就是非测试用例发现的缺陷” 的比值能够在一个合理的范围内。比值过高或者过低都有可能存在某方面问题,不在这里详细说明。
3.测试用例和非测试用例发现缺陷比。
我们可以通过如下3个指标来对“测试用例”进行评估:
测试用例评估
这个详情见本部门《项目质量分析和缺陷报告_V4.0模板》
按照测试用例的等级P1~P3
测试用例的模块
测试用例的类型
测试用例的选择
测试团队的测试执行顺序是否和测试策略相符
需要特别注意的是,按照优先级来执行测试用例,不是说我们一开始就只执行高优先 级的测试用例,而不去执行中、低优先级的测试用例。正确的图8-11我们需要在测试刚开始的时候,对每个功能都执行一些基础性的测试用例,以确认这些功能基本可用,不会阻塞后续的测试。这就是在8-11趋势图中,在测试刚刚开始的时候(第1周)都有测试进度,且在进度上没有明显的差异的原因
图8.12所示的测试执行趋势,并不 是我们想要的。
配置测试→功能测试→功能交互→满规格测试
跟踪测试执行的目的有3个(我们这里重点只说测试用例相关的):1.确保测试团队是按照测试策略来执行测试的。2.实时关注缺陷,通过缺陷分析来确认测试策略是否合适,是否需要调整。3.关注项目中的实时风险,基于风险来调整测试策略。
跟踪测试用例执行情况
们希望测试人员在测试过程中,在执行测试用例的时候 能够进行一些“发散测试”,但是我们也希望通过测试用例发现的缺陷和非测试用例发现的 缺陷的比值能够在一个合理的范围内。比值过高或过低都不是我们希望看到的结果,如果出现偏差,就需要对这部分缺陷进行分析。
非测试用例发现缺陷的原因分析
其它
测试用例
0 条评论
回复 删除
下一页