反省：同级间工作态度评价

a和b是同级，数次合作后，a认为b的工作态度差，不负责任，导致了一些问题，给a（以及其它同事）的工作带来了一些阻碍。a对b形成了这样的一种“态度评价”后，对与b交互的工作更为挑剔，并在言行中表现出了这种评价。

1.a不应该表现出对b的态度评价。如果办不到，就是职场生存能力不足。

2.只有高一级的管理者才有资格随时进行态度评价。没有授权时，同级间的态度评价是越位。如果不承认该观点，就是对个人所处位置不明晰。

3.a对b的态度评价所依赖的信息是有限而片面的，态度评价的形成可能是随意非理性的；b的“真正工作态度”可能是另一种情况。如果不肯推翻重建对b的态度评价，就是不够理性，逻辑思维能力不足。

4.a对b的态度评价及随之而来在言行中体现的情绪，为a与b的继续合作制造了阻碍。如果a不能从合作共赢的角度放弃情绪化表现，就是合作意识不强。（-2009.05.13新增）

（事实，事实带来的态度，态度引起的情绪。2009.05.13新增）

每日一题：测试环境

通过搜索和资源整合，可获得如下信息：（文末有金大侠点评）
1.测试环境的定义
软件测试环境包括设计环境、实施环境和管理环境。本章讲述的是通常意义上的测试环境即测试的实施环境。

软件测试设计环境：编制测试计划/说明/报告及与测试有关的文件所基于的软件/硬件设备和支持。
在设计阶段根据客户的需求进行环境设计，当然期望测试环境无限接近于客户所需软件运行的真实环境，但实际上由于各种资源的限制，只能在近似的模拟环境中进行测试。

软件测试实施环境：对软件系统进行各级测试所基于的软件/硬件设备和支持。
测试实施环境包括被测软件的运行平台和用于各级测试的工具。实施环境必须尽可能地模拟真实环境，以期望能够测试出真实环境中的所有问题，同时也需要理想环境以便找出问题的真正原因。

软件测试管理环境：管理测试资源所基于的软件/硬件设备和支持。
广义的测试管理环境包含测试设计环境、测试实施环境和专门的测试管理工具。例如，对bug的跟踪、分析管理，对CASE的分类管理，对测试任务的分派、资源管理等。

2.测试环境是测试的基础
测试环境贯穿了测试的各个阶段，每个测试阶段中测试环境对测试影响是不一样的。
在测试的计划阶段，充分理解客户需求，掌握产品的基本特性有助于测试环境的设计，合理调度使用各种资源，申请获得未具备的资源，保证计划的顺利实施。如果在测试计划中规划了一个不正确的环境，直到实施的过程中才发现，浪费了大量的人力和物力取得一些无用的结果，即使只是遗漏了一些环境配置，如不能及时发现，及时申请购买或调用，也会影响整个项目的进度。在计划阶段，考虑周全很重要。
在单元测试和集成测试阶段，有部分测试工作是由开发人员完成的。开发人员的测试环境通常为开发环境，近似于理想环境。理想环境有利于代码的调试和分析，但测试结果不能视为真实结果。有这样一个例子，测试人员报告的bug在开发环境中无法重现，开发人员就在测试人员的测试环境中研究，原来是环境系统的设置不同造成的，此时测试人员就应该分析修改系统设置是否合理。如果合理，这就是一个很棒的解决方案，但要求用户手工修改系统设置，或不能识别用户的系统设置通常都是不合理的，这应该是个严重的bug。
在系统测试和验收测试阶段，测试环境必须模拟并最大限度地接近实际环境。测试人员在设计测试案例时就得写明测试环境，因为在不同的环境中预期的结果是不同的。

金大侠点评：
作为专业测试，必须保证测试环境的可控性。版本控制可以说是测试的基础。

每日一题：QA与QC的职责

通过搜索和整理，一般可得到如下答案：（点评在最后）
1、在项目初始阶段，编写测试计划
2、在策划案完成后，审查完后开始编写测试用例
3、随着策划案的更改，修改用例
4、游戏功能完成后，开始执行用例
5、反馈BUG
6、写测试报告
7、对BUG进行跟踪、复查

而查找相应的词条，可得如下信息：
QA即英文QUALITY ASSURANCE 的简称，中文意思是品质保证，其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足品质要求，而在品质管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关品质保证的职能，担任这类工作的人员就叫做QA人员。
无论是ISO9000还是CMMI，都是以过程为中心。也就是说，通过过程的持续改进来提高产品质量。而过程质量与产品质量如何正向关联呢？就需要质量保证（QA）。这也是ISO9000和 CMMI都很推崇的方法。但从国内软件企业的现状来看，很多企业的过程体系都相差无几，而开发出来的产品质量却千差万别。导致这种差别的原因有很多，过程及其执行方式的生搬硬套就是其中很重要的原因之一。

