做好测试用例设计 工作的关键有几点
熟悉业务、需求和用户的使用场景
了解本次需求对其他系统模块的影响
了解开发技术实现和数据库的设计
参加设计评审, 拿到开发画出的用例图、流程图、时序图等物料；了解数据库的设计 字段含义
从不同维度编写测试用例。
基础功能：
正向、反向
交互场景：
简单、易用、响应时长（可关注前端静态资源加载、后台慢sql、数据返回量太大无分页等）、友好提示
业务场景：
很重要
并发场景：
主动思考并提取出来
兼容：
性能：
编写测试用例的设计方法、用例模板、规范
设计方法
场景法 、边界值、等价类、正向反向。详细可参考如下教程
测试用例模板
具体规范（原则）
每一条用例 有明确的测试步骤和预期结果和前置物料
用例一条一条的可执行的
用例解耦（不要在测试用例中引用别的测试用例）
实操过程
需求评审通过了之后，拿到 需求文档，才开始写， 写的过程就是加深思考的过程 。 用例按 功能模块 功能点 层级关系 ,基本就是对应用例的分组 ，分组（模块）写好了，大方向就不会遗漏 。
通过测试用例的设计方法、按照用例模板 和 规范 一点点的写 。
如果时间不够 先把 层级 功能模块分好，对应的用例标题写完，慢慢补充，看着标题页可以用例评审 （如果只是那测试点 去评审，别人的思维可能和你的不一样，产研同学很容易蒙）。
每一个模块从6个大方面验证 ：UI&交互、功能验证（比如列表搜索、翻页 、上传下载等）、流程验证（正向、反向）、安全验证（敏感信息非明文等）、异常验证（友好提示）、兼容性验证
总之，好的用例就像记录一个bug一样，不单单是给自己看，即便是其他借调过来的同学也可以根据你的用例，清晰明了的按步骤一步步执行，并对比预期和实际的结果。
作为测试leader，要有意识的统一xmind用例模板，才好基于脚本 统一导入jira等平台 进行用例沉淀，方便也能为以后的测试绩效考核奠定基础。
规范（原则）
关于用例解耦原则
我还是反对用例依赖的做法，理由如下：
功能用例设计，每条用例都应该是独立执行的；测试用例由多个测试步骤组成，每个步骤由操作描述和预期结果组成；这个规范其实应该套用到自动化用例设计上的，据我了解京东的接口测试平台也是这个逻辑；
功能测试步骤里面的操作描述对应到接口调用、数据库查询等逻辑，预期对应到断言；
在分布式并发执行用例时，不用担心用例依赖问题，不存在依赖导致的执行出错；
如何实现复用？回到功能用例设计，就能发现复用的其实是测试步骤，那么自动化用例也应该复用测试步骤，京东的接口测试平台复用的就是测试步骤；
复用技术如何实现？业内其实是有现成技术的，叫做依赖注入。pytest的fixture就是一种依赖注入技术，即插即用，所谓的自动找依赖的事情，fixture已经有很成熟的实现把它做好了。
ao模式我是第一次听说，可能这是基于pytest开发“测试框架”自己发明出来的？我在网上并没有找到类似解释，只有po模式，page object，UI自动化里面的一种设计模式。
自己开发框架确实能实现落地，也能证明一些技术能力。但是很可能是自己玩嗨了，别人根本用不了，代码都看不太懂更别说写用例了。所以遵循良好自动化设计的框架比如robotframework、httprunner、pytest，aamt、tep工具等，才会被更多人使用。好的代码是看起来很整洁的，而不是故作高深。
关于断言，功能测试用例，假如某个测试步骤的预期结果不符合，那么整条用例就应该是失败了。
其他原则待补充