软件测试质量标准的指标,关于测试设计的基本原则和用例的质量标准

关于测试设计的基本原则和用例的质量标准

发表于:2009-11-12来源:作者:点击数:

关于测试设计的基本原则和用例的 质量 标准 软件测试 一、测试用例设计的基本原则 在测试用例设计时,除了需要遵守基本的测试用例编写规范外,还需要遵循些基本的原则。 ? 1尽量避免含糊的测试用例 ? 含糊的测试用例给 测试过程 带来网难,甚至会影响测试

关于测试设计的基本原则和用例的软件测试

一、测试用例设计的基本原则

在测试用例设计时,除了需要遵守基本的测试用例编写规范外,还需要遵循些基本的原则。

?

1尽量避免含糊的测试用例

?  含糊的测试用例给

例如,还用上断的例子来说明,对J:Ij户登录的页面校验测试进行测试用例鼓计:

??    ·  输入JF确的用户和密码,所有程序工作上【=常。  .  输入错误的用户和密码,程序_:|二作小正常,井弹出对话框。

??    在L而这样的测试用例设计,未能清楚地描述什么样是程序正常工作状态,什么样是程序不正常工作状态,这样含糊不清的测试用例必然会导致测试过程‘{1问题的遗漏。

2尽量将具有相类似功能的测试用例抽象并归类

一直强调软件测试过程是无法进行穷举测试的,因此,对相类似的测试用例的抽象过程显得尤为重要,一个好测试用倒应该足能代表组或者一系列的测试过程。

3尽量避免冗长和复杂的测试用例

这样做的主要目的是保证验证结果的惟一性。这也是和第一条原则相一致的,为的是在测试过程执行过程th确保测试用例的输出状态惟性,从而便于跟踪和管理a在一些很长和复杂的测试用例设讨过程中,需要将测试用例进行合理的分解,从而保证测试用例的准确性。在某些时候,rj测试用例包含很多不I司类型的输入或者输乩或彳}测试过程的逻辑复杂而币连续,此时需要对测试用例进行分解。张实际的测试用例设计中,需要将前述的基本原则和考虑凶素结台起来,遵循基本的测试用例编写规范。按照实际测试的

二、如何定义测试用例的质量标准

在定义测试用例的质量标准之前,先要了解设计测试用例的目的。测试用例是测试工作中最重要的元素或测试件(test ware)之一,是测试执行的基础。测试用例不仅能有效地帮助实施后继的

达到已定义的或所要求的测试覆盖率,如大于98%。

使测试执行的效率达到最好的水平,如最有效的途径并使60%以上的测试用例被

但是,按照这样的标准,很难在测试执行前或执行过程中评估测试用例的质量,而不得不在执行完这些测试用例之后进行

根据多年的实践经验,测试用例的标准不能局限于一个层次,因为测试用例设计类似于软件设计,软件设计有架构设计(结构设计/概要设计)和详细设计,所以对于测试用例的质量标准,也应分为两个层次来考虑:

(1)高层次——满足某一个测试目标或测试任务来整体看测试用例,衡量一组测试用例的结构、设计思路和覆盖率等指标。

(2)低层次——从单个测试用例看,衡量其描述的规范性、可理解性和可维护性等指标。

朱少民-软件测试和质量专栏 版权所有

1.高层次(high-level)标准

高层次标准是从满足某一个特定的测试目标出发来进行定义,分析一组测试用例的设计思路、设计方法和策略,包括测试用例的层次、结构等。从高层次看,测试用例设计的关键点是:始终从客户需求的角度(出发)想,始终围绕测试的覆盖率和执行效率不断思考,最终通过有效的技术方法完成测试用例的设计。

对于一整套的测试用例组(集合),可定义如下的质量标准:

(1) 测试用例的目标清楚,并能满足软件质量的各个方面,包括

(2) 设计思路正确、清晰。例如,通过序列图、状态图、工作流程图、数据流程图等来描述待测试的功能特性或非功能特性。

(3) 在组织和分类上,测试用例层次清楚、结构合理。测试用例的层次与产品特性的结构/层次相一致,或者与测试的目标/子目标的分类/层次相一致,并具有合理的优先级或执行顺序。

