软件测试（software testing）

软件测试（英语：software testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

软件测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。

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

Glenford J.Myers曾对软件测试的目的提出过以下观点：

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

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

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

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

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

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

(7)另外，根据测试目的的不同，还有回归测试、压力测试、性能测试等，分别为了检验修改或优化过程是否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等。

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

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

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

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

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

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

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

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

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

软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。编码和单元测试属于软件生存期中的同一个阶段。在结束这个阶段后对软件系统还要进行各种综合测试，这是软件生存期的另一个独立阶段，即测试阶段。

测试目的

软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。

第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。

第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。

软件质量是由几个方面来衡量的：一、在正确的时间用正确的的方法把一个工作做正确（Doing the right things right at the right time.）。二、符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。三、质量本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高质量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.）。四、质量也代表着它符合客户的需要（Quality also means “meet customer needs”.）。作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。只有这些问题都解决了，软件产品的质量才可以说是上去了。

测试原则

一，测试应该尽早进行，最好在需求阶段就开始介入，因为最严重的错误不外乎是系统不能满足用户的需求。

二，程序员应该避免检查自己的程序，软件测试应该由第三方来负责。

三，设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，如网络异常中断、电源断电等。

四，应该充分注意测试中的群集现象。

五，对错误结果要进行一个确认过程。一般由A测试出来的错误，一定要由B来确认。严重的错误可以召开评审会议进行讨论和分析，对测试结果要进行严格地确认，是否真的存在这个问题以及严重程度等。

六，制定严格的测试计划。一定要制定测试计划，并且要有指导性。测试时间安排尽量宽松，不要希望在极短的时间内完成也有一个高水平的测试。

七，妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。

测试人员的任务

1、寻找Bug；

2、避免软件开发过程中的缺陷；

3、衡量软件的品质；

4、关注用户的需求。

总的目标是：确保软件的质量。

测试目标

1．发现一些可以通过测试避免的开发风险。

2．实施测试来降低所发现的风险。

3．确定测试何时可以结束。

4．在开发项目的过程中将测试看作是一个标准项目。

心理依据

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

专业性——独立测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业知识。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。专业化分工是提高测试水平、保证测试质量、充分发挥测试效应的必然途径。
权威性——由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，专业化的独立测试机构的评价，更客观、公正和具有权威性。

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

Test Platform软件测试平台，简称TP，是业界唯一的对软件测试全过程进行支撑的软件测试工具。

业界已有的软件测试工具基本上都局限在测试执行阶段，只能支撑测试执行阶段的活动，而测试分析、测试设计、测试实现这三个前期阶段的活动缺乏有效的测试工具支撑，直接影响了软件测试的完整性和充分性，从而影响最终研发的软件质量。David.yuan这样说：企业使用了博为峰TP测试平台，整个软件测试过程的 测试覆盖率提高到前所未有的高度和广度，可以极好的达成软件在安全性、健壮性、稳定性和功能、性能方面的要求，即使是没有很多年测试经验的管理和测试人员，通过TP测试平台就可以完成智能化地管理、设计、分析、执行整个测试过程，达到一流测试管理专家所做到的效果。 　　

1、TestPlatForm 简称TP，在业界首先将各种有效的缺陷分析模型引入到该软件平台中，包括ODC分析、Gompertz分析、Rayleigh分析、四象限分析、缺陷注入分析、DRE/DRM等工程方法，帮助管理者建立软件研发过程的质量基线、测试能力基线，并帮助管理者将项目实际缺陷、能力数据和基线数据进行对比分析，发现软件过程中的改进点，判断测试是否可以退出、软件是否可以发布，并对软件中残留缺陷数进行预测； 　　

2、TestPlatform 简称TP，建立了测试分析和设计的理论框架和一整套工程方法，能够很好的支撑测试的辅助分析和设计； 　　

3、TestPlatform 简称TP，建立“开发需求项－>测试项－>测试子项－>测试用例－>缺陷”的测试跟踪关系，能够及时的反应开发需求和设计的变更对测试的影响范围，保证软件的一致性和测试的充分性，从而保证软件的质量； 　　

4、TestPlatform 简称TP，能够全面的管理软件质量工作，具有高度的集成性，一款TestPlatform能够完成多款其他各类的相关质量管理工具集成在一起才能完成的软件质量管理工作。它集成了需求跟踪、静态测试、动态测试、测试人员管理、测试环境管理、测试计划管理、测试用例管理、缺陷管理、缺陷分析等软件质量相关的流程。 　　

