用例设计

1. 什么是测试用例，测试用例的基本要素？

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径 或核实是否满足某个特定需求。 测试用例的基本元素： 测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

2. 怎样写测试用例

在测试面试的过程中大多都会问到你是怎么来设计测试用例的刚开始的时候都会被问懵。

我们从两个方面来看怎么设计测试用例

1. 对于新手来说最简单的是从用户的角度来设计测试用例，即使之前没有接触过软件测试但是每个人的生活中都离不开”APP”。从用户的角度来讲，一个产品首先关注的当然是产品的功能，其次是兼 容性和稳定性，最后是容错能力。翻译成测试用户就是，首先写功能测试用例然后写兼容性测试用例 和稳定性测试用例，最后想想在测试过程中会遇到哪些异常，针对这些异常设计一些用例，来检验产品的容错能力。

2. 常用的用例编写的方法有边界值法、等价类划分法、功能图法、因果图等常用的编写测试用 例的方法。

3. 描述测试用例设计的完整过程？

首先根据需求文档、概要设计、测试计划、测试方案细分出各功能模块的测试项

再根据各测试项，按照概要设计、详细设计以及测试方案中测试的覆盖率细分出测试子项

最后按照测试子项、根据测试用例的设计方法（因果图、边界值、等价类等的设计方法）书写测试用例。

注意

1. 选用适合的用例管理工具（如 word，excel）
2. 用例一定要及时更新（补充新的想法，删除过时的需求）
3. 做好用例分级
4. 做好用例评审，写用例之前可以征询相关人员的意见，如果评审通过可以参考其执行测试，如果未 通过，需要继续修改直到通过为止。
5. 可以考虑结对编写，这个是不错的主意
6. 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等
7. 注意把握适当的颗粒度

4. 好的测试用例有哪些特点？

质量属性：

• 正确性：确保测试标题描述部分的内容正确性。
• 经济性：只为确定需要的目的设计相应的测试步骤。
• 可重复性：自我一致性，即不管谁执行此用例，结果一样。 适应性：既能适应短期需要，又能考虑长远需要。
• 可追踪性：用例能追踪到一个具体的需求。
• 自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。结构化和可测试性含有规范的测试标题和编号。含有一个确定的测试某一个特定需求的目的。含有关于测试方法的描述。

指定条件信息 - 环境、数据、预置的条件测试、安全入口等。含有操作步骤和预期结果。

陈述任何辅助证据，例如截图报告并确保这些东西妥善保存。 确保测试环境的干净（即用例不会影响整个环境）。

描述时使用主动语气结构。操作步骤不要超过 15 步。

确保单个用例测试执行时用时不超过 20 分钟。

自动化脚本用例添加必要的注释，比如目的、输入和期望结果。 如果可能，建议提供可选择性的预置条件测试。

用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。

配置管理：

• 采用命名和编号规范归档。
• 保存为特定的格式，文件类型。
• 用例版本是否与当前被测试软件版本一致（对应）。包含用例需要的相应测试对象，如特定数据库。
• 存档阅读。

5. 测试用例制定的原则？

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测 试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：

1. 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2. 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3. 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4. 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5. 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
6. 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据 / 非法数据，主要在边界值附近选取。
7. 压力测试：输入 10 条记录运行各个功能，输入 30 条记录运行，输入 50 条记录运行。进行测试。
8. 等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
9. 错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
10. 效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
11. 可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
12. 可移植性：在不同操作系统及硬件配置情况下的运行性。
13. 回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员已经解决，进行 下一轮的测试。
14. 比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较 。

6. 测试用例是否纳入测试基线管理？测试用例发生变更的流程？测试用例如何进行标识？

是。测试用例没有变更流程

测试用例的标识为 ST-001 这种格式标识

7. 什么时候编写测试用例？依据是什么？如何保证测试用例与需求的一致性？需要同行评审吗？

在测试计划完成之后，按照计划进度编写测试用例。依据是软件需求规格说明书通过同行评审来对用例进行评审，需要同行评审

8. 测试用例如何设计的？

在测试用例的设计之前首先要仔细阅读开发的详细设计文档，充分了解产品的详细功能，不清的 地方与开发人员进行沟通，搞懂每个功能，尽量详细到输入框、按钮等小功能，功能点清楚之后按照 功能模块分类进行用例编写。在具体的用例设计中会运用到等价类边界值等黑盒测试方法

9. 如何保证用例覆盖到罕见缺陷？

1. 充足的设计时间
2. 充分的需求分析
3. 每一个功能点都有用例覆盖
4. 严格的评审流程
5. 保障输出都是有效的
6. 在测试执行过程中，会根据实际的项目情况，对用例做增加和修改

10. 什么时候编写测试用例？依据是什么？如何保证测试用例与需求的一致性？需要同行评审吗？

在测试计划完成之后，按照计划进度编写测试用例。

依据是软件需求规格说明书通过同行评审来对用例进行评审，需要同行评审

11. 写测试用例时要注意什么问题

1. 复用率：如果随着产品不停得升级，需要设计的详细些，追求一劳永逸；仅使用一两次，则没有必要设计的过于详细；
2. 项目进展：项目时间如果允许可以设计的详细些，反之则能执行即可；
3. 使用对象：测试用例如果供多人使用，尤其让后参加测试的工程师来执行，则需要设计的详细些。
4. 用例的冗余
5. 操作步骤要细分简明，可执行

12. 如何在有限的情况下提高测试效率，保证产品的上线质量？

1. 一个详细合理的详细的测试计划
2. 测试尽早的介入项目，连接项目的业务需求，做好测试的前期准备
3. 对测试项目前景充满信心，调整最佳心态，保持愉悦的工作心情
4. 提高测试接受的标准，减少测试版本的送测次数

13. 如何降低漏测率

1. 需求评审
2. 梳理需求，尽早与开发人员、需求人员进行需求确认，统一不同角色对需求的认识
3. 用例设计及评审
4. 测试执行
5. bug 回归
6. 发布前的功能回归

14. 测试用例的基本设计方法

1. 等价类划分法
2. 边界值分析法
3. 错误推断法
4. 因果图判定表法
5. 正交实验法
6. 流程法
7. 场景法

15. 测试为什么要写测试用例

1. 深入了解需求的过程
2. 测试执行的指导
3. 规划测试数据的准备
4. 反应测试进度
5. 举一反三发现隐藏缺陷
6. 分析缺陷标准