软件测试期末复习资料

最新推荐文章于 2024-11-04 08:17:56 发布

nuc的救赎

最新推荐文章于 2024-11-04 08:17:56 发布

阅读量355

点赞数 5

文章标签：功能测试压力测试单元测试测试用例测试工具

本文链接：https://blog.csdn.net/weixin_74152658/article/details/139438097

版权

第一章

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

软件质量保证（Software Quality Assurance，SQA）活动是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程。

软件测试的目的

（1）测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

（2）通过分析错误产生的原因还可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进。同时通过对测试结果的分析整理，还可以修正软件开发规则，并为软件可靠性分析提供依据。

（3）测试是以评价一个程序或者系统属性为目标的一种活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求，为用户选择与接受软件提供有力的依据。

软件测试的对象

软件测试不等于程序测试。

软件测试贯串于软件定义和开发的整个过程。

软件开发过程中所产生的需求规格说明、概要设计规格说明、详细设计规格说明以及源程序等都是软件测试的对象。

软件测试的原则

所有的软件测试都应追溯到用户需求；

尽早地和及时地测试；

完全测试是不可能的，测试需要终止；

测试用例应当由测试数据和与之对应的预期结果这两部分组成；

测试用例应包括有效输入和无效输入；

在程序提交测试后，应当由专门的测试人员进行测试；

格执行测试计划，排除测试的随意性；

充分注意测试当中的群集现象；

应对每一个测试结果做全面的检查；

保存测试计划、测试用例、出错统计和最终分析报告，为维护工作提供充分的资料。

V模型 P11

W模型 P70

H模型

测试驱动开发的思想 P12

第二章

ISO 9126软件质量三层模型 P16页

软件质量的度量主要是根据软件生存周期中对软件质量的要求所进行的一项活动。它主要分为三方面：外部度量、内部度量和使用度量。

外部度量—测试和使用软件产品过程中进行

内部度量—软件设计和编码过程中进行

使用质量的度量—在用户使用过程中完成的

软件测试分类：

1）按照是否运行程序划分为：

静态测试、动态测试

（2）按照测试的方法划分为：

主动测试、被动测试

（3）按照测试用例设计方法划分为：

白盒测试、黑盒测试、灰盒测试

（4）按照开发阶段划分为：

单元测试、集成测试、系统测试、验收测试、α测试、β测试

（5）按照测试中是否使用工具划分

手工测试、自动化测试

（6）按照实施测试的组织划分为：

开发方测试、用户测试、第三方测试

静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等。

动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证。

主动测试方法：测试人员主动向被测试对象发送请求、或借助数据、事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果

被动测试方法：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据。

软件测试的级别 P28-29

软件测试计划和测试用例 P29-31

第三章软件测试的方法

3.1 基于直觉和经验的方法

3.1.1 自由测试（Ad-hoc测试方法）和ALAC测试（像客户那样做）

3.1.2 错误推测法

3.2 基于输入域的方法（IDBT）

3.2.1等价类划分法

习题

3.2.2边界值分析法

确定边界值的方法

示例

3.3 基于组合技术和组合优化的方法

3.3.1判定表方法

示例

3.3.2因果图法

示例

3.4 基于逻辑覆盖的方法

3.4.1语句覆盖

语句覆盖法的基本思想是设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次
如果是顺序结构，就是让测试从头执行到尾
如果有分支、条件和循环，需要利用下面的方法，执行足够的测试覆盖全部语句

语句覆盖能发现一般语句的错误，但不能发现其中的逻辑错误。

例如：

3.4.2判定覆盖（书本p49页）

3.4.3条件覆盖

3.4.4判定条件覆盖（书本p51页）

3.4.5条件组合覆盖p52

示例在书上

3.4.6 基本路径覆盖（环形复杂度和程序流图在本节p54）p53

流图的画法

独立路径

示例

第5章 单元测试与集成测试

单元测试是对软件基本的组成单元进行独立的测试

5.2 静态测试技术的运用

静态测试是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。

（1）代码测试：主要测试代码是否符合相应的标准和规范。（单元测试）

（2）界面测试：主要测试软件的实际界面与需求中的说明是否相符。（系统测试）

（3）文档测试：主要测试用户手册和需求说明是否真正符合用户的需求。（验收测试）

互查（Peer Review）
走查（Walk Through）
评审（ Inspection ）

	走查	审查
