作者：赵聚雪,杨鹏
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
软件测试管理与实践试读：
前言
软件测试项目实践涉及软件测试过程中的相关工作，是软件测试工程师、软件项目经理、软件测试经理的典型工作任务，是软件测试工程师必须要具备的技能，也是计算机相关专业的重要课程。在软件测试项目开展过程中，测试任务的划分往往是按照功能模块或者测试类型进行的。测试工程师要管理所负责部分的测试需求、方案、用例、执行以及缺陷提交和总结报告，因此，测试工程师的日常工作包含了软件测试流程中的大部分工作。
建议阅读本书之前先了解与软件测试基础相关的测试概念、用例设计方法等内容。本书以训练读者的软件测试项目实践能力为目标，全面地介绍了软件测试的相关理论和工具，内容翔实，可操作性强，简明易懂。本书主要包括测试流程管理、测试需求分析、测试计划制订、测试用例编写、测试执行、测试缺陷提交、测试报告编写、测试团队建立、测试管理工具应用等内容。全书从实用角度出发，重点培养学生利用理论和工具动手解决实际问题的能力。
通过理论学习、工具实训、项目实践，读者不仅能够掌握软件测试相关的理论，还要掌握相关工具以及操作方法，更重要的是能够通过项目实践获取将理论和工具应用到具体的项目中的能力，最终具备解决实际问题的能力。
本书的参考学时为46～60学时，建议采用理论实践一体化教学模式，各章的参考学时见下面的学时分配表。学时分配表续表
本书关于软件质量模型、软件测试模型部分的介绍引用了相应理论的经典图片，此部分只用于教学使用，不做商业用途使用。
本书由赵聚雪、杨鹏主编，赵聚雪编写了理论部分的第1、2、3、4、6、8、9章，以及第10章的ALM工具实训部分；杨鹏编写了理论部分的第5、7章，以及第11章的项目实例部分、附录的项目模板部分。
由于编者水平和经验有限，书中难免有欠妥和错误之处，恳请读者批评指正。编者2017年11月第1章软件测试管理概述
随着计算机应用的普及和深入，各行各业都已经离不开计算机和软件，人们的日常生活和工作对计算机和软件的依赖性也越来越大。除了不断追求硬件的更新换代，人们也越来越关注软件的质量问题。这一方面是因为软件产品的质量不好可能引起严重的经济损失，甚至直接伤害到生命或社会安全，比如一些加工控制软件和金融软件；另一方面是用户越来越重视使用体验，不仅要求软件产品“能工作”，而且要求产品能方便、快速地工作。
本章主要讲述什么是软件质量、软件项目管理和软件测试管理的关系，以及测试管理工具的选择。本章学习目标
●理解软件质量的含义以及软件测试与软件质量的关系。
●了解软件项目管理与软件测试管理的关系。
●理解软件测试管理的要素。
●了解软件测试管理工具的种类、基本功能及选择依据。1.1 软件质量1.1.1 软件质量的概念
从现代质量管理的角度讲，质量是客户要求或者期望的有关产品或者服务的一组特性，落实到软件上，这些特性是软件的功能、性能和安全性等。
ANSI/IEEE Std 729-1983《软件工程术语的IEEE标准术语表》（Glossary of Software Engineering Terminology）定义软件质量为“与软件产品满足规定的和隐含的与需求能力有关的特征或特性的全体”。软件质量反映在以下3个方面。
●软件需求是度量软件质量的基础，不符合需求的软件质量不合格。
●软件需求开发过程中，往往会有一些隐含的需求没有显式地提出来。如软件应该具备良好的可维护性。
●软件研发的流程定义了一组开发准则和最佳实践，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量可能就得不到保证。
也就是说，为满足软件各项精确定义的功能、性能需求，需要相应地给出或设计一些质量特性及其组合，作为在软件开发与维护中的重要考虑因素。如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品质量就是高的。特性是软件质量的反映，软件属性可用作评价准则，度量软件属性便可知软件质量的优劣。1.1.2 软件质量模型
软件质量是各种特性的复杂组合，它随着应用的不同而不同，随着用户提出的质量要求不同而不同。软件产品各种质量特性的组合就叫作软件质量模型。
常见的软件质量模型有3种：Boehm质量模型（1976年）、Mc CALL质量模型（1978年）、ISO 9126质量模型（1993年）。
1.Boehm质量模型
Boehm质量模型是1976年由Boehm等人提出的分层方案，将软件的质量特性定义成分层模型（见图1-1）。图1-1 Boehm质量模型
2.Mc CALL质量模型
Mc CALL质量模型（见图1-2）是1979年由Mc Call等人提出的软件质量模型。它将软件质量的概念建立在11个质量特性之上，而这些质量特性分别是面向软件产品的运行、修正和转移的。图1-2 Mc CALL质量模型
3.ISO 9126质量模型
按照ISO/IEC 9126-1：2001，软件质量模型可以分为内部质量模型、外部质量模型、使用质量模型。而在质量模型中又将内部质量和外部质量分成6个质量特性，将使用质量分成4个质量特性，具体见图1-3。图1-3 ISO 9126软件质量模型
不同的软件质量模型提出了不同的软件质量特性，为了更好地理解软件质量与软件质量模型，就要弄清楚这些质量特性的含义。常见的软件质量特性及含义见表1-1。表1-1 常见的软件质量特性及含义1.1.3 软件测试与软件质量
要保证软件质量，一方面要用规范化的方法和开发准则指导研发人员用工程化的方法开发软件，另一方面就是对软件进行充分的测试。
软件测试是软件质量控制中的关键活动，是软件质量保证的关键步骤。软件测试在软件生存周期中占有非常突出的位置，是保证软件质量的重要手段。
软件测试活动是有计划、有组织的活动，通过测试管理确保测试活动的顺利开展，项目的测试管理对测试工作的开展至关重要。1.2 项目管理与软件测试管理1.2.1 项目管理
项目管理是管理学的一个分支学科，项目管理是指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定的条件下，实现或超过设定的需求和期望的过程。
项目管理知识体系（Project Management the Body of Knowledge，PMBOK）把项目管理分为5个过程及9个知识领域。管理过程包括输入、输出、所需工具和技术。各个过程通过各自的输入和输出相互联系，构成整个项目管理活动。
1.项目管理的5个过程
① 启动。成立项目组，开始项目或进入项目的新阶段。启动是一种认可过程，用来正式认可一个新项目或新阶段的存在。
② 计划。定义和评估项目目标，选择实现项目目标的最佳策略，制订项目计划。
③ 执行。调动资源，执行项目计划。
④ 控制。监控和评估项目偏差，必要时采取纠正行动，保证项目计划的执行，实现项目目标。
⑤ 结束。正式验收项目阶段，使其按程序结束。
2.项目管理的9个知识领域
① 项目集成管理（Project Integration Management）。项目集成管理是为了正确地协调项目各组成部分而进行的各个过程的集成，是一个综合性过程。其核心就是在多个互相冲突的目标和方案之间做出权衡，以便满足项目利害关系者的要求。
② 项目范围管理（Project Scope Management）。项目范围管理就是确保项目完成全部规定要做的工作，最终成功地达到项目的目的。基本内容是定义和控制列入或未列入项目的事项。
③ 项目时间管理（Project Time Management）。其作用是保证在规定时间内完成项目。
④ 项目费用管理（Project Cost Management）。项目费用管理，是为了保证在批准的预算内完成项目所必需的诸过程的全体。
⑤ 项目质量管理（Project Quality Management）。项目质量管理，是为了保证项目能够满足原来设定的各种要求。
⑥ 项目人力资源管理（Project Human Resource Management）。项目人力资源管理，是为了保证最有效地使用参加项目者的个别能力。
⑦ 项目沟通管理（Project Communications Management）。项目沟通管理，是在人、思想和信息之间建立联系，这些联系对于取得成功是必不可少的。参与项目的每一个人都必须用项目“语言”进行沟通，并且要明白个人所参与的沟通将会如何影响到项目的整体。项目沟通管理可保证项目信息及时并准确地提取、收集、传播、存储以及最终进行处置。
⑧ 项目风险管理（Project Risk Management）。项目风险管理是指识别、分析不确定的因素，并对这些因素采取应对措施。项目风险管理要把有利事件的积极结果尽量扩大，而把不利事件的后果降到最低程度。
⑨ 项目采购管理（Project Procurement Management）。项目采购管理，是为了从项目组织外部获取货物或服务。1.2.2 软件项目管理与软件测试项目管理
软件项目是指软件工程类的项目，具体来说，软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期（从分析、设计、编码到测试、维护的全过程）都能在管理者的控制之下，以预定成本按期、按质地完成软件并交付用户使用。
软件测试项目是软件工程项目中的一种，是以软件测试为主要任务的项目。软件项目管理和软件测试项目管理与一般的工程项目管理有共性，但是在实际开展项目管理时因任务特点不同又有其特殊性。1.2.3 软件测试管理的要素
测试活动贯穿于软件产品的整个生命周期，测试管理贯穿于测试的全过程。软件测试管理着眼于对软件测试的流程进行策划组织，对测试实施中的所有元素进行管理控制，确保测试活动按时保质开展。测试管理主要涉及以下内容：
●测试过程和资产管理；
●测试团队管理；
●测试需求管理；
●测试计划管理（测试规划）；
●测试用例管理（测试设计）；
●测试缺陷管理；
●测试工具选择和使用；
●测试执行和汇报管理。1.3 测试管理工具1.3.1 测试工具与测试管理工具的关系
软件测试工具可提高软件测试工作的效率。软件测试工具分为自动化软件测试工具和测试管理工具，所以测试管理工具是测试工具的一种。
自动化软件测试工具存在的价值是为了提高测试效率，用软件来代替一些人工输入，提高测试用例的复用率。常见的自动化软件测试工具主要有单元测试工具、性能测试工具和功能测试工具。比如功能测试工具QTP（Quick Test Professional）、性能测试工具Jmeter和Load Runner。1.3.2 测试管理工具的基本功能
完整的测试管理工具应该能对测试整个流程的各个环节进行管理。对于测试人员来说，测试管理工具能够管理测试过程中测试人员的日常活动，其主要功能包括以下几种：
●用户及权限管理；
●测试项目的创建；
●测试项目需求管理；
●测试任务分配和实施；
●测试项目缺陷管理；
●测试数据收集；
●测试项目数据分析及统计和报告生成；
●测试项目用例管理；
●测试执行管理；
●测试文档管理。1.3.3 测试管理工具的来源和分类
测试管理工具有开源的，可以自主开发，也可以购买。测试管理工具的分类如下。
1.专项测试管理工具
这类工具可管理软件测试中的某个内容，如缺陷管理工具、用例管理工具，比如BUGzilla和BUGfree。BUGzilla是一个开源的缺陷跟踪系统（BUG-Tracking System），它可以管理软件开发中缺陷的提交（new）、修复（resolve）、关闭（close）等整个生命周期。BUGfree是一款简单、实用、免费并且开放源代码的一个Bug管理系统，不过目前已经不提供更新和技术支持了。
2.专门的测试管理工具
这类工具对测试的整个流程进行管理，比如IBM Rational Quality Manager、HP ALM（Application Lifecycle Management）等。ALM软件是惠普公司的一款高端商业软件，提供了需求管理、缺陷管理、测试用例管理、测试执行管理和各种分析报告管理。
3.开发和测试都包含的项目管理工具
专门的测试管理工具主要用于第三方软件测试机构，以及软件开发部门和测试部门相对独立的公司。大部分时候，开发和测试属于同一个团队，此时研发团队会使用覆盖整个研发周期的软件产品。这些产品或者是公司自己开发的，或者是从市场购买的，也可能是开源的软件。
比如，禅道项目管理软件是一款国产的开源软件。该软件集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件。
4.其他可用于测试管理的工具
小型项目团队、初创业的团队、学生课程设计团队往往直接利用Office办公软件完成软件测试的管理，包括Office Project、Word、Excel。对于软件测试中的文档管理，则可以借助于一些文件管理软件，比如Tortoise SVN、Tortoise Hg。1.3.4 测试管理工具的选择
在进行测试管理工具的选择时，要综合考虑项目大小、团队规模、团队性质、成本预算等因素。工具是一个载体，重要的是按照流程开展工作。
对于新创业项目、学生项目等团队规模比较小的情况，可以选择开源工具或Office办公软件，节省成本，简单易用；对于第三方测试团队，则可以选用专门的测试工具；对于研发测试一体化的团队，则可以采用完整的项目管理工具。1.3.5 测试管理工具发展趋势
软件测试管理工具发展的趋势如下。
① 与其他软件自动化测试工具集成，比如在软件测试用例的管理中，用例可能是Load Runner的性能测试脚本，也可能是QTP的功能测试脚本，也可能是需要手工测试的用例。目前的测试管理工具倾向于能直接启动测试用例并执行，这就要求测试管理工具与Load Runner、QTP等自动化测试工具有很好的衔接。
② 与软件研发其他环节的集成越来越紧密，比如软件测试管理工具中的集成版本管理功能。
③ 基于云计算的测试管理工具，比如，QASymphony开发的QTest是基于云计算的测试管理工具，有各种典型的关键特性。QTest在连接器的帮助下，可以集成JIRA整个端到端质量的解决方案。它还集成了其他工具，比如BUGzilla、Fog BUGz、Rally等。1.4 项目实践任务一：分组和项目选择
实践任务：
●所有学员自由组合成测试小组（3～4人），给出小组名单，并指定组长。
●选择被测试的软件项目。
●将分组名单和选定的项目提交给学习委员汇总。
实践指导：
选择的被测试项目可以是企业项目、教学实训项目、学生开发的参赛和课程设计项目、网络开源项目等，软件架构不限。第2章软件测试流程管理
要开展软件测试管理，首先要建立软件测试的流程。本章主要讲述软件开发过程和测试过程是如何交互的，典型的测试模型有哪些，软件测试的一般流程是怎样的，如何建立软件测试的流程，以及软件测试流程中涉及的资产、度量分析。本章学习目标
●理解研发过程和测试过程的交互过程。
●理解典型的软件测试模型。
●理解软件测试的一般流程。
●了解建立一个测试流程应该包含的内容。
●了解测试中涉及的文档资产及度量分析。2.1 软件研发中的测试
软件测试和软件开发一样，都遵循软件工程的原理。测试和开发是密切相关的。测试活动是贯穿于软件项目开发的全过程的，和开发活动交互开展。
图2-1描述了软件项目开发中的测试环节及相应的测试活动。
① 软件需求完成后，需要进行需求的评审，此时测试人员可以参与需求的评审。当需求确定后，测试人员可以开始进行系统测试方案及计划的制订。
② 软件项目总体设计方案完成后，测试人员可以开始进行集成测试方案及计划的制订。
③ 详细设计完成后，测试方可以开始进行模块测试方案及计划的制订。
④ 单元测试和编码一般是同步的，由开发人员自己完成。
⑤ 整个模块开发完成后，测试人员开始进行模块测试。当然在这之前，所有的模块测试用例已经准备完毕。
⑥ 模块测试后是集成测试和系统测试。
⑦ 软件运行维护期间则要对运行期间发现的问题进行回归测试。
从图2-1可以看出，在软件项目开发过程中不能把测试理解为开发后期的一个活动，它是贯穿于整个开发过程的。图2-1 软件研发中的测试环节及测试活动2.2 软件测试模型
在实践中产生了很多的测试模型。这些测试模型明确了测试和开发之间的关系。主要的测试模型有V模型、W模型和H模型。
1.V模型
V模型（见图2-2）是软件测试模型中的一个经典模型，它发展自软件研发的瀑布模型，模型明确标识了测试过程中存在的测试阶段，以及测试阶段与开发阶段之间的关系。从图2-2可以看到，项目研发中的开发活动是从需求分析到概要设计，之后到详细设计，再到编码，然后是测试活动。测试活动对应开发的4个阶段，分别是单元测试、集成测试、系统测试和验收测试。
在这个模型中，把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。测试活动在编码之后，并且只对代码测试，未能体现尽早测试的原则。虽然该模型有局限性，但是该模型仍然是指导测试开展的一个重要模型。图2-2 V模型
V模型中的单元测试、集成测试、系统测试、验收测试也被其他模型引用。
① 单元测试，是对软件中的最小可测试单元进行检查和验证，是指在编码完成后，对所实现的方法/函数的内部逻辑进行的测试。单元测试的依据是方法/函数的功能与功能实现流程；单元测试的主要对象是方法/函数的功能在实现过程中的错误或不完善的地方；单元测试所采用的测试方法是白盒测试，即针对方法/函数的内部实现逻辑，并结合方法/函数的输入及输出的可能取值范围，进行程序的针对性测试。对于单元测试中的单元，一般来说，要根据实际情况去判定其具体含义，如C语言中的单元指一个函数，Java里的单元指一个类。
② 集成测试，也叫组装测试或联合测试，将所有模块按照设计要求（如软件架构图）组装成为子系统或系统，进行集成测试。之所以进行集成测试，是因为一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。一些局部反映不出来的问题，在全局上很可能暴露出来。在实际项目实践中，集成测试之前还会安排模块测试。模块测试是指针对产品设计所识别出的各个模块在本产品版本所承载的功能实现，测试模块级功能的实现，模块间的接口、交互，以及依赖关系的正确与否。
③ 系统测试，是将经过集成测试的软件，作为计算机系统的一个部分，与系统中的其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。系统测试是针对产品版本系统进行的整体测试，主要采用的测试方法是黑盒测试，系统测试除了关注功能测试外，还需要关注软件产品的非功能需求，包括但不限于容量测试、性能测试、压力测试、负载测试、兼容性测试、稳定性测试、可靠性测试、可用性测试和用户文档测试。
④ 验收测试，也称为交付测试。验收测试的目的是确保软件准备就绪，向未来的用户表明系统能够像预定的要求那样工作，即软件的功能和性能如同用户所合理期待的那样。验收测试阶段，相关的用户和独立测试人员根据测试计划及结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定的需求的测试。验收测试有非正式验收测试（Alpha 测试）和正式验收测试（Beta测试）之分。
●Alpha 测试，是非正式验收测试，是由用户在开发环境下进行的测试，也可以是公司内部的用户（比如技术支持人员、销售人员、代理商等）在模拟实际操作环境下进行的受控测试。Alpha测试不能由程序员或测试员完成。
●Beta测试，属于正式验收测试，是软件的用户在实际使用环境下进行的测试，开发者通常不在测试现场。Beta测试不能由程序员或测试员完成。比如，游戏的公开测试就属于Beta测试。一般Beta测试通过后就可以正式发布产品了。
2.W模型
W模型（见图2-3）从V模型演化而来，在这个模型中增加了与软件各开发阶段同步的测试活动。从模型图中可以看到，测试伴随着整个软件开发的周期。用户不仅需要对程序进行测试，还需要对需求和设计进行测试。测试和开发是同步的，有利于尽早地发现问题。但是W模型存在一个和V模型相同的问题，它们把软件研发的过程视为一系列串行的活动，没有融入迭代及变更的元素。图2-3 W模型
3.H模型
H模型（见图2-4）强调测试活动是独立的，贯穿于整个产品的周期，和研发流程是并发的。在H模型中，只要测试就绪点达到了，就可以开始进行测试。这个模型可以满足测试尽早开始这样一原则，模型本身并没有太多的执行指导，可以把它理解为一种理念，测试就绪点满足了就可以测试了。图2-4 H模型2.3 软件测试流程
测试过程定义了企业在产品开发过程中在设计、开发与实现、维护、退出等阶段与测试相关活动的内容、流程及规范。定义测试过程的目的是给本公司在产品开发过程中测试相关的活动提供指导，确保产品可以真正满足用户的要求。测试过程指导项目如何开展各项测试活动，以及各项活动的输入与输出；约定活动中所涉及的角色与职责，规范各个活动的内容和规程，以及所使用到的统一的模板、表单、指导书和检查单。
在软件项目中，测试和开发是相互配合、同步推进的。因为软件项目的复杂性，被测对象往往不断发生变化，在实际项目中，测试与开发的关系更加复杂。虽然复杂，但是测试工作的开展是有自己的过程要遵循的。
虽然在一个项目的研发过程中有很多种不同的测试类型、不同的测试阶段，但是对单次测试来说，存在一个一般性的过程。
在软件测试的一般性过程中（见图2-5），首先进行测试的需求分析，然后进行测试计划制订，接下来进行测试的设计和开发，之后进行测试的执行和监控。测试执行完毕后，最终给出软件评估报告和测试的总结报告。在实际运行中，各个公司会根据自己的实际情况进行调整。图2-5 软件测试的一般性过程
1.测试需求分析
相关人员收集相关资料，学习业务（测试对象），分析测试需求点。
2.测试计划及监控
测试主管组织并编写《测试计划》，该文档指明测试范围、方法、资源及相应测试活动人员的时间进度安排，其中包括软件和硬件资源、集成顺序、人员时间进度安排和可能的风险等内容。测试计划需要进行评审，测试计划一旦开始执行，就要定期监控计划的执行情况。
3.测试设计与开发
① 测试设计一般由对需求熟悉的资深的测试工程师进行，测试方案要求根据《软件需求规格说明书》上的每个需求点设计出包括需求点简介、测试思路和详细测试方法在内的方案。
② 测试开发主要是测试用例的开发，可完成测试用例编写、测试数据准备、测试环境准备。测试用例是根据《测试计划》来编写的。通过对测试需求的分析，测试人员对整个系统需求有了详细的理解，然后开始编写用例，这样才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项、用例级别、预置条件、操作步骤和预期结果。其中，操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又应覆盖测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。
4.测试执行及报告
此阶段的主要任务是执行测试用例，及时提交测试中发现的Bug，及时反馈测试情况。
5.软件评估报告及批准
根据测试结果给出对软件的整体评估，以及是否通过测试的建议。一般，决策部门会根据这份评估报告决定产品是否可以进入下一个阶段。
6.测试总结及资产归档
项目结束后，对整个测试过程进行回顾总结，将项目相关资源进行整理归档。
与一般项目不同，大型项目，特别是产品型项目，在开发过程中会将开发任务划分为多个子项目（模块）。其项目管理也更加复杂，测试管理也更加复杂。图2-6所示是某复杂大型项目的测试过程。图2-6 复杂大型项目的测试过程
从图2-6可以看出，复杂的大型软件项目在测试过程中会先对软件整体进行测试规划，再分模块进行测试执行，最后进行整体测试。小知识
项目型IT公司、产品型IT公司、混合型IT公司（1）项目型IT公司：承包项目，能够根据客户需求完成项目的公司。公司的业务就是不断承接项目、完成项目。有评论指出，由于我国软件产业的发展历史非常短暂，基础软件薄弱，主要集中在应用软件和行业软件，进入门槛低，找到项目即可成立一个软件公司，因此，90%以上的IT公司都是项目型的。项目由于其具有一次性、独特性因素，导致实施成本大，风险高，对项目人员要求高等。（2）产品型IT公司：产品与项目的不同在于需求的来源。项目需求是客户提出的；产品需求是企业根据市场的情况自己挖掘、设计出来的，投入市场之前很难确定用户是否接受，成功的风险比项目大，一旦成功，利润也比较多。产品型IT公司就是自己设计产品然后推出市场。美国的苹果公司、微软、Oracle等是全球公认的产品型IT公司，它们引领市场的发展方向和世界的技术潮流。国内的用友、金蝶公司也是公认的产品型IT公司，它们是企业财务和管理软件产品化的典型代表。（3）混合型IT公司：处在完全项目型阶段的IT公司，不能否定其项目的价值与意义，它助推了公司的成长，在积累到一定的客户数量后，将逐步往产品化过渡和转型，而产品在客户和市场发生变化时，也将按照项目的方式进行演进。项目与产品是辩证统一的关系。公司不能为了项目而放弃产品，也不能因为产品而完全放弃项目，它们之间离开谁都无法独立存在。
不同类型的公司，其测试管理的特点也不尽相同。不同于项目型IT公司，产品型IT公司的软件测试产品比较固定或相似，测试的对象是同一个产品的不同版本，或者是同一个产品的周边产品，测试的复用率和可借鉴性比较高。比如某手机公司，其不同款式的手机都是在基础款的基础上变化而来的，每次测试的重点是变化的部分和新添加的部分，原有的部分进行回归测试就可以了。2.4 软件测试过程资产
测试过程中会产生多个文档，涉及的文档列表如下。
① 测试方案文档（测试计划文档）。
② 测试用例列表。
③ 测试缺陷列表。
④ 测试总结报告。
⑤ 其他。
●新开发或引入的测试工具。
●测试工作会议记录。
●测试计划（测试方案）、测试用例的评审报告。
●测试总结。
●测试原始数据及度量数据。
●测试日志：每天测试日程记录。
●周期性测试报告。
●任务报告：任务完成情况报告。
测试过程中涉及的关键文档的内容具有一般性，表2-1列出了关键文档的主要内容。表2-1 测试过程中涉及的主要文档及其内容2.5 软件测试流程的建立
为了更好地开展测试管理，需要为测试项目的执行创建一个测试流程。测试流程主要包括以下内容。
① 定义团队在产品开发过程中各阶段（设计、开发与实现、维护、退出）与测试相关活动的内容、流程及规范。
② 为测试相关活动提供指导。指导项目如何开展各项测试活动，以及各项活动的输入与输出。
③ 约定活动中所涉及的角色与职责，规范各个活动的内容和规程，以及所使用到的统一的模板、表单、指导书和检查单。
测试的一般过程：分析测试需求、定义测试方案（或者测试计划）、评审方案、设计并编写测试用例、评审用例、执行并提交缺陷、撰写测试报告、测试过程回顾和资料备案。图2-7所示为某企业软件测试跨职能流程图，图中详细定义了测试需要开展的阶段，各个阶段的参与人员、负责人员及相关任务。图2-7 某企业软件测试跨职能流程图
定义测试过程时需要将过程中用到的模板定义清楚，将指导任务开展的指南书编写好。表2-2所示是某企业测试过程的文档清单。表2-2 某企业测试过程的文档清单续表
在建立流程的过程中，具体要开展哪些测试、测试的具体要求等都要根据产品及人员的能力现状而定，不能盲目追求达到最高要求，合适的才是最好的。
制订测试流程一定要从实际情况出发，重点定义哪些测试要做、谁做、什么时间做、如何做等问题。测试过程的定义要非常明确，达到可执行、具有指导性的程度。团队的实际情况包括团队与开发的关系（是开发测试协同性团队，还是第三方测试团队）、团队的组织架构情况、团队要开展哪些测试等。如果团队需要开展模块测试和系统测试，则可能要分别定义模块测试和系统测试的过程及模板。
需要注意的是，测试过程创建后并不是一成不变的，要根据实际实践情况不断改进和完善，进行修订后要及时进行过程发布。一般在测试过程执行中要设置一定的机制，以保证测试人员按照测试过程开展测试活动。一般是通过QA人员和审计活动去确保测试流程的执行。测试流程时，每一轮执行完毕之后都要对流程进行更新和完善。这里大家要注意区分测试执行和测试过程执行，测试执行是按照测试计划去执行测试活动，测试过程执行是严格按照测试的过程去开展测试活动。2.6 测试流程中的度量分析
在创建测试流程时，要考虑测试数据的度量和分析。测试数据的度量主要用于积累数据，评价工作，改进过程，预测趋势。
要开展测试数据的度量，就要先建立测试数据采集机制，然后确定要采集数据的种类、数量和频次，还要专门指定数据采集的负责人，以及安排人员进行检查。要充分利用合适的工具去辅助完成数据的收集和统计，还要建立专门的数据库，用于长期保存各种数据。
1.测试度量分析的主要目的
●积累：积累原始实践数据，为分析做准备。
●评价：通过分析结果，对测试和开发工作进行量化评价。
●改进：基于分析结果发现问题，直到工作改进。
●预测：基于现有数据预测趋势和风险。
2.建立测试数据采集机制
●确立数据采集机制，将数据采集作为测试日常工作。
●确定采集的数据种类、数量、频次等。
●确定数据采集的负责人。
●安排人员进行检查，确保数据采集工作的持续进行。
●利用合适的工具辅助完成测试数据统计。
●建立数据库，长期保存各项数据。
3.常见的测试度量项
●工作量估算偏差。
●进度估算偏差。
●遗留缺陷密度。
●测试缺陷发现率。2.7 项目实践任务二：实践环境准备
实践任务：
① 创建一个VMWare虚拟机系统（建议Windows Server 2008）。
② 在虚拟操作系统中配置好软件测试管理要使用的相关工具（建议 Office、Tortoise SVN、ALM）。
实践指导：
实践要用到的软件列表如下。
① VMWare 8.0或以上版本。
② Windows Server 2008，32 bit。
③ SQL Server 2008，32 bit。
④ ALM服务器端：Software_HP_ALM_11.0_Simpl Chinese，32 bit。
⑤ ALM客户端：ALMExplorer Add In。
⑥ SVN客户端：Tortoise SVN。
⑦ SVN服务器端：Visual SVN Server。
⑧ Office Word、Power Point、Excel。
实践步骤：
① 能用VMWare启动Windows 2008 Server虚拟操作系统，确保操作系统的IIS服务正常。
②安装SQL Server 2008数据库服务。
③ 安装ALM服务器端。
④ 配置ALM服务器端。
⑤ 安装ALM客户端。
⑥ 安装SVN服务器端并进行配置。
⑦ 安装SVN客户端。第3章测试需求分析
测试需求是测试的出发点，本章主要讲述什么是软件需求、什么是测试需求，以及如何开展测试需求分析。本章学习目标
●了解不同层次的软件需求。
●理解测试需求的重要性及测试需求分析的步骤。
●掌握测试类型分析的方法。
●掌握测试需求的表达方式。
●能够根据理论开展软件项目测试需求的分析。3.1 测试需求3.1.1 认识软件需求
软件需求是测试需求的基础。要认识测试需求，首选要了解软件需求。软件需求分为业务需求、用户需求、功能需求3个层次（见图3-1）。（1）业务需求
●组织或客户的高层次目标。
●描述为什么要开发系统（Why），希望达到什么样的目标。
●一般2～5条，记录在《软件愿景和范围》文档中。（2）用户需求
●从用户角度描述产品必须要完成什么任务。
●用户能使用系统来做什么（What）。
●通过用户访谈、调查、对用户使用场景进行整理等方法获取。（3）功能需求
●描述开发人员在产品中实现的软件功能。
●描述开发人员如何设计具体的解决方案来实现这些需求（How）。
●数量往往比用户需求高一个数量级。
●属于《软件需求规格说明书》的一部分。图3-1 软件需求的3个层次
需求包括功能需求和非功能需求两个方面。（1）功能需求
●用户需求。
●系统需求：用于描述包含多个子系统的产品（即系统）的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。
●业务规则：业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以对某些功能需求进行追溯时，会发现其来源可能是一条特定的业务规则。业务规则可能产生功能需求，也可能产生非功能需求。（2）非功能需求
●质量属性：产品必须具备的属性或品质。系统的质量属性包括可用性、可修改性、安全性、可测试性、易用性等。
●约束条件：也称为限制条件、补充规约，通常是对解决方案的一些约束说明。
●外部接口：外部接口需求。3.1.2 认识软件测试需求
无论做任何事，为了避免出现方向性错误，人们首先要了解需求，测试也是如此。测试需求是解决“测什么”的问题，是整个测试项目的基础，是制订测试计划、开发测试用例的依据。清晰完整的测试需求有助于保证测试的质量与进度，有助于确保测试的覆盖率。如果没有明确的测试需求就开展测试工作，那么经常会出现需求遗漏、产品质量关注不全面等问题。
测试需求必须是可以核实的，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求。测试需求不涉及具体的测试用例和测试数据，测试用例和测试数据是测试设计环节的内容。
如果要明确测试需求，就要开展测试需求分析活动。测试需求分析的输入是软件需求规格说明书。测试需求分析的目标是明确测试范围和功能处理过程。3.1.3 测试需求分析知识准备
1.眼花缭乱的测试分类
软件测试是一项系统性工程，从不同的角度考虑可以有不同的划分方法，了解各种不同的测试分类，能更好地理解测试、开展测试。图3-2所示为软件测试常见的分类角度及相应的类别。图3-2 软件测试常见分类角度及相应的类别（1）根据测试阶段进行划分
依据软件测试流程中各个阶段要开展的测试来划分，可分为单元测试、模块测试、集成测试、系统测试、验收测试等。（2）根据是否执行被测软件进行划分
按照是否需要执行被测软件的角度可分为静态测试和动态测试。静态测试不运行被测软件，比如需求文档评审、设计文档评审、代码走查等。动态测试则通过运行被测试软件开展测试。（3）根据是否使用工具划分
根据测试是手工执行的还是工具执行的可以分为手工测试和自动化测试。一般情况下，性能测试用自动化测试方式。（4）根据测试技术划分
根据测试技术可以划分为黑盒测试、白盒测试和灰盒测试。白盒测试通过对程序内部结构的分析、检测来寻找问题。黑盒测试通过软件的外部表现来发现其缺陷和错误。灰盒测试是介于白盒测试和黑盒测试之间的测试，灰盒测试不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒测试那么详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。（5）根据测试类型划分
测试类型是从不同的角度来分析和测试产品的，测试类型的概念很早就已经存在，比如性能测试、安全性测试、功能测试、兼容性测试等。
2.软件的测试类型
软件的测试类型是从不同的角度有针对性地来分析和测试产品。软件测试执行阶段是由一系列不同的测试类型的执行过程组成的。每种测试类型都有其具体的测试目标和支持技术，每种测试类型都只侧重于对测试目标的一个或多个特征及属性进行测试。准确的测试类型可以给软件测试带来事半功倍的效果。
测试类型有很多种，同一种测试类型还可能有多个不同的名字。如果在网络上搜索，大概有30种测试类型。经过整理，表3-1所示为常见的测试类型及其主要测试内容说明。表3-1 常见的测试类型及其测试内容说明续表续表
3.软件测试类型分析
面对被测软件和测试需求，测试人员需要先分析应该开展哪些类型的测试。为了更好地确定测试类型，要注意测试类型之间的区别。（1）不同的测试类型分析产品的角度不同
这是测试类型划分的主要依据。测试类型的提出就是针对某个测试角度而提出的。比如兼容性测试是专门测试兼容性的。（2）不同的测试阶段重点采用的测试类型也不同
比如在模块测试阶段，功能测试是重点；在系统测试阶段，性能测试是重点。不是说系统测试阶段的功能测试就不重要，在模块测试阶段，功能已经经过测试，所有的模块配合起来的性能尚没有经过测试，所以在系统测试阶段要更加关注性能。（3）不同的测试类型会发现不同类型的缺陷
缺陷有功能缺陷、界面缺陷、性能缺陷，不同的测试类型会发现不同类型的缺陷。（4）不同的测试类型有不同的测试方法
不同的测试类型采取的主要测试方法也不相同，比如，性能测试一般采用自动化测试方法，功能测试则不一定。（5）不同的产品对应的测试类型的集合可能有很大的不同
不同软件的测试角度和测试重点有很大的不同，对应的需要开展的测试（测试类型）也有很大的不同。比如，单机版软件和C/S架构的软件需要开展客户端的安装卸载测试， B/S架构的软件则不需要进行安装卸载测试；移动APP软件需要进行交叉事件的测试，而单机版软件一般不需要。表3-2和表3-3分别列出了移动APP软件的主要测试类型和典型单机版软件的主要测试类型。表3-2 移动APP软件的主要测试类型续表表3-3 单机版软件的主要测试类型续表
测试团队要根据软件的具体特征不断补充及完善产品需要开展的测试类型，形成一个完整的测试类型集合，更好地服务于被测软件。
建立软件的测试类型列表并不容易，这里有两种方法可以参考。
一是建立软件的测试类型列表时参考以往的项目经验，比如在对B/S结构的软件进行测试类型分析时，以往同类的B/S架构软件的测试类型就是一个重要的参考。
二是对照软件质量特性寻找对应的测试类型（见表3-4）。
ISO 9126软件质量模型是评价软件质量的国际标准，由6个特性和27个子特性组成。进行软件测试时，可以从这6个特性和27个子特性去测试、评价一个软件。因此在进行测试类型分析时，对于大部分的软件，可以考虑从质量特性着手进行软件测试类型分析，软件质量特性分类与测试类型之间的部分对应关系见表3-4。表3-4 软件质量特性分类与软件测试类型之间的部分对应关系续表注意
不必过分纠结于测试类型。
登录测试属于功能测试还是安全性测试呢？测试不同操作系统下的安装卸载，属于安装卸载测试还是兼容性测试？安装卸载的响应时间测试属于安装卸载测试还是响应时间测试？
可以将以上问题理解为被测对象颗粒度不同，测试类型分析不仅适用于分析一个软件，也可以具体分析一个需求。比如可以对“安装卸载测试”这个具体的测试项开展测试需求分析，分析结果包括了功能测试、用户界面测试、响应时间测试、极限测试、兼容性测试等。
在进行软件测试类型分析时不必过分纠结于要分多少种测试类型，以及某个测试属于什么测试类型，最关键的是覆盖了全部的测试需求，没有遗漏就可以了。在进行测试任务划分的时候，并不是对每种测试类型单独开展测试的。比如可以将用户界面测试包含在功能测试中；将安装包的兼容性测试包含在安装卸载测试中，而不是兼容性测试中。3.2 测试需求分析的步骤
测试需求分析一般有4步（见图3-3）：原始需求收集、原始需求整理、需求项分析、建立测试需求跟踪矩阵。3.2.1 原始需求收集
原始需求是整个测试活动的输入。一方面，原始需求收集要注意广泛性和全面性，要尽可能地收集原始需求，不要将需求仅仅局限于各种文档、资料。另一方面，原始需求的收集要根据项目的实际情况来开展，不同的产品背景、团队管理水平、测试阶段有不同的侧重点。图3-3 测试需求分析的步骤
●不同的产品背景：如果是用户定制性产品，则以用户需求规格说明书为主；如果是公司自行设计推出的产品，则要将产品愿景等纳入原始资料范围。
●不同的团队研发流程规范性：如果产品的需求分析、管理和跟踪开展得比较好，则可以以用户需求规格和系统需求规格为主要来源，这时产品的原始需求都已经集中到需求规格说明书中。如果测试需求管理不规范，测试需求的收集范围就相应地要扩大。
●不同的测试阶段：不同测试阶段参考的需求有所不同，比如模块测试阶段要参考模块的需求和设计，验收测试则要参考用户需求。
测试需求的来源可能包括但不局限于以下项。
① 用户需求。
② 系统开发需求。
③ 产品愿景。
④ 产品设计说明书。
⑤ 同类竞争产品及其说明书。
⑥ 旧产品及其说明书：如果是产品升级换代的情形。
⑦ 相关的协议和规范：如果产品要符合某种规范，则要将协议和规范包含在需求范围内，比如儿童手机对辐射度的规范要求，建筑软件中对计算精度的要求等。
完成原始需求收集后产生原始需求来源表，见表3-5。表3-5 测试原始需求来源表样表3.2.2 原始需求整理
原始需求收集完毕后是原始的，甚至可能是凌乱的，需要进一步地整理。整理时要确保覆盖全面，要完全覆盖各种原始需求，不遗漏。整理过程中注意对需求进行归类和补充。
实际执行中，很难一次性整理出所有详细的测试需求，可以先进行概要需求整理，再进行详细需求整理。
1.概要需求整理
软件设计有概要设计和详细设计，在需求整理中也应遵循先概要后详细的方法，一般先整理出概要部分，从而对被测对象的需求有一个整体的把握，然后对每一个部分进行详细的分析整理。
开展概要需求整理有以下原因。
●一般情况下，测试团队需要在短时间内给出测试计划，如果等所有的测试需求都分析到非常详细的时候才去计划，那么时间上不允许。
●如果测试方是一个团队，就需要大家配合工作，测试经理可以根据整理出的概要需求进行工作分配，便于测试团队从整体把握被测对象。
概要需求整理的主要工作是浏览所有的需求来源资料，给出软件的概要需求，一般可以分为功能需求和非功能需求两种。概要需求整理的结果建议用列表表示或者用图来表示，后者更加清晰直观。图3-4所示是某在线课程作业管理系统的测试需求分析。
试读结束[说明：试读内容隐藏了图片]