QC即英文QUALITY CONTROL的简称，中文意义是质量控制，其在ISO8402:1994的定义是“为达到质量要求所采取的作业技术和活动”。
产品经过检验后再出货是质量管理最基本的要求。质量控制是为了通过监视质量形成过程，消除质量环上所有阶段引起不合格或不满意效果的因素。以达到质量要求，获取经济效益，而采用的各种质量作业技术和活动。在企业领域，质量控制活动主要是企业内部的生产现场管理，它与有否合同无关，是指为达到和保持质量而进行控制的技术措施和管理措施方面的活动。质量检验从属于质量控制，是质量控制的重要活动。

金大侠点评：
说得挺多挺乱，是不是把具体的工作内容和职责搞混了？目的和手段要区分清楚，具体的工作是为了完成职责目标的手段。
职责其实很简单：协助团队完成一个质量合格的产品。其中包括：协助策划完善设计，协助程序完善代码，对产品做出质量评估作为领导层决策的依据。这是测试的，也就是QC的。
QA的职责是质量管理，改进和落实监督开发流程，从过程角度保证项目质量。

excel使用技巧（1）

在设计测试用例时所产生的需求，我找到了解决方法。它们是2点工具使用技巧：

a）一个公式需要引用多个表格的数据，然后下拉使得其它表格沿用该公式，希望有的表格数据可以自行变化而另外一些表格数据不变；处理方法是在不变的表格数据的字母和数字前各加一个$。如图：

b）操作项需要在已有的选项序列选取，可在本子表中添加待选项列，将待操作的操作项范围进行设置“数据”-“有效性”，允许“序列”，并选中选项序列数据区域。点击设置好后的表格，表现如图：

新名词（1）

1.DNS
域名系统。Domain Name Sever的简写。域名与ip之间的转换工作，称为域名解析。域名解析需要专门的域名解析服务器来完成，DNS就是进行域名解析的服务器。（百度百科）

2.Add-on 资料片

3.db
数据库。data base的简写。

4.耦合度
模块与模块之间联系的紧密程度。

5.安全沙箱
即为沙箱。现实中的沙箱，是一种儿童玩具，类如KFC中一个装满小球的容器，儿童可以在随意玩耍，起到保护儿童的作用。也可以理解为一种安全环境。

沙箱技术：Sandboxie是一款专业的虚拟类软件，它的工作原理：通过重定向技术，把程序生成和修改的文件，定向到自身文件夹中。当然，这些数据的变更，包括注册表和一些系统的核心数据。通过加载自身的驱动来保护底层数据，属于驱动级别的保护。（百度百科）

6.UCH
UCenter Home 是一套采用PHP+MYSQL构建的社会化网络软件（Social Network Software，简称SNS）。

《狼图腾》与《浮沉》

1.姜戎《狼图腾》
作者的确是有点偏激，但那种时代环境能不让人偏激么。
大到自然环境，小到人的生理、心理在合适的范围内都是有让人惊叹的自愈、循环能力的。
过犹不及。

2.京城洛神《浮沉》
作者讲故事的能力真好，不愧是中文系出身并在职场中历练了些年的，情节悬念和人物塑造都值得学习——从小说写作的角度看。
我很认可序言所说的、换个说法：它展现你暗的一面，但仍把你往光的方向引导。
这是一部互联网的职场小说，对小虾米着墨不多，几个老板的智慧很让人开眼。

游戏设计有无技术可言？

策划做设计，有技术可言吗？有多少技术呢？

技术是说，可较为广泛的传授，如有缺失可补习；对达不到设计理念的，可通过技术的反复练习来提高对理念的掌握能力。

策划们会说：嘿，来我们开个座谈会，谈谈自己做设计上的一些新发现～除了那些理论、结论、推论、假设，他们会谈论怎样具体的设计方法吗？

技术，或者说，设计技巧，其实是有的，只是我所了解的很少。我当了一年多QC，我发现QC有很多技术可言；但今天我搞不明白了，策划的技术在哪儿呢？

我今天还想了另外一个问题，就是关于设计：有高人总结的几个那么短小精悍的词，是怎么总结出来的；他又是怎么运用他的结论的？

结论的获得可能是有逻辑的，假如对结论的运用具备了理性，就是技术。

做游戏设计，理念似乎是从来不缺的。缺少的是技术，——把结论化为实现技巧的技术。

我想做这方面的尝试和修炼。

如何对待自己所作的结论

作结论的时候，不要把结论的适用范围人为扩大。要放在所参照的信息笼罩范围内。

可以做大范围的假设，但不把假设当作又一个定理。

结论的获得可能是逻辑严密的，但在运用上若放弃了理性，则不若没有这个结论。

