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