软件测试概论

软件测试概论

软件测试概论<!--

@page { size: 8.27in 11.69in; margin:

0.79in }

P { margin-bottom: 0.08in }

H2 { margin-bottom: 0.08in }

H2.western { font-family: "Times New Roman", serif }

H2.cjk { font-family: "AR PL SungtiL GB"; font-style: normal }

H2.ctl { font-family: "Tahoma" }

H4 { margin-bottom: 0.08in }

H4.western { font-family: "Times New Roman", serif }

H4.cjk { font-family: "AR PL SungtiL GB"; font-style: normal }

H4.ctl { font-family: "Tahoma" }

-->

什么软件生存周期

一个软件从开始计划起，到废弃不用止，称为软件生存周期。

一般来说，软件生存周包括计划、开发、运行三个时期，每一时期又可分为若干更小的阶段。计划时期的主要任务是

分析用户要求，分析新系统的主要目标以及开发该系统的可行性。开发时期要完成设计和实现两大任务具体。具体分为需求分析、概要设计、详细设计、编码、测试。其中编码

和测试是软件开发期的最后两个阶段。运行时期是软件生存周期的最后一个时期，软件人员在这一时期的工作，主要是做好软件维护。统计表明，开发较大规模的软件，

有40%以上的精力是耗费在测试上的，即使富有经验的程序员，也难免在编码中发生错误，何况，有写错误在设计甚至分析阶段早已埋下祸根，无论是早期潜伏下来的错误或编

码中新引入的错误，若不及时排除，轻者降低软件的可靠性，重者导致整个系统的失败。为防患于未然，强调软件测试

的重要性是必要的。

好的测试工程师

1、沟通能力一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人

员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不

可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须

能够同等地同用户和开发者沟通。2、技术能力

就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要

做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。3、自信心开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。4、外交能力当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定

的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于"赢了战争却输了战役"。

5、幽默感在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

6、很强的记忆力一个理想的测试

者应该有能力将以前曾经遇到过的类似的错误从记忆深处

挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

7、怀疑精神可以预料，开发者会尽他们最大的努力将

所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。8、自我督促干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。9、洞察力一个好的测试工程师具有"测试是为了破坏"的观点，捕获用户

观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

软件测试工程师成为IT就业新热点

日前，招聘网站——中华英才网发布了最新一期的ＩＴ职场人气排行榜。根据统计，ＩＴ人才仍是企业需求量最大的人群，其中软件测试工程师、高级程序员、产品项目经理高

级职位进入“三甲”，成为ＩＴ就业市场最新风向标。作为软件开发流程中的重要一环，软件测试岗位渐渐“浮出水面”，并凭借其庞大的人才需求和广

阔的职场发展前景日渐成为ＩＴ职场就业的大热门。

近年来，软件产品的质量控制与质量管理越来越受到重视，并逐渐成为企业生存与发展的核心。在许多ＩＴ企业中，软件测试并非只担当“挑错”的角色，其重要性不亚于软件的开发环节。越来越多的ＩＴ企业已逐渐意识到测试环节在软件产品研发中的重要性。此类软件质量控制工作均需要拥有娴熟技术的专业软件测试人才来协作完成，软件测试工程师作为一个重头角色正成为ＩＴ企业招聘的

热点。

随着测试重要性的日趋凸显，我国软件测试人才正处于一个“双高”地位，即地位高、待遇高，职场前景非常广阔，因而，近两年来，软件测试工程师也成为了ＩＴ就业最新的亮点。

由于我国企业对于软件测试自动化技术在整个软件行

业中的重要作用认识较晚，因此，这方面的专业技术人员在国内还是凤毛麟角，人才供需之间存在着巨大的缺口。有

关数据显示，我国目前软件从业人才缺口高达40万人。即

使按照软件开发工程师与测试工程师的岗位比例计算，我国对于软件测试工程师的需求便有数十万之众。业内专家预计，在未来5到10年中，我国社会对软件测试人才的需

求数字还将继续增大。

