测试规程与用例设计
更新时间:2024-04-21 01:41:01 阅读量: 综合文库 文档下载
测试规程/用例设计
测试规程(test procedure)是一个提供详细的测试用例执行指令的文档。测试规程应该更注重测试的流程、方法等比较泛的内容,以方便我们对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。
测试用例(test case)对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。
测试规程与测试用例的区别:理想化的测试用例确实需要很多测试数据集合,但是现实中对某一软件进行测试时,由于涉及的面太广,无法一一列举出所有数据,所以要根据公司的规范来做相应的调整。所以,测试规程的文档编辑量较轻,但是只适合熟练的测试人员执行,而测试用例的执行者可以使任何人。
测试用例的设计:
测试用例可以分为基本事件、备选事件和异常事件。
设计基本事件的用例:参照用例规约(或设计规格说明书),根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计备选事件和异常事件的用例:采用的基本方法仍然是等价类划分、边界值、因果图等,根据软件的不同性质和测试的不同目标灵活运用,至
设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能,覆盖率达100%。
于最终设计的测试用例是否能暴露更多的隐藏缺陷,全凭用例设计人员的丰富经验和精心设计了。例如,测试一个手机终端的电话本模块。测试人员需要考虑,将相同的号码A存储到不同联系人名B和C 中,号码A呼入和呼出时,显示的联系人名应该是B还是C呢。类似这样的备选事件,往往在需求阶段描述的并不详尽,需要测试人员及早提出并与项目组达成一致。
测试用例在软件测试中的作用 :
指导测试的实施 规划测试数据的准备
编写测试脚本的\设计规格说明书\
评估测试结果的度量基准 分析缺陷的标准
此阶段的难点和重点:
测试用例设计的几大基本点 使用合理的语言
测试人员该做什么,系统输出什么应该写得很清楚明白,也就是说首先要分清楚测试用例的输入和预期输出
一种最好的避免含义混淆的方法是在操作步骤中采用动词+名词的结构,动词总是测试人员要做得事情,名词总是测试人员操作的对象、事物
将同一个事物命名为同一个名称,不管这个事物是否通过不同的方式出现 测试用例的易测性
简洁性:简洁性的衡量方法就是执行测试花费时间的长短以及在测试过程中是否能保持整个测试的纯净 正确性:正确性意味着测试人员根据测试用例进行的测试获得的测试结果(通过或不通过)是正确的
控制测试用例的长度
控制测试用例的操作时间
对于Matrix用例,一个好的测试用例的长度的衡量标准是是否能在20分钟内测试完毕
在Step-by-step用例中一个比较好的长度是不多于15步:
执行每个测试用例花费更少的时间
测试人员很少犯错误、丢失步骤或需要帮助 测试经理能够准确地估计测试的时间 测试结果更容易跟踪
测试用例依赖关系的利弊
具有依赖关系的测试用例是一些需要依靠先前的测试用例执行的结果来执行的用例
考虑是否真的需要其他的测试的结果作为数据输入,如果是,那么测试必需是累积的。应尽量避免这种情况
保持测试用例依赖关系的正确性和一致性
以一种合理的顺序来安排测试用例的顺序
过分追求“能发现到目前为止没有发现的缺陷的用例是好的用例”
实际测试中,很多人一心想要设计出发现“难于发现的缺陷”而陷入盲区,忘记了测试的真实目的所在。测试只需要保证两点就能达到测试目的:
过分抬高测试用例设计标准,达到“使一个没有接触过系统的人员也能进行测试“的程度
不知道有没有公司真正做到这点,能够将每个测试用例都写得如此详细。之前看了微软关于一个工具的GUI 测试用例,它分了几部分,第一部测试用例设计的五大误区
1)、程序做了它应该做的事情 ;2)、程序没有做它不该做的事情。在做好这两点基础上,才谈得上改进测试用例,使其“发现没有的缺陷“。
分是一些启动/进入模块的case,感觉确实很详细,基本达到能认识英文就能操作的层次。然后在后期关于具体功能测试时,依然出现前置条件(测试环境)不充分的问题,比如在某一部分的Case中,测试环境中要求将文件A 先拷贝到指定目录下,然后再进行Test Step。在这部分的第一个 Case中有关测试环境环境的搭建,但是后面几个Case就没有了(如果只做后面几个Case的话,按照Step来操作直接就Fail了)…微软尚且如此,偶相信其他公司也不会高明到哪里去。
测试的目的是尽可能发现程序中存在的缺陷。每个公司实际情况不同,每个项目的实际情况也不同,所以需要因地制宜,根据实际情况制定测试用例的设计标准。如果项目周期短,工作量大,甚至可以考虑使用测试规程来代替测试用例指导实际的测试执行。
测试用例没有包含实际的数据
先看一个例子,某测试人员需要检查编辑框内是否不允许输入英文,他设计的测试步骤为“输入任意英文字符”。大家觉得是否很熟悉? 测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出,没有测试数据的用例最多只具有指导性的意
义,不具有可执行性。当然,测试用例中包含输入数据会带来维护、与测试环境同步之类的问题,这就有回到测试用例的设计标准上了,还是那句话:
根据实际情况选择适合自己团队的规范标准。
需求/设计变更,而测试用例确没有修改
看似明显的错误,却是在在执行阶段经常出现的老毛病。往往在软件需求和设计已经变更了多次,测试人员觉得这些问题自己知道就行,测试用
测试用例中预期输出过于简单
很多测试用例中,“预期输出”仅简单描述为应用程序的直观反映,其实,“预期输出”还需要更深一层的描述。例如,对一个存储系统, 输入
例没有任何修改。结果导致新加入的测试人员在执行测试用例不知所措,也使测试用例间接变成一堆废纸。
存储数据,点击确定,预期输出为“系统提示成功”。这样的用例完整吗呢?系统提示成功就表示数据成功存储了?显然,还需要去相应界面查看数据是否更新。
正在阅读:
测试规程与用例设计04-21
2011年四川省人民政府工作报告01-26
2018年信访干部心理问题防制与解决措施06-18
EPC项目-美丽乡村提升改造建设总承包项目-技术标(承包人实施方案06-26
燕山大学工程流体力学三级项目09-16
《港珠澳大桥》纪录片观后感12-11
京剧表演艺术中的程式美07-19
防溺水安全教育主题班会教案05-26
- 多层物业服务方案
- (审判实务)习惯法与少数民族地区民间纠纷解决问题(孙 潋)
- 人教版新课标六年级下册语文全册教案
- 词语打卡
- photoshop实习报告
- 钢结构设计原理综合测试2
- 2014年期末练习题
- 高中数学中的逆向思维解题方法探讨
- 名师原创 全国通用2014-2015学年高二寒假作业 政治(一)Word版
- 北航《建筑结构检测鉴定与加固》在线作业三
- XX县卫生监督所工程建设项目可行性研究报告
- 小学四年级观察作文经典评语
- 浅谈110KV变电站电气一次设计-程泉焱(1)
- 安全员考试题库
- 国家电网公司变电运维管理规定(试行)
- 义务教育课程标准稿征求意见提纲
- 教学秘书面试技巧
- 钢结构工程施工组织设计
- 水利工程概论论文
- 09届九年级数学第四次模拟试卷
- 规程
- 测试
- 设计
- 黑白装饰画的美感 教案
- 给在读研究生+未来要读研同学们的一封受益匪浅的信
- 2014年高考数学(理)真题分类汇编:D单元 数列
- 鲧禹治水 大卫 夸父追日 天上偷来的火种 女娲造人 教案
- 基督教讲章:一路上有你
- 职民工驻地安全专项方案
- 法律谈判技巧模拟案例
- 浅析简约风格在女装设计中的运用 - 图文
- 小学四年级体育教案
- 关于审美标准的英语作文-实用word文档(2页)
- 一年级应用题 100题
- 初中生物适岗培训总结
- 人教版二年级语文下册全册教案
- 危机应对案例分析
- (新课标)高三数学一轮复习 第9篇 第1节 随机抽样课时
- 组胚双语习题
- 校园招聘网站的需求分析
- 《初中同步测控全优设计》2013-2014学年七年级英语人教版上册例
- 《个人所得税法》第2条第11项引发的思考
- 滕州市集中供热管理实施办法