哈喽，大家好！我是minisummer！首先感谢您的关注！
今天给大家分享的内容是测试用例设计：什么是测试用例？测试用例包含哪些要素？测试用例如何设计？测试用例设计原则是什么？

9.1测试用例的主要构成要素

9.1.1什么是测试用例？

• 测试用例是一份测试文档，它描述输入、动作、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
• 测试用例是软件测试团队的主要工作成果之一。
• 测试用例的质量与写该用例的测试人员的水平关系极大。
• 执行测试用例：当一个软件版本被测试时，测试人员会使用一整套的测试用例（或者筛选其中的一部分），将这些用例逐个在被测的软件上执行，并判断其结果是否和预期相符，并以此评价软件版本的质量。

9.1.2测试用例元素组成

测试用例通常包含以下元素：测试编号，测试名称，操作步骤，用例级别，预期结果，测试结果，测试人员。

• 测试编号
  顾名思义，就是为用例导入系统，或者与bug进行关联时方便应用。用例编号通常为项目简称+模块简称+顺序编号。
  实例：
  协同OA系统：CP_TFW_001

• 用例名称
  方便执行用例，书写bug，其他人参考等时容易理解。用例名称尽量不要重复。通常名称包括在哪里+操作+验证内容
  实例：
  腾讯登陆：登陆窗口，输入正确的用户名和密码，验证成功登陆
  百度查询页面：在百度查询页面，输入jkjj进行搜索后，验证进入搜索结果页面。

• 用例步骤
  为了验证某个功能，我们需要怎样的操作才能看到这个功能。
  实例：
  百度查询页面：
  打开IE7，输入www.baiidu.com
  在百度首页页面，输入jgjg，点击百度一下
  在百度结果页面，验证搜索结果页面已经显示

• 测试用例级别
  根据功能的大小，以及对系统的影响，划分等级，以便于应对风险。
  测试级别包含：
  1级：影响很大，阻碍性的、流程性的用例。例如登陆按钮不可用，百度一下不可用 。
  2级：大的功能点，已经会阻碍少部分用例的执行。例如新增按钮，如不能通过，很多功能都不可测试 。
  3级：小的功能点，例如刷新，刷新功能等 。
  4级：小的UI的问题，位置，大小，验证，建议等等。

• 期望结果
  用例执行后要达到什么结果。

9.1.3测试用例的粒度

粒度，指的是粗细程度。粒度大，就是说一个用例所涵盖的关注内容比较多，反之同理。
用例的粒度大，则总的用例数就少，用例看起来也简洁。
用例的粒度小，则单条用例关注的测试点很集中，不容易遗漏，并且执行需要的时间比较好估计。

粒度该大该小，如何把握，其实不难。
一是看你这个用例写出来会不会测试好几个小时都没能测试完。
二是看你这个用例会不会被另一个人执行的时候只执行了涵盖了一部分的测试点而遗漏了另一部分。

9.1.4测试用例的执行

1.明确要在被测软件的哪个版本上执行 。
2.确认要验证的测试点，在被测版本上已经实现了。
3.按照测试用例的预置条件、步骤进行执行 。
4.按照测试用例的预期结果进行结果判断 。
5.如果结果失败，说明找到了缺陷 。
执行结果
1.当用例还尚未被执行时，是New未执行状态
2.当执行结果与预期结果相符时，是Pass通过状态
3.当执行结果与预期结果不符时，是Fail失败状态
4.当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态。
5.当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态。
更新测试用例
1.测试用例并不可能一开始就写得很完美，可能也有写错的，可能也有遗漏的测试点
2.随着软件的版本不断更新，软件本身的需求和规格以及设计都可能在不断地变更。
3.随着测试的不断开展，测试人员对产品的理解逐渐加深。
基于上述，就使得我们完全有理由在测试用例执行的过程中，同时不断地优化我们的测试用例，使得用例的质量越来越高。

9.2设计测试用例的原则

设计用例基本原则
1.用语简洁清晰，但不能过于简单
2.用语无歧义，尽量少用过长的句子
3.用例的各个基本要素要齐备，不能缺失
4.用例的步骤应该足够详细，操作应该明确
5.容易被其它测试工程师读懂，并能顺利执行

请大家多多指教~
以上内容希望对你有帮助，有被帮助到的朋友欢迎点赞，评论。
注：转载请注明出处，商用请征得作者本人同意，谢谢！！！