本文转自gamerboom.com

游戏邦注：本文原作者是Andrew Andreas Grapsas，他曾经在美国第三大游戏制作发行商THQ的Kaos工作室任游戏设置与动画程序师，还曾作为助理系统程序员参与《荣誉勋章》的制作。目前在主攻Facebook游戏的Arkadium公司从事游戏编程工作，此外还参与各种项目的编写和编程。

真相

你已经在这个行业捉摸滚打好几年了，难免感到灰心丧气。所以你从一盆滚烫的水盆跳到另一盆，只为追寻那个完美的梦想。每一次你选择离开，任凭你的老板在风中凌乱、震惊、恍惚。或者，他们也许会有抑止不住伤感的时候。尽管如此，他们还是会向你暗示：他们并不在乎你。

那些留住你的人，那些与你并肩作战的伙计姑娘们，希望打造一款“了不起”的游戏、攻克最终的难题、把产品推向市场。但是，一个又一个，他们走了。沮丧的你再也无法让自己的手指安然地在键盘上敲打。你只能顺其自然。终于有一天，内心那个“太多”终于突破底线了，你开始觉得自己像只被掏空的南瓜。

Quit job(from pongoresume.com)

放弃

我只能说这是一段轶事；但作为一个游戏开发者，我已经目睹了许多朋友和前辈走上两条路：独立游戏制作人或离开游戏行业。开发人越是年轻，越是可能走上这两条路之一。对于工程师就更是如此了。

我明白独立的诱人之处。

但是，为什么离开游戏行业？我们先问一个简单的问题：为什么不进入游戏行业？

我教授关于游戏引擎构建的毕业生课程时，遇到的大多数优秀的程序师不是委身于小工作室就是沦为软件公司中的怪人。这其中存在一些巨大的激励因素和决定性因素。请继续读下去，我将一一道来。

水管工和水管

当我提到水管工时，你想到了什么？一个穿工装裤的家伙，顺着梯子溜进一个大得能容下一张沙发的裂缝里，可能是这样的吧？肯定不是一个文质彬彬、光彩照人、才华横溢的先生。肯定不是！

想一想你单位里的机修师。想一想你和他们的交往。你（或你所在公司的其他人）是不是把他们当成水管工来看待？“啊，坏了，修好它。”你是不是想都没想过任务有多难、有多重要，就指派他们去做？他们有完整的时间吗？他们有没有时间来声明自己的工作？或者，他们是不是不断地把头发从U型管中挑出来？你最后一次让他们坐下来谈想法是什么时候？

软件工程师不是水管工。

看一看开源群体。一定程度上，开源的存在是为了排遣“垂头丧气”——无法实现创意自由的受挫感。创意含有勇气和好奇的成份。你是不是将工程师的创造力发挥到极致了呢？或者，你差遣他们是不是像命令水管工来修理积水的厕所？

以开发为中心的公司很容易错失软件领域中最优秀的编程人才。这是为什么？他们怎么会这样？相反的，小公司看似拥有不可思议的挖掘人才的能力，而且能够留住这些有才干的程序员好一阵子？怎么会？其他企业要怎么才能做到这一步？

招聘不易

我拒绝了许多公司。为什么？好吧，他们的环境不太吸引我，或者我遇到不喜欢的经理人。更差一点，办公地点太恶劣。这些公司为了聘用我投入了多少成本？好吧，他们花时间安排初次面试和二次面试——这些可是从开发商的日程表上挤出来的宝贵时间啊；另外，他们还在中介机构和广告上撒了些钱。雇用一个人真是一笔大投入啊。如果他们想雇我，我却说不，那对他们来说真是一笔大损失啊。

另一方面，要相中一个合适的人也非常困难。你必须找那些符合公司规章制度（游戏邦注：包括待遇、工着装、社交环境、项目等等）的人；同时，这些人还得有能力完成必要的任务，最重要的是，效率要高。

我们不是车

你买车时，你会讨价还价。值得一试，对吧？无论你能支付代理商多少钱让他脱手，那车的功能和运作情况都是一样的。

你为什么和开发商杀价？你为什么对他们隐瞒曾经那段最好的“经验”？

