测试过程--编写测试用例

1、定义：什么是测试用例

测试用例（Test Case），就是为了验证某个需求是否实现、是否存在缺陷，在测试执行之前设计的一套详细的测试方案，指导后续的测试过程。 体现测试方案、方法、技术和策略。

测试用例的元素

• 测试目标：Why——为什么而测？功能、性能、可用性、容错性、兼容性、安全性等。
• 测试对象：What——测什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等。
• 测试环境：Where——在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议等单机或网络环境。
• 测试前提：When——什么时候可是测？测试用例运行时所处的前提或条件限制。
• 输入数据：Which——那些数据？在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。
• 操作步骤：How——如何测？执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等。
  概括为 5W 1H。

2、为什么需要测试用例

可以不编写测试用例直接进行测试，但这样是有风险的，不能够保证全面覆盖。另外，编写测试用例的其他作用：

（1）了解需求的过程
在编写用例的过程中，将仔细梳理整体业务流程、充分思考产品需求的细节，找出需求是否存在不合理、有矛盾、不明确等问题，从而推动BA/UX完成更加详细的设计。

（2）理清测试思路及测试过程

测试用例的编写，实际上是把需求转换为一种可操作步骤的行为。QA也没有那么强大的大脑能够把所有的操作步骤都记在脑海里，写下来不仅能帮我们记住，写下来的这个过程也是梳理测试思路的过程。特别是，当你将当前需求的用例都罗列出来时，也能很清晰规划之后的测试顺序。

（3）规划测试数据的准备

我们可以看到，在测试实践中，测试数据是与测试步骤分离的。在测试执行前，按照测试用例准备一组或若干组测试数据，特别是一些需要其他人协助准备的测试数据，这十分有助于高效的测试执行工作。

（4）记录测试所覆盖的测试内容，同时反应测试进度

依照测试用例执行测试，并及时记录每一个测试用例的测试结果，这样项目成员都能够清楚地了解到目前已经完成了哪些测试，这些测试覆盖了哪些需求。那么在一些突发情况下，比如你被调离或离职，别人也能迅速了解测试覆盖内容及测试进度。

（5）为后续的测试提供可参考的依据

新加入的功能可能会影响已有功能，新的需求是对原来的功能进行优化，新版本要上线等，项目进行过程中有这很多情况，都需要QA进行回归测试，有了测试用例，回归测试就能按部就班进行。

（6）是分析缺陷的标准

测试用例并不是一写完就再也不用更新了。通过记录的缺陷数据，与测试用例进行对比，分析是否存在漏测情况，即当前测试用例是否能够覆盖该缺陷，若未能覆盖，说明当前测试用例集不完善，应补充相应测试用例；若已有相应测试用例，则表明测试执行过程中存在问题。

（7）指导测试过程
可以帮助实施有效的测试，所有被执行的测试都是有意义的，不要执行毫无意义的测试操作；另外测试用例也是知识积累的过程、一个知识传递的过程，能保持一致、稳定的测试质量。

简单来讲，测试用例能够帮助我们在测试执行前澄清需求、检验需求、梳理测试过程，并提前规划好测试数据；在测试执行中作为清单使用，记录测试覆盖的内容、反应测试进度；测试执行后也能作为回归测试等的参考，能与缺陷记录结合分析，来不断完善测试用例本身。

3、设计测试用例

测试人员的水平主要体现在测试用例的设计上。 要设计出全面，覆盖广的测试用例，需要测试人员对自己所测试的项目的业务需求非常熟悉，甚至要比开发人员或产品人员还要熟悉。有以下方法使自己更熟悉需求：

• 熟读功能需求文档， 任何有疑问的地方都要去和PM确认。
• 把自己当成最终用户， 经常使用自己所测试的软件。模拟用户的行为。
• 熟记软件的每个功能。

3.1 如何设计一个好的测试用例

在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，接着分析出每个软件功能需求点对应的多个测试需求点，然后再针对每个测试需求点设计测试用例；最后挖掘隐性需求，覆盖非功能测试层面

具体到测试用例设计本身的设计，两个关键的点：