准备	通读设计和编码	事先准备Spec、程序设计文档、源代码清单、代码缺陷检查表等
形式	非正式会议	正式会议
参加人员	开发人员为主	项目组成员包括测试人员
主要技术方法	无	缺陷检查表
生成文档	会议记录	静态分析错误报告
目标	代码标准规范无逻辑错误	代码标准规范无逻辑错误

动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。

白盒测试

黑盒（灰盒）测试

驱动程序和桩程序

运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。

驱动模块（drive）:对底层

或子层模块进行测试所编写的

调用这些模块的程序。

桩模块（stub）：对顶层或

上层模块进行测试时所编写的

替代下层模块的程序。

单元测试的测试举例：

案例：驱动模块和桩模块

#include <stdio.h>

void main(void)

{int a=1,b=2,c;

c=fun1(a,b);

}

int fun1(int x,int y)

{return x+y;}

单元测试的测试举例：

练习：为下面的函数构造一个驱动模块，并至少设计5条测试用例。

/*计算2个整数的除法运算将结果转换为单精度输出*/

float divide(int a,int b)

{ float c;

if(b==0) printf(“除数不能为0！”);

return 0;

c=(float)a/b;

return c;}

构造驱动模块如下：

void main(void)

{ int x;

int y;

float z;

scanf(“%d%d”,&x,&y);

z=divide(x,y);

printf(“%f”,z);

}

编写5条测试用例，如下表所示：

用例编号	输入数据	预期结果
1	x=4,y=2	2.000000
2	x=1,y=5	0.200000
3	x=3,y=0	提示“除数不能为0”
4	x=a,y=b	提示“请输入整数”
5	x=1.2,y=3.4	提示“请输入整数”

单元测试的停止准则

（1）软件单元功能与设计需求一致；

（2）软件单元接口与设计需求一致；

（3）能够正确处理输入和运行中的错误；

（4）在单元测试中发现的错误已经修改并通过了测试；

（5）达到了相关的覆盖率的要求；

（6）完成软件单元测试报告；

5.5 系统集成的模式与方法

一、集成测试（组装测试）

——将经过单元测试的模块按设计要求组合起来再进行的测试。

二、目的

——检查各模块间接口是否存在问题

三、集成测试的任务

（1）将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失。

（2）将各个子功能组合起来，检查能否达到预期要求的各项父功能。

（3）一个模块的功能是否会对另一个模块的功能产生不利的影响。

（4）全局数据结构是否有问题，会不会被异常修改。

（5）单个模块的误差积累起来，是否被放大，从而达到不可接受的程度。

集成测试的模式

渐增式测试模式与非渐增式测试模式　

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。

采用大棒集成方法,先是对每一个子模块进行测试（单元测试阶段），然后将所有模块一次性的全部集成起来进行集成测试 。

因为所有的模块一次集成的，所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用，适合在规模较小的应用系统中使用。

渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

自顶向下集成方式的步骤：

① 以主模块为所测试模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。

② 依照所选用的模块集成策略（深度优先和广度优先），用实际模块替换相应桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。

③ 进行回归测试，排除组装过程中引入新的错误的可能。

④ 判断是否所有的模块都组装到系统中？是则结束测试，否则转到②去执行。

自底向上集成方式的步骤：

① 由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。

② 用实际模块代替驱动模块，与它已测试的直属子模块组装成子系统。

③ 为子系统配备驱动模块，进行新的测试。

④ 判断是否已组装到达主模块。是则结束测试，否则转到②去执行。

4、两种增量集成方式的比较

自顶向下集成方法

优点：不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，发现上层模块的接口错误。
缺点：需要桩模块

自底向上集成方法

优点：不需要桩模块。
缺点：程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体。

混合策略(Modified Top-down Integration)

混合法：对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向上”法，两者相结合

改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底。

	自底向上	自顶向下	混合策略	大棒	三明治	改进三明治
集成	早	早	早	晚	早	早
基本程序能工作时间	晚	早	早	晚	早	早
需要驱动程序	是	否	是	是	是	是
需要桩程序	否	是	是	是	是	是
工作并行性	中	低	中	高	中	高
特殊路径测试	容易	难	容易	容易	中等	容易
计划与控制	容易	难	难	容易	难	难

持续集成

