|
一. 风险分析（Risk Analysis）
1. 基本概念
潜伏缺陷（Latent Defect）：一个实际存在但由于触发条件不满足而没有导致系统失效的缺陷。
隐蔽缺陷（Masked Defect）：一个实际存在的缺陷，由于其他缺陷导致它所在的代码没有得到执行，因而没有引起系统失效。风险分析是指识别、估计和评价风险的过程。 软件风险分析的目标：确定测试对象、测试的优先级以及测试的深度。l 理想状况下，风险分析工作应该由交叉学科的专家小组来负责。 （包括开发员、测试员、用户、客户、销售人员和其他 ）风险分析工作应该在软件生命周期内尽早进行。因为需求、资源和其他因素可能会发生变动，必须要在项目进行的过程中时时对分析结果进行评审
3. 风险分析步骤
•步骤1：成立头脑风暴小组，包括最终用户、开发员、测试员、销售人员和业务分析师。
•步骤2：编制系统功能列表 编制系统范围内的特征和属性列表。
•步骤3：确定系统失效的可能性，为失效的可能性赋一个相对值。该特征或属性不能正常运行的可能性有多大？
•步骤4：确定影响，为影响赋一个相对值。如果该特征或特性发生失灵，将会对用户造成什么样的影响？
•步骤5：赋数值，根据在上述第3和第4步所赋的相对值赋数值。
•步骤6：计算风险优先级，将赋给失效可能性和影响可能性的值求和。
•步骤7：评审/修改值，根据复杂性、佩瑞多分析、新的或修改过的特征、开发方法、环境可达性、可使用性和小组历史等信息来评审和修改优先级。
•步骤8：排定特征的优先级，根据风险优先级重新组织特征和属性列表。
•步骤9：确定“分割线”，建立“分割线”，将特征分成“待测”特征和“不予测试的”特征。
•步骤10：考虑缓解风险，决定哪些风险（如果有的话）能够通过增加资源、变换开发方法等方式得到缓解。
二. 测试计划
1. 总体测试计划
总体测试计划：可以是一份独立的文档，也可能被包含到项目计划中、作为其中的一部分。其目的是组织各个等级的测试测试计划是最终形成一份文档的一个过程，它让参与测试过程的各个方面牵涉性的确定测试中的将出现的重要问题，并确定如何以最好的方式处理这些问题。测试计划的目标并不是简单地建立一个冗长的测试用例表，而是处理测试策略、资源利用、职责、风险和优先级等方面的重要问题。
2. IEEE标准829-1998测试计划模板
测试计划标识符
目录表参考文献
词汇表
介绍
测试项
软件风险问题待测特征
不予测试的特征
测试策略
测试项通过/失败标准
挂起标准和恢复需求
测试交付物
测试任务
环境需求
职责
人员安排与培训需求
进度表
计划风险与应急措施
审批
3. 测试覆盖率
代码覆盖率：由一系列测试用例（即一个测试集）执行的程序语句、分支、或者路径的百分比。
需求覆盖率度量的是一个测试集所覆盖的业务需求的百分比；
设计覆盖率度量的是被覆盖的设计的百分比。
接口覆盖率度量的是测试集所执行到的接口的百分比。 走查与审查
走查是对软件产品进行的同行评审，这项工作是通过顺序地“从头到尾走过”（逐行）产品来完成的，以判别被评审产品的质量并发现其中的缺陷。
审查：一项正式的评价技术，由作者之外的其他个人或团队对软件需求、设计或者代码进行详细检查，以便检测出故障、违反开发标准的地方以及其他问题。软件审查的目标是检测和识别软件元素中存在的缺陷。
审查、走查和基于计算机的测试是互为补充的；如果缺少任何一个方面，错误的检测效果都将大打折扣。 5. 配置管理：包括变更管理和评定bug优先顺序的决策过程。如果将代码早早的冻结，测试工作将变得不切实际，因为修复以前发现的bug可能会改变正在被测试的代码。
回归测试是指对以前测试过的特征重新进行测试，以确保变更或者bug修复不会带来新的问题。
确认测试就是重新运行发现过bug的测试，以确保该bug得到完全的、真正的修复。
6. 详细测试计划
普通的项目信息可以用来开发总体测试计划，而更为具体的软件信息则用来开发详细的测试计划。
一个测试等级是由某个环境来定义的，这个环境是由人员、硬件、软件、接口、数据、甚至是测试员的观点组成的集合。
所需测试等级的数量：一般而言，主要取决于系统的复杂性、独特用户的数量、政策、预算、人员配置、组织结构，等等。
共驻软件是指驻留于同一平台的其他应用程序。等级测试计划：需对产品风险问题、资源限制、人员配置和培训需求、进度表、测试策略和其他所有因素进行通盘考虑。
定义一个等级的范围和这个等级打算完成的任务；然后，制定一个计划以确保任务的实现。
7. 验收测试
验收测试就是主要根据用户的需求建立的，并且需要演示说明这些需求已经得到满足的一个测试等级。
读者：用户、客户、系统测试员、开发人员。
时间：验收测试的计划过程应该在较高等级的需求确定之后尽快开始进行。
信息来源：项目计划、总体测试计划和需求文档。 系统测试
•系统测试：测试人员使用全面集成的整个系统，以查找在各种系统操作中的错误。
•读者：测试组成员
•信息来源：需求规格说明、设计文档和用户文档（如果存在这些文档的话）及其他文档等。
•在系统测试中涵盖的域还可能包括：容量、并发、配置、转换、硬件、安装、互操作性、接口、定位、性能、恢复、可靠性、资源使用、可伸缩性、敏感性、软件配置和可使用性。
9. 烟雾测试
烟雾测试是一组用以确定系统处于稳定状态、所有的主要功能都具备并且能够在“正常”条件下运行的测试用例。
烟雾测试不能由测试小组独立来建立；它应该是通过联合的方式，至少是在与开发员达成一致的情况下建立的。
烟雾测试的目标是显示稳定性、而不是发现系统的每个bug。
必须在系统测试环境中运行。
10. 集成测试
集成测试是这样一个测试等级：用来确保系统的各个组件之间彼此能够正确地相互作用和传递数据，并且功能上是内聚的。
集成测试是一种检查系统的各个部分、尤其是各个接口如何组合在一起协调工作的过程。
读者：开发人员
时间安排：设计趋于稳定，开始集成测试计划过程。
驱动就是模拟较高等级的组件的模块，而桩就是模拟较低等级的组件的模块。
信息来源：详细设计规格说明及体系结构的设计规格说明。
11. 单元测试
单元测试过程的建立和文档记录工作应该由开发人员来负责。
缺陷密度是指缺陷与规模的比率。最常见的比率是每千行代码中存在的缺陷数量（KLOC）。
在单元测试过程中的高缺陷密度可能还表明，需要为较高等级的测试分配更多的时间。
如果一个单元测试满足了集成或系统测试级上的一个测试目标，那么就可以为那个目标重用单元测试。 |