笔者了解到，日前在国展举办的一次招聘会上，多家企业纷纷打出各类高薪招聘软件测试人员的海报，出人意料的是收到的简历尚不足招聘岗位数的50％，而合格的竟不足30％。有行业专家表示，软件测试人才“供远小于求”的现实问题正影响着我国软件业的健康发展。

一方面，企业对软件测试人才有大量需求，但苦于招不到合适的人；而另一方面，很多应聘者却因为缺乏相关技能而被用人单位拒之门外，软件测试人才职场正面临着

“有人没活干，有活没人干”的尴尬局面。对此，

业内专家表示，软件测试行业已显现出实际需求与人力资源之间的尖锐矛盾。设立软件测试人才的职业培训体系应是

解决ＩＴ职场“结构性失业”的一条捷径。

专家表示，软件测试是一项需具备较强专业技术的工作。在具体工作过程中，测试工程师要利用测试工具按照测试方案和流程对产品进行性能测试，甚至根据需要编写不同的

测试工具、设计和维护测试系统，对测试方案可能出现的问题进行分析和评估，以确保软件产品的质量。一名合格的

软件测试工程师必须要经过严格的系统化职业教育培训，作为产品正式出厂前的把关人，没有专业的技术水准、没有高度的工作责任心和自信心是根本无法胜任的。

目前，国内少数具有远见的ＩＴ培训机构已经充分认识到了测试工程师的供需矛盾，开始针对软件测试行业人才需求启动系统化专项培训，为ＩＴ行业求职者提供了一个进

入软件测试行业的途径。据了解，这些课程科学、系统以提升就业竞争力为目标，根据软件测试岗位工作的实际要求

设计而成，以实际应用场景为核心，配以实际测试项目和测试工作流程，注重学习的系统性、教学的渐进性及学员的参与性，使学员能够用最少的时间掌握测试工作中最实用的

必备职业技能，具备测试岗位需求的工作经验和综合素质，从而具备较强的竞争力。

有关专家表示，随着各类软件测试培训课程体系的推出，

我国软件企业人才结构将日趋合理，软件测试业的人才供需矛盾也将得到逐步缓解，这无疑有利于我国软件行业整体品质的进一步提升。

软件本地化测试

本地化的主要工作就是翻译产品的用户界面（UI ），有时也更改某些初始设置以使产品适合于另一个地区。本地化测试检查针对特定目标区域的产品本地化质量。此测试基于国际化测试的结果，后者验证对特定区域性或区域设置的功能性支持。本地化测试只能在产品的本地化版本上进行。

本地化测试过程中的测试工作集中在：

受本地化影响的方面，如UI 和内容

特定的区域设置、特定的语言和地区方面的内容

另外，本地化测试还应包括：

基本功能测试

在本地化环境中运行的安装和升级测试

根据产品的目标地区计划应用程序和硬件兼容性测试。

用户界面和语言的本地化测试应包括的项有：

验证所有应用程序资源

验证语言的准确性和资源属性

版式错误

书面文档、联机帮助、消息、界面资源、命令键顺序等的一致性检查。

确认是否遵守系统、输入和显示环境标准

用户界面可用性

评估文化适合性

检查政治上敏感的内容

当交付本地化产品时，确保包含本地化文档（手册、联机帮助、上下文帮助等）。要检查的项包括：

翻译的语言质量

翻译的完整性

所有文档和应用程序UI 中使用的术语一致

软件测试理论

1.什么是软件测试

无论怎样强调软件测试的重要性和它对软件可靠性的影响

都不过分。在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完

美无缺，因此，在软件生命周期的每个阶段都不可避免地会

产生差错。我们力求在每个阶段结束之前通过严格的技术

审查，尽可能早地发现并纠正差错；但是，经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。如果在软件投入生产性运行之前，没有发现并

纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运

行之前，尽可能多地发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。

大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤

总成本的三倍到五倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。仅就测试而

言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终日的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。

2.软件测试的目标

