第二章 软件测试策略
（根据mooc课程所做的笔记）
2.1 软件开发过程及模型
（此小节熟悉各个模型大概是什么 指数**）
瀑布模型：项目分解为独立的不同阶段，不同阶段具有顺序性和依赖性，每个阶段通过预先定义的输出与下一个阶段发送联系。发现问题则返回上一阶段，一次跳一个阶段知道在某个较早的阶段改正该错误。
优点：简单、易于组织、易于管理、质量保证
缺点 ：不灵活、错误会被逐级放大、返回上一级代价非常大、对于需求不能完全确定的项目风险巨大。
适合：需求分析比较好的系统、二次开发的系统
原型开发模型：项目组和客户交互，理解客户需求，然后生成原型，展示最终软件系统的外观以演示工作流和处理逻辑。客户和项目组不断评审原型使项目在一开始就不断获得客户反馈。根据原型生成需求规格说明书，根据该文档进行开发活动，原型将被丢弃。
快速原型模型：相比于原型开发模型，快速原型模型开发的原型迭代开发而不丢弃。
优点：有助于获得用户需求、今早发现错误
缺点：不能支持风险分析、在技术方案上可能影响质量(为了快速开发模型)
适合：开发人员不了解应用领域、客户不清楚需求。
螺旋模型：迭代进行需求获取、设计、编码和测试，如果给定需求有缺陷会使该需求返回到前面的阶段。开发人员在任何时候能演示当时产品所具有的功能，能降低在项目后期发现重大缺陷的风险。
优点：有助于获取需求、尽早发现错误、支持需求的动态变化、支持风险分析。
缺点：很大程度上依赖于风险评估的成败，需要开发人员具有相当丰富的风险评估经验和专门知识。
适合：需求动态变化、存在资金或时间或技术等风险因素的项目。
V字模型：活动更加并行化，减少时间，可以降低风险。例如概要设计后就可以写系统测试的用例。但实际上还是先编码后测试和瀑布模型没差太多。
优点：在验证和确认上有巨大优势。
W字模型：测试伴随整个开发周期，注意测试的对象不仅仅是程序，还包括需求、功能和设计。
优点：增加了同步测试有利于尽早发现问题。
局限性：任然把开发活动看成是从需求开始到编码结束的串行活动不支持迭代以及变更调整。
2.2 软件测试过程-单元测试
（内容不多，熟知 不用背 指数***）
驱动程序：调用被测模块进行单元测试的程序。
桩程序：模拟被测程序调用的程序，会返回给被测程序数据。
单元测试内容：
模块接口测试：参数的个数、属性、次序是否正确，调用子模块时输入参数是否正确，输出给标准函数的参数是否正确，全局变量是否正确。
局部数据结构测试：是否使用尚未赋值或初始化的变量、不正确或不一致的数据类型说明、错误的初始值或默认值、变量名拼写错误。
路径测试：检查各个路径运算次序、运算方式等等是否正确。是一个基本的测试。
错误处理测试：对于出错是否正确干预处理。
边界测试：测试边界值。
单元测试类型：逻辑单元测试、集成单元测试、功能单元测试。
断言：是一个简单的方法调用，用于判断某个语句是否为真（是个函数、放达）。
单元测试作用：编写单元测试可以使开发人员更有信心重构程序。
2.3 软件测试过程-集成测试
（内容不多，熟知 不用背 指数***）
集成测试范围：
集成测试方法：
非增式测试：先分散测试个单元然后再组装起来集成测试。例如大爆炸测试。
-
增式测试：逐步增加单元集成测试，减少了辅助模块。包括：
-
自顶向下增式测试：以主控模块为测试驱动程序，把对主动模块进行单元测试时引入的所有装模块用实际模块代替。依据所选择的集成策略(深度优先、广度优先)每次只代替一个模块，每集成一个立即测试，每组测试完成后才会替换下一个装模块。
简单说：就是从主模块开始测试，测试主模块的桩模块会被逐步替换为实际模块，然后可以把这个实际模块当成子系统的主模块重复该过程。
实际模块逐步替代桩模块
优点：能较早的发现一些主控模块决策机子的问题，适合控制结构清晰、底层不稳定的项目。
缺点：底层用桩模块替代不能反应实际模块情况。替换后才能发现。
-
自底向上增式测试：底层模块组织为实现某个子功能的模块簇，开发驱动模块控制测试输入输出，对每个模块簇进行测试后，删除驱动模块。用高层模块把模块群组织为完成更大功能的新模块群。
简单说：高层及模块逐步替代驱动模块
优点：测试用例写起来简单、底层重用率高的模块重复测试。
适合：底层稳定、高层不确定的项目。
缺点：很晚能看到项目的整体情况。
-
2.4 静态白盒测试
（熟悉 指数 ***）
定义：静态白盒测试指在不执行软件的条件下有条理的仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时也称为结构化分析。
静态白盒测试好处：尽早发现软件缺陷，找出黑盒测试难以发现和隔离的软件缺陷。为黑盒测试提供思路。
正式审查：静态白盒测试的过程，包括程序员之间的交谈岛严格详细的软件设计、代码检查，但是在正式审查前一定要建立正式审查过程。盲目交谈可能更糟。
正式审查的基本要素：确定问题、遵守规则、准备、编写报告。
正式审查的方法：同事审查（你看我的我看你的）、走查（代码走查组，类似代码答辩过程）、检验（技术评审，高度组织化）。
无论方法是否正式都应该满足正式审查的基本要素
审查范围：业务逻辑、算法效率、代码风格、编程规则。
2.5 静态黑盒测试
（ 熟悉 指数 ***）
2.5.1静态黑盒测试内容：开发文档、用户文档、管理文档等
(静态白盒测试检查的是体系结构、代码等而静态黑盒测试检查的是生成的文档)
2.5.2需求规格说明书测试：
需求评审：为了让需求明确、一致，测试人员需要参加需求评审。可以从测试角度提出意见。
需求说明书检查步骤：获取用户原始需求文档和最新版软件需求规格说明书。阅读和尝试理解说明书中的所有需求。对照需求规格说明书检查表进行检查修订。检查表样例：
需求文档规范：正确性、必要性、优先级、明确性、可测性、一致性、可修改性。
2.5.3 用户文档测试策略：
2.5.3产品说明书测试：假设自己是用户，研究相关标准和规范 ，审查和测试类似的软件。审查时逐字阅读产品说明书，优秀的产品说明书应当完整、准确、清晰、一直、贴切、合理、代码无关、可测试性，同时应该对术语进行检查，如总是、每一种、当然、明显、显然、以有时等等不明确的词语。
产品说明书：根据与客户沟通，吧系统要解决的业务逻辑、要实现的功能描述清楚，更宏观，重点是站在客户角度将产品功能。
产品规格说明书：从业务规则讲起，细一点偏向于软件的概要设计。把系统的约束、输入、输出和处理过程定义清楚，更具体，包含原型界面、业务接口、活动图等。