1. 从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，只有深入理解被测试软件的架构，你才能设计出”有的放矢“的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
2. 对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。

3.2 测试用例设计原则

1、测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
**2、测试结果的可判定性：**即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
3、测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

3.3 把握测试用例的粒度

测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。测试用例写得过于简单，则可能失去了测试用例的意义 。
我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

3.4 常见测试方法

黑盒测试方法

4. 测试用例写作说明

1. 用例编号
2. 标题
也称测试点、检查点、测试概述、用例概述、测试说明；最好看到这句话就能知道如何测试。一般用一句话对测试用例进行概述，达到总结测试目的；
可以用疑问句表示；可以用 检查、验证、测试 等字眼（如验证 QQ 默认安装）；
尽量唯一（决策表可能会有重复的测试说明）；
用例执行多轮时，越往后执行可能越快，如果用例写得好，直接看概述就行。

3. 初始（前提）条件

• 初始条件要是一个状态，而且是静态的，如管理员已登录后台；
• 初始条件是第一步操作步骤之前的状态，不能太远，不用从头写到尾

4. 操作步骤

• 若对数据要求高，需要把数据分离出来；
• 步骤要都有序号；
• 每一步用分号分开，最后用一个句号；
• 每一步必须换行；
• 参数前加冒号（如用户名：admin）；
• 涉及按钮界面用【】、“”等成对符号间隔；
• 功能的详细用例步骤 4-6 步左右；
• 最后一步一定是个动作，不能写结果。

5. 预期结果

• 是一个状态；
• 如果参考文档中有描述，原封不动的抄过来；如果文档中没有具体要求，则点要一致，可以有几个点，如 QQ 默认安装，应能启动、默认选项匹配等。

6. 用例状态

• 通过、失败、阻塞、未执行、搁置、无效用例…
• 初始条件达不到时，一般用例状态设置为阻塞。
• 看如何执行用例，执行完关心什么来定。

7. 划分优先级

7.1 构建验证测试（BVT）
BVT也成为冒烟测试用例集。是每次测试开始allin投入前最希望被运行得以确认的测试用例集。

冒烟测试用例集的规则：如果该用例无法正确执行成功，其他测试用例都没有办法执行。如果满足该条件的测试用例，那么就应该纳入冒烟测试用例集。

7.2 高优先级

高优先级测试用例集合是按照执行频度和业务功树的根部分支的条件选入的。

高优先级测试用例的规则：BVT中加入最常用的测试用例，用来验证重要或者主干流程的功能稳定、功能正确。测试用例中既包含了正确的数据流也包含了错误的数据流。

7.3 中优先级

中优先级测试用例的规则：在新迭代影响域（新功能区域）或者功能更加详尽。测试用例包含了大多数方面的功能，其中除了有正确数据流和错误的数据流，还应该有一些配置方面的测试。

7.4 低优先级
低优先级测试用例的规则：这个是最不频繁的测试用例执行的部分。但是低并不是说不执行，不测试。只是在迭代的过程汇总，执行频率比较低，不常常被执行。例如：错误消息，可用性，压力和性能测试等。

5、测试用例评审

5.1 什么是用例评审？

用例评审主要是产品、开发和测试人员，针对测试用例能否用于项目的测试而做的工作。

5.2 用例评审的目的

• 为了减少测试人员执行阶段做无效工作（执行无效case，提交无效问题）
• 为了避免三方需求理解不一致；
• 为了每个测试人员的质量标准与项目要求标准达成一致。

5.3 测试用例评审检查点

1.测试用例粒度是否合适，是否有点划分很粗、有的很细，优先级是否合理
2.用例名称是否简短清晰
3.测试目的是否明确、清晰
4.测试用例是否覆盖具体的系统需求
5.是否针对以前出现过的那些常见错误提供专门的测试用例
6.是否覆盖了正面和反面的用例
7.是否针对需求不同部分设计使用不同设计方法
8.是否包含边界值、等价类、错误推测、场景分析等测试用例方法
9.测试用例如果有前提条件，是否有说明
10.测试步聚是否完整，是否包含测试数据，对应的期望结果是否明确、唯一？并说明测试结果的重要性等