AutoRunner是国内第一款自动化测试工具，可以用来完成功能测试、回归测试、每日构建测试与自动回归测试等工作。是具有脚本语言的、提供针对脚本完善的跟踪和调试功能的、支持IE测试和Windows native测试的自动化测试工具。 　　

TestCenter是一款功能强大测试管理工具，它可以帮助您：实现测试用例的过程管理，对测试需求过程、测试用例设计过程、业务组件设计实现过程等整个测试过程进行管理。实现测试用例的标准化即每个测试人员都能够理解并使用标准化后的测试用例，降低了测试用例对个人的依赖；提供测试用例复用，用例和脚本能够被复用，以保护测试人员的资产；提供可伸缩的测试执行框架，提供自动测试支持；提供测试数据管理，帮助用户同意管理测试数据，降低测试数据和测试脚本之间的耦合度。 　　

TAR(Terminal AutoRunner)适用于VT100、VT220等标准的应用系统，支持命令行模式和窗口模式（使用Cursors编写的应用程序），支持自动录制脚本、所见即所得的资源和脚本编辑，稳定的自动同步功能。是目前国内最好的银行业务测试工具. 　　

LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ， 企业能最大限度地缩短测试时间， 优化性能和加速应用系统的发布周期。目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢， 系统崩溃等问题。这些都不可避免地导致公司收益的损失。 　

TestDirector是全球最大的软件测试工具提供商Mercury Interactive公司生产的企业级测试管理工具，也是业界第一个基于Web的测试管理系统，它可以在您公司内部外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。

Alpha测试

Alpha测试通常是阶段性的开发完成后所开始进行，一直持续到进入Beta测试阶段前的阶段。Alpha测试是一种验证测试，在模拟的环境中以模拟的数据来运行。

在这个阶段中，通常是在开发单位由开发人员与测试的测试人员，以模拟或实际操作性的方式进行验证测试。

Beta测试

在系统测试中通常先进行Alpha测试以验证信息系统符合用户以及设计需求所期望的功能。当Alpha阶段完成后，开发过程进入到Beta阶段，由公众参与的测试的阶段。Beta测试可称为确认测试，在一个真实的环境中以实际的数据来运行测试，以确认性能，系统运行有效率，系统撤消与备份作业正常，通过测试让信息系统日后可以更趋完善。

封测与公测

封闭测试（Closed Beta，常简作封测或CB）是软件或服务等产品在开发完成后、将公开上市前的测试过程。相对于公开测试，封闭测试的主要用途是测试软件的功能和检查程序错误等等，因此通常只提供给少数人进行测试。有些公司会要求参与测试者签署保密协议，以避免测试的产品提前外流。MMORPG的封测退出之后，游戏公司常会将角色数据删除，但也有少数不删的。

公开测试（Open Beta，常简作公测或OB），一般常指软件或服务等产品在正式上市前开放给不特定人试用，虽然原意是希望试用者能够提报bug，但并不是把试用者当做真正的验证人员。由于通常为免费性质，故常常能够吸引到大批的试用者参与，可视为另一种营销策略。另一方面也节省下测试人员的成本，和验证稳定度（对于多人使用的带宽及机器是否能负载，又称压力测试）的时间。

Gamma测试

Gamma测试是一个很少被提及的非正式测试阶段，该测试阶段对应的是对“存在缺陷”产品的测试。考虑到任何产品都可以被称为“存在缺陷”的产品（测试只能发现产品中存在的问题，不能说明产品不存在问题），因此这个概念存在一定的不确定性。 对Alpha和Beta测试常见的一个误解是“Beta测试＝黑盒测试”。实际上，Alpha和Beta测试对应在软件产品发布之前的Alpha和Beta阶段，而白盒、黑盒和灰盒测试技术是从技术和方法层面对测试的描述，不应该将这两部分概念混淆。

等价类

1.定义

是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试用例设计方法。

2.划分等价类

等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

1)有效等价类

是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

2)无效等价类

与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

3.划分等价类的标准

1)完备测试、避免冗余；

2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合；

3)并是整个集合：完备性；

4)子集互不相交：保证一种形式的无冗余性；

5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。

4.划分等价类的方法

1)在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

如：输入值是学生成绩，范围是0～100。

2)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下，可确立一个有效等价类和一个无效等价类。

边界值

1. 定义

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

2. 与等价划分的区别

1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

