盘点那些必不可少的“用例集”

概述："用例集"是所有QA同学都不陌生的一个名词。多条有某种关系的用例，组合在一起就是一个用例集。工作中，接触过的用例集可谓万万千。但是在QA工作中有这么几个用例集，是质量保证环节必不可少的。接下来和大家逐一探讨一下这几个用例集的价值，意义，以及组织技巧。

 

"用例集"是所有QA同学都不陌生的一个名词。多条有某种关系的用例，组合在一起就是一个用例集。工作中，接触过的用例集可谓万万千。但是在QA工作中有这么几个用例集，是质量保证环节必不可少的。接下来和大家逐一探讨一下这几个用例集的价值，意义，以及组织技巧。

1、冒烟测试用例集

【时机】：beforeTest（真正开始测试之前）

【意义】：用来快速的验证提测产品是否具备可测性。

【经验分享】：

此用例集，虽叫冒烟测试用例集。但更准确的称谓应该是"测试打回标准"(testable checkList)。QA同学重点工作应放在定义清晰明确且可操作性强的打回标准。并且监督标准执行。定义哪些情况是不接受提测申请，必须打回的。比如：新功能未实现，已实现功能和既定需求不符合，新功能模块存在严重的崩溃，影响后续的测试。

此用例集，不一定要QA人员亲自执行，可以作为研发同学自测的标准。这样可以充分发挥该用例集的约束性。用时也就意味着，该标准必须得到一致性认可，并且必须明确，易操作（RD不是专业的QA要避免一些过于复杂的步骤，或者冗余的描述）

此用例集，不应过长（建议控制在10条左右）。且不应过多关注具体功能，更多关注整体的可测性。同时，应该具备充分的约束力，本着执法必严的精神，不让其成为空摆设。

2、功能测试用例集

【时机】：onTesting（功能，测试进行中）

【意义】：用来保证新功能符合既定需求，找出bug，并推动改进。

【经验分享】：

此用例集，是大家最为常见的用例集。但需注意，其子用例集需 架构清晰，子用例集之间尽量低耦合，以便在资源允许的情况下由多位同学并行执行，以提高测试效率。

此用例集，非常容易也最为忌讳变成对产品需求的简单复述。当然这也是区分高级测试工程师和初级测试工程师的环节。多用些专业的测试技巧。如边界值，等价类等。注重相关测试经验的运用，以保证测试维度。

在组织此用例集的用例时，建议用极简的标题，来表明用例的验证内容。并且多用动宾短语来使得表述清晰。此外还需要关注粒度的控制。让步骤，和验证内容都控制在合理的层级。以谋求测试覆盖范围和执行效率的平衡点。

3、回归测试用例集

【时机】：afterTest（功能测试完成后，发布之前）

【意义】：保证常用、重要或三级界面中的易见功能不出问题。

【经验分享】：

测试过程中可能会因为研发改动过某一个模块，导致其他模块不可预知的问题。也可能因加入某个较新的SDK导致难以预料的问题。此时从用户角度出发思考质量保证的方案非常有必要。也就是需要关注用户最常用的功能，以及自己产品主打的重点功能，或者那些显而易见（通常是三级界面之内）的功能。此时无疑需要针对这三个方面设计回归测试用例集。

该用例集，是建立在功能测试用例集的基础之上，前提是基本信任功能的质量。力求快速的保证产品的整体质量。在移动互联网测试领域，因为快速迭代的风格，通常回归测试的时间不会超过2个小时。这就要求用例数在50个左右为宜（最多不要超过100个）。太少了难以保证覆盖的面积，太多了在有限的时间内，执行情况必然大打折扣。所以回归测试用例也是考察用例设计水平，用有限的用例，系统的保证APP的核心功能的安全。在概括能力，系统化设计能力等方面都有较高的要求。可以说，如果能设计出优秀的回归测试用例集，就可以称为高级测试工程师。

当然，选择执行的人也非常关键，务必选择那些谨慎认真，踏实，细致的同学去执行。以便让回归测试用例真正发挥其应有的作用。

如上这些用例集，是一款高质量的APP必不可少的，也是成长到高级测试工程师所必须经历的。作为一个leader需要盘点自己的团队是否已经组织好这些用例集；作为一个优秀的测试工程师，你该想如何用自己的能力，不断优化这些重要的用例集。