软件测试（黑盒白盒）

软件=程序+数据库+文档+服务

软件测试：

使用人工或自动手段来运行或测试某个系统的过程，目的在于检验其是否满足规定的需要，或是弄清楚预期结果与实际结果之间的差别

软件测试目的：以最小的人力物力和时间找出软件中潜在的错误和缺陷。

测试的基本要求：外观界面测试 易用测试 兼容性测试 安全性测试 性能测试 功能测试

软件测试的原则：

1.尽早地和及时地进行测试，从需求阶段开始介入

软件测试应贯穿软件生命周期

2.测试前应当准备好测试数据和与之对应的预期结果两部分

3.测试输出数据应包括合理的输入条件和不合理的输出条件

4.严格执行测试计划，排除测试的随意性

5.测试用例的所有相关预期结果做全面的检查

6.充分注意测试当中的群集现象

7.保存测试计划，测试用例，出错统计和最终分析报告，为维护工作提供充分的资料

8.缺陷具有免疫性（修改3~4个缺陷，一般都会再产生一个缺陷）

为什么进行软件测试：

提高软件质量    确保软件满足需求

软件测试的发展历程：

第一阶段：初始阶段   第二阶段：定义阶段

第三阶段：集成阶段（软件开发方式逐渐由混乱无序的开发过程过渡到结构化的开发过程）  

第四阶段：管理测量和最佳化阶段

测试环境搭建的原则：真实，干净，无毒，独立

软件测试的三种模式：现场测试模式，内部测试模式，设立联合研发中心模式

测试用例设计的基本原则：数量越少越好，典型性越高越好，对缺陷的定位性越强越好

软件测试分类：

从是否关心内部结构角度：黑盒测试、白盒测试

从是否运行被测程序角度：静态测试、动态测试

从执行时是否需要人工干预角度：人工测试、自动化测试

从软件开发的过程的角度：单元测试，集成测试，系统测试，验收测试

从测试实施组织的角度划分：开发方测试，用户测试，第三方测试

自动化测试适用场合

回归测试 更多更频繁的测试  跨平台的测试  手工测试无法实现的工作  测试过程和验证点比较稳定

不适用场合：

随机性测试 时间短/一次性的项目 需求变化多的项目，软件版本不稳定  涉及与物理设备交互的测试

软件开发模型：软件开发的全部过程、活动、任务和管理的结构框架。它给出了软件开发活动各阶段之间的关系

2.1软件开发生命周期模型（大爆炸模式，边写边改模式，瀑布模型，螺旋模型，敏捷模型）

1. 大爆炸模式

优点：思路简单，通常可能是开发者的突发奇想

缺点：开发过程是非工程化的，随意性大，结果不可预知

测试：开发任务完成后，修复较困难

1. 边写边改模式

优点：简单考虑到了软件的需求，产品周期短

缺点：没有计划和文档的编制

测试工作：由于新的版本不断产生，测试工作长期循环

1. 瀑布模型

需求分析—概要设计—详细设计—编码—测试—上线运行及维护

优点：如同瀑布流水，逐级下落——样式；将软件生存周期各活动规定为依线性顺序联接的若干阶段的模型；易理解，阶段明显，强调需求分析，明确测试阶段，提供了一套模板；文档驱动

缺点：风险大；灵活性差；适应性差；代价大

适合场景：功能、性能明确完整；需求固定，无重大变动

4.螺旋模型

五个步骤：确定目标，选择方案；评估方案，解决风险；本阶段的开发和测试；计划下一阶段；确定下阶段方法；

优点：严格的全过程风险管理；强调各开发阶段的质量；提供机会评估项目是否有价值继续下去。

缺点：很难让用户确信这种演化方法的结果是可以控制的.经常出现无法满足客户需求的情况

5.敏捷模型

以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发

2.2软件测试过程模型（V模型，W模型,X模型，H模型）

1. V模型

特点：动态测试行为应与开发行为对应，每个测试阶段的基础是对应开发阶段的提交物，并通过低层测试确保源代码正确，通过高层测试保证整个系统满足用户需求

局限性：测试滞后，缺少静态测试

1. W模型

特征：静态测试和动态测试行为伴随整个开发阶段，并与开发行为对应，有助于早期发现缺陷、了解项目难度、评估测试风险，并加快项目进度，降低项目成本

W模型局限性：将软件开发看成需求分析、设计和编码等一系列串行的活动；开发、测试之间保持着线性的前后关系，无法支持迭代的开发模型，无法支持变更调整；未体现测试流程的完整性

1. H模型

测试流程应独立于其他流程，且应保持自身的完整性，即测试是一个独立的流程，与其他流程并发进行，且其本身的测试准备和执行活动是分离的，不同测试活动可按某个次序先后进行，也可能是重复的，只要测试准备工作完成，就可以开始测试执行

1. X模型

清晰地体现了单元测试→集成测试→系统测试的过程，该模型还能处理开发中包括交接、频繁重复的集成等工作，更加贴合实际的项目开发流程

综合策略

宏观上以W模型为基本框架，将软件开发和测试作为两个并行的过程，测试伴随整个开发过程

微观上对每个测试阶段则以H模型为指导，进行独立测试，即只要满足测试执行条件就可以进行独立的测试，并反复迭代测试，直至达到预定目标

当项目小组的开发过程中存在诸多不确定因素时(如需求的变更、对缺陷的修复等)，则可利用X模型，针对每个相对独立的系统组成部分，进行相互分离的编码和测试，经多次交接后集成为最终的版本

对于软件企业而言，则应以软件测试成熟度模型(TMM)为指导，努力建立规范的软件测试过程

2.3软件测试流程

软件测试计划：在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试

测试用例：为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果等信息的一个特定集合

搭建测试环境：环境分为：开发环境，测试环境，正式环境

3.1黑盒测试——等价类划分

黑盒测试，又称为功能测试或数据驱动测试。

黑盒测试的优势：方法简单有效；可以整体测试系统的行为；开发与测试可以并行；对测试人员要求相对低

等价类划分法产生的原因:对系统进行穷尽测试是不可能的;使用有限的数据对系统进行测试是可能的;我们可以选择少量测试用例来测试系统，并满足测试是完备的;测试是没有冗余的

等价类测试：依据需求对输入域/输出域进行细分，然后在分出的每一个子集内选取一个有代表性的测试数据开展测试

等价类划分的原理：分而不交、合而不变、类内等价

有效等价类：对于SRS而言，合理、有意义的输入数据构成的集合，即被测对象能接受的数据，用于考查软件的正常工作能力

无效等价类：对于SRS而言，不合理、无意义的输入数据构成的集合，即被测对象不能接受的数据，用于考查软件的容错能力

• 等价类划分的原则：

若输入条件规定了取值范围，且取值范围上、下限之间的数据是有意义的数据，则取值范围内的数据构成一个有效等价类，小于下限、或大于上限的所有数据分别构成两个无效等价类；

若输入条件规定了“必须如何”的条件，则满足必须条件的数据构成一个有效等价类，其他数据构成一个无效等价类；

若输入条件是一个逻辑量，即规定了输入数据的一组值，且系统要对每个输入值分别进行处理，则可为每一个输入值确立一个有效等价类，此外还要针对这组值确立一个无效等价类，它是所有不允许的输入值的集合

用户需求规定必须遵守某种规则时，可规定一个有效等价类及若干个不同角度违反规则的无效等价类