linux-计算机词汇

1，名词解释

1，硬编码（Hard Code）

1.1 硬编码 （hard code 或hard coding ）

指的是在软件 实现 上，把输出或输入的相关参数 （例如：路径、输出的形式、格式）直接硬编码在源代码 中，而非在运行时期由外界指定的设置、资源、数据、或者格式做出适当回应。
硬编码，一般被认是种反模式 或者不好的实现，软件因应输入数据、或者输出的格式改变就必需修改源代码。对客户而言，改变源代码之外的小设置也许容易点。
硬编码，也并非完全只有缺陷，因应某些封装需要，或是软件保护的措施，硬编码有时候是必要的手段。除此之外有时候因应某些特殊的需求，制作出简单的应用程序，应用程序可能只会运行一次，或者永远只应付一种需求，杀鸡焉用牛刀，硬编码来缩短开发的时间，也是一种不错的决策。

硬编码就是一种不够灵活的代码方案,比如说，一个服务期端的程序，在执行时需要创建服务器进行侦听，你可以
1,简单的将它需要侦听的端口号放在代码里面，
2,也可以通过程序参数传入，
3,也可以通过配置文件放置。
上述的放在代码里面的就叫做硬编码。

#java小例子： int a=2,b=2;
硬编码：if(a==2) return false;
不是硬编码 if(a==b) return true;
#一个简单的版本：
顾名思义， 就是把数值写成常数而不是变量
如求圆的面积 的问题 PI（3.14）
3.14*r*r (这个3.14就是hardcode）
PI*r*r （这里的PI用的是变量形式，就不是hardcode)

1.2 产品激活码（Active Product）

指的是某软件经常检查它的开发商网站以确认该软件独一无二的的产品激活码没有列入黑名单或者该软件属盗版软件 。如果该开发商网站变了样、改了网域名 、亦或开发商破产且它的站关了，该软件将停止工作。
造成这种情况的软件开发者应该被认为是个严重过失，因为网站常常消失、更动。然而，这些考虑常常被忽略，原因归咎于软件开发者对网站或公司未来存在的傲慢态度，或者对遥远未来客户身上将发生什么事的消极态度。

1.3 固定安装路径

一些 Windows 软件在编写时，假设用者一定会将它安装在 C:/Program Files/Appname 下，于是导致不装在该目录下就无法安装、或者装了后不工作。因为有相当广大的用户偏好安装在默认磁盘以及默认目录，所以很多时不会碰到这个问题，而且软件 测试也可能无法找到这个问题。然而，对程序设计师或开发人员来说还是建议不要硬编码软件安装路径；因为你永远不知道路径名用哪国语言写的，而且不见得每个 装载 Windows 的机器都有 C: 磁盘驱动器。

1.4 启动盘

指的是某软件在激活时经常检查存在软盘上的某特殊文件，以确定该软盘不是盗版。假设该计算机 升级到没有软盘的新机器，该软件便无法运行，因为软盘没地方插。

在80 到90年代 ，无法想像一台计算机没有软盘，然而到现在这是很正常的事，因为软盘 已被淘汰了。如果某程序在15年前硬编码，而且没有发布任何补丁，该程序可能面对很严重的问题。当然，许多公司不关心它们的程序会不会在15年后被运行，甚至实际上可能是有计划地淘汰该程序的一种做法。

2，测试术语

回归测试是当软件发现bug并进行修复以后进行的一系列测试，主要是为了验证bug被修复并且没有引入新的bug;

冒烟测试是在进行正式测试之前对软件系统的一些基本的功能进行的测试,确保测试能够进行.

2.1 回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

2.2 冒烟测试

冒烟测试冒烟测试(smoke test)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。

冒烟测试是自由测试的一种。

3，封网

所谓“封网”不是封闭网络,而是“封闭”互联网数据中心机房,网站工作人员和硬件设备都不能进出机房。封网不是针对普通网站和网友,而是针对电信、网络运营商、互联网数据中心公司。
“封网”是电信运营商的专门说法，不是关闭网络和封闭网络、停止对外的访问接口，而是停止升级、割接、设备入网等工作，停止对网络影响较大的操作活动，以保障网络的稳定运行。当然，"封网"不代表不维护网络，如果遇到网络故障，仍然需要第一时间处理。

