软件测试 - 用例篇

回顾上一篇博客主要内容:软件测试 - 基础篇
1: 软件测试的流程是什么?

需求分析,测试计划,测试设计/测试开发,测试执行,测试报告

需求分析
分析需求,验证需求的正确性和合理性,从需求中提取出测试项

测试计划
要考虑测试人数,测试环境,测试时间,测试设备等

测试设计/测试开发
要根据需求写测试用例

测试执行
到这里开发已经完成;我们要执行测试用例,验证功能是否完善,有BUG就提交BUG,验证BUG

测试评估
写了多少测试用例,执行了多少,剩余的测试用例数有多少,有多少BUG数量,解决的BUG数量,遗留的BUG以及解决方案,测试范围以及测试功能等

2: 如何描述一个 BUG ?

1:发现问题版本
2:测试环境
3:测试数据
4:测试步骤
5:测试实际结果与预期结果
6:附件,错误日志,错误截图等等
7:不要把多个BUG放到一起

3: 因为一个 BUG 和开发人员产生了冲突怎么做?

1: 先检查自身,看 BUG 描述是否清楚
2: 从用户的角度去说服开发人员
3: BUG 定级要依据公司的标准
4: 要不断的提高自己的技术和业务水平,提高自己在团队的影响力
5: 找产品经理一起商量解决办法

4: 在回忆什么是测试用例?

向被测试系统发起的一组集合,包含测试环境,测试步骤,测试数据,预期结果

为什么软件测试人员要写测试用例?

1: 测试用例是测试执行的依据

2: 测试用例可以复用,在进行回归测试的时候不用重新编写

3: 测试用例可以衡量需求的覆盖率
查看需要测试的需求是否都测了,写下来之后就不会频繁的测试最后可能就会把自己搞晕,对照着测试还是很方便的

4: 后人可以借鉴
我们写的测试用例都是在公司会有备份的,即使你后来不干了,后面来的新人就可以借鉴你写的测试用例

5: 手工测试用例是自动化测试的依据
自动化测试就是把手工测试用例给转换成代码脚本,让其自己测,从而提高效率

基于需求设计测试用例

需求是测试人员进行测试的依据,测试人员分析需求,验证需求的合理性和正确性,无二义性,并且逻辑自洽.从需求当中提取出测试项,根据测试项进行进一步的细分,提取出测试点,编写测试用例…

1: 从界面开始进行测试(符合UI设计稿)(功能性)
这是我们拿到软件的第一眼,看看是否好坏,是否满足需求

2: 验证软件的功能,把业务相关的功能串起来进行测试(功能性)
比如一个淘宝大概的流程:搜索,加入购物车,结算,付钱…看看是否满足需求,要求我们不能针对一个点进行测试,要把他们串起来

3: 一个功能的不同的输入,和相应不同的输出(功能性)
就像我们登录QQ一样,用户名密码正确成功登入是一种情况,用户名或密码错误是一种情况,有一个没写又是一种情况

4: 功能之间的交互性(功能性)
就像注册和登录是两回事,购物车跟收藏夹也是(购物车满了,可以放在收藏夹里),联系客服(买家跟卖家的联系)等等

5: 异常功能的测试(功能性)
就像QQ登录一样,输错了有没有提示信息,都分别提示的什么?

6: 功能用到的算法的验证(功能性)
有一些功能是需要用到算法的,要结合代码,所以需要和开发人员沟通怎样测,然后设计一些数据来进行测试

7: 从易用性,兼容性性能等几个方面去考虑(非功能性)
软件用起来简单还是不好上手,软件安在各种的系统上有没有不兼容的情况,这些都要进行测试

浅浅看一下日历的一些功能

我们在对不同应用的软件对于非功能性的要求是不一样的:
1: 面向客户端的软件,像画图板,office,Word等对性能,安全性要求不高的,但是对于兼容性(必须在不同的系统上都能够使用),可移植性,稳定性要求(频繁使用)较高
2: 面向企业内部的软件,像飞Q,飞书,钉钉等对兼容性要求不高,但是对于功能性要求高,可靠性要求高
3: 大型商用软件,像微信,QQ等对性能,兼容性,可靠性,可移植性,安全性等要求较高(毕竟用户多,而且腾讯也是用他们来赚钱的,懂得都懂,虽然他是免费的,但是我们发现他上面是有很多广告的,只要我们点击了,腾讯就会向广告商收钱,想一想这其中有多少用户…)

具体的设计测试用例的方法

1: 等价类

根据需求输入(特殊情况会考虑输出)划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举的问题
就像我们春夏秋冬的衣服都是分类好的放在一块区域(勤快的人哈…),就可以把它们理解为等价类

2: 边界值

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

3: 错误猜测法

根据测试人员的经验,知识积累,猜测某一块功能有问题,有针对性的进行测试用例的编写(就像探索性测试,针对性比较强,比较依赖测试人员的个人水平)

例如:

1: 搜索框查询(空格)
在某个搜索框里搜一个名字(王二狗),但是用户在输入的时候前面多输了空格或者后面多输了空格导致并没有查到王二狗,但是数据库确确实实有王二狗,就是因为这个空格导致了数据不匹配所以查不到,我们学Java的都知道,在 String 中有一个方法叫 trim(),他就可以去除字符串前后的空格(当然中间的是不能去掉的,中间的用户是能够发现的,是有意义的)

