软件测试心得

摘要

随着软件产业的发展，软件产品的质量控制与质量管理正逐渐成为软件企业生存与发展的核心。几乎每个大中型IT企业的软件产品在发布前都需要大量的质量控制、测试和文档工作，而这些工作必须依靠拥有娴熟技术的专业软件人才来完成。软件测试工程师就是这样的一个企业重头角色。目前的现状是：一方面企业对高质量的测试工程师需求量越来越大越大，另一方面国内原来对测试工程师的职业重视程度不够，使许多人不了解测试工程师具体是从事什么工作。故写此论文，对软件测试的概念、理念、方法、技术等进行一下表述，并总结一个多月中软件测试工作的心得和经验。

论文主要分两个部分讲述了软件测试：

第一章，从理论上介绍软件测试的定义、理念等。

第二章，从一个多月的软件测试工作中获得的经验和心得。

第一章 介绍

1.1 软件测试简介

软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。

1.1.1 软件测试的概念

使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别.

它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。

软件测试工程师Grenford J.Myers曾对软件测试的目的提出过以下观点:

(1)测试是为了发现程序中的错误而执行程序的过程；

(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

(3)成功的测试是发现了至今为止尚未发现的错误的测试。

然而,这种观点指出测试是以查找错误为中心,而不是为了演示软件的正确功能.但是只从字面意思理解,可能会产生误导,认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上并非如此!

(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进；

(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性；

(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法

1.1.2 软件测试的原则

软件测试的几大原则： 

1.软件开发人员即程序员应当避免测试自己的程序

不管是程序员还是开发小组都应当避免测试自己的程序或者本组开发的功能模块。若条件允许，应当由于开发组和客户的第三方测试组或测试机构来进行软件测试。但这并不是说程序员不能测试自己的程序，而且更加鼓励程序员进行调试，因为测试由别人来进行可能会会更加有效、客观，并且容易成功，而允许程序员自己调试也会更加有效和针对性。 

2. 应尽早地和不断地进行软件测试 

应当把软件测试贯穿到整个软件开发的过程中，而不应该把软件测试看作是其过程中的一个阶段。因为在软件开发的每一环节都有可能产生意想不到的问题，其影响因素有很多，比如软件本身的抽象性和复杂性、软件所涉及问题的复杂性、软件开发各个阶段工作的多样性，以及各层次工作人员的配合关系等。所以要坚持软件开发各阶段的技术评审，把错误克服在早期，从而减少成本，提高软件质量。 

3.对测试用例要有正确的态度：第一，测试用例应当由测试输入数据和预期输出结果这两部分组成；第二，在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件。因为软件投入实际运行中，往往不遵守正常的使用方法，却进行了一些甚至大量的意外输入导致软件一时半时不能做出适当的反应，就很容易产生一系列的问题，轻则输出错误的结果，重则瘫痪失效！因此常用一些不合理的输入条件来发现更多的鲜为人知的软件缺陷。 

4.人以群分，物以类聚，软件测试也不例外，一定要充分注意软件测试中的群集现象。不要以为发现几个错误并且解决这些问题之后，就不需要测试了。反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益。 

5.严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作。 

6.应当对每一个测试结果进行全面检查。一定要全面地、仔细地检查测试结果，但常常被人们忽略，导致许多错误被遗漏。 

7.妥善保存测试用例、测试计划、测试报告和最终分析报告，以备回归测试及维护之用。

在遵守以上原则的基础上进行软件测试，可以以最少的时间和人力找出软件中的各种缺陷，从而达到保证软件质量的目的。

1.2 软件测试的心理学

人类行为具有高度目标性，确立一个正确的目标有着重要的心理学影响。软件测试的心理学问题就是如何摆正测试的两个目标的关系，使得测试活动更加富有成效。 

1.程序测试的过程具有破坏性 

每当测试一个程序时，人们总希望为程序增加一些价值。利用测试来增加程序的价值，是指通过测试，找出并修改尽可能多的程序缺陷，从而提高程序的可靠性或质量。 

因此，不要只是为了证明程序能够正确运行而去测试程序。相反，应该一开始就假设程序中隐藏着错误（这种假设几乎对所有的程序都成立），然后测试程序，发现尽可能多的错误。 

事实上，如果把测试目标定位于要证明程序中没有缺陷，那么就会在潜意识中倾向于实现这个目标。也就是说，测试人员会倾向于挑选那些使程序失效的可能性较小的测试数据。另一方面，如果把测试目标定位于要证明程序中存在缺陷，那么就会选择一些容易发现程序缺陷的测试数据。而后一种态度会比前者给程序增加更多的价值。 

因此，大多数测试专业人员都赞同Myers对测试的定义：“测试是为发现错误而执行程序的错误。”这个定义意味着程序测试的过程是具有破坏性的，甚至是一个“施虐”过程。开发人员可能不愿意这么做，因为人们总是倾向于建设而不是破坏。这个定义还暗示了对于一个特定的程序，应该如何设计测试用例（测试数据）、哪些人应该而哪些人又不应该执行测试。 

事实上，如果在测试某个程序段时发现了可以纠正的缺陷，或者测试最终确定在没有其他缺陷，则应将这次合理设计并得到有效执行的测试称作是“成功的”。而所谓“不成功的”测试，仅指未能适当地对程序进行检查，未能找出程序中潜藏缺陷的测试。因为软件中不可能没有缺陷，没有找出它们，当然测试是“不成功的”。 

“软件测试就是证明软件不存在错误的过程”。对几乎所有的程序而言，甚至是非常小的程序，这个目标实际上是无法达到的。因为即使程序完全实现预期要求，仍可能包含有缺陷。也就是说，如果程序不按要求工作，它显然有缺陷，但如果程序做了不要它做的事，它也有缺陷。 

心理学研究告诉我们，当人们在干一件已经知道是不合适的或不可能做到的事时，往往他们的表现就相当糟糕。把程序测试定义为在程序中找出错误的过程，就使测试成了可以做到的任务，从而克服了心理上存在的问题。虽然这看起来像是个微妙的文字游戏，但对成功地进行软件测试有很大的影响。 

总之，软件测试更适宜被视为试图发现程序中错误（假设其存在）的破坏性的过程。一个成功的测试，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。当然最终人们还是要通过软件测试来建立某种程度的信心：软件做了其应该做的，而没有做其不应该做的。 

2.程序员应避免测试自己的程序 

由开发人员来测试自己的代码是一件很不妥当的事情。开发和测试生来就是不同的活动。开发是创造或者建立某种事物的行为，如一个功能模块或整个系统。而测试的重要目的是证实一个模块或者一个系统工作不正常。这两个活动之间有着本质的矛盾。一个人不太可能把两个截然对立的角色都扮演地很好，因此应当开发人员在测试中的参与，给他们比较合适的任务是进行最底层的测试——单元测试。 

当一个程序员完成了设计与编写程序的建设性工作后，要一夜之间突然改变他的观点，设法对程序形成一个完全否定的态度，那是非常困难的。所以，大部分程序员都由于不能使自己进入必要的精神状态（不是抱着要揭露出自己程序中错误的态度），就不能有效的测试自己的程序。除了这个心理学问题之外，还有一个重要的问题：程序中可能包含由于程序员对问题的叙述或说明的误解而产生了错误。如果是这种情况，当程序员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。 

3.程序设计组织不应测试自己的程序 

在宏观意义上，一个程序设计组织或一个工程项目是个有生命的有机体，它同样有心理学问题。在大多数情况下，人们都以“在给定日期内，以一定代价完成程序编制任务的能力”来衡量程序设计组织和项目管理人员的。这样做的理由是时间和成本指标便于衡量，而程序的质量很难度量。要程序设计组织在测试自己的程序时持客观态度是很困难的，因为如果用正确的定义看待测试，就不大可能按预定计划完成测试，也不大可能把耗费的代价在要求的范围以内。 

软件生产的三个最重要的因素是：质量、进度和费用。由于费用和进度的，要开发一种高质量、快速交付和低成本的软件产品并不容易。也就是说要同时达到三个目标是困难的。因此在软件产品的开发中要权衡它们之间的关系，是软件的特性能满足用户的要求，这意味着软件产品的特性的度量和预计是必要的。 

软件测试由测试机构承担有很多好处。测试是指软件测试工作由在经济上和管理上于开发机构的组织进行。测试可以避免软件开发者测试自己开发的软件，由于心理学上的问题，软件开发者难以客观、有效的测试自己的软件，要找出那些因为对问题的误解而产生的错误就更加困难。测试还可以避免软件开发机构测试自己的软件，软件产品的开发过程受到时间、成本和质量三者的制约，在软件开发的过程中，当时间、成本和质量三者发生矛盾时，质量最容易被忽视，如果测试组织与开发组织来自相同的机构，测试过程就会面临来自于开发组织同一来源的管理方面的压力，使测试过程受到干扰。 

采用测试方式，无论在技术上还是管理上，对提高软件测试的有效性都具有重要意义。 

客观性——对软件测试和软件中的错误抱着客观的态度，这种客观的态度可以解决测试中的心理学问题，既能以揭露软件中错误的态度工作，也能不受发现的错误的影响。经济上的性使测试有更充分的条件按测试要求去完成。 

专业性——测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业知识。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。专业化分工是提高测试水平、保证测试质量、充分发挥测试效应的必然途径。 

权威性——由于专业优势，测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，专业化的测试机构的评价，更客观、公正和具有权威性。 

资源有保证——测试机构的主要任务是进行测试工作，这使得测试工作在经费、人力和计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性可以避免开发单位侧重软件开发而对测试工作产生不利的影响。

1.3 软件测试的内容

软件测试主要工作内容是验证(verification)和确认(validation )，下面分别给出其概念： 

验证(verification)是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。(Do the right thing) 

1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程； 

2.程序正确性的形式证明，即采用形式理论证明程序符合设计规约规定的过程； 

3.评市、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。 

确认(validation)是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do it right) 

1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性； 

2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问题。 

软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期间各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。

1.4 软件测试的分类

从是否关心软件内部结构和具体实现的角度划分 

A.白盒测试 

B.黑盒测试 

C.灰盒测试 

从是否执行程序的角度

A.静态测试 

B.动态测试。 

从软件开发的过程按阶段划分有

A.单元测试 

B.集成测试 

C.确认测试 

D.系统测试 

E.验收测试 

* 测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。 

* 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。 

* 集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。 

* 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。 

* 系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。 

单元测试 (Unit Testing) 

* 单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。 

* 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地进行单元测试。 

1. 单元测试的内容 

* 在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。 

(1) 模块接口测试 

* 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括： 

– 调用本模块的输入参数是否正确； 

– 本模块调用子模块时输入给子模块的参数是否正确； 

– 全局量的定义在各模块中是否一致； 

* 在做内外存交换时要考虑： 

– 文件属性是否正确； 

– OPEN与CLOSE语句是否正确； 

– 缓冲区容量与记录长度是否匹配； 

– 在进行读写操作之前是否打开了文件； 

– 在结束文件处理时是否关闭了文件； 

– 正文书写／输入错误， 

– I／O错误是否检查并做了处理。 

(2) 局部数据结构测试 

* 不正确或不一致的数据类型说明 

* 使用尚未赋值或尚未初始化的变量 

* 错误的初始值或错误的缺省值 

* 变量名拼写错或书写错 

* 不一致的数据类型 

* 全局数据对模块的影响 

(3) 路径测试 

* 选择适当的测试用例，对模块中重要的执行路径进行测试。 

* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。 

* 对基本执行路径和循环进行测试可以发现大量的路径错误。 

(4) 错误处理测试 

* 出错的描述是否难以理解 

* 出错的描述是否能够对错误定位 

* 显示的错误与实际的错误是否相符 

* 对错误条件的处理正确与否 

* 在对错误进行处理之前，错误条件是否已经引起系统的干预等 

(5) 边界测试 

* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。 

* 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。 

2. 单元测试的步骤 

* 模块并不是一个的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。 

– 驱动模块 (driver) 

– 桩模块 (stub) ── 存根模块 

* 如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。 

* 对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。 

集成测试（Integrated Testing） 

* 集成测试 (集成测试、联合测试） 

* 通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是： 

– 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失； 

– 一个模块的功能是否会对另一个模块的功能产生不利的影响； 

– 各个子功能组合起来，能否达到预期要求的父功能； 

– 全局数据结构是否有问题； 

– 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。 

在单元测试的同时可进行集成测试， 

发现并排除在模块连接中可能出现 

的问题，最终构成要求的软件系统。 

* 子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。 

* 通常，把模块集成成为系统的方式有两种 

– 一次性集成方式 

– 增殖式集成方式 

1. 一次性集成方式(big bang) 

* 它是一种非增殖式组装方式。也叫做整体拼装。 

* 使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。 

2. 增殖式集成方式 

* 这种集成方式又称渐增式集成 

* 首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统 

* 在集成的过程中边连接边测试，以发现连接过程中产生的问题 

* 通过增殖逐步组装成为要求的软件系统。 

(1) 自顶向下的增殖方式 

* 这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。 

* 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。 

* 选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。 

(2) 自底向上的增殖方式 

* 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。 

* 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。 

* 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。 

* 一般来讲，一种方式的优点是另一种方式的缺点。 

(3) 混合增殖式测试 

* 衍变的自顶向下的增殖测试 

– 首先对输入／输出模块和引入新算法模块进行测试; 

– 再自底向上组装成为功能相当完整且相对的子系统; 

– 然后由主模块开始自顶向下进行增殖测试。 

* 自底向上-自顶向下的增殖测试 

– 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试; 

– 然后对含写操作的子系统做自顶向下的组装与测试。 

* 回归测试 

– 这种方式采取自顶向下的方式测试被修改的模块及其子模块; 

– 然后将这一部分视为子系统，再自底向上测试。 

关键模块问题 

* 在组装测试时，应当确定关键模块，对这些关键模块及早进行测试。 

* 关键模块的特征： 

① 满足某些软件需求； 

② 在程序的模块结构中位于较高的层次（高层控制模块）； 

③ 较复杂、较易发生错误； 

④ 有明确定义的性能要求。 

确认测试（Validation Testing） 

* 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。 

* 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。 

1. 进行有效性测试（黑盒测试） 

* 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。 

* 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。 

* 通过实施预定的测试计划和测试步骤，确定 

– 软件的特性是否与需求相符； 

– 所有的文档都是正确且便于使用； 

– 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试 

* 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类： 

– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。 

– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。 

2. 软件配置复查 

n 软件配置复查的目的是保证 

u 软件配置的所有成分都齐全； 

u 各方面的质量都符合要求； 

u 具有维护阶段所必需的细节； 

u 而且已经编排好分类的目录。 

n 应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。 

验收测试（Acceptance Testing） 

* 在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。 

* 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。 

* 由用户参加设计测试用例，使用生产中的实际数据进行测试。 

* 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。 

* 确认测试应交付的文档有： 

– 确认测试分析报告 

– 最终的用户手册和操作手册 

– 项目开发总结报告。 

系统测试（System Testing） 

* 系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。 

* 系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。

1.5 软件测试模型

软件测试若使用经典的V模型阶段可以分为

单元测试 

集成测试 

系统测试 

V模型是最具有代表意义的测试模型 。

V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系 。 

从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。 

左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。 

用户需求 验收测试 

需求分析和系统设计 确认测试和系统测试 

概要设计 集成测试 

详细设计 单元测试 

编码 

V模型问题： 

1.测试是开发之后的一个阶段。 

2.测试的对象就是程序本身。 

3.实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。 

4.整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度 

W模型

W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

H模型

H模型中, 软件测试过程活动完全,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。

这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程,例如设计流程或者编码流程。也就是说, 只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以进行了。 

H模型揭示了一个原理:软件测试是一个的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备, 尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展。 

X模型

X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

1.6 软件测试职业发展前景

随着我国软件业的发展，专业的软件测试人员成为了众多知名公司追逐的对象，软件测试有着广阔的发展前景，具体可以分为： 

• 初级测试工程师：初级职位，开发测试脚本，执行测试 

•测试工程师 / 程序分析员：编写自动测试脚本程序 

•高级测试工程师 / 程序分析员：确定测试过程并指导初级测试工程师 

•测试组负责人：监管 1-3 人工作，负责规模 / 成本估算 

•测试 / 编程负责人：监管 4-8 人，安排和领导任务完成，提出技术方法 

•测试 / 质量保证 / 项目经理：负责 8 名以上人员的一个或多个项目，负责全生存期 

•业务 / 产品经理：负责多个项目的人员管理，负责项目方向和业务盈亏

1.7 软件测试的误区

市场对软件质量重要性的认识逐渐增强。所以，软件测试在软件项目实施过程中的重要性日益突出。但是，现实情况是，与软件编程比较，软件测试的地位和作用，还没有真正受到重视，对于很多人（甚至是软件项目组的技术人员）还存在对软件测试的认识误区，这进一步影响了软件测试活动开展和真正提高软件测试质量。 

（1）误区之一：软件开发完成后进行软件测试 

人们一般认为，软件项目要经过以下几个阶段：需求分析，概要设计，详细设计，软件编码，软件测试，软件发布。据此，认为软件测试只是软件编码后的一个过程。这是不了解软件测试周期的错误认识。软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。因此，软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。软件开发与软件测试应该是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。如果等到软件编码结束后才进行测试，那么，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。更严重的是如果此时发现了软件需求阶段或概要设计阶段的错误，如果要修复该类错误，将会耗费大量的时间和人力。 

（2）误区之二：软件发布后如果发现质量问题，那是软件测试人员的错 

这种认识很打击软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因为从根本上讲，软件测试不可能发现全部的错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。出现软件错误，不能简单地归结为某一个人的责任，有些错误的产生可能不是技术原因，可能来自于混乱的项目管理。应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。 

（3）误区之三：软件测试要求不高，随便找个人多都行 

很多人都认为软件测试就是安装和运行程序，点点鼠标，按按键盘的工作。这是由于不了解软件测试的具体技术和方法造成的。随之软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具，新流程，新测试设计方法都在不断更新，需要掌握和学习很多测试知识。所以，具有编程经验的程序员不一定是一名优秀的测试工程师。软件测试包括测试技术和管理两个方面，完全掌握这两个方面的内容，需要很多测试实践经验和不断学习精神。 

（4）误区之四：软件测试是测试人员的事情，与程序员无关开发和测试是相辅相成的过程 

需要软件测试人员、程序员和系统分析师等保持密切的联系，需要更多的交流和协调，以便提高测试效率。另外，对于单元测试主要应该由程序员完成，必要时测试人员可以帮助设计测试样例。对于测试中发现的软件错误，很多需要程序员通过修改编码才能修复。程序员可以通过有目的的分析软件错误的类型、数量，找出产生错误的位置和原因，以便在今后的编程中避免同样的错误，积累编程经验，提高编程能力。 

（5）误区之五：项目进度吃紧时少做些测试，时间富裕时多做测试 

这是不重视软件测试的表现，也是软件项目过程管理混乱的表现，必然会降低软件测试的质量。一个软件项目的顺利实现需要有合理的项目进度计划，其中包括合理的测试计划，对项目实施过程中的任何问题，都要有风险分析和相应的对策，不要因为开发进度的延期而简单的缩短测试时间、人力和资源。因为缩短测试时间带来的测试不完整，对项目质量的下降引起的潜在风险，往往造成更大的浪费。克服这种现象的最好办法是加强软件过程的计划和控制，包括软件测试计划、测试设计、测试执行、测试度量和测试控制。

（6）误区之六：软件测试是没有前途的工作，只有程序员才是软件高手 

由于我国软件整体开发能力比较低，软件过程很不规范，很多软件项目的开发都还停留在“作坊式”和“垒鸡窝”阶段。项目的成功往往靠个别全能程序员决定，他们负责总体设计和程序详细设计，认为软件开发就是编写代码，给人的印象往往是程序员是真正的牛人，具有很高的地位和待遇。因此，在这种环境下，软件测试很不受重视，软件测试人员的地位和待遇自然就很低了，甚至软件测试变得可有可无。随着市场对软件质量的不断提高，软件测试将变得越来越重要，相应的软件测试人员的地位和待遇将会逐渐提高。在微软等软件过程比较规范的大公司，软件测试人员的数量和待遇与程序员没有多大差别，优秀测试人员的待遇甚至比程序员还要高。软件测试将会成为一个具有很大发展前景的行业，软件测试大有前途，市场需要更多具有丰富测试技术和管理经验的测试人员，他们同样是软件专家。这两年来国内软件测试人员的需求不断增大,越来越多的IT企业认识到了软件测试的重要性,这种可喜的现状与发展趋势让笔者对我国软件业的发展重新抱有较大的希望。 

尽管这是一门崭新的学科,目前在国内的发展仍处于"婴儿"阶段,但看到越来越多的软件公司为软件测试招兵买马,看到越来越多的技术人员投入到软件测试中,我就情不自禁地感叹:机会来了!这机会不仅仅是某一个人的,而是所有人的,它对每个人都是公平的,学的领域需要新的理论新的工具新的方法,由于国内的软件测试还处在一个比较初级的阶段，没有人确切地知道它需要什么样的基础,也没有人确切地知道它应该怎样发展,因此这个领域需要大家来共同,以促进它的深入发展。

1.8 软件测试的前景

随着软件产业的发展，软件产品的质量控制与质量管理正逐渐成为软件企业生存与发展的核心。几乎每个大中型IT企业的软件产品在发布前都需要大量的质量控制、测试和文档工作，而这些工作必须依靠拥有娴熟技术的专业软件人才来完成。软件测试工程师就是这样的一个企业重头角色。业内人士分析，该类职位的需求主要集中在沿海发达城市，其中北京和上海的需求量分别占去33%和29%。民企需求量最大，占19%，外商独资欧美类企业需求排列第二，占15%。然而，目前的现状是：一方面企业对高质量的测试工程师需求量越来越大越大，另一方面国内原来对测试工程师的职业重视程度不够，使许多人不了解测试工程师具体是从事什么工作。这使得许多IT公司只能通过在实际工作中进行淘汰的方式对测试工程师进行筛选，因此国内在短期将出现测试工程师严重短缺的现象。根据对近期网络招聘IT人才情况的了解，许多正在招聘软件测试工程师的企业 

很少能够在招聘会上顺利招到合适的人才。在具体工作过程中，测试工程师的工作是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试用例，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。对软件测试工程师而言，必须具有高度的工作责任心和自信心。任何严格的测试必须是一种实事求是的测试，因为它关系到一个产品的质量问题，而测试工程师则是产品出货前的把关人，所以，没有专业的技术水准是无法胜任这项工作的。同时，由于测试工作一般由多个测试工程师共同完成，并且测试部门一般要与其他部门的人员进行较多的沟通，所以要求测试工程师不但要有较强的技术能力而且要有较强的沟通能力。

第二章 软件测试工作的经验和心得

2.1 软件测试用例的规范

 一个好的测试用例，是测试人员能够迅速、准确找出程序中潜在问题的良好开端。

此所谓：工欲善其事，必先利其器。只有一个好的测试用例，才能使测试人员在测试过程中少走歪路，在最短的时限内，找出程序中潜在的Bug；只有一个好的测试用例，才能使测试人员更准确、更有效地找出Bug。

 下面是我在对邮件服务系统进行测试时，缩写的测试用例表（包含测试的场景/条件、测试的方法/操作、预期结果、实际结果和备注说明）

测试用例示例

正如前面所说的，好的测试用例左右了测试的过程。那是否一个好的测试用例能适合所有的测试对象呢？

答案是否定的，就从我对软件测试接触和实践，个人认为：“没有最好的测试用例，只有最合适的测试用例”；就好比我们无法用“漏勺”去取“水”一样，一个程序的测试用例，我们往往无法运用到另一个程序上，即便两个程序十分相似，也不能保证一个测试用例能够覆盖两个程序中的所有场景。遗漏场景就意味着测试工作尚未完成———用错了工具，“水”永远也取不上来。下面就给出了，一个与上面用例完全不同的测试用例。

 这个测试用例，是我在测试WebService方法时所用的用例之一，使用了自动化测试的方法（关于自动化测试，详见下一节）。

 这个WebService方法有一个参数，名叫“rightNumber”，此处，我为这个方法写了3组用例，case001和case003分别是两组参数正确的用例条件，而case002则使用了一组无效数据。（一般用例都要考虑空数据，但此处因为是调用WebService方法，方法参数填写为空不具备任何意思，故不作考虑）

根据以上测试用例，我调用了自己编写的名为WebServiceTest的测试小工具，先进行测试用例的加载，分析测试用例格式的合法性。格式合法，则可进行测试（测试过程自动）。

结果如下图：

图2.1.1

图2.1.2

结果分析：

图2.1.1为WebService方法GetRightByNumber正确数据的结果图，图中标签下的为该方法返回结果类型，标签下的标签为返回值的各项数据。

图2.1.2为WebService方法GetRightByNumber无效数据的结果图，图中的标签说明该项测试条件有误，并显示详细的错误信息：

下图为Bug表单的示例

图2.1.3

通常来说测试用例完成后，测试人员根据已有的测试用例对目标项目进行包含以下步骤的测试：

1．新的缺陷被测试人员提交；

2．项目经理确定该缺陷的优先级、分配开发人员来修复；

3．开发人员根据缺陷的优先级去修复缺陷，使该缺陷被修复；

4．开发人员发布一个新的内部版本；

5．测试人员确认这个新版本中的被修复 缺陷；

6．被修复的缺陷被关闭；没有被修复缺陷被再次打开，返回1。

2.2 自动化测试

概念：利用软件测试工具自动实现全部或部分测试，自动测试是软件测试的一个重要组成部分，它能完成许多手工测试无法实现或难以实现的测试。正确、合理的实施自动测试，能够快速、全面的对软件进行测试，从而提高软件质量，节省经费，缩短软件发布周期

自动化测试的优点：

（1）改进所有的测试领域

a)测试用例设计改进

b)性能测试改进

c)压力测试改进

d)质量度量与测试优化

