四.单元测试与静态白盒测试

1.单元测试

1.单元测试内容

    1.1：模块接口测试

        1.调用所测模块的输入参数与模块的形式参数在个数、属性、顺序上是否匹配

        2.所测模块调用子模块是，它输入子模块的参数与子模块的形式参数在个数、属性、属性上是否匹配

        3.输出给标准函数的参数在个数、属性、顺序上是否匹配

        4.全局变量的定义在各模块是否一致

    1.2：局部数据结构测试

       1.检查不正确或者不一致的数据类型说明

       2.使用尚未赋值或尚未初始化的变量

       3.错误的初始值或者默认值

       4.变量名拼写错误或书写错误

       5.不一致的数据结构

    1.3：路径测试 ，不正确计算

       1.运算的有限次序不正确或者误解了运算的有限次序

        2.运算的方式错误（运算的对象彼此在类型上不相容）

        3.算法错误

        4.初始化不准确

        5.运算精度不够

        6.表达式的符号表示不正确等

    1.4：常见的比较和控制流错误

        1.不同数据类型的比较

        2.不正确的逻辑运算符或优先次序

        3.因浮点数精度问题而造成的两值比较不等

        4.当遇到发散的迭代时不能终止循环

    1.5：错误处理测试

        1.出错的描述难以理解

        2.出错的描述不足以对错误定位和确定出错原因

        3.显示的错误与实际错误不符

        4.如果出错情况不予考虑，那么检查恢复正确后模块可否正常工作

    1.6：边界测试

         1.最小、最大值

          2.第一次循环、最后一次循环

2.单元测试类型

 逻辑单元测试

集成单元测试

功能 单元测试

断言：断言是一个简单的方法调用，用于判断某一个语句是否为真

单元测试的作用：

      1.可以帮助把编码人员代码的可测性

      2.可以使开发人员更有信心重构应用程序，去拥抱变化

 

 

2.集成测试

       也叫组装测试或联合测试，在单元测试的基础上

集成测试范围：

    1.方法：接口：实例变量、类内消息

     2.类：接口：类间消息

     3.簇  接口：类间消息、包间消息

     4.子系统  接口：进程间通信、远程间通信、ORB服务、OS服务

集成测试策略必须回答三个问题：

       1.哪些模块是集成测试的重点

       2.模块接口应该以什么样的顺序进行检测

       3.应该使用哪种测试设计技术检测每个接口

集成测试方法：

       1.非增式测试 ：大爆炸集成测试方法

        2.增式测式：

              1.自底向上增式测试

              2.自顶向下增式测试

 

 

3.静态白盒测试

      是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时也称为结构化分析

      检查和评审代码、文档，需要有编程方面的专业经验

好处：

     1.尽早发现软件缺陷，以找出动态黑盒测试难以发现和隔离的软件缺陷，在开发过程初期让测试小组集中精力进行软件设计的评审非常有价值

      2.为黑盒测试人员在接收软件进行测试时设计和应用测试用例提供思路

正式审查：

    1.确定问题：审查的目的是找出软件的问题，不仅是出错的项目，还包括遗漏的项目。要注意对事不对人

    2.遵守规则：要遵守一套固定的规则，规则可能设定要评审的代码量、花费多少时间、哪些内容要做评价等

    3.准备：每一个参与者都为评审做准备，并尽自己的力量

    4.编写报告：审查小组必须做出审查结果的书面总结报告，并使报告便于开发小组的成语使用

审查方法：

       1.同事审查

       2.走查

       3.代码走查

审查内容：

      1.业务逻辑的审查

      2.算法的效率

      3.代码风格

      4.编程规则

检查：也叫技术评审

编码标准和规范：

     1.可靠性

      2.可重用性/移植性

     3.可读性/可维护性

4.静态黑盒测试

 黑盒测试都是动态测试

静态是指：需求分析、概要分析、详细设计以及程序编码、实施等阶段所得到的文档，包括需求规格说明书、概要设计规格说明书、详细设计规格说明书以及系统（用户）操作手册

静态黑盒测试是测试如下内容：

   1.开发文档：软件需求说明书、数据库设计说明书、概要设计说明书、详细设计说明书、可行性研究报告

   2.用户文档：用户手册、操作手册、维护修改建议

   3.管理文档; 项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告

需求文档测试的必要性：

   1 .软件开发过程中，需求分析是最开始的工作，需求分析如果做得不够详细或者是偏离用户需求的话，往往会给项目带来灭绝性的灾难

   2.用户的表达和需求工程师的理解有时候并不会一致，这样会导致用户所想的和需求说明书上所描述的有偏差

   3.50%以上的缺陷其实是在软件需求阶段被引入的。由于需求编写存在问题，不明确、不清楚、不正确、需求遗漏导致的

需求规格说明书检查列表：

   1.用户覆盖了用户提出的所有需求项

   2.用户是否清晰，语义是否存在有歧义的地方

   3.是否清楚的描述了软件需要做什么以及不做什么

   4.是否描述了软件的目标环境，包括软硬件环境

   5.是否对需求项进行了合理的编号

   6.需求项是否前后一致，彼此不冲突

   7.是否清楚的说明了系统的每个输入、输出格式，以及输入与输出之间的对应关系

   8.是否清楚的描述了软件系统的性能要求

   9.需求的优先级是否合理分配

   10.是否描述了各种约束条件

需求文档规范：

   1.正确性：对照原始需求规格说明书

   2.必要性： 不能回溯到出初的需求项可能是多余的

   3.优先级：恰当地划分并标识

   4.明确性：不能使用含糊的词汇

   5.可测性：每项需求都必须是可验证的

   6.一致性： 内容前后一致

   7.可修改性：良好的组织结构

用户文档测试：

   1.帮助用户正确地安装、使用和维护软件

   2.用户文档测试现状