设计测试用例

目录

测试用例的基本要素

测试用例的设计方法

功能需求测试分析

非功能需求测试分析

设计测试用例的具体方法

---

测试用例的基本要素

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

一个优秀的测试用例可以使一个不熟悉业务的人也能依据用例很快的来进行测试。

评价测试用例好坏的标准：

• 用例表达清楚，无二义性

• 用例可操作性强

• 用例的输入与输出明确，一条用例只有一个预期结果。

• 用例的可维护性好。

• 用例对需求的覆盖率高

测试用例的设计方法

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

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

在分析测试需求时，一般分为功能测试需求和非功能测试需求。

功能需求测试分析

对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试通常包括以下几个方面：

1. 系统各个功能界面的验证。

2. 借助业务把功能串起来进行测试。

3. 功能的一致性，交互性（多功能交互操作）的测试。

4. 系统的不同输入，结果输出的业务数据测试。

5. 功能的错误操作，异常操作的测试（属于负面测试）。

6. 功能实现用到的算法验证，优势需要运用代码评审。

7. 用户操作的易用性，用户体验，往往结合功能测试同时验证。

针对具体的需求，可以根据业务分类，用户角色或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分是最常见的做法。

非功能需求测试分析

非功能测试需求主要涉及性能、安全性、可靠性、兼容性、易维护性和可移植性等方面。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性、性能带来更大的挑战。

需要补充的是，对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体项目、具体需求和不同产品应用的特点进行分析。

• 纯客户端软件，例如字处理软件（Word，PPT），媒体（视频/音频）播放软件（电脑自带的）等软件，这类软件对系统的功能测试要求是最低的，但是对兼容性、稳定性和可移植性有一定的要求。

• 外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复 杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

设计测试用例的具体方法

• 等价类

  等价类分为有效等价类和无效等价类。

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

  无效等价类：根据需求说明书，不满足需求的集合。

• 边界值

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

  举个例子

  输入框要求长度为1~11，那么我们就可以取边界值为：1、11、12、0

  运动员的参赛项目为1~3项，那么我们就可以取边界值：0项、1项、3项、4项

• 正交排列

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

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

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

• 场景设计法

  现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触 发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者 设计测试用例，是测试用例更容易理解和执行。 典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功 能细节忽视业务流程要点的错误倾向

• 错误猜测法

  错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针 对性地设计测试用例的方法。 这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。 错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比 很高，被广泛应运于测试。 这个方法的缺点是难以系统化，并且过度依赖个人能力。

设计测试用例万能公式

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

功能测试：可能来自于需求文档，也可能来自于生活经验。

性能测试：功能没有问题不代表性能一定是好的，性能往往表现在一些极端情况下。

界面测试：颜色、形状、大小、材质、文字、输入框、图片、下拉框...所有可以看到的元素。

兼容性测试：浏览器的兼容性、版本兼容性、系统兼容性、数据兼容性......

易用性测试：软件是否具备简单易上手的属性。

安全测试：隐私数据是否加密，能否防止SQL注入，是否存在越权问题。

兼容性测试里需要注意：

不同的浏览器，不同的版本，可能会有非常多，难道所有的版本和浏览器我们都需要测试吗？我们选型的标准是什么？

答：不是所有的版本和浏览器都需要测试，这是无法实现的。

1、大部分用户使用的

2、在工作中是有数据后台可以监测到大部分用户使用的浏览器、版本、手机型号