设计者可以放任自己在适当时候充分接受灵感的冲击，但在最后一刻仍然需要再次拥抱逻辑严密的理性思维方式。

软件测试易混淆概念区分

手工测试与自动化测试
手工测试是指执行测试采用的是手工；自动化测试是指QC根据程序开放的接口，编写和运行脚本来执行测试，或者利用现有的工具如LR等录制回放。自动化测试执行过程中，通常是无人值守。

黑盒测试与白盒测试
黑盒测试是指知道测试输入和测试输出，但不去了解内部实现过程；白盒测试是指，直接了解内部实现过程。

以上2组概念常被混淆：黑盒测试被等当作手工测试，白盒测试被当作自动化测试；尤其是后者被混淆的程度更大，这可能与2者都有“代码”在其中参与有关。
需要强调的是，自动化测试是测试员编写代码，用来跑测试用例；而白盒测试则是指直接对程序员所写的代码进行测试，执行者可以是程序员，也可以是QC。 比如：编写代码对程序员所写的代码进行静态分析，是采用了自动化测试的方法执行白盒测试。

静态测试与动态测试
这组概念通常运用于白盒测试领域。其区别在于是否把被测代码运行起来，不运行就是静态测试，运行就是动态测试。

（以上概念区分源于个人理解，更规范而全面的释义请自行搜索。）

手工测试没有技术含量？

首先说明，手工测试不等于黑盒测试。

结论：手工测试当然是有技术含量的，而且还很高。

手工测试和自动化测试的关系：
手工测试是自动化测试的基础。

手工测试和自动化测试的效果：
80%以上的bug是手工测试发现的--这是无法否认的权威数据。

手工测试和自动化测试的应用范围：
自动测试的比例在软件行业最高也不超过50%的比例。手工测试应用最广泛，只能自动测试而无法手工测试的东西就算存在也决不会太多。

最后，两者对测试员的能力需求：
自动测试对测试员的能力需求包含了手工测试对测试员的所有要求，并且还增加了代码能力的要求。

因此，自动测试比手工测试技术含量高。但是高出的仅仅是代码能力，相对于其他大多数相同的需求，代码能力占的比例并不高，最多也超不过10%。所以虽然自动测试比手工测试技术含量高，但是也没有决定性的优势，不能以此否认手工测试具有的技术含量。

结论：手工测试具有技术含量。

网络游戏开发模式对比

加入游戏业5年来接触到不少开发模式，其中两种比较典型：
A：程序负责实现，策划负责设计。
B：程序负责底层代码支持，策划负责功能和逻辑的设计和实现。

简单的区分就是：第一种情况，策划是不接触代码的，所有代码都由程序完成；第二种情况，程序则不关心游戏具体的内容，只负责引擎和工具支持，游戏的逻辑和规则部分代码是由策划在程序提供的支持基础上完成的。

由于各自的工作分工不太一样，因此工作方式也有很大不同，其中也有一些不同的陷阱。

A类，主要问题是经常会出现策划设计完成后程序说不能实现，或者程序理解策划案错误，做出来的效果令策划不满意。
这种团队非常依赖程序与策划间的沟通，如果沟通不好就会出现种种问题。对策划案的质量要求也比较高。要求程序员要懂一点游戏，策划要懂一点程序。

B类，由于游戏逻辑和规则是策划自行实现的，因此很少会出现程序声称策划设计无法实现的情况。
这种模式对策划和程序间的沟通需求较少，对文档要求较低。这种模式中程序员可以专心技术，甚至一点游戏都不懂似乎都问题不大。而对策划的程序能力要求较高，要能自己编程实现（虽然是在程序提供的工具基础上进行）。

实际上，还存在很多AB之间的模式，也就是策划要负责一部分实现，但是可能仅仅是一部分逻辑或者一部分数据。

A类的优缺点：
优点：
1：首先，专业分工明确，各部门职责明确，管理上相对更顺畅。
2：相对于B，通常过程文档更丰富，便于后期维护。

缺点：
1：由于职责分明，各部门对于其他部门的知识相对了解较少，可能出现以知识优势忽悠的情况，早年这种情况较多，目前应该说已经很少见了。
2：分工明确，也导致部门间沟通需求更多，增大了沟通成本，而当团队过于依赖口头沟通时反而可能导致过程文档质量下降。
3：由于程序策划分工明确，互相对对方专业了解不足，因此对测试员的知识面要求比较高。

下面再分析B模式的优缺点。
优点：
1：首先，这种模式对沟通要求低，因此往往能够节约开发时间。但是需要警惕，不要把必要的沟通也省略掉。
2：程序员可以专心与程序底层，而不需要关注游戏逻辑和表现，因此相对来说游戏底层的稳定性可能会更高（只是有这个可能性）。
3：开发模式决定了这类游戏系统的扩展性往往较高，因为底层和游戏逻辑之间的分隔比较清晰。因此，做换皮类项目更快，更稳定。往往可以在更短的时间内，作出一个换皮项目，实现流水线式的游戏开发。

