本文共 3127 字，大约阅读时间需要 10 分钟。

测试设计：

- 测试分析：

• 我们需要做什么？
  1. 把明确的需求点转换成测试项
  2. 缺陷预防
• 怎么做？
  1. 整体模块分析
  2. 逻辑分析【这一点主要是从产品实现的原理上去分析可能的影响】
  • 怎么做？
    • 开发的设计文档
      • 补充和挖掘测试点
      1. 全部服务的异常监控、服务重启
      2. 各类存储对空间的占用、占满、是否需要做存储的接口测试
      3. 所有类型的管理员、操作权限测试、支持的多少管理员并发操作
      4. 对流程图的挖掘 – 流程图全部流程测试、流程图重要的节点异常测试
      5. 对状态的挖掘 – 所有状态的相互转化需要覆盖全、状态转化是否合理、每一个状态下哪些操作可做哪些不可做，多个状态是否可以共存
      6. 对关联项的挖掘 – 流程进展到哪一步关机重启/服务重启、和备份配置的关联，和操作日志的关联等等
      7. 任务的并发操作测试、是否可配置、是否会出现性能不足，是否符合用户场景
      8. 异常处理机制测试，异常处理机制是否完善
      9. 指标测试，开发的指标设计是否合理
      • 修正不合理的需求
    • 如何分析
      • 逻辑原理：
      1. 该模块是否涉及到一些全新的概念(比如我们的 bbc 全量包)，需要明确?
      2. 该模块包括哪些服务?
      3. 该模块涉及到哪些存储技术(如 mysql、dap、redis)?具体怎么存储的?占用大小如何?
      4. 该模块的操作流程有哪些?是否有子流程图?
      5. 该模块是否有多个状态的转化?是否有明确的状态转化图?
      6. 该模块对多个管理员是否区分，管理员权限如何设计?
      7. 该模块是否有一些特殊的操作限制?操作限制是否有明确的表格?
      8. 该模块的任务是否有并发需求?并发的设计?
      9. 该模块的所有指标如何?
      10. 该模块是否有异常处理机制?在设备各种异常时，该模块的设计是否满足能稳健运行?
      • 场景分析
      1. 从用户的使用习惯和使用方法去分析影响
      2. 检查当前案例是否覆盖到用户场景
      • 关联测试分析：
      1. 考虑你的模块所在整个系统的地位，分析上下游的影响
      2. 对老功能的影响
      • 经验补充分析
      1. 版本分析
      2. 模块分析
      • 输出
      1. 测试项
      2. 补充测试地图

- 测试设计：

• 需要做什么？
  1. 把测试项细化成测试点
  2. 缺陷预防
• 需要做什么？
  • 基本设计方法
  1. 等价类划分法【将输入域和输出域划分为不同的等价类，等价类之内的操作结果相同】，使用范围：显示输入框输入
  2. 边界值法【需要结合等价类划分法方法，在划分出来的等价类选取有代表性的值】
  3. 正反对比【一般会放到同一个用例里覆盖】
  4. 字符多样性【考虑不同字符的输入】
  5. 测试类型
  • 产品专项测试
  • 正交组合设计【正交矩阵，覆盖各个参数间的组合情况】
  • 业务逻辑设计【根据业务设计测试点】
• 输出：
  • 基本测试点

- 用例设计：

• 需要做什么？
  • 把测试点用文字完整表述出来
