第二章 软件测试策略

第二章 软件测试策略

（根据mooc课程所做的笔记）

课程链接

文章目录

• • • 第二章 软件测试策略
    • • 2.1 软件开发过程及模型
      • 2.2 软件测试过程-单元测试
      • 2.3 软件测试过程-集成测试
      • 2.4 静态白盒测试
      • 2.5 静态黑盒测试

2.1 软件开发过程及模型

（此小节熟悉各个模型大概是什么 指数**）

瀑布模型：项目分解为独立的不同阶段，不同阶段具有顺序性和依赖性，每个阶段通过预先定义的输出与下一个阶段发送联系。发现问题则返回上一阶段，一次跳一个阶段知道在某个较早的阶段改正该错误。

优点：简单、易于组织、易于管理、质量保证

缺点 ：不灵活、错误会被逐级放大、返回上一级代价非常大、对于需求不能完全确定的项目风险巨大。

适合：需求分析比较好的系统、二次开发的系统

优点：有助于获取需求、尽早发现错误、支持需求的动态变化、支持风险分析。

缺点：很大程度上依赖于风险评估的成败，需要开发人员具有相当丰富的风险评估经验和专门知识。

适合：需求动态变化、存在资金或时间或技术等风险因素的项目。

V字模型：活动更加并行化，减少时间，可以降低风险。例如概要设计后就可以写系统测试的用例。但实际上还是先编码后测试和瀑布模型没差太多。

优点：增加了同步测试有利于尽早发现问题。

局限性：任然把开发活动看成是从需求开始到编码结束的串行活动不支持迭代以及变更调整。

2.2 软件测试过程-单元测试

（内容不多，熟知 不用背 指数***）

驱动程序：调用被测模块进行单元测试的程序。

桩程序：模拟被测程序调用的程序，会返回给被测程序数据。

单元测试内容：

• 模块接口测试：参数的个数、属性、次序是否正确，调用子模块时输入参数是否正确，输出给标准函数的参数是否正确，全局变量是否正确。

• 局部数据结构测试：是否使用尚未赋值或初始化的变量、不正确或不一致的数据类型说明、错误的初始值或默认值、变量名拼写错误。

• 路径测试：检查各个路径运算次序、运算方式等等是否正确。是一个基本的测试。

• 错误处理测试：对于出错是否正确干预处理。

• 边界测试：测试边界值。

单元测试类型：逻辑单元测试、集成单元测试、功能单元测试。

断言：是一个简单的方法调用，用于判断某个语句是否为真（是个函数、放达）。

单元测试作用：编写单元测试可以使开发人员更有信心重构程序。

2.3 软件测试过程-集成测试

（内容不多，熟知 不用背 指数***）

集成测试范围：

需求文档规范：正确性、必要性、优先级、明确性、可测性、一致性、可修改性。

2.5.3 用户文档测试策略：

2.5.3产品说明书测试：假设自己是用户，研究相关标准和规范 ，审查和测试类似的软件。审查时逐字阅读产品说明书，优秀的产品说明书应当完整、准确、清晰、一直、贴切、合理、代码无关、可测试性，同时应该对术语进行检查，如总是、每一种、当然、明显、显然、以有时等等不明确的词语。

产品说明书：根据与客户沟通，吧系统要解决的业务逻辑、要实现的功能描述清楚，更宏观，重点是站在客户角度将产品功能。

产品规格说明书：从业务规则讲起，细一点偏向于软件的概要设计。把系统的约束、输入、输出和处理过程定义清楚，更具体，包含原型界面、业务接口、活动图等。