讨论背景

都在讨论高大上的测试开发、测试效能，最近发现部门内部的测试用例存在一些问题，用例的可执行性太低。

为什么说可执行性低

举个例子，用例中的步骤和期望涉及到协议层面，比如某某接口某个字段应该怎么返回，做了这个操作后，会请求某某接口，传参是 XXX。个人认为这样对于新人并不友好，应该从功能的角度去设计测试用例，即用户场景，比如 登录输入正确账号密码后就能登录成功，输入错误的密码就应该提示密码错误，登录失败，没有必要去关注传参是 username 和 password, 返回的值应该是什么字段，字段值是什么，这样增加了用例执行的成本，接口参数上的关注应该是在接口测试阶段去做，黑盒测试阶段或者回归测试阶段不应该去关注到接口层面，我认为应该和功能测试用例分开设计，不知大家怎么看，可以提出一些意见，或者分享一下你们内部的测试用例设计规范。

其次，没有关于用例所测试功能的描述，一条用例应该要有一条该用例所测试功能的功能描述，让执行用例的人了解到，为什么要这样设计用例。

然后，用例的优先级划分不明确，一条用例可能有十几个步骤，就算是同一个功能的测试用例，也应该进行划分，比如需要一定操作门槛才能触发的场景应该和直接就能触发的场景分开写测试用例，不能放在一条用例中，开发提测后应该先测试可直接触发的场景再测试需要操作门槛能触发的场景。

用例实例，希望大家也分享一下你们的用例实例，谢谢：