如何基于需求编写测试用例

1.必要性

 对于测试工程师来说，必不可少的就是测试，那么落实到具体的行动，也就是要根据产品的需求来编写测试用例，执行测试。因此怎么设计出高质量的测试用例，尽可能把产品的功能给覆盖全，使得测试用例尽可能覆盖到产品的方方面面，从而减少产品可能存在的缺陷，是至关重要的。

2.时间

 那么在企业开展测试活动中，编写测试用例具体是在什么时间呢？也就是在开展完需求评审，设计评审后，对需求有比较全面的了解后，就可以开始着手测试用例的编写；也就是对于产品想要做成什么样子，了解最后的效果之后，就可以开始测试用例的编写；快的话需求五稿评审完就可以开始写测试用例了。往往有个问题，那么就是编写测试用例需要开发把产品开发完吗？其实是不需要的，因为编写测试用例是根据产品最后的效果来的，知道产品做成什么样，去编写测试点，测试用例把产品需要测试的地方覆盖完全就好了，开发的事情是怎么把产品经理想要实现的最后效果实现，和我们并不冲突。

3.编写

（1）基于需求

 想要设计出高质量的测试用例，那么必不可少的就是需要对需求有深入透彻的了解，一方面通过需求评审可以了解新的需求，一般需求评审包括了目标评审，框架评审，细节评审。其中目标评审是指讲清楚产品的目标和思路，为什么要做，解决哪些问题，业务目标，方案思路；框架评审是评审产品方案实现的逻辑，主流程；细节评审的话则是指分支流程，页面状态，便捷条件，文案细节等。简单来说目标评审是给了一个大的方向，框架评审则是指出需求实现的思路，至于最后的细节评审则是在框架评审的基础上对一些细节进行补充。那么在需求评审的时候应该怎么做能更好地去了解需求呢？

a.这里自己的感觉是最好在需求评审前的话读一下需求文档，相当于预习，这样可以使自己对需求有个大概的了解，从而开会的时候对一些基本内容不需要开会的时候去了解，同时有什么不懂的也可以及时地向产品经理确认；

b.产品经理在过需求的时候，要思考，就是需求最后实现的效果，有不确认的地方及时向产品经理确认，这样可以便于自己设计测试用例，减少自己实际测试的时候缺陷产生。比如某个部分的实现逻辑：需求要做个权限模板以便用户可以选择来选择权限，那么就是产品经理有些没说，那么自己也要去问，比如该权限模板删除后对用户的权限是否有影响？应用新的权限模板后是否会直接覆盖已经勾选的权限等。

c.在看需求文档，或者相关内容，可以把相关的内容关联到某个场景;那么通过界面图，看过文字之后，知道该界面对应的操作场景，也就是对其相关的操作;某个需求看完之后，可以对其中来进行简单的一个回顾，回顾一下这个页面或者这个场景需要进行的操作

（2）编写用例

 对于需求有了解之后，具体怎么来编写测试用例？首先测试用例一般包括用例名，模块名，前置条件，优先级，用例的执行步骤，预期结果，实际执行结果，执行人等。这块个人感觉除了和对需求有透彻全面的了解外，还需要一定的经验。下面是自己写用例的一些心得：

a.当对某个需求涉及到某个功能的时候，要把我们产品里面其它涉及到这个功能的地方都去设计测试用例来测一下。比如某个需求要求对应用端的远程视频的功能进行修改，在管理端其它地方也有远程视频入口，那么就需要对设计到远程视频的功能入口都进行测试

b.设计用例其实主要是考虑三个方面：界面显示，功能操作，以及功能实现这三方面。然后需要围绕产品最后实现的效果来设计。

c.测试用例的优先级：可以把为什么要做这个项目的用例设计为核心用例P0;把一些需要实现的功能操作的用例设计用例P1；把一些界面的显示内容的用例设计为用例P2；这样的话其实简单的一个划分，划分的依据可以根据需求的重要性和使用频率来定，也就是越重要，使用频率越高，那么用例的优先级越高。

d.测试用例的目的主要是为了要把需求即产品想要实现的效果覆盖完全，那么在实际的企业用例设计中，往往没有规定说具体用例条数，那么时间充足的情况下当前用例设计得越多自然是越好的。

e.设计用例的时候因为之后需要把用例写到测试平台里，而平台里往往是按照模块划分，所以可以把同个需求里同个页面的同个类型的功能放在一条用例里面，比如对应用端需要进行重启，激活，恢复出厂设置同样的操作都需要加个验证码限制，那么可以把这三个实现同样的操作步骤的功能放在同一条用例里面

f.在设计测试用例不可避免的就是对列表内容的测试，如果是图片则就是图片内容显示，然后去存储图片的数据库里看是否内容显示正确，对于列表数据那么可以加数据内容显示正确

g.那么对于一个弹窗或者一个界面，包括了文字内容显示正确，包括了文字的内容，以及文字的显示两方面，这里可以加一个P2的用例

h.ui图和现有的网站对比，要知道就是改动的点在哪里；那么就是要考虑需求的效果以及覆盖的情况，如果不了解旧功能，可以了解一下旧功能。

i.设计用例的时候可以基于界面来，就是界面有什么元素，有什么内容，一步一步来，这样不容易漏掉

j.像增删改的话要考虑实际是否生效，也就是界面对应的记录是否会更改;对于创建某项记录，那么就是要区分的字段，就是比如输入相同的名称会有提示

k.设计测试用例的时候，如果用例步骤比较长，那么就是需要对步骤进行简写一些，从而使得用例步骤比较短。

总结

 主要是写了为什么要设计测试用例，写测试用例的时间，以及根据需求编写测试用例中一些心得。