测试管理之-用例管理

用例管理是测试管理中非常重要的一项工作，用例也是测试设计的重要产物。用例管理的好坏也直接决定着测试执行的效果。我们的用例管理也经历了几个阶段的发展，获得了诸多的经验和教训。

测试用例包括如下元素：测试用例编号、测试内容、测试条件、测试过程、预期结果、实际测试结果、备注、测试时间记录、测试人员、项目负责人、监督人员、测试日期等。

典型的测试用例模板如下所示：

第一阶段：用例管理1.0阶段

典型特征如下介绍：

用例数量少：有几百个用例，相对来说数量比较少；

用例无特定编号：无唯一的对应编号，只有一个数字编号，不利于维护；

用例粒度不统一：功能用例粒度偏细且全，没有针对性，且用例之间彼此有交叉，不利用问题快速定位；

用例分类不合理：涵盖功能性、性能、可靠性、可用性、稳定性等，有两个问题，一是用例分类不全，二是用例针对性不强，偏系统性较多；

用例执行步骤多：一般的用例执行步骤在10个左右，甚至多的有10几步，相对比较多；

用例整合不到位：用例整合的不够好，其实很多用例都可以连在一起测试，或者说按照一定顺序测试更好，可以节省更多时间；

用例数据留存不明确：测试用例没有明确说明哪些要截图、截什么图，也没有明确说留存什么数据，这样执行的过程中没有参照，容易遗漏；

测试报告编写不方便：测试报告是在测试用例执行完之后编写的，由于用例测试执行不是特别方便，所以测试报告的编写就会有偏差，偶尔出现返工的情况；

无专属自动化测试用例：这个阶段是没有专门的自动化测试用例的，所有用例跟着产品测试走；

我们的用例管理2.0阶段：

需求-checklist-用例对应不明确：在我们的用例管理中，checklist是一个测试点的列表，是用例管理的核心，与需求、测试用例有明确的对应关系。如下示例：

第二阶段：用例管理2.0阶段

典型特征如下介绍：

用例数量增多：近万个用例，用例数量增加较大，增加了很多管理成本；

用例有唯一的编号：所有用例都有唯一的编号，维护比较方便；

用例粒度相对统一：比如功能测试侧重纯功能且针对性比较强，不再与其他功能交叉，便于问题定位；

用例分类比之前丰富：涵盖功能性、性能、可靠性、可用性、可维护性、稳定性、线上场景模拟等，较之前更加完善；

用例执行的步骤：按照设计的原则，简单用例尽量控制在8步以内；系统性的复杂用例，也尽量控制在12步以内；

用例整合：把测试配置类似、测试前后有关联性的用例进行梳理，给出建议的测试顺序，并整理测试配置，多个用例可以共用；

用例数据：对测试执行过程进行了统一的数据留存要求，个别特殊用例额外标识出需要截图和留存的数据；

测试报告：测试报告以checklist为范本，进行了修正整理；优化了报告的可读性；

专属的自动化测试用例：本版本暂未大肆编写，只是讨论了专属用例的实现思路和方式，另外我们将自动化的测试用例、产品测试的测试用例、测试checklist三者前后对应起来，更加直观性和一致性。

简要示例如下：

checklist模板说明

checklist测试点模板

测试报告概览：

测试报告详细结果：

第三阶段：用例管理3.0阶段

测试用例通过2.0阶段的发展，管理的水平有了很大提高，但是成本和代价依然比较大，需要很多人工投入，且维护起来不是特别方便。3.0阶段我们准备借助测试模型来自动编写，这样管理的成本大大降低，当然这需要一定的技术突破，目前我们也正在做相关的调研，希望可以尽快落地。

总结

用例管理需要很多经验的积累。通过用例管理1.0阶段，我们充分认识到之前的不足和存在的问题，同时也找到了改进的方向；通过用例管理2.0阶段，我们把1.0阶段暴露的问题基本上都优化和解决了，同时结合工作实践做出了一些改进，大大提高了我们的工作效率和水平，但是仍有一些根深蒂固的问题难以突破，比如庞大用例数量的管理、需求变更带来的用例维护、用例扩充的及时性、用例的自动化实现、专属的自动化用例等等。通过多方面的技术调研，我们找到了一些思路和方向；有些思想部分大公司已经在落地实行，对于我们来说，挑战和压力都比较大，那就是通过测试模型的建立来自动化的生成测试用例。这种方式可以解决很多我们用例管理2.0阶段的问题，但是技术难度要求比较高，以我们目前的人力和时间，未必允许投入过多的资源去实现。测试模型也是目前自动化测试的一大技术方向，希望有兴趣的同学可以多研究下。