下面这些规则也可以看作是测试的目标或定义：

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

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

测试方案；

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

从上述规则可以看出，测试的正确定义是“为了发现

程序中的错误而执行程序的过程”。这和某些人通常

想象的“测试是为了表明程序是正确的”，

“成功的测试是没有发现错误的测试”等等是完全相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如

果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。

由于测试的目标是暴露程序中的错误，从心理学角度看，

由程序的编写者自己进行测试是不恰当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外，应该认识到测试决不能证明程序是正确的。即使经过了最

严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。

软件测试术语表

acceptance testing: Formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component.

接收测试：用来使一个用户、客户或者其它的权威机构决定是否接收一个系统或者组件的测试。

actual outcome: The behaviour actually produced when the object is tested under specified conditions.实际输出：被测对象在特定条件下实际产生的行为。

ad hoc testing: Testing carried out using no recognised test case design technique.

探索式测试：不使用可识别的测试用例设计技术所进行的测试。

alpha testing: Simulated or actual operational testing at an in-house site not otherwise involved with the software developers.

α测试：在软件开发人员缺席的情况下内部做的模拟的或者实际的操作性测试。

arc testing: A test case design technique for a component

in which test cases are designed to execute branch outcomes.

分支测试：一种针对组件的测试用例设计技术，通过分支覆盖来进行测试用例设计。

Backus-Naur form: A meta language used to formally describe the syntax of a language.

Backus-Naur 形式：一种用来从形式上描述一种语言的语法的元语言。

basic block: A sequence of one or more consecutive, executable statements containing no branches.

基本块：一个由不包含任何分支的一个或者多个连续的、可执行的指令组成的序列。

basis test set: A set of test cases derived from the code logic which ensure that \% branch coverage is achieved. 基本测试集：基于代码的逻辑结构且保证一定的分支覆盖率的测试用例的集合。

bebugging: The process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program.

错误撒播：通过在计算机程序中人为的引入已知的错误来监

测发现和消除错误的比率、估计程序中剩余的错误数的方法。

behavior: The combination of input values and preconditions and the required response for a function of a system. The full specification of a function would normally comprise one or more behaviors.

行为：系统中一个功能的输入值、前提条件和必要的响应的集合。一个功能的完整说明需要包含一个或多个行为。

beta testing: Operational testing at a site not otherwise involved with the software developers.

β测试：在软件开发人员缺席的情况下做的操作性测试。big-bang testing: Integration testing where no incremental testing takes p lace prior to all the system‘s components being combined to form the system.

非渐增式测试：在单独测试所有构成系统的组件之前不进行任何额外测试的集成测试。

black box testing: Test case selection that is based on an analysis of the specification of the component without reference to its internal workings.

黑盒测试：不涉及组件的内部工作情况而只根据组件规格说

明来选择测试用例的测试方法。

bottom-up testing: An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.

自底向上的测试：集成测试时先测试最低层的组件，然后用最低层的组件来帮助测试更高层组件的一种方法。这个过程一直重复进行直到最高层的组件被测试到。

boundary value: An input value or output value which is on the boundary between equivalence classes, or an incremental distance either side of the boundary.

边界值：位于两个等价类之间的输入或输出值，或者边界附近的值。

boundary value analysis: A test case design technique for a component in which test cases are designed which include representatives of boundary values.

边界值分析：为被测组件设计包含典型边界值的测试用例的一种测试用例设计方法。

boundary value coverage: The percentage of boundary values of the component‘s equivalence classes which have been exercised by a test case suite.

边界值覆盖：被一组测试用例覆盖到的被测组件等价类的边界值占所有边界值的百分比。

全球化测试

全球化测试的目的是检测应用程序设计中可能阻碍全球化的潜在问题。它确保代码可以处理所有国际支持而不会破坏功能，导致数据丢失或显示问题。全球化测试使用每种可能的国际输入类型，针对任何区域性或区域设置检查产品的功能是否正常。

