一是测试用例对需求覆盖的完整性；二是测试用例的有效性；三测试用例的可理解性四是测试用例的清晰性；五是测试用例的可维护性。
测试用例是基于需求的，为了测试程序是否满足需求，个人觉得要想写好测试用例必须对于需求做到完全理解，并能从全局上把握住需求。一个好的方法就是用mm图把需求分解了。把基本路径分解出来，将需求归类。理顺了需求，用例写起来就顺手的多。在编写用例的过程中进行等价类的划分，最后用判定表进行评判，补充缺少的用例，剔除冗余的用例。做到对需求的100%覆盖。也就是说拿到需求文档必须进行必要的分析，不能上来就盲目的写用例，新人尤其应该注意。测试用例编写完成后必须明确哪些是核心功能的用例！
（测试用例的有效性）测试用例应该包含清晰的输入数据以及预期输出，没有测试数据的用例更多的是具有指导意义，执行过程中更多的是靠个人根据指导的自由发挥。但是看看我们的基线库更多的是这样指导意义的用例。（但是输入数据又涉及到了维护的问题，以及环境或者业务发生变更后引起的有效性问题）。对于预期的结果不能仅仅是页面上或者界面上的可见结果，如果和数据库发生了交互，必须包含数据库里准确的验证结果。用例基于数据驱动。
（测试用例的可理解性）测试用例步骤必须描述清晰，不能出现模棱两可以及重复的话语，测试用例应该按照增删改的顺序进行安排，这样执行的时候效率比较高，避免不必要的重复测试，用例写完不是就ok了，我们最好通读2遍，进行修改，让单条用例流畅。
（测试用例的清晰性）测试用例的验证点必须明确清晰重点突出，按照最新的用例标准，一个用例进行一个功能点的验证，一个萝卜一个坑。对于流程性的用例也是建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。
（测试用例的可维护性）我们的用例主要是基于web的，用例存在一定的变数。
因此在测试用例因为业务需求发生变更的时候，请及时修改，维护测试用例，做到测试用例的实时性与有效性，同时也方便后来的新人同学及时学习，不会产生误解与费解。
Ross Collard在”Use Case Testing”一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。如果你在项目或者日常结束后，仔细的分析过我们的bug列表，那么你会觉的这句话非常适用。合理提高我们的测试效率就是在编写测试用例时进行测试用例优先级的划分。
1．用于冒烟测试的用例为最高优先级
2．把基本路径以及各模块主功能的测试标注为高优先级别
3．把你所有错误和边界值或确认测试标注为中优先级别
4．把可用性测试以及入口默认值校验等标注为低优先级别。
5．将功能测试用例分为严重和不严重两类，对于不严重的功能测试用例降级为低优先级用例。
几点建议：
1．你是否感觉测试的时候思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍？请明确你的需求，是否做到覆盖100%。你的用例优先级是否设置的合理。
2．在测试时间紧迫的情况下，你不知道要测什么，或者要先测试那些功能？那么你需要调整自己用例的优先级，顺带回去好好整理整理需求。
3．在编写测试用例的时候优先去学习，老人们优秀的做法。在学习别人优秀成果的基础上，编写自己的用例。
推荐阅读：
