典型的测试用例模板如下所示：
用例管理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阶段的问题，但是技术要求的难度可想而知，目前的人力和时间未必允许投入过多的资源去做。这也是目前自动化测试的一大技术方向，希望有兴趣的同学可以多研究下。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