4，长尾理论

http://blog.csdn.net/zhoubl668/article/details/7857747

其实随着网络的快速发展，不难看出，电子商务相比于传统的实体商务，有非常大的不同。正是这些不同，才让电子商务成为一门非常赚钱的学问。一个我认为很简单很形象的例子就是在一片海域中的岛屿和水平面的关系。在传统的实体商务中，相当于水平面非常的高，那么能看到的岛屿就非常的少，而且一个显著的特征就是这些岛屿必须是所有岛屿中最高的几个。这个类比于一个DVD商店，就是因为货架是有限的，那么只能够摆放一些购买量巨大的DVD。如果把货架资源浪费在一些很少有人问津的DVD上面，那么将带来的收益非常小。所以在传统得商店里面，摆放的通常都是销量排在前面的东西，通常这只是占了很少的一部分。但是随着互联网的发展，特别是电子商务的发展，那么这种货架得形式逐渐被磁盘等代价非常小的媒介所代替。这个就相当于海平面开始下降了，带来的好处就是更多的岛屿将会浮出水面，而且新浮出水面的这些岛屿可能会非常的矮。这样的方式正是现在的网店的盈利模式，也就是让更多的岛屿浮出水面。当这种条件限制正在慢慢变得不重要的时候，收益并非只是这些热门的东西，一些可能单件销量很少的物品合起来却能带来非常巨大的收益。电子商务已经不再是将盈利的模式集中在传统商店的热门商品上了，因为他们已经没有什么比如租金的条件限制，还有同样重要的盈利部分来自于原先并不受重视的商品的并集，这就是长尾效应。

Chris关于长尾的提出是基于他对娱乐市场的观察而得出的。通过对传统娱乐业和网络娱乐业的对比，Chris发现由于成本和规模的限制，传统娱乐业只能覆盖那些20%的主流（Hits）而忽略了后面的尾巴（Misses）。但是，网络技术解决了这个问题，使得在保证收益的前提下，满足了更多消费者的需求。同时，Chris还指出，人们对主流的关注一方面是因为传统娱乐业自身经营的限制（不可能提供所有的选择），另一个重要的方面是因为人们并不知道自己需要的是什么。Chris指出，事实上每一个人的品位都会与主流有所偏离，并且当我们发现的越多，我们就越能体会到我们需要更多的选择。这样，现实的世界（Physical World）是一个短缺的世界。在这个基础上，Chris看到了Amazon，Vann-Adibé等网络书店和影像店的出现推翻了传统的认知，他们可以以较低的成本去提供更多的选择，这样，当人们越多越多的关注那些被遗忘的事物，他们会发现自己可以有更多的选择。而如果互联网商家能够捕捉的这些被遗忘的角落，就会有比主流市场更大的市场。这就是所谓的长尾。

Chris认为，只要存储和流通的渠道足够大，需求不旺或销量不佳的产品共同占据的市场份额就可以和那些数量不多的热卖品所占据的市场份额相匹敌甚至更大。长尾理论对二八法则的挑战在于，80%的非主流元素形成的“长尾”不是仅占20%的份额，而是更多，可能达到甚至超过50%。

Google是一个最典型的“长尾”公司，其成长历程就是把广告商和出版商的“长尾”商业化的过程。数以百万计的小企业和个人，此前他们从未打过广告，或从没大规模地打过广告。他们小得让广告商不屑一顾，甚至连他们自己都不曾想过可以打广告。但Google的AdSense把广告这一门槛降下来了：广告不再高不可攀，它是自助的，价廉的，谁都可以做的；另一方面，对成千上万的Blog站点和小规模的商业网站来说，在自己的站点放上广告已成举手之劳。Google目前有一半的生意来自这些小网站而不是搜索结果中放置的广告。数以百万计的中小企业代表了一个巨大的长尾广告市场。这条长尾能有多长，恐怕谁也无法预知。无数的小数积累在一起就是一个不可估量的大数，无数的小生意集合在一起就是一个不可限量的大市场。