• 怎么做？
  • 功能用例框架：
    • 模块框架模板
      • 需求类
        • UI测试【如果UI用例可以被功能用例覆盖，这里可以不写】
          • 公共测试类：
            • 链接
            1. 选中会有高亮显示
            2. 点击跳转到对应页面
            3. 当前页面对应的名称下有区别显示
            • 翻页
            • 按钮
            • 输入框【这个功能用例一般可以覆盖】
            • 下拉框
            • 排序
            • 条目选择【这个很重要，第一次集成测试一定要保证每个选项都是有效的】
            • 搜索
            1. 所有字符类型验证
            2. 为空验证
            3. 模糊搜索
            4. 精确搜索
            5. 搜索不存在的关键词
            • 刷新
            1. 验证自动刷新
            2. 验证手动刷新
            3. 验证持续刷新
            • 拖动
            • 移动
            1. 点击下移，往下移动一行
            2. 点击上移，往上移动一行
            3. 最上面的行，上移不能点击，图标灰色
            4. 最下面的行，下移不能点击，图标灰色
          • 功能测试
            • 测试点：
            1. 功能基本流程逻辑覆盖
            2. 业务流程多样性覆盖
            3. 用户操作习惯的多样性
            4. 模块配置的多样性
            5. 数据流的多样性覆盖
            • 测试目录
            1. 平级分类相对独立
            2. 上下级分类有关联
            3. 下级从上级细化而来
      • 关联类：
      1. 模块与模块之间的
      2. 模块与功能之间
      3. 模块与硬件之间
      • 场景类
        • 建模思路
        1. 部署方式【比如用户一般使用2主机还是3主机部署集群】
        2. 数据流
        3. 业务流【用户是怎么使用申请工单，是怎么样的完整流程】
        4. 操作顺序【创建云主机的顺序之类的】
        5. 配置方法【用户一般怎么配置使用静态路由】
        6. 使用时间【用户会不会连续长时间开启云主机】
        7. 用户角色【一般那些角色做什么操作】
        • 用户操作的设计方向
        1. 最常用的功能
        2. 最容易出现网上问题的功能
        3. 典型客户使用的功能
        4. 版本的性能验证
      • 专项类
        1. 兼容性

        2. 可靠性【测试产品在异常情况下能否正常工作或者是恢复正常工作，可靠性重点测试对模块自身处理的覆盖】. 补充：容错性测试【测试系统在非正常操作、非正常的外部环境下是否能够处理错误和正常运行】

           eg：

           1. 针对数据库的测试：【磁盘空间不足、数据库文件损坏、无读写数据权限、写数据时断电、写数据时强制关闭mysql、读写速度】
           2. 针对网络设备：【网络中有攻击数据、丢包时延大、IP冲突、网络线路断开、同时掉电】
           3. 针对程序：【 客户端进程被手动停止、设备后台资源cpu、内存占满】

        3. 安全性【主要是验证程序有哪些缺陷可能会造成安全方面的问题】

           eg：
           1. 密码加密方式【什么时候用明文，什么时候用密码显示】
           2. 隐私数据隐藏【用户的隐私显示】
           3. 设备的完整目录【完整的目录会增加后台被攻击的危险】
           4. 文件上传功能【检查上传的文件类型；限制上传文件的权限】
           5. 防暴力破解【对于连线认证之类的操作要冻结、禁用其连续错误尝试操作】

        4. 脚本测试

           • 使用注意细节
             • 文件夹以01-xx，02-xx区分开
             • 每个文件夹下不能超过10个用例
             • 每个测试用例一个测试点
             • 在02-功能测试的描述中，备注说明功能测试框架的思路

-用例整体规范

• 用例标题【好的标题需要准确的表达你的测试目的、要测试的测试点】
  eg：
  • 测试。。。
  • 验证。。。
  • 。。。的测试
  • 与。。。的关联测试
  • 。。。的异常测试
  • 。。。的兼容性测试
• 用例属性

1. 测试环境【默认的前置条件可以不用写；写的前置条件要准确，不要写的模糊】
2. 测试方法
3. 优先级
   • BVT【最最最基本的功能】-BVT(10%)：模块最基本的功能验证(含常用部署、基本关联)，推荐1级用例的20%左右
   • level1【基本操作、基本场景】-Leve1(30%)：基本需求点，基本逻辑，基本可靠性，基本关联，基本用户场景
   • level2【比较少见的正常操作】-Leve2(40%)：常见功能/逻辑细化点/专项细化点，常见关联/容错/边界值/用户场景
   • level3【异常操作；后续不需要再执行】-Leve3(20%)：错误提示、极少测试的用例、非常见部署方式/用户场景/容错/边界值等

• 用例格式

1. 前置条件
2. 测试步骤【单个用例全部步骤不能超过8步】
3. 后置条件【不是必填的】
4. 预期结果
5. 备注【不是必填的】

• 语言规范

1. 语言简练
2. 不能出现模糊的形容词【比如说大概、可能、很多、差不多】

• 可维护性

1. 灵活运用模块备注

• 设计原则

1. 目的明确【一个用例对应一个测试点；测试步骤和测试目的一致】
2. 用例效率
   • 保证设计出来的用例10分钟内可以执行完成；
   • 用例需要的环境可以整理出来，然后写到模块备注中，让执行者先准备好环境一次性执行全部用例；
   • 执行的时候按照测试集方式来执行；
   • 有工具可以实现的用例不要采用脚本方式实现
3. 测试步骤：

• 用户角度
  1. 设计的用例要符合用户的操作顺序和操作习惯
  2. 符合用户的使用环境
  3. 符合用户的配置
• 可执行
  1. 不要出现那种用例设计没有错，但是执行起来很复杂或者是依赖环境很夸张的用例
• 正反对比
  1. 这一点很重要，很多时候我们会把有正反操作的用例分开写，其实是可以合在一个用例里面写
• 强弱关联
  1. 对于强关联的步骤一定要写清楚
  2. 对于弱关联的可以备注或者是不写
• 测试用例不能出现操作步骤
  1. 直接写需要做的操作就可以了

4. 预期结果：

• 用户角度：
  1. 反思用户期望操作完会有什么结果
  2. 反思客户最关注的测试点
• 可检查
  1. 预期结果要可以观察到，不要写的很模糊
  2. 把重点检查的检查点覆盖到
• 用例编写口诀
  1. 强弱正反之业务
  2. 重点突出之效率
  3. 目的明确之语言
  4. 框架覆盖之检查
  5. 逻辑场景之经验

转载地址：http://zzswi.baihongyu.com/