一个低工资、少福利的开发人，另一个不担心薪水、不担心福利、不担心任何其他外部因素的开发人，这二者是不能比的。

警告：我不是在主张高薪。超过某个门槛的工资并不能刺激员工多干活。当然，我说的“门槛”是指可以让他们满意的薪水。如果你不知道这个门槛，那就瞄高一点吧！最差的情况是什么？你多付给开发人几千块，他们就会开心吗？

如果你支付给开发人的薪水不够，又会发生什么最恶劣的情况？甩手走人。这就是严峻的后果。

体育团队积极地征招最优秀最闪亮的成员，几乎是不择手段地吸引他们归队。为了招徕工程师、设计师和美工，你做了什么？你的工作环境怎样？拥挤吗？光线够吗？福利又怎么样？是不是可以让开发人不必担心？

一般来说你的开发人对生活、工作等方方面面有什么忧虑？

车不会担心。但开发人员会。焦虑中的开发人不仅表现差，而且压抑的情绪累积到一定程度，他们终于找到解脱的办法——离开。

沉默是“金”

许多开发人对于自己的需求都沉默不语。本来就是这样。你能多积极地探究自己的需要？你对解决自己的问题有多投入？水管工？水管工？谁是水管工？

在一次年终回顾上，有人曾经这么对我说：“呃，你本应该提醒我们你想加薪！”我加入公司时曾定下一个口头协议，如果我表现良好，他们就会在一年以内支付与另一家公司相同的高薪。看来这人是告诉我，我早该让他们意识到这个事实。我是来当工程师的，难道我还得像谈生意一样跟他们讨价还价？作为工程师，编程才是我关心的事。

你得关心的是剩下的部分。

“我们做游戏！”

这个故事的寓意：

你告诉开发人员你是做游戏的，这样就能挽留他们的吗？你相信这样就足以留下他们？

你猜会怎样？其他人也做游戏啊！

没你，我们照样能做游戏！

大部分程序员在童年时期就深深地迷恋上某些游戏了。这就是为什么我们选择留在这个行业里，这就是为什么我们喜欢从事游戏。

然而，如果程序员的待遇就和随叫随到的水管工相当；如果没经过真正的投资，就要求程序员解决问题；如果还没建立管道系统，就要求程序员治理阻塞；如果没有合适的激励体系，水管工式的程序员能停留多久？

在你的公司运作中，程序员到底占了多重的份量？

“数百万人会玩这款游戏！”如果这个世界上没有数十亿万，那也有数百万的管道垫圈。我是愿意设计保时捷？还是处理垫圈？

“自由！”

独立本身是很吸引人的。美国人先祖感悟到了自由的力量，然后利用这个理念鼓励人民勇敢地挣脱比自己更强大的敌人。游戏开发人也很快就领悟到，我们靠自己也能飞黄腾达。

这对工程师来说，实在是至理。我们掌握了过硬的技术，我们有能力制作出独一无二的好系统。我们是软件的基础关键。没有我们，哪有软件！

随着移动领域的崛起，xbox接纳了独立游戏人，PC游戏借助数字化分布重燃希望之火，你又怎么能让我们为“你的项目”打拼？你拿什么留住我们？

当然有，安全感！但是，到现就只有这个是吗？另外，一个工程师当然可能为了稳定而留下来，但你真的能让他们为你鞠躬尽瘁，死而后已？你为什么老是给你的开发人员使绊？工程师靠创意起家。一旦创意的路途被堵了，这些人就不可能好好表现。

开发人员

作为开发人员，我有选择。我想在一个把自己当成水管工的公司工作，不断地被使唤吗？我想在一个把我的项目牢牢揣在他们手里的公司做事吗？这是一个非常传统的模式。工程师被指派工作做，就像在学样做各门各科的作业。

当你解放这些“囚犯”时又会怎么样呢？

问问Valve（美国软件公司）。

以开发人员为中心和工作室应该是近义词。在大多数工作室里，权力分配是平等的，或向工程师倾斜。为什么会这样？首先，这里几乎不存在领导和投资个体；再者，在小团队的软件系统里，几乎不可能有人能代替工程师，对吧？想想看，他们有程序代码啊。他们是唯一能接触程序代码的开发人。他们理解程序代码的运作。你怎么能替换他们？所以，他们往往手握重权。