正常的产品功能假定该组件性能稳定，能按照设计规范运行（不考虑国际环境设置或区域性/区域设置），并且数据的表示方式正确。

下列内容必须是全球化测试计划的一部分：

决定每个组件的优先级

若要使全球化测试更有效，请为所有测试的组件分配测试优先级。应具有高优先级的组件为：

支持ANSI（美国国家标准学会）格式的文本数据

大量处理字符串的组件（例如，具有许多编辑控件(Edit Control) 的组件）

使用文件进行数据存储或数据交换的组件（例如，Windows 图元文件、安全配置工具和基于Web 的工具）

过去存在许多全球化问题的组件

选择测试平台

那么，应为国际测试平台使用哪一种操作系统(OS) 呢？第一个选择应是安装了语言组的Windows 2000 的本地版本。例如，如果使用Windows 2000 的美国版本，请安装

东亚语言组。这种组合对选择的语言提供了完整的国际支持，而没有对测试者的语言技能提出要求。

即使是面向更广泛的操作系统，Windows 2000 也应是主要的测试平台。早期的操作系统在本地设置和本机支持方面，没有为最广泛的语言和区域性或区域设置提供同样的灵活性。

还可以使用不同于Windows 2000 的本地版本的其他

平台：

MUI（多语言用户界面）Windows 2000 —当代码实现多语言UI 而且必须调整到OS 的UI 设置时特别有用。这种方

法是安装OS 的多个本地化版本的更容易实现的替代方法。为了进一步增强多语言支持，Microsoft 提供了一个单独的Windows 2000 多语言版，它提供Windows 用户界面的多达24 种本地化语言版本。有关更多信息，请参见多语言用户界面(MUI)。

目标OS 的本地化版本—德语或日语是好的选择。记住，如果不熟悉操作系统的UI 语言，使用它们可能比较困难。此方法并不比前面的解决方案有明显的优势。

通过测试发现的大多数全球化问题都发生在这两种情

况下：即东亚语言支持处于活动状态时，或者OEM 代码页不同于给定区域性或区域设置的ANSI 代码页时。例如，可以在Windows 2000 的美国版本中选择下列区域性/区域设置来测试潜在的全球化问题：

日语

德语

尽可能采用两者（一种为系统区域设置选择，另一种为用户区域设置选择）的组合以包括多语言支持

如果安装所有语言组，轮换使用区域性或区域设置，并按如下所述运行“全球化”测试，则可以获得最全面的覆盖范围。

创建测试环境

为执行全球化测试，必须安装多个语言组并确保区域性或区域设置不是您的本地区域性或区域设置。如上所述，在日语环境、德语环境以及两者的组合环境中执行测试案例可以覆盖大多数全球化问题。[NextPae]

基本上，使用日语和德语环境创建世界通用的测试环境的步骤为：

在Windows 2000 本地版本上，如果没有安装日语（或任何其他东亚地区语言）和德语支持（默认情况下，Windows 2000 的美国版本安装德语支持），请安装它们。

将测试机器上的区域性或区域设置设置为与本地区域性或

区域设置不同的区域性或区域设置（日语或德语）。

用Windows 2000 系统的本地版本的混合环境建立一个分

布式网络，将某些系统设置为日语区域性或区域设置，将其他系统设置为德语区域性或区域设置。

将日语作为系统默认区域性或区域设置进行测试，可验证ANSI（非Unicode）组件中的双字节字符集(DBCS) 处理。将德语作为系统默认区域性或区域设置进行测试，可确保再需要进行文本转换时能够正确处理ANSI 和OEM 代

码页。建立分布式混合网络环境可以验证数据是否可以在不同的区域性或区域设置之间成功传递。

执行测试

在为全球化测试设置好环境后，当运行常规测试案例时，必须特别注意潜在的全球化问题：

将重点更多地放在直接或间接处理字符串输入/输出的测试

案例上。

测试数据必须包含来自东亚语言、德语、复杂脚本字符和英语（可选）的混合字符；其中复杂脚本字符指阿拉伯语、