第三集 测试用例

概念

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、测试步骤、测试数据、测试预期结果等要素。

什么是要素？就是我们在编写测试用例的时候，每个用例需要给出这些要素对应的信息。

测试中可能会遇到很多问题，如：

·不知道是否较全面的测试了所有功能
测试的覆盖率无法衡量
对新版本的重复测试很难实施
存在大量冗余测试影响测试效率

而测试用例的出现，就是为了解决这些问题。

万能公式

功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试。

功能测试
功能测试是⼀个试图发现程序与其外部规格说明之间存在不⼀致的过程。外部规格说明是⼀份从
最终⽤⼾的⻆度对程序⾏为的精确描述。功能测试通常是⼀项⿊盒操作。在进⾏功能测试时，需要对
规格说明进⾏分析以提炼测试⽤例，本课程中讨论的具体设计测试⽤例的⽅法尤其适⽤于功能测试。
然⽽，不仅是⼯作中还是⾯试中，可能会存在需求不明确的功能？这种情况下该如何进⾏功能测试？
◦ 查找其他相关⽂档，来帮助理解所要测试的产品需要完成的⽬标;
◦ 尽量多参加项⽬组内的会议，⽐如需求讨论、设计讨论、计划讨论等，能够加深对产品的理
解;
◦ 召集相关⼈员，对你整理的结果进⾏讨论，通过评审后，这份⽂档就可以作为依据来设计你
的case了;
◦ 如果是⼀款已经上线的产品，可以多使⽤产品，有不懂的问产品经理;
◦ 也可以去看历史bug，可以了解到⼀些需要关注的东西。
界⾯测试
对软件界⾯上所有的内容都需要进⾏测试。
要求：
整体界⾯测试界⾯的实现与设计图要求⼀致。
◦ 界⾯元素测试
▪ 控件操作验证
性能测试
性能测试和功能测试的区别是：功能测试检查软件是否做了，⽽性能测试测试软件做的好不好。
兼容性测试
软件是部署在硬件系统之上，并依赖所需要的软件环境。如QQ可以在PC端打开，也可以在移动
端打开；移动端⼜分为IOS系统和Android系统，且市⾯上⼿机⼜有不同的品牌、不同的机型、不同
的版本。软件是否能够在不同的环境下正确运⾏需要测试⼈员进⾏验证。
问题：既然市⾯上有众多版本的机器，那么在执⾏兼容性测试时难道所有的机型都需要全⾯覆盖吗？
选取标准：
• 优先选择使⽤当前产品top级别的机型进⾏测试实际在企业中，后台是可以获取到使⽤产品的机型，并以报表的形式统计在后台，供产品⼈员或
其他⼈员制定策略参考。
• 选择主流的浏览器/机型进⾏测试
易⽤性测试
易⽤性测试的标准是检查产品是否具备简单易上⼿的属性。假如测试⼈员从来没有安装或使⽤过
该产品，作为⼀个新⽤⼾，对当前产品是否能够快速适⽤产品的使⽤流程。
安全测试
安全测试和性能测试⼀样都是⽐较⼤的领域。常⻅的安全问题如：
隐私数据明⽂显⽰。
参数未强校验导致SQL注⼊。
越权：普通⽤⼾也可以执⾏管理员权限的操作。
接下来继续尝试对⻔锁进⾏测试⽤例的设计，你能设计多少呢？
除了万能公式之外，还有⼀个⽐较常⽤的测试类型：弱⽹测试、安装卸载测试
弱⽹测试
弱⽹测试的⽬的就是尽可能保证⽤⼾体验，关注的关键点包括：
• ⻚⾯响应时间是否可以接受，关注包括热启动、冷启动时间、⻚⾯切换、前后台切换、⾸字时间，
⾸屏时间等。
• ⻚⾯呈现是否完成⼀致。
• 超时⽂案是否符合定义，异常信息是否显⽰正常。
• 是否有超时重连。
• 安全⻆度：是否会发⽣dns劫持、登陆ip更换频繁、单点登陆异常等。
• ⼤流量事件⻛险：是否会在弱⽹下进⾏更新apk包、下载⽂件等⼤流量动作。