通常系统集成都会采用持续集成的策略，软件开发中各个模块不是同时完成，根据进度将完成的模块尽可能早的进行集成，有助于尽早发现Bug，避免集成中大量Bug涌现
而且容易定位Bug、修正Bug，最终提高软件开发的质量与效率

第六章

1、系统测试

系统测试的根本任务就是要证明被测系统的功能和结构的稳定性；还要有一些非功能测试：性能测试、压力测试、可靠性测试等等。

最终目的是为了确保软件产品能够被用户或操作者接受。测试的主要目标不再是找出缺陷，而是证明其性能。

系统测试属于黑盒测试范畴，不再对软件的源代码进行分析和测试。

系统测试就是将已经集成好的软件系统，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。

系统测试的目的在于通过与系统的需求定义比较，检查软件是否存在与系统定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规约所指定的要求。

2、功能测试

功能测试属于黑盒测试技术范畴，是系统测试中要进行的最基本的测试，它不用考虑软件内部的具体实现过程。

功能测试主要是根据产品的需求规格说明书和测试需求列表，验证产品是否符合产品的需求规格。

需求规格说明是功能测试的基本输入。因此先对需求规格进行分析，明确功能测试的重点。

可按照如下步骤进行：

① 为所有的功能需求（其中包括隐含的功能需求）加以标识；

② 为所有可能出现的功能异常进行分类分析并加以标识；

③ 对前面表示的功能需求确定优先级。

④ 对每个功能进行测试分析，分析其是否可测、采用何种测试方法、测试的入口条件、可能的输入、预期输出等等。

⑤ 是否需要开发脚本或借助工具录制脚本。

⑥ 确定要对哪些测试使用自动化测试，对哪些测试使用手工测试。

功能测试要点：

功能逻辑清楚，符合使用者习惯
系统的各种状态按照业务流程而变化，并保持稳定
每项功能符合实际要求
系统的界面清晰、美观
菜单、按钮操作正常、灵活，能处理一些异常操作
能接受正确的数据输入，对异常输入的容错处理
数据的输出结果准确，格式清晰，可以保存和读取
程序安装、启动正常，有相应的提示框、错误提示等

功能测试方法:

等价类划分法、边界值分析法、错误推测法、因果图法、组合分析法

3、回归测试

回归测试的目的

所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；
不影响软件原有功能的正确性。

一旦程序某些区域被修改了，就可能影响其它区域，导致受影响的区域出现新的缺陷（回归缺陷）。如果这时没有回归测试，产品就带着这样的回归缺陷被发布出去了，造成严重后果。回归测试就是为了发现回归缺陷而进行的测试。

回归测试的组织和实施

- - 识别软件中被修改的部分；
  - 从原有测试用例库T中，排除不适用的测试用例，建立新的测试用例基线库T0；
  - 从新的测试用例基线库中选择测试用例，测试被修改的软件；
  - 若回归测试套件达不到所需的覆盖要求，必须补充新的测试用例，使覆盖率达到规定的要求，则生成新的测试用例集T1，用于测试T0无法测试的软件部分；
  - 用T1测试修改后的软件。

4、性能测试

性能测试（performance test）就是为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况。

软件性能认知：用户，软件对用户操作的响应时间，如用户提交一个查询操作、打开一个web页面的链接等，业务可用度，或者系统的服务水平如何

开发人员，架构设计是否合理、数据库设计是否存在问题、代码是否需要优化，如SQL语句、如何通过调整设计和代码实现，或如何通过调整系统设置提高软件的性能表现。

系统管理员，并发压力、服务器端资源使用情况、是否存在性能瓶颈、系统可扩展性如何。

性能测试目标：

获取系统性能某些指标数据
为了验证系统是否达到用户提出的性能指标
发现系统中存在的性能瓶颈，优化系统的性能

性能测试类型：

性能验证测试，验证系统是否达到事先已定义的系统性能指标、能否满足系统的性能需求
性能基准测试，在系统标准配置下获得有关的性能指标数据，作为将来性能改进的基准线
性能规划测试，在多种特定的环境下，获得不同配置的系统的性能指标，从而决定在系统部署时采用什么样的软、硬件配置
容量测试可以看作性能的测试一种，因为系统的容量可以看作是系统性能指标之一

性能测试要点：

1、测试环境应尽量与产品运行环境保持一致，应单独运行尽量避免与其他软件同时使用。

2、性能测试一般使用测试工具和测试人员编制测试脚本来完成。

