【tool】什么样的用例是好的测试用例

什么样的用例是好的用例?

  一.质量属性

  Quality Attributes

  1.正确性:确保测试标题描述部分的内容正确性。

  2.经济性:只为确定需要的目的设计相应的测试步骤

  3.适应性:既能适应短期需要,又能考虑长远需要。

  4.可追踪性:用例能追踪到一个具体的需求。

  5.自我清理性:单个用例不会影响整个测试环境,即用例执行完了可以恢复原有的测试环境。  软件测试 

 二.结构化和可测试性

  Structure and testability

  1.含有规范的测试标题和编号。

  2.含有一个确定的测试某一个特定需求的目的。

  3.含有关于测试方法的描述。

  4.指定条件信息-环境、数据、预置的条件测试、安全入口等。

  5.含有操作步骤和预期结果。

  6.陈述任何辅助证据,例如截图报告并确保这些东西妥善保存。

  7.确保测试环境的干净(即用例不会影响整个环境)。

  8.描述时使用主动语气结构。

  9.操作步骤不要超过15步

  10.确保单个用例测试执行时用时不超过20分钟。

  11.自动化脚本用例添加必要的注释,比如目的、输入和期望结果。

  12.如果可能,建议提供可选择性的预置条件测试。

  13.用例之间的先后顺序是否跟业务流程一致,即用例在业务流程中的彼此顺序关系是否合理。

  三.配置管理

  Configuration management

  1.采用命名和编号规范归档。

  2.保存为特定的格式,文件类型。

  3.用例版本是否与当前被测试软件版本一致(对应)。

  4.包含用例需要的相应测试对象,如特定数据库。

  5.存档阅读。

  6.存档时按角色控制访问方式

时间: 2024-09-15 10:23:35

【tool】什么样的用例是好的测试用例的相关文章

spring自动注入是单例还是多例?单例如何注入多例?

单例多例需要搞明白这些问题:      1. 什么是单例多例:      2. 如何产生单例多例:      3. 为什么要用单例多例      4. 什么时候用单例,什么时候用多例:   1. 什么是单例.多例: 所谓单例就是所有的请求都用一个对象来处理,比如我们常用的service和dao层的对象通常都是单例的,而多例则指每个请求用一个新的对象来处理,比如action; 单例模式和多例模式说明: 1. 单例模式和多例模式属于对象模式. 2. 单例模式的对象在整个系统中只有一份,多例模式可以有

用例建模指南

用例建模指南 用例(Use Case)是一种描述系统需求的方法,使用用例的方法来描述系统需求的过程就是用例建模.用例方法最早是由Iva Jackboson博士提出的,后来被综合到UML规范之中,成为一种标准化的需求表述体系.用例的使用在RUP中被推崇备至,整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的,各种类型的开发活动包括项目管理.分析设计.测试.实现等都是以系统用例为主要输入工件,用例模型奠定了整个系统软件开发的基础. 1. 什么是用例? 在介始用例方法之

我的测试用例设计-02用例组成元素(用例模板)

可以这么说,每一家公司对于测试用例的设计规范.风格和用例的组成元素(填写的字段)都一样,但都大同小异,不同只是来源于公司对于某些实际需求来带来的差异. 一般基本的测试用例都具有以下基础的组成元素:用例编号.用例名称.用例优先级.用例步骤.前提条件.预期结果.用例设计者.创建时间. 接下来说说我结合我公司的实际应用,设计出来的用例模板(使用QC9.0工具): 简单说一下某些字段用途: 1.用例版本:用于测试用例的版本管理,也可以追溯用例来源于哪个需求版本. 2.用例状态:有效用例则为当前该功能可用

用例结构优化心得

在大型项目的测试中通常都伴随着大量的测试用例.如何优化用例以提高编写的效率,如何组织用例以提高执行的效率经常困扰着我们:因此总结了一些在编写用例时的心得. 1.用例框架的优化 一份好的用例设计需要有一个好的用例框架的支撑,因此用例结构优化的第一步就是优化用例框架. 一般我们的用例框架是先以测试方法作为基础,第一层是测试类型,考虑系统所需要测试的测试类型. 如果用例偏重于场景法的话,那么第二层是场景考虑,此时暂不要去思考如何实现:如果用例偏重于模块测试的话,那么第二层是你划分的各个模块:如果用例设

接口用例之好用例和坏用例

自动化测试的重要性显而易见,但自动化测试又无法解决所有问题,所以说完全依赖自动化是不可能的,但完全没有自动化是万万不能.在软件开发项目中,重度依赖人力进行持续回归是一件非常枯燥的重复工作.企业需要花费大量的时间和金钱来维持这样一支队伍以保证产品质量,而队伍中的同学在每天重复劳动的工作之下,也丝毫得不到成长,看不到方向. 尽管自动化测试不能解决所有问题,但是却拥有一个优势:“Once” Written, Run Anytime as Desired(一旦写好,即可随意重复执行).所以,自动化测试通

星云精准测试之用例魔方

精准测试从某个层面来讲,是赋予了测试用例真正的生命力,传统的测试用例仅仅是一些只能够依赖人去理解和分析的文本文件而已,在计算机和算法层面则没有存在意义和价值.下图是精准测试的整体架构图: 大家首先可能会比较好奇,"用例魔方"的概念是怎么来的?测试用例魔方是在精准测试的设计.开发和商业实践中自然产生的功能集合的一个统称.当我们把精准测试的和用例分析相关的功能画成架构图形表示的时候,它自然而然地看起来就像魔方,所谓"魔"则是精准测试核心算法所赋予的超能力.上图是星云精准

在敏捷测试中如何设计用例

1.测试用例的粒度测试用例可以写得很简单,也可以写得很复杂.最简单的测试用例是测试的纲要,仅仅指出要测试的内容,如探索性测试(Exploratory Testing)中的测试设计,仅会指出需要测试产品的哪些要素.需要达到的质量目标.需要使用的测试方法等.而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样,会指定输入的每项数据,期待的结果及检验的方法,具体到界面元素的操作步骤,指定测试的方法和工具等等.测试用例写得过于复杂或过于详细,会带来两个问题:一个是效率问题,一个是维护成本问题.另外,测

unittest---unittest多种加载用例方法

在做自动化测试我们对执行用例很有要求,因为每条用例可能就和上一条数据有关系,那么我想要批量执行一些用例呢?这个怎么去操作呢?unittest自带的功能可以帮助到我们,我们可以通过不同的场景运用不同的执行用例方法 TestCase 表示测试用例集合,我们可以直接进行执行这个集合来批量执行测试用例.直接通过unittest.main()进行执行 testsuite 加载测试套件suite进行实例化,通过addTest进行添加用例,最终将用例赋于给TextTestRunner()然后进行执行用例. 这

pytest文档31-allure标记用例级别severity

前言 我们在做功能测试的时候,执行完一轮测试用例,输出测试报告的时候,会有统计缺陷的数量和等级. 在做自动化测试的过程中,当你的测试用例越来越多的时候,如果执行一轮测试发现了几个测试不通过,我们也希望能快速统计出缺陷的等级. pytest结合allure框架可以对用例的等级做详细的划分. 用例等级 allure对用例的等级划分成五个等级 blocker 阻塞缺陷(功能未实现,无法下一步) critical 严重缺陷(功能点缺失) normal 一般缺陷(边界情况,格式错误) minor 次要缺陷