缺点：
1：由于是策划自行设计自行实现，因此可能导致文档质量较差，后期可维护性较差，人员流动对项目的影响较大。（只是这种可能性较大而已）
2：策划依赖程序工作，团队的工作效率严重依赖程序能力，当程序能力不足或者出现比较严重的问题时，会导致整个团队效率的下降。表面上看程序不参与游戏具体内容的制作，但是实际上在这种团队，程序一定是核心部门。
3：虽然此类团队的第二个项目（或者换皮项目）会做得很快，但是这是建立在第一个项目的基础上的，由于前面的问题，此类模式开发第一个游戏时效率并没有优势，甚至可能存在劣势。
4：游戏规则和逻辑是策划实现的，而策划毕竟不是专业的程序员，因此这部分的代码质量往往相对较差，bug会比较多。于是在这种团队中，测试组的重要性相对更突出一些。

盛大发展后劲不足

盛大通过某些方式收购（控制）了很多团队，产品线很丰富，但是盛大作为游戏公司，发展的后劲不足。

理由：自身研发能力不足。

固然运营比开发重要，但开发是根本。盛大已经并且仍将收购（控制）很多开发团队，但这些开发能力并不属于盛大自身。

腾讯必然成为行业第一

腾讯必然成为游戏行业的老大。虽然它现在还没有坐上第一的位置。

这是众所周知的。腾讯的营销优势太大了：它所拥有的用户群异常广大。

游戏测试员从业现状

据我所知，目前游戏测试员（仅指普通QC，不包括主管或管理人员）的待遇差别是很大的，较大一部分月薪在1k-2k档次，小部分在1k以下，也有一部分在3k-8k档次甚至更高。

1k-2k档次的人数在业内占据了主力地位，另外在网络上能查找到的游戏测试相关知识通常也是以这一档次人员的认知需求为主。故而大家一提到游戏测试人员往往就先浮现出一种低级体力劳动的印象，这种大众认识很大程度上束缚了游戏测试职业的发展。

多数网游研发公司或团队对研发期的测试并不重视。这种不重视主要体现为：

1.测试人员待遇低下；

2.工作内容与职业定位不符；

3.团队地位与岗位贡献不符。

这或许与游戏测试从业人员的职业素质良莠不齐互为因果。

好在一流的游戏研发公司和研发团队在产业形成之初就已经对游戏测试相当重视，并拉动了越来越多的团队注意到QC和测试部（组）设立的必要性。

游戏测试行业目前存在着供需矛盾：

企业需要高水平的测试人才，但是能力足够的人不满意游戏测试的普遍待遇而转向其它岗位，有兴趣向高级游戏测试工程师发展的人找不到学习资料和交流机会，能力不够且无心进修的人在现有岗位上继续为这个职业制造不好的形象传播。

游戏行业竞争力简论

技术（程序）和美术从来不是游戏行业的核心竞争力，现在它们也不再成为行业的门槛。

运营开始比开发重要了，营销是竞争主力，设计作为核心竞争力将要求策划团队更好的把握用户需求。

留个脚印

留个脚印

我为什么使用blogspot？

体验不到1小时，我就决定好好探索下blogspot。

作为互联网应用体验的保守者，老公对我邀请他注册google帐号一同在blogspot写博不满，质疑道，“你有多少blog都是写了一次就放弃的？红旗飘遍全国！”他这话倒是真的。不过应该改一下，把“全国”改成“全球”，这次blogspot是google提供的免费博客托管服务。

我从04年初开始使用blog，从天涯博客、网易日记到blogcn，sinablog，最终稳定在网易博客约一年半至今。开始对订阅器产生需求时，也尝试了多款，最终在google reader和有道阅读中艰难选择了有道。虽然有道阅读测试版远没有google reader好用和稳定，但它与网易博客的一帐号通及“转载到博客”功能，还是让我留了下来。

我一直以为google没有blog服务，这次在delicious上意外搜到google所提供的blog免费托管服务blogspot，让我又在网易通行证和谷歌通行证2者之间摇摆了。

对blogspot的期待：

1.体现google帐号的聚合作用，一个帐号串联我所需求的大部分互联网应用。

2.访问速度快、界面简洁友好、安全稳定。

3.社区待发掘的用户及用户贡献的价值高。

4.others待发掘的惊喜。

《游戏创造与职业》阅读计划

阅读范围：

11章 编程原理 P208-242

14章 用户界面与游戏控制 P292-306

17章 游戏测试 P332-342

19章 公共关系与市场营销 P350-374

阅读计划：

1.了解及部分掌握，作读书笔记，写心得。

2.5月10日前完成。