亚马逊是又一个成功的“长尾”公司。亚马逊网上书店成千上万的商品书中，一小部分畅销书占据总销量的一半，而另外绝大部门的书虽说个别销量小，但凭借其种类的繁多积少成多，占据了总销量的另一半。一个前亚马逊公司员工精辟地概述了公司的“长尾”本质：现在我们所卖的那些过去根本卖不动的书比我们现在所卖的那些过去可以卖得动的书多得多。

对于如何抓住长尾市场，Chris提出了三项法则：
　　1、让所有的东西都可以获得。（Make everything available.）
　　2、将价格减半，现在让它更低。（Cut the price in half. Now lower it.）
　　3、帮我找到它！（Help me find it!）

另外，多线程中总有少数几个线程特别慢的情况，我猜也可以叫长尾效应。

5，dump

1，当我们把dump译为"转储"时,总是指"把内存中的内容复制到其它存储设备上",

2，而实际使用dump时,并非一律如此,有时dump就是copy(复制)的意思。

3，另外，在linux中，dump也是一个单独的命令。dump为备份工具程序，可将目录或整个文件系统备份至指定的设备，或备份成一个大文件。

7，kick off

在美国企业，kick off 指的是项目启动。

8，代码重构

重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。　也许有人会问，为什么不在项目开始时多花些时间把设计做好，而要以后花时间来重构呢？要知道一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控，而无法知道每个细枝末节，其次永远不变的就是变化，提出需求的用户往往要在软件成型后，始才开始"品头论足"，系统设计人员毕竟不是先知先觉的神仙，功能的变化导致设计的调整再所难免。所以"测试为先，持续重构"作为良好开发习惯被越来越多的人所采纳，测试和重构像黄河的护堤，成为保证软件质量的法宝。

9，hack代码

顾名思义是修改的意思，修改开源的代码，出处大概是：黑客入侵他人网站后，常会篡改网页内容，为了玩笑或者提高知名度，往往会留下 Hacked by xxx 之类的字样。

10，原型系统

使用原型的原型化方法特别适用于需求不确定性较高的软件系统的开发。它的基本思想是根据用户给出的基本需求，通过快速实现构造出一个小型的可执行的模型，满足用户的基本要求，这就是系统界面原型。让用户计算机上实际运行这个用户界面原型，在试用的过程中得到亲身感受和受到启发，做出反应和评价，提出同意什么和不同意什么。然后开发者根据用户的意见对原型加以改进。
广义来理解，当前系统的原始形态，这里不一定就是信息系统，非信息化的系统也有原型
狭义来理解，原型特指系统生命期开始阶段建立的，可运行的最小化系统模型
软件开发过程就是分析系统原型，建立系统模型，再优化转换的过程

11，codegen

编译原理中的代码生成环节。也可指模式化（模板）的产生代码

12，hook技术

钩子(Hook)，是Windows消息处理机制的一个平台,应用程序可以在上面设置子程以监视指定窗口的某种消息，而且所监视的窗口可以是其他进程所创建的。当消息到达后，在目标窗口处理函数之前处理它。钩子机制允许应用程序截获处理window消息或特定事件。
钩子实际上是一个处理消息的程序段，通过系统调用，把它挂入系统。每当特定的消息发出，在没有到达目的窗口前，钩子程序就先捕获该消息，亦即钩子函数先得到控制权。这时钩子函数即可以加工处理（改变）该消息，也可以不作处理而继续传递该消息，还可以强制结束消息的传递。

13，mock测试

就是在测试过程中，对于某些不容易构造或者 不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。

14，脏数据

脏数据是指源系统中的数据不在给定的范围内或对于实际业务毫无意义，或是数据格式非法，以及在源系统中存在不规范的编码和含糊的业务逻辑。如在常见的数据挖掘工作中，脏数据是指不完整、含噪声、不一致的数据。

15，压力测试

软件压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。软件压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行软件压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽。

16，增量全量

全量数据就是表中所有的数据，增量数据是上次导出之后的新数据。

17，SNAPSHOT

当前代码或存储的一个快照（备份）。

18，数据持久化

持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。