3. 边界值分析方法的考虑：

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

4. 常见的边界值

1) 对16-bit 的整数而言 32767 和 -32768 是边界

2) 屏幕上光标在最左上、最右下位置

3) 报表的第一行和最后一行

4) 数组元素的第一个和最后一个

5) 循环的第 0 次、第 1 次和倒数第 2 次、最后一次

5. 边界值分析

1) 边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

例：测试计算平方根的函数

--输入：实数

--输出：实数

--规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息"平方根非法-输入值小于0"并返回0；库函数Print-Line可以用来输出错误信息。

分类角度细分

1、从是否关心软件内部结构和具体实现的角度划分（按测试分类）

A.白盒测试

B.黑盒测试

C.灰盒测试

2、从是否执行程序的角度

A.静态测试

B.动态测试。

阶段细分

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

A.单元测试

B.集成测试

C.确认测试

D.系统测试

E.验收测试

F.回归测试

G.Alpha测试

H.Beta测试

软件测试的方法：

1、软件测试的基本方法

2、单元测试的基本方法

3、综合测试的基本方法

4、确认测试的基本方法

5、系统测试的基本方法

软件测试的基本方法

软件测试的方法和技术是多种多样的。

对于软件测试技术，可以从不同的角度加以分类：

从是否需要执行被测软件的角度，可分为静态测试和动态测试。

从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试；

1、黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

2、白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。

3．ALAC(Act-like-a-customer)测试

ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对那些客户最容易遇到的错误。

单元测试的基本方法

单元测试的对象是软件设计的最小单位模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。

单元测试任务

单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。

模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。

测试接口正确与否应该考虑下列因素：

1 输入的实际参数与形式参数的个数是否相同；

2 输入的实际参数与形式参数的属性是否匹配；

3 输入的实际参数与形式参数的量纲是否一致；

4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；

5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；

6 调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；

7 调用预定义函数时所用参数的个数、属性和次序是否正确；

8 是否存在与当前入口点无关的参数引用；

9 是否修改了只读型参数；

10 对全程变量的定义各模块是否一致；

11是否把某些约束作为参数传递。

如果模块内包括外部输入输出，还应该考虑下列因素：

1 文件属性是否正确；

2 OPEN/Close语句是否正确；

3 格式说明与输入输出语句是否匹配；

4 缓冲区大小与记录长度是否匹配；

5文件使用前是否已经打开；

6是否处理了文件尾；

7是否处理了输入/输出错误；

8输出信息中是否有文字性错误；

检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。

局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

1 不合适或不相容的类型说明；

2变量无初值；

3变量初始化或省缺值有错；

4不正确的变量名（拼错或不正确地截断）；

5出现上溢、下溢和地址异常。

除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。

在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。??的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。

计算中常见的错误包括：

1 误解或用错了算符优先级；

2 混合类型运算；

3 变量初值错；

4 精度不够；

5 表达式符号错。

比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：

1不同数据类型的对象之间进行比较；

2错误地使用逻辑运算符或优先级；

3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；

4比较运算或变量出错；

5循环终止条件或不可能出现；

6迭代发散时不能退出；

7错误地修改了循环变量。

一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，应着重检查下列问题：

1输出的出错信息难以理解；

2记录的错误与实际遇到的错误不相符；

3在程序自定义的出错处理段运行之前，系统已介入；

4异常处理不当；

5错误陈述中未能提供足够的定位出错信息。

边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。

单元测试过程

一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。

应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。

驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。

提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。

综合测试的基本方法

时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。

某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。

1 自顶向下集成

自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把M2、M3和M4与主控模块集成在一起，再将M5和M6 和其他模块集资集成起来。

自顶向下综合测试的具体步骤为：

1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；

2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；

3 每集成一个模块立即测试一遍；

4 只有每组测试完成后，才着手替换下一个桩模块；

5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。

从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。下图中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。

自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。

2自底向上集成

自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。

自底向上综合测试的步骤分为：

1 把低层模块组织成实现某个子功能的模块群（cluster）;

2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；

3 对每个模块群进行测试；

4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。

从第一步开始循环执行上述各步骤，直至整个程序构造完毕。

下图说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可对MaD3被去掉后，M3与模块群3直接接口，可对Mb进行集成测试，最后Ma、Mb和 Mc全部集成在一起进行测试。

自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。

此外，在综合测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：①对应几条需求；②具有高层控制功能；③复杂、易出错；④有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。

确认测试的基本方法

