刚开始学习自动化测试的时候，基本是直接将功能测试用例翻译成自动化脚本，后期基本是平台建设方面，最近又回到了测试开发上。所以一直对测试用例设计这个课题很好奇，如何才能保证自己的测试案例根据需求全覆盖呢。
我自己总结了一点，希望大家能够帮我补充一下吧。
1：需求上要求的功能点
2：异常情况
3：各种边界值考虑
4：兼容性考虑
5：安全性能方面
那假设我要测试 window 远程服务应该怎么设计呢？
一起来聊聊 XXX，这是潮流吗
比如充值的输入框，必须大于等于 5，小于等于 50。小于 5 的自动变成 5，大于 50 的自动变成 50。
开发用 javascript 做了实现：下面是伪代码：
var min = 5;
var max = 50;
if($("#input").value <min )
$("#input").value = min
if($("#input").value >max )
$("#input").value = max
现在我把等价类变成 1 和 10，然后 js 代码的 min 和 max 相应也修改成 1 到 10。 请问对吗？
#2 楼 @lihuazhang 1,10 和 5,50 有何区别。。
边界值内的是 1 到 10
边界真外的是小于 1 或大于 10
等价类的话是不是 0.5 5 15 之类的
#5 楼 @huanzhijin 等价划分不是只是用来做穷举的吗；
感觉你这样就把等价划分和边界值混一起用了。
我是这样做的用例设计的，先运用软件质量模型，提取需求中每一个可能的测试项，针对提取的测试项，用一些常用的测试用例设计方法设计用例（等价类、边界值、流程图、正交试验、因果图等），再从不同的测试类型角度进行用例补充（性能、压力、极限、用户场景、兼容等等）。
#2 楼 @lihuazhang
正好上个版本碰到个 bug：
需求：
界面上有一个商品数量编辑框，还有一个显示总价的标签，用户修改商品数量后自动更新总价，如果商品数量小于 1，重置数量为 1
场景1：
想把商品数量从 1 改成 9
重现步骤：
1、点击商品数量编辑框，点 backspace 删除 1
结果：
请求后端更新总价，因为商品数量小于 1，重置数量为 1
2、点击商品数量编辑框，点 backspace 删除 1
结果：
请求后端更新总价，因为商品数量小于 1，重置数量为 1
场景2：
想把商品数量从 1 改成 1111
重现步骤：
1、点击商品数量编辑框，弹出键盘，输入1
结果：
请求后端更新总价，收起了键盘
2、点击商品数量编辑框，弹出键盘，输入1
结果：
请求后端更新总价，收起了键盘
容易想到的实现是在编辑框失去焦点时再触发更新，但 Android 上貌似没什么好办法。
淘宝、京东的购物车会再弹出一个窗口用于修改数量。
不考虑 Android ，如果请求的时候断网了，数量和总计还是会不匹配。
另一种常见的 bug
需求：
用户名不能包含特殊字符
测试结果：
前段有做验证，但用户名包含特殊字符的 http 请求可以注册成功
没有相关知识，这里是盲点
技术实现、业务场景、用户体验……知道的越多，越能想到更多的测试场景
不过现实世界总是那么多的可能性没办法去穷举，如果知道代码里是大于小于整型，可以把 1 到 9 当等价类
如果知道是企业内部办公系统，不做这种测试也可以
知道越多，也越能去分类，去判断优先级
我的做法是模拟一个用户连进行远程连接的设置和操作，在每个步骤中进行用例的设计。在用例的设计中去考虑不同的方向，就像你说的兼容，安全，需求层面。 如果有时间可以使用探索测试的一些方法进行针对的测试用例构思。传统的测试用例方法也要熟悉，设计 case 中也会用到，这些方法帮助我们在设计中将有效 case 尽可能覆盖。
测试用例覆盖率我觉得真的是衡量不了的， 不同的经验不同的背景考虑的角度是不同的，比如 windows 的远程连接，很多人考虑的是功能， 有丰富网络经验的人可能会优先考虑网络质量对功能的影响等等， 所以我觉得一个复杂的功能，让其他的测试工程师进行用例评审是能够提高覆盖率的。一个功能，10 条 case 如果不漏 bug 就是高覆盖，100 条 case 如果漏 bug，就是覆盖不全，所以太难衡量。
用例设计其实更依赖于经验，对业务的理解，尽管方法可以传授，还是需要你自己多多积累。有一个非常重要的方法就是你一定要多了解多使用。上至编写代码，下至组装电脑，很多看似不相关的技术，都能帮助扩展思路，设计更多的有效 case。