19，Hot Fix

Hotfix是针对某一个具体的系统漏洞或安全问题而发布的专门解决该漏洞或安全问题的小程序，通常称为修补程序。
Hotfix是那些无法等待下一个内容就需要马上修正的一些内容；patch就是补丁程序,是对原程序的一些修改和补充。
通常情况下你可以理解为一个概念,非要细分的话,hotfix更急一点,并且总是bug修改一类,而PATCH可以不是修正bug而仅仅是提高/增加功能。

20，Code Freeze

当P5之前的BUG都被修复了，这时离产品发布日期也就不远了，一般是2个星期后就能release产品，这时要对VSS中的代码进行freeze，以保证代码库的稳定性。Code freeze阶段一般会把各开发人员的check in和check out的权限关闭，若在这时仍有BUG报告上来并经讨论确定是重大的且必须在本版本中fix的，则需要经管理层同意并特殊地授予权限，在修改完成后修改者要把修改了哪些文件，影响了哪些文档等信息上报给各部门如QA、build人员、文档编写者等。在code freeze阶段，测试部门在紧张地进行着各种测试，得出各种数据，并决定本版本是否可以release了。

21，极限存储

极限存储的应用场景比较特别，主要是海量数据存储的原因：前端交易系统、商品中心、用户中心等出于效率的考虑，不会长期保存大量历史数据，而数据平台作为企业数据分析及挖掘的基础设施，天生具有保存历史数据的职责，非但如此，如何快速、高效的获取历史上任意一天的快照数据也成为设计历史数据存放方式时的重要考量。例如淘宝每天的业务数据：

典型操作【典型数据库增删改操作】主要包括:

1，新增商品/订单(new) 

2，商品/订单状态变更(update) 

3，商品下线/订单撤销(delete)。

数据特点主要是：

1，有业务主键，确保记录唯一性 

2，全量快照数据量巨大(>1TB)，数据分析需要全量快照数据 

3，每日变更量占比很少(远低于5%) 

4，数据记录冗余度非常高【注:变更指发生增删改的记录】

增量存储的缺点：

1，访问快照数据成本太高
2，无法直接反应删除/被变更数据，需要额外设计
3，应用改造成本较高
因此，尽管增量存储是数据库中备份的一般方法，但是实际中对于访问快照太慢，故不采用。但如果全量存储，又很显然的浪费了存储空间，因此这里采用极限存储来压缩存储空间，并维持访问快照的速度。

举个最简单的例子，比如有一张表，它有4个字段: 用户注册日期, 编号，姓名，地址。该表5月1日的记录如下：当我们全量同步这张表的时候，则5月1日的分区中存在8条记录：

用户注册日期	编号	姓名	地址
5月1日	001	张三	西湖区
5月1日	002	李四	西湖区
5月1日	003	王五	上城区
5月1日	004	张1	下城区
5月1日	005	王1	西湖区
5月1日	006	王2	西湖区
5月1日	007	王3	上城区
5月1日	008	王4	下城区

该表5月2日的记录如下：当我们全量同步这张表的时候，则5月2日的分区中存在10条记录：

用户注册日期	编号	姓名	地址
5月1日	001	张三	西湖区
5月1日	002	李四	西湖区
5月1日	003	王五	下城区（王五搬到了下城区）
5月1日	004	张1	下城区
5月1日	005	王1	西湖区
5月1日	006	王2	西湖区
5月1日	007	王3	上城区
5月1日	008	王4	下城区
5月2日	009	张2	上城区
5月2日	010	张3	下城区

该表5月3日的记录如下：当我们全量同步这张表的时候，则5月3日的分区中存在12条记录：

用户注册日期	编号	姓名	地址
5月1日	001	张三	上城区(张三这个人搬家了，因此地址变换了)
5月1日	002	李四	西湖区
5月1日	003	王五	下城区
5月1日	004	张1	下城区
5月1日	005	王1	西湖区
5月1日	006	王2	西湖区
5月1日	007	王3	上城区
5月1日	008	王4	下城区
5月2日	009	张2	上城区
5月2日	010	张3	下城区
5月3日	011	张4	上城区
5月3日	012	张5	下城区

