软件测试基础(四)

1.测试用例的基本要素

1.测试用例：是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
2.好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。
3.评价测试用例的标准：对比好坏用例的评价标准：
(1)用例表达清楚，无二义性。
(2)用例可操作性强。
(3)用例的输入与输出明确。一条用例只有一个预期结果。
(4)用例的可维护性好。
(5)用例对需求的覆盖率高。

2.为什么在测试前要设计测试用例？

1.测试用例是测试执行的依据。
2.可以复用(回归测试的时候)。
3.衡量需求的覆盖率。
4.使得工作可重复，自动化测试的依据。
5.借鉴意义，后续测试人员可以借鉴前人写的东西。

3.测试用例的设计方法

3.1基于需求进行测试用例的设计

1.基于需求设计测试用例是测试设计和开发测试用例的基础
(1)第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。
(2)在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计。
2.在分析测试需求时，一般分为功能测试需求和非功能测试需求。
3.功能需求测试分析：
需求是测试人员进行测试的依据。功能测试需求包括以下，通常包括以下几个方面。

(1)系统各个功能界面的验证。
(2)借助业务把功能串起来进行测试。
(3)功能的一致性，交互性(多功能互操作)的测试。
(4)系统的不同输入，结果输出的业务数据测试。
(5)功能的错误操作，异常操作的测试(属于负面测试)。
(6)功能实现用到的算法验证，有时需要用运代码评审。
(7)用户操作的易用性，用户体验，往往结合功能测试同时验证。
针对具体的需求，可以根据业务分类，用户角色(餐厅的会员系统)或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分是最常用的方法。

4.例子：下面对一个简单日历系统的需求进行分析

对日历根据web界面的功能布局分析出的功能框图如下：

也可以采用思维导图的方式，更为方便、有效，只管的呈现测试需求得到分析结果，可以更好的支持测试分析思路的连贯性。
5.百度网盘收集段为例进行需求分析：

在进行需求分析的时候，我们还要考虑业务规则，如上传文件的大小有没有限制；一次性上传多少数量的文件，比如小于00个；文件夹最多有多少层。
6.非功能需求测试分析：
1.非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等，从测试需求分析来看，每一类非功能性测试都需要根据需求单独分析。他们之间可以会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能性的要求是不一样的，这个需要根据具体的项目，具体需求和不同产品应用的特点进行分析。

(1)纯客户端软件，比如字处理软件(word,PPT),媒体(音频/视频)播放软件(电脑自带的)等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定要求。
(2)企业内部的客户端/服务端(C/S)应用系统，比如电子邮件，即即时通讯系统(飞Q,飞书，企业微信，钉钉)等，在系统功能
(3)测试需求上比纯客户端复杂，要求功能正确，稳定性好，但是整体上看，对性能，安全性，兼容性要求不高。
(4)外部大型复；
杂商业软件，比如电子商务，网上银行，视频网站(腾讯，优酷)等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

2.非功能性测试
用户需求：购买3000块钱以内的华为智能手机。

测试用例：
(1)价格<=3000元
(2)品牌为手机
(3)智能手机
(4)手机功能验证
打电话
接电话
发短信
收短信

3.2具体的设计方法

3.2.1 等价类

根据需求将输入(特殊情况下才考虑输出)，把输入划分成若干个等价类，从每一个等价类当中取一个测试用例进行测试，如果这个测试用例通过，我们就说测试用例代表的等价类测试通过。等价类可以解决测试用例无法穷举的情况。

(1)有效等价类:符合数据规格说明的数据集合。
(2)无效等价类：不符合数据规格说明的数据集合。
在进行测试的时候有效等价类和无效等价类都要进行测试。

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

2.例子：网易邮箱的登录

3.2.2 边界值

1.边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
2.例子：

(1)输入框长度为1-11，取边界值为：1,11,12,0
(2)运动员的参赛项目为1-3项，取边界值为：0项，1项，3项，4项。
(3)查询面页面有999行，每50行为一页，取边界值为：输入0行，1行,50行，51行，999行。
边界值即边界周围的值，边界左右1的值，值对应的预期结果。

3.2.3错误猜测法

1.错误猜测法：测试人员依据自己的经验，知识，个人直觉判断软件哪一块有问题，针对性的设计测试用例。适合于补充测试用例或者进行探索性测试的时候。
2.错误猜测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运与测试。这个方法的缺点是难以系统化，并且过度依赖个人能力。
3.错误猜测法的例子：

