51Testing软件测试论坛

标题: 优秀测试用例设计的策略 [打印本页]

作者: 阿蛮的开心姐 时间: 2018-3-26 15:45
标题: 优秀测试用例设计的策略
咱们测试同学日常工作中最为基础核心的内容就是设计测试用例，什么样的测试用例是好的测试用例?我们一般
会认为数量越少、发现缺陷越多的用例就是好的用例。

那么我们如何才能设计出好的测试用例呢?

一份好的用例是设计出来的，是测试人员思路和方法的集合，而非测试逻辑和需求的罗列。

测试用例设计的几个准则

1.用例设计=思路。

强调测试的场景，测试方法。

2.测试步骤化。

此处说的测试步骤，不是说每条测试用例都要写明测试步骤，而是指哪些通过测试步骤的调整会出现缺陷的地方
需要重点关注测试步骤，比如添加操作，单纯的添加功能是OK的，但是先删除一条数据，在添加相同的数据就失
败了，这个就涉及到操作步骤了。

3.用例流程化。

此过程依托于完整的业务流程图，每个分支就是一条支流，通过业务端发起的请求，最终都会流向一条分支，而
流程化就是将这些分支梳理为测试场景，通过覆盖测试场景来覆盖业务逻辑。

测试用例设计的步骤

1.明确原始需求。

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

2.拆分原始需求。

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

3.梳理业务逻辑。

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

接口没有返回数据时，页面如何处理;

接口返回的参数不完整，比如返回包有list结构，此作为前台展示列表数据的依据，但是list为空;

接口返回包中没有需求的参数名称

这个地方有一个原则，需要注意，即前后端分离和前后端测试集合。

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

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

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

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

4.区分页面测试和业务逻辑类测试

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

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

   ·界面元素测试：

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

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

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

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

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

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

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

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)