总结、探寻我所理解的测试策略，输出可执行的文案，只为回首往事时不因虚度年华而悔恨，不因碌碌无为而羞耻。
作为测试，发现缺陷的多少、发现缺陷严重性的高低可以作为衡量其能力的一个重要指标，那么如何才能发现尽可能多的权限，如何才能更早的发现严重性高的缺陷呢？我的理解是依托测试用例设计。
作为测试，日常最常见的一项工作就是设计测试用例，什么样的测试用例是好的测试用例？我的理解是数量越少、发现缺陷越多的用例就是好的用例，好的用例是设计出来的，是测试人员思路和方法的集合，而非测试逻辑和需求的罗列。
那么问题来了，如何才能设计出好的测试用例呢？
一、测试用例设计的几个准则：
1.用例设计=思路。强调测试的场景，测试方法。
2.测试步骤化。此处说的测试步骤，不是说每条测试用例都要写明测试步骤，而是指哪些通过测试步骤的调整会出现缺陷的地方需要重点关注测试步骤，比如添加操作，单纯的添加功能是OK的，但是先删除一条数据，在添加相同的数据就失败了，这个就涉及到操作步骤了。
3.用例流程化。此过程依托于完整的业务流程图，每个分支就是一条支流，通过业务端发起的请求，最终都会流向一条分支，而流程化就是将这些分支梳理为测试场景，通过覆盖测试场景来覆盖业务逻辑。
二、测试用例设计的步骤：
1.明确原始需求。
原始需求是软件的使用者(客户)的需求，在需求文档基础+本质理解才能真正理清楚需求要实现什么样的目的，以此为出发点才能不偏离需求本质；
2.拆分原始需求。
在需求测试阶段，如果按照需求测试策略对需求梳理一遍之后，对于所有的需求点应该都已经很清楚了，将这部分的需求点罗列出来，就可以作为需求粗的测试点；
3.梳理业务逻辑。
现在比较多的前端业务都来源于接口所返回的数据，前端最多的时候也就是根据返回数据做一些响应的显示和计算，所以如果对页面设计测试用例，那么需要关注接口数据的完整性和正确性对页面的影响，而接口本身的测试则要归纳到接口测试用例设计环节。
（1）.接口没有返回数据时，页面如何处理；
（2）.接口返回的参数不完整，比如返回包有list结构，此作为前台展示列表数据的依据，但是list为空；
（3）.接口返回包中没有需求的参数名称
这个地方有一个原则，需要注意，即前后端分离和前后端测试集合。
（1）.前后端分离，有专门的接口测试人员来保证接口功能的正确性。此时作为前段测试人员，只需要保证接口返回数据正确时，页面显示正确；接口返回数据异常时，页面显示正确；调用接口的数据正确即可；
（2）.前后端半分离，接口也做测试，但是是使用自动化工具，保证基本的参数正确性与通畅性，而对于接口的逻辑需要前段配合测试。此时作为前段测试人员，就需要了解接口的实现逻辑，如数据的处理逻辑、存储结构等。据此来设计前段测试用例，必要时也要绕开前段，直接调用接口模拟前段测试。
综上所属，对业务逻辑的理解程度，取决于业务的结构，在理解了业务逻辑后，补充对应需求点的业务逻辑测试点。
4.区分页面测试和业务逻辑类测试
4.1.页面层级的测试遵循以下的方法：
（1）.整体界面测试：就是去验证整体的界面是否和设计图一致；
（2）.界面元素测试：
（3）.控件操作验证：如对控件能否操作、操作是否正常的验证；
4.2.业务逻辑(功能)等级的测试遵循以下方法：
（1）.任何情况下都必须使用边界分析法，出问题最多的就在边界值；
（2）.必要时用等价类划分方法补充一些测试用例；
（3）.用错误推测法再追加一些测试用例；
（4）.对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流，
图1 场景发基本图
图2 银行卡取钱场景法
网友评论