2:搜索查询出的信息 有5000条(去重了)
查找500条关键信息,每一页展示 100 条,共展示5页,但是发现不同的页面上有相同的数据,数据 id 也一样,为什么?
因为我们查询一般是要进行排序的:

4: 场景设计法

很多的软件不同的场景,是基于不同的事件的触发,不同的事件的触发,会导致场景走向不同的事件流.
不同的功能点串起来形成一个场景,不同的功能点又有不同的输出,不同的输出导致不同的测试场景

例如:ATM取款机场景流程:
插卡 => 输入密码 => 输入取款钱数 => 取款 => 退卡
针对每一个点都存在一些事件:

1: 插卡:

1. 插错了卡(公交卡,饭卡,会员卡…非银行卡)
2. 银行卡的磁条无法识别
3. 卡损坏
4. 卡号冻结,账户锁死
5. 网络不好,无法识别卡
6. 停电吞卡
   …

2: 输入密码:

1. 输入正确的密码
2. 输入错误的密码
3. 不输入密码,直接点击确认
4. 密码输入错误超过三次,账户锁定
5. 密码第一次输入错误,第二次或第三次输入正确
6. 测试密码是否加密
7. 是否支持不同字符的输入
   …

3: 输入取款钱数:

1. 输入小于卡余额的钱数
2. 输入等于卡余额的钱数
3. 输入大于卡余额的钱数
4. 输入非整百的钱数
5. 不输入直接点击取钱按钮(这时取钱按钮是灰色的)
   …

4: 取款:

1. 输入小于等于卡余额的钱数时,取款成功
2. 输入大于银行卡余额的钱数,取款失败,并提示"余额不足"
3. 超过每日取款余额的上限
4. 超过每日取款次数的上限
   …

5: 退卡:

1. 取钱后正常退卡
2. 操作超时,吞卡
   …

6: 还有 ATM 机存在的问题:

1. ATM 一切正常
2. ATM 余额不足
3. ATM 断网,断电,硬件故障 软件系统崩溃
4. 发生异常情况 ATM 是否支持事务回滚
   …

虽然我们能够写出这么多的事件,但是他不算一个测试用例的,这里我们只是把每个场景可能设计到的情况写了下来.测试用例他是应该带有测试效果的:

1: 插错银行卡,系统提示"无法识别"
2: 卡消磁后,并将其插入 ATM 中,ATM 提示"无效卡,请检测你的银行卡是否有效!"

场景设计法就是根据场景中会可能发生的事件进行设计测试用例…

5: 因果图法

因果图是一种逻辑图,恒等,与,或,非用因果图来设计测试用例,叫做因果图法.

使用场景: 当我们有很多输入,不同的输入或者不同的输入组合针对有不同的输出,这个时候我们可以用因果图法来进行测试用例的设计.

5.1 恒等

输入为真,输出也为真

5.2 与

多个不同的输入同时为真,输出才为真.

5.3 或

多个输入中其中一个为真,输出为真.

5.4 非

输入为真,输出为假.

5.5 因果图法设计测试用例的步骤

1: 分析出所有的输入和输出

2:找出输入和输出之间的组合关系

3: 根据关系画出因果图

4: 根据因果图画出判定表

5: 根据判定表写出测试用例

例子:我们根据 618 的活动,订单已提交且金额大于 300 ,有优惠,或者 有红包也有优惠:

5.5.1 分析出所有的输入和输出

输入: 订单已提交,金额大于 300,有红包 ; 订单未提交,金额小于等于 300,没有红包

输出: 有优惠,无优惠

5.5.2 找出输入和输出之间的组合关系

1: 订单已提交,金额大于 300,有红包 ===> 有优惠

2: 订单未提交,金额小于等于 300,有红包 ===> 有优惠

3: 订单已提交,金额大于 300,没有红包 ===> 有优惠

4: 订单已提交,金额小于等于 300,没有红包 ===> 没有优惠

5: 订单未提交,金额大于 300,有红包 ===> 没有优惠

6: 订单未提交,金额小于等于 300,有红包 ===> 没有优惠

7: 订单未提交,金额大于 300,没有红包 ===> 没有优惠

8: 订单未提交,金额小于等于 300,没有红包 ===> 没有优惠

5.5.3 根据关系画出因果图

5.5.4 根据因果图画出判定表

5.5.5 根据判定表写出测试用例

根据判定表的每一列都是一个测试用例:

1: 订单已提交,金额小于300,有红包 > 有优惠

2: 订单已提交,金额大于300,没有红包 > 有优惠

3: 订单已提交,金额小于300,没有红包 > 没有优惠

4: 订单已提交,金额小于300,没有红包 > 没有优惠

5: 订单未提交,金额大于300,有红包 > 没有优惠

6: 订单未提交,金额小于300,有红包 > 没有优惠

7: 订单未提交,金额大于300,没有红包 > 没有优惠

8: 订单未提交,金额小于300,没有红包 > 没有优惠

6: 正交法(了解)

知道有这个方法就行.

根据正交性来设计测试用例,从大量的实验(测试)数据中根据正交原则取出最优的数据的组合,根据最有数据组合试验的结果,来分析整个测试的结果.

正交法的目的就是为了减少用例数目,用尽量少的用例覆盖输入的两两组合.