简介

  一般情况下我们在写测试用例的时候，虽然存在很多设计用例的方法，比如等价类分析法，场景法，错误推测法等等，但是其实好多时候都是想到了才用上，并没有比较规范和具体的思路，以此尝试规范一套个人设计测试用例的流程，以后续进行测试设计用例的时候进行查看。

设计用例步骤

1. 使用场景法，把基本流写出来，在补充备选流（以整体的形式看需求）。

      个人理解就是把这个需求要实现的最终目主流程写出来，并且尽量详细步骤，细化到点击，输入数据等。
    然后再按照流程中存在条件分支等，抽选出多个备选流。
    
    这里的话个人觉得还是会漏掉一部分模块的功能，比如说新增一个课程上架到网站，有时候并不会需要编辑等功能。
   

2. 从需求部分功能的角度编写测试用例，比如一个问答功能列表，由新增、编辑、删除、禁用启用等不同的功能部分组成，针对每一个部分细化测试用例（以部分的形式看需求，不细化到字段）。

    以针对一个部分来说，编辑，新增，删除。可以考虑以下的情况：
        1.是否可以重复操作
        2.操作后的影响模块
        3.操作是否存在前置条件
    
    比如删除功能的前置条件，是数据的状态为禁用等，删除和禁用启用是互相影响的
    禁用启用也是可以重复操作的，在操作禁用启用的时候，可能还会存在其他的影响模块，以及前置条件等
   

3. 从字段的角度来完善测试用例

    比如说新增问答里面的字段可能有：编号、标题、序号、状态、题干等
        1.字段的数据来源：比如编号系统自动生成，标题为手动输入，或者存在其他来源回显
        2.字段的类型和范围：比如序号只支持正整数，就可以等价类，边界值，以及输入其他的数据类型验证
        3.考虑字段的属性：必填，初始值等
        4.考虑字段的影响和使用范围：比如序号和标题可在页面回显，也可以在前端回显等，是否会影响
        5.字段是否可变：变化的影响范围，前提条件，限制条件等
   

4. 从页面搭建的角度来完善测试用例

    比如说一个页面出现，是由很多个不同的部分和数据组合起来的。
    想象一个页面在为空的情况下从零由不同的部分组合起来，这个时候其实会考虑到不同的方面。
        1.数据一个一个叠加起来的时候，由你搭建页面，你可能会考虑到数据的（摆放，顺序）
        2.数据由哪里来，会进行相应模块的联想
   

5. 从运行的环境角度来完善测试用例

    如果经过以上的几种角度，我个人觉得，测试用例其实也差不多可以覆盖一部分了。
    接下来还可以从我们业务需求的运行环境上来考虑对我们功能的影响：
        1.首先从第三方承载来考虑，如果是网页，那么就是浏览器，如果是app，那么就是手机
        2.另外一个考虑点就是网络，在不同的网络情况下也会不一样
        3.以及从不同的硬件设备下，运行的情况
        4.不同的操作系统
   

6. 整理测试用例和结合

    其实上面的很多种角度，我们都可以使用思维导图大概的写出不同角度的测试点，然后在结合起来。
    为了避免太多重复的路径，我们多个测试点，可以附带在一条测试路径上，这样才能在更快的进行测试以及提高效率
   

总结

  目前经验还不足，只能由以上的几种角度来逐渐完善自己设计测试用例的思路和流程，但也算是往好的一种方向开始发展，后面会逐步进行完善和整理。