联通未来 人.机.管理
编制人：杨超
如何编制测试计划及方案
目录
测试计划、方案设计
测试计划、方案的目的作用
1、在本次培训中,每一个章节我们大概都讲什么内容
2、重点强调”系统流程”是本次培训的重点
一、测试计划、方案的目的作用
用于明确软件产品确认测试过程中的测试组织架构、沟通机制， WBS任务分解法来分解测试任务，安排时间、日程、目标，以使整个测试工作有计划地顺利进行。
用于明确测试任务完成的步骤、人员、进度及输出结果，便于项目经理监控测试进度。
测试方案用于说明某项特定测试工作的一般方法和目标。
目的
一、测试计划、方案的目的作用
软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作展开的基础。
作用
避免测试的“事件驱动”
使测试工作和整个开发工作融合起来
资源和变更事先作为一个可控制的风险
指导测试工作进行
二、测试计划方案设计
、按测试阶段划分设计
二、测试计划方案设计
、测试计划方案设计内容
计划测试工作中，小组成员应该就那些问题达成一致？
软件产品的术语，工作产品以及里程碑的定义
团队之间的责任（组间协调）
测试阶段的划分，测试阶段的开始/停止标准
测试资源要求
每一个测试员的任务分配
版本修改与提交程序的方式/流程/频度/条件
测试工作量和缺陷的度量
测试过程中的风险和问题如何解决
二、测试计划方案设计
、测试计划方案设计内容
根据软件需求规格说明及软件质量需求进行测试设计，内容以下：
确认测试需求，分析测试重点，确定测试范围、测试环境、测试方法、测试工具
测试方式
手工测试
商业测试工具
测试工具
可以使用Rational Robot、WinRunner进行功能测试
使用LoadRunner进行并发性能测试
开发一些测试程序进行定制测试
Urtracker进行BUG缺陷跟踪
二、测试计划方案设计
、测试阶段日程安排设计
测试执行需要多长的时间？
二、测试计划方案设计
、测试阶段日程安排设计
一个简单方法是经验评估。评估方法如下：
1. 计算需求文档的页数，得出系统测试用例的页数
需求页数：系统测试用例页数 ≈ 1：1
2． 由系统测试用例页数计算编写系统测试用例时间
编写系统测试用例时间 ≈ 系统测试用例页数×1小时
3． 计算执行系统测试用例时间
编写系统用例用时：执行系统测试用时 ≈ 1：2
4． 计算回归测试包含的时间
系统测试用时：回归测试用时≈ 2：1
二、测试计划方案设计
、测试阶段日程安排设计
举例说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人；假如一个月为22个工作日，则共计约11人/月，即投入4个人需要3个月左右时间工作量完成。当然，这是系统测试需要的全部时间。根据测试阶段划分原则，设计用例时间可以和开发同步进行，只需在测试阶段中安排的时间为1500小时即4人2个月工作量。
基于以上方法优点是需求为已知的，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况下；
缺点是处于研发状态的项目，需求不清晰的时候比较难计算。
该计算方法的优缺点
二、测试计划方案设计
、计划方案变更的控制
测试计划、方案改变了已往根据任务进行测试的方式，测试计划方案的目的，本身就是强调按规划的测试战略进行测试。在这种情况下，测试计划中强调对变更的控制显得尤为重要。
变更来源于以下几个方面：
项目计划的变更
需求的变更
测试产品版本的变更
测试资源的变更
二、测试计划方案设计
、项目计划的变更
调整测试计划中的测试策略和测试范围
重新检查不重要的测试部分，调换测试的次序和减少测试规模，对测试类型重新组合择优，在限定时间内做最重要部分的测试。
减少进入测试的阻力，降低测试计划中系统测试准入准则；
分步提交测试，改成迭代方式增量测试；
减少回归测试的要求，开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；
和公司QA商量进行简化配置管理，跳过正式发布环节；
缺陷进行局部回归而不是重新全部测试等等。
二、测试计划方案设计
、需求的变更
项目进行过程中最不可避免的就是需求的变更
假使面临一个需求动态的项目，须在计划中对需求变更造成的测试（设计）方式变化进行说明。（例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计；）
最好制定一个变更周期的约定――尤其在执行测试阶段发现需求的变更――定义变更的最大频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。
值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。
二、测试计划方案设计
、测试产品版本的变更
由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成
测试必须是基于一个稳定的“基线”进行，因反复修改造成测试资源和开发资源的浪费是可观的。
明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。
测试计划通常制定了准入和准出准则，要考虑测试暂停。例如：产品错误发布或者服务器数据更新，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，增加暂停测试原则是很有必要的。
二、测试计划方案设计
、测试资源的变更
源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。
没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。
二、测试计划方案设计
、制定测试策略
一个好的测试策略应该包括下列内容：
实施的测试类型和测试的目标
实施测试的阶段
技术
用于评估测试结果和测试是否完成的评测和标准
对测试策略所述的测试工作存在影响的特殊事项
二、测试计划方案设计
、制定测试策略
确定测试策略的一般方法
确定测试的需求
评估风险并确定测试优先级
确定测试策略
二、测试计划方案设计
、确定测试的需求
测试需求所确定的是测试内容，即测试的具体对象。
在分析测试需求时，可应用以下几条一般规则：
测试需求必须是可观测、可测评的行为。如果不能观测或测评测试需求，就无法对其进行评估，以确定需求是否已经满足。
在每个用例或系统的功能需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求；有些功能需求将派生一个或多个测试需求。
测试需求可能有许多来源，其中包括用例、用例模型、补充需求、设计需求、业务用例、与最终用户的访谈和软件构架文档等。应该对所有这些来源进行检查，以收集可用于确定测试需求的信息。
二、测试计划方案设计
、确定测试的需求
测试需求包括：
功能性测试需求
性能测试需求
可靠性测试需求
二、测试计划方案设计
、确定测试的需求
功能性测试需求
功能性测试需求来自于测试对象的功能性行为说明。
每个用例至少会派生一个测试需求。对于每个用例事件流，测试需求的详细列表至少会包括一个测试需求。
二、测试计划方案设计
、确定测试的需求
性能测试需求
性能测试需求来自于测试对象的指定性能行为。
性能通常被描述为对响应时间和资源使用率的某种评测。
性能需要在各种条件下进行评测，这些条件包括：
系统的应用环境、场景、工作量
不同功能下系统的性能要求
不同的配置
二、测试计划方案设计
、确定测试的需求
可靠性测试需求
测试可靠性需求有若干个来源，它们通常在补充需求、用户界面指南、设计指南和编程指南中进行说明。
检查这些工件，对包括以下内容的语句要特别注意：
有关可靠性或对故障、运行时错误（如内存减少）的抵抗力的语句
说明代码完整性和结构（与语言和语法相一致）的语句
有关资源使用的语句
二、测试计划方案设计
、评估风险并确定测试优先级
成功的测试需要在测试工作中成功地权衡资源约束和风险等因素。
确定测试工作的优先级，以便先测试最重要、最有意义或风险最高的用例或构件。
确定测试工作的优先级，需执行风险评估和实施概要，并将其作为确定测试优先级的基础。
二、测试计划方案设计
、评估风险并确定测试优先级
确定测试需求只是确定测试内容的一部分；还应该确定测试内容的优先级和先后顺序，其目的：
1.确保将测试工作的重点放在最适当的测试需求上
2.确保尽早地处理最关键、最有意义或风险最高的测试需求
要评估风险并确定测试优先级，可执行以下三个步骤：
评估风险
确定实施概要
确定测试优先级
评估风险并确定测试优先级的步骤
二、测试计划方案设计
、评估风险并确定测试优先级
将最高的评估因素（风险、实施概要等）值用作总体优先级。
确定一个最有意义的评估因素（风险、实施概要及其他），然后将该因素的值用作优先级。
使用评估因素的组合来确定优先级。
采用权重方案。确定每个因素的权重，然后根据权重来计算各因素的值和优先级。
确定测试优先级的策略
二、测试计划方案设计
、评估风险并确定测试优先级
在开始时可确定并说明将要使用的风险程度指标，例如：
H - 高风险，无法忍受。极易遭受外部的风险。公司将遭受巨大的经济损失、债务或不可恢复的名誉损失。
M - 中等风险，可以忍受，但是不希望其出现。遭受外部风险的可能性最小，公司可能会遭受经济损失，但只存在有限的债务或名誉损失。
L - 低风险，可以忍受。根本不会或不太可能遭受外部的风险，公司只有少许经济损失或债务或根本没有损失。公司的名誉也不会受到影响。
评估风险
在确定风险程度指标之后，可以从三个方面来评估风险：
影响 - 指定用例（需求等）失效后将造成的影响或后果
原因 - 用例失效所导致的非预期结果
可能性 - 用例失效的可能性。
二、测试计划方案设计
、评估风险并确定测试优先级
在开始时可确定和说明将要使用的实施概要程度指标，例如：
H - 使用得相当频繁，在每个时期会使用很多次，或者由多个用例使用。
M - 使用得比较频繁，在每个时期会使用若干次，或者由若干用例使用。
L - 很少使用，或者由很少的用例使用。
所选择的实施概要指标应该基于用例的执行频率，其中包括：
用例在给定时间内执行用例的次数，或者执行用例的数量.通常，用例使用次数越多，实施概要指标也就越高。
在确定实施概要程度指标之后，列出测试对象中的每个用例。为列出的每一项确定一个实施概要指标并且说明每个指标值的理由。性能分析文档中的信息可用于此评估。
确定实施概要
二、测试计划方案设计
、评估风险并确定测试优先级
在开始时可确定和说明将要使用的测试优先程度指标，例如：
H - 必须测试
M - 应该测试，只有在测试完所有 H 项后才进行测试
L - 可能会测试，但只有在测试完所有 H 和 M 项后才进行测试
在确定要使用的测试优先程度指标之后，列出测试对象中的每个用例。为列出的每一项确定一个测试优先级指标并且说明您的理由。
当确定每一项的测试优先级指标时，应考虑下列各项：
先前确定的风险程度指标值
先前确定的实施概要程度指标值
确定测试优先级
二、测试计划方案设计
、确定测试策略
应清楚地说明所实施测试的类型和测试的目标。清楚地说明这些信息有助于尽量避免混淆和误解。测试目标应该表明执行测试的原因。
示例：
“功能性测试。功能性测试侧重于从用户界面上执行在测试对象内实施的以下用例。”
“性能测试。系统的性能测试将侧重于测评用例 2、4 和 8 - 10 的响应时间。”
“配置测试。通过执行配置测试来确定和评估测试对象在三种不同配置下的行为，并根据我们的基准配置来比较性能特征。”
测试类型和目标
二、测试计划方案设计
、确定测试策略
技术
技术应该说明将如何实施和执行测试。其中包括测试内容、在测试执行过程中执行的主要操作以及用于评价结果的方法。
二、测试计划方案设计
、确定测试策略
规定完成标准的目的在于以下两方面：
确定可接受的产品质量
确定测试工作成功实施的时间
表述明确的完成标准应该包括以下内容：
所测评的功能、行为或条件
测评方法
标准或与测评的相符程度
完成标准
二、测试计划方案设计
、确定测试策略
本节应该确定所有会影响测试策略中所述测试工作的影响因素或依赖关系。这些影响因素可能包括：
人力资源（如用来支持/参与测试的非测试资源的可用性或对这些资源的需要）
约束（例如设备限制或可用性，或对特殊设备的需要/特殊设备的缺乏）
特殊需求（例如测试时间安排或对系统的访问）
特殊的考虑事项
谢谢各位！
Thank You！
1、在本次培训中,每一个章节我们大概都讲什么内容
2、重点强调”系统流程”是本次培训的重点
