本周分享《测试用例设计》实验内容,由于知识含量较多,现在拆分为多篇分享,今日是第八篇,也是最后一篇内容、 本次教材后加入了“思考练习”,希望学习本次教材连载的小伙伴最终能够完成最后的小作业,边学边练才会事半功倍,加油。 回顾前期内容,请点击: 教材连载:测试用例设计(七) 教材连载:测试用例设计(六) 教材连载:测试用例设计(五) 教材连载:测试用例设计(四) 教材连载:测试用例设计(三) 教材连载:测试用例设计(二) 教材连载:测试用例设计(一)
本实验主要讲解测试用例设计方法,包括等价类,边界值,正交试验表,判定表,流程分析法,状态迁移法,错误猜测等。
(1)、掌握测试用例设计方法,以便设计高效的测试用例。
8.对测试用例进行评审
在测试工作中有一项很重要的活动就是团队之间互相对测试用例评审,也就是平时所说的同行评审。
同行评审(Peer Review)是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。需要进行同行评审的特定产品在定义项目软件过程的时候被确定并且作为软件开发计划的一部分被安排了进度,可以以会议的形式进行,也可以不以会议的形式来进行。
测试用例评审的目的:
1)为了减少测试人员执行阶段做无效工作;(执行无效case,提交无效问题);
2)为了避免三方需求理解不一致;
3)为了每个测试人员的质量标准与项目要求标准达成一致;
测试用例评审的标准:
1)检查大纲和用例内容一一对应,影响因素无丢失;
2)检查语言描述简洁、清晰、明了;
3)检查每条测试用例都有明确的预期结果;
4)根据正规化用例的各个字段要求对应的细节(比如测试目的、前提条件、实现说明、测试环境准备、测试步骤、优先级别、是否自动化等);
测试用例评审检查项:
1)测试用例是否按照公司定义的模板进行编写的;
2)测试用例的本身的描述是否清晰,是否存在二义性;
3)测试用例内容是否正确,是否与需求目标相一致;
4)测试用例的期望结果是否确定、唯一的;
5)操作步骤应与描述是否相一致;
6)测试用例是否覆盖了所有的需求;
7)测试设计是否存在冗余性;
8)测试用例是否具有可执行性;
9)是否从用户层面来设计用户使用场景和业务流程的测试用例;
10)场景测试用例是否覆盖最复杂的业务流程;
11)用例设计是否包含了正面、反面的用例;
12)对于由系统自动生成的输出项是否注明了生成规则;
13)测试用例应包含对中间和后台数据的检查;
14)测试用例应有正确的名称和编号;
15)测试用例应标注有执行的优先级;
16)测试用例包含相关的配置信息:测试环境、数据、前置测试用例、用户授权等;
17)每个测试用例步骤应<=15 Steps(业内推荐,不强制);
18)自动化测试脚本必须带有注释(注释应包括:目的、输入、期望结果等);
19)非功能测试需求或不可测试需求是否在用例中列出并说明?
(1)什么是测试用例?
(2)测试用例应该包含有哪些内容?
(3)简述一下你所知道的测试用例设计方法。
(4)什么是测试用例优先级?划分测试用例优先级有什么作用?
(5)如何进行测试用例的评审?测试用例的评审有什么作用?
(6)城市的电话号码由两部分组成。这两部分的名称和内容分别是:
a)区码:以0开头的三位或者四位数字(包括0);
b)电话号码:以非0,非1开头的七位或者八位数字。
假定被测系统的页面上有城市电话号码的输入框,请写出对此输入框的测试用例。