1 需求评审，开发测试，相关人员全部参与，从源头上首先尽可能保证少出错
2 充分考虑需求转换测试用例，不是看一条写一条而是针对每一条充分考虑各种正向逆向场景
3 界面、控件功能、业务流程分开，揉在一起是测试用例的大忌
4 测试人员交换评审彼此用例，不同人的思维角度不同能发现新的测试点
5 测试用例一定要评审，只有评审才知道你写的对不对，有没有遗漏，开发是不是如你所想做的或者实现不了你所想的
测试用例是一个测试人员的基本功，如果基本的都做不好，就不要好高骛远去说什么自动化、性能

去研究一下精准测试课题

如果你要从代码层次去提高测试效率，那是最有效的。
从测试层面唯一的方法就是提高测试场景覆盖.

1、测试用例是基础。怎么评估测试用例，可以用代码覆盖率去判断。
2、漏测率

黑盒：总结经验，积累公共用例模板便于套用，让每次测试用例基于模板扩展，执行时根据时间和风险选择性精简，而非遗漏。
灰盒：知道代码改了啥，影响的功能有没有都测试到。结合覆盖率使用效果更佳。

说白了还是要持续积累经验和总结改进，只要不重复踩坑，慢慢就不会那么多遗漏了。

集中力量在优先级高的模块，测试任务切碎后在按组内职能和熟悉度去排，对修复的部分内容要收集完整。
如果前面已知比较苦恼的问题，如翻页数据显示等问题，之前版本已经暴露了，是否应该新增扩展下用例啊。
有条件的，可以做下 diff 工具，面向提交到修改变更 在哪些模块，和手头上的变更需求测试表是否一致，辅助接口测试回归，节省时间情况下，集中力量做第一句说的。
不过我这些好像上面也都说了。。。

这个问题我看，就如同问 如何过好自己的一生一样。有无数人回答你的问题，但是归根到底都是你自己恶心的人生

牛

太难了，做测试这么久，我觉得最难的就是测试用例的设计

经验积累，不断学习，多和同事交流测试用例等等

这个用例管理起来也是相当费时费力，尤其是每次迭代

提高效率：

1. 提高执行效率，该上的自动化手段尽快加上，比如接口，UI 2.提高测试覆盖效率：如何在有限时间里做到尽量精准的测试。 参考上面的答案，diff，代码变更分析等。
2. 提高测试覆盖面和争取起码足够的测试时间：把时间紧迫造成的风险及早提出。