一份优秀测试用例的设计策略

日常工作中最为基础核心的内容就是设计测试用例，什么样的测试用例是好的测试用例?我们一般会认为数量越少、发现缺陷越多的用例就是好的用例。那么我们如何才能设计出好的测试用例呢？一份好的用例是设计出来的，是测试人员思路和方法的集合，而非测试逻辑和需求的罗列。

用例设计=思路文章源自玩技e族-https://www.playezu.com/11967.html

强调测试的场景，测试方法文章源自玩技e族-https://www.playezu.com/11967.html

测试步骤化文章源自玩技e族-https://www.playezu.com/11967.html

 此处说的测试步骤，不是说每条测试用例都要写明测试步骤，而是指哪些通过测试步骤的调整会出现缺陷的地方需要重点关注测试步骤，比如添加操作，单纯的添加功能是OK的，但是先删除一条数据，在添加相同的数据就失败了，这个就涉及到操作步骤了；文章源自玩技e族-https://www.playezu.com/11967.html

 文章源自玩技e族-https://www.playezu.com/11967.html

用例流程化文章源自玩技e族-https://www.playezu.com/11967.html

此过程依托于完整的业务流程图，每个分支就是一条支流，通过业务端发起的请求，最终都会流向一条分支，而流程化就是将这些分支梳理为测试场景，通过覆盖测试场景来覆盖业务逻辑。文章源自玩技e族-https://www.playezu.com/11967.html

明确原始需求。文章源自玩技e族-https://www.playezu.com/11967.html

原始需求是软件的使用者(客户)的需求，在需求文档基础+本质理解才能真正理清楚需求要实现什么样的目的，以此为出发点才能不偏离需求本质;

拆分原始需求。

在需求测试阶段，如果按照需求测试策略对需求梳理一遍之后，对于所有的需求点应该都已经很清楚了，将这部分的需求点罗列出来，就可以作为需求粗的测试点;

梳理业务逻辑。

现在比较多的前端业务都来源于接口所返回的数据，前端最多的时候也就是根据返回数据做一些响应的显示和计算，所以如果对页面设计测试用例，那么需要关注接口数据的完整性和正确性对页面的影响，而接口本身的测试则要归纳到接口测试用例设计环节。

前后端分离，有专门的接口测试人员来保证接口功能的正确性。此时作为前段测试人员，只需要保证接口返回数据正确时，页面显示正确;接口返回数据异常时，页面显示正确;调用接口的数据正确即可;

前后端半分离，接口也做测试，但是是使用自动化工具，保证基本的参数正确性与通畅性，而对于接口的逻辑需要前段配合测试。

此时作为前段测试人员，就需要了解接口的实现逻辑，如数据的处理逻辑、存储结构等。据此来设计前段测试用例，必要时也要绕开前段，直接调用接口模拟前段测试。

综上所属，对业务逻辑的理解程度，取决于业务的结构，在理解了业务逻辑后，补充对应需求点的业务逻辑测试点

页面层级的测试遵循以下的方法：

整体界面测试：就是去验证整体的界面是否和设计图一致;

界面元素测试：

控件操作验证：如对控件能否操作、操作是否正常的验证;

业务逻辑(功能)等级的测试遵循以下方法：

任何情况下都必须使用边界分析法，出问题最多的就在边界值;

必要时用等价类划分方法补充一些测试用例;

用错误推测法再追加一些测试用例;

对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

图文来源网络，如有侵权联系删除