1、 第11章 软件测试实例 在整个软件测试的学习中，软件测试实例应该是离我们的实践最近的一部分了，只有真正去接触实际，才能够把测试做得更好。11.1 项目背景 项目需求包括项目的来源、客户和需求等。要做好软件测试计划和随后的工作，也需要掌控软件项目的背景，就是要抓住与软件测试相关的项目要素，了解与这些要素相关的详细信息。11.1 项目背景 制订测试计划时，由于各软件公司的背景不同，所撰写的测试计划文档也有差异。在实际测试工作中，可依据实际情况对模板增删或部分修改。11.2.1 测试计划的内容测试计划需要包含16个大纲领：1测试计划标识符2简要介绍：主要是对测试软件基本情况的介绍和对测试范围的概括
2、性描述。11.2.1 测试计划的内容3测试项目：包括所测试软件的名称及版本，需要列出所有测试单项、外部条件对测试特性的影响和软件缺陷报告的机制。具体要点如下：设计测试、整体测试需求规格说明、用户指南、操作指南、安装指南、与测试项相关的事件报告。11.2.1 测试计划的内容4测试对象：需要列出待测的单项功能及功能组合。5不需要测试的对象：需要列出不测试的单项功能及组合功能，并说明不予测试的理由。6测试方法（策略）：测试计划的核心所在，需要给出有关测试方法的概述以及每个阶段的测试方法。主要描述如何进行测试，并解释对测试成功与否起决定作用的所有相关问题。11.2.1 测试计划的内容7测试项通过/失败
3、的标准：需要给出“测试项目”中描述的每一个测试项通过/失败的标准。8中断测试和恢复测试的判断准则：需要给出测试中断和恢复测试的标准，在哪种情况下应中断测试。11.2.1 测试计划的内容9测试完成所提交的材料：需要包含测试工作中开发设计的所有文档、工具等。10测试任务：需要给出测试前的准备工作以及测试工作所需要完成的一系列任务。11测试所需的资源：在测试开始之前，要制定一个项目测试所需的资源计划，包含每一个阶段的任务所需要的资源。11.2.1 测试计划的内容12职责：需要明确指出每一名测试人员的工作职责。13人员安排与培训需求：明确哪些人员（管理、测试和程序员等）负责哪些任务。14测试进度表：主
4、要列出测试的重要日程安排，估算各项测试任务所需的时间，给出测试进程时间表。11.2.1 测试计划的内容15风险及应急措施:需要列出测试过程中可能存在的一些风险和不利因素，并给出规避方案。16审批:宣布已经为测试工作转入下一个阶段做好准备的某个人或某几个人。测试计划审批部分中的一个重要的部件是签名页，审批人除了在适当的位置签署自己的名字和日期外，还应该表明他们是否建议通过评审的意见。11.2.1 测试计划的内容1目的项目简介的目的文档应该包括以下目标（1）确定现有项目的信息和应测试的软件构件。（2）列出推荐的测试需求（高级需求）。（3）推荐可采用的测试策略，并对这些策略加以说明。（4）确定所需的
5、资源，并对测试的工作量进行估计。（5）列出测试项目的可交付元素。11.2.2 项目简介2背景 即对测试对象（构件、应用程序、系统等）及其目标进行简要说明。需要包括的信息有：主要的功能和性能、测试对象的构架以及项目的简史。11.2.2 项目简介3范围 范围即描述测试的各个阶段（例如，单元测试、集成测试或系统测试），用于说明本计划所针对的测试类型（如功能测试或性能测试）。范围所包括的几个方面如下：（1）简要地列出测试对象中将接受测试或不接受测试的那些性能和功能。（2）如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。（3）列出可能会影响测试设计、开发或实施的
6、所有风险或意外事件。（4）列出可能会影响测试设计、开发或实施的所有约束。11.2.3 测试参考文档和提交文档1测试参考文档测试参考文档2测试提交文档测试提交文档 测试提交文档应当列出在测试阶段结束后，所有可提交的文档。11.2.4 测试风险和优先级 测试风险是指在软件开发过程中因遇到的预算、进度、开发不成功等方面的问题而引起损失的可能性。软件测试风险主要是对测试计划执行的风险分析与制定要采取的应急措施，降低软件测试产生的风险造成的危害。11.2.4 测试风险和优先级测试计划风险发生时，可能采用的应急措施有：（1）缩小范围：决定在后续的发布中，实现较低优先级的特性。（2）增加资源：请求用户团队为
7、测试工作提供更多的用户支持。（3）减少过程：在风险分析过程中，确定某些风险级别低的特征测试或少测试。11.2.4 测试风险和优先级1、需求风险需求风险包括如下内容：范围风险：与范围变更有关的风险。外部可预测风险：市场风险（原材料可利用性、需求）、日常运作（维修需求）、环境影响、货币变动、通货膨胀、税收。外部不可预测风险：规章（不可预测的政府干预）、自然灾害。内部非技术风险：战略风险（公司的经营战略发生了变化）、管理风险（公司管理人员是否成熟等）。需求定义欠佳，而进一步的定义会扩展项目范畴。添加额外的需求。产品定义含混的部分比预期需要更多的时间。在需求中用户参与不够。缺少有效的需求变化管理过程。
8、11.2.4 测试风险和优先级2计划编制风险计划编制风险包括如下内容：计划、资源和产品定义全凭用户或上层领导口头指令，且不完全一致。计划不能实现，只能算是期待状态。计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上。产品规模比估计的要大。完成目标日期提前，但没有相应地调整产品范围或可用资源。涉及不熟悉的产品领域，花费在设计和实现上的时间比预期得要多。没有按照要求的技术性能和质量水平完成任务。没有在预算的时间范围内完成任务。没有在预算的成本范围内完成任务。11.2.4 测试风险和优先级3组织和管理风险组织和管理风险包括如下内容：仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时
9、间延长。员工离职。低效的项目结构降低生产率。管理层审查决策的周期比预期的长。预算消减，打乱项目计划。缺乏必要的规范，导致工作失误与重复工作。非技术的第三方的工作。作为先决条件的任务（如培训及其他项目）不能按时完成。开发人员和管理层之间关系不佳，导致决策缓慢，影响全局。缺乏激励措施，士气低下，降低了生产能力。某些人员不熟悉软件工具和环境。项目后期加入新的开发人员，需要进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率低。由于项目成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作。不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性。没有找到项目急需的具有特定技能的
10、人。11.2.4 测试风险和优先级4开发环境风险 开发环境风险包括如下内容：设施未及时到位。开发工具未及时到位。开发工具不如期望的那样有效，开发人员需要时间创建工作环境或切断新的工具。新的开发工具的学习期比预期的长，内容繁多。11.2.4 测试风险和优先级4开发环境风险 开发环境风险包括如下内容：设施未及时到位。开发工具未及时到位。开发工具不如期望的那样有效，开发人员需要时间创建工作环境或切断新的工具。新的开发工具的学习期比预期的长，内容繁多。11.2.4 测试风险和优先级5设计和实现风险设计和实现风险包括如下内容：设计质量低下，导致重复设计。用户对最后交付的产品不满意，要求重新设计和重做。用
11、户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做。用户提供的组件质量欠佳，导致额外的工作。用户没有或不能参与审核，导致需求不稳定和产品生产周期的变更。一些必要的功能无法使用现有的代码和库实现。代码和库质量低下，导致需要进行额外的测试、修正错误或重新制作。过高估计了增强型工具对计划进度的节省量。分别开发的模块无法有效集成，需要重新设计或制作。没有严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作。要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作。在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题。开发一种全新的模块将比预期花费更
12、长的时间。依赖正在开发中的技术将延长计划进度。11.2.4 测试风险和优先级 优先级别的确定，利于测试工作有的放矢地展开，使测试人员清晰了解核心的功能、特性与流程有哪些，客户最关注的是什么，由此可确定测试的重点在哪里，更方便处理测试进度发生问题时，实现不同优先级别的功能、模块、系统等迭代递交或取舍，缓和测试风险。11.2.4 测试风险和优先级11.2.5 测试内容和策略测试内容具体要点有：（1）功能的测试：理论上测试要覆盖所有的功能项，例如，在数据库中添加、编辑、删除记录等。（2）设计的测试：对一些用户界面、菜单的结构以及窗体的设计是否合理等的测试。（3）整体考虑：这部分测试需求要考虑到数据流
13、从软件中的一个模块流到另一个模块的过程中的正确性。11.2.5 测试内容和策略测试策略下面几点是我们所要注意的：（1）功能测试的安排要从缺陷产生的概率、修正的难度来考虑。（2）每日构建验证是在不影响功能测试整体计划的前提下进行的。（3）Ad-hoc测试目的是给测试人员一个自由的想象空间。（4）每日缺陷验证，先验证已修正的软件缺陷，然后处理计划好的测试任务。11.2.6 测试资源软件测试资源分类：1人力资源 2测试环境资源 （1）硬件 （2）支持的系统软件 （3）测试工具11.2.6 测试资源11.2.7 测试时间表 测试项目时间表可以通过工作估计和资源分配来建立。在迭代开发环境中，每一迭代都需
14、要一个独立的测试项目时间表。在每一迭代中都将重复所有的测试活动。11.2.7 测试时间表11.2.8 测试问题卡 一个完整的BUG包括“属性”和“错误现象”描述两部分，而“错误现象”的描述是BUG的最重要部分，归纳起来填写一个BUG要注意以下几点。1正确的属性添好BUG的属性，包括类型、等级、时机、频率。2好的“错误现象”描述 1）准确的定位 2）准确的描述 3）客观的描述 4）描述简洁 5）描述全面 3通用的约定 11.2.9 附录：项目任务测试有关的任务：（1）制定测试计划。确定测试需求。评估风险。制定测试策略。确定测试资源。创建时间表。生成测试计划。（2）设计测试。准备工作量分析文档。确
15、定并说明测试用例。确定测试过程，并建立测试过程的结构。11.2.9 附录：项目任务（3）复审和评估测试覆盖。（4）实施测试。记录或通过编程创建测试脚本。确定设计与实施模型中的测试专用功能。建立外部数据集。（5）执行测试。（6）执行测试过程。（7）评估测试的执行情况。（8）恢复暂停的测试。（9）核实结果。（10）调查意外结果。11.2.9 附录：项目任务（11）记录缺陷。（12）对测试进行评估。（13）评估测试用例覆盖。（14）评估代码覆盖。（15）分析缺陷。（16）确定是否达到了测试完成标准与成功标准。11.3 测试执行 测试执行在测试执行前开一个动员会阐述测试策略，清楚交待测试任务、范围等。
16、严格审查测试环境，包括硬件型号、网络协议、各种服务器的设置、软件系统版本等。对要执行的测试用例进行分类，基于测试策略和历史数据分析，构造有效的测试套件并在此基础上建立要执行的测试任务。11.3.1 设置测试环境1测试环境的正确性2测试环境的可靠性3测试环境的多样性和复杂性11.3.2 执行测试任务执行测试前，应做好下面两项工作。1测试环境的准备 构建测试运行的平台和安装需要的软硬件系统。2人员的安排 不仅包括指定哪些人参加系统测试和谁负责测试环境的维护等，还包括人员的培训、知识的传递。11.3.2 执行测试任务测试的执行过程构成了多个层次并行的测试空间。（1）功能测试的安排要从缺陷产生的概率、
17、修正的难度来考虑。（2）每日构建验证是在不影响功能测试整体计划的前提下进行的。（3）Ad-hoc测试，指进行一些非计划内的、随机的、猜测性的测试。（4）每日缺陷验证。11.3.3 评估测试的执行评估测试的执行的目的有如下两个：（1）确定是将测试执行完毕还是暂停测试。（2）确定是否需要纠正措施。11.3.4 核实测试结果目的：（1）确定测试结果是否可靠。（2）针对测试结果表明的测试工作或测试工件中存在的缺陷，确定合适的纠正措施。11.3.5 测试执行的策略（1）首先要向测试人员不断地灌输一个概念“测试工作是及时发现缺陷”，让大家取得共识。（2）测试执行阶段可划分为两个子阶段。（3）在代码冻结或产
18、品发布前的后期阶段，测试目标是增加测试覆盖率及降低风险，这时测试的效率会更低一些，以损失部分测试效率来获取质量的安全性，从而降低风险，获得更高质量的收益。11.3.5 测试执行的策略（4）在前一阶段测试用例的执行速度会慢一些，测试人员应该多思考，多做一些Ad-hoc测试，这样可以帮助提高测试用例的质量，从而对随后的回归测试提供更有力的保障。（5）测试执行要进行有效的监控，包括测试执行效率、缺陷历史情况和发展趋势等。（6）测试总是有风险的，正是因为始终存在的风险，才使测试更具有艺术性。11.4 测试总结与报告 测试总结报告：给出系统在最终测试后功能、性能等方面所达到的状况的总结和评价，通常测试总结报告要包含量化的描述，测试总结报告将呈现给测试部门、开发部门以及公司的相关负责人。11.4.1 测试总结报告11.4.2 附录 包含测试总结报告的模板，可以复制该模板并可将其作为一个特定测试阶段的测试总结报告的基础。测试总结报告用于总结某个特定测试阶段的结果，并可作为以后测试过程改进的基础。编写测试总结报告使用的原则是产生一个简明扼要的文档。11.5 本章小结 本章介绍了软件测试的实例，包括的项目背景、测试计划的制订、测试的执行和测试总结与报告，在具体的软件测试及其文档中，首先要注意的就是项目背景，了解了项目背景才能开始后面的一系列工作。第第11章结束章结束 谢谢！