（2）改进测试工作质量

a)BVT测试改进

b)回归测试改进

c)多平台兼容性测试改进

d)软件配置测试改进

e)普通测试执行改进

f)集中于高级测试问题改进

g)执行手工测试无法完成的测试

h)定时启动测试

（3）减轻测试工作量并加快测试进度

答案也是否定的。因为有点时候，我们没有办法实现自动化或不合适使用自动化测试。

以下是自动化测试的适用范围

（1）执行回归测试

（2）执行手工很难达到或手工无法完成的测试

（3）枯燥乏味的重复性工作

（4）一致的，可重复的测试

自动测试常见的错误

（1）实施一项测试设计时，不遵循任何设计标准，结果产生了不可重复的测试脚本，因而不可重用

（2）试图将测试需求100%自动化

（3）使用错误的工具

（4）在应用程序开发周期中启用测试工具太晚

（5）测试工程师参与应用开发生存周期太晚，导致不能很好的了解应用和系统设计，因而无法完成测试

在上一节中，我在测试WebService方法时就使用了自动化测试，下面进行详细的说明测试中，我使用了多个测试用例同时加载，并挨个进行测试的方法，对所有的WebService方法进行了测试。

虽然网上也提供了现成的WebService方法测试工具。但这种工具只能一次测试一个WebService方法的一组数据，无法进行批量测试，效率不高。所以，我自己写了一个小工具，提供了批量测试的可能。这一点也符合自动化测试灵活、合理实施的理念。