通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

1. 确认测试标准

实现软件确认要通过一系列墨盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。

确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足??这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

2. 配置复审

确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。

3. α、β测试

事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。

α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

系统测试的基本方法

计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。

在系统测试之前，软件工程师应完成下列工作：

（1） 为测试软件系统的输入信息设计出错处理通路；

（2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；

（3） 参与系统测试的规划和设计，保证软件测试的合理性。

系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。

下面简单讨论几类系统测试。

１、恢复测试

恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

２、安全测试

安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

３、强度测试

强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。

４、 性能测试

对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

编写规范

1 目的：统一测试用例编写的规范，以保证使用最有效的测试用例，保证测试质量。

2 范围：适用于公司对产品的业务流程、功能测试测试用例的编写。

3 术语解释

3.1 测试分析：对重要业务、重要流程进行测试前的分析。

3.2 业务流程测试用例：关于产品业务、重要流程的测试用例。

4 业务流程测试用例编写原则

4.1 系统性

4.1.1 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；

4.1.2 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；

4.2 连贯性

4.2.1 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确；

4.2.2 对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；

5 测试用例设计的方法

5.1 等价类划分法

5.1.1 确定等价类的原则

5.1.1.1 如果输入条件决定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。

5.1.1.2 如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，此时可确立一个有效等价类和一个无效等价类；

5.1.1.3 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类；

5.1.1.4 如果规定了输入数据的一组值，而且程序对每个输入值分别进行处理，此时可为每一个输入值确立一个有效等价类，此外，针对这组值确立一个无效等价类，它是所有不允许输入值的集合；

5.1.1.5 如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同的角度违反规则）。

5.1.1.6 如果确知，已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。

5.1.2 测试用例的选择原则

5.1.2.1 为每一个等价类规定一个唯一的编号；

5.1.2.2 设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直至所有的有效等价类都被覆盖过；

5.1.2.3 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直至所有的无效等价类都被覆盖为止。

5.2 边界值分析法

5.2.1 测试用例的选择原则

5.2.1.1 如果输入了条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个边界范围的值作为测试输入数据；

5.2.1.2 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大多1、比最小小1的数作为测试输入数据；

5.2.1.3 根据规格说明的每个输出条件，使用前面的原则；

5.2.1.4 如果程序的规格说明给出的输入输出域是有序集合，则应选取集合的每一个元素和最后一个元素作为测试用列；

5.2.1.5 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例；

5.2.1.6 分析规格说明，找出其他可能的边界条件。

6 测试用例设计的原则

6.1 全面性

6.1.1 应尽可能覆盖程序的各种路径

6.1.2 应考虑存在跨年、跨月的数据

6.1.3 大量数据并发测试的准备

6.2 正确性

6.2.1 输入界面后的数据应与测试文档所记录的数据一致

6.2.2 预期结果应与测试数据发生的业务吻合

6.3 符合正常业务惯例

6.3.1 测试数据应符合用户实际工作业务流程

6.3.2 兼顾各种业务变化的可能

6.4 仿真性

人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；不允许出现与知名人士、小说中人物名等雷同情况。

6.5 可操作性

测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。

7 测试用例编写格式细则

7.1 测试用例内容

7.1.1 具体实施可以采用EXCEL和图形相结合，可用EXCEL编写测试用例的同时插入图形来加以说明。测试用例设计的内容可由：模块名、功能说明或图形说明、测试用例输入、应输出结果、实际输出结果、结论、BUG编号、BUG级别8部分组成。

7.1.2 在测试用例设计模版中有“业务流程测试用例设计模版”（包含整体业务流程）和“功能测试用例设计模版”两个模板可按需要选择。

7.2 测试用例表格格式

7.2.1 表格内容的字体为宋体；

7.2.2 表格内容的字型为12号；

8 测试用例优先级

测试用例优先级 描述

A 测试计划中重要的模块功能和业务流程

B 测试计划中比较重要的模块功能和业务流程

C 测试计划中次重要的模块功能和业务流程

D 测试计划中不重要的模块功能和业务流程

E 系统小单元、系统容错功能

对于A、B 级应重点考虑

9 BUG级别

V模型

1、测试阶段:

单元测试

集成测试

系统测试

2、实现意义

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

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

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

3、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）误区之一：软件开发完成后进行软件测试

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

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

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

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

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

（4）误区之四：软件测试是测试人员的事情，与程序员无关

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

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

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

前景

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

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