No.8 测试用例的编写和用例评审

1.什么是测试用例:

TestCase是为了某个特殊目标而编制的一组测试输入,执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。

总结:每一个测试点的数据设计和步骤设计。

2.测试用例的重要性:

1.测试用例是软件测试的核心,影响软件测试的因素很多,例如软件本身的复杂程度,开发人员(包括分析,设计,编程和测试人员)的素质,测试方法和技术运用等等,因为有些因素是客观存在的,无法避免,有些因素则是不稳定的,波动的,例如开发团队是流动的,有经验的走了,新人不断补充进来。人工作会受到情绪等因素的影响,有了这些因素,软件测试的稳定性就会受到影响,但是有测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量。可以把人为因素的影响减少到最小,即便最初的测试用例考虑不周全,随着测试的进行和软件的更新,也将日趋完善。

因此测试用例的设计和编制是软件测试活动中最重要的,测试用例是测试工作的指导,是软件测试必须遵守的准则。

2.评估测试结果的基准;

3.好的测试用例,不仅方便自己和别人查看,而且能帮助软件设计时考虑的更周全,因此测试用例的编写和设计一样也是非常重要的。测试用例要有执行性(指导性)。

3.测试用例的内容:

(1)用例ID:可以定义测试用例的编号,便于查找测试用例,便于测试用例的跟踪。

产品名-子系统-测试项-xxx,例如:WX-HB-001,QQ-RZ-biaoTi-001,QQ-KJ-SS-FB-001;

(2)用例名称:是测试用例的编辑的名称代号,输入内容+结果(手机号为汉字,界面提示)见名知意;

(3)测试目的:也就是测试用例的目标和使其过程中所要达到的最终要求;(可省略);

(4)测试级别:也就是指测试用例的等级划分。高中低,或者 1 2 3 4等;

(5)测试环境:软件+硬件环境(一般是兼容性测试时填写);

(6)测试数据:测试用例是“一组输入,执行条件,预期结果‘,毫无疑问地应该包括清晰地输入数据和预期输出,没有测试数据的用例最多只具有执行性意义,不具有可执行性;

(7)前置条件:执行用例的前置条件;

(8)测试步骤:也就是指测试用例所需要地详细操作过程;(有效的用例可以整合到一条用例中,冒烟测试可以只包括正常情况的一种即可,其余的有效情况可整合在子模块中)页面存在的元素加上双引号,要与页面名称一致,如:在输入框中输入“昵称”:xxxxx

(9)预期结果:每条测试用例地期望结果;(预期结果每一步与实际操作步骤相对应)

(10)实际结果:实际测试结果;

(11)所属模块 子模块

界面显示的专业名词:

①下拉框:

No.8 测试用例的编写和用例评审_第1张图片 

②输入框:

No.8 测试用例的编写和用例评审_第2张图片 

③按钮:

No.8 测试用例的编写和用例评审_第3张图片 

④单选框:

No.8 测试用例的编写和用例评审_第4张图片 

⑤复选框:

No.8 测试用例的编写和用例评审_第5张图片 

⑥菜单栏:

4.如何编写测试用例:

(1)对测试需求进行分析,依照不同的功能模块列出测试点(详细);

(2)选择等价类,边界值,错误推测法等测试用例设计方法,根据测试点命名为不同的测试标题,并补充相应的测试步骤及测试数据,预期结果;

(3)测试用例覆盖所有用户需求,包括单个功能和业务功能的覆盖,正面(有效等价类)和反面(无效等价类)用例的覆盖;

(4)编写测试用例注意编写格式,元素包括测试编号,测试标题,预置条件,不存在冗余,重复,二义性(可能,也许,或许,是否)等等;

5.测试用例的原则:

(1)每一个测试点至少有一个测试用例与之对应;

(2)每个测试用例包含的测试步骤尽量不要超过10个,如果过多就进行拆分;

(3)每个步骤只包含一种情况,不能将多种情况放在一个步骤里;

(4)每个测试用例包含的测试步骤不得少于2个;

