魔兽7.0变身玩具:软件测试概论

软件测试概论

什么软件生存周期

一个软件从开始计划起，到废弃不用止，称为软件生存周期。一般来说，软件生存周包括计划、开发、运行三个时期，每一时期又可分为若干更小的阶段。计划时期 的主要任务是分析用户要求，分析新系统的主要目标以及开发该系统的可行性。开发时期要完成设计和实现两大任务具体。具体分为需求分析、概要设计、详细设 计、编码、测试。其中编码和测试是软件开发期的最后两个阶段。运行时期是软件生存周期的最后一个时期，软件人员在这一时期的工作，主要是做好软件维护。

　 　 统计表明，开发较大规模的软件，有40%以上的精力是耗费在测试上的，即使富有经验的程序员，也难免在编码中发生错误，何况，有写错误在设计甚至分析阶段 早已埋下祸根，无论是早期潜伏下来的错误或编码中新引入的错误，若不及时排除，轻者降低软件的可靠性，重者导致整个系统的失败。为防患于未然，强调软件测 试的重要性是必要的。

好的测试工程师

　1、沟通能力

　　一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者） 和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系 统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户 和开发者沟通。

　　2、技术能力

　　就总体言，开发人员对那些不懂技术的人持 一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使 用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者， 简化自动测试工具编程的学习曲线。

　　3、自信心

　　开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

　　4、外交能力

　 　当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需 要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于"赢了战争却输了战役"。

　　5、幽默感

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

　　6、很强的记忆力

　　一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

　　7、怀疑精神

　　可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

　　8、自我督促

　　干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

　　9、洞察力

　　一个好的测试工程师具有"测试是为了破坏"的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

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

日前，招聘网站——中华英才网发布了最新一期的ＩＴ职场人气排行榜。根据统计，ＩＴ人才仍是企业需求量最大的人群，其中软件测试工程师、高级程序员、产品 项目经理高级职位进入“三甲”，成为ＩＴ就业市场最新风向标。作为软件开发流程中的重要一环，软件测试岗位渐渐“浮出水面”，并凭借其庞大的人才需求和广 阔的职场发展前景日渐成为ＩＴ职场就业的大热门。

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

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

　　由于我国企业对于软件测试自动化技术在整个软件行业中的重要作用认识较晚，因此，这方面的专业技术人员在国内还是凤 毛麟角，人才供需之间存在着巨大的缺口。有关数据显示，我国目前软件从业人才缺口高达40万人。即使按照软件开发工程师与测试工程师11的岗位比例计 算，我国对于软件测试工程师的需求便有数十万之众。业内专家预计，在未来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 place 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]

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

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

2. 将测试机器上的区域性或区域设置设置为与本地区域性或区域设置不同的区域性或区域设置（日语或德语）。

3. 用 Windows 2000 系统的本地版本的混合环境建立一个分布式网络，将某些系统设置为日语区域性或区域设置，将其他系统设置为德语区域性或区域设置。

　　将日语作为系统默认区域性或区域设置进行测试，可验证 ANSI（非 Unicode）组件中的双字节字符集 (DBCS) 处理。将德语作为系统默认区域性或区域设置进行测试，可确保再需要进行文本转换时能够正确处理 ANSI 和 OEM 代码页。建立分布式混合网络环境可以验证数据是否可以在不同的区域性或区域设置之间成功传递。

　　执行测试

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

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

• 测试数据必须包含来自东亚语言、德语、复杂脚本字符和英语（可选）的混合字符；其中复杂脚本字符指阿拉伯 语、希伯来语、泰语。某些情况下有限制，比如接受只匹配区域性或区域设置的字符时。如果不熟悉准备测试数据所用的语言，则手动输入所有这些测试数据可能很 困难。一个简单的 Unicode 文本生成器在此步骤中可能非常有用。

　　识别问题

