软件测试的重点内容和测试计划
软件测试愈来愈受到人们的重视，作者计划对软件测试过程管理的有关问题作系统的介绍，计划包括以下四个部分：
■ 软件测试的重点内容和测试计划
■ 测试设计开发、执行与错误跟踪
■ 配置和管理内部测试资源与组织
■ 协调外部测试资源与组织
本文根据作者多年从事软件开发与测试的工作经验，结合新的测试技术与标准，对软件测试过程管理的主要领域进行讨论，以便大家对软件测试有一个相对全面的了解，对于哪些希望从事测试业务管理的人员，算是一个引导，更深的内容可以通过专业的书籍和培训获得。
首先介绍软件测试的重点内容，这是软件测试项目的基础。
1.1 测试什么？目的是什么？确认测试的重点内容和目的
在特定的情况下，对于软件我们要测试什么？目的是什么？做什么类型的测试：结构（白盒）测试还是行为（黑盒）测试？在什么环境进行测试：运行现场测试、实验室中测试还是开发现场测试？测试细到什么程度？如何保证测试粒度的互补性和连续性？是在软件生命周期的什么阶段作检测？是阶段性评审？还是可以运行程序的测试？不同阶段测试的目的是不一样的，回答以上问题，对于有针对性的确认测试的重点内容和测试的目的范围大有帮助。
1.2 为什么测试？结果如何判断？明确质量、质量风险及其评价方法
测试是为了评价软件是否能满足用户的各种要求，这一过程表现为发现问题、缺陷等不符合项，按照一定的质量模型或标准进行评价软件模块或产品，对于不同的测试，会有不同的关注要点，如果不了解质量模型或标准，可能只关注这些要点，在软件质量改进的管理过程中会感觉多有不便。从开发者与测试评价者的共同角度讲，为了评价质量风险，需要为每个风险分配优先级。
非正式的方法有：
对于组件测试：考虑状态、事务、代码覆盖、数据流覆盖、函数、用户界面、机械寿命、信号质量等；
对于集成测试：考虑接口、函数、容量和体积、错误/灾难处理和恢复、数据质量、性能、用户界面等；
对于系统和验收测试：考虑函数、用户界面、状态、事务、数据质量、操作权限与维护、容量限、安全性、可靠性、有效性和稳定性、性能、配置选项和兼容性、标准兼容性、错误/灾难处理和恢复、重点、日期和时间、本地化、网络和分布式环境、环境，电源输入、消耗和输出，打击、振动和坠落，安装、关闭、设置和初始化配置、卸载、许可注册，文档和打包，可维护性等；另外还有α、β和其他的测试。把这些关注点与质量模型结合，逐渐积累经验，能形成一套合理有效地评价模型和工作方法。
评价质量风险的正式方法（也称作故障模式与效果分析），考虑以下内容：
系统功能或特性、潜在故障模式？D？D质量风险、故障的潜在效果、是否至关重要？故障严重性、故障的潜在原因、解决故障的优先级（系统危害等级）、检测方法、对产品和用户影响所及可能性等；
以上说明可由下式概括：风险优先级数＝严重性×优先级×可能性
风险优先级数与质量模型或标准从不同角度反映软件的功能重要性、质量特性、子特性及度量特性，把它们数值化便于计算和比较，风险优先级数是从开发和维护的角度反映功能、质量特性、子特性、度量项等对应的故障严重性、优先级和可能性，意在提醒开发者或维护者应优先解决易发生严重故障的缺陷问题。功能分析，质量特性、子特性、度量项选择可以参考文章《教学软件质量模型度量选择与权重实例》、《GB/T 16260.2-2006<软件工程 产品质量 第2部分：外部度量>使用指导》及标准《GB/T 16260－2006软件工程 产品质量》，本文不再细述这些问题。
根据故障模式与效果分析的结论，评估风险优先级数大发展方向及可能的预期结果，通过采取适当的行动，解决相关明显的和潜在的严重缺陷，防止严重故障发生。这要明确故障的潜在原因和参考依据，确定何人何时采取适当的行动解决问题和缺陷，并通过测试验证行动结果，所有这些过程都应当管理起来，使测试团队自身及其与开发团队或其他利益相关方之间能协调运作。
1.3 测试的内容范围、进度和预算
1）使测试计划适应项目
测试工作分为计划准备、测试设计开发、测试执行、总结跟踪等几个步骤，分别包括以下内容：
计划准备主要包括计划、资源配置、人员配备等，在计划阶段通过进行测试需求分析明确测试的内容和范围；
测试设计开发主要包括建立或部署测试工具、创建测试包和测试用例库、安装测试报告形成工具、做文档记录、明确记录什么；
测试执行主要包括运行测试、记录测试状态、报告测试结果；
总结跟踪主要包括错误分析、趋势分析、错误跟踪、发布确认产品状态等。
通过细化各阶段工作内容，估计需要进行的发布，确认测试循环数（需要几次跟踪测试？）、测试通过数（测试用例和功能达到多大的通过比例，软件产品（包括中间产品）才算通过？）、错误修复配合情况（跟踪错误）、佳候选测试发布（确认产品适合发布），按工作分解结构估计测试的工作量，初始评估一般有50％～200％差距。细化到1～2天可以完成的工作，可以避免失控。
项目管理需要实践、工具和技巧，经验从简单开始积累，不努力尝试好的管理方法，企业不可能成为的企业，引进软件测试过程规范化管理，是软件企业走向成熟的标志。
2）估计资源、创建预算
测试需要一定的资源，资源分类包括：人员、测试工具、设备与日常开支、测试环境、外部实验室等。对资源进行列表，使用参考数据、估计数据，标记易变内容，为后续管理作准备。
考虑隐性成本，包括人员负荷率、人员成本变化幅度、测试环境及辅助应用软件、支持合同和培训等。
每周对执行情况进行统计，可以使以后的估计更准确。如果允许的话，让测试参与者参与计划制订过程。好隐藏预算、薪水等信息，防止产生不必要冲突。做完预算后搁置一两天，重新审查是否有遗漏，注意标识不确定的内容，这些正是测试项目管理的风险所在。
3）协商测试项目进度
测试团队通常不是独立工作，与开发团队协商好测试进度，才能使各项计划工作得到正常开展，否则测试进度和效果将难以得到保证。
如果时间紧，可以按优先级相反顺序减少测试深度。并可以根据发布日期反推安排测试计划，保证重要的用户频繁使用的功能能稳定运行，重要的非经常使用的功能在正常操作的情况下能正常运行，次要的非经常使用的功能即使出现一般等级的错误，在紧急发布的情况下可以暂不修改，其他情况依据轻重缓可以急酌情处理。而这些需要与开发团队协商好，以便在未来的版本中及时处理。
1.4 建立测试计划
在测试执行之前宜召开测试计划评审会议，在测试阶段，人们往往只注意到测试的细节，而忽视对整体的把握。
对于开发的含有多个子项目的系统，在系统测试阶段作者推荐编制多个子项目测试计划。因为一般情况下，各个子项目进度和特征不一样，放在一起编制计划，会有太多待定的内容，这样整个计划让人难于理解，因而难于获得批准。
因此需要分析子项目差别：时间阶段、方法学、目标、听众（相关利益者），编制多个子项目测试计划时，需要有一个主测试计划说明公共主题。
对于不太清楚的工作内容，可以利用草案激发讨论？标注多待定事项，引起注意。如果计划中待定事项过多，对项目没有多大价值！因此规定交流文档的内容、格式及交流工作规范有利于提高交流工作的效率。
测试计划草案可以考虑以下方面：
◆ 测试计划模板、质量风险（简要说明对应的测试策略）、计划使用的质量评价规程
◆ 里程碑的推荐进度：方便与开发进行协调
◆ 如何过渡：进入、终止、继续的标准（判断准则、条件）
◆ 测试配置和环境应列出清单，并说明准备程度，例如需要测试组以外的人员提前准备好。
◆ 测试执行：关键参与者、测试用例与错误跟踪方法、错误隔离和分类及处置权。
◆ 测试版本管理（控制更新发布间隔、否则将忙于应付新发布而不能完整测试，开发测试件实现自动回归测试）
◆ 测试循环的数量、时间和进度，测试期间注意人员、资源、子项目相互衔接。
◆ 风险和不测事件：如果有未解决事件，发现数量超常的错误需要调试性开发的支持或者在讨论继续标准时讨论这类问题，决定出路
◆ 说明如何记录计划本身的变更历史，列出参考文档。
测试计划模板一般包括：测试计划标记、引言、测试项、要测试的特性、不测试的特性、测试方法、测试项通过/失败标准、暂停标准和恢复需求、测试交付品、测试任务分配与时间安排、环境需求、人员职责配置和培训需求、进度、风险和不测事件、批准等。
测试项、要测试的特性、不测试的特性相当于范围和质量风险。
推销计划：如果以评审会议方式批准，可以以电子邮件方式发给应参加评审的人员，要求返回意见。通常这些人不阅读计划，也不返回意见，因此准备硬拷贝，逐页评审计划，记录修改意见是使计划适用的好过程。
评审参与人员：开发经理、项目经理、生产/发布经理、技术支持经理、销售和市场营销经理、业务分析员、其他内部领域专家、以及测试经理或第三方测试组织、主要测试工程师等。
测试计划应清晰、实用、重点突出、有针对性，简短有效。说明谁在何时做什么。
结束语：本文主要说明了软件测试关注的要点，通过将关注的要点与质量模型相结合可以形成合理的评价规范和工作方法，通过计划管理测试工作将易使其得到有效控制，从而保证测试质量，并使被测软件的质量风险得到控制。