控制权是诱人的。

还有，小团队里可能有许多欢庆会，对吧？就算没什么特别含义的欢庆会也好。“我们第一个人物移穿过场景了！！！干杯！”

这个过程就是：

挑战–> 主动权 –> 获得认可。

结语

好吧，我写的有点像满腹怨言的“咆哮体”了；但是，我希望你明白我的主要意思。工程师不应该被视为商品，而应该是公司的强大投资。一个优秀的工程师可以给公司创造莫大的价值；但请扪心自问，你为工程师本人及其生活增加什么价值了吗？

我想，你要问的不是工程师能为你的公司做什么，而是你的公司能为工程师做什么

软件测试的分类和技术多种多样，对于测试技术可以从不同角度进行分类：

• 从是否需要执行被测试软件的角度，可以分为静态测试和动态测试。
• 从测试是否是针对系统的内部结构和具体实现算法分类可分为白盒测试和黑盒测试。
• 按照测试的对象分类（web，client，server，database），设计面向开发的单元测试、GUI和捕获/回放测试，基于web的应用测试，C/C++.JAVA应用测试，负载和性能测试，数据库测试，软件测试和QA管理等各类工具的测试。
• 其它测试方法，如回归测试、压力测试、恢复测试、安全测试和兼容性测试等。

也可以从另外角度来划分测试阶段：面向测试操作类型的阶段划分、面向测试操作对象的阶段划分、面向测试实施者的阶段划分。

• 测试操作类型包括调试、集成、确认、验证、组装、验收、操作等
• 测试操作对象可以是单元、部件、配置项、子系统、系统等
• 测试实施者可以是开发者、测试者、使用者、验收者等

测试的分类

软件测试可以分别按测试范围、测试目的、测试对象、测试过程分类。

   1.按照测试范围分

• 单元测试（unit testing）
• 组件测试（component testing）
• 集成测试（integration testing，string testing）
• 系统测试（system testing）
• 验收测试（acceptance testing，beta testing）
• 安装测试（installation testing）

   2.按照测试的目的分

 

软件公司对软件缺陷级别的定义不尽相同，一般可以分为4种：

1. 致命（fatal）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失
2. 严重（critical）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明
3. 一般的（major）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等
4. 微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等

除了严重性外，还要反映软件缺陷处于一种什么样的状态，便于跟踪管理，这样就定义了不同的bug状态。

1. 激活状态（open）：问题还没有解决，测试人员新报的bug，或者验证后依然存在。
2. 已修复状态（fixed或resoveled）：开发人员针对所存在的缺陷，修改程序，认为已解决或者通过单元测试。
3. 关闭或非激活状态（close）：测试人员验证fixed bug后，确认bug不存在了，需要关闭。

此外还要根据软件版本来提交bug，单服测试中的bug，或者alph测试中的bug，亦或者beta测试中的bug。如果能够定位bug出现的相关功能模块，特别是定位到改模块的某个文件那就更好了，不过一般不要求测试人员去定位bug，为的是不误导程序修改bug。目前也并不是所有的测试人员都能够接触到源代码。一般的测试都是基于黑盒的测试。

质量是什么？

先验论:质量是产品的一种可以认识但不可以定义的性质

用户角度：质量是产品满足用户使用目的的程度

制造者的观点：质量是产品性能符合规格要求的程度

产品观点：质量是联结产品故有性能的纽带

基于价值观点：质量依赖于顾客愿意付给产品报酬的数量

质量所关联的另外一个概念就是“客户”，质量和客户息息相关，两者相对而存在。对客户的定义至少存在两种范畴——内部和外部：

外部的客户是产品的实际使用者或者服务对象，是传统意义上大家认可的客户。

内部的客户是更为广泛意义上的客户，客户可以被理解为下一道工序的接受者。这样，在软件生产的环节中有关的人员都可以被定义为这一类的客户，软件的设计者是需求分析人员的客户，编程人员是设计者的客户，软件测试者是编程人员的客户。