　　最严重的全球化问题是丢失功能，包括立即丢失功能（区域性/区域设置更改时）和以后访问输入数据（非美国字符输入）时丢失功能。

　　某些功能问题和显示问题一样是可以检测到的：

• 出现问号 (?) 而不是显示文本表示问题出在 Unicode 到 ANSI 的转换中。

• 如果出现随机高位 ANSI 字符（如 ?、?、‰、? 和 ?）而不是可读的文本，则表示问题出在使用错误代码页的 ANSI 代码中。

• 如果出现方框、竖条或鼻音化符号（默认的标志符号）[□、|、~]，则表示所选字体无法显示某些字符。

　　在要求变形、布局或脚本知识的显示或打印结果中找出问题可能很困难。这种测试是语言特定的，在没有语言专门知识的情况下通常无法执行。另一方面，测试可能仅限于代码检查。如果使用标准文本处理机制形成并显示输出文本，则可以认为这方面是安全的。

　　潜在问题的另一个方面是未能遵循由当前区域性或区域设置定义的本地约定的代码。确保应用程序根据计算机的当前区域设置显示区分区域性或区域设置的数据（例如，数字、日期、时间、货币和日历）。

　　“控制面板”中的“区域选项”并未包括所有区域性或区域设置特定的功能。例如，在那里看不到当前的排序顺序。因此，在开始测试前制定一个包括与区域性或区域设置有关的所有功能方面的测试计划很重要。

一本适合测试初学者阅读的中文译著

