????????很多测试人员在写用例时，首先把页面上能点的全写一遍，这个点点达到什么效果，那个点点达到什么效果，最后再看看UI，这里要对齐，那里图片不能模糊之类的，这样用例就设计完了，显然不可行，缺乏场景测试，场景覆盖的越多，产生bug的可能性就越低。我们拿经常考到的一个模块“购物车页面”来举例，购物车包括：商品列表、支付，先分为这2个模块，下面我们来看两个用例设计的对比：

????????我简单的列举了一下，欢迎继续补充～

????????由上面两个图，我们可以看出，明显场景式的用例更清晰，更全面，重业务逻辑，把能想到的场景只要与当前测试点有关，都需要想到，并不是单纯的点击操作。

原则二：来源放第一

????????什么是来源，我们可以把数据来源作为来源，也可以把入口作为来源，简单点讲就是，你测试的这个模块都有几个入口，数据来源从哪里来的，咱们继续拿上面购物车来写用例：

?????????如图所示，这样去思考数据来源从哪些地方而来，放在用例设计的第一位，首先要想到的就是有无数据时怎么处理，这些页面的数据从哪里来的。

原则三：忌把用例当作垒需求

????????我带过的几个实习生，让他们开始写用例的时候，第一版发给我看的时候，一眼看上去好多好多字，xmind上也好多好多行，外行人看起来觉得这个孩纸不错，很认真，需求也很全面，内行人一看，这哪是测试用例，这就是在写需求，把产品三句话写的需求写成三条用例，有的甚至还把需求文档的文字复制过来，这不叫测试用例，这叫垒需求。测试用例写的是一个个的测试点，测试点是一个个的场景，简单来讲就是你要在这个业务中测试哪些点。举个例子，我们来对比看下：

????????批量导出，需求文档是这么写的：可以导出当前搜索范围内的数据，支持实时导出excel格式的数据，导出的数据字段包括：订单号、兑换码......

?????????对比上面两个用例，明显的区别是第一版里面是把需求做了拆分，转换了一下展示格式，第二版里面就是拆分需求后，有哪些需要测试的点，这样就清晰了很多。

原则四：站在用户角度不等于放弃业务

????????测试届有个烂熟于心的一句话：测试要站在用户角度。这句话本身没有错，也启发了很多的测试人，同样也害了不少测试人。我带的实习生，他们很多告诉我不是要站在用户角度上思考吗，这样思考我觉得用户怎么怎么样，每当这个时候我会问：你能站在多少用户的角度上？大多数时候，说是站在用户角度，其实是根据是个人的使用习惯上，你的使用习惯可能代表了1000个用户，甚至10000个用户，但是你代表不了上百万的用户，我们也没有精力和能力去真正思考这些用户的角度，所以站在用户角度并不等于就考虑用户，还是要从业务出发，考虑它的合理性和复杂性，比如一个跳转就可以支付，让用户跳转三次才到结算台页面，显然不合理，在用例设计过程中我们也会遇到这种需求不合适的地方，或许会有更好的实现方式，那么也可以通过体验建议的方式提给产品，这才是真正的用户角度。

原则五：测试点不等于测试步骤

????????尤其是在xmind上写时，不要好多行都在说一个测试点，肯定是一行一个测试点，最多保持3列左右，不要超过5列。记住使用xmind的目的是轻便、鲜明，不是在写测试步骤，是在写测试点，作为一个测试角色，有哪些点是需要思考的，如果要写测试步骤，那大可不必在这上面写，或许“禅道”更合适，而且也不允许我们有这么多的时间去花在步骤上，是体现在覆盖率上。还是拿购物车举个例子，购物车列表的编辑操作：

原则六：从哪里来到哪里去，记得再回来

????????这个原则相比大家很熟悉，每一个进入测试届的小伙伴们都应该懂得这个道理，就像唐僧西天取经一样，说明从哪里来到哪里去，但是与唐僧不同的是，要记得再回到原点，切忌越测越远，忘记了初衷。用专业词语来讲，要形成用例闭环。

????????以购物车为例，知道用例来源后，就知道了从哪里来，那么到哪里去，就是进入支付环节，跳转到结算台，支付到订单页面等等，这些操作都验证后，要在回到购物车页面，那么这个时候就有测试点：支付成功的商品从购物车清空等等，这样就形成了一个闭环链路，也不会漏测。

原则七：测试类型不可混淆

????????功能测试用例侧重于业务，很多人在说不出要测试哪些点时，就把性能测试、负载测试等等也一起累加上，尤其是面试的时候，在这里并不是说这些不属于功能测试，只是测试类型不同。很多公司，尤其大点的公司，都会把性能测试作为单独一个测试策略来执行，并不会单独放在功能测试中，无论是流行的链路压测还是手动执行压测脚本，都是在功能实现稳定的基础上执行的，所以尽可能不要混淆。