软件质量由3部分组成：

1. 软件产品的质量，即满足使用要求的程度
2. 软件开发过程的质量，即能否满足开发所带来的成本、时间和风险等要求
3. 应用领域或业务上的质量

高品质软件是相对的无产品缺陷（bug free）或者只有少量缺陷，它能够准时的交给客户，所花费也都在预算内，并且满足客户需求，是可维护的。但是有关质量好坏的评价依赖与客户的反馈。

软件质量有3A特性：accoutability（可说明性）、availability（有效性）、accessibility（易用性）

1. 可说明性：用户可以基于产品或服务的描述和定义（如：市场需求说明书、功能设计说明书）加以使用
2. 有效性：产品或服务对于客户的需求是否能够保持有效，如具有99.99%有效性，可以说达到质量要求。
3. 易用性：对于用户，产品或服务非常容易使用并且一定是非常有用的功能（例如确认测试和用户可用性测试）

在rational unified process中，质量被定义为具有以下三个维度：

1. 功能（对应可说明性）：按照既定意图和要求，执行指定用例的能力。
2. 可靠性（有效性）：软件坚固性和可靠性（防故障能力，如防止崩溃、内存丢失等能力）、资源利用率、代码完整性以及技术兼容性等。
3. 性能（易用性）：测试对象的及时配置文件和操作特征。及时配置文件包括与作业负载相关的执行流、数据访问、函数调用和系统调用。性能的操作特征包括与作业负载相关的特征，如相应时间、操作可靠性、以及与操作限制相关的特证，如负载容量或者强度。

产品质量

1. 功能性（functionality）：软件所实现的功能达到它的设计规范和满足客户的需求的程度。
2. 可用性（usability）：对于一个软件，用户学习、操作、准备输入和理解输出所做的努力的程度，如安装简单方便，容易使用；界面友好，并能适用于不同特点的用户，包括对残疾人、有缺陷的人能够提供产品的使用的有效途径和手段。
3. 可靠性（reliability）：是用户使用的根本。在规定的时间和条件下，软件所能维持其正常的功能操作、性能水平的程度。
4. 性能（performance）：在指定条件下，用软件实现某种功能所需的计算机资源（包括内存大小、cpu占用时间等）的有效程度
5. 容量（capacity）：系统的接受力、容纳或吸收的能力，或某项功能的最大量或最大限度，有时需要特定的需求所能容纳的最大量、所能表现的最大值如web能够承受多少并发用户访问、会议系统可以承受的与会人数等。
6. 可测量性（scalability）：系统某些性能可以通过一些量化的数据指标描述器当前状态或着理想状态。
7. 可维护性（service manageability）：在一个运行软件中，当环境改变或者软件产生错误时，进行相应修改所做努力的程度。
8. 兼容性（compatibility）：软件从一个计算机系统或者环境移植到另外一个系统或环境的容易程度，或者是一个系统和外部条件共同工作的容易程度。兼容性包括很多方面，如系统的软件和硬件的兼容性、不同版本的软件系统、数据的兼容性。
9. 可扩展性（extensibility）：指将来功能在呢更加系统扩充的难易程度或者能力。

过程质量

探索复杂系统开发过程的秩序，按一定规程工作，可以较合理的达到目标。规程由一系列活动组成，形成方法体系，建立严格的工程控制方法，要求每一个人都要遵守工程规范。目前主要流行的过程改进规范有以下：

1. 软件能力成熟度模型（CMM,Capability Maturity Model）。
2. 国际标准过程模型ISO9000。
3. 软件过程改进和能力决断（SPICE,Software process Improvement and Capability Enterminition）.

1. 软件下载
2. 服务器和客户端安装
3. 建立版本库（Repository）
4. 配置用户和权限
5. 运行独立服务器
6. 初始化导入
7. 基本客户端操作