(4) 测试用例覆盖所有测试点、覆盖所有已知的用户使用场景(User scenario),也就是说每个测试点都有相应数量的测试用例来覆盖,而且将各种用户使用场景通过矩阵或因果图等方式列出来,找到相对应的测试用例。

(5) 测试手段的区别对待。在设计测试用例时,就要全面考量测试的手段,哪些方面可以通过工具测试,哪些方面不得不用

(6) 有充分的负面测试。作为测试用例,不仅要测试正确的输入和操作,还要测试各种各样的例外情况,如边界条件、不正确的操作、错误的数据输入等。

(7) 没有重复、冗余的测试用例,满足相应的行业标准等。

2.低层次(low-level) 标准

低层次标准是考察单个测试用例是否满足测试的需求,是否能被更有效地执行。测试用例设计的结果就是交付测试用例,使测试用例被执行,所以除了覆盖率,执行的效率也是测试用例的一个重要属性。测试用例越清楚,越容易被理解和执行。执行效率越高就说明测试用例越好,如果测试用例能被机器(computer)执行,当然执行效率得到体现。

对于具体的某个测试用例,不妨可定义如下的质量标准:

(1) 测试用例的出发点是发现缺陷,即单个测试用例在“暴露缺陷”上具有较高的可能性。

(2) 测试用例的单一性。一个测试用例面向一个测试点,不要将许多测试点揉在一起。例如,通过一个测试用例发现1~2个缺陷,而不能发现5~10个缺陷甚至更多的缺陷。

(3) 符合测试用例设计规范或测试用例模板,见下面附表所示。

(4) 描述清楚,包括特定的场合、特定的对象和特定的术语,没有含糊的概念和一般性的描述。例如,测试用例名称为“登录功能使用正常”,就是一个描述不清楚的例子,而这样的描述“登录功能中用户名大小写不敏感性验证”、“登录功能中用户名唯一性验证”和“用户帐号被锁定后再进行登录操作”等就比较好。

(5) 操作步骤的准确性,按照步骤的操作得到唯一的测试结果。

(6) 操作步骤的简单性。操作步骤不应该太复杂,过于复杂的操作步骤意味着测试用例需要被分解为多个测试用例或者分解为多个环节进行验证。

(7) 所期望的测试结果是可验证的,即能迅速、明确地判断测试的实际结果是否与所期望的结果相同或相匹配。例如,在测试用例中描述期望结果为“登录成功”,这实际是不可验证的。要使这个期望结果具有可验证性,我们就应该这样描述所期望的结果——“‘退出(log out)’按钮出现”。

(8)

(9) 前提条件、依赖性被完全识别出来。

这样,测试用例具有很好的可理解性和可维护性,可以提高测试执行的效率。并能保证不同的人员执行相同的用例能获得统一的结果。步骤的准确性和期望结果的可验证性,非常有助于测试执行的自动化实现。也只有实现了测试执行的自动化,测试执行的效率才是最高的,而且测试人员才有更多的时间去思考、去设计更优秀的测试用例,进入良性循环,相互促进,不断地提升测试的质量和效率。

附表 测试用例模板

MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">字段名称

类型

注释

标志符

整型

唯一标识该测试用例的值,自动生成

测试项

字符型

测试的对象,可以从软件配置库中选择

测试目标

字符型

从固定列表中选择一个

测试环境要求

字符型

可从列表中选择,如果没有,则直接输入新增内容

前提

字符型

事先设定、条件限制,如已登录、某个选项已选上

输入数据

字符型

输入要求说明、或数据列举

操作步骤

字符型

按1., 2., …操作步骤的顺序,准确详细地描述。

期望输出

字符型

所属模块

整型

模块标识符。

优先级

整型

1,2,3(1-优先级最高)

层次

整型

0,1,2,3  ( 0 –最高层)

关联的测试用例

整型

上层(父)用例的标识符。

执行时间

实型

分钟

自动化标识

布尔型

T,F

关联的缺陷

枚举型

