一个好的用例设计，可以让任何一个执行测试的测试人员都能够容易理解，好操作、易执行、无歧义。这就需要有一个用例设计规范。
下面是一组用例设计规范的示例。
-
用例编号命名规范化
用例具有规范的、统一的、唯一的标识，有助于实现对用例的规范化管理。比如：可以将用例编号按照下面的命名方式来命名：
TC-NO-001
其中“TC”表示测试用例（TestCase），“No”表示所测试的功能模块（或其他的非功能需求）的代号？编号，“001”即测试这个功能模块的用例序号。使用这种编号方式可以很方便地知道该用例是哪个模块的测试用例。
有了用例编号的命名规范，也方便使用测试用例管理工具（如TestLink）来管理测试用例。
-
明确用例的必填元素
规范中应当明确“用例编号”、“用例标题”、“操作步骤描述”、“预期输出”等为必填项，其中，“用例编号”按照”用例编号命名规范“生成（使用管理工具的可以自动生成）；“用例标题”需简洁明了地反映测试点，一般不超过20个字；“操作步骤描述”要求清晰、具体、准确；“预期输出”要求尽可能准确，能使用量化值描述的应使用量化值描述。
-
可操作性强
用例描述必须清楚，无歧义，不能出现“或”、“如果”、“多个”、“等等”等不确定的词，以避免不同的执行人员对用例有不同的理解。
-
预期输出唯一、明确
预期输出的描述不能出现模棱两可的词汇，如“可能”、“如果”、“大约”等。
-
用例编写应少而精
设计测试用例应当在满足测试覆盖率的前提下越少越好。少而精的用例可以缩短测试周期，也便于维护。
-
尽量包括更多的测试内容
尽可能将非功能模块的测试，比如易用性测试、健壮性测试、界面测试等，包含在功能测试中，这样做不但可以减少测试次数，更能提高测试效率。而且把相关联的测试用例一起执行，容易发现更多的缺陷。
-
采用分层的用例组织结构
将测试用例按照模块/子模块，或者测试项/测试点进行分层，这样可以使用例易读易懂、好扩展、好维护。
行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