3、性能测试的重点在于前期数据的设计与后期数据的分析。

4、性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。

性能测试常用术语（p153）

响应时间、吞吐量、资源占用率、在线用户虚拟用户、并发用户、用户并发数量、思考时间、负载模式

压力测试(Stress test)，也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。

压力测试类型：在一种需要反常（如长时间的峰值）数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈或其它不稳定性问题

并发性能测试（重点）
疲劳强度测试
大数据量测试

性能测试需求和指标：

性能测试需求：
用户对各项指标提出的明确需求；如果用户没有提出性能指标，则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）
主要的性能指标：
服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间

性能的具体指标：

数据传输的吞吐量（Transactions）
数据处理效率（Transactions per second）
数据请求的响应时间（Response time）
内存和CPU使用率
连接时间（Connect Time）、发送时间（Sent Time）
处理时间（Process Time）、页面下载时间
第一次缓冲时间
每秒（SSL）连接数
每秒事务总数、每秒下载页面数
每秒点击次数、每秒HTTP 响应数
每秒重试次数

性能测试要点：

1. 测试环境应尽量与产品运行环境保持一致，应单独运行尽量避免与其他软件同时使用
2. 录制脚本和手工编写脚本相结合
3. 重点在于前期数据的设计与后期数据的分析
4. 设置数据池，实现变量加载
5. 采用复合交易测试方案、业务批量执行
6. 需要同时监控数据库服务器、Web服务器以及网络资源等使用情况，以便对系统的性能做全面评估
7. 模拟用户数的递增
8. 合理设置交易之间时间间隔
9. 超时（timeout）的设置、错误处理
10. 并发用户连续执行交易数的设置、设置并发点
11. 并发用户数量极限点
12. 尽量将执行负载测试的机器合理分布
13. 加压机器的CPU使用率也有必要监控

5、其他非功能性测试

安全性测试
可靠性/容错性测试
兼容性测试

第七章验收测试

1.什么是验收测试？

验收测试 (Acceptance Test): 在软件产品完成了系统功能和非功能测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。

7.1 验收测试的过程和主要内容

前提:系统或软件产品已通过了系统测试的软件系统。

测试内容:验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受。主要包括易用性测试、安装测试、文档（如用户手册）测试等几个方面的内容

2.测试步骤：

测试步骤：制定测试计划及验收通过准则，通过客户评审
设计测试用例并通过评审
准备测试环境与数据，执行测试用例，记录测试结果
分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。
提交测试报告

3.验收标准和注意事项

验收测试完成标准:

（1）完全执行了验收测试计划中的每个测试用例

（2）在验收测试中发现的错误已经得到修改并且通过了测试、或经过评估留待下一版本中修改

（3）完成软件验收测试报告

注意事项：

必须编写正式的、单独的验收测试报告
验收测试必须在实际用户运行环境中进行
由用户和测试部门共同执行。如公司自开发产品，应由测试人员，产品设计部门，市场部门等共同进行

**4.α测试和β测试

α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
经过α测试调整的软件产品称为β版本。
β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
验收测试报告，也称为发布报告（Release Report）

7.2 产品规格说明书的验证

产品规格说明书的审核

从客户的角度和立场进行审核工作
检验套用标准的正确性，不要和行业规范相抵触
审查、研究同类产品。
验证其完整性、准确性、一致性、合理性等特性。

产品规格说明书的验证

已经实现的特性标识为通过
特性没有实现、报告bug并在报告中体现
特性基本实现，但与其不一致，报bug并在报告中体现

7.3 用户界面和易用性测试

用户界面的 7个要素:

1. 1. 符合标准和规范
  2. 直观性
  3. 一致性
  4. 灵活性
  5. 舒适性
  6. 正确性
  7. 实用性

易用性测试没有具体量化的指标，主观性较强

直观性：

- 首先了解所需的功能或期待的结果的响应直观、显著，并在预期的地方出现。

- 其次要考虑用户界面的组织和布局是否合理。

一致性：包括软件本身的一致性，以及软件与其他软件的一致性

灵活性：用户可灵活地选择不同的状态和方式，完成相应的功能。但灵活性也可能发展为复杂性，太多的状态和方式增加了用户理解和掌握的困难，也增加了编程的难度和测试的工作量

舒适性：恰当的表现、合理的安排、必要的提示或更正能力等是要考虑的因素，包括容错处理和性能。

