软件测试过程及方法指南
近总有人询问测试计划的编写方法和步骤，如何合理的设计测试计划是每个测试经理 的责任，测试中需要关注的要素太多了，既有技术方面的考虑，也有管理方面的考虑，如何 才能设计出实用的测试计划呢？我根据自己的经验，理出一份软件测试计划编写指南，希望对大家有所启示，并同大家交流测试中的心得和方法。
1 前言
1.1 软件测试的目的
软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误， 那么测试应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是 为了给终用户提供具有一定可信度的质量评价，那么测试应该直接针对在实际应用中会经常用到的商业假设。 不同的软件项目会有不同的测试目的；相同的软件项目，不同的时期也可能有不同测试 目的，可能是测试不同区域或是对同一区域的不同层次的测试。 软件测试： ①、软件测试是为了发现错误而执行程序的过程； ②、测试是为了证明程序有错，而不是证明程序无错误。 ③、一个好的测试用例是在于它能发现至今未发现的错误； ④、一个成功的测试是发现了至今未发现的错误的测试。 这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的目，查找不出错误的测试是没有价值的，事实并非如此。 首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。 其次，没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。 对于测试数据的动态积累可以给项目管理者展示出当前项目的实时状态，为科学的决策提供有力的保障，并且为今后的培训，考评，工作的检查等提供强有力的数据基础。
1.2 软件测试的复杂性和经济性
人们常常以为，开发一个程序是困难的，测试一个程序则比较容易。这其实是误解。设计测试用例是一项细致并需要高度技巧的工作，稍有不慎会顾此失彼，发生不应有的疏漏。不论是黑盒测试方法还是白盒测试方法，由于测试情况数量巨大，都不可能进行彻底的测试。所谓彻底测试，是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。 “黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用， 才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 “白盒”法是穷举路径测试，贯穿程序的独立路径数是天文数字，但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。所以说：“程序测试只能证明错误的存在，但不能证明错误不存在”。 在实际测试中，穷举测试工作量太大，实践上行不通，这注定了一切实际测试都是不彻底的。当然不能够保证被测试程序中不存在遗留的错误。软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试。为了降低测试成本，选择测试用例应注意遵守“经济性”的原则。第一，要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级；第二，要认真研究测试策略，以便能使用尽可能少的测试用例，发现尽可能多的程序错误。掌握好测试量是至关重要的，一位有经验的软件开发管理人员在谈到软件测试时曾这样说过：“不充分的测试是愚蠢的，而过度的测试是一种罪孽”。测试不足意味着让用户承担隐藏错误带来的危险，过度测试则会浪费许多宝贵的资源。 测试是软件生存期中费用消耗大的环节。测试费用除了测试的直接消耗外，还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下：
①、系统的目的
系统目的的差别在很大程度上影响所需要进行的测试的数量。那些可能产生严重后果的系统必须要进行更多的测试。
②、潜在的用户数量
一个系统的潜在用户数量也在很大程度上影响了测试必要性的程度。这主要是由于用户团体在经济方面的影响。
③、信息的价值
在考虑测试的必要性时，还需要将系统中所包含的信息的价值考虑在内，一个支持许多家大银行或众多证券交易所的客户机/服务器系统中含有经济价值非常高的内容。很显然这一系统需要比一个支持鞋店的系统要进行更多的测试。这两个系统的用户都希望得到高质量、无错误的系统，但是前一种系统的影响比后一种要大得多。因此我们应该从经济方面考虑，投入与经济价值相对应的时间和金钱去进行测试。
④、开发机构
一个没有标准和缺少经验的开发机构很可能开发出充满错误的系统。在一个建立了标准和有很多经验的开发机构中开发出来的系统中的错误不会很多，因此，对于不同的开发机构来说，所需要的测试的必要性也截然的不同。 然而，那些需要进行大幅度改善的机构反而不大可能认识到自身的弱点。那些需要更加严格的测试过程的机构往往是不可能进行这一活动的，在许多情况下，机构的管理部门并不能真正地理解开发一个高质量的系统的好处。
⑤、测试的时机
测试量会随时间的推移发生改变。在一个竞争很激烈的市场里，争取时间可能是制胜的关键，开始可能不会在测试上花多少时间，但几年后如果市场分配格局已经建立起来了，那么产品的质量变得更重要了，测试量要加大。测试量应该针对合适的目标进行调整。
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.1 Bug 数据库管理
提示和技巧： 谁负责创建数据库？ 谁有权限增加数据库的帐号？ 谁有权使用哪类帐号？ 数据库使用过程中出了问题和谁联系？
谁负责数据库备份？ 多长时间备份一次？ 由谁使用数据库？ 缺陷管理应该与开发部门的负责人一起讨论。
3.8.2 缺陷处理过程
提示和技巧： 解释缺陷报告和分配过程。 缺陷标题、测试环境应如何填写。 解释如何输入，解决，重新打开，关闭和重新即或一个缺陷。 让测试人员清楚一个缺陷从击活到解决的全过程。 缺陷必须指定由谁负责解决。 定义优先级、严重级别等。 在项目结束时，如何解决这些缺陷。 如果有Bug管理工具，只需遵照工具的流程执行。
