功能测试之软件测试用例的理论-编程知识

用文字描述出系统测试时的操作步骤，或许有些帮助

写测试用例好处

1）清晰思路、避免遗漏

当系统功能多且复杂时，根据系统每个模块，拆分功能点，花点时间思考并整理成文档，尽可能结合功能与业务，模拟不同场景，从根本上避免了直接测试系统的“手忙脚乱”。

2）明确测试进展

参考测试用例，可以清晰看到哪些用例执行了，哪些用例没有执行，从中看到测试进行到哪一步，以及结合问题管理平台，直观地从测试角度，分析项目进展。

3）系统模块缺陷率

根据测试用例发现的问题，可以看到哪个功能模块出现的bug较多。

设计方法

1）等价类划分

策略：将输入值划分为相互等价的类别，并选择一个测试用例来代表每个等价类。

描述：通过代表性测试用例覆盖每个等价类，以减少冗余测试。

示例：假设有一个登录页面，有用户名和密码两个输入框。可以将用户名输入划分为等价类：合法用户名、空用户名、非法用户名；将密码输入划分为等价类：合法密码、空密码、非法密码。然后从每个等价类中选择一个测试用例进行测试，例如选择合法用户名和合法密码的组合。

2）边界值：

策略：关注输入值的边界情况，即最小值、最大值和接近边界的值。

描述：测试边界值和接近边界的特殊情况，因为边界处常常存在错误。

示例：假设一个函数接受一个整数参数，范围是1到100。选择边界值和接近边界的测试用例，例如选择1、2、100、101作为输入值，以覆盖边界值和接近边界值的情况。

3）判定表

策略：根据系统的决策逻辑和条件组合，设计判定表以生成测试用例。

描述：将系统的条件和相应的动作组织成表格形式，然后根据条件的组合选择测试用例。

示例1：假设有一个根据温度和湿度来判断天气的决策表。表格中的条件包括温度和湿度的范围，动作是天气的判断。设计测试用例以覆盖不同的条件组合和对应的动作。

4）因果图

策略：通过绘制因果图，可视化系统功能和输入之间的因果关系，进而设计测试用例。

描述：考虑系统功能之间的因果关系，从而设计测试用例。

示例：假设有一个电商平台，用户根据价格和评级来筛选商品。绘制因果图以显示价格和评级作为输入条件，以及筛选商品作为输出结果。设计测试用例来覆盖不同的价格和评级组合。

5）错误推测法

策略：基于测试人员的经验和直觉，推测可能存在的错误，并设计测试用例来验证这些猜测。

描述：测试人员根据过去的经验和知识，推测可能存在的错误，并设计测试用例来尽可能多地验证这些猜测。

示例：假设有一个电子邮件发送功能，测试人员可能猜测错误的情况包括：发送空邮件、发送带有特殊字符的邮件、发送超过限制大小的邮件等。设计测试用例来验证这些错误情况。

6）场景法

策略：基于实际使用场景来设计测试用例，考虑用户的实际操作和使用情况。

描述：设计具有代表性的场景和相应的测试用例，以模拟真实的使用情况。

示例：假设有一个在线购物网站，设计场景如下：用户登录、浏览商品、加入购物车、结算订单。然后设计相应的测试用例来模拟这些场景。

7）正交法（不常用，需了解）

策略：使用正交表格设计测试用例，以覆盖系统不同的输入组合。

描述：通过选择一组正交表格，确保在最少的测试用例下覆盖尽可能多的输入组合。

示例：假设有一个控件如下案例。通过使用正交表格，选择不同的字体、字符样式、颜色、字号的组合进行测试。

常用正交设计表-举例

案例：字符属性设置程序
窗体中有多个控件（字体、字符样式、颜色、字号），每个控件有多个取值

字体：仿宋、楷体、华文彩云
字符样式：粗体、斜体、下划线
颜色：红色、绿色、蓝色
字号：20号、30号、40号

步骤：
1、根据控件和取值数选择一个合适的正交表；

根据分析可知，该案例有4个控件，每个控件有3个取值。所以我们可以组合3^4 = 81个组合，那么在常用的正交表中，我们可以选择此表，那么本来要81个组合测试才能测得完的用例，根据正交表设计法，只需要进行9次测试即可。所谓，使用最小的测试过程集合获得最大的测试覆盖率。

2、列举取值并编号，生成取值表；
接下来对控件和控件的取值进行排序，生成取值表：

3、把取值表与选择的正交表进行映射；
根据取值表和所选择的正交表进行编号进行映射，生成以下的实际测试用例：

元素

1）目录

根据拆分的系统功能点，每个功能点可以用目录的方式区分，如一个系统的系统管理-用户管理-用户添加，那么系统管理就是一级目录，用户管理就是二级目录，用户添加就是三级目录；

2）测试项

同上，根据三级目录，一般用户添加包括的元素有用户名、密码输入框、保存按钮、取消，那么每个元素都可以分成一个测试项；

3）操作步骤

每一个测试项，都对应相应的操作步骤，可以分成操作步骤1、操作步骤2，操作步骤可以细化到，点击添加用户的按钮、输入框输入某某用户名密码点击保存按钮；

4）预期结果

操作步骤，在完成一系列动作之前，都要有对应预期结果作为参考，这个参考就是最初业务部门提供的需求分析文档，根据需求分析文档来告诉我们每一个功能要有什么样的结果；

5）实际结果

操作步骤，完成之后，需要记录实际的情况，如果与预期结果不符，就可以归于bug；

考虑是否可以将实际结果改成注释，避免与预期结果一一对应关系，解耦合。

6）优先级探索性测试

在设计测试用例时，并不能完全保证每个功能每个场景都设计到位，而且单纯执行测试的时候非常枯燥，那么加入一点发散性思维，进行一些非常规性操作，以用户的心态去使用系统，或是尽情地“破坏”系统，发现系统的问题。

真正的探索性测试需要对产品的深入了解，以及软件开发技术有一定的深度和宽度。

用例评审

测试用例编写完成后，需要在测试内部进行一次评审，评审的内容包括：功能是否完整、需求是否符合，使每一个测试人员在系统测试过程中，不存在主体思维的偏差。

同时用例评审也是一个很好的学习过程，每一位测试人在介绍系统时，能够意识到各自设计用例时的不足，包括自动化、性能都可以进行技术的探讨。

不需要用例情况

1）功能过于简单

2）急于交付，弊端就是不能保证测试的覆盖率。

弊端

用例粒度

　　用例粒度好比一个剧本，写细了容易束缚了表演者的自我发挥，写粗了又担心表演者遗漏某些重要环节。
　　如果你是一家传统软件公司，一个项目可能几个月甚至半年、一年才一次交付，那么你拥有充足的时间去设计你的测试用例，那么我建议你的用例能尽可能描述详细，不停的修复、补充、完善。
　　然而在大多数互联网公司，基本都走敏捷，讲究小步快跑，快速试错，基本上产品迭代非常频繁，譬如一个公司的产品两周一个迭代。
　　这给我们测试留下的执行测试的时间就极短，更别说写用例的时间，这时我们就不得不在某种程度上做个妥协，简化测试用例，不再对每一条用例做详细描述，而更多的是写测试点。
　　遇到比较复杂的流程时，还是希望能尽可能将用例描述详细。测试点不表示不需要考虑各种用户场景，而是尽可能通过一句话能描述出这个场景的概要，这样测试人员在了解需求的前提下通过这么一句话概要就可以清楚知道需要执行那些用例，这对测试员的要求会相对更高点。　　