由于看好软件测试的行业发展前景，越来越多的人士加入到软件测试的大军中来。但是由于很多人都是刚刚毕业或者从其 它非测试公司或岗位转来的，他们对软件测试的要求和知识技能了解和掌握的很有限，而各公司对测试工程师的招聘大都要求熟悉软件测试的理论和实践经验，这就 造成了初涉测试行业的新人在求职过程和实际测试工作中暴露测试专业知识不足的问题。因此，他们迫切需要在较短的时间内学习和掌握软件测试的基本知识。

   无疑，阅读关于测试的书籍是较快的学习方法。但是，现在出版的很多关于测试的书籍，并不适合测试入门者的实际需求，这些书籍要么是关于测试理论的长篇大 论，要么是针对某一个很狭窄的领域进行讨论。另外，国内目前市场上出版的关于测试的书籍质量良莠不齐，甚至很多翻译的书籍内容错误连篇，还不如直接阅读英 文原著更好。实际上，测试初学者最需要的是对测试进行深入浅出的介绍和结合测试实践的测试入门书籍。

  笔者经常到书店浏览国内关于 软件测试的新书，也先后买过和阅读了不少测试书籍，对于书籍的优劣感触颇深。我有时为发现一本好书而“爱不释手”，陶醉于阅读的兴趣中，但有时也为不小心 买到了粗制滥造的书籍感到烦恼，阅读这些内容不好的书籍简直是一种“煎熬”，纯粹浪费时间，甚至造成误导。从目前看来，国内这两年的确出版了不少国内作者 创作的测试专著，但是更多的是翻译国外的英文书籍。在以往测试工作中，经常有一些朋友（特别是是刚刚参加测试工作的新人）询问和要求我推荐一些适合他们阅 读的测试入门书籍。

  经过比较，我推荐书名为《软件测试》的译著。本书作者为美国的Ron Patton，译者是周予滨、姚静等。由机械工业出版社2003年8月第一次出版，书号是ISBN 7-111-09925-7。1000mm x 1400mm B5.9印张，348千字，共271页，定价25元人民币。

  这本书不仅书名和封面设计朴实无华，更重要的是书中内 容比较适合测试入门者。与同类书籍相比，本书非常浅显易懂。另外本书内容全面，包括软件测试的概述、软件开发过程简介、基本和高级的软件测试技术、测试工 具与测试自动化、测试计划、报告软件缺陷、测试职业发展等。虽然内容繁多，但是全书只有271页，利用有限的篇幅对这些测试只是进行了高度概括。作者凭借 丰富的实践经验从满足测试初学者需求的角度，将这些繁杂的内容使用最简捷的浅显表述，将复杂问题层层剖析、流畅讲解，呈现给读者的是作者的独到见解，为初 学者组织量身定做的实用内容，这是一本作者用心写作的书籍。

 软件测试是有计划、有组织和有系统的软件质量保证活动，而不是随意地、松散地、杂乱地实施过程。软件测试已经成为一门单独的学科，包含很多方面的内容， 而作为测试初学者，面对如此丰富的测试知识，经常感到不知从何学起，不知道最快的学习方式是什么。本书对此由浅入深的将需要学习的测试内容分为六个部分， 每一部分包含几章分别介绍。这六个部分分别是：软件测试综述、测试基础、测试技术、加强测试、使用测试文档和软件测试展望。在每一章里，作者给出了不少实 际测试例子，配合很多图形，将每个问题的描述、测试技术和实践经验一一阐述。不仅如此，每一章还包含针对本章内容的“小测验”，并且在书末给出了完整的参 考答案。

  对于近年来备受关注的国际化和本地化软件测试，本书也专门列出“外国语言测试”一章进行阐述，其中讲述了翻译问题、本地 化问题、配置和兼容性问题。此外本书还包含了网站测试、文档测试、配置测试等章节，也包括黑盒测试和白盒测试的方法，将测试过程中常用的测试对象的类型逐 个简明介绍。

  本书不仅讨论软件测试的技术，而且对于软件测试管理和个人软件测试职业发展进行了论述，在本书的最后一章“软件测试员职业指导”中，列出了提高测试技术的途径和可用资源，给测试初学者指明了测试职业的努力方向和发展前途。

  另外，本书只所以被笔者看好，一个重要的原因还在于本书的翻译水平较高，比较通顺、准确和富有文采。看得出译者具有丰富的科技文档翻译经验，某些译文可以用“精彩、传神”来形容。

   但是，稍显遗憾的是本书中有不少关于软件测试的术语的翻译不太准确，与软件测试领域的专业说法很不一致，有可能为测试初学者今后工作带来一些困惑，猜测译 者可能缺乏足够的软件测试实践经历。比较有代表性的是以下几个词的翻译：“QA”，书中翻译成“质量评判”，应该是“质量保证”。“Project Manager”，书中翻译成“项目管理员”，应该是“项目经理”。“Regression testing”，书中翻译成“回复测试”，应该是“回归测试”。另外，本书也存在一些打字错误，例如，第24页，原文“软件终归要分布的”，应该是“软 件终归要发布的”。第145页，原文“网页不受如何一台计算机的限制”，应该是“网页不受任何一台计算机的限制”。第201页，原文“编写用于输入输入的 实际数值和预期结果”，应该是“编写用于输入输出的实际数值和预期结果”。希望再版时，可以将这些错误改正，最好请熟悉软件测试的人员对全书内容进行审 阅，以保证软件测试术语的翻译准确性。

  俗话说“瑕不掩瑜”，对于测试初学者，本书属于物有所值，值得推荐。当然，除了阅读好的测试书籍外，重要的是有机会参与完整的测试项目，总结实践经验，并且虚心交流。当然，这都是题外话，在此不再多言。

Alpha和Beta测试简介

大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。

　　Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在 模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员 及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始， 或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备 好。

　　Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开 发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由 用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。 Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于 Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。

　　由于Alpha和Beta测试的组织难度大，测试费用高，测试的随机性强、测试 周期跨度较长，测试质量和测试效率难于保证，所以，很多专业软件可能不再进行Beta测试。随着测试技术的提高，以及专业测试服务机构的大量涌现，很多软 件的Beta测试外包给这些专业测试机构进行测试。

国际化软件测试概论

