软件测试过程及方法指南
-
软件测试过程及方法指南
最近总有人询问测试计划的编写方法和步骤，
如何合理的设计测试计划是
每个测
试经理
的责任，测试中需要关
注的要素太多了，既有技术方面的考虑，也有管
理方面的考虑，如何
才能设计出实用的测试计划呢？我根据自己的经验，理出
一份软件测试计划编写指南，
希望对大家有所启示，
并同大家交
流测试中的心得
和方法。
1
前言
1.1
软件测试的目的
软件测试的目的决定了如何
去组织测试。如果测试的目的是为了尽可能多地
找出错误，
<
/p>
那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多
的位置。如果测试目的是
为了给最终用户提供具有一定可信度
的质量评价，那
么测试就应该直接针对在实际应用中会经常用到的商业假设。
不同的软
件项目会有不同的测试目的；相同的软件项目，不同的时期也可能
有不同测试
目的，可能是测试不同区域或是对同一区域的不同层次的测试。
软件测试：
①、软件测试是为了发现错误而执行程序的过程；
②、测试是为了证明程序有错，而不是证明程序无错误。
③、一个好的测试用例是在于它能发现至今未发现的错误；
④、一个成功的测试是发现了至今未发现的错误的测试。
这种观点可以提醒人们测试
要以查找错误为中心，而不是为了演示软件的正
确功能。
但是仅
凭字面意思理解这一观点可能会产生误导，
认为发现错误是软件
测试的唯一目，查找不出错误的测试就是没有价值的，事实并非如此。
首先，测试并不仅仅是为了
要找出错误。通过分析错误产生的原因和错误的
分布特征，可以帮助项目管理者发现当前
所采用的软件过程的缺陷，以便改进。
同时，
这种分析也能帮助
我们设计出有针对性地检测方法，
改善测试的有效性。
其次，没有发现错误的测试
也是有价值的，完整的测试是评定软件质量的一
种方法。
对于测试数据的动态积累可
以给项目管理者展示出当前项目的实时状态，为
科学的决策提供有力的保障，
并且为今后的培训，
考评，
工作的检查等提供强有
力的数据基础。
1.2
软件测试的复杂性和经济性
人们常常以为，开发一个程
序是困难的，测试一个程序则比较容易。这其实
是误解。
设计测
试用例是一项细致并需要高度技巧的工作，
稍有不慎就会顾此失
彼，
发生不应有的疏漏。
不论是黑盒测试方法还是白盒测试方法
，
由于测试情况
数量巨大，
都不可能进
行彻底的测试。
所谓彻底测试，
就是让被测程序在一切可
能的输入情况下全部执行一遍。通常也称这种测试为
“
穷举测试
”
。
“
黑盒
”
法是
穷举输入测试，只有把所有可能的输入都作为测试情况使用，
才能以这种方法
查出程序中所有的错误。
实际上测试
情况有无穷多个，
人们不仅要测试所有合法
的输入，而且还要对
那些不合法但是可能的输入进行测试。
“
白盒
”
法是穷举路
径测试，
贯穿程序的独立路径数是天文数字，
但即使每条路径都测试了仍然可能
有错误。
第一，
穷举路径测试决不能查
出程序违反了设计规范，
即程序本身是个
错误的程序。第二，穷
举路径测试不可能查出程序中因遗漏路径而出错。第三，
穷举路径测试可能发现不了一些
与数据相关的错误。所以说：
“
程序测试只能证
明错误的存在，但不能证明错误不存在
”
。
在实际测试中，穷举测试工作量太大，实践上行不通，这就注定了一切实际
测试都是不彻
底的。
当然就不能够保证被测试程序中不存在遗留的错误。
软件
工
程的总目标是充分利用有限的人力和物力资源，
高效率、
高质量地完成测试。
为
了降低测试成本，选
择测试用例应注意遵守
“
经济性
”
的原则。第一，要根据程序
的重要性和一旦发生故障将造成的损失来
确定它的测试等级；
第二，
要认真研究
测试策略，
以便能使用尽可能少的测试用例，
发现尽可能多的程
序错误。
掌握好
测试量是至关重要的，
一位有经验的软件开发管理人员在谈到软件测试时曾这样
说过：
“
不充分的测试是愚蠢的，而过度的测试是一种罪孽
”
。测试不足意味着让
用户承担隐藏错误带来的危险，过度测试则会浪费许
多宝贵的资源。
测试是软件生存期中费用消耗最大的环节。
测试费用除了测试的直接消
耗外，
还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下：
①、系统的目的
系统目的的差别在很大程度上影响所需要进行的测试的
数量。那些可能产生
严重后果的系统必须要进行更多的测试。
②、潜在的用户数量
一个系统的潜在用户数量也
在很大程度上影响了测试必要性的程度。这主要
是由于用户团体在经济方面的影响。
③、信息的价值
在考虑测试的必要性时，还需要将系统中所包含的信息
的价值考虑在内，一
个支持许多家大银行或众多证券交易所的客户机
/
服务器系统中含有经济价值非
常高的内容。
很显然这一系统需要比一个支持鞋店的系统要进行更多的测试。
这
两个系统的用户都希望得到高质量、
无错误的系统，
但
是前一种系统的影响比后
一种要大得多。
因此我们应该从经济方
面考虑，
投入与经济价值相对应的时间和
金钱去进行测试。
④、开发机构
一个没有标准和缺少经验的开发机构很可能开发出充满
错误的系统。在一个
建立了标准和有很多经验的开发机构中开发出来的系统中的错误不会
很多，
因此，
对于不同的开发机构来说，所需要的测试的必要性
也就截然的不同。
然而，那
些需要进
行大幅度改善的机构反而不大可能认识到自身的弱点。
那些需要更加严
< br>格的测试过程的机构往往是最不可能进行这一活动的，
在许多情况下，
机构的管
理部门并不能真正地理解开发一个高质量的系统的好处。
⑤、测试的时机
测试量会随时间的推移发生
改变。在一个竞争很激烈的市场里，争取时间可
能是制胜的关键，
开始可能不会在测试上花多少时间，
但几年后如果市场分配格
局已经建立起来了，
那么产品的质量就变得更重要了，
测试量就
要加大。
测试量
应该针对合适的目标进行调整。
1.3
文档介绍
1.3.1
本文档的受众
测试计划编写指南有两类潜
在的受众。首先，测试经理使用它作为指导方针
编写测试计划。
测试计划编写完成后，
将作为整个团队
（包括开发人员和测试人
员）沟通的基础。
1.3.2
文档更新
测试项目开始时，应该完成
测试计划的大部分内容。项目开始后，由于测试
情况有变化，
可
能导致测试计划文档变化。
如果文档有明显的变化，
必须在文档
中添加变更历史来记载这些变化。
1.3.3
文档目的
测试计划在策略和方法的高
度说明如何计划、组织和管理测试项目。测试计
划包含足够的信息使测试人员明白项目需
要做什么是如何运作的。
另外，
清晰的
文档结构能使任何一个读者在浏览计划的前面几页后，
就能对项目有一个大概的
认识。
测试计划只是测试的一个框架，
很多细节
需要跟开发人员或其他人员沟通，
因此计划不包括测试用例的细节和系统功能的详细信息
。
本文档描述出了整个开发过程中测试工作的流程，不同的测试时期可以根据
需要对本
文档的一部分进行充实（如：单元测试阶段等），但是在结项后，本文
档规定的各个时期
的测试计划均需完整，
以备检查。
对于项目类产品，
可根据实
际情况参照执行。
1.4
测试工作流程
测试工作从产品立项后开始介入，贯穿于软件产品的整
个生命周期。初期测
试经理参与项目的需求评审，
并以需求设计
为标准设计系统测试的测试用例。
当
开发进入详细设计阶段时，
测试经理根据测试的需要同开发经理讨论技术的实现
方式，
在允许的范围内，
尽量使用方便今后测试工作开展的实现方式。
同时此阶
段测试经理开始设计集成测试的测试用例。
详细设计评审通过后，
开发人员开始
进入编码阶段，<
/p>
同时，
测试经理应同开发经理协调好进度，
按照模块开发的时间
规划，
测试经理开始根据模块的接口规范
设计灰盒测试用例，
尽量保证模块级的
测试可以同开发进度协调
进行。
编码完成后，
测试人员协助开发人员进行集成测
试，
测试经理使用前期已经完成的集成测试方案对产品进行测试。
集成测试完成
后，
由测试经理对集成测试的效果进
行评估，
对于合格的产品填写系统测试申请
报告，
向测试部正式申请进入系统测试阶段。
系统测试完成后，
由测试经理向测
试部申请软件发行。
当相关的产品化工作正
式完成后，
由测试部开据质量合格证
书，产品正式发行。
以上
概要的介绍了测试方法和测试原则，以及公司对于产品类项目的测试流
程，
以下将具体的给出各个测试阶段，
相关测试计划的文档要求，
文档中将给出
关键的考察点，
计划编制的技巧与说明，
以便在书写测试计划的时候有章可循。
2
引言
2.1
编写目的
阐明编写测试计划的目的并指明读者对象。
2.2
项目背景
说明项目的来源、委托单位及主管部门。
2.3
定义
列出测试
计划中所用到的专门术语的定义和缩写词的原意。
2.4
参考资料
列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：
项目的
计划任务书、合同或批文；项目开发计划；需求规格说明书；概要设计说
明书；详细设计
说明书；用户操作手册；本测试计划中引用的其他资料、采用的
软件开发标准或规范。<
/p>
2.5
文档摘要
主要说明测试计划中重要的和可能有争议的问题。本节
的主要目的是将这些
信息传递给那些可能不会通读整个测试计划文档的人员
（比如经理或开发项目的
负责人）。
提示和技巧：
在写这一节时，考虑一下你的计划在那些地方可能会引
起反对。这个计划跟
以前的计划相比，有什么不同的地方。测试项目与系统开发计划的关
系等。
使用列表的格式，可以将问题按重要程度罗列出来，然后在后面的章节中再
对这
些问题进行详细说明，
这样就能让对这些问题有重要影响的人员知道问题的
所在。
2.6
文档历史和变更
[
作者
]
–
[
日期
]
–
[
文档的当前状态，上版本以来所作的主要变化
]
3
管理
3.1
系统视图和目标
系统视图对测试人员了解自己需要做什么是非常重要的
。测试项目负责人应
积极与系统设计人员或开发人员沟通，
以取
得相关资料。
系统目标是帮助实现系
统视图的重要指标。
系统视图和目标对实现整个项目计划来说是至关重要的。
测
试人员必须知道系统是做什么并且帮助项目实现这种目标。
在计划中包括系
统视
图和目标后，要确保所有的测试人员都知道项目和系统的目标。
通常情况下视图和
项目计划都是模糊的。模糊的目标必须通过成员的努力转
换成可衡量和实现的东西。
没有固定的视图和目标，
你将无法完成部分任务。
< br>而
且，你会发现很难将对产品的认识向别人转述。
提示和技巧：
为什么视图对客户是重要的？
你如何向客户表达这种视图？
你将做什么来保证你是在向实现视图的方向前进
?
在你回答这些问题之后，你
就可以将视图转换成测试导向的目标？
整个系统的总体运行框架什么？各个部分的运行目标是什么？
3.2
运行环境
需测试的软，硬件环境，有无特殊的要求。如有些设备
是有使用时限的需注
明，如果测试环境不能满足测试要求，如何解决等？
3.3
资源需求
3.3.1
培训需求
本节说明项目测试人员需要哪些培训。
提示和技巧：
对于新手需要先介绍测试系统，如果测试人员比较熟悉
该系统，则需要说明
新系统的功能。
是否进行自动测试。
测试人员要不要培训以编写自动化脚本。
3.3.2
硬件需求
本节说明测试人员需要的各种类型的硬件以及这个测试
团队需要的硬件。
3.3.3
软件需求
本节说明测试人员需要使用的软件。
3.3.4
办公空间需求
本节说明需要多少办公空间。
3.4
风险分析
目前存在那些不确定因素，包括可预计的和不可预计的
。系统开发和测试过
程中，
会有各种可能导致系统发布延迟，<
/p>
在计划中需要预先估计这些风险，
并且
提
出相应的对付办法。
3.5
测试团队结构
这一节说明测试团队的结构和项目测试人员的数量。
提示和技巧：
查看开发计划确定那些功能需要最多资源。
在各个测试阶段确定需要多少测试人员，各需掌握那些技巧。
多少人做自动测试，是哪些人。
列出项目参与人员的联系方式包括
E-mail
和电话。
3.6
相关信息保存的位置
测试服务器的相关信息；
测试文档保存的位置；
测试工具保存的位置；
测试中需要使用的软硬件的存放地点；
Bug
如何记录，存放的位置。
3.7
测试时间安排
包括主要时间点的安排，如各个测试阶段的开始，截至
日期，产品预计发布
日期等。
3.8
缺陷处理
测试过程中可衡量的是发现
的缺陷的状况。因此缺陷的报告和管理必须写成
书面文档。
3.8.1 Bug
数据库管理
提示和技巧：
谁负责创建数据库？
谁有权限增加数据库的帐号？
谁有权使用哪类帐号？
数据库使用过程中出了问题和谁联系？
谁负责数据库备份？
多长时间备份一次？
由谁使用数据库？
缺陷管理应该与开发部门的负责人一起讨论。
3.8.2
缺陷处理过程
提示和技巧：
解释缺陷报告和分配过程。
缺陷标题、测试环境应如何填写。
解释如何输入，解决，重新打开，关闭和重新即或一个缺陷。
让测试人员清楚一个缺陷从击活到解决的全过程。
缺陷必须指定由谁负责解决。
定义优先级、严重级别等。
在项目结束时，如何解决这些缺陷。
如果有
Bug
管理工具，只需遵照工具的流程执行。
3.9.
测试过程控制
在测试过程中，通过对缺陷
数据库进行分析可以确定测试的状态。另外，通
过让测试人员填写测试工作周报，可以对
项目进展状况进行反馈。
3.9.1
缺陷数据分析
提示和技巧：
在开发过程和稳定阶段是否有过多的未处理缺陷，这可
能说明开发的资源不
够，或者有其它问题。
如何确定项目中是否有过多的缺陷。
测试人员是否积极发现缺陷，或者过分积极。
在每个时间点上，系统是否稳定。
系统哪些部分的缺陷最集中。
在系统发行时修复了多少缺陷。
哪些类型的缺陷最普遍。
3.9.2
测试工作周报
提示和技巧：
周报中应包括哪些信息。
如何填写工作周报。
谁负责查看工作周报。
以上详细的描述了，测试过程中可能遇到的或者必须提
前安排的工作内容，
有一些项是要在工作过程中陆续充实的，
有
一些是需要提前给出解决办法的，
在
制定计划过程中，请依据实
际情况进行书写。
4
测试计划
4.1
整体测试策略
本节的目的是说明计划中使用的基本的测试过程。
提示和技巧：
是否使用里程碑技术和在测试过程中验证每个模块？或
者是什么都不做，只
是普通的测试而已。
测试人员是否在项目开发初
期就开始工作？或者测试人员只在系统开发完后，
才开始测试。
是否明显的界定出单元，集成，系统，验收测试阶段？
自动测试工作是否进行？
对于像压力，性能，兼容性等的测试项目，放到那一个
测试区间内，有什么
质量要求？
4.2
测试范围
通常说明什么是要测试的，
什么是不要测试的是非常重要的。明确规定这些
问题后，测试人员对该做什么有一个清晰
的认识。
提示和技巧：
需要特别测试那些部分？
那些部分不需要测试，为什么？
测试人员是否需要测试内容以及相关部分？
是否要验证每个模块的稳定性？
是否有理论上应该测试的，但是测试环境无法进行测试的内容？
对于产品附带的文档，测试人员是否需要检查？
4.3
质量目标
围绕软件质量，有几种不同的说法。第一个是质量是一
种绝对的标准，对所
有的系统必须等同处理。
事实上，
质量是相对的而且是和产品相关的概念。
例如，
多媒体产品的质量目标倾向于精美的表示和适当的内容，
而应用系统可能倾向于
易用性、
健壮性和适用于不同的任务。
质量目标
可能是动态的。
在项目进行过程
中，会由于市场压力、新的机会
和功能改变而重新设定质量目标。
另一种有关软件质量的说法是，定义和衡量系统质量是
测试部门一个部门的
事。实际上，建立质量标准是所有职能部门共同努力的结果。测试、
开发、系统
使用部门、
用户教育、
系统
支撑必须为建立和维护系统的质量标准做出自己的贡
献。
每个部
门必须对自己最了解的部分做出相应的质量定义。
例如，
测试和
开发
部门对系统质量的衡量标准主要是健壮性和正确性。
用户部
门可能对易用性方面
比较熟悉。
最后，质量不仅是衡量系统的功能或性能是否正常。对
系统来说，在开发过
程中尽早建立全面的质量标准与系统的及时发布是一样重要的。
质量目标是一个
强有力的工具，
应该在系统
开发过程中尽早建立。
一个定义准确的质量目标在以
后的产品开
发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，
应该修复那些缺陷？
在系统完成后那种类型的测试是最合适的。