设计测试用例的方法

等价类

依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，如
果 这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达到尽量
多的 功能覆盖，解决了不能穷举测试的问题。

等价类分类：
• 有效等价类：对于程序的规格说明书是合理的、有意义的输⼊数据构成的集合，利⽤有效等价类验
证程序是否实现了规格说明中所规定的功能和性能
• ⽆效等价类：根据需求说明书，不满⾜需求的集合。

根据等价类设计测试⽤例的⽅式：

1.确定有效等价类和⽆效等价类
2.编写测试⽤例，设计具体测试数据
练习：根据学到的边界值将上述未完成的⽤例进⾏完善
缺点：等价类只考虑输⼊域的分类，没有考虑输⼊域的组合，需要其他的设计⽅法和补充。

边界值

边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对
等 价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。

边界值包含：边界值+次边界值

1. 输⼊框⻓度为1-11，取边界值为：1、11、12、0
2. 运动员的参赛项⽬为1-3项，取边界值为：0项、1项、3项、4项
3. 查询⾯⻚⾯有999⾏，每50⾏为⼀⻚，取边界值为：输出0⾏、1⾏、50⾏、51⾏、999⾏

正交法

通过等价类和边界值⽅法我们完成了部分⽤例的补充
当前还剩下⼀个场景的⽤例未补充完成，“只填写部分选项”，这⾥到底要设计多少测试⽤例呢？
通常来说，为了保证系统的测试覆盖率，我们⾸先能够想到的就是排列组合。
假如当前有两个选项A和B，可以设计出都填写、都不填写、填写A、填写B四个测试⽤例（2²）。
假如当前有三个选项A、B、C，通过设计可以得到8个测试⽤例（2³）
…
当前可选的选项是5个，分别是，姓名、电⼦邮箱、密码、确认密码、验证码。按照排列组合设计出
来的⽤例是32个…

正交法的⽬的是为了减少⽤例数⽬。⽤尽量少的⽤例覆盖输⼊的两两组合

可以使用allparis工具生成正交表

判定表法

需求中会存在各种各样的场景，现在我们把需求改成如下的要求：

⽤⼾输⼊的账号中包含admin字符，或者通过内部链接进⼊注册⻚⾯，提交注册按钮成为管理员⾝
份；反之⽆管理员⾝份。

通过这个需求可以看出，不同的组合操作可能对应不同的结果。采⽤正交法⽆法解决这样的问题。⽽
正交法能够解决需要考虑输⼊之间的组合关系对应不同结果的场景。

根据判定表法设计测试⽤例的步骤：

1. 确认需求中输⼊条件和输出条件
2. 找出输⼊条件和输出条件之间的关系
3. 画判定表
4. 根据判定表编写测试⽤例

场景法

通过运⽤场景来对系统的功能点或业务流程的描述，从⽽提⾼测试效果的⼀种⽅法。⽤例场景来测试
需求是指模拟特定场景边界发⽣的事情，通过事件来触发某个动作的发⽣，观察事件的最终结果，从
⽽⽤来发现需求中存在的问题。我们通常以正常的⽤例场景分析开始，然后再着⼿其他的场景分析。
场景法⼀般包含基本流和备⽤流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所
有的基本流和备⽤流来完成整个场景。场景主要包括4种主要的类型：正常的⽤例场景，备选的⽤例场
景，异常的⽤例场景，假定推测的场景。

错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从⽽
针对性地设计测试⽤例的⽅法。
这个⽅法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个⼈的经验和直觉。
错误推测法和⽬前流⾏的“探索式测试⽅法”的基本思想⼀致，这类⽅法在敏捷开发模式下的投⼊产
出⽐很⾼，被⼴泛应⽤于测试。