软件测试——用例

黑盒测试用例从设计方法

测试用例

测试用例的四个要素：测试环境 操作步骤 测试数据 预期结果
评价测试用例的标准：对比好坏用例的评价标准

1. 用例表达清楚，无二义性
2. 用例可操作性强
3. 用例的输入与输出明确
4. 一条用例只有一个预期结果
5. 用例的可维护性好。
6. 用例对需求的覆盖率高。

基于需求的设计方法

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计；
需求文档——>梳理需求——>针对文档设计测试用例
在分析测试需求时，一般分为功能测试需求和非功能测试需求

功能需求测试分析
对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以下，通常包括以下几个方面。
（1）系统各个功能界面的验证
（2）借助业务把功能串起来进行测试
（3）功能的一致性，交互性（多功能互操作）的测试
（4）系统的不同输入，结果输出的业务数据测试。
（5）功能的错误操作，异常操作的测试（属于负面测试）
（6）功能实现用到的算法验证，有时需要用运代码评审
（7）用户操作的易用性，用户体验，往往结合功能测试同时验证
非功能需求测试分析
非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分
析。
（1）纯客户端软件，比如字处理软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）
等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。
（2）企业内部的客户端/服务端（C/S)应用系统。比如电子邮件，即时通信系统（飞Q，企业QQ）等，
在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全
性，兼容性要求不高。
（3）外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

例如：
163邮箱注册
功能相关：业务流程相关 界面 易用性
非功能相关：兼容 性能 安全 网络

等价类

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

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

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

超市买水果
有效等价类：苹果、桃子、梨
无效等价类：青菜、米、饮料，…

以上述的需求为例：
|用户名 | 必填，录入用户名 | 6至15 | 字符类型A-Z,不区分大小写|
用户名由长度为6-15位的字符串组成，那么针对字符有效等价类为A-Z,a-z，无效等价类为两个：数字：1，
0.1，-1 特殊字符：@，#，￥，空格
有效：6~15位
无效：小于6位 大于15位

等价类思想设计测试用例步骤：
1.理解需求
2.划分有效与无效等价类
3.从有效和无效等价类中抽取一个设计等价类

边界值

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

用户名由长度为6-15位的字符串组成

上点：边界上的点 6 ，15
内点：边界内的点 13
离点：边界附近的一个点 5 ，16

边界点思想设计测试用例步骤：
1.理解需求
2.找边界点
3.针对边界点设置测试用例

判定表法

1.定义
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
2.判定表的优点
能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
3、判定表有几个要素
1)条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
4、判定表的设计步骤

1. 明确条件桩
2. 明确动作桩
3. 对条件桩进行全组合
4. 明确每个组合对应的动作桩
5. 设计测试用例，每列数据对应一条测试用例