公司模板软件测试用例设计指南
| 项 目 签 名 日 期 产品型号及名称 （图册编号） 设 计 校 对 审 核 第 张 共 张 标准化 空司通信修配厂制 批 准 |
1 目的
本文的目的是为软件测试用例设计提供指导，提高软件测试用例设计水平。
2 适用范围
3 职责与术语
3.1 术语表
3.2 参考资料
4 工作程序
测试用例设计必要性
测试用例设计就是将软件测试的行为活动，做一个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的，设计软件测试用例的目的就是为了能将软件测试的行为转换为可管理的模式。 软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。
使用测试用例的好处：
下面我们从理论技术、管理方法、通用结构、选择策略四个方面循序渐进的介绍如何编写测试用例，将无序的测试行为转变为可控、有序、高质量的测试活动的过程。
4.1 测试用例设计方法
测试包括黑盒测试和白盒测试。黑盒测试用例方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交实验法、功能图法、场景法等。白盒测试方法包括代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法等。
目前系统测试过程多为黑盒测试，下面将重点介绍等价类划分法、边界值分析法、错误推测法、场景法。这些方法是比较实用的，在使用时要针对开发项目的特点对方法加以适当的选择。
4.1.1 等价类划分法
等价类划分法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。等价类划分有两种不同的情况：有效等价类和无效等价类。
设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。
下面给出等价类在五种情况的划分原则：
| 输入条件 | 有效等价类（个） | 无效等价类（个） |
| 规定了取值范围或值的个数 | 1 | 1 |
| 规定了输入值的集合或者规定了“必须如何”的条件 | 1 | 1 |
| 输入条件是布尔量 | 1 | 1 |
| 规定输入数据的一组值（n个），并且程序要对每一个输入值分别处理 | n | 1 |
| 规定输入数据必须遵守的规则 | 1 | 违反规则可能数 |
4.1.2 边界值分析法
测试经验得知：大量的错误是发生在输入或输出范围的边界上，而不是输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。边界值是指对于对于输入等价类和输出等价类，稍高于其边界值及稍低于其边界值的特定情况。
使用边界值分析方法设计测试用例，首先应确定边界情况，选取正好等于、刚刚大于、刚刚小于边界的值做为测试数据。
下面给出边界值选择方法：
| 输入条件 | 边界值 |
| 规定了取值范围 | 刚刚达到这个范围的边界的值 刚刚超越这个范围的边界的值 |
| 规定了值的个数 | 最大个数、最小个数、比最大个数大1 比最小个数小1 |
| 输入\输出域是有序集合 | 集合的第一个元素和最后一个元素 |
| 程序中的内部数据结构 | 内部数据结构边界上的值 |
| 软件要求输入 | 没有输入任何信息，默认值 |
4.1.3 错误推测法
错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误，有针对性的设计测试用例的方法。
基本思想：列举出程序中所有可能有错误和容易发生错误的特殊情况，根据它们选择测试用例。 例如，设计一些非法、错误、不正确和垃圾数据，特别是在以前产品测试中曾经发现的错误进行输入测试是很有意义的。
4.1.4 场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发式的情景形成了场景。
相同事件组不同的触发顺序和不同的处理结果形成不同的事件流，包括基本流和备选流。不同事件流构成不同的路径。场景法测试用例就是执行所有路径。
对于业务流程清晰的系统，利用场景法贯穿整个测试案例过程。
4.1.5 测试方法综合运用
不同类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，在实际的测试用例设计中，会根据软件特点综合使用各种方法。面对我们的行业软件，如何选取和运用测试方法，有效的提高测试效率和测试覆盖度，是软件测试经理需要考虑的问题，下面是对于业务流程清晰的系统，功能测试方法综合策略 ：
场景法为主线，等价类法控制数据流，边界值作为节点必须考察，进行错误推测，对照程序逻辑补充测试用例。
方法步骤：
（对相关功能项的连续操作形成了场景，每个功能项的不同输入数据形成了多个分支，正常数据形成基本流，非正常数据形成备选流。）
注：以上为测试用例设计过程，是在测试需求已识别后进行的。对于业务流程清晰的系统可统一参照以上综合方法。
除了进行功能测试，易用性测试要贯穿始终。易用性测试主要分两大类：界面易用性测试和流程易用性测试。界面易用性测试是测试技术中相对简单的工作，业界有统一易用性标准，对于有实力的软件生产商通常有自己的产品界面标准。测试人员只需将这些标准汇成表格，逐条检查。因此界面易用性测试通常作为测试新手入门工作。
流程易用性测试对测试人员要求较高，要求对行业流程和客户习惯非常熟悉，必要时可邀请客户方参与流程易用性测试。
4.1.6 性能测试用例设计方法
性能测试用例设计的首要条件是性能指标和其应用场景的识别，一般的性能指标分为单用户或者多用户并发时的响应时间、响应成功率，同时要考虑的环境因素如下：
根据不同的环境下的性能要求确定出具体的测试周期，需要测试的次数，监测的资源使用情况、响应时间的峰值、平均值、成功率。
确定出7*24小时稳定性测试的测试环境、数据规模、测试周期，监测资源使用情况、响应时间的峰值、平均值、成功率。
兼容性测试、安全测试根据具体的需要分别执行。
4.2 测试用例管理
4.2.1 测试用例文档
软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，为实现用例的连贯性和数据流转方便，通常还会以该产品的业务流为单位，形成测试用例文档。
测试用例文档由测试说明和测试用例两部分组成。测试说明需要包含如下内容：软件名称、版本、功能模块、编制人、编制时间、维护日志、文档标识、环境要求、测试目的、测试范围、定义术语、参考文档、概述等。根据测试角度不同，测试用例文档的测试用例部分被划分多个测试分支，每个测试分支包含各测试用例。
4.2.2 测试用例基本元素
一个测试用例基本项包括输入的实际数值、条件与预期结果。
除以上基本信息外，每个具体测试用例一般包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、出口准则、注释等。
4.2.3 测试用例维护
测试用例能够不断完善的重要前提是存在统一的测试用例库，如果测试用例是以单个任务为单位一次性编写的，几乎没有重复利用的可能，对于市场缺陷的反馈得不到积累，软件新增功能和完善的测试用例与原用例没有联系。测试水平难以提高。因此，对于一个相对稳定的软件产品，测试组从一开始就应筹备建立测试用例库，并随着下述三方面的触发不断维护更新：
对于市场缺陷，除了弥补测试用例库漏洞外，应分析总结在测试方法上的设计缺陷问题，形成测试用例检查单，为日后的测试用例设计提供参考。
4.2.4 测试用例评审
测试用例是软件测试的准则，是测试行为有效性的重要前提，如同开发设计一样，测试用例设计是设计者的思维作品，存在漏洞风险，需要进行评审，评审通过后才可以使用。
测试用例评审根据被测软件功能风险和功能复杂度分为2个级别：伙伴检查和专家评审。伙伴检查由测试用例编写人提交给同软件开发组的测试负责人或设计负责人评审。专家评审由测试用例负责人提交评审委员会负责，评审委员会由项目经理、设计负责人、编码人员、测试经理、行业客户代表组成。
4.2.5 测试用例管理工具
最好使用测试用例管理软件协助管理测试用例。使用工具的好处有：
如果能够将测试需求和测试用例、测试执行、缺陷跟踪集合到一个工具里，测试人员无论是跟踪测试需求、还是出软件测试报告、进行度量分析，都会变得轻而易举。目前业界广泛使用的测试管理工具有：TD、TestCenter
4.3 测试设计过程
4.3.1 测试需求
在需求明确后，开发人员提供评审后的需求规格说明书作为测试依据。测试人员通过分析需求规格说明书提取测试需求。测试需求包含以下几类内容：
业务流程，本次需求包含的基本业务流程和分支。
测试人员明确以上测试需求，并在测试方案中指明具体内容和测试方法。测试需求明确后，进行测试用例设计。
4.3.2 测试用例
测试用例文档一般以需求点或功能模块或业务流程划分。可以说一个测试用例文档就是一个相对独立的测试过程的指导文件。对于一个相对独立的测试过程，一般的测试用例设计思路如下：
常见考察点：
| 1、界面布局合理性:输入框大小一致，左右对齐，不存在显示不全的情况。 |
| 2、回车键:能够控制输入焦点的顺序移动：从左到右，从上到下。 |
| 3、tab键:能够正确控制输入焦点的移动顺序：从左到右，从上到下。 |
| 4、快捷健:常用按钮要支持快捷键，对快捷键进行检查。 |
| 5、焦点获取：可输入控件检测到非法输入后应给出说明信息并能自动获得焦点。 |
| 6、帮助菜单：帮助菜单的“关于”中的版权和产品信息是否与实际一致。 |
| 7、界面自动调整：界面的最大化、最小化，在不同分辨率下是否能够自动调整。 |
| 8、恶意破坏：任意无序的破坏性打开多个界面，考察是否有显示错误。 |
常见考察点：
| 1、增加一条记录，点保存，看是否正确。 |
| 2、增加多条记录，考察对批量的处理是否易用；点保存，看处理是否正确，响应时间是否在可接受范围。 |
| 3、不增加记录，直接点保存。 |
| 4、增加一条记录-保存-修改-保存-删除，考察每步，且删除后没有记录。 |
| 5、重复记录输入考察，输入主键相同的记录。 |
| 5、连续删除多条记录。 |
| 6、空记录时查询数据。 |
| 7、对于需要多页显示的多条记录进行查询，考察首页、末页数据。 |
| 8、查看操作日志记录是否完整。 |
| 9、按照权限分类逐项检查。 |
| 10、必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*；增加和修改时对必填项的控制是否一致。 |
| 11、可输入编辑框的边界值的考察，包括数值、字母、特殊字符、超常输入、空。 |
| 12、查询检查: 在有查询功能的地方输入系统存在和不存在的内容,看查询结果是否正确.如果可以输入多个查询条件,可以同时添加合理和不合理的条件,看系统处理是否正确。 |
常见考察点：
| 1、两个客户端同时增加记录。 |
| 2、两个客户端查询出同一条记录，修改后同时保存。 |
| 3、两个客户端查询出同一条记录，同时删除。 |
| 4、两个客户端查询出同一条记录，一个先删除，另一个再点保存记账。 |
| 5、两个客户端查询出同一条记录，一个修改或删除，另一个通过上一条和下一条回退。 |
常见考察点：
| 1、名称易懂：菜单、按钮、标签的名字应具有自解释性。难理解的名字和操作步骤要有明确的指导。（避免使用晦涩难懂的名称。按钮、标签名称、选项条目、操作等难理解的都要在相关显要位置做简捷易懂的说明） |
| 2、布局合理：重要的命令按钮与使用较频繁的按钮要放在界面上引人注目的位置。（例如：常用功能不能隐藏起来，应该在当前界面中可视，不能通过右键或多重菜单方式展现。） |
| 3、输入控制：对可能引起致命错误或系统出错的输入要及时屏蔽或处理，避免客户重复劳动。尽量避免用户做出有悖正常业务流程或没有意义的操作。（例如：用户输入错误的位置及时提醒，不能在全部信息输入完成后才提示，然后大部分信息又要重复输入。对于系统不能处理的流程应控制用户不能操作，不能依靠用户自己控制。） |
| 4、操作简便：对于用户的关键操作都应有所回应。能用一步操作完成的尽量不做分步处理。有关联的业务操作间要有操作方向提示。（用户操作后系统应有相应的动作反馈给用户，让用户确认自己的操作有效。例如重要操作提示操作成功，菜单界面的快速变化，长时间操作提供进度条或状态图标等。简化用户操作步骤，除必须的人为干预外尽量使用系统完成。） |
| 5、提示明确：错误提示要明确出错原因；对可能造成数据无法恢复的操作必须提供确认信息，给用户放弃选择的机会。（增强用户自我恢复机制，如果所有操作都可恢复就不用确认提示了，对于目前无法做到恢复的功能都必须给出确认提示框，根据操作概率确定默认焦点放在 确认 还是 取消）。 |
以上项目为测试用例文档中必包含项目。
| 1、客户端从联网到断网。 |
| 2、客户端从断网到联网。 |
| 3、通讯服务器从联网到断网。 |
| 4、通讯服务器从断网到联网。 |
| 5、网络时断时联。 |
| 6、通讯过程中断网。 |
| 7、通讯开始时就断网。 |
10、兼容性测试：考察软件在需求中已承诺的不同的软硬件和网络环境下是否能够支持，常见考察点如下：
| 1、低端硬件配置下运行系统。 |
| 2、推荐配置下运行系统。 |
| 3、不同的操作系统下运行系统。 |
| 4、不同的网络环境：局域网、拨号、宽带等。 |
| 5、从低版本升级后运行系统。 |
| 6、重新安装运行系统。 |
| 7、通讯开始时就断网。 |
11、更新包和整个版本检查：对于完整的产品的测试除了以上测试检查外还要进行安装卸载测试和用户说明书等文档测试。
4.4 测试用例选择策略
在实际测试活动中，我们经常遇到这样的情况：软件的需求规格说明和设计不是
很详尽甚至没有；受市场影响急需完成不可能完成全部功能的测试任务；测试用例设计的详细程度难以确定。这就需要我们在实际的测试设计中掌握一定的策略。
4.4.1 可测性转化
当面对三无产品（无需求规格说明书、无详细设计、无用户手册）时，测试人员首先要对产品进行可测性转化。可测性转化分为四步骤：
- 。预期结果：处理结果。
在做可测性转化过程中测试人员除了调查软件在正常情况下的处理外，还要特别了解软件在各种异常情况下的处理结果。时刻提醒自己测试行为是要考察软件做该做的事，不做不该做的事。
4.4.2 软件功能风险
测试的六大原则之一是测试需要终止。在有限的时间和资源内，我们不可能将全部测试分支识别出和测试完成。所以测试要有针对性，根据测试活动的目的是保障软件系统在客户处运行的可用性和可靠性。我们通过软件功能风险级别来确定测试的重点和优先级。
软件功能风险的定义，从以下几方面综合考虑：
每项定义4个级别 a\b\c\d
推荐做如下风险级别定义：
- 级高风险功能：两个a以上
- 级中风险功能: 两个b以上
- 级低风险功能：其他
4.4.3 测试范围：深度和广度
通过软件功能风险级别定义，我们明确了测试的重点，那么对不同级别的功能将如何进行不同的测试设计？需要定义测试任务的深度和广度。
测试广度：识别出的测试需求功能考察点集合。
测试深度：5级
- 级深度为等价类划分
- 级深度为边界值
- 级深度为错误推测
- 级灰盒测试
- 级白盒测试
对应到业务逻辑清晰的应用软件
- 、正常流程 常规数据
- 、正常流程 边界数据
- 、非正常流程异常处理
- 、比对数据库中间过程
- 、对照程序分支检查测试遗漏分支
对应不同的软件功能风险级别，一般做如下的测试广度、深度安排：
- 高风险功能—3级深度 100%广度
- 中风险功能—2级深度80%广度
- 低风险功能—1级深度60%广度
4.5 测试用例执行
4.5.1 测试用例执行流程
4.5.2 测试用例执行结果记录
1、功能测试用例
2、性能测试用例
3、稳定性测试用例
5 质量记录
测试用例模板
6 相关文件
| 文件名称 | 文件编号 | 备注 |