文档测试介绍

                                           文档测试介绍

 

 

1 以往的开发/测试过程回顾
 1.1 过程
    开发                  测试
     需求分析
  总体设计
  概要设计
  详细设计
  编码                  单元测试
  编码                  集成测试
  编码                  系统测试
 1.2 测试所能发现的问题
  单元测试：代码的功能、性能不符合概要设计、详细设计的要求
  集成测试：代码的功能、性能不符合总体设计、概要设计的要求
  系统测试：代码的功能、性能不符合需求、总体设计的要求
 1.3 缺陷与漏洞
  1.3.1 只能发现代码功能和性能上的不合要求，无法发现代码本身是否与设计相符
   编码人员不按照设计中的算法来实现，而是使用另一种算法
  1.3.2 在编码开始之后才能开始发现问题，而且，涉及面越广的问题，越迟才能发现
   设计时漏了一个功能
   设计有缺陷，不能完全实现相应的功能
   没有设计某些保护性机制（例如服务器与服务器的ping机制、数据同步与纠错机制），从而导致产品的强壮性和可靠性的下降

2 文档测试综述
 2.1 什么是文档测试
  文档测试是指直接针对设计文档和代码文档，检查其正确性的测试。
  2.1.1 针对设计文档的文档测试
   根据设计文档预见到之后的设计和编码过程中可能出现什么问题
   根据设计文档估计出最终代码，根据需求和设计估计出功能测试和性能测试的内容，预见到最终代码将在功能测试和性能测试中可能出现什么问题
  2.1.2 针对代码文档的文档测试
   检查代码与设计是否一致
 2.2 引入文档测试后的开发/测试过程
    开发                  测试
     需求分析
  总体设计              文档测试
  概要设计              文档测试
  详细设计              文档测试
  编码                  文档测试
  编码                  单元测试
  编码                  集成测试
  编码                  系统测试
 2.3 文档测试主要过程
  查看文档
  交流讨论
 2.4 文档测试与以往测试的不同
  以往的测试只能针对代码，文档测试可以针对设计和代码
  文档测试的开始时间更早，可以更早发现问题
 2.5 文档测试与静态测试的不同
  静态测试只针对代码，文档测试也用于设计文档
  静态测试与单元测试一样，是检查代码在功能上的正确性；针对代码的文档测试更注重代码与设计的一致，而代码在功能上的正确性则更多的由针对设计的文档测试来保证
 2.6 文档测试与评审（设计评审、代码评审）的不同
  评审人的范围比较广，可以包括主管、项目经理、其他开发人员等
  评审的时间相对较短
  评审的随意性较大，系统性不强，评审人从各自的角度提出意见
  文档质量较差时，评审人很难提出实质性的意见
 2.7 文档测试的优缺点
  优点：
   能尽早发现问题，降低修复的成本
   提高文档质量，提高设计和编码水平
  缺点：
   对测试人员的要求非常高
 2.8 文档测试的对测试人员的要求
  与文档提供者拥有对等能力
  2.8.1 设计文档的文档测试的要求
   有设计同样项目的能力
   有编程能力，至少会使用一种高级语言（C/C++、java、VB、Pascal）
   对功能测试和性能测试有较深入的认识
  2.8.2 代码文档的文档测试的要求
   有编程能力，懂得该代码语言
 2.9 文档测试的适用范围
  研发流程比较规范
  项目工期不是太紧
  要有高水平的测试人员