国际化软件测试包括软件国际化测试和软件本地化能力测试。软件的国际化测试是重要的测试阶段，必须在本地化测试之前进行测试。国际化软件的测试目的是判断软件的国际化设计程度，确定软件是否支持可能的区域，是否可以容易的本地化。

　　一、国际化软件测试的重要性

　　软件项目团队的所有成员都应该认识并且高度重视国际化测试的重要性。

　　首先，任何不良的国际化设计的软件错误，将存在于所有本地化的语言版本，都需要修改源语言程序的代码才能修复该类错误，这将增加软件的本地化成本。

　　其次，良好国际化设计的软件将需要最小程度的本地化测试。因为良好的区域语言支持已经集成在软件的国际化设计中，需要翻译的资源已经从程序代码中分离出来，可以很容易的翻译资源文件中需要本地化的内容，而且不会破坏程序的功能。

　　二、国际化软件测试的原则

　　为了提高国际化测试的质量，需要遵循下面的原则：

• 一旦程序的代码足够稳定，尽早进行测试。

• 按照组件和功能特征的优先级从高到低的顺序进行测试

• 重点放在处理多语言字符串的直接或间接的输入/输出（I/O）

• 国际化功能测试与本地化能力测试并行进行。

• 使用伪本地化和伪镜像技术进行本地化能力测试。

　　三、软件国际化测试的方法

　　软件的国际化测试主要测试软件的国际化功能特征，需要测试国际化软件的通用功能、文本处理功能和区域支持功能。

　　采用下面的方法进行国际化测试：

　　1、测试通用功能

• 在各种语言环境下安装应用程序。

• 各种系统和用户区域设置的通用功能。

• 通过各种区域设置卸载应用程序。

　　2、测试文本处理功能

• 使用不同区域的输入法编辑器交互式文本输入。

• 多语言文本的剪贴板操作。

• 用户界面的文本处理。

• 双字节字符集的输入和输出。

• 多字节字符集文本的缓冲区大小的处理。

　　3、测试区域特征功能

• 遵循区域标准，正确输入、存储并检索区域特定数据。

• 验证带有数据分割符的输入时间、日期和数值。

• 纸张和信封的大小和打印的正确性。

• 区域有关的度量衡的处理功能。

　　四、软件本地化能力测试的方法

　　本地化能力测试的目的是验证被测软件的用户界面不用修改代码，就能够容易地被翻译成任何目标语言。

　　为了快速有效的测试软件的本地化能力，常用以下的测试方法：

　　1、测试伪本地化版本

　　伪本地化版本测试可以不用实际本地化，就能够发现在本地化过程中的用户界面的翻译错误。镜像技术也是伪本地化版本测试的常用技术，发现一些本地化过程中的控件布局方面的错误。

　　2、检查程序的代码

　　在检查程序的代码时，确保代码满足下列要求：

• 所有资源都独立于代码，并且以标准的资源格式编写。

• 不用指针算法来计算字符串长度、访问字符串元素。

• 不是通过剥离或串联，在运行时构建字符串。

• 没有假设字符串缓冲区的固定长度。

• 不在图标和位图内包含需要本地化的文本。

• 不存在对驱动器和文件名或者注册键的假设。

　　3、检查用户界面和文档

　　确保用户界面和文档中所用的术语清晰、一致、明确。当用户界面和文档提到相同的特性，是用的术语不一致，或者当文档使用了太多的技术行话时，会使本地化过程增减很大难度。如果本地化能力依赖于伪本地化，更应该注重检查文档的内容。

　　4、选择实际的本地化版本进行测试

　　虽然针对伪本地化版本的测试能够发现很多本地化能力方面的问题，但是仍然不能代替对实际的本地化版本进行本地化能力的测试。在选择合适的本地化版本时，通常考虑以下方面：

• 选择熟悉的可以迅速创建和测试的本地化语言版本。

• 选择特别容易暴露本地化问题的语言版本。

• 选择非常重要的目标市场的语言版本