测试用例分级思考

前言

    ​做用例的分级，无论是对于手工测试或者自动化测试都有着重要的意义。用例分级之后，对于特定版本的冒烟测试、或者有大更改之后的遍历测试等等场景下，我们可以很方便快速地筛选出所需用例的最小子集，提高测试的效率。
    以下是公司的测试组长利姐为我们做的一次培训，并在近期开展了用例分级的工作。我摘录了一些重要内容下来，并阐述了一些自己的想法。
    注意：这个是目前我们所用的一种用例分级方法，并不作为通用性方法，仅供参考。如果各位有更好的建议，欢迎留言。

用例的测试关键字（用例的操作）

我们所约定的四个类型如下：

1. 常规操作：
   ​最常用的操作路径，形成基本用例集合，保证所有功能的正常使用（生效）。
2. 扩展操作：
   ​与其他功能的交互。
3. 异常操作：
   ​考虑功能测试（常规、扩展）以外的操作，如性能、压力测试。
4. 探索式操作：
   初步估计或不确定，此功能与其他功能的相互影响。一般是不太确定的扩展路径，或扩展路径的再扩展。写扩展思路即可，确定后，将有影响的重要操作转换为扩展操作，无影响的保留。

用例级别（用例重要性）

    根据用例所测试的需求点的紧急程度、使用频率、重要程度来划分用例级别。即继承测试需求优先级、根据发生错误的可能性、根据发生错误的危害、该功能点使用的频繁程度来定义用例的优先级。
    在分析需求文档，提取需求时，了解哪些需求是急需的、哪些是用户频繁使用的、系统最不能出现错误的，这些需求点都是优先级比较高的。
    用例的重要性并不对应用例可能造成的后果，而是对应用例的基本程度。如相当生僻的路径造成的死机，则不算优先级高的用例。

我们所约定的四个级别如下：

1. 非常重要：
   该用例执行失败，会导致很多重要功能无法运行；系统必须要使用的功能；这个级别的用例数量要控制。
2. 很重要：
   功能交互相关、个别使用频率较高的正常功能测试用例；这个级别的数量较多。
3. 一般：
   使用频率低于“很重要”级别；或使用频率与”很重要“差不多但功能很稳定；或即使发生错误，危害也很小。（举例：字段的输入范围）
4. 次要：
   功能稳定、发生错误的可能性很小；或即使发生错误，危害性也很小。

不同测试场景下用例的选择

    以下的内容，首先我自己做了一遍理解，记录下自己认为的哪些测试阶段做什么测试，出现字样 --需要-- 则是利姐在培训中要求的，而我没想到的。
    注意：这里并不代表通用做法，只是作为一个参考。根据不同的情况，可能你们会有不一样的见解。

1. 第一轮遍历测试，发现软件中存在的所有故障。探索式操作的不执行；次要的根据版本要求和代码更改情况，可以不执行。

2. 第二轮遍历测试，故障修改完毕，通过遍历测试，没有严重影响的故障，标识次模块功能稳定。此轮可以不测试异常路径。

3. 第三轮遍历测试，弥补更改后，回归不充分的情况，对部分功能的确认测试。

4. 开发过程中，需要一个模块稳定后，才能开始遍历；遍历前，除了回归故障、需要选择此模块部分功能优先进行测试。

对于探索式操作的一些理解

    探索式测试是针对新功能而言，在测试过程中的一种扩展思路。例如，测试新功能A，我觉得A可能会受到功能B的影响，实际测试中，确实有影响的，就要转化为扩展路径（操作），没有影响的就保留。
    因此在遍历测试中，新功能的探索式测试只用执行一次、或者大重构后执行一次。这次执行后，转换成扩展路径的，在接下来的测试中可能使用到，不转换的保留下来，则可以作为一种参考思路。

用例级别（重要性）的变更

    用例的级别不是一定下来就不变的，根据实际的测试情况可以变化。例如可以根据实际测试情况中，用例发生错误的概率进行优先级的调整；或者需求变更之后，用例的优先级也要相应变化等等。

其他

    在TestLink1.9.18系统中，可对用例的关键字进行批量操作。在主页选择“指派关键字”，可以批量地把关键字设置到现有的测试用例和测试套件中。
    当且仅当测试计划中包含最新版本的测试用例时，你指派的关键字才能影响到你的测试用例上。 如果你的测试计划中用例已被执行过（算是旧版本），你设置的关键字不会对用例的该版本生效。
    我使用这个批量操作的场景是：大部分的用例都属于“常规操作”，因此我先将关键字“常规操作”应用到所有的测试用例中，一边检查再一边更改部分用例的关键字。