本节主要内容 - 测试用例的基本要素 - 测试用例的设计方法 - 测试用例的有效性 - 测试用例的粒度和评价
测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合,这组集合包括:测试环境、操作步骤、测试数据、预期结果等要素。
评价测试用例好坏的标准: - 用例表达性清楚,无二义性。 - 用例可操作性强 - 用例的输入与输出明确。一条用例只有一个预期结果。 - 用例的可维护性好。可维护性好包含两个方面:用例的可读性好、用例易修改。 - 用例对需求的覆盖率高。需求的覆盖率=用例的条数/功能点的个数。 - 暴露程序Bug的能力强。
测试用例的优点 - 测试执行者的依据 - 自动化测试的基础 - 评估需求覆盖率 - 用例的复用 - 基类测试的方法思路以供后续借鉴
测试用例的缺点 - 费时费力,往往在设计测试用例时花费的时间比执行是花费的时间还多。 - 测试的覆盖率无法衡量,不知道是否较全面的测试了所有功能。 - 对新版本的重复测试很难实施,存在大量冗余测试影响测试效率。
设计方法有5种:基于需求的设计、等价类、边界值、因果图、正交排列、场景设计法、错误猜测法。
RBT是基于需求的测试方法,会使测试更加有效,因为它使测试专注于质量问题产生的根源,即需求。
基于需求的测试是一种最根本的软件测试,主要关注以下两个问题: 1. 验证需求是否正确、完整、无二义性,并且逻辑一致。 2. 要从“黑盒”的角度,设计出充分并且必要的测试集,以保证设计和代码都能完全符合需求。
案例:
依据需求将输入划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题。
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
1
在实际的测试设计中,会将等价类和边界值结合起来使用。
1
因果图是一种简化了的逻辑图,能直观地表明程序输入条件(原因)和输出动作(结果)之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法,特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。 - 恒等
1
- 与
1
- 或
1
- 非
1
因果图法设计测试用例的步骤如下:
因果图:
判定表:
因果法测试用例可以帮助测试人员理清输入和输出的关系,但是对于比较复杂的输入和输出,会耗费大量的时间。所以引出了下面的正交法。
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法,它是根据正交性,由试验因素的全部水平组合中挑选出部分有代表性的点进行试验,通过对这部分试验结果的分析了解全面试验的情况,找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
正交法中的重要概念: - 因素:在一项试验中,凡欲考察的变量称为因素(变量)。 - 水平:变量的取值。
正交表的构成: - 行数:正交表中的行的个数,即试验的次数,用N代表。 - 因素数:正交表中列的个数,用C代表。 - 水平数:任何单个因素能够取到的值的最大个数。正交表中的包含的值为从0到数”水平数-1“或1到” 水平数“,用T代替。
正交表的表示形式: L=行数(水平数*因素数) 即:
L=N(TC)
正交表的两条性质: - 每一列中各数字出现的次数都一样多。 - 任何两列所构成的各有序对出现的次数都一样多。
正交法设计测试用例的步骤: 1. 分析有哪些因素(变量); 2. 每个因素有哪几个水平(变量的取值); 3. 选择一个合适的正交表; 4. 把变量的值映射到表中; 5. 把每一行各因素水平的组合作为一个测试用例; 6. 加上你认为可疑且没有在表中出现的用例组合。
1
正交表:
作业:用什么方法来设计以下两个作业,5个条件都是可填和可不填的。
查询页面:姓名、性别、学号、学校、班级
1
正交表1:
事件流 通俗的说,单击鼠标后不同的触发顺序和处理结果就形成了时间流。
控制流 是指按一定的顺序排列程序元素来决定程序执行的顺序。
场景设计法可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,是测试 用例更容易理解和执行。 典型的应用是用业务流把各个孤立的功能点串起来,为测试人员建立整体业务感觉,从而避免陷入功能细节忽视业务流程要点的错误倾向。
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。
基于经验和直觉,找出程序中你认为可能出现的错误,有针对性地设计测试用例。 经验可能来自于在对某项业务的测试较多,也可以来自于售后用户的反馈意见,或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题,问题越多的地方,潜在的bug也就越多。
以注册邮箱为例: 1. 校验中特殊字符空格的处理: - 当空格出现在前面或后面时,正规开发人员会对空格进行截取,所以不会影响; - 但当空格出现在中间时,就会将空格认为是一个字符,就会报错。 2. 密码校验中的大小写 3. 姓名中的特殊字符 4. 密码发送是否明文
粒度:指测试用例编写的详细程度 测试用例编写时: 1. 写的过于简单,则可能失去了测试周例的意义; 2. 写的过于复杂或详细,会带来两个问题: - 效率问题 - 维护成本问题 - 容易限制测试人员的思维 大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键,也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可参考以下内容: - 产品的质量要求 - 项目对用例的要求 - 测试时间和资源是否充足
主要有: - 同行评审:体现了敏捷的“个体和交互比过程和工具更有价值”这一原则。 - 用户检查:体现了敏捷的“顾客的协作比合同谈判更有价值”这一原则。 - 项目组评审
本文转自:https://blog.csdn.net/bit666888/article/details/81078499