(1)查询信息:王小二
“王小二”--------------->可以搜出相关信息(数据库中有王小二的信息)
" 王小二 "--------->搜不到任何信息(把空格也当做有效字符了)。
(2)查询信息:500条数据，每一页只展示100条
翻页查看的时候，发现不同的页面有重复的数据出现，是怎么回事？

原因是没有经过排序展示的，经过排序后数据就不会乱了。

3.2.4场景设计法

1.把一个个孤立的功能串起来形成场景，每一个功能不同的输入会触发流程走向不同的场景，根据这些不同功能的不同输入触发形成的场景进行测试用例的设计。

2.ATM取款流程
提取场景中涉及的功能点，考虑每一个功能的不同输入。
插卡----输入密码-----输入取款金额取钱-------退卡

3.2.5因果图法

1.因果图是一种简化了的逻辑图，能直观的表明程序输入条件和输入动作之间的相互关系。使用场景：当输入有多个，并且不同的输入组合对应着不同的输出，这个时候我们可以用因果图来进行测试用例的分析，根据分析的结果来设计测试用例。
2.因果图的几种关系
(1)恒等：输入为真，输出为真。

(2)与:当输入条件有多个，多个条件都为真的情况下，输出才为真。

(3)或：当输入条件有多个，其中有一个条件为真，输出为真。

(4)非：输入为真，输出为假/输入为假，输出为真

3.如何使用因果图法来设计测试用例?

(1)分析所有的输入输出。
(2)找出输入和输出之间的逻辑关系。
(3)根据输入和输出画出因果图。
(4)根据因果图画出判定表。
(5)根据判定表去设计测试用例。

4.例子：618京东活动，订单已提交，并且购物金额大于300，或者右红包，有优惠，否则无优惠。
(1)分析所有的输入输出:
输入:
订单已提交，购物金额大于300，有红包。
输出:
有优惠，没有优惠。
(2)找出输入和输出之间的逻辑关系。
订单已提交，购物金额大于300，有红包->有优惠
订单已提交，购物金额小于300，有红包->有优惠
订单已提交，购物金额大于300,没有红包->有优惠
订单已提交，购物金额小于300，没有红包->没有优惠
订单未提交，购物金额大于300，有红包->没有优惠
订单未提交，购物金额小于300，有红包->没有优惠
订单未提交，购物金额大于300，没有红包->没有优惠
订单未提交，购物金额小于300，没有红包->没有优惠。
(3)根据输入输出的逻辑关系，画出因果图

(4)根据因果图，画出判定表

(5)根据判定表写测试用例(8个)

3.2.5正交排列

1.正交试验设计是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
2.
因素：变量称为因素。
水平：在试验范围内，因素被考察的值称为水平。
正交表的构成：
行数：正交表中的行的个数，即试验的次数,用N代表。
因素数：正交表中列的个数，用C代表。
水平数：任何单个因素能够取得的值的最大个数，正交表中的包含的值为从1到“水平数”，用T代表。
正交表的表示形式： L=行数(水平数*因素数) L=N(TC)
正交表的两条性质：

每一列中各数字出现的次数都一样多.
任何两列中的各有序数对出现的次数都一样多。

3.正交法设计测试用例的步骤：

1、有哪些因素（变量）
2、每个因素有哪几个水平（变量的取值）
3、选择一个合适的正交表
4.把变量的值映射到表中
5.把每一行的各因素水平的组合作为一个测试用例.
6、加上你认为可疑且没有在表中出现的用例组合.

4.什么样的测试用例是一个好的测试用例？

4.1什么是测试用例的有效性？

1.测试用例对应的功能已删除，不可操作了。
2.执行一条测试用例未发现BUG,实际该处有BUG.
3.执行一条测试用例发现了BUG.
4.执行一条测试用例未发现BUG,实际该处BUG已修改。

4.2测试用例的粒度和评价

测试用例的粒度

1.好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

粒度:指测试用例编写的详细程度。

(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
(2)(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
2.大多数测试编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。主要考虑的内容有：

(1)产品的质量要求
(2)项目对用例的要求
(3)测试时间和资源是否充

但是不管用例怎么简化，都不应该省略。

测试用例的评价

1.测试仪用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量，测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式评审和非正式评审。

同行评审
用户检查
项目组评审

(1)测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
(2)除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。
(3) 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。