数据仓库中的数据，存放的是反应历史变化情况的快照数据，一般一旦数据进入数据仓库，都会保留相当长的一段时间。因此当一些大表，而且每天增长量又相当大的情况下，传统的存储方式就会占用相当大的存储空间。（我们不能只保留最近一份全量数据，把之前的都删除，这样就不能反应历史情况了。）

就比如上面这个例子中，5月1号的数据存放了8条记录；5月2号的数据存放了10条记录，5月3号的数据，存放了12条记录，而且随着时间的推移，每天的全量数据将不断的增加。为了解决这个存储问题，于是就引发了一个思考：如何才能节约存储空间，而又能反应数据的历史情况？

我们看一下上面3天的记录数，其实一共就是从编号001到012的12个人的记录，其中张三和王五因为搬家变更了一次地址。如果我们给记录加上一个生命期的概念，那么就能达到既节约存储空间，又能反应数据历史变化情况的效果了。

用户注册日期	编号	姓名	地址	Begin_date	End_date
5月1日	001	张三	西湖区	2011-05-01	2011-05-02
5月1日	001	张三	上城区	2011-05-03	2011-05-03
5月1日	002	李四	西湖区	2011-05-01	2011-05-03
5月1日	003	王五	上城区	2011-05-01	2011-05-01
5月1日	003	王五	下城区	2011-05-02	2011-05-03
5月1日	004	张1	下城区	2011-05-01	2011-05-03
5月1日	005	王1	西湖区	2011-05-01	2011-05-03
5月1日	006	王2	西湖区	2011-05-01	2011-05-03
5月1日	007	王3	上城区	2011-05-01	2011-05-03
5月1日	008	王4	下城区	2011-05-01	2011-05-03
5月2日	009	张2	上城区	2011-05-02	2011-05-03
5月2日	010	张3	下城区	2011-05-02	2011-05-03
5月3日	011	张4	上城区	2011-05-03	2011-05-03
5月3日	012	张5	下城区	2011-05-03	2011-05-03

如上图，如果将数据存储成以上形式。那么总记录条数减少到了14条。而真实的表，字段要远远比上面例子中的多，每天的记录也远远比例子中的多，所以使用该存储优化方案带来的效果将非常明显。

如果要查询5月2号分区的数据，SQL也非常容易写：Select *  from  table where  begin_date<=’2011-05-02’and end_date>=’2011-05-02’;

重复存储是最大的浪费，极限存储方案就是为了解决因为重复存储造成存储空间浪费的问题的。

极限存储的适用场景：

1，针对很大很大的表

2，业务上不允许删除历史快照信息。

3，表的数据变化较小（表数据肯定是有变化的，但是表的数据相对比较稳定，不变的数据较多），如用户表，商品表，成交表，订单表等等等等。

极限存储的一个总体思想就是通过给表记录设定生命周期的方式，减少重复存储的那些记录。所以当满足以上场景的情况下，表越大，极限存储带来的效果越是明显。

22，PV（浏览量）,UV（访客数）,IP（独立IP）

PV(访问量)，即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。或者说一个访问者在00:00-24:00内到底看了你网站几个页面。

UV(独立访客)，即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。

IP(独立IP)：即Internet Protocol,指独立IP数。00:00-24:00内相同IP地址之被计算一次。

技术普及帖：你刚才在淘宝上买了一件东西 

摘要如下：