1，软件下载
下载Subversion服务器程序。
到官方网站 的下载二进制安装文件，来到二进制包下载部分  ，找到 Windows NT, 2000, XP and 2003部分，然后选择"this directory"，这样我们可以看到许多下载的内容，目前可以下栽 svn-1.2.3-setup.exe。
下载Subversion的Windows客户端TortoiseSVN。
TortoiseSVN是扩展Windows Shell的一套工具，可以看作Windows资源管理器的插件，安装之后Windows就可以识别Subversion的工作目录。
官方网站是TortoiseSVN，下载方式和前面的svn服务器类似，在Download页面的我们选择Official version for Win2k/XP or higher的版本，然后在sourceforge的下载页面选择目前的最高稳定版本的安装文件TortoiseSVN-1.2.4.4479-svn-1.2.3.msi。

2，服务器和客户端安装

服务器安装，直接运行svn-1.2.3-setup.exe，根据提示安装即可，这样我们就有了一套服务器可以运行的环境。
安装TortoiseSVN，同样直接运行TortoiseSVN-1.2.4.4479-svn-1.2.3.msi按照提示安装即可，不过最后完成后会提示是否重启，其实重启只是使svn工作拷贝在windows中的特殊样式生效，与所有的实际功能无关，这里为了立刻看到好的效果，还是重新启动机器。

4，配置用户和权限

来到E:\svndemo\repository\conf目录，修改svnserve.conf：

# [general]
# password-db = passwd

改为：

[general]
password-db = passwd
然后修改同目录的passwd文件，去掉下面三行的注释：

# [users]
# harry = harryssecret
# sally = sallyssecret

最后变成：

[users]
harry = harryssecret
sally = sallyssecret


5，运行独立服务器

在任意目录下运行：

svnserve -d -r E:\svndemo\repository
我们的服务器程序就已经启动了。


6，初始化导入

来到我们想要导入的项目根目录，在这个例子里是E:\svndemo\initproject，目录下有一个readme.txt文件：

右键->TortoiseSVN->Import...
URL of repository输入“svn://localhost/trunk”
ok
完成之后目录没有任何变化，如果没有报错，数据就已经全部导入到了我们刚才定义的版本库中。


7，基本客户端操作

取出版本库到一个工作拷贝：

来到任意空目录下，在本例中是E:\svndemo\wc1，运行右键->Checkout，在URL of repository中输入svn://localhost/trunk，这样我们就得到了一份工作拷贝。

在工作拷贝中作出修改并提交：

打开readme.txt，作出修改，然后右键->Commit...，这样我们就把修改提交到了版本库，我们可以运行。

察看所作的修改：

readme.txt上右键->TortoiseSVN->Show Log，这样我们就可以看到我们对这个文件所有的提交。在版本1上右键->Compare with working copy，我们可以比较工作拷贝的文件和版本1的区别。

按照测试对象的结构分类可以分为：c/s结构系统测试、b/s结构系统测试、个人软件测试……

Client/Server软件测试

c/s结构的软件测试发生在三个不同的层次

• 个体的客户端应用以“分离的”模式被测试——不考虑服务器和底层网络的运行
• 客户端软件和关联的服务器段应用被一起测试，但网络运行不被明显的考虑
• 完成的C/S 体系结构，包括网络运行和性能，被测试。

C/S结构软件测试常用方法

• 应用功能测试——客户端应该被独立的执行，以揭示在其运行中的错误
• 服务器测试——测试服务器的协调和数据管理功能，也考虑服务器性能（整体反应时间和数据吞吐量）
• 数据库测试——测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证书具备正确的存储、更新和检索。
• 事务测试——创建一系列的测试以保证每类事务被按照要求处理。测试着重于处理的正确性，也关注性能的问题。
• 网络通信测试——这些测试验证网络节点间的通行正常的发生，并且消息传递、事务和相关的网络交通无错的发生。

Browse/Server软件测试

B/S结构软件测试需要关注：

• 基本功能测试
• 性能测试
• 浏览器兼容性测试
• 数据库测试
• 安全性测试
• 可用性易用性测试
• 链接测试
• 针对系统支持的协议的测试
• 等

补充点个人软件测试需要关注的内容：

• 基本功能测试
• 安装卸载测试
• 升级测试
• 兼容性测试
• 自我保护测试

这是个总结每一个相关的测试关注点都不是一句两句说得清楚，至少我知道现在针对不同的结构关注的内容都有哪些了？继续努力不断进步！加油！