(5)测试用例设计时应该包含功能的边界情况、等价类等方法;

(6)对于流程尽量实现每个路径的覆盖;

(7)关注需求中特别提出的权限,必输项,初始值和计算结果等内容;

(8)测试用例设计根据测试范围进行评审检查,覆盖全部范围;

(9)功能测试时,根据界面,业务,数据流变化进行用例划分;

(10)测试用例不能只有自己看懂,要清晰明确;

6.用例评审的重要性:

①无论是初级测试工程师,还是高级的,还是专家级的,设计出来的测试用例都是需要经过评审;

②测试用例一般分配给每个人来设计,设计用例的人并不知道在具体执行的时候是否有问题,不能保证自己设计的用例能否覆盖完全;

③保证测试人员和开发人员对于被测试功能的理解的一致性,避免测试过程中针对不过测试人员与开发人员扯皮;

④需求人员参与评审,他们能帮助你找出更多问题,经常在测试的时候,有些细节是无法从需求文档上得知的,需要频繁和需求人员进行沟通(空格的处理,app软件更新);

⑤现在很多人是项目外包或人员外包,那么完成每一项工作的第一件事就是提交客户评审,当然在提交给客户之前自己的team先评审一下最好,确保提交给客户高质量的产品;

⑥按照用力数量来评估工作量,用例不完整,工时给少了,实际测试的时候就等着加班吧;

7.用例评审的内容:

以会议评审为主,一般我们会在用例初步设计完成后,先进性测试组内部的评审,然后进行项目组内的评审。

用例评审的内容(用例检查清单):

(1)测试用例是否按照公司定义的模板进行编写;

(2)测试用例本身的描写是否清晰,是否存在二义性;

(3)测试用例内容是否正确,是否与需求目标相一致;

(4)测试用例的期望结果是否确定,唯一;

(5)实际操作步骤与描述步骤相一致;

(6)测试用例是否覆盖了所有的需求;

(7)测试用例设计是否存在冗余性;

(8)测试用例是否具有可执行性;

(9)场景测试用例是否覆盖最复杂的业务流程;

(10)用例设计是否包含了正面,反面的用例;

(11)对于系统自动生成的输入项是否注明了生成规则;

(12)测试用例应包含中间和后台数据的检查;

(13)测试用例应有整齐而的名称和编号;

(14)测试用例应标注有执行的优先级;

(15)测试用例包含相关的配置信息:测试环境、数据、前置条件、用户授权等;

8.用例评审的流程:

参与用例评审的人员:

测试组内部评审:各个测试人员和测试负责人;

项目组内评审:产品,测试,开发;

问题1:为什么要有不同的人员参与评审?

每个人看待问题的角度不同,保证对需求理解的一致性;

流程:

(1)评审当天准备好测试用例;

(2)提前和大家说一下/协商,项目经理,测试负责人,测试人员,产品经理,开发人员,并把用例发给大家;

(3)召开会议评审,针对评审用例检查清单,评审过程中收集相关人员的反馈信息,并在此基础上进行测试用例更新,直到评审通过;

(4)由测试人员或项目经理进行用例评审后的确认;

9.用例评审后的确认:

为了节约时间成本,第一次评审尽量对用例设计考虑全面,提前发现其中的不足之处;但是第一次评审难免会要修修补补的地方,在评审时尽快地修复用例,不能在一两分钟修复地,记录袭来,在会议结束后进行修改。

如果改动不是很多的,可以发出邮件,标明修改部分,再最后确认最终版,如果需要进行二次评审,那么重新开始邀约会议做二次评审。

10.用例评审需要避免:

①测试点含糊用于,每个用例评审都应该确定最终版,少有矛盾或疑惑的需求点,都应该确认下来,不能含糊不清;

②杂乱无章的评审,有顺序有逻辑的进行评审是很重要的一点,如果只想按照自己的思路评审,不顾他人感受,那么就等同于做无用功,这样的用例执行出来也会有一定的质量风险;

③我们的测试用例需要经常更新:增加,删除,修改用例;

你可能感兴趣的:(测试用例)