3 文档测试的检查点
 3.1 对于总体设计的检查点
  检查需求中规定的功能点如何实现
   需求中列出的所有功能点都能实现
  检查需求中规定的性能指标如何保证
   需求中列出的所有性能指标都能保证
  检查普遍性的功能点（强壮性、容错性、安全性）如何实现
   系统部分失效（断线重连、断线重启）
   异常的输入数据
   异常业务量（零负荷、超负荷）
   非法入侵
  检查普遍性的性能指标（可靠性、稳定性）如何保证
   业务处理能力
   业务预期响应时间
   最大支持用户数
  检查模块定义是否正确
   模块的功能描述明确
   模块与模块的关系与现实关系一致
 3.2 对于概要设计的检查点
  检查功能点（包括接口）如何实现
   界面的输入项齐全
   界面的输入项的数据类型、输入方式正确
   界面的输出项齐全
   界面的输出项的数据类型、输出方式正确
   接口的输入参数齐全
   接口的输入参数的数据类型正确
   接口的输出参数齐全
   接口的输出参数和返回值的数据类型正确
   接口的输出参数和返回值能反映异常情况
   本模块与其他模块的通讯与总体设计一致
   算法和流程正确
  检查性能指标如何保证
   算法和流程高效
  检查类定义是否正确
   类的功能描述明确
   类不可以再分为两个类
   类与类的关系与现实关系一致
   没有使用友类
   属性只定义为protected或private（用作数据包的类除外）
   属性与类的关系与现实关系一致
   类提供的每个功能都只对应一个方法
   类的每个方法都只提供一个功能
   没有使用友函数
   引用和指针类型的输入参数使用const定义
   方法的输出参数和返回值能反映异常情况
  检查数据库定义是否正确
   表的功能描述明确
   一个表只保存同一类数据
   同一类数据只保存在一个表中
   字段的功能描述明确
   界面或系统外部接口中需保存的数据都有字段对应
   与界面中非必填数据对应的字段定义为null
  检查多线程机制是否完善
   线程数不会过多
   线程被正确地生成与释放、启动与结束
   线程间的数据交互正确
   多个线程都访问到的资源有锁机制保护
   锁被定义为某个类的属性，只在该类的方法中被使用，而且加锁和解锁必须在同一个方法当中成对使用
   不会死锁
  检查数据流转是否正确（把各个概要设计结合起来，按照功能点来检查）
   数据从界面或系统外部接口输入，能通过各种接口在各模块间传递，并最终在界面或系统外部接口输出
   数据从界面或系统外部接口输入，能通过各种接口在各模块间传递，并最终保存到数据库
   数据从数据库读出，能通过各种接口在各模块间传递，并最终在界面或系统外部接口输出
   数据从数据库读出，能通过各种接口在各模块间传递，并最终保存到数据库
 3.3 对于详细设计的检查点
  检查类实现是否正确
   输入正常的数据并经过正常的处理能得到正常的结果
   输入异常的数据或处理过程中出现的异常能在输出参数或返回值中反映，或抛出异常
  检查类实现是否容易理解
   函数或方法用于正常处理的逻辑分支（循环和分支语句的个数）不会过多（最好5个以内，尽量不超过10个）
   函数或方法用于正常处理的操作不会过多（最好8个以内，尽量不超过15个）
   函数或方法将产生的代码行不会过多（最好30行以内，尽量不超过60行）
 3.4 对于代码的检查点
  检查设计中规定的类和方法是否正确定义
   类齐全
   方法齐全
   输入参数齐全
   输入参数的数据类型正确
   输出参数齐全
   输出参数和返回值的数据类型正确
  检查代码中的算法和流程是否与设计一致
   设计中的流程分支有对应的代码分支
   代码中不存在多余的分支
   设计中描述的步骤有对应的代码
   设计中描述的步骤有对应的注释
  检查纠错机制是否完善
   函数或方法的开始处有检查输入参数的合法性
   调用函数或方法前有检查输入参数的合法性
   调用函数或方法后有检查输出参数和返回值的合法性
   指针操作前有检查指针是否为空
  检查异常处理机制是否完善
   函数或方法可能抛出的所有异常都有处理
   未知的异常也有处理
  检查数据初始化有否进行
   局部变量有初始化
   类属性有初始化
   全局变量有初始化
   内存申请后有初始化
  检查代码的可读性、可修改性
   文件名、类名、属性名、方法名、变量名、常量名等等命名符合规范
   代码的缩进符合规范
   代码的注释符合规范
   类的声明符合规范
   函数或方法用于正常处理的逻辑分支（循环和分支语句的个数）不会过多（最好5个以内，尽量不超过10个）
   函数或方法的代码行不会过多（最好30行以内，尽量不超过60行）
   各种特定的值被定义为常量
   函数或方法的输入参数和输出参数没有被作为工作变量使用