网址www.taobao.com转换成ip地址：通过DNS解析域名时将你的访问分配到不同的入口。淘宝网全网在平日（非促销期间）的PV大概是16-25亿之间。仅用于生成www.taobao.com首页的服务器就可能有成百上千台。最关键的便是LVS(Linux Virtual Server)，世界上最流行的负载均衡系统之一，正是由目前在淘宝网供职的章文嵩博士开发的。访问淘宝网首页需要加载126个资源，那么如此小的并发连接数自然会加载很久。所以前端开发人员往往会将上述这些资源文件分布在好多个域名下，变相的绕过浏览器的这个限制。在双十一当天高峰，淘宝的访问流量最巅峰达到871GB/S。这些访问流量不可能集中在一起。这便是CDN(Content Delivery Network)，即内容分发网络的作用。淘宝在全国各地建立了数十上百个CDN节点，利用一些手段保证你访问的（这里主要指js、css、图片等）地方是离你最近的CDN节点，这样便保证了大流量分散在各地访问的加速节点上。淘宝网如何保证全国各地的CDN节点中都会同步的存在这几张图 片供用户使用呢？这里边就涉及到了大量的内容分发与同步的相关技术。淘宝开发了分布式文件系统TFS(Taobao File System)来处理这类问题。对于每年数十上百亿比交易的商品详情快照进行保存和快速调用不是一个简单的事情。这 其中又涉及到数套系统的共同协作，其中较为重要的是Tair，淘宝自行研发的分布式KV存储方案。分布式系统的日志记录都非常庞大，达到TB级别非常正常。那么为了快速及时 传输同步这些日志数据，淘宝研发了TimeTunnel，用于进行实时的数据传输，交给后端系统进行计算报表等操作。你的浏览数据、交易数据以及其它很多很多的数据记录均会被保留下来。使得淘宝存储的历史数据轻而易举的便达到了十数甚至更多个 PB(1PB=1024TB=1048576GB)。如此巨大的数据量经过淘宝系统1:120的极限压缩存储在淘宝的数据仓库中。并且通过一个叫做云梯的，由2000多台服务器组成的超大规模数据系统不断的进行分析和挖掘。

淘宝技术发展

这两篇有点意思哈。

23，sql注入

例如输入：'or 1='1

对于后台，若SQL写的就是：

select * from login where username='"+name+"' and password='"+pw+"'

则name，password装入后，即变成了：

select * from login where username=''or 1='1' and password=''or 1='1'

24，hadoop和mapreduce

hadoop是google的云计算系统的开源实现。
谷歌集群系统主要包括三个部分：分布式文件系统GFS，分布式并行计算模型map/reduce，以及分布式数据库Bigtable；
hadoop也实现了这三个，GFS对应HDFS，hadoop的map/reduce对应谷歌的map/reduce模型，Hbase对应Bigtable。

2 游戏名词解释

1，私服

未经版权拥有者授权，非法获得服务器端安装程序之后设立的网络服务器，本质上属于网络盗版，而盗版的结果是直接分流了运营商的利润。相对于官服而言未经版权拥有者授权，以不正当手段获得游戏服务器端安装程序之后设立的网络服务器，它属于网络盗版的一种，是侵害著作权的行为。

2，网络游戏测试

2.1 封测

封测，即封闭测试。是指一款游戏在开发完成的前期由游戏公司人员或少量玩家参与的游戏测试，是游戏的最初测试，以技术性测试为主。很多游戏公司为了节省经费开支，会通过不同的平台对外发放少量的封测账号，供部分玩家试玩来寻找BUG。经过极少数的玩家的测试后向游戏公司反馈BUG以及存在的问题。封测结束后，一般会进入内测、压测、公测。

2.2 内测

内测，即alpha测试。通俗的说就是内部测试程序错误的阶段，一般都是开发人员记录测试情况，以便对程序进行完善。内测在这三个阶段中,是时间最长的,少则几周,多则数月,这个阶段的测试至关重要。所有的关于游戏的技术问题,以及关于游戏的故事,角色,风格服饰,语言,动作,主,支线任务的合理性等等诸多方面的测试和评估,乃至最后的修改，都是在内测时进行的，因而内测时游戏改动比较大。内测也分为封闭性内测与开放性内测，封闭性内测仅仅是开发、运营、代理商参与，而开放性内测会有更多相关人员参与进来。

2.3 公测

公测，即bata测试，是使用者单独进行的测试，一般是游戏正式运营前最后的测试。公测也就是公开测试，让大家都来参与测试程序的稳定和缺陷。到了公测阶段,就会有相当一部分玩家参与进来,这个时候,游戏已经基本定型，也就是处于正式推出的最后阶段的测试。实际上就是听取玩家的意见和反馈,以便为今后纠正错误做统计和准备,纠正错误的方式一般采取出补丁的方式。