缺陷标识符列表。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目录 一 软件测试 从零开始 5 1.1 引言 5 1.2 测试准备工作 5 1.2.1 向有经验的测试人员学习 5 1.2.2 阅读软件测试的相关书籍 6 1.2.3 走读缺陷跟踪库中的问题报告单 6 1.2.4 走读相关产品的历史测试用例 6 1.2.5 学习产品相关的业务知识 6 1.3 识别测试需求 7 1.3.1 主动获取需求 7 1.3.2 确认需求的优先级 8 1.3.3 加入开发小组的邮件群组 8 1.3.4 与开发人员为邻 8 1.4 测试用例设计 8 1.4.1 测试用例基本格式 8 1.4.2 重用同类型项目的测试用例 9 1.4.3 利用已有的软件 Checklist 9 1.4.4 加强测试用例的评审 10 1.4.5 定义测试用例的执行顺序 10 1.5 测试用例执行 10 1.5.1 搭建软件测试环境,执行测试用例 10 1.5.2 测试执行过程应注意的问题 11 1.5.3 及时更新测试用例 11 1.5.4 提交一份优秀的问题报告单 12 1.6 测试结果分析 12 1.7 总结 13 二 软件测试的常识 13 2.1 引言 13 2.2 软件测试常识 13 2.2.1 测试是不完全的(测试不完全) 13 2.2.2 测试具有免疫性(软件缺陷免疫性) 14 2.2.3 测试是 “ 泛型概念 ” (全程测试) 14 2.2.4 80-20 原则 14 2.2.5 为效益而测试 15 2.2.6 缺陷的必然性 15 2.2.7 软件测试必须有预期结果 15 2.2.8 软件测试的意义 - 事后分析 15 2.2.9 结论: 15 三 浅谈软件开发中的注意事项 16 3.1 项目设计 16 3.2 设计变化和需求变化 16 3.3 代码编写 17 3.3.1 源程序文件结构 17 3.3.2 界面设计风格的一致性 17 3.3.3 编辑风格 17 3.3.4 命名规范 18 3.4 BUG修补 18 3.5 开发人员的测试 18 四 软件测试的若干问题 19 4.1 前言 19 4.2 博弈的各方 19 4.3 测试的过程 20 4.4 测试所具备的素质 20 4.5 自动化测试 20 4.6 测试的误区 21 五 浅谈功能测试用例模板设计 21 5.1 Excel 模版 21 5.2 测试用例状态转换分析 23 六 如何提高软件质量 23 6.1 什么是质量 24 6.2 流程对质量的贡献 25 6.3 流程与技术 27 6.4 全面质量管理 28 6.5 关注测试 29 6.6 成功的铁三角 30 6.7 国际上流行的质量标准 30 6.8 如何起步 32 七 ISO和CMM,我们该选择谁 32 7.1 管理水平的适用性 33 7.2 复杂度的适用性 33 7.2.1何谓研发过程复杂度 34 7.2.2 何谓组织机构复杂度 34 7.3 量化管理的适用性上 35 7.4 结论 36 八 如何做好单元测试 36 8.1 前言 36 8.2 组织结构应该保证测试组参与单元测试 36 8.3 加强单元测试流程规范性 37 8.3.1 制订单元测试的过程定义 37 8.3.2 单元测试工作产品必须纳入配置管理 38 8.3.3 必须制订覆盖率指标和质量目标来指导和验收单元测试 38 8.3.4 加强详细设计文档评审 39 8.4 单元测试者技能的提高 39 8.4.1 加强对单元测试人员的技能培训 39 8.4.2 必须引入工具进行辅助 40 8.4.3 单元测试者加强对被测软件的全面了解 40 8.5 结尾 40 九 漫谈人机界面测试 41 9.1 一致性测试 41 9.2 信息反馈测试 42 9.3 界面简洁性测试 42 9.4 界面美观度测试 42 9.5 用户动作性测试 43 9.6 行业标准测试 43 9.7 小结 44 十 基于Web的系统测试方法 44 10.1 功能测试 45 10.1.1 链接测试 45 10.1.2 表单测试 45 10.1.3 Cookies测试 45 10.1.4 设计语言测试 45 10.1.5 数据库测试 46 10.2 性能测试 46 10.2.1 连接速度测试 46 10.2.2 负载测试 46 10.2.3 压力测试 46 10.3 可用性测试 47 10.3.1 导航测试 47 10.3.2 图形测试 47 10.3.3 内容测试 47 10.3.4 整体界面测试 47 10.4 客户端兼容性测试 48 10.4.1 平台测试 48 10.4.2 浏览器测试 48 10.5 安全性测试 48 10.6 总结 49 十一 为盈利而测试 49 11.1 引言 49 11.2 什么是软件测试 50 11.3 六个误区 50 11.3.1 误区一:忽视对正常输入的测试 50 11.3.2 误区二:忽视设计阶段的参与与评估 50 11.3.3 误区三:忽视测试计划与测试文档的建立及维护 51 11.3.4 误区四:忽视缺陷的分析,报告及跟踪 51 11.3.5 误区五:错误的测试目标及测试终止条件 51 11.3.6 误区六:不懂得合理调配使用测试人员的知识技能结构 51 11.4 软件质量与软件测试 52 11.5 软件测试的经济目的 54 11.5.1 满足用户需求,提高产品的竞争力,最终提高产品的销售量 54 11.5.2 尽早发现缺陷,降低后继质量成本 54 11.6 何时应当停止测试 56 十二 整体性能测试剖析 57 十三 性能测试工具之研究 62 13.1 性能测试的意义 62 13.2 性能测试工具综述 63 13.3 性能测试工具的体系架构 64 13.4 虚拟用户产生器 Vugen 65 13.5 Proxy 二次捕获的问题 67 13.6 关联的问题 68 13.7 脚本的问题 70 13.8 Conductor 和 Player 部分 71 13.9 Conductor 和 Player 的技术要点 72 13.10 数据分析工具 Analysis 72 13.11 结束语 72 十四 性能测试原理及性能测试实例分析 73 14.1 软件测试中的性能测试 73 14.1.1 性能测试的含义 73 14.1.2 性能测试的分解 73 14.2 一个性能测试实例 74 14.2.1 被测系统 74 14.2.2 对被测系统进行性能测试 75 14.5 总结 80 十五 软件GUI测试中的关注点 80 15.1 不能不说的二个问题 81 15.1.1 软件测试中的“二八”原则 81 15.1.2 软件黑盒测试解决的问题 81 15.2 软件黑盒测试常见错误类型及说明 81 15.2.1 用户界面错误 81 15.2.2 功能性 81 15.2.3 人机交互 82 15.3 命令结构和录入 87 15.3.1 不一致性 87 15.3.2 “最优化” 87 15.3.3 菜单 89 15.4 遗漏的命令 90 15.4.1 状态转换 90 15.4.2 危机预防 90 15.4.3 由用户进行的错误处理 91 15.4.4 其他问题 91 15.5 程序僵化 92 15.5.1 用户可调整性 92 15.5.2 控制方式 93 15.6 性能 94 15.6.1 降低程序速度 94 15.6.2 缓慢回应 94 15.6.3 如何减少用户吞吐量 94 15.6.4 反应拙劣 94 15.6.5 没有提前输入 95 15.6.6 没有给出某个操作会花很长时间的警告 95 15.6.7 程序太多提示和询问 95 15.6.8 尽量使用简单命令和提示 95 15.7 输出 95 15.7.1 不能输出某种数据 95 15.7.2 不能重定向输出 95 15.7.3 与一个后续过程不兼容的格式 96 15.7.4 必须输出的很少或很多 96 15.7.5 不能控制输出布局 96 15.7.6 荒谬的精度输出级别 96 15.7.7 不能控制表或图的标记 96 15.7.8 不能控制图形的缩放比例 96 15.8 错误处理 96 15.8.1 错误预防 96 15.8.2 错误检测 97 15.8.3 错误恢复 98 15.8.4 边界相关的错误 99 15.8.5 计算错误 100 15.9 小结 100 十六 软件测试技术 100 16.1 软件测试基础 101 16.1.1 测试目标 101 16.1.2 测试原则 101 16.1.3 可测试性 102 16.2 测试用例设计 104 16.3 白盒测试 104 16.4 基本路径测试 105 16.4.1 流图符号 105 16.4.2 环形复杂性 106 16.4.3 导出测试用例 106 16.4.4 图矩阵 108 16.5 控制结构测试 108 16.5.1 条件测试 108 16.5.2 数据流测试 110 16.5.3 循环测试 111 16.6 黑盒测试 112

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值