评估维度：

  1. 方便单元测试
  2. 方便联调测试

谁来测试？

  1. 开发人员自测
  2. 测试人员测试

会有哪些测试内容？

  1. 开发人员
    1. 功能开发
      1. 自己调试
      2. 单元测试
        1. 一般自己编写单元测试代码
      3. 接口测试
        1. 一般自己编写接口测试代码
    2. 功能转测
      1. 与其他模块（前端）联调测试
      2. BVT测试
  2. 测试人员
    1. 功能测试
      1. 手工测试
      2. 自动化测试
      3. 接口测试
      4. 模块测试
      5. 场景测试
    2. 特征测试
      1. 性能测试
      2. 稳定性测试
      3. 兼容性测试
      4. 发布测试

可测试性关注点

指软件程序需要提前做哪些设计（功能、接口、流程、模块拆分、日志、统计等等），来配合上述的测试内容的进行：

保障上述测试内容能够正常进行

  1. 侧重可以做到
  2. 比如程序是否可以最小粒度（每个接口），支持“接口测试”
  3. 比如程序是否可以最小粒度（每个模块，每个模块里面的子功能，每个模块里面的子流程），支持“单元测试”“模块测试”
  4. 比如一些关键数据、内容、状态、统计值等是否可以查看得到，而不是仅存在与程序内存中，支持“自动化测试”“手工测试”

**

保障上述测试内容能够高效进行

  1. 侧重可以高效做到，不需要付出较大代价（人力、流程、设备、时间等等）
  2. 比如一个文件管理系统，测试文件上传功能时，想测试文件是否上传成功
    1. 可存在如下几种测试方式确认：
      1. 通过对应的下载功能看是否能够再完整的下载下来，可以人工模拟操作或者模拟前端提交等 - 人工参与判断
      2. 通过查询对应后台数据库的xxx表的xxx字段等，确认文件已经存储成功 - 进后台
      3. 通过调用提供的后台文件查询接口，直接查询指定名称、指定ID等的文件是否存在 - 调接口
    2. 可见“方式3”的代价应该是最小的，且可以集成进自动化完成一个文件上传功能的测试
    3. 那么提供一个“后台文件查询接口”即是一个有效的针对 “功能性测试” 的 可测试性设计
  3. 比如一个流量处理系统，想测试系统的最大处理带宽能力
    1. 可存在如下几种测试方式确认：
      1. 通过外接其他更高性能的设备，桥接在设备外部，进行带宽统计
      2. 流量处理系统自身提供带宽统计功能，并提供后台统计查询接口，可以直接查询对应处理带宽
    2. 可见“方式2”的代价较小
    3. 那么提供一个“带宽统计功能 以及 带宽查询接口”即是一个有效的针对 “性能测试” 的 可测试性设计

注：如上关注点也即对于测试性的评估维度