正确性：正确性的问题一般都很明显，比较容易发现。

实用性：实用性不是指的是软件本身是否实用，而仅仅指的是具体特性是否实用。大型软件的开发或周期较长经过几次反复的软件开发中容易产生一些没有实用性的功能。

1. 可安装性和可恢复性测试

（1）系统软件安装（2）应用软件安装（3）服务器的安装（4）客户端的安装

（5）产品升级安装

可安装性测试

安装说明书有无对安装环境限制和特别要求？
过程是否简单、易掌握？
过程中是否有明显的、合理的提示信息？
是否会出现不可预见或不可修复的错误？
安装程序是否占用与原系统冲突的资源(如端口)？
安装中途是否可退出？是否能够后退？
能否安全卸载测试？
升级安装后原有程序是否可正常运行？
许可证号码与注册号码的验证

可恢复性测试

检查系统的容错能力。当系统出错时，能否在指定时间内修正错误或重新启动系统。
恢复测试:通过各种手段、让软件强制性地发生故障，然后验证系统是否能尽快恢复。

1. 文档测试

种类：（1）联机帮助文档或用户手册；（2）指南和向导；（3）安装、设置指南；（4）示例及模板；（5）错误提示信息；（6）用于演示的图像和声音；（7）授权/注册登记表及用户许可协议；（8）软件的包装、广告宣传材料；

怎样进行文档测试

好的文档能达到提高易用性、提高可靠性、降低技术支持费用的目的，从而提高了产品的整体质量。

主要检查文档:正确性完备性可理解性一致性

第8章国际化和本地化测试

8.1 软件国际化

国际化的英文单词是“Internationalization”。
软件国际化是在软件设计和文档开发过程中，使得功能和代码设计能处理多种语言和文化习俗，能够在创建不同语言版本时，不需要重新设计源程序代码的软件工程方法。
2、国际化软件设计要遵循的通用准则：
(1)在国际化软件项目的初期融入国际化思想，并且使国际化贯穿于项目的整个生命周期。
(2)采用单一源文件进行多语言版本的本地化，不针对不同的语言编写多套代码。
(3)需要本地化的文字与软件源代码分离，存储在单独的资源文件中。
(4)软件代码支持处理单字节字符集和多字节字符集文字的输入、输出和显示，并且遵守竖排和折行规则。
(5)软件代码应该支持Unicode标准，或者可以在Unicode和其它代码页(Code Page)互换。
6)软件代码不要嵌入字体名，也不要假设使用某种字体。
(7)使用通用的图标和位图，避免不同区域的文化和传统差异，避免在图标和位图中嵌入需要本地化的文字。
(8)菜单、对话框等界面布局能够满足处理本地化文字的长度扩展的需要。
(9)源语言的文字要准确精简，使用一致的术语，避免歧义和拼写错误，以便进行本地化翻译。
(8)保证不同区域的键盘布局都能使用源软件的快捷键。
(11)考虑不同区域的法律和文化习俗对软件的要求。
12)如果软件中采用第三方开发的软件或组件，需要检查和确认是否满足国际化的要求。
(13)保证源语言软件可以在不同的区域和操作系统上正确运行。
(14)软件代码中避免“硬编码”，不使用基于源语言的数字常量、屏幕位置、文件和路径名。
(15)字符串的缓冲区长度要满足本地化字符扩展的长度。
(16)软件能正确支持区域排序和大小写转换。
3、国际化测试
国际化测试的目的是测试软件的国际化支持能力，发现软件国际化的潜在问题，保证软件在世界不同区域中都能正常运行。

8.2 软件本地化

本地化是为解决网站、软件以及文档资料向其它国家推广时遇到的语言障碍问题。网站本地化：网站需要翻译成不同国家的语言，以便不同国家的人能够无障碍地阅读网站内容。软件本地化，以便能够在目标国家推广。当然将网站或软件本地化为全世界所有语种是不现实的，一般的惯例是只面向几种主要的语种（尤其是英语）进行本地化，比如现在许多国内网站都有中英文两个版本

软件全球化（ Globalization ）：是一个概念化产品的过程，它基于全球市场考虑，为全球用户设计，面向全球市场发布具有一致界面、风格和功能的软件。它的核心特征和代码设计并不局限于一种语言和区域用户，可以支持不同目标市场的语言文字和数据信息的输入、输出、显示和存储。