软件测试过程与改进技术

软件过程管理的现状
既然说到了软件开发的过程模型，就不得不提一下目前软件过程管理的现状，目前主要有两大体系，CMMI和ISO9000。 [资料来源：www.THINK58.com]

1.2.2.1 CMMI
CMMI（Capacity Maturity Model Integrated）中文的意思是能力成熟度集成模型。CMMI有两个表示方法（Representation），分别为阶段式（Staged Representation）和连续式（Continuous Representation），涉及面很广，其领域覆盖了软件工程（SW）、系统工程（SE）、集成产品开发（IPPD）和系统采购（SS）等学科。
CMMI是在取得巨大成功的SW-CMM模型的基础上，结合EIA/IS731模型以及IPD-CMM模型而形成的一个全新的集成型模型。CMMI融入了大部分最新的软件项目管理实践，是IT行业最佳实践的集合，同时弥补了SW-CMM模型中的缺陷。CMMI的实施能够提高企业的管理水平，同时降低企业的研发成本。
CMMI Staged Representation中共分为5个等级[7]，每个等级中包括数量不等的PA（Process Area），其不同的等级代表了企业不同的研发、管理成熟度。
Level 1――初始级。在初始级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。
Level 2――管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。 think58 [资料来源：www.THINK58.com]
Level 3――定义级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化。这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。科学的管理成为企业的一种文化，企业的组织财富。
Level 4――量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
Level 5――优化级。在优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。
按照目前国内中、小型企业的过程管理状况，多停留在Level 3或以下，很少有能达到Level 4——量化管理级的，尽管如此，在测试过程中加入量化控制依然是必要的，这样可以反过来促进开发过程的进步。
过程的总体设计
2.1 过程中各阶段的关键点的描述
在综合的考虑了目前国内软件开发的现状以及模型的可重用和移植性后，决定以瀑布模型为基础来建立测试的模型，因为其他国内所使用的过程模型从根本上来说，也还是能够被分解为瀑布模型，当需要对该测试模型进行移植的时候，只需要将开发模型分解后再代入就可以了。以下就针对瀑布模型的各个关键过程点，来说明一下目前的问题以及需要改进的地方： 本文来自think58 [来源：http://www.think58.com]
1． 需求分析阶段：因为本阶段是软件开发的起始阶段，因此要根据目前的测试资源情况，找到一个合适的切入点，并且这一阶段需要编写系统测试的测试计划跟测试用例，如何进行量化控制也是一个关键点。
2． 设计阶段：该阶段因为会涉及到一些技术实现的细节问题，如果解决好目前软件测试人员技术能力不强的问题是该阶段的关键。
3． 编码集成阶段：该阶段所遇到的主要问题依然集中在测试人员技术能力的不足上面，所以基本上是跟设计阶段一样。
4． 系统测试阶段：这一阶段的重点就是如何对发现的系统缺陷进行记录管理，以及对结果数据的分析上。 [资料来源：THINK58.com]

2.2 设计原则
由于本文所设计的测试过程是面向目前国内所有中、小型软件公司的，而这些公司所采用的技术工具也各式各样，因此，在设计的过程中，将尽可能的不设计到具体的技术及使用的工具，而仅仅是提供一个可以普遍适用的的过程框架，仅定义出在软件开发各阶段的关键活动，这样各公司可以根据自己的实际情况来选用合适的技术工具，进而增强了本过程的适用性。
测试人员介入项目的时间点
在这里，我们把测试人员介入项目的时间点定义在需求调研完成，第一版的需求规格说明书出来，进行评审的时候，根据对软件缺陷修复成本的分析[9]，我们可以发现，缺陷被发现的越早，其修复的成本也将会越低，根据这一结论，我们可以很容易的推断出，如果测试人员在需求调研的时候就介入到项目中将会是最理想的情况，因为需求调研是整个项目的开始阶段，如果再这一阶段的时候就能很好的控制缺陷，将大大降低项目开发后期的成本，但是很遗憾，由于需求调研是一个长期的过程，需要大量的人力投入，而公司的测试资源是有限，按照现有的情况，经常是会有5-6个项目在同时开展，而实际能提供的测试资源却只有两到三个人，要把测试人员在进行需求调研的时候就投入到项目当中显然是不可能的，因此，测试人员介入的时间必须后推，于是，在需求评审会上介入就成为了最佳的选择。要评审的需求可以在评审会前的2-3天由项目组提交给测试人员，然后由测试人员抽时间进行预审，把其中发现的问题记录下来，留待正式的评审会上解决，这样在整个需求开发阶段，需要测试人员投入的工作量就大大降低了，并且只有需求评审会的时间是固定的，像之前的需求预审及之后的测试用例设计等，都可以根据其他项目的进展及优先级情况来灵活的对测试资源进行调度，极大的缓解了测试资源不足的问题，并且也把查找缺陷的最初阶段定义到了需求开发阶段，在成本和资源之间取得了一个很好的平衡。 copyright think58 [资料来源：http://THINK58.com]
3.3 测试文档的开发
3.3.1 功能点测试说明书
一旦需求规格说明书基线了之后，就可以开始考虑测试需求的整理——也就是明确地定义现阶段要“测什么”。测试需求的确定将为我们制定进度时间表分配资源以及如何确定某个阶段测试工是否完成提供一个可供衡量的标准。当然还有更重要的一点：已被确定的测试需求是我们进行测试用例设计和考虑测试覆的依据。整理测试需求的第一步，就是要“测试需求”。这里的“测试需求”中的“测试”是一个动词，指的是对软件需求本身的检查。这是测试工作的开始。软件分析设计阶段测试人员除制定测试计划书等本职作外，还有一个必不可少的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。之所以要这么做，是因为加强测试用例在测试过程中的地位、强化测试用例管理过程，如果编写测试用例直接参考需求规格说明书或者分析流程图这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因。
因此首先需要编写的文档就是功能点测试说明书，它是软件的详细测试分析文档，其主旨是将系统分析人员的分析文档加工成站在测试角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的效验描述，包括何种方法测试，何种数据测试，测试结果期望值等，这些信息都是描述性的，无需具体数据，只要用容易理解的自然语言就可以了，明确地描述一项需要测试的内容，对于多项测试内容，应尽可能地剥离开来，它的作用是据此编写测试用例，以及测试执行时的参考依据，它直接来源于需求，覆盖最全，也最贴近客户。 内容来自think58 [资料来源：THINK58.com]

3.3.2 测试计划制定
接着需要制定测试计划，一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告等等。其中包括的具体内容如下，1、产品基本情况调研：这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。2、测试需求说明：这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。3、测试的策略和记录：这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好。4、测试资源配置：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。5、计划表：测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。6、问题跟踪报告：在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。 本文来自think58