下面是批量测试时测试用例文件。

图2.2.1

测试时，先将该文件夹下的所有用例文件进行加载，然后进行测试。

下面是测试结果安放文件夹

图2.2.2

根据分析以上测试结果，将问题及时反馈给开发人员。

2.3 测试中的问题

2.3.1 测试运用的是认识论

认识论是探讨人类认识的本质、结构，认识与客观实在的关系，认识的前提和基础，认识发生、发展的过程及其规律，认识的真理标准等问题的哲学学说。又称知识论。

根据认识论的运用我们可以给软件测试提出以下问题：

（1）怎么知道软件足够好？

（2）如果软件并不是足够好，怎样才能知道？

（3）怎么知道已经完成了足够的测试？

这些看似简单的问题，都是科学家，心理学家的通过研究认识论才总结出来的，对我们测试提供了重要的指导思想。

2.3.2 测试无法发现所有的程序问题

 测试人员的任务是找出并报告重要的程序问题，但是不会发现所有的程序问题。为了发现全部程序错误，测试人员必须检查所有可能有问题的地方，而事实上是不可能做到的。如果测试人员认为自动能够做到，要么产品太简单，要么是测试人员的想象力太差。因此，测试人员只能发现软件存在问题，却无法确定软件不存在问题。

参考资料

【1】百度知道

【2】测试用例设计

【3】《软件测试经验与教训》，作者：Cem Kaner、James Bach、Bret Pettichord

【4】《硅谷的测试在中国》

【5】《软件开发的科学和艺术》节选，撰文/陈宏刚

【6】其他网络资料

论文信息

论文作者：姚斌

撰写时间：2010-11-29

撰写目的：对软件测试的心得和经验的总结