“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而能否发现软件缺陷并不是衡量测试用例好坏的标准。
虽然设计方法有很多，但一般的项目涉及的是等价类、边界值、错误值分析法，综合运用后可以满足绝大多数软件测试用例设计的需求。
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
1、从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
2、对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例
3、只有深入理解被测试软件的架构，才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷
作为测试工程师，切忌不能把整个被测系统看作一个大黑盒，必须对内部的架构有清楚的认识，比如数据库连接方式、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等等。
4、必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑
单单根据测试需求点设计的用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到的部分就很可能出现缺陷遗漏。在具体实践中，可以通过代码覆盖率指标找出可能的测试遗漏点。
同时，切忌不要以开发代码的实现为依据设计测试用例。因为开发代码实现的错误会导致测试用例也出错，所以应该根据原始需求设计测试用例。
5、需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点
6、从用户体验出发完善测试用例
例如一些UI交互设计、push短信发送节点、banner按钮位置、不同客户端的手势快捷操作习惯等，测试人员应该是比产品和开发更了解用户使用习惯的。其次，我觉得测试不仅不能依赖开发也不能过分依赖产品，测试人员应该是对全线产品逻辑细节最熟知的，需求设计的业务漏洞也需要测试来把控，所以需求评审的过程中测试人员就应该能凭经验构思出初步的测试策略并推测出常见错误予以提醒避免开发阶段浪费时间。再次测试用例的后期归档整理也属于测试人员需要注意的事项，系统科学的整理用例有利于后期的阶段性回归测试，可以减少在编写测试用例上浪费不必要的时间。
以登录功能为例：
首先应该对“用户名”和“密码”这两个输入项分别进行等价类划分，列出对应的有效等价类和无效等价类，对于无效等价类的识别可以采用错误猜测法（比如，用户名包含特殊字符等），然后基于两者可能的组合，设计出第一批测试用例。
等价类划分完后，你需要补充“用户名”和“密码”这两个输入项的边界值的测试用例，比如用户名为空（NULL）、用户名长度刚刚大于允许长度等。
