五个知识点
1:、软件测试的产生与演进（了解）
- 软件的“泛在性”与可靠性问题
- 软件的缺陷、错误、故障、失效
| 缺陷 | defect |
组件或系统中会导致组件或系统无法执行其必 描述性定义：（1）软件未达到产品说明书中已标明的功能 （2）出现了产品说明中指明不会出现的错误 （3）软件未达到产品说明书中虽未指明但应（隐含）达到功能 （4）软件难以理解，不易使用 （5）软件功能超出软件功能书中说明的范围 |
| 错误 | fault |
软件中自身存在的潜在错误 |
| 故障 | bug | 常指缺陷或错误，将会造成软件使用上的故障 |
| 失效 | failure | 组件/系统与预期的交付、服务或结果存在的偏 差。[与Fenton 一致][GBT 11457] |
- 软件测试定义演进和内涵发展
2、软件测试概要
- 软件测试的目的和原则
| 目的 | 软件测试是以发现的 存在缺陷 、错误为第一目的 、错误为第一目的 ，并藉此对软件的质 ，并藉此对软件的质 量 进行度评价 |
| 原则 | 尽早 和及时的进行测试。活动应从软件产品开发初始阶段就； 充分注意测试中的集群效应 应对测试结果作核查，存档计划、用例缺陷统和分析报告 应对测试结果作核查，存档计划、用例缺陷统和分析报告等文档，为软件运行时的 维护工作提供足够的资料及测试 条件。 |
- 软件测试的基本原理和测试特性准则
| 基本原理 | 原理 1：测试可以证明缺陷存在，但不能证明缺陷不存在 原理 2：穷尽测试是不可能的 原理 3：测试活动应尽早开始 原理 4：缺陷的集群性 原理 5：应对测试用例进行修正或更新。 原理 6：测试依赖于测试内容 原理 7：没有失效就是有用的系统是一种谬论 |
| 特性准则 | 若一个软件系统在一个测试数据（测试用例）集合上的测试是充分 的，那么再测试执行一些测试用例也是充分的，这一特性称作测试的单调性。 即使对软件所有的组成成分都进行了充分测试，也并不能表明整体软 件系统的测试已经充分，这一特性称作测试的非复合性。 即使对软件系统整体的测试是充分的，也并不能证明软件系统中各组 成分都已得到了充分测试，这个特性称作测试的非分解性。 软件测试的充分性应与软件需求及软件实现相关。测试充分性和软 件需 求、实现相关联。 软件越复杂，测试数据需用就越多，这一特性称为测试的复杂性。 测试越多，进一步测试所获充分性增长就越少，这一特性称作测 试回报 递减率。 |
3、基本测试策略与模式
| 1．明确测试目标 | 测试需要对每一阶段和每个部分的目标进行确定。 |
| 2．确认测试对象 | 软件开发过程中产生的需求分析、概要设计、详细设计以及编码等各个阶段所获文档，如需求规格说明、概要设计规格说明、详细设计规格说明以及源程序等都是软件测试的对象。 |
| 3．建立测试生命周期 |  |
| 4．制定和实施测试策略 | （1） 确定测试由谁执行 （2） 确定测试什么 （3） 何时进行测试 （4） 确定怎样进行测试 |
| 5．明确测试类型 | （1） 功能测试（Functional Testing） （2） 非功能性的测试（Non-Functional Testing）：性能测试、 （3） 恢复测试 (Recovery Testing ) ：检查软件系统的容错能力 4） 确认测试 (Confirmation Testing) （5）验收测试（Acceptance testing） ：正式验收、非正式验收和 Alpha 测试、Beta 测试。 （6）回归测试（Regression testing） ：完全重复测试（ 覆盖修改法。 周边影响法， 指标达成法， 选取重要级别高的用例进行回归测试） 选择性重复测试 |
4、软件测试模型分析
| 模型 | 优点 | 缺点 | 流程 |
| 瀑布模型 | （1）易于理解 （2）开发具有阶段性 （3）强调早期的计划及需求分析 （4）基本可确定何时交付产品及进行测试。 |
（1）需求调查分析只在最初进行，不能适应需求的新变化； （2）顺序开发流程使开发经验教训不便进行前向反馈； （3）不能反映出开发过程的反复性与迭代特性，无任何类型的风险评估，出现或隐藏的问题直到开发后期才会显露，失去了及早纠正错误或缺陷机会。 |
 |
| 螺旋模型 | （1）是瀑布方法与边写边改模式的演化、结合形式 （2）随成本增加，风险程度随之降低； （3）具有严格的全过程风 |
（1）对管理水平提出较高要求，需管理者专注及具备管理经验，并需较多人员、资金与时间的投入。 |  |
| RUP 流程（统一软件过程，Rational Unified Process） | 汇集了现代软件开发多方面的最佳经验，并为适应各种软件项目及开 发组织的需要提供灵活形式，作为一种商业开发模型，它具有非常详细的过程指导与应用模板。 |
该开发模型比较复杂，因此在模型的运用掌握上需花费较大的成本，并对项目管理提出了较高的要求。 |  |
| IPD 集成产品开发流程（Integrated Product Development） |
（1）适于复杂、大型软件开发项目，尤其是涉及到软、硬件结合的开发项目 （2）综合考虑了从系统工程、研发（硬件、软件、结构设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。 |
（1）通过流程成本来提高整个产品的质量。 （2）由于该流程没有定义如何进行流程 |
总共划分六个阶段：
四个决策评审点：
|
| 敏捷模式 | 简单、灵活与效率 | 迭代式增量开发过程（Scrum）； 特征驱动软件开发 FDD（Feature-Driven Development）； 自适应开发(Adaptive Software Development）； 动态系统开发方法 DSDM（Dynamic Systems Development Method） 极限编程 XP（Xtreme Programming） 等方法。 |
|
| V模型 | （1）体现“尽早地和不断地进行软件测试”原则 （2）遵循软件验证与确认的原则 （3）测试对象不仅是程序，需求、设计同样需要进行测试（评审），测试与开发 |
（1）需求、设计、编码活动被视为串行 （2）同时，测试和开发活动也保持线性的前后关系，只有上一阶段完成才开始下一阶段活动，因此该模式难于支持迭代方式和不适应开发过程中作变更调整。 |
 |
| W 模型 | V 模型的发展，相对于 V 模型，强调测试伴随整个软件开发周期， 而且测试对象不仅是程序，需求、功能和设计同样要进行测试（或评审），测试 与开发同步，从而有利于尽早发现软件潜在问题。 |
需求、设计、编码等活动被视为串行，同时，测试和开发活动也保持着一种线性的前后关 系，只有上一阶段完成，才开始下一阶段活动，因此，这种模式不支持迭代模式 和不适应开发过程中的变更调整。 |
 |
| X 模型分 | （1）已通过集成测试的成品进行封版，并提交用户， （2）X 模型还定位了探索性测试，帮助有经验的测试人员在测试计划之前，探索发现更多的缺陷。 |
X 模型没有明确的需求角色确认 |
针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序 |
| 测试前置模型 | （1）提供灵活方式，可使软件开发加快进度 （2）用较 |
（1）开发和测试相结合 （2）对每一个交付内容进行测试 （3）包括两项测试计划技术
（4）在设计阶段进行计划和测试设计 （5）前置测试增加了静态审查质量保证）测试 （6）验收测试和技术测试应保持相互独立 （7）反复交替的开发与测试
|
5、软件生命周期与测试流程
- 组件测试
- 集成测试
- 系统测试
- 确认、验收测试
- 变更测试
