528 浏览摘要
随着全球信息产业的飞速发展，软件的产生在我们的生活和工作中有着越来越多的 影响。在当下竞争日益激烈的市场，对于如何提升软件的质量是每一个软件企业都需要 去重视的问题。因而在软件开发的进程中，对软件进行质量的测试，是对软件质量的保 障的十分重要的方式，因此拥有一个较为完善成熟的软件测试管理机制是保障软件在进 行测试的过程中有效性和适度性的最大依据，从而保障该软件投向市场时的质量。
本文将CL公司所拥有的对Saas软件的测试管理作为研究对象，从软件测试过程管 理角度探究其如何改进当前CL公司实行的Saas软件测试流程的管理。本文在探究的过 程中，首先是对软件测试的流程所涉及的相关理论和在进行软件测试的流程中所触及的 过程模型进行介绍。上述的介绍作为基本，对CL公司现有的软件测试管理的现状进行 分析，介绍CL公司的Saas软件所独有的特征，并分析其测试管理当前存在的问题，主 要体现在各职能部门间的协作不畅、需求不明确、测试过程问题以及当前测试过程中所 面临的不同问题。通过构建Saas软件测试过程管理改进模型，介绍其适用范围并进行 详尽的模型分析，以期达到改进当前问题的目的。最后，通过介绍改进模型在CL公司 Saas软件测试过程管理中的应用，提岀计划制定、版本发布标准控制、用例模式改进、 政策保障以及测试过程执行情况、测试结果评估标准，预判改进模型的实施效果，完成 对C1公司在进行Saas软件测试流程中的管理方案改进措施的研究。
通过本文的探究，期待对己有的软件测试过程的管理的相关理论进行扩充，并提高 当前相关领域或公司的软件测试活动的质量。
关键词：软件测试；过程管理改进；TMM
目录
摘要I
AbstractII
目录III
第1章绪论1
1.1研究背景及意义1
1.1.1研究背景1
1.1.2研究意义2
1.2国内外研究现状及发展动态分析3
1.2.1国外研究现状3
1.2.2国内研究现状4
1.2.3发展动态分析5
1.3论文的主要研究内容和研究框架6
1.4研究方法7
第2章软件测试过程管理的相关理论8
2.1软件测试及质量8
2.2软件测试过程10
2.2.1软件测试过程模型10
2.2.2软件测试阶段12
2.3测试过程管理.13
2.3.1测试过程管理理念14
2.3.2软件测试管理内容15
2.3.3软件测试管理周期16
2.4测试过程管理对质量的影响16
2.5本章小结18
第3章CL公司软件测试管理问题分析19
3.1CL公司概况及产品简介19
3.1.1公司概况19
3.1.2产品简介20
3.2公司软件质量管理现状21
3.2.1产品管理现状21
3.2.2研发管理现状23
3.2.3测试管理现状24
3.3测试管理问题28
3.3.1各职能部门之间协作不畅29
3.3.2需求不明确29
3.3.3测试过程问题29
3.3.4当前测试过程中面临的问题31
3.4本章小结34
第4章CL公司软件测试模型构建与分析35
4.1模型可行性分析35
4.2测试模型的构建35
4.2.1测试模型介绍35
4.2.2测试模型适用范围42
4.3测试模型分析43
4.3.1模型优化方法43
4.3.2模型与TMM的关系44
4.3.3多角度剖析模型44
4.4本章小结45
第5章改进模型在CL公司的应用46
5.1实施规范计划和版本发布标准46
5.1.1细化规范测试计划46
5.1.2版本发布标准的控制47
5.2用例模式的改进实施47
5.3政策标准的保障实施49
5.3.1明确测试地位与目标49
5.3.2建立健全测试组织结构49
5.3.3构建完善的测试制度规范以及文档体系50
5.3.4建设和优化测试支持条件50
5.3.5优化测试过程管理50
5.4测试结果评估51
5.4.1监控测试过程执行情况51
5.4.2应用新的准入准出标准和bug规范52
5.5改进后的模型实施效果54
5.6本章小结55
第6章研究成果和结论56
参考文献
第1章绪论
1.1研究背景及意义
1.1.1研究背景
软件行业的发展程度和行业技术创新力都是对国家经济方面和科技发展程度衡量 的一个主要的标致，也是各个行业相关技术发展和提升效率的主要途径和方法，是提升 各个行业信息技术程度的一个重要的支柱。软件领域的长足发展对我国经济发展、社会 进步以及国防事业有着重要的影响。软件领域的高速发展为经济的持续稳定和发展提供 了重要的作用，“百年大计，质量第一”，因此如何提升我国相关软件行业的企业管理水 准提升产品的质量，是我国软件领域能够高速长远发展的重要保障⑴。
随着对软件应用方面的持续发展，对软件程序设计的难易程度也在不断的加深，软 件开发的周期也随之减少，用户在软件质量的需求方面也在不断的增加，因此我国软件 企业将面对一个重大的考验。因此对软件质量的管理需要企业不断的重视。软件的质量 管理是相关企业以质量为核心，通过对其管理过程的设定和提供一定的资源，通过提高 软件管理的水平进而提高软件开发的技术水准，强化软件质量的把控方式，对内部的质 量过程进行监管，消除存在的瑕疵和薄弱的地方,进而满足使用者对软件质量的需求【2］。 高效的软件质量管理不仅可以较少软件维护的所需要的成本，同时也可以提升软件企业 在市场中的信誉从而提高软件企业在市场中的竞争能力。
随着互联网技术的高速发展，尤其是Web2.0的崛起，客户对软件质量的需求在不 断的增加，而软件逐渐的成为一种服务的形式，软件领域在发生着巨大的改变，其中主 要以形成软件，即服务模式最为的突出〔3一5】。Saas不是云计算，云计算也不等于Saas, Saas是进行云计算时一种应用额表现，而云计算则为Saas的后端基础服务提供了相应 的保障。如图1-1中所示与laas和Paas的区别，Saas是一种为用户提供服务的应用程 序，也是软件运营商以云计算作为基础设施的一种程序，客户可以通过各种各样的设备 进行用户端的访问就比如当前的浏览器用户不需要对云计算基础设施进行管理和控 制，例如对网络或是服务器等进行操作，Saas是以设置软件作为基础，以互联网的方式 直接为用户提供相应的服务，同时还可以根据用户的需求定制符合自身的服务。因此 Saas的这一模式为软件的质量管理带来了全新的挑战，对此需要找出相应的策略进而确 保软件服务的质量卩】。而这种全新模式的产生正式对应了需求的发展，以软件服务的形 式替代传统模式的软件销售，这样仅仅可以避免出现盗版软件的产生，同时也可以较少 软件开发企业在软件的开发和维护方面的成本以及出现的问题。
既然是提供给客户的一种服务，它的使用者是具备各种不同形态和需求的人，而人 是具备不同个性的千变万化的主体，产品质量的各种问题也会随之暴露出来，在产品竞 争如此激烈的环境中，用户也会对产品的质量要求会不断提高，这就需要我们不断在快 速创新和更新自己产品的同时更要确保它的质量。而面对互联网产品的飞速发展，这似 乎又是一个矛盾体。Saas软件管理的模式，己经对于传统的套装软件的企业带来了巨大 的压力，在其自身的发展方面进行十分的快速，有许多的调查以及咨询企业提供的相关 的数据可以进一步的显现这一特征囲。其中例如阿里、亚马逊、OpenAir等在软件行业 有着代表的多个企业都开始对这一全新的模式进行关注，同时在传统的软件营销模式方 面进行了大量的投资以便将其营销的模式转变为以服务为主的营销模式，这也是对于软 件质量管理方面一个全新的挑战，因此相关的软件开发企业也应该拿出相对的政策进行 即将面对的以高品质为主的软件服务。
1.1.2研究意义
对于进行软件的测试是对于软件质量的把控上不可缺少的一部分。软件的质量是其 市场竞争力的表现，为了实现对软件质量的保证，相关的人员在进行长期的软件系统开 发的过程中逐渐的积累了较多的经验，同时逐渐的形成了一套卓有成效的方法，但是使 用这些方法时只能对于软件中存在的错误或是薄弱环节进行减少，但是依旧无法避免软 件中存在的所有的错误。因此我们应该重视软件测试在软件质量中的重要作用，通过选 用适合的检测技术和检测战略，进而可以进一步的实现对软件质量的保证。
本文探究的课题主要来源于笔者所在的企业的Saas企业网盘软件项目开发过程中 对测试管理的要求，此项目由于其自身的独有特质和类似于敏捷开发的实施方式，在测 试管理过程中面对的一些问题，为了实现开发过程的需求进而对测试管理的过程进行改
变，提升测试流程的质量以及产品自身的质量，减少项目存在的风险，增加客户的满意 程度，进而提升产品在市场的竞争力。软件测试在项目周期中所处的位置如图1-2所示。
1.2国内外研究现状及发展动态分析
1.2.1国外研究现状
上世纪70年代开始，部分在软件测试方面的学者便对于软件开发的过程这一问题 进行了思考，同时提出依据软件的自身需要在软件开发过程中的初始阶段就可以进行介 入【"I Bill Hetzel博士软件测试方面的宗师对软件测试进行了定义，将其定义为是系统 或是软件程序的特征以及功能，同时可以对系统或是软件程序是否到达对其预期结果的 随意流程的活动，主要的观点是软件测试的方式是对软件检验的过程是进行工作的，也 就是软件的能力是根据需求进行实现的［⑵。Glenford J.Myers在1979年指出，软件测试 应该是对软件存在错误的证明，通过逆向的思维方式查找更多的错误，而不是对软件正 确工作的检验。测试是实现发现错误的一个执行的体统或软件程序的流程，是他对软件 测试的定义卩3］。Mayers指出软件测试其主要目的是进行伪证的概念，指出了软件测试 发展的一道防线，对软件测试的相关理论和方法实践给出了长久的发展方向。该方法的 提出受到了行业以及相关领域专家一致的认同和支持。这一理论运用到后来一直在传统 软件项目上也取得了很好的效果。
软件测试也就是软件质量控制，在国际上是一件非常重要的工程工作，测试也是一 个非常独立的职业。在Microsoft、IBM等开发大型系统软件公司，很重要项目的开发 测试人员的比例能达到1： 2甚至更大，可见对测试的重视程度。在软件测试技术方面， 自动化测试系统正朝着通用化、标准化、智能化和网络化的方向前进。20世纪90年代
中期以来，自动化测试系统开发研制的指导思想发生了重大变化，釆用共同的硬件及软 件平台实现资源共享的思想受到高度重视其主要思路是：釆用共同的测试策略，从 设计过程开始，通过“增值开发”的方式使后一阶段测试设备的研制能够利用前一阶段 的开发成果；软件模块可以重用；使用商业通用标准、成熟的设备，缩短研发时间，降 低开发成本并且易于升级和扩展。
1.2.2国内研究现状
在我国软件测试属于互联网领域中刚刚兴起的一个方面，软件测试就以当前的发展 来说，其不仅仅数一个依赖于软件开发过程中无足轻重的一部分，而应该是己经发展到 一个专业阶段的新兴行业1均。刘云洁指出对于软件质量的检测不能仅仅局限于软件程序 方面，在对软件程序编写的前后对于代码的质量检测也是同样重要的。同时还建议可以 依据把控目标对质量的要求程度以及对软件质量监管方面的不同，在进行软件开发的各 个阶段都应该进行见证点以及停止点的质量把控3】。
王耀志提出企业在进行对软件质量的管理应该掌控包含了加强对软件文档质量的 管理、加强对软件测试质量的管理、加强对软件审查质量的管理、加强对软件配置管理 质量的管理、加强软件在进行外包的过程中质量的管理以及加强对软件过程中能力质量 的管理等六个重点方面的管理卩力。
宋坤等人在进行较大规模的软件体统开发的流程中，使用将整体划分为许多的子任 务的方式，由软件系统研发的小组开始，随后在在釆用提成联调的形式［岡。以及选用了 EasyBug当做软件体统出现Bug的管理工具,并使用MindManager当作对子任务管理的 工具，同时釆用SVN作为当进行软件系统开发过程中出现时间段任务量大同时研发人 员较少的情况下，保证能保证顺利完成全部系统研发的对版本进行管控的工具。
董永健指出在进行项目软件的质量管理的流程中，想要达成人治进而转向法治，就 需要创建完整的科学的软件质量管理体制，这是在进行软件质量管理的过程中必不可缺 的一个重要的步骤"］。在软件项目成立的初期，就应该以软件质量管理体制作为项目创 立的标准，进而确保软件项目在质量方面可以满足软件使用者的需求。对于软件质量的 监管和把控可以使用工程化的方式实现。
杜金环等提出软件质量的度量是强化对软件项目管理的一个重要的环节，指出了可 以运用线性加权综合度量法模型进行检测，通过给出数量值的方式找出存在于软件设计 环节的瑕疵和较为薄弱的地方，通过对杜度量化的使用，可以对软件在测试性以及维护 性方面进行把控，进而提升软件的质量
翁婕等学者使用层析分析的方法，对软件质量可能存在的影响的因素进行了相关性 的分析，通过分析进提升软件的质量，通过对软件质量影响的关键影响的査找，对不相 同的目标进行层次性的挑选和排序，对影响的因素进行分类⑵】。从而使得在对软件可能 存在问题把控方面，软件的研发人员可以通过较少的时间从而将出现的问题有效的解决。
1.2.3发展动态分析
随着软件产品趋向大型化和复杂化，对于软件的高质量是在满足软件使用者需要的 同时也是软件开发企业其自身对产品品质的追求。满足软件使用者的需要是要求软件在 其功能上、界面的简易程度、实用性以及安全性等多方面的需求。而对于软件开发企业 其自身对产品品质的追求主要是简化软件体统复发程度，使得软件在扩充方面、移植方 面以及系统的维护方面更加的方便、快捷。对于Saas软件，对其质量方面的需求，主 要是在于软件系统的有效性、实用性、安全可靠性以及维护简易性等方面的需求〔22-2饥 软件测试技术
，对于传统的软件质量测试主要分为对软件的静态和动态两方面的测 试。静态测试主要是指再进行测试时，以不执行软件的程序代码的形式找出程序代码中 可能存在的瑕疵或是对软件的程序代码进行评估的一个过程。静态测试主要是以人工的 形式进行程序代码的检查、程序代码的走查、程序代码的桌面检查，或是以软件工具的 形式进行自动的静态分析。以广义的角度来看，静态测试也包含了对软件市场需求的分 析以及软件设计阶段所使用技术的审查〔25】。
动态测试是以对测试的数据进行抽样的基础上，通过相关程序的运行进而对软件在 程序的动态行为和程序运行的结果进行检验进而发现软件存在的质量缺陷【26】。动态测试 对软件的质量测试中有多种辅助性的能力，主要包括了产生测试用例、程序的运行和程 序的检验的结果的内容，以及对文档的体系、测试数据的结果、测试操作的流程和对相 关工具的使用等。生成测试案例战略是动态测试最主要的所在，也是其作为动态测试的 对软件测试的有效性和高效性的体现。
近些年互联网行业又兴起了对软件质量测试的新型测试形式敏捷测试，敏捷测试是 一个完整的测试管理方案、一套经由实际实践的或者是经过一定的顺序实现的有测试活 动组成的特定的测试过程【27-29】。该测试流程为了适用于对软件的敏捷开发，通过敏捷测 试力争将软件的质量和开发的效率实现平衡的一套完善的测试流程。敏捷测试与传统测 试的区别，不是由于敏捷测试时的软件质量测试增加快速、不是对测试的时间进行缩短、 也不是减少软件质量测试的测试范围，更不是通过缩减测试的质量而对测试的流程进行 较少，而是在于通过对完整的测试计划、测试阶段的划分、相关的文档、过程的记录、 沟通等方面的不同的侧重。敏捷功能测试=新特性的手工测试（针对user story验证）+原 有功能的自动化测试（回归测试）。
13论文的主要研究内容和研究框架
本文的主要研究内容包含以下几个方面：
（1）研究内容：对当前国内Saas软件的发展现状进行研究，对企业客户群体需求 进行研究，着重阐述当今互联网模式下Saas软件服务背景下软件测试过程管理在整个 开发过程中遇到的困境和过程中留存的问题，同时提出在全部的软件开发的过程中，对 软件测试流程改进的重要性。通过构建CL公司软件测试过程管理改进模型，并介绍其 使用范围，分析测试模型，改进CL公司软件测试过程管理工作。并在构建模型的基础 上，将该模型应用在具体项目中，制定计划、版本发布标准的控制、用例改进模型以及 政策标准的保障，并阐述测试过程分析情况，并预估改进模型实施效果，完成本文的 CL公司Saas软件测试工程管理改进的研究。
（2）要实现的目标：确定软件测试流程管理在整个项目周期中的位置，分解软件 测试过程管理的各个组成因素，以及测试过程管理的各个环节，找出较优组合方式，探 索出最适合于本公司软件的方法，并将方法做成通用标准，运用到不同的项目中去。在 时间计划上力求做到更合理，确保缓冲时间不超过整个时间计划的10%,方法策略上在 保证产品质量的情况下兼顾人力资源的兴趣性和能力的提升，确保团队的稳定性人员流 失率每年不超过10%,这也是提高工作效率的一个重要因素，最后归结为我们的目标是 追求产品质量的功能精致，性能高效，稳定可靠，数据安全有保障。
（3）解决的关键问题：针对CL公司的Saas企业云盘开发过程中的测试过程管理 环节的研究，通过对Saas软件的特点分析，测试理论在敏捷开发过程和传统开发过程 中的运用中会遇到的问题，分析软件项目周期中由于非标准传统或敏捷开发带来的质量 管理上的问题。解决如何去平衡软件测试过程管理中对时间，资源和侧重点的安排，针 对上线后客户反馈的问题以及快速迭代过程中各种条件不标准化情况下出现的计划和 节奏混乱问题研究，适合于项目特点的解决方案。
1.4研究方法
论文主要用到的研究方法如下：
（1）案例分析的方法。起先是对LC公司的公司概况进行了解，同时对其公司的软 件质量管理的现状进行分析，随后将Saas企业网盘软件作为案例进行软件质量管理问 题的探究，最终依据公司的管理现状进行战略的改革。
（2）规范分析的同时进行实证分析。将公司的实际项目进行研究，依据相关的理 论对实际项目软件进行质量的检测，其中的理论包含软件工程理论、软件过程改进理论 和CMMI （Capability Maturity Model Integration,能力成熟度模型集成）标准理论等, 通过上述理论分析得出在该实际软件项目中质量管理存在着诸多的问题的原因。并将分 析作为建立模型的根本，为尝试建立适用于LC公司在软件质量管理方面的相关模型。
在进行全部软件开发的进程中，软件测试过程的管理在其中有着承先启后的作用， 虽然是处在软件开发周期的次末端，但仍然能发挥超出自己的推动作用。在提高工作效 率的前提下，产品质量得到了显著提升，并很好的满足了客户的需求，销售量在业界保 持到领先地位。让客户来为我们做广告，将产品在国内外都得到大家的一致认可，为公 司实现低成本的大量销售。
本文将传统测试和敏捷测试相结合，开创出一个灰色地带，研究出一个为国内互联 网Saas云盘行业量身打造的一种软件测试管理方法。以CL公司的软件测试为例，构建 了一个新的测试管理模型，使之既能在之前的基础上得到改进提升，又能成为可动态扩 展的模型基础。既不教条主义，也不激进主义，做到这两者中取平衡才是关键所在。没 有绝对的创新，关键在于我们如何使用，如何组合其中的元素和元素间的平衡。
第2章 软件测试过程管理的相关理论
2.1软件测试及质量
测试通常引入对比概念，它需要一个测试对象，一系列测试要遵循的相关测试基本 条例，测试会针对实际结果和预期结果的不同给出反馈。很多关于测试的概念解说都是 可用的。在可管理的自动化操作范围内，TMap (Poletal. 1995)从可管理角度提出了测 试概念的定义，釆用了这种定义说明：测试是集合了计划，准备的过程，目标在于建立 信息系统的特征集合，并说明实际结果和需求间的差异［3%
一个好的测试过程是在真正度量完成之前需要好的计划和准备。在信息系统的开发 和维护阶段，质量更应该引起特别的关注。在质量被粗略定义为满足需求的情况下，测 试对质量的不同等级给岀了建议说明。当我们在质量较差的时候发布我们的产品，需要 清晰的说明当前发布的风险。这说明测试的主要目标是用于降低IT系统质量的不确定 性，所以测试需要花费时间和金钱来确定风险的高低。测试客户需要决定花费多少时间 和金钱在降低这个不确定性的级别上。测试需要执行到什么样的程度取决于IT系统带 着多大风险投入使用，所以说有测试就有风险，测试的结果就是呈现风险高低的。
测试是基于一种在IT系统中可能出现的所有情况的最好的可能性抽样调查，实际 上这种方法并不彻底，它只是最大限度的让你知道，测试仅仅用于表明产品状态。可想 而知，测试其实就是发现了其中存在的问题，而这些问题又是我们要修复的，也就是说 仅仅是发现的问题被修复了，没发现的还不知道有多少。基于这种原则，如果提测了一 个较差的版本，就不应该继续测试，而应该重新开发。
如果测试的开发是在一个项目开始时进行的，那么测试将是非常有效的。及早考虑 可测试性，及早进行测试设计，和尽可能早地实现测试，提高了有力预防错误的方法。 这些过程迫使设计人员更仔细地考虑需求和规约的实现，其结果可能改进应用设计。关 于体系结构、详细设计和编码实践的及早决策，都能使测试变得更容易更经济。
软件测试和软件质量的概念是分不开的。测试是手段，质量是目的。质量模式的加 强应该是从上到下开始的。系统的质量是做出来的，而不是测出来的。关于建立质量的 一个组成部分的思考是预防远比修复要重要，预防更重要，且更廉价。预防在系统的开 发的初始过程中是很重要的一步，依靠测试来提升产品质量成本是极高的。在IS09000 中对质量的定义是“质量是能够对集体关系的有关行动、态度、活动与环节等有推进的 作用，进而形成的结果。能够以客户和有关的组织为目标为其实现需求以及期望。而组 织所提供的产品的质量以及服务的标准与客户的能力是息息相关的，和有关方的有益或 无益也是有关的。产品与服务的质量标准不只要求满足功能与性能，还要包括顾客对于 产品和服务质量的评价⑶】。”
ISO对质量的定义大体分为两个部分一个是产品和服务自身的特性符合程度，一个 是相关方感受到的质量。软件产品的质量也包括这两个方面，但软件是特殊的产品，是 一种智慧的产物，它与用户和运行环境（其它软件或者硬件）双向交互，不仅面向最终 用户，还需要面向维护人员，甚至是测试人员和开发人员，因此一般对软件质量的描述 为“软件质量指对用户在功能和性能方面的需求的满足、对规定的标准和规范遵循以及 正规软件公认的应该具备的本质”。软件质量主要有四个方面：
（1）时效性，虽然软件质量描述中没有强调这一点，但在互联网盛行的今天，一 个错过时机的“过期”软件，即使质量再好，也不会产生价值。
（2）需求是软件质量的基础，不符合需求的软件就是谈不上质量。
（3）标准规范的满足程度。标准规范定义了一组指导软件开发的准则，用来指导 团队用工程化的方法开发软件。如果不遵守这些开发标准规范，软件的质量就得不到保 证。这一点对于上万行代码的项目表现更为突出。
（4）软件除了满足需求中明确的需求外，还需要满足一组隐含的需求。比如需求 是开发一款app,针对移动设备特点，app对电力的消耗、流量的需求、存储空间占用 就是一些隐含的需求。
2.2软件测试过程
软件的检测过程一般被使用在软件的检测的环节上，也可以称为一种办法，是一个 抽象的概念［32】。我们大家都知道，如果在开发环节中的质量不行那么就会直接影响都软 件的实际质量，同理，在测试环节中的质量标准也会对测试的结果产生一定的作用，会 影响到结果的可靠性与标准性。所以，软件无论是在开发的环节还是在测试的环节都要 严格按照软件的工程与管理学的有关原理。
在软件的检测环节控制不断发展的过程中，软件的测试人员也在实际的操作中获得 了许多的测试环节的模型。这些模型能够对测试活动实现抽象，也能够和开发的环节实 施有效的结合，为检测环节的发展奠定了基础〔33】。
2.2.1软件测试过程模型
软件开发的生命周期也包括了软件的检测环节，所以，软件的检测环节也要按照软 件工程与管理学等有关的原理来实施。V模型、W模型、H模型是大家最经常用到的三 中软件检测环节模型，下面将对它们进行介绍〔34 一361：
(1)V模型
V模型是在20世纪80年代后期被提出来的，最早的提出者是Paul Rook,其目的 是为了促进软件开发的效率与效果。V模型能够显示检测环节与分析环节两者之间的关 联，如图2-1所示。图2-1表达的就是最简单的开发环节与检测环节，其十分显著的展 示了检测环节里的各种类型的检测和这些检测环节与在开发环节中各个流程里的相关 关系。
图2-1软件测试V模型
V模型表示，单元测试与集成测试的检测任务是要发现程序在实施中能否实现软件 设计的标准；系统测试的检测任务是要发现系统的功能、性能的质量能否完成系统所要 求的标准；验收测试的检测任务是要发现软件的具体实施能否让用户满意。但是V模型 有其不足的地方，它只是以程序为对象而实施的一个查找错误的行为，把测试当作是一 个开发环节用于编码之后，它忽略了检测环节中对于需求分析和系统设计等这些环节的 详细验证。
(2)W模型
Evolutif提出了 W模型，和V模型不同的是，W模型弥补了 V模型在软件开发环 节中的检验和检测的环节，如图2-2所示。两个V模式的结合变成了 W模型，两个V 分别表示的是检测和开发的环节，明显的展示了两者的关系是并行的，而且W模型在 早期便做好了应急的方案，对于测试时间有着很好的把控，有利于减少项目的时间成本。
图2-2软件测试W模型
W模型的特点是其测试出现在了软件开发的整个环节，并且其测试的对象不只包括 了程序、用户需求，还包括了软件设计等，其测试和开发是并行执行的。W模型的优点 就是有利于在每一个环节中检测出问题。比如，在完成了需求分析后，有关的检测人员 就能够对需求的一系列分析进行检测与判断，有利于及早的发现缺点和出现的问题。而 且，此做法也有能够提前检测出项目的难度与有关的风险程度，有利于提前做好应急的 措施，减少风险和后期的检测时间，有利于项目的进度。
但其实，W模型也有着其不足的地方，例如，在W模型里，其需求分析、设计、编 码等环节称为串行，而且，检测与开发环节有着前者与后者的线性关系，只有上一环节 的活动结束才能开始下一环节的活动，所以这样会不利于软件的开发与更新。W模型在 现阶段复杂的环境下，也不能够很好的解决在检测过程中会遇到的一系列难题。
(3)H模型
V模型与W模型都有着其不足的地方，就像前面说的，它们都将软件的开发当成是
需求分析、设计、编码等一系列的串行的行为，但其实不然，上述的活动在很大程度上 都是可以交叉实现的，也就是说，它们之间并没有前后的次序要求。于此同时，各个环 节中的测试，包括单元测试、集成测试、系统测试等都会出现多次的触发与迭代的现象。 所以，有专家在此基础上提出了H模型，其能够把测试环节完全的独立开，使其成为一 个独立的环境，其能够清楚的展示出检测前期环境与检测实施环节，如图2-3所示。
图2-3所表述的只是一个“微循环”是在完整的生产周期中的某一部分的一次简单 的检测。图2-3中的其他流程指的是设计流程或者编码流程或者是任意一个开发的流程。 H模型表达了一个原理：软件的测试是和其他的环节并行实施的，它是一个完全独立的 环节，伴随着整个产品的生命周期。H模型表示出软件的测试要早准备早测试早完成。 对于不同的检测环节可以有着相同的检测次序，当然也可以不同，但如果想检测的环节 能够实现，就要使检测环节能够到达准备的节点。
2.2.2软件测试阶段
测试是伴随着软件的完整的生命周期的一个完整的环节，因为只有这样才可以在检 测的环节中发现软件完成前会出现的问题，并进一步去修改完善它，减少软件开发中的 重复检测。测试的完整流程大家对此有着各不相同的看法，但是基本都包括了检测的计 划、检测的设置、检测的实施以及检测的评价等这几个环节負-39］。
(1)测试计划
测试计划的概念是指一个测试项目的环节，制定各个环节中的目标以及应对措施， 只有这样才能更好的去判断与管理检测。这个流程需要制定测试的计划文案，决定要实 现的测试行为，给测试环节中的每一个环节给予明白的目标；判断实现整个活动所需要 的时间与资源；制定测试结构与工作岗位，制定活动以及合理的分配资源；安排跟进与 管理检测环节的行为。而测试计划中修改的部分要对其实施再一次的检查。
(2)测试设计阶段
测试设计是一个过程，即按照提供的测试计划制定测试方案，制定全面的测试脚本。 测试时间环节中记录的是各个测试环节中应用的检测例子。吧检测计划环节中计划的测 试行为进行分散，可以分为多个可实施的检测环节，建立测试计划里描述的实施测试需 要的因素，这部分因素一般有驱动程序、检测数据集合与具体实施检测所需要的软件, 于此同时还需要给每一个测试环节选出一个对应的检测例子，提前准备好检测的环境与
用具。
检测设计的成果被当成每一个环节中的检测计划的附件用于评审。检测设计有另一 中检测内容是回归的检测设计也称为确定回归测试的用例集。检测例子中被修改完善的 部分也需要再一次进行评审。
(3)测试执行阶段
需要对依照前期准备的测试计划或者应用测试例子对于每一个需要被检测的项目 实施严格的检测，再把得到的结果和期望的结果来进行对比、研究与评价，需要得出每 一个软件的成功与否，是够能通过测试，明确开发环节中需要进行的下一项工作，对其 进行记录、跟进与后期工作的管理完善。
在完成每一个测试之后对于检测出来的错误都要对其实施修改和完善，等到每一个 的测试错误都被修正之后再对原来的所有环节进行新的一轮的测试，得出检测结果，因 为只有这样才能够保证修正后的软件的准确性与质量。在实施环节里，要依照评价标准 去评价测试的任务与被测试的软件，在测试结果出现问题是，要对其进行及时的修改， 制定新的检测计划，一直到检测结果通过，达到标准的要求。与此同时，想要减少出现 更多的错误或者是在修改好的基础上又出现新的问题，要实施定期的回归测试，在固定 的每一段时间都必须重新对之前所修改过的错误实施新的测试，避免其错误重复的出现。
回归检测的任务是对已经被测试过了的项目进行再一次测试，检查其错误不再出现, 当执行好一个环节的时候要对比执行的结果和原先计划的结果或者和测试的文件内容 是否有不同的地方，如果出现了不同点，就要对其实施适当的修改，可以对测试的设计 文件里的内容或者是测试计划的进度管理等的修改。
(4)测试评估阶段
把在测试环节中获得到的测试结果实施总的归纳研究，按标准来评定测试的例子的 有关测试环节以及软件整体的等级高低。想要有更专业结果还可以请专家来进行评估， 得出最后的测试成果。
测试报告中不仅要有测试的对象还要有测试的成果。测试报告能够对测试的成果实 施具体的研究描述。在得到检测之后，能够得到软件所拥有的能力也能够得到它的缺点 与限制的地方，能够获得公正的综合评价以及有关建议，这些建议是针对软件的质量标 准提出的，能够有效的得出是否可以把软件交与用户使用的结论〔"I。
2.3测试过程管理
依照测试的要求、测试计划，对测试中的每一个环节实施记录、跟进与控制，并对 比进行有关的研究归纳，制定与打印各种研究归纳的统计报告〔4七经过仔细的研究并记 录，整合成一个比较完整的软件检测管理文件，有利于减少相同错误的再一次出现在软 件的开发环节里，进一步增强软件开发的质量，所表示的软件检测环节控制示意图如图 2-4所示。
图2-4测试过程管理
2.3.1测试过程管理理念
能够给我们带来软件检测的流程与方式的生命周期模型也同样为检测过程控制奠 定了基础。但其实具体的实施起检测的任务来是比想象中还要复杂任务又多的，所以一 般不可能有哪一个模型能够完全的被应用在每一个检测的任务里。由此，要想模型能够 更好的被应用，应该把不同模型中能够应用在具体情形的检测过程管理理论独立出来， 然后再根据这些独立出来的理论去规划测试过程，去应对会出现的所有状况""I。测试 管理涉及到的领悟十分的广阔，包含有：过程概念、人力资源管理、风险控制等几种管 理理论，下面将简单的对几种进行讲解。
(1)尽早测试
W模型独立出来了一个称为“尽早测试”的抽象理论，其测试环节在软件开发的实施 之前就己经执行了，并不是等到所有代码都编写实现好后面才来进行的检测，因为其测 试和开发两者是相辅相成一同前进的关系。
“尽早测试，，有着两点具体的实施：第一是，软件的前期准备工作要求测试人员的加 入，保证其能尽快的执行测试的前期任务，任务包含有：制定测试计划、确定测试方案 和准备好测试用例；第二，及时的实施测试环节的任务，一层接一层，当软件的代码环 节被编写完成就可以马上的进行单元测试，当代码环节成功的集成为一个独立出来的子 系统就应该马上进行集成的检测，当岀现BUILD提交的情况就能够进行系统的测试任务。
因为能够提前的执行了测试的前期准备任务，所以测试的人员可以在早期的时候便 获得测试的难度和提前预知测试的风险，有利于增强检测的效率和减少检测的风险等。 因为能够提前的实施的检测执行的任务，所以检测的人员可以在早期便发现软件的不足, 有利于后期对BUG进行修正的成本的减少。但如果要进行"尽早测试"时，一定不能盲目 的没有前期的准备就直接进行，其实施的条件是让测试环节执行要达到测试的节点。
(2)全面测试
W模型中有一个非常主要的观点，即软件是一个集合，其中包括了程序、数据与文 档等，所以对软件的检测不能只是对程序的测试，还应该包含了软件的数据、文档等的 测试，对象应该是软件的整体集合。因为需要文档与设计文档都是软件在开发环节中的 部分产品，它们都会对软件的质量产生影响。每一个环节中的产品的质量都是对软件产 品质量的积累，所以如果阶段中产品的质量不能把控，那么也会造成整个软件的质量出 现问题。
上面的检测可以成为"全面测试.，其也包括了两个方面的含义：第一，要对包括需 要、设计文档、代码、用户文档、检测的进度把控、测试方案的修改、需求的变动等软 件的整体产品实施全面的测试；第二，无论是软件开发还是测试人员或者是用户，都必 须全面的出现在软件的检测任务里，而且还要对测试环节实施整体的跟进，比如对于需 求的验证与确定的环节，就需要上述提到的三方的全面参与，因为测试环节不只是简单 的让软件能够成功运行就好，还需要让软件能够被用户所满意。所以还需要制定一个完 善的度量与分析一下机制，对测试的流程进行一个度量，有利于获得到测试环节中的信 息，可以尽早的对测试出现不足的地方进行调整。
(3)独立的、迭代的测试
为了满足不同的需求，人们在软件开发的环节里探索出了很多模型，例如螺旋模型、 迭代模型等等，软件开发中的瀑布模型也仅仅是其中的一种理想的模型。如果需要、设 计、编码等任务是迭代与重复实施的。那么测试的相关工作也一定是迭代与反复的。假 如我们不能够把检测从开发中独立出来，那么测试的控制任务就不能够继续进行下去。
虽然说软件的测试和软件的开发是息息相关的，但是两者不是一个主次依附的关系, 测试活动是独立与软件开发过程的，测试需要注意的一个主要特定是，测试是一个独立 的、重复的测试，其表示，只要当测试的条件满足了，测试的前提准备实现了，测试的 执行环节便可以得到实施。
所以，检测人员不仅需要按照尽早测试、全面测试的有关测试的环节控制理论，还 需要在适合的时机把测试环节从开发的过程中独立出来，使其成为一个独立的测试环节 实施对其管理。要时刻的掌握独立的、重复测试的理论，因为这样可以在很大程度上降 低开发过程中对测试管理带来的工作上的复杂程度〔45)。对于软件环节中不同阶段的产品 与不同的测试种类，只要前提的测试准备完成，就能够更早的执行测试任务，把控软件 的质量。
2.3.2软件测试管理内容
检测控制的详细内容包括有：
(1)测试方案控制：单元检测、集成检测与产品的检测执行中的录入、修正、査 找与打印等。
(2)检测例子管理：检测例子的增加、删除、修改、复制、检查等；
(3)测试例子的检测状态的控制，例如检测的情况包含：未测试、测试中、己测 试；
(4)检测的成绩包括：完成、未完成、出现问题等；
(5)检测例子的环节：录入、排号、进档；
(6)检测环节控制：检测的进度控制；检测环节标记；检测记录与检测的状态。
(7)问题报告控制：问题报告的应对流程(问题报告-＞整改报告)、完成问题报告和 检测例子的建立。
(8)检测报告控制：建立单元检测、集成检测与产品的检测等检测报告；
除了上述的管理内容，还包括了在检测的控制环节中对人员与环境资源实施控制。
软件测试管理人员为了实现软件测试管理，需要组成一个专门的测试管理队伍，队 伍中的人员都能够胜任他们所担任的角色是很重要的。另外，还需确认每种角色的人员 应具有必要的权利以完成他们的责任。同时为了能够获得很高的效率，每个测试管理参 与者又都应最大限度地发挥出其最大的技术能力。
环境资源包括硬件资源和软件资源，它们是提供测试管理的基础。每一种资源都包 括有四个基本的描述特点：分别是资源的表示、实用性表达、使用此资源的时间、此资 源被持续利用的时间〔46】。
2.3.3软件测试管理周期
任何程序，无论大小，都可能会有错误发生。所以所有的新版本都必须要经过新特 点的检测或者是其他特点的回归检测，也体现了软件测试控制的周期性，如图2-5所示。
测试管理人员在接受一个测试管理任务后，除了要制定周密的测试管理计划，还要 进行测试方案管理；并且对测试人员所做的测试活动予以记录，做好测试流程的管理。 同时，对发现的缺陷予以标识，一方面反馈给提交测试的人员；另一方面将存在的问题 和缺陷存入案例库，直至测试通过［47妣］。
2.4测试过程管理对质量的影响
要想软件的质量有保障就要实施对软件艰辛测试这个重要的一项，软件的测试变得越来越复杂，程度可与软件的开发比拟了。以前的软件测试是在软件产品的开发完成之 后再来进行检测的，但是对于现阶段来说，后期的检测已经太迟了，传统的检测不再能 够使用了，因为如果在后期才检查出早期的错误，那么得花费很高的成本去修正它，所 以，正确的软件测试是必须贯彻在整个软件的生命周期的所有环节。
不仅是软件开发过程要按照软件工程原理和管理学原理，软件的测试环节也不例外。 随着软件测试行业的快速发展，大家对于软件的质量要求也越来越高，但是现阶段的软 件的质量越来越难以把控，所以必须不断的加强和推进软件开发的发展，以此来跟上不 断变化的软件开发，使软件测试模型能够更好的为软件的检测带来更高的效果以及质量。 随着软件产品开发趋于复杂化、多样化的同时，传统测试模型己不足以适应当前软件测 试过程。
质量模式的加强应该是从上到下开始的。系统的质量是做出来的，而不是测出来的。 关于建立质量的一个组成部分的思考是预防远比修复要重要，预防更重要，且更廉价。 预防在系统的开发的初始过程中是很重要的一步。依靠测试来提升产品质量成本是极高 的。基于这种原则，一个较差系统的测试工作应该停止，而应该重新开始开发出新的测 试管理流程模型运用到整个项目的质量管理过程中〔列。
测试不是一个独立的措施，测试仅仅是质量管理这个大的积木堡垒中的一块积木而 己，它是用于发现bug的一个组成部分。反过来，对质量的侦测仅仅是质量保证的一种 行为。最后，质量保证仅仅是质量管理中的一部分。在质量管理范围内执行这些措施需
图2-6不同支出之间的关系
要花费金钱。质量管理不行同样会耗费金钱：失败的费用。这些不同的费用总体就叫做 质量花费。如图2-6所示说明了各种不同支出之间的关系。这个图标明在整个质量耗费 中会有一个最小值。质量耗费如下：
（1）预防措施费用：执行预防措施的花费。
（2）发现bug的费用：执行找bug的花费。
（3）修复措施费用。执行修复措施，或者由于质量不和规范导致的费用（失去收 入，额外的服务费用，担保索赔，损害赔偿金）。
这个图为我们传达了一条很重要的信息就是追求完美的质量并不是最有利的，因为 到最后为了质量的一个很小的改进都将会需要一笔大的开销。直接转变为对测试的信息 就是：只要发现在运行中发现和修复问题的金额比产品的不足导致的金额要低，测试就 可以继续。
2.5本章小结
本章主要是对软件的检测环节管理的有关原理进行了讲解，包括有软件的检测、软 件的标准、软件检测环节的定义、模型等，以及具体软件测试过程管理中的概念、理念、 内容、周期，并阐述了测试过程对质量的影响，为下文的研究奠定理论基础。
第3章CL公司软件测试管理问题分析
在本章中对CL公司的产品会做简单介绍，包含公有云，私有云和融合云三种模式。 并以CL公司的Saas服务公有产品为例，结合该公司目前的测试管理现状，对其进行软 件测试过程管理问题的分析和讨论。
3.1 CL公司概况及产品简介
3.1.1公司概况
CL公司主要业务涉及云计算服务（包括云主机，云存储和云基础设施）、技术开 发及技术外包等，致力于推动中国企业“互联网+”变革，助力云计算产业健康发展。 其中云存储业务-企业网盘是中国企业级网盘领域的先行者，自2006年开始产品技术研 发，至今稳定运营10余年。
云存储凭借全球领先的研发创新能力、满足客户核心需求的产品、专业完善的服务 体系，一直领跑中国企业网盘市场，市场份额占比41%。至今已为50+行业、100万+ 企业用户提供安全、稳定、高效、性价比高的数据资产解决方案，在政府、教育、金融、 能源、制造、交通运输、建筑工程等行业树立了产品口碑和标杆影响力。
CL公司企业网盘（以下简称CL网盘）助力企业以高性价比的解决方案实现文件 云存储、高效共享及安全协作，便捷移动办公，海外传输加速，以云产品的身份，向企 业提供大数据存储、发布以及汇总服务。可以作为企业的文件服务器以及FTP服务器的 取代产品，从而降低IT的管理经费，不断优化分支机构管理的效率，加快客户的数据 交换速度。CL云储存至今己服务50+行业，200+龙头企业，300,000+企业用户。
云是数据中心的未来，随着企业的云化进程，越来越多企业转移到线上办公。CL 网盘作为行业领导者，将围绕企业用户的需求和体验，不断创新产品技术，提高企业办 公效率。
（1）优质传输：将8线BGP链路接入到我国的主干网上，并由八大运营商负责网 络的覆盖，利用全球先进的传输技术以及存储技术，不限带宽、不限速度，保在各种网 络接入环境下，提高传输效率。
（2）安全保障：通过密码设置和全面的日志功能，监控账号安全和记录用户操作， 以IS027001国际规范安全管理系统作为标准，对数据加密、软硬件安全防范机制以及 数据容灾等内容加以规范，确保数据的安全性。
（3）可靠平台：一套自主研发拥有自主知识产权的PAAS服务平台，国家级重点 项目，持续运营10年，为本公司和国内主要的IT企业提供云存储平台服务和技术支持， 达到 99.9%的 SLA（Service- Level Agreement） o
3.1.2产品简介
(1)部署模式
由于产品是面向企业而非个人的形式对外发布，根据企业需求组织架构定制网盘模 式，提高办公效率，分为公有云，私有云，融合云三个部署模式。
公有云网盘，满足客户多样的业务需要，按需开通、按量计费的高效服务模式，为 客户提供高效的文档分发和协作平台，
图3-1公有网盘网络拓扑图
私有云部署，满足企业数据管理的IT建设需要，为客户提供满足统一存储、内网 加速、安全可控特性的私有云解决方案
融合云部署，确保了储存模式的灵活性，可以为本地数据中心的选择提供便利，从 而使得大数据在内网流程需求以及各分支机构的合规需求得以满足；同时在对国内外数 据中心的选择上，可以按照业务的需求来进行抉择，从而确保企业跨国业务以及对外分 发需求得以实现，确保数据双通配置的可实现性。
(2)产品形态
除了以上描述的网盘各项功能以外，在产品形式上提供了面向用户的Web, Pc,手 机端，以及Outlook插件等各终端上的应用，从各终端上共享文件办公达到更好地协同 办公的目的。用户通过移动端可以移动办公，Pc端上可以上传无大小限制的文件，Web 端上有更完备的管理功能，Outlook插件能让你传输文件不受附件大小的限制，更灵活 办公。
(3)Saas软件的特点
Saas软件，英文为Software as a Service,是一种提供云计算服务的软件，其通过软 件公司布置云计算系统，将应用程度放置在公用服务器上，进入该系统的消费者可以依 据自己的工作生活需求，将自己的电脑连接在互联网上，向软件公司发送软件需求，通 过一定的使用条件获取使用权限，这是一种全新的软件经营方式。Saas云服务软件具有 很多优点，比如其布置方便，投资成本低，可以按照需求自行定制，Saas软件己经成为 了现在企业首选的信息化解决创新手段。
Saas软件具备很多云服务功能，并且其系统组成一般由以下几个内容共同组成，第 一层是基础部分组成结构，可以为用户提供计算、存储、处理、网络等云服务系统基础 服务，这基本是所有的云计算系统都要具备的，用于软件开发和功能实现。第二层是系 统管理层，这一层是为了对接相应的管理软件和为提供软件接口的管理层部分，能够实 现云计算服务系统的管理和集成服务，并且可以分配资源，集成其他管理软件功能的强 大管理平台。还有一层是各类软件的功能实现模块，这层是该云计算软件的应用功能集 成层，能够为消费者提供软件在线服务，包含企业资源管理系统、企业客户管理系统、 网络办公平台、供应链管理系统等多种操作系统，并且能够为软件用户提供实时在线的 交流平台。最后一层是软件客户端访问，这一层通过云服务，不需要客户端，用户可以 通过笔记本电脑、手机、平板等多种连接网络的连接到Saas云计算软件。Saas云计算软 件可以为消费者提供在线使用，按照需求支付费用，合作交流，这在一定程度上提高了 我国企业、政府等机构部门信息化的普及，提升了工作效率，也证明了Saas云计算软件 在我国具有广阔市场。
3.2公司软件质量管理现状
软件质量和研发过程，产品过程息息相关，每个过程都不是独立的，都有互相之间 的渗透和关联。
3.2.1产品管理现状
产品管理是公司通过组织架构的形式对产品或者产品线的生产计划、市场或者生命 周期进行的一项管理过程。而对于产品管理而言，具有高典范性的矩阵式管理特点。从 内容上来说，它是一种对企业产品在各环节中的一项业务管理过程，主要包括规划、生 产、开发、销售以及支持等方面，现阶段CL公司包含了需求管理，产品的战略和市场 管理，产品研发设计管理这几部分。
需求管理主要是对需求相关的设计和文档管理，包含了需求设计文档及UI/GUI设 计，需求主要来自两个方面，由战略目标和市场竞品分析得出的产品方向和真实用户反 馈的需求。一般通过战略目标和竞品分析得到的需求会放在产品的主线设计中，也就是 大版本规划，通常这部分需求不紧急，或涉及改动较大，代表着产品的发展方向，产品 生命周期也较长。但作为互联网产品的Saas服务，又不能迭代速度过慢，长久不更新， 所以在这期间会同时穿插了小版本的迭代，就是需求的另外一个来源，来自用户的反馈。 通常会将用户的反馈加以整理，将紧急的，周期较短的以及改动影响不大的需求作为快 速迭代版本上线，在用户反馈的问题中还包含了一部分bug,不涉及架构和功能涉及的 bug也会安排到快速迭代版本计划中。
战略和市场管理主要是为了使产品能够具有与其他产品更明显的优势进行的分析 和研究，一般战略方向由产品经理或产品主设来完成，并经过其上级领导的认可后方可 执行。产品的研发设计管理是针对已经确定要实现的需求后应该做的后续相关事宜，包 括和相关研发的评审确认，设计文档的提供，UI/GUI的设计等。这期间可能会因为前 期评审的一些工作量评估的失误会有相应调整。产品管理流程如图3-2所示。
需求文档是增量式提供，只是针对本次修改部分的文档及设计。由产品部门进行需 求的收集及编写工作，并由产品部门负责相关需求的内容进行收集梳理，从而制定《用 户需求说明书》，且该文件需要由公司负责人加以审核，并交由给研发中心，从而进行
相关的开发设计与测试设计。在该文件内容中，主要对主体功能进行了少量简易的描述， 通过三两句话语很难将用户需求中的所有功能向测试工程师以及研发工程师展示清楚。 例如：按照目前策略服务器以及客户端生成相应的日志，并按照准确的形式对其进行传 输并由服务器加以储存，便留有日志后期查询与管理。但在该项描述中，比没有解释清 楚怎样用什么方法对日志进行储存，且日志的上传需要的时间，在面对服务器中储存大 量的数据以及日志后该怎样处理，怎么对客户脱机的情况下处理日志等问题。
3.2.2研发管理现状
设计、编码、详细设计、单元测试等环节都属于谭发工作的主要路程。具体阶段如 下：
（1）概要设计阶段
研发以需求文档为依据做研发设计，目前研发的设计文档主要是对接口的设计说明, 原理性的说明比较少。《用户需求说明书》的审核符合要求后，其文件的撰写有研发工 程师加以负责，并及时跟踪反馈产品部门的工作开展进度，完成一系列工作后再次送审， 并召开相应的评审会议。会议的召开时间一般来说不会很长，所以没有办法确保工作人 员査看全部文档。尽管己经将审核时间尽早告知，但是还会有部分技术人员没有对文档 先熟悉，仍旧是在审核的过程中阅读，这在很大程度上影响到了审核的进度，也无法使 得审核文档的质量得以保障。
（2）详细设计阶段
UI/UE工程师设计了产品的原型，并对该项工作的设计阶段进行同步更新，与设计 说明书相同，审批工作也需要通过相应的审核。详细设计经常会和概要设计放到同一文 档中，没有明显分开。在对目前工作情况的操控上具有一定的难度，研发工程师不能按 时完成产品的细节设计，且在完成设计工作之后仍旧需要进行相应的审核。然而在现实 中，代码程序员通常会因为项目时间的紧迫性从而直接进行代码的编写，从而也会在一 定程度上影响产品的质量。
（3）编码阶段
尽管对于代码的编写，在CL公司中都要进行相应的规定，然而代码的规范要求并没 有深入企业的每一位员工心中，代码评审并没有在编写完成后进行组织，且在审核的过 程中也存在很多问题。而开发经理也会因为项目进度的追赶而放弃代码评审。可能出现 不同风格的代码，导致人员更换时难以无缝衔接，经常是出现人员流动时就会有一波bug 的高峰期。
（4）单元测试阶段
尽管代码编制完成之后，依照CL公司的研发流程需要由研发部进行相关的单元检测, 然而，却没有将其落实到每一项工作中。由于一般安排的开发进度都比较紧张，上线要 求速度快，开发人员可能只有完成代码的时间，没有真正去测试自己代码的时间。更不
23
用说静态的代码评审了，所以bug通常都是在正式的测试阶段才发现的，导致bug的修改 周期较长，效率低下。偶然有进行单元测试的，然而单元测试也会因为其质量低下，没 有一定的规范性而无法生成相关的《单元测试报告》，且在向测试部门提交了测试后因 为版本上存在的较多问题，从而不能通过冒烟测试，所以使得项目的进度受到了阻碍。
3.2.3测试管理现状
测试过程管理从时间阶段上划分为前期准备，测试执行、测试设计以及测试监控。 按照内容进行分类，还包括测试人员管理，用例管理，测试工具管理，缺陷管理和测试 报告。本文主要从时间线描述，空间上穿插从内容上划分的部分。整体的测试流程图如 图3-3所示。
（1）测试前期准备
在前期的准备过程中，按照《项目总体计划》由测试人员对相关内容的前期准备工 作进行安排,由测试leader完成测试计划的编写，测试计划或称测试方案包含以下内容：
1）项目背景和质量目标；
2）实施测试活动的测试环境、测试工具、测试人员安排、测试进度遵循总体项目 计划安排，如果包含服务端的测试需要给出环境的网络拓扑图。
3）测试策略：需要说明本次测试的重点；功能测试的内容，测试范围包含哪些； 性能测试内容及本次测试范围；其他方面的测试入兼容性，UL安全，易用性，稳定性 等的测试；
4）测试进度计划：实施测试活动、时间及人员安排，如图3-4是进度实施表的范 例。
（2）测试设计
非功能测试用例以及功能测试用例则是测试用例的两大主要内容。系统测试用例、 集成测试用例以及确认测试用例是将其按照阶段从而划分的主要内容。而测试用例在产 品的研发项目中是必不可缺，需要将测试用例需求的覆盖比重在项目的《总体测试计划》 中加以体现。并对用户环境测试以及在研发项目中增加新的模块加以维护，所以测试用 例必须存在。
1）在设计阶段，项目的测试用例则由工程师依照一定需求进行设计，而设计的内 容主要有以下几点内容：测试用例编号、测试目的、名称、输入数据、测试步骤、测试 描述、预期结以及实际结果。
2）需要覆盖所有需求说明中提到的需求点，并且要挖掘出隐含需求，挖掘隐含需 求是用例设计的难点则是设计测试用例所遵循的原则；
3）负责不同客户端的测试用例设计的人员，需要沟通好用例有重叠的部分，避免 出现过多用例比较复杂；
4)测试工程师对测试用例进行审核，并加以组织，由组内以及个人对评审方式进 行审核与复査。组内评审的方式有：审核组的成员可以是所有的项目人员；《测试用例》 代表了输入；《会议纪要》则代表了输出会议纪要内容包含评审结论，参与评审人员， 评审时间等。
5)测试用例需要纳入版本管理，保留每次变更的版本信息。
(3)测试执行
测试执行是整个测试过程中耗时最长的环节，也是整个测试过程中最容易发现问题 的部分。包括集成测试，系统测试和确认测试，一般确认测试的角色不固定，实施或运 维人员有时候也会承担，测试负责提供确认测试的用例。这部分用例一般是从冒烟测试 用例中抽取关键功能点进行检测。
(4)测试监控
测试监控是需求和测试的双向追踪，也是在测试过程中对版本质量状态的跟踪。及 时对软件系统中存在问题进行排查与解决是系统的测试目的，并通过跟踪处理，对每个 存在问题的处理重点工作进行确认与落实。需求的变化应该反映在测试需求跟踪矩阵表 中，并进行测试需求分析、测试范围调整。测试计划、测试用例、测试执行也应有相应 的改变和对应，如图3-5所示。
Bug的管理跟踪主要是通过bugzilla工具实现，bug的处理流程遵循通用的流程规 范并根据项目特点进行了一些相应调整，如图3-6所示。
变更需求
新的Bug由测试人员上交入库，并以New代表错误状态。在对错误的检测上，如 果高级测试人员认定了措施，则由相关的开发人员负责，并以Open代表了设置状态。 一旦发现不是错误，则将其拒绝，并以Declined作为设置状态。当进行状态查询时，如 果显示的是Open的Bug,贝！］用invalid代表了不是错误的状态，如果存在Bug,则以Fixed 作为修复状态。遇到无法解决的Bug时，需要通过相应的说明进行注释，并将Bug设 置成Open状态。且在对该问题的处理上，普遍来说需要经过相应的评审会进行审核通 过，不能简单地由研发人员进行操作。对Bug处于Fixed状态进行查询时，由测试人员 对其进行检验，并将Closed代表了 Bug被解决，用Reopen代表了 Bug有待解决。
Bug的Priority（优先级）和Severity（严重程度）是两个重要属性。一般来说，在Bug 的提交过程中，只有Severity会被进行界定，换而言之为问题的严重性，并由Project Leader或Team Leader对Priority进行界定，并对Bug的修复顺序也尤其要负责。而 Severity则在很大程度上决定了 Priority,且通常来说，Bug的Priority则会因为Severity 的严重而增加。Blocker, Critical, Major, Minor/Trivial 是 Bug 管理系统里中对 Severity 所 划分的等级内容，而Immediate, Urgent, High, Normal, Low则是priority的等级内容。
Severity的定义如下：
1）系统的执行困难、应用模块无法启动或异常退出、崩溃或严重资源缺陷、无法 测试、造成系统不稳定都是Blocker的内容。
2）系统功能或操作受到影响，主要功能不完善，但系统稳定并不会因此受到影响 则是Critical的主要内容。
3）性能缺陷、界面、兼容性则是M組or的主要内容。
4）易用性及建议性问题则是Minor/Trivial的主要内容。
Priority的定义如下：
1）“马上解决”代表了 Immediate,换而言之，需要有处理问题的及时性，否则会 对系统造成影响从而不能满足预期效果。
2）“急需解决”代表了 Urgent,这表示问题的处理非常紧急，这决定了系统能不 能正常运行主要功能。
3）“高度重视”代表了 High,这代表了问题的解决一刻不能耽误，不然就会使得 系统的需求与原先设定的主功能的可实现性遭到破坏。
4）“正常处理”代表了 Normal,这意味着个人计划需要进行解决，但这对系统需 求的可实现性不能造成一定影响，但是会对别的内容有影响。
5）“低优先级”代表了 Low,这表示必须要对系统的解决性在系统发布前加以确 认。
3.3测试管理问题
本文从测试管理的不同阶段开始分析出现的问题，前边提到过测试的最终目的是将 软件的质量风险充分暴露，尽可能提交软件存在问题。
3.3.1各职能部门之间协作不畅
CL网盘的设计师根据产品进行设计的，不同的产品在公司中不是相同部门，产品 部门的生产人员需要归纳产品需求，综合产品的生产工艺和销售方式，和不同部门的工 作人员开会讨论问题：
(1)每个部门的工作方式和工作职责不同，不同部门的工作人员相互不了解，并 且每个部门的考核指标不同，这使得部门之间无法统一工作目标，加大交流成本；
(2)产品部门向研发部门和测试部门提供的产品需求不能满足要求，对于需求不 一致；
(3)产品部门不了解软件工作人员的工作方式，会不断施加压力给研发部门；
(4)产品部门、研发部门和测试人员的工作考核结果不一致，不能有效团结该小 团体会拖累工作进展；
(5)产品需求变更后直接与研发沟通，未经过测试，导致测试结果和实际要求有 偏差，各方信息不统一。
团队协作能力较差，这在研发部门和测试部门之间也存在很多情况，例如产品研发 部门在和技术交流后改变产品设计，却没有及时告知测试部门，也没有将最新研发的产 品交给测试部门，导致测试部门延误工作。另外还有测试部门在测试产品过程中发现了 较为重大的产品错误，却没有及时告知研发工程师。当研发部门工作延迟时测试不了解 产品设计的延迟原因，即使这个时候已经接近研发计划的尾声，测试组选择等待研发部 门而不主动询问原因，这种没有交流的工作方式，严重拖延了产品的研发进程，并且会 降低产品质量。
3.3.2需求不明确
软件的需求描述太过简陋，不能反映软件需求人员的真实需求，只是将想法记录在 纸上，描述不精确的方案使得研发人员不了解软件需求，难以真正挖掘到用户的实际需 求，导致设计的目标不明确，在后期工作中会出现反复修改的情况，研发和测试部门不 能根据需求设计详细的软件设计方案，同时不明确的软件需求也会导致后期大大增加沟 通成本，甚至在软件完成后也会脱离用户需求。
3.3.3测试过程问题
(1)原始的测试
虽然对于如何让测试做得更理想己经讲了不少，但结果是日常实践仍是偏离了很多 这个理想状态。现在很常见的一种原始的测试状态时这样的，测试工作往往都是在系统 要进入产品化上市前的很短一段时间才投入。在这个有限的时间内，测试可能被偶然招 聘的一名人员来执行。测试用例很大程度上是这名测试人员一次性使用的，并且对于 测试的完成度和充分度没有深入分析的见解。测试执行终止的标准往往是产品要上市了 或者是在一段时间内没发现问题。这样导致的结果通常是系统带着很多的bug上线， 这种缺乏质量控制的结果就是需要花费高额费用并且几乎持续性的返工和重新测试。
（2）当前测试情况
知道了到当前的困难形式以后，对于一个好的测试过程管理的重要性在当前被大家 都普遍意识到。在真正投入测试执行前要做好计划和准备。测试用例基于一些其他基础 -功能规格，以便于知道那些是应该测的哪些是不应该测的。虽然这仅仅是正确方向中 的一步，很多组织结果中仍然不能很好的控制。测试经常是缺时间，人力，资源和专家。 测试在开发周期中的后期介入，看起来经常会导致这样的结果：重做，重测，重做，重 测的无休止并且花费着昂贵的费用的循环中。最后，当测试终止以后，仍然不确定测 试是否对所测对象的质量是否给出了充分深入的意见和见解。当我们试图求助测试工具 去提高测试效率，降低费用时，又出现了一个不尽如人意的相反的结果。测试工具重复 使用率不高，所以我们又要花费大量的时间对它做二次开发或维护。
测试过程并不是产生项目重复修订工作高额费用和项目延期的唯一原因，一个很烂 的开发过程管理也是原因之一。测试仅仅是建立一个表明系统有各种不足问题的事实， 改进质量还需要接下来的各种努力。测试能做什么，越来越多的是需要表明产品（缺 乏）质量，并确保测试工作能尽可能的低费用，尽可能的高效快速。
（3）新发展形势面临的问题
虽然当前的情形还不能叫人完全满意，各种新的进展己经展现，可能能为我们提供 测试过程的额外挑战和机遇。面临当前市场产品的激烈竞争，我们要想取胜，团队就要 不断缩短我们的新产品上市的时间。IT系统通常扮演了一个很重要的支援角色。结果就 是团体要不断缩短提供新产品进入市场的压力会越来越大。而且IT系统越来越多的被 用于客户沟通。例如网络应用或计算机电话集成系统，本来处于它们各自的链条中进 行，现在需要一个订票和开发票系统。结果是在可操作管理系统中依赖高质量的IT系 统。系统的质量不足的消极结果将会有深远的影响，客户很不愿意听到这样的答复“这 不是我们的问题，是机器挂了"。
最后，IT创新也是个重要角色。从技术的视觉来看，快速应用开发的介绍，GUL 产品方向，以及架构例如客户端/服务器可能会引起在多元化环境中发展过程的加速。虽 然这个过程发展很快，也没有理由假设在一定时间段内会降低bug的数量。经验的缺乏 和日益增长的技术复杂度证明了在一定时间段内至少会是保持一样的bug数量。例如增 强的复杂度是与有限制数量组合的面向用户的字符界面相比，面向用户的无限制过程组 合的图形化界面就显得异常复杂。然而一般在缩短项目开发时间的情形下将利润用于推 广过程还是难以被接受。
3.3.4当前测试过程中面临的问题
正如前边第三章提到的测试管理现状中，软件测试流程是测试准备阶段，测试设计， 测试执行和测试监控几个部分。在当今的互联网飞速发展趋势下，我们已经不再是仅仅 追求过去传统形式对软件质量的要求了，质量固然重要，效率和时间更是我们追求的。 互联网对速度的要求越来越高，尤其是处在琳琅满目的产品中要脱颖而出，或者要吸引 住用户，优先获取到用户的数据显得尤为重要。
而要做到使得质量和成本达到最优的配比，追求一个平衡点，并不是一件很容易的 事情。它要求既不能只讲求形式，又不能只注重实际，针对现在的测试过程分析，确实 也存在着不少问题，具体从以下几点说明。
(1)产品研发管理问题导致的测试问题
测试准备阶段没有深入做需求分析，对需求的理解不够透彻就开始进入了后面的用 例设计阶段，导致用例设计深度不够，停留于简单的覆盖需求。而前面又提到了需求存 在的诸多问题，使得用例设计粒度过粗，可能会有较多遗漏的测试点。如图3-7所示, 我们的目的是将蓝色和中间绿色的部分这两个区域尽量增大，相应将少黄色和灰色部分 区域的部分。而蓝色区域就是测试重点要关注的。刚才说的这种情况就会出现黄色区域 和灰色区域很大概率变大。而用例设计粒度过细又会导致需求变更时修改用例的工作量 过大，导致出现很多无用功。
再有就是当时间进度较紧张时会省略掉一些要求，例如缺少研发详细设计文档，作 为一个测试人员，应该对需求和研发的设计都分析透彻才能设计出一份好的用例，如果 对软件本身的设计都不太清楚很难说设计的用例能最大程度的发现潜在bugo快速的产 品迭代虽然我们也提倡敏捷开发模式，想通过沟通方式快速解决没有设计文档带来的问 题，如果只是一些小细节的沟通不会有问题，但如果过多的通过沟通方式解决会导致后 续的执行中出现问题时没有明确依据，从而出现各种矛盾和不一致问题。测试人员为了项目赶进度，又想为了给用户一个满意的产品，需要尽量保住质量，就出现了面临研发 和用户的双重压力。
(2)测试部门没有制定项目进度计划
在有些时候，测试部门的工作人员数量不能满足繁重的工作需求，测试部门经理同 时也在进行测试业务，没有多余精力去关注项目进度，使项目一度处于缺乏掌控的状态， 出现了一些问题，比如有的软件有较为重大错误，质量不满足设计要求，研发人员不能 及时修改问题，软件在实现某些功能时会出现问题导致不能测试其他功能，这些问题不 能及时解决，导致开发项目发生延期。所以测试部门负责人需要实时掌控项目进度，了 解项目研发信息。一般测试部门经理需要管理以下工作，比如测试执行问题，测试人员 提出的软件问题，以及软件的突发状况等。
(3)测试没有正规的版本控制
本文在这里说的软件版本是指测试软件的版本控制，是指测试部门对于研发部门提 交的软件进行版本控制行为。在研发部门没有进行软件版本控制时，测试部门一定要进 行软件版本控制，要确保软件的设计版本是可控的。在这里建议研发部门和测试部门进 行沟通，约定哪一个部门进行版本控制，要落实到书面上，确定软件设计版本控制人， 对于每次提交的软件版本进行记录，包括软件变更的设计等等，这些做法可以有效避免 因为软件变更版本导致测试软件出现问题或者产生无效工作。
(4)测试部门的人员流失问题
测试部门的员工离职问题不是个例，这对于IT信息行业来说都是比较常见的。对 于测试部门管理层而言，经理需要和其他管理人员加大对团队成员的关心，打造和谐友 好的团队氛围，及时了解团队成员的工作生活情况，对于各类问题及时解决调整。这是 对于测试部门的建议，如果要从根本上解决这个问题，还要需要公司完善人员管理制度， 为员工设置好职业晋升路线，并提供层体系的培训，打造学习型生态组织，才能够解决 人员流失问题。在前文提到了公司的稳健管理和文件的有效性不能满足人员管理的要求, 在出现人员离职时候会给项目造成不可弥补的损失。与此同时，测试部门没有建立完善 的培训体系，使新入职的员工不能很快的融入团队，对于项目的完成产生了影响。
(5)测试同化现象
测试同化现象是指随着软件的研发进程，软件设计人员会对测试部门的员工产生影 响，包括设计思路和软件缺陷的判断上，特别是对于同一个软件，开发设计人员和测试 部门员工合作了很长一段时间，对于软件本身存在的系统问题，测试部门员工在测试过 程中逐渐熟悉了系统问题，从而忽视了软件问题，特别是在软件设计开发人员的解释说 明下，更容易发生测试同化现象，测试部门员工会接受这种问题，在每次测试中都不会 记录软件问题。
(6)测试工程师的定位效应
部分心理学家曾经做过这样的实验，组织一部分人召开会议，让他们在会议室自由 选择座位，之后让他们从会议室出去，再次进入会议室就座，如此重复5次，实验发现 大部分选择座位时还会选择他们第一次选择的座位，心理学家把这种现象称为定位效应。 定位效应说明人类只要是习惯的认定一件事情，大部分时候是不想轻易改变这个事情的。 定位效应心理同样会出现在软件开发设计人员和测试人员身上，当软件开发设计人员开 发了一个软件功能时，其在其他软件中如果有同样的功能会复制该代码，但是由于这段 代码在上一个软件经过了测试，所以在接下来的测试中会忽略该代码，但是就是这种代 码会引起系统错误。测试部门员工的定位效应的反应是其对于测试过的代码不会再次认 真细致的检测，在进行测试时，对于某些功能经过了测试，认为是可以使用的，再次修 改后进行测试只对以前测试版本出现的问题检验是否完成。
定位效应在多次反复测试中出现的更为明显，一般情况下，测试部门员工对于系统 进行测试时发现的问题会让软件设计部门员工进行修改，软件开发设计人员在修改问题 时可能会造成新的问题，如果测试部门员工如果没有认真检査就会通过，将带有问题的 软件呈交给用户。一般解决这类问题的方法有两种，第一种是重新进行完成的测试，但 是这种方法的资源投入较大，一般情况下会在软件最后一次测试时进行。第二种是交叉 测试，即测试部门的员工交换测试任务，这样可以在一定程度上减少定位效应的心理问 题，对于软件的测试效果较好。一般这俩种方法都要使用，在日常测试过程中使用交叉 测试，在提交软件前进行完成测试。
(7)全部测试拖延项目进度的问题
在软件的测试过程中，测试部门经理经常会遇到该问题。全部测试不是指对某个软 件进行完成测试，而是针对该软件的测试计划全部执行，一般情况下，全部测试需要花 费较长时间，会拖延软件项目的进度。为了节省时间，一般不会对软件进行全部测试。 测试部门员工为了不拖延项目进度，经常习惯性的减少测试软件时间，特别是在软件还 没有开发完成项目功能之前，这种情况更为突出。
(8)Saas模式面临的问题
Saas的管理模式是对软件品质的进一步挑战，在执行Saas模式时，需要制定相应 的软件管理措施来完善软件服务。随着我国网络信息技术的快速发展，web2.0时代的来临，消费者对于软件服务的需求逐渐增大，目前的软件行业都在开发新的软件产品以适 应这种需求。其中最引入注目的软件产品就是形成软件Saas模式。
Saas模型基于软件部署，通过互联网直接向客户提供服务，客户可以根据需要定制 自己的服务。Saas模型有许多特定的需求，包括对软件开发方法和过程的更高要求、系 统架构的灵活性、兼容性和可扩展性、系统部署、操作、技术支持和维护需求。这些无 疑是软件质量管理面临的新挑战，我们需要找到适当的对策来确保高质量的软件服务。
(9)缺陷管理跟踪过程不完善
在整个软件测试过程中，发现软件存在的缺陷并正确报告出来几乎是整个测试目的 的核心，而对缺陷的跟踪管理也是非常重要的一个环节。目前的bug跟踪管理存在着一 些问题，对bug的级别定义虽然有说明，但主观性成分较多，容易产生不同的人对同一 个问题的级别定义也不同，在最后评估是否上线发布时容易产生分歧或者产生错误的指 引作用。例如存在一个不通过的二级bug,但这个bug可能并不足以使产品无法上线， 这个功能点可能只是一个附加需求，很少有人使用，不紧急但产品误以为是一个很容易 实现的小功能点，而实际研发评估后这个功能点上出现的严重问题可能并不是短期内能 解决的问题。按照实际情况，这个功能点不存在也是可以的，它并不足以成为一个阻止 上线的问题。我们应当对bug的定义更偏向于客观化，尽量不存在带有争议性的结果。
(10)没有明确的准入准出标准
软件测试到一定阶段，当需要进入到下一个阶段时仅仅依靠剩余的bug来评估是不 完善的，bug是反映当前软件存在的问题多少和严重程度的一个状态。实际在交付某一 阶段的软件时还应当有完整的节点状态应该具备的内容，比如有该节点状态的代码，研 发设计文档，测试计划，测试用例等。
3.4本章小结
本章首先介绍CL公司概况，并对其产品形态以及部署模式进行了简单介绍，通过 产品管理现状、研发管理现状以及测试管理现状进一步分析公司软件质量管理当前的情 况，之后介绍Saas软件的特点及CL公司公有产品情况，从多角度提出公司当前测试管 理存在的诸多问题。
第4章CL公司软件测试模型构建与分析
本文在上一章节简单的介绍了 CL公司的公有云、私有云以及融合云三种模式的产 品，之后通过对CL公司进行软件测试，在测试的过程中发现当前CL公司存在的问题。 对于这些问题到底应该如何进行修缮与处理。在本章节，主要以软件测试过程中模型改 进的方式来处理CL公司存在的问题。
4.1模型可行性分析
和别的软件公司一样，CL公司也是以测量模型的形式进行软件测试部门的测试工 作。并且软件公司测试模型一般都不是随意构建的，而是根据各个公司不同的管理经验 以及产品特性进行针对性的构建的。软件公司在测试模型的搭建方面投入的资金成本相 对而言是较高的，因此该模型除了能够满足公司自身的测试要求之外，还能够为公司其 他早己经搭建完成的模型做对照。
通常来说，软件测试包含组织管理测试、过程管理测试以及保证测试的相关因素和 条件。尽管各个软件公司设计开发的软件产品不同，但是大体上来说，所有的软件测试 基本测试流程都是类的，并且无论是从测试方法、测试工具还是测试原理上来看，几 乎是没有什么差别的，此外在进行整个测试的过程中就可以看到软件测试管理中所存在 的问题和必须满足的条件环境。无论是哪个公司，在进行组织管理的过程中都会明确制 定公司的总体定位，专门设置相应的岗位职责，明确制定公司的相关制度规定。进行测 试的时候，设置对照组，也就是和测试内容相同的产品进行对比，根据最后的测试结果， 总结测试组织管理和传统测试相比的优点以及其他的作用。站在这个层面上来说，搭建 测试模型对软件公司是百利而无一害的。
4.2测试模型的构建
通过分析当前测试管理存在的问题以及所运用的模型的缺陷，研究创建了一个改进 的测试模型，使之更适合现有的工作模式。
4.2.1测试模型介绍
为了解决CL公司当前软件测试管理中存在的问题，本文在参考国内外软件测试的 基础之上，运用先进的软件测试方法和理论，针对CL公司当前软件测试的现状，搭建 了一个测试模型，具体如图4-1所示。
CL公司搭建的软件测试模型主要由9个部分组成，分别是测 试定位、组织结构、制度规范、险管理、人员管理、测试理论技术和方法论、基础条件 支持、过程管理以及基于TMM (Testing Maturity Model,测试成熟度模型)的过程持续 改进。在这九个模块中，只有两个模块是有明确的划分，一是测试定位可以划分为宏观 思考，另一个是过程管理可以划分为微观思考。至于剩下的7个模块，因为没有明确的 划分，所以不管是从宏观角度来看，还是微观角度而言，都是可以进行讲得通的。从宏 观的角度来看就是，有职能定位、存在意义以及成立的条件，从微观上来看，就是在测 试过程中起到参考、方式路线以及依赖条件的作用，也是彰显了软件测试模型的多样性。
测试模型搭建完成之后，还需要对测试模型运行的环境进行实施保障，也就是需要 对上述提到的测试定位、组织结构、制度规范、险管理、人员管理、测试理论技术和方 法论、基础条件支持、过程管理以及基于TMM的过程持续改进这九个方面各自的职能 和必要性有明确的解释：
(1)测试定位
对于企业来说，测试定位在测试模型中占据的地位还是比较重要的。企业制定的测 试定位决定了企业自身的发展空间、参与程度以及影响范围，并且企业往后的软件测试 工作的重心基本上都是朝着这个目标进行的。在CL公司制定的软件测试模型中，对测 试定位进行了更为详细的划分，主要分为三个测试方向。首先是站在公司的发展战略层 面而言，衡量当前制定的测试定位能否对公司今后的发展产生长足的影响；其次是以提
升公司产品质量以及服务质量为标准，判断当前的测试定位能否在原有的基础之上，迅 速或者长久的改善产品的质量、提升公司产品的服务，从而最终达到更大获益的目标; 最后以部门职权和影响力来看，CL公司在测试定位方面分配的人力、物力以及财力等 其他资源要和最后实现的效果成正比，也就是说付出和回报要成正比。就此而言，制定 公司的测试定位对CL公司的影响是举足轻重的，CL公司的领导以及相关测试部门的 人员应当重视制定测试定位这个环节，并且在制定公司的测试定位时一定要结合企业自 身的实际情况和当前管理现状，选择更为贴合的测试定位，并且根据企业测试实际的运 行定位进行不断的调整和整理测试定位，为企业的软件测试做一个好的开始，形成良好 的铺垫作用。
(2)组织结构
在公司的测试定位明确制定之后，接下来就应该是确定该组织模型内的各个员工的 岗位职责和角色分工了。对于CL公司而言，不但要制定合理的测试定位，还要划分合 理的员工岗位职责，分清各个部门及员工的责任以及职责范围，并且处理好上下级以及 同级之间的工作对接关系，保证在该测试模型内部的所有员工都能够顺利及时的进行联 络交流，解决问题。组织结构主要确定的是员工的职能设置和责任划分问题，只有把在 测试模型中各个员工的职责明确划分到个人，才能更好的保证整个测试模型的顺利运行, 保证整个测试管理和测试执行顺利的完成。可以说，明确划分测试模型中各个员工的岗 位职责和个人职能是顺利进行测试模型的关键，也是测试模型开展下去的前提，并且组 织结构的明确划分在处理某些问题以及决策中充当十分重要的角色。在CL公司测试模 型中涉及的人员里，可以按照各自的职能属性和项目属性将员工分为两类，一类是职能 组织结构，另一类是项目组织结构。尽管职能组织结构和项目组织结构人员的担任职责 范围不同，但是他们的功能实质上是一样的。在具体项目的执行过程中，有可能会按照 项目规模大小的不同任命不同的职能属性的员工作为项目的总经理，但是值得注意的是, 一定要区分项目属性的组织结构和职能属性的组织结构，项目属性的职责和权力只能在 项目中发挥作用，这一点是尤其要注意的。
（3）制度规范
对于任何企业来说，有效的制度和规范是公司实施各种计划及目标的重要前提条件。 站在公司层面来说，严格的规章制度也是公司要求的落实的文件的形式。公司制度的体 现可以是很多方面的，比如确定公司的测试定位和测试方向，制定公司的宏观发展战略， 对公司组织体系的严格约束，包括软件测试人员管理办法、软件测试人员行为规范、软 件测试外包管理办法、测试工具釆购办法、测试资产管理办法等等一系列的办法。当然， 这里要说明的就是测试过程管理规范涵盖的范围很广，其中囊括了软件测试管理办法、 软件测试优化指南、软件测试文档管理办法、软件测试质量管理办法、软件测试风险管 理办法、软件测试评审实施办法、软件测试环境管理办法、软件测试资源申请调配办法 等。总而言之，制度规范是对测试模型中涉及到的人员、资金、产品测试流程以及管理 办法进行详细管理的细节说明。反观测试文档体系规范则是对和测试模型中涉及到有关 文件的详细细节说明要求，包括：测试报告编写规范、测试脚本编写指南、测试用例设 计模板、测试工具配置指南等。建立有效的制度规范对测试模型相关部门以及工作人员 而言都是有利的，可以帮助员工高效的工作和有效的交流，保证测试模型的正常使用以 及测试过程的顺利执行，也是必不可缺的规定。制度规范要点如图4-4所示。
明确测试地位、方针等的根本原则和方向 制定涉及测试部门管理和支撑的管理办法 有制度管理办法，并进行相应说明
（4）风险管理
对于企业来说，任何项目的执行都存在一定的风险，那么如何最大程度的降低风险 一直是企业关心的问题。测试模型也是一样，因此建立风险管理就是为了降低在测试过 程中可能出现的风险，并且制定相应的风险管理办法。在测试模型的风险管理中，将风 险具体划分为两个方面，一是风险范围，二是风险管理过程。CL公司从这两个方向出 发进行风险管理，并在此基础上提出风险管理的使用边界，并且提出风险管理的相关办 法和应对措施。也就是说，在进行测试风险管理的时候，将风险按阶段划分，主要分为 风险识别阶段、风险评估阶段、风险分析阶段、制定策略阶段和风险监控阶段等五个阶 段，并且针对这5个不同的阶段提出相应的解决办法。
（5）人员管理
企业的管理始终和人员管理脱不开管理，对于企业而言，人员肯定是最核心的资源。 在测试模型中也不例外，也是通过资源和人员之间的相互协调和配合，共同完成企业分 配的任务或者是测试任务，最终实现企业的制定目标。在测试模型人员管理中，主要从 以下四个方面进行：人员比例、进入与退出、考核与激励、培训与调配，下面对这四个 方面进行详细的说明。1）人员比例：按照岗位类别和岗位职责的不同，对人员按照自 由人员和外包人员的比例、男性与女性的比例、测试人员与开发人员的比例等的比例进 行分配。2）进入与退出：对企业的测试人员按照不同人员的素质水平和技术水平进行 调入和调出管理，一则是对人员的分配管理，二则是可以对文档等内部资料信息进行保 密管理。3）考核与奖励：对软件测试人员进行定期的考核工作，通过考核规定会有相 应的奖励措施，但是反之则会进行一定的警戒。4）培训与调配：对于企业人员管理来 说，定期的培训不仅能提高员工的个人技能，还能帮助企业实现更大的利益。并且，不 断的进行人员的调配，可以最大限度的发挥员工的个人技能，实现员工的个人能力提升， 实现资源最优分配。人员管理要点如图4-6所示。
(6)测试理论、技术和方法论
相对于其他工作内容来说，软件测试工作是一门技术含量较高的工作，不仅需要专 业的测试技术，还需要相关的测试理论进行支撑。并且从事软件测试相关的工作人员， 不仅要不断的学习IT测试技术，还要积累和阅读测试相关的文献资料，以便掌握相应 的理论。理论知识固然重要，但是经验总结也不可或缺。在软件测试模型中，一方面要 重视相应的软件测试方式，紧跟现代科学技术的脚步，明白科学技术是第一生产力的重 要性，将理论运用在实践中。另一方面是要不断的总结经验和重视经验的积累，分类归 纳岀以往的经典测试方法和测试理论。
(7)基础条件支持
测试的基础条件是保证测试工作顺利进行的前提，也是提高测试效率和测试质量的 关键。什么是测试的基础条件呢？其实对于体系模型而言，测试的环境条件、测试中用 到的工具以及测试调度等都属于基础测试条件。测试环境是类似于实际生产环境的一种 模拟环境，在测试环境中能够进行功能测试和性能测试，并且能够进行单元测试以及集 成测试等等。测试工具如果要细分的话可以分为测试管理工具和测试工具。测试过程中 数据的覆盖以及数据统计都是由测试管理工具进行实现的，而测试工具主要满足功能测
试、性能测试、单元测试以及集成测试等，必要时也可能会引入其他测试软件工具。把 测试调度作为测试的基础条件之一是有原因的。测试调度涵盖的内容是安排测试任务周 期、人员分配、资源分配以及成本预测等内容，而这些内容又是测试工作任务中必须要 考虑的前提条件，因此说测试调度在基础条件中占据的比例也不小。顺利进行测试的前 提是保证基础条件，只有基础条件达到测试要求，测试才能够顺利进行，才能够进行创 新测试等。基础条件支持要点如图4-8所示。
(8)测试过程管理
一个完整的测试周期包含的内容有很多项，测试管理过程主要进行的测试项目管理 有：需求分析管理、人员调配管理、测试环境管理、测试工具管理、测试计划制定管理、 测试方案制定管理、测试脚本管理、测试用例设计管理、测试执行管理、缺陷管理、测 试结果分析总结管理以及测试评审管理等多个环节，正是由于这些环节才组成了测试管 理过程。在每项的软件测试过程中，都可以参照这个流程进程测试工作的管理。此外, 在该测试模型中又加入了测试质量管理、测试变更管理和测试资产管理三个板块。但是 总体而言，所有的测试管理流程都是类似一致的，不过就是在具体测试管理执行的过程 中都要制定严格的制度规范来约束测试管理过程，并且也是作为测试管理执行的保障措 施。过程管理的要点如图4-9所示。
（9）基于TMM过程持续改进
随着科技力量的不断发展，各种技术也在不断的创新，因此新型的科学理论技术和 开发模型是测试手段创新的重要前提，也是促进测试模型不断创新的动力。基于TMM 的过程持续改进，是软件测试过程改进的重要方法，同样也是促进体系创新的方法，CL 公司的网盘测试管理是之前是采用了基于TMM的管理方法，因在实施过程中仍然会有 一些阻碍效率和质量的问题，故改为本文介绍的新的测试模型。
4.2.2测试模型适用范围
普通意义上来说，测试模型不是一个具体的概念，而是在总结国内外的经验基础之 上，结合实际测试过程中的具体经验，归纳出的模型。所以对于软件测试相关的企业而 言，建立测试模型来进行软件测试对公司还是有相当大的指导意义，并且这个测试模型 对于一些积累了一定项目建设经验和管理实践的企业指导作用更加显著。但是对那些想 利用测试模型去判断公司或者测试人员的测试能力来说，就不是很适用。
测试模型不是一个完整的规范体系，还不同于CMM (Capability Maturity Model, 能力成熟度模型集成)和TMM。测试模型不能作为判断测试能力的标准，因此面对不 同的企业或者是不同层级以及不同软件产品的成熟度水平，会专门设置不同的过程域， 或者是评估标准。并且测试模型是对TMM的完善与补充，也可以将测试模型用作是标 准的测试模型，用于和其他模型进行对比。
如果测试的目的是为已有的测试模型提供经验借鉴或者是建设性的指导意义的话， 那么选择测试模型也是可以的。以已有的模型作为对照组，将测试模型作为实验组，根 据最终的测试结果为原有的测试模型提供修改意见或者指导思路。测试模型是面向系统 结构进行设计的架构，运用测试模型进行测试，对任何企业而言都是具有好处的。
4.3测试模型分析
4.3.1模型优化方法
普通意义上来说，测试模型不是一个具体的概念，而是在总结国内外的经验基础之 上，结合实际测试过程中的具体经验，归纳出的模型。所以对于软件测试相关的企业而 言，建立测试模型来进行软件测试对公司还是有相当大的指导意义，并且这个测试模型 对于一些积累了一定项目建设经验和管理实践的企业指导作用更加显著。值得注意的是, 在制定优化方案之前，要对已有的测试模型当中存在的问题进行分析，找出己有模型和 优化模型之间的区别，制定最终的优化模型方案。制定测试模型的优化方案具体分为四 个步骤，下面将对各个步骤进行详细的说明：
(1)对比已有模型和测试模型之间的异同，将已有模型的测试结果和体系模型的 测试结果进行对比分析，可以以表格的形式，将两个模型所拥有的功能、存在的差异、 共同的特点以及不同的地方罗列出来，并观察测试模型和体系模型之间的区别。
(2)重视己有模型和测试模型的对比结果，对这个结果进行详细的分析。并且一 定要结合企业自身的实际情况，客观评价和改进当前的测试模型，确实是否需要增加新 的功能，是否需要立即添加，当前模型中存在的功能在测试模型中并没有发挥实质性的 作用，那么是否需要去掉，这些一系列的问题都是需要慎重考虑的，在做每一个结果之 前都需要经过深思熟虑，始终以最适合企业当前的现状为目标而设置测量模型。
(3)根据已有模型和测试模型的对比，制定适合企业自身发展的优化策略。在制 定优化策略之前，一定要对企业的现状、存在的问题以及未来的发展目标详细了解清楚。 不仅是为了能够制定符合企业自身实际的优化测量模型，而且还能够避免不必要的功能
模块的设计，简化测量模型，达到节约成本的目的。
(4)借助测试能力成熟度和TMM共同完成模型的优化。TMM能够进行测试能力 成熟度的检验，并且能够按照不同的级别以及过程域对不同测试能力成熟度进行不同的 划分，还能针对不同级别和过程域制定不同的评估标准，所以提高测试能力的重要方法 就是TMM。因此，适当的进行测试模型的改进与优化对于企业而言是十分有益的。
总的来说，制定优化测试模型的步骤主要就是上述所说的四个方面，但是并不是唯 一确定的，在企业实际运行过程中，可以根据企业自身情况进行增加或者删减。
4.3.2模型与TMM的关系
TMM和测试模型既不是并列的关系，也不是包含的关系。在测试模型的实现过程 中，TMM既属于一种实现手段，也是一种具体表现，也可以把两者都看作是测试模型。 TMM不仅能作为测试能力成熟度的评估标准和方法，在提升测试能力和搭建测试模型 中发挥了重要的作用。对于测试模型来说，是已有模型重要的对照物，能够清晰的看到 测试模型的构成。TMM和测试模型两者可以互补，也可以独立开来。
单独来看TMM,也可以把它看作是测试模型。在构建模型的时候，可以釆用由易 到难、由下自上的过程，并且一定是企业在结合自身发展的实际环境下，制定一个相对 而言可以提高自身测试能力的模型。并且这个模型能够不断的促进企业向前，使企业能 够不断的进行发展。但是这个模型的缺点是发展历经的时间较长，并且在企业发展的过 程中，缺少对照物，很难发现自身存在的问题以及发展的局限性，不能及时的进行战略 上的调整，以至于尽管企业一直是处于发展的状态，但是企业实际获得的成果与利益却 是十分微弱的。
相比于TMM,测试模型的实现则显得更有价值一些。因为测试模型在企业测试过 程中充当的是参照物的角色，站在企业的角度而言，能够迅速的发现企业的测试定位、 发展方向以及基础条件中存在的问题，能够很具体很形象的显现出测试模型的构造。如 果企业能够同时将TMM和测试模型进行综合应用，对企业而言才是最有效益的解决方 案。
因此，在制定优化测试模型的过程中，要结合运用TMM与测试模型。将测试模型 作为已有测试模型的参照物，将TMM作为测试模型的实现途径，二者相辅相成，共同 完成测试优化模型的制定。
4.3.3多角度剖析模型
站在企业的角度而言，构建测试模型是以宏观角度出发的。企业考虑测试定位、测 试发展以及测试模型在今后企业的战略发展中有说明作用。在制定了企业测试定位之后, 会根据目标的需要，合理分配人员与资源，并且实行相应的人员管理以及考核措施，制 定严格的测试模型执行规范，选择适用的测试理论以及测试工具，搭建测试模型所需的基础条件，预测在测试过程中可能会出现的风险，并给出相应的风险应对措施，最后再 进行模型的优化与改进。以上所考虑的问题都是对测试模块的基础设计，也叫顶层设计。
企业设置测试模型的岗位人员职能和责任的目的在于更好的解决与处理测试模型 中可能会发生的问题。将员工的职责明确划分到个人，能够便于企业更好的管理，对于 企业测试模型中的运转以及资源的调动能够及时的进行分配管理，对于测试模型的定位 发展、岗位设置以及权力分配、文档管理等也都需要进行详细的管理和规范。
在企业允许的前提下，测试模型的测试部门承担的责任主要是制定测试定位和测试 发展。因此，测试部门可以在自己职权允许的范围内，合理的调动企业的资源，为测试 做准备工作。在测试部门内部，可以根据实际测试工作的需要，设置或者取消相关的岗 位机构，同样的也可以赋予或者是罢免个别员工享有的职权。无论是对于部门还是员工 个人而言，自下而上的管理最后的目的都是为了企业的测试工作能够顺利的进行，相互 配合，一起完成测试任务。从微观角度而言，测试模型中的测试过程管理是最基本的工 作了，这也是为许多宏观的设计做铺垫，是保证测试工作继续开展进行的重要前提。
测试基本过程管理，一个完整的测试周期包含的内容有很多项，测试管理过程主要 进行的测试项目管理有：需求分析管理、人员调配管理、测试环境管理、测试工具管理、 测试计划制定管理、测试方案制定管理、测试脚本管理、测试用例设计管理、测试执行 管理、缺陷管理、测试结果分析总结管理以及测试评审管理等多个环节，正是由于这些 环节才组成了测试管理过程。流程总归是不能对企业产生影响的，最重要的还是要将各 个测试步骤进行具体化，对每一个环节涉及到的人员、资源、技术方法以及理论知识等 都要进行明确的规范。站在微观的角度而言，测试过程中的测试条件、测试支持力度以 及测试保障等都是影响测试的主要因素。测试条件包含了测试过程中涉及到的人员、环 境、时间、资源、设备以及公司制定的相应规范等等；支持力度包含测试人员的技术能 力、测试的理论知识、人员组织结构以及测试所用的工具等等；测试保障就是公司对测 试的质量评估标准、风险管理措施等等。
自上而下的测试模型的搭建过程是测试过程分析的基础需求，夜视镜不断提高测试 质量和提升测试效率的过程。
4.4本章小结
本章根据之前章节分析的CL公司现有测试管理存在的问题构建了适用于CL公司 软件测试过程管理改进模型，分析了模型的可行性，介绍了该模型的各个主要构成要素 的内容，并对其使用范围以及模型优化方法、与TMM的关系等展开分析，并从多个角 度剖析了该模型。
第5章 改进模型在CL公司的应用
从第3章中的描述中可以得出这样的结论，即便现在的测试过程比较合理且让人满 意，将来的情况未必是令人满意的。所以在工作中使用的测试方法也不会是一成不变的, 也是一个不断改进的过程，本文提到的改进模型是结合了目前Saas软件的特点以及飞 速发展的互联网行业的需求做出的，它在执行过程中实际操作内容也是一个随着发展可 以动态变化的。
在Saas软件测试过程改进项目开始之前，CL公司就针对其具体情况和企业环境发 布了相关的改进方案，同时对相关成员展开了系列培训，使得所有参与到该项目的成员 都能够熟悉这一流程，并熟练运用这一工具，以保障项目后期的有序开展。该项目是方 案改进后的首个项目，故而受到全公司的重点关注，该公司按照改进方案对组织架构进 行了重新划分，对于分工和职责更为明确，其中设项目经理1人；风险管理2人；软件 开发部共设置19人；软件测试部共设置8人；质量管理组共设置9人。与此同时，整 个项目保持井然有序的进行着，并合理实施各项管理。截至目前，项目如期发布，未出 现延期现象，虽然在整个过程中不可避免地出现了很多问题，但是因为事先进行了合理 的风险预估，故而，各个问题都得以很好的控制。
5.1实施规范计划和版本发布标准
5.1.1细化规范测试计划
测试计划是测试项目中的重要工作，编写测试计划可以更好地收集各种想法、不同 观点以及相关记忆。通常情况下，在召开测试计划评审会时，会针对测试计划的终极目 标展开系列争论以及讨论。一旦进入测试阶段，人们的目光往往是聚焦在某一细节上, 缺乏对于整体的把握。
对于一项比较重大或者比较复杂的项目而言，要想保证项目后期能够顺利进行，往 往需要依据项目具体情况指定适宜的测试计划。而对于一些规模相对较小的项目而言, 往往只需要一个测试计划，就可以将后期测试的各个等级都覆盖。因此，在制定测试计 划之前，有必要对该项目的规模以及范围做出合理的定位。
在测试活动日益复杂的情势下,我们更加需要一个良好的测试计划，如图5-1所示， 以便为后期项目执行保驾护航。
5.1.2版本发布标准的控制
在针对项目进行测试时，会不断有新的测试版本被发布出来，而测试者从准备测试 环境到安装新的测试版本这一过程会耗费大量的时间，一旦出现所提交的版本因为模块 异常而导致的版本不可测问题，那么势必会严重浪费整个测试过程的时间，因此，所提 交的版本保证可测是高效完成测试的首要条件。为了减少这种问题导致的时间浪费，测 试内部专门针对这种问题开发了一套自动化的工具，一旦新版本推出，可以在非上班时 间安装并进行冒烟测试，如果新版本能够通过冒烟测试，测试人员可以在上班时间安装 并进行进一步的测试，如果不能通过，就无需安装新版本，继续使用旧版本，来提高测 试效率。
5.2用例模式的改进实施
测试用例的编写主要是以需求文档、系统设计文档等作为依据，他主要是为了对系 统的需求进行验证，了解其是否能够满足某一特定需求的一组测试输入、执行条件以及 预期的结果，最终需要形成一种具有统一格式的文档。测试用例的作用是对测试活动进 行指导，测试人员在实际测试过程中，各项测试活动都是严格依据测试用例中的各项要 求来执行的，同时采用测试用例管理软件来记录各项测试结果，从而保证测试状态被有 效跟踪。在测试过程中，测试用例具有重要的作用，其被作为测试的标准而严格遵循， 与此同时，测试管理中的一项重要工作就是对测试用例进行管理。
测试用例所涉及到的内容较多，如测试目标及环境、数据的输入、测试中的各个步 骤、预期的测试结果、测试脚本等。通常情况下，各个公司会根据自身项目的具体情况， 构建适宜的测试用例模板，以便后期测试用例编写过程中能够有严格的标准，对于整个 过程的管理以及控制有着重要意义。一般测试用例需要经过初期的编写和后期的评审， 其编写主要是由测试人员来执行，评审则是由开发人员、测试人员以及项目管理人员共 同组建评审小组来执行。
一般情况下，测试用例的设计主要遵循以下四个方面的原则：
(1)对于软件系统的各个功能点应该做到最大限度地覆盖。测试人员在进行测试 前，应该认真解读需求文档以及软件设计文档，精准把握用户地实际需求，同时从操作 层面上细化不同模块地功能点，力争能够最大限度地覆盖到用户地需求。
(2)测试用例应该能够准确定义很多测试内容，如对于测试功能点地定义，对于 测试条件的定义，对于测试步骤的定义，对于输入值的定义，对于预期结果的定义。
(3)在对测试用例进行设计时应涵盖不同类型的测试用例。通常情况下，测试用 例不仅需要满足系统一些基本的功能，同时还应该对于系统的容错性、全面性、易用性 以及与实际业务的相符性做出充足的考虑。
(4)对于测试用例的管理工具进行合理的筛选。通常情况下，测试用例需要经过 不断的优化，并且在后期使用过程中也要持续性维护，因此需要专门的管理工具对其进 行管理，并对版本做好控制及跟踪。
测试案例成功与否的标准是看其是否能够发现某些之前未被发现的错误，而测试用 例在设计过程中也不能保证一定不会出现差错，同时也不能保证对于软件系统的需求全 面覆盖，从理论层面上来说，测试的路径是及其漫长的，在实际的测试过程中不可避免 地会发现一些测试用例中未能覆盖到的测试路径以及数据，此时，对于项目管理者而言， 如何对测试用例进行优化以及维护才是管理过程中的重中之重。
在实际的测试改进方案中，主要涉及到如下几个方面：
(1)对测试管理工具进行统一，制定规范的编写格式。釆用Microsoft测试管理管 理器来对测试用例进行统一管理。使用这一管理器具有两个方面的优势，一是可以创建 测试用例，而是可以创建支持项目测试的测试套件和测试配置。而最为重要的是采用这 种管理工具能够共享用例中的步骤，在实际的测试过程中，很多时候要求测试人员能够 对多个测试用例执行相同的步骤序列，在这种诉求下，釆用创建共享步骤的方法，在对 步骤序列进行定义时更为方便，对于提高编写测试用例的效率来说具有重要意义。
(2)增加用户使用场景。对于认可一款产品而言，其价值的体现均在终端用户身 上，而通常情况下，用户的使用环境具有一定的复杂性，而与之相比，测试环境相对单 一，因此在测试过程中难以发现其所有的缺陷。为此，改进方案中考虑结合用户使用环 境以及使用习惯，编写一套用户场景用例，帮助测试人员更加全面地发掘系统中可能存 在地隐形缺陷。
(3)做好测试用例评审以及测试用例维护工作。测试用例是整个测试实施地标准 与依据，其重要性不言而喻。在过去的项目中，对于新项目用例地评审制度不完善，导 致测试用例杂乱无序，不具备足够的参考价值。基于此，改进方案中对测试用例地评审 工作进行了新的规定，一旦针对某一模块进行了更改，就需要对测试用例进行同步修改, 并由相关评审小组对更改地内容进行严格的评审，只有通过评审之后，才可以将其保存 到配置库中。
5.3政策标准的保障实施
5.3.1明确测试地位与目标
对于测试工作的地位以及目标应该高度明确，应该在公司文件中落实对于测试工作 的重视，将其与企业发展策略以及战略实施联系起来，使得测试发展具有良好的发展方 向以及发展规划。
(1)将测试的定位问题体现在公司的战略规划中；
(2)设置专门的测试部门，并对测试部门赋予足够的职权，保证其在公司的地位 以及权力，以便后期能够做好测试管理工作以及部门协调工作等；
(3)在公司的长远发展规划中，将测试的规划以及方向体现出来；
(4)公司领导应该重视测试工作，明确其在业务服务中的重要作用，并将测试结 果作为质量衡量的重要依据。
5.3.2建立健全测试组织结构
建立健全组织结构体系主要包括以下几个方面：
(1)通过多种方式对职能科室配置进行优化，并将技术测试科室更改为非功能测 试科室；同时再增加了功能测试科室，将之前的功能测试组纳入到功能测试科室，这样 一来，之前的技术测试以及业务测试便可以进行统一管理；与此同时，还增加了测试规 划调度科室，将项目投产计划以及测试任务分配工作进行了统一的规划与部署；增加测 试支持科室，使得多项管理工作以及测试工作有了一定的支持。具体各个科室的数量根 据实际情况而定，设置过程需要遵照功能健全、数目合理以及职责边界清晰等原则；
(2)再进行职能岗位设置时，需要依据其职责范围，务必做到功能健全且数目合 理。如，针对非功能测试科室的具体情况，设置测试管理岗及实施岗、质量管理岗以及 配置管理岗等。当前CL公司软件测试岗位数量相对较少，因此有必要针对其具体请开 给你增加岗位数量，同时对岗位功能进行适当的完善，并根据科室职责范围做好岗位设 置；
(3)做好项目级测试机构以及岗位的设置，面向测试管理成立相关的机构以及岗 位。可以设置相关机构，如测试评审委员会、测试变更控制委员会等；同时可以设置相 关岗位，如测试主管、经理、架构师、需求分析工程师、用例设计师、工程师、性能测 试工程师、质量专员等。机构及岗位设置需要覆盖到测试项目的各项功能；
(4)在管理过程中，制定合理的管理规范以及管理方法，始终保证部门与科室之 间能够和谐地沟通。
5.3.3构建完善的测试制度规范以及文档体系
测试管理过程中，制度规范和文档是不可或缺的一部分，构建完善的测试制度规范 以及文档体系主要包括以下几个方面：
(1)釆取合理的管理方法，如，针对外包制定外包管理方法，针对研发部门制定 研发管理方法，针对采购制定釆购管理方法，此外，还制定了员工管理方法以及行为规 范管理方法等；
(2)对测试过程地管理方法进行完善，如，制定测试文档、质量、资产、环境、 变更、风险、评审等管理办法；
(3)针对测试实施制定管理办法及文档体系，如，测试优化指南、缺陷管理方法、 脚本规范指南、工具使用指等，以及测试报告、测试方案、测试用例设计等；
(4)制定测试制度管理办法以及测试管理规范管理办法，在实际的测试过程中， 可以根据具体情况，对制度及规范进行修改以及增减。
5.3.4建设和优化测试支持条件
建设和优化测试支持条件主要包括以下几个方面：
(1)构建与生产运行环境契合度较高的系统测试环境，以提升测试的准确度以及 测试质量；
(2)构建不同用途的测试环境，以便能够同时满足不同项目的功能、非功能以及 自动化测试；
(3)设置测试环境管理科室，包括测试环境建设、设备釆购及配置以及测试环境 的持续优化和搭建等多个方面，从而制定岀最优的测试环境配置以及最大化的资源利用;
(4)设置测试开发科室，这类科室主要执行测试理论创新、技术研究、工具研发 以及数据分析和总结等工作，为后期测试工作的顺利执行提供理论基础以及技术支撑；
(5)做好各项工具的采购以及改进工作，如测试管理工具的改进及完善，各项测 试工具的釆购以及研发，同时丰富多种测试工具的工具库，以便能够满足后期测试工作 的各种需求；
(6)制定合理的测试任务计划以及测试任务调度方案，在进行计划及方案制定时， 应重点依据项目投产计划，做好测试任务、测试资源以及测试人员的安排和调度工作。
5.3.5优化测试过程管理
对于策划过程的管理工作进行合理的优化，以测试管理规范以及文档体系管理办法 为依据，对测试过程进行完善。主要从以下几个方面着手：
(1)对于功能测试过程，依据测试管理办法进行规范化管理，健全其各项流程； 同时以非功能测试的测试管理过程为依据，对功能测试进行优化，如将缺陷管理、测试
变更控制以及测试评审管理等管理手段用于功能测试中；
（2）设置变更控制委员会机构，一旦测试中有所变更，该机构可以及时分析及管 理；设置测试评审委员会机构，测试过程中产生的交付物以及测试结果都可以及时评审； 与此同时，还可以针对测试变更问题以及测试评审问题制定相关的办法；
（3）对于缺陷管理问题进行优化，同时做好测试工具的普及使用；
（4）对于测试脚本以及测试用例的设计效率以及设计质量进行提升，对其质量指 标以及设计方法进行完善，通过全周期管理测试用例以及脚本设计，最终形成测试数据。
（5）对测试需求进行深度分析，明确各个功能点，做好质量把关，提升对于数据 分析以及测试技术的使用能力；
（6）对于测试环境、测试工具、测试人员、测试方案等都进行合理的优化，做好 测试效果的分析及总结，并使得测试过程中的各个环节都能够受到管控，并建立联系。
5.4测试结果评估
5.4.1监控测试过程执行情况
当对方案进行深入分析以及彻底改进之后，将其书面化以及文档化，同时面向项目 成员进行一定的说明，保证所有项目成员都能够对新的流程及措施有充足的理解。与此 同时，核心小组应该做好流程改进的监督工作，使流程在合理的监督及管理中持续优化。
对软件测试的通过率进行分析，对于企业而言，本身设定了 90%以及95%的软件测
试过程质量标准，产品开发后，应该对其测试通过情况进行持续的监督，一般情况下，
当通过率高于90%时，认为其当前状态处于可控范围，一旦低于这一标准，就需要引以 关注，及时分析其下降的原因。
通过对CL公司Saas软件测试通过率变化的情况进行统计后，将其在2018年9月 至12月间的变化情况表示如图5-2所示（该图由工具生成），由图可见，整个过程中， 在序列14时通过率下降到了 90%,在序列15时通过率降低到了 88%。通过讨论，分析 造成测试通过率下降的原因后发现，之前的一个功能模块在开发后为按照开发流程进行 功能测试，而直接转交给测试部门进行测试，故而导致测试率明显偏低的现象。据此, 在开发团队内部制定了合理的监督及控制体系，确保在后期开发环节中，各个模块都能 够按照已有的开发流程严格执行，测试过程执行工作总暂未出现其他异常。
5.4.2应用新的准入准出标准和bug规范
为了配合准入准出准则能正确执行，将bug做了规范定义，以统一级别。
5.5改进后的模型实施效果
（1）进度实施效果
进度偏差指的是一个项目在实际开发过程中所耗费的时间与初期计划的时间之间 的差值。故而，进度偏差值的正负性代表了项目是是否拖延，当值为正时，代表项目进 度拖延；当值为零时，代表项目进度与计划相符；当值为负时，代表项目进度提前。通 过对项目进度偏差进行度量，可以及时了解CL公司Saas软件测试过程管理项目的开展 是否存在严重拖延，一旦拖延情况超过预期，就需要及时整顿计划，保证项目始终在可 控范围内进行。
通过预测估计，CL公司Saas软件测试过程管理项目的偏差基本控制在10%以内， 而通过对项目进行调整后，其在多项测试中进度都有所提前，项目进度从整体上得到了 很好的保证，即改进后的Saas软件测试过程管理预计可以取得良好的效果。
（2）测试用例评价
测试用例的覆盖率主要是针对测试用例进行测试的执行结果与实际的软件存在的 问题的比较，并以此来对测试用例的有效性进行合理的评估。改进前与改进后的Saas 软件测试过程管理中，通过统计报告的软件缺陷被现在的测试用例覆盖情况来确定测试 用例的覆盖率。改进后的CL公司Saas软件测试过程管理的测试用例从测试的各个阶段 都相对之前有所提高，这对于软件质量的提升有着重要意义。同时也说明测试用例在进 行改进后取得了相当可观的效果。
（3）软件质量评价
对于某一项目而言，其过程中的Bug趋势走向应该是符合一定规律的。从理论层面 上讲，合理的Bug趋势图应该是在初级阶段Bug数量逐渐增多，随之快速达到一个峰 值，继而持续减少，整个过程中会岀现一定的波动，最终达到允许的水平范围内，整个 过程呈现出“几”字形。预计改进模型后的Saas软件测试Bug趋于“几”字形理想状
O
（4）用户满意度评价
通过对用户满意度进行调查后发现，对改进前后的CL公司Saas软件测试展开用户 满意度测评，用户满意度有大幅提升，即代表了改进模型提高了软件测试的整体质量。
5.6本章小结
本章引入上一章中构建的模型，并将其运用在CL公司实际项目中，介绍了实施规 范计划和版本发布标准、应用改进后的用例模式、实施新的政策标准、测试结果评估规 范化的实例，并描述了改进模型后的实施效果。
第6章 研究成果和结论
目前我国的软件产业正处于快速发展的态势，目前我国的网络信息行业发展迅速， 软件的开发不断增加，国内外软件市场的竞争越来越剧烈，我国的软件产业正处于起步 阶段，市场发展前景广阔。软件公司的发展机遇很多，但同时也面临巨大挑战，软件测 试行业的发展也不仅仅停留在追求高精尖的技术上，还要全面提升测试质量，这是被软 件行业所公认的。
本文根据软件行业测试管理过程及其相关理论和模型，借鉴国内外软件行业测试先 进经验，结合笔者在华北电力大学所学的相关理论知识及学习过程中了解到的相关软件 测试技术，结合实际情况分析了 CL公司目前软件质量管理现状及存在的问题，提岀了 软件测试过程的改进建议，结论如下：
(1)对软件测试、软件质量以及软件测试过程的模型及其相关理念、内容、周期 等理论知识进行学习，获取了软件测试过程对质量的影响。
(2)本文以CL公司软件测试为研究对象，在熟悉CL公司软件测试管理现状的基 础上，从职能分布、测试需求、测试过程等方面分析了公司Saas软件测试的特点，提 出了测试管理当前存在的诸多问题。
(3)建立了 CL公司软件测试过程管理改进模式的模型，并对其进行分析，介绍该 模型TMM的关系，多角度剖析模型概况。
(4)分析了改进模型在CL公司的具体应用，并给出预估实施效果。
由于本文的研究是以CL公司Saas软件模型为研究对象进行的，对该模型的测试流 程进行优化，引领软件行业测试体系发展，依此构建了相似领域的通用模型并可动态扩 展的综合模型。
首先，软件的测试流程不是固定的，这是因为软件需要根据相关条件进行修改，比 如公司的战略目标、涉及行业、新开展的业务，以及软件测试理论的发展等条件，及时 适应各种影响因素进行调整。
其次，软件测试体系需要完善软件评价体系，构建相关指标体系，优化评估方法。 现在实施的软件评估体系是根据公司积累的经验进行总结的，对于日新月异的软件发展 评价稍显不足，在接下来的经营过程中需要不断引进国内外先进的理论体系以优化评价 模型，研究评价体系进一步的应用可能性，提升模型的实用性。
最后，通过总结真实公司的软件测试现状，提出相关的优化方案和实施保障，并跟 踪优化方案的执行情况，分析实践结果和预期效果的差异，确定改进方案的正确性，为 我国软件测试行业提供借鉴。
参考文献
[1]王象刚.软件测试过程管理工具的设计与实现[J].软件，2014(2)： 96-97.
[2]王迪.电液控制系统软件测试过程管理分析[J].煤矿机械，2017(6)： 8-12.
[3]李国萍.浅析有效进行软件测试过程管理的方法[J].通讯世界，2015(10)： 201-201.
[4]尤艺，李志敏，谢鹏.软件测试过程质量保证管理系统的搭建及应用[J].计算机仿 真,2014,31(10)： 54-57.
[5]李乔，郑啸.云计算研究现状综述[J].计算机科学，2011, 38(4) : 32-37.
[6]丁荣涛，中小企业Saas模式的商务智能系统研究卩].现代商业，2009, (08)： 191-192.
[7]徐彬，张凌东，李华.基于SFMEA和SFTA的软件测试[J].电子设计工程,2018(16)： 85-89.
[8]李乔，柯栋梁，王小林.云测试研究现状综述[J].计算机应用研究,2012.29(12)： 3-6.
[9]Khomh F, Khomh F, Kai P. On rapid releases and software testing: A case study and a semi-systematic literature review[J]. Empirical Software Engineering, 2015, 20(5): 1384-1425.
[10]Korel B. Dynamic method for software test data generation[J]. Software Testing Verification & Reliability, 2010, 2(4):203-213.
