04.5~04.10
我的第一家公司：FS。
程序员。
写过php，html，jsp，java，as1，开始接触linux。
使用的语言很杂，而每种语言使用的时间都很短，好处是我在后面接触python、ruby等脚本语言时上手非常快，坏处是养成了我做什么都不求深入的坏习惯。

04.11~05.1
程序员。
用j2me写了个手机上的游戏小demo，可以通讯，走地图，完成简单的任务，聊天。基本上是自己摸索出来的，可惜没有继续写下去了。后来我总觉得，如果那时继续写了，没准我也可以做好程序员的。但测试行业就失去了一个好测试了
这段时间还兼职给GT管理层会议做会议记录，开始知道大佬们想些什么，开始知道部门之间的沟通、配合，当然还有扯皮。
有一件事情给我的触动很大：GT的副总看到会议室桌子脏了，亲自找了块抹布很仔细的把桌子擦干净了。我明白了什么叫做责任心。

05.2~05.9
程序员。
用php做了一个网站。
需求是boss直接提的，做出来效果boss看到后直接给意见改。很荣幸的得到了直接跟boss交流的机会，也通过这个机会，开始模糊的有点产品意识了。

05.10~06.10
小游戏测试。
正因为跟boss直接交流了，所以被boss赶出程序员的队伍来做测试了。这是我职业生涯重要的转折点。
一年的时间，我不仅掌握了测试流程、测试方法、测试工具，还学会了怎么跟团队中其他人配合把事情做好。
我接触到了非常优秀的程序员，跟他们学到了很多工作方法和思想，学会了用python写脚本来让工作自动化，也就是学会偷懒。
后来想起，我一直坚信是因为在做测试之前知道了什么叫责任，知道了什么叫产品。所以我才会那么努力认真的想要把工作做到完美、极致。
与此同时，我遇到了我职业生涯中第一个瓶颈——我自己知道怎样能把测试做好，但我不知道怎么让别人也具备把测试做好的能力，我自己在测试技术方面的能力似乎也到头了，不知可以往哪里走。

06.11~08.2
游戏社区测试。
公司策略问题，之前项目组撤销，我们开始开发一个类似虚拟人生的社区。
这段时间整组人状态都很低落。我开始在网上疯狂的看测试资料，试图找到一个方法——任何人，只要掌握了这个方法，就可以把测试做的跟我一样好，甚至比我更好。
后来我看到了一篇东西，作者认为测试人员在技术方面发展，还是要做一个能写C/C++的程序员。
我决定尝试一下。

08.3~10.4
我的第二家公司：8d。
测试经理。
做测试时团队里的一个程序员创业，带上了我。
产品用scrum，敏捷开发模式。这种模式需要团队里大部分人可以互相替代工作。
于是我决定尝试一下，做一个会写代码的测试，以方便做自动化、性能方面的测试。开始研究公司程序员写的代码，开始尝试自己动手甚至修改……不会的就缠着公司的程序员提问，可是一段时间下来，收效甚微。
我问自己：我真的要学会写代码吗？除了浪费别人的精力，我能得到什么？我能学会吗？
在想通了一件事以后，我很可耻的放弃了：写代码这件事，我需要花费比别人多的精力还做的比别人差。但做测试，分析测试点，分析框架合理性方面，我能做的比别人好很多，快很多。所以，我可以只设计测试需求，让会写代码的人帮我实现。
几乎与此同时，我得到了另外两个启发：
1、人和人是有差距的，能力、悟性、观念都是有差距的，要承认人能力的差距，所以根本不可能存在一种方法，可以让人掌握了之后可以无差别的工作。那么在用人的时候，一方面安排适合他能力和特长的工作给他，另一方面也要想办法培养提高他的能力和意识。
2、不必强求高大全，适合就好。这个感悟是来自于服务器安全性方面。我们用服务器时，由于出于安全方面的考虑，禁止使用root权限，而是给一个刚刚好的权限。我们在做项目，做产品，做测试，做什么都好，要兼顾质量、效率、成本多方面的考虑，找出一个适合我们的工作方法和流程。而对个人的职业规划也是如此，找到一条适合自己的路，没有人能把所有的事情都做的很好。
至此，之前遇到的瓶颈就算是突破了。

09年6月底，由于关键人物的离职，我需要兼顾美术部门的工作计划、安排和进度跟踪。同时打理两个部门。这段时间总结了一套关于外行的进度跟踪的方法，协调解决了几个产品上遗留的美术问题，并且还促进了一些美术部内部的培训、交流活动。
由于同时打理两个部门，对一些跨部门沟通的问题有了更深入的体会。也可以站在更高、更广的层面上看问题。
举个例子来说吧。当时的产品有一个美术效果很差的问题，美术提出的解决方案是要做高模，但程序质疑做高模会影响服务器计算性能，直接增加运营成本。于是这个问题一直丢在那里无人理会。我接手美术部工作进度跟进以后，就趁着美术主管有空，让他做了一个高模出来给我进行性能测试，测试结果出来，我吓了一跳：对服务器性能的影响远远小于我们以前的感觉，几乎可以视为没有影响。于是，高模版本顺利出炉。
看我把两个部门的事务都打理的不错，还促进了一些改进，老板对我表示很满意。
这时看到了一篇文章：java程序员的那些事儿。整篇看下来，我把其中的三句话刻在了心里：
1、把技术练到像吃饭走路一样熟练，像呼吸一样顺其自然。
2、适合的才是最好的，最厉害的技术都来自最基础的知识。
3、产品，产品，还是产品，只有产品。

10.5~至今
我的第三家公司：9y。
网页游戏测试组长。
不得不说，这是一个很舒服的职位，有责任，自有老大扛，有苦活累活，自有小弟担。
由于习惯了从产品和项目层面看问题，所以我挺好管闲事的，现在也开始收敛，因为明白，别人也有别人的无奈，他们更需要的是帮助，而不是责难。
所以我偶尔也教一下别的部门的人使用一些方便工作的小工具，甚至私底下做一些小工具给他们用。
我目前的工作重心，除了负责一个项目的各方面测试工作以外，就是招人，带人，培养人。
我之前说过，人，才是最重要的，把人的能力培养起来，才能真正把事情做好，光靠流程规范，是靠不住的。
但我在这方面的能力，还在积累经验中吧。
想把以下几个事情做好：
1、找到适合做测试的人；让自己拥有迅速分辨人的能力。
2、培养一群人能把测试做好；让自己拥有把人培养好的能力。
3、让更多的人拥有责任心和产品意识，让更多的人拥有振兴测试行业的能力和愿景。

任重而道远。好在我不强求。

    今天面了一个应届的，非常无语。

    笔试题全部答错，问他哪门功课学的最好，说数据库，可是连最基础的sql都不会写。

    填资料时日期也填错。。。

    除了无语还是无语。

    果断拒绝。

    直接看例子。

    【旧需求】1级联盟人数上限是10人，达到10人后由盟主操作可以升到2级联盟；2级联盟人数上限是20人，达到20人后由盟主操作可以升到3级联盟，2级盟如果人数少于10人则降成1级盟；3级联盟人数上限是30人，3级盟如果人数少于20人则降成2级盟，如果人数少于10人则降成1级盟。

    【新需求】1级联盟人数上限是20人，达到20人后由盟主操作可以升到2级联盟；2级联盟人数上限是30人，达到30人后由盟主操作可以升到3级联盟，2级盟如果人数少于20人则降成1级盟；3级联盟人数上限是50人，3级盟如果人数少于30人则降成2级盟，如果人数少于20人则降成1级盟。

    【问题】如果这个需求更新出去，运营中人数在10到19之间的2级、3级盟，会全部变成1级盟；运营中人数在20到29之间的3级盟，会全部变成2级盟。这对玩家绝对是一个打击。

    【解决方案】1级盟人数为1~20人，2级盟人数为10~30人（本来是20~30人），3级盟人数为20~50人（本来是30~50人）。确保运营中的玩家利益不受影响

---------------------------------------------------------------------------

    【旧需求】任务链：1->2->3->4->5->6->7...
                                                       ->a->b

    【新需求】任务链：1->2->3->4->5->6->7...
                                                                  ->a->b

也就是说，本来做完任务3后出现任务a，改成做完任务5后才出现任务a。

    【问题】先解释一下程序原来的实现思路：每个任务链有一个串编号，按照这个串编号来记录当前任务链做到了哪一个任务。如果外网的玩家第一条链做到了任务4，第二条链做到了任务b，改成新需求后，玩家完成任务5后，任务a就会重新出现，也就相当于玩家要做两次任务a和b。

    【解决方案】策划要求，如果外网的玩家以前没做过ab这两个任务的，就按照新需求。但如果玩家以前做过了ab这两个任务，而还没做到任务5的，在做完任务5后，不出现ab这两个任务。

    这是一个相当变态的需求，程序花了很大的力气甚至改动了程序框架才解决了这个问题。

---------------------------------------------------------------------------

    我能想到的：

1、多点考虑需求变更给外网玩家带来的影响，如果没做对现有数据的兼容处理，可能会出现严重的运营事故。

2、在考虑解决方案时，尽量多的让利给玩家，保持一个和谐的运营环境是非常重要的。

3、以后我碰到类似的问题还会持续的记录下来，积累经验，积累资料。

    昨天早上一个，昨天下午一个。

    早上那个是应届的，题目做的很好，基本上都答对了。可是聊天过程中，发现他只会背书，看不到自己的见解。一副信心满满的样子。最后他还问我他表现的怎样，我告诉他书背的很好，但没有看到他能力特别出彩的地方。

    头面完出来跟我说不要。原因是在面试过程中，这家伙语气很不友好。头问他一些问题，他说完以后还会反问：难道你不觉得XXXXX吗？

    这个没办法了，招聘的被应聘的串了，总是不爽的。

    下午这个一年前毕业的，人来晚了，据说有事耽误了，但还是上来看看有没有机会。

    据说头天晚上通宵赶兼职，精神状态很不好，但笔试题答的一般般，有些知识已经忘记了。居然是带着女朋友上来的，说他女朋友病了，面试完就一起去医院。。。

    基础一般吧，不过态度还行。头很喜欢他负责任和诚实的态度，所以打算留下试用一下。

    今天下午又来两个。

    第一个学电子的，应届毕业生，专业不对口，但人很灵活。出的sql题不会做，居然用excel做类比，佩服啊。

    说话有点小啰嗦，喜欢滔滔不绝，可能跟他做过客服的实习有关，但基本上逻辑还是清晰的，性格外向，整个人的感觉还比较舒服，但基础知识缺失太多，对游戏的了解算泛泛。

    圈出他笔试过程中的三个错别字，居然强调那是意外，很会找借口。。。

    最后他问了我一个很有趣的问题：“我是最差的吗？”

    第二个学计算机的，毕业两年了，但只在他父亲的店里打了一年工，跟计算机一点关系都没有，据说当年没心情找工作，但不愿意说原因。

    笔试答题时间半个小时，半个小时我进去看的时候，他正在讲电话，晕死。整个面试过程中电话不断，虽然他没接，但给人感觉相当不好。

    专业知识基本忘光，性格属于内向，奇怪的是，有人的内向给人感觉沉稳，但他的内向给人感觉消极。

    两个都拒绝掉。

1、责任心强

2、平和、低调、务实、严谨

3、谦虚好学

4、简洁，尤其是说话要简单清晰明了

待补充。。。

    昨天晚上和今天早上各面了一个。

    我现在的策略调整是，基础知识看笔试情况，面谈过程看项目经历（针对有经验的），性格，理解能力和表达能力，个人职业规划等。

    昨晚那个笔试情况一般般，半个小时只做了三题，代码，sql，操作系统，但都做对了。但我担心他工作效率有问题，太慢了。字写的很漂亮。

    他的经历是一边工作一边参加培训和参加自考大学的，工作经验几乎可以忽略不计，啥都做了一点点，但啥都了解不深入。过程中讲了一下我们这边工作压力比较大，他有少少迟疑。不过性格还不错，沟通中觉得他理解能力有点小问题，但还属于可培养范围。

    鉴于他还很年轻和平和踏实的性格，打算给offer培养一下。

    今天早上这个有三年半的工作经验，82年的，08年才大学毕业，我问他为什么，他却闪烁其词，开始不想回答，后来才说他留过级。

    笔试结果一般般，和昨晚那个差不多（不过昨晚那个做的是应届毕业生的题，今天这个做的是有经验的题）。涉及到一些概念的，都是教科书中的标准答案，没有写自己的体会。

    面谈过程中发现，虽然笔试题的答案是正确的，但在工作中就真的没积累起什么经验，基本上都是浅尝辄止。说是了解sql，但出了一题完全不会做，连select也不会写。问了一个游戏中小功能的测试点，也是顾左右而言他。

    82年的，这样的经验和能力，加上面试过程中不太老实（昨晚那个问到不会的就老老实实说不会），一副老油条的态度，果断拒绝。

    刚刚又面了一个，应届毕业生，大专的。

    技术底子还可以，冒泡算法和sql都做对了，其它涉及到树、linux方面的知识缺失。字写的不好看。

    聊天过程中非常啰嗦，且抓不住重点，问他一个两句话能说明白的事情，他能说上好几十句，还要先介绍事件背景。。。几次忍不住打断他的话。

    头去看了一下，跟我的感觉一样，拒绝掉。

题外话：

如果在面试过程中面试官打断你的说话就要注意了，这是一个信号，人家觉得你说话太啰嗦了，需要立刻调整自己说话的方式。

    刚面了一个，广西的，应届毕业生。

    笔试题基本上都会做（除了linux没学过），偶尔有些记忆不清的，聊天过程中发现对测试和游戏的概念都比较含糊，但能够根据学过的知识说出自己的见解。整个人给人的感觉是低调踏实，态度平和，非常好。

    鉴于基础比较扎实，我个人感觉做测试有些许可惜了。本想推荐给程序面一下看看的。头面完之后出来说，那样怕给面试者本人的感觉不好——程序刷下来到测试。。。。

    头跟他聊了一下应聘的情况，据说他应聘过程序和策划，都失败了。所以头简单跟他介绍了测试的工作特点后，他还是决定要做测试的。

    当场给这个小朋友答复：要了。

    面试了这么多年，这是给人感觉最好的一个。

    今天心情大好。

    今天下午又来了两个，面下来感觉让人有点小无语。

    第一个是应届毕业生，计算机专业，大老远从深圳赶过来，笔试中看出还是有一定的基础，但是审题有问题，有好几题没弄清题意。

    聊下来感觉，虽然宣称很热爱游戏，对测试和游戏都不了解，对应聘的是什么职位也不太清楚，完全搞不清需要做什么，没做好准备。问他为什么应聘这份工作，说是感觉我们公司需要很有活力和激情的人，虽然我没感觉出他的活力在哪。

    第二个是去年毕业的，但只有一个三个月的工作经历，之后就一直在找工作。学的是计算机，那份工是做程序员，但一个冒泡排序算法都不会写。可能是成见，但我还是觉得那个三个月是因为没有通过试用期。

    聊下来的感觉，居然也宣称很热爱游戏，但一样对测试和游戏都不了解，基础比上一个更差，计算机相关的东西几乎完全不了解，问他为什么，他说因为学了太久，忘了。又一个打算以测试为跳板的人，目标是策划。

    两个都不要。

    测试真的这么好混吗？真的这么低要求吗？任何谁找不到工作都可以来“屈就”一下？

    今天感觉相当不爽。

    昨天下午又面了两个。

    这两个人有着共同的特点，毕业后都做了一段时间跟软件测试无关的工作。所以，虽然不是应届毕业生，但基本上可以当作应届生来对待。两个人有一个共同的优点，就是字写的很漂亮。

    第一个是广西人，说话有比较浓重的口音，大学学的是微电子，计算机软件方面的知识几乎没有了解，从经历和家庭环境上看，属于比较能吃苦的那种，愿意拼。聊了一下，相关基础知识缺失太严重，对游戏算有少少粗浅的认识，性格比较沉稳和平和，算是比较踏实的人。

    第二个是江西人，家庭条件应该还不错，本科学的是计算机，底子还在，但知识都记得不太清楚了，玩过游戏，但了解不多。性格也还可以，整个谈话过程比较轻松，表达清晰，口齿清楚，但比较冷场，很难相信他上一份工作是做销售。也许正是这样的性格所以想做技术吧。虽然口头上说做好了吃苦的准备，但是，他给人的感觉是不太会为事业拼命的那种人。性格也算平和的那种。

    两个人情况有点像，只是想先找一份工作，测试对他们来说是过渡也好，跳板也好，最终都是想做策划的。这种人见的太多了。

    最后决定，第一个一点基础都没有，不要。第二个，虽然需要花点力气培养，但喜欢他的性格和清晰的表达能力，所以决定试用一下。因为我们现在正有培养新人的计划。但这对应聘者来说可能比较残酷，虽然放低了进入的门槛，但转正那关就难过多了。

    （后来打算试用的那个他没来了。）

    昨天下午面的，三年半测试经验，待过的公司都主要是做外包的。经历平平，无亮点。

    笔试结果看，完全不懂游戏，对测试的了解也局限于感觉，很粗浅，但总算大概知道测试是做什么的，对未来也有一些模糊的愿景。

    面聊过程中，回答问题抓不住重点，很啰嗦，基础太差。

    我很直白的告诉他，他没有打动我。他说他知道，眼里有点小失落。

    我让他列举他的优点和缺点，他把优点归结于性格品质方面，例如细心、真诚、好学、上进、沟通能力强等，把缺点归结于经验，例如没有做过游戏测试，没有经历过正规测试流程之类的。

    我圈出他笔试中写的一个错别字，他把“优秀”写成了“优季”，告诉他，他一点也不细心，说话太啰嗦抓不住重点，所以沟通能力也不强。

    有感于他的真诚，我让老大看了一下他，老大觉得他基础太差，out掉了。

题外话，今天早上突然想到的，要想把事情做好，有四件事情很重要
1、知道什么是好的
2、知道什么是不好的
3、知道怎么做会好
4、知道怎么做能避免不好

让自己慢下来，静下来，深入一点去思考清楚，比大量的去玩游戏、看资料、做培训有用的多，能力不是靠“量”堆积起来的。愈是浮躁的年代，愈需要沉寂下来。忘掉所有招式以后还能留下来的，才是自己的东西。

简历印象：

1、在北大青鸟培训过，感觉有点不好

2、一年左右测试经验，满简历都在强调lr，qc等类似的测试工具，但只说用什么工具做什么事情，无深入

面谈印象：

1、因为不熟悉路，为了不迟到，提前了40分钟到，感觉不太好

2、当前公司也是做游戏测试，但通过自己的思考，做了一些小工具来搭建测试环境和帮助测试，他说遇到问题还是尽量自己想办法解决不去麻烦别人，这点不错

3、对游戏不了解，且认为了解游戏设计知识是策划的工作，与测试无关

4、的确有lr的使用经验，的确在工作中有思考，但过于强调技术，言语中多少流露出对功能测试，手工测试的轻视。而且我一问到关于性能指标等问题时就支支吾吾了，所以也只是会用lr这些工具而已

经过yzzt三个多月的测试工作，其中在外网体验服也放了几个版本，发现大家在测试工作中碰到了一些问题。在不同的阶段，处理问题的方法是不太一样的，因为事情的轻重缓急会起变化。而我们的工作中应该有一个很重要的部分是给事情排优先级。

1、  QA文档阶段

最重要的是风险预估

Ø  思考玩法是否足够吸引，与整个游戏的联系是否紧密，能否很好的配合游戏主题

Ø  关注潜在的逻辑冲突和漏洞，功能本身的，和其它功能交叉的

Ø  思考有没有更好的实现方式，用更少的精力更小的风险达到同样的甚至更好的效果

Ø  尽多尽早的考虑版本、流程、产品中可能出现的问题

2、  开发阶段

最重要的是全盘了解版本状况

Ø  尽快拿到可测试版本，导致测试进行不下去的bug要追着程序修

Ø  尽快的跑通流程，导致流程跑不通的bug要催程序处理

Ø  不要让程序闲下来，尽可能快和多的发现问题，加bug

Ø  思考玩法是否达到了预期的目的，进一步发现产品设计上的问题

Ø  拿不准的问题跟策划沟通或在测试内部沟通，影响大的问题可以发到产品群

Ø  如果遇到细节问题想省事，可以直接加bug给策划，让策划回复确认

3、bugfix阶段

最重要的是让版本尽快稳定下来，可以体验

Ø  适当的调高影响体验的bug的优先级

Ø  有些严重但不影响体验的bug可以适当的调低优先级，延后解决

Ø  允许留下一些不影响体验的问题，尽早出版本让策划体验

Ø  对于盟战这种策划难以体验的功能，可以邀请策划来测试服一起体验

4、发布阶段

最重要的是发布，学会判断，学会放弃

Ø  确定发布时间后，要评估哪些bug必须修，哪些bug可以修，哪些bug不用理

Ø  在接近发布时间时发现的bug，能不处理的问题就不处理，以免引发更多更严重的问题

Ø  在接近发布时间时发现影响发布的bug，不必再走bug流程，直接提出让程序修，同时要发到测试群里，让其他人了解情况

Ø  接近发布时间的定义，一般是一天左右

Ø  严格把握发布流程，不能出任何纰漏

Ø  打包和上线的版本确认，关键是确认这个版本是不是我们确认可以发布的版本（例如看最后修复的bug还在不在，在关键流程上跑一跑，看有没有发布环境引起的问题）

5、空闲时间安排

最重要的是提升自己

Ø  关注细节，提高品质

Ø  对游戏的理解

Ø  对测试的理解（技术、管理、流程）

Ø  对游戏测试的理解

Ø  多思考，多总结，多交流

6、其它

Ø  如果是各个阶段交融怎么办？例如一个版本要发布，另一个版本提交测试。

--这种时候比较少，一般由主管特殊说明，大家不用过分担心。

Ø  在何时需要妥协，在何时需要寻求帮助？

--随机应变，多站在用户角度考虑，多站在产品品质角度考虑，但要兼顾我们的实际情况和时间压力。

Ø  策划和程序商量的修改不通知测试怎么办？

--一方面需要大家自己更主动的去了解，另一方面，在新的流程下再出现这种事情，向测试主管投诉。

1、判断数据在客户端、服务端缓存、数据库的方法

Ø  客户端操作后的显示----客户端

Ø  客户端操作后，重新登录后的显示----服务端缓存

Ø  客户端操作后，清缓存再重新登录的显示----数据库或内存

Ø  修改数据库后，必须要清缓存，数据库的数据才能生效

Ø  如果要进行外挂测试，则修改数据库后清缓存，但不重新登录客户端

2、区别客户端、服务端bug的方法

Ø  所有显示、操作、弹框等都是由客户端处理的

Ø  涉及到逻辑、数据的问题，则要检查服务端缓存和数据库/内存是否正确：

²  如果正确，表示是客户端的问题

²  如果不正确，也不能完全肯定不是客户端的问题，碰到这种情况bug指给服务端

Ø  遇到测试环境的bug，程序在自己的环境不能重现的，优先检查策划表是否正确

3、测试数值的方法

Ø  自己做表格方便计算数值

Ø  自己修改xml文件中的数值、公式

4、测试表格的方法

Ø  理解表格中每个字段的意思和在程序实现中的用法

Ø  分类分批检查，如技能表可以分成：主动技能/被动技能、人物技能/召唤兽技能

Ø  逻辑上明显的漏洞

Ø  错别字、语法错误

Ø  一些隐性的问题可以到游戏中测试

5、功能实现不全的测试方法

Ø  可以测到的功能先测，测不到的功能后测

Ø  通过构造数据的方法来绕过某些没实现的功能

²  加各种礼包

²  设置召唤兽的各种技能

²  帮敌人复活

²  把召唤兽技能放到怪物上测试

Ø  修改程序代码，绕过没实现或实现有问题的功能

6、服务端实现了，客户端没实现的测试方法

Ø  断点+单步

Ø  看log

7、做的好的地方

Ø  做一些实用的小工具

Ø  做存储过程

Ø  项目内工作交流、互相帮助

8、做的不足的地方

Ø  测试用例覆盖率（我自己写的战斗系统测试用例不好用）

Ø  比较被动

Ø  和程序、策划的交流没有在测试内部分享

Ø  测试经验和心得分享

Ø  Bug定位（寻找bug重现条件）、Bug描述

Ø  对程序的架构和思路不够了解

9、其它部门配合不足的地方

Ø  策划表数据不全，导致没有真实数据测试，只能自己构造

Ø  策划更新表不通知，或没有通知到所有相关人员

Ø  策划导表后不及时帮我们同步

Ø  策划提交表的修改后，程序没提交相应修改功能

Ø  程序提交sql不通知，不提供修改字段的sql，导致每次修改都要清库

Ø  程序功能实现不全，且很零散，又不及时修bug，导致测试很难全面系统的进行

    我很少能主动做一些总结，有很多事情在我看来是很理所应当的事情，这导致了我一个很严重的问题，我会感觉没什么东西教给我带的新人。今天，一个网上认识的做测试的朋友问了我两个问题，记录一下吧。

1、假如你当面试官，你让人家说说他们的项目流程，你想得到一个什么答案呢

答：没有预期值，只是想看看对方对流程的了解以及理解
如果是毕业生，就算完全不了解，问题也不大，从别的方面去考察他的领悟能力和学习能力
如果是初级的人员，能够对流程有一定的了解就可以了
如果是高级的人员，则要懂得，流程是手段，更重要的是过程中的应变能力
当然，高级人员对流程要有相当深入的了解和体会

2、那如果是你你会怎么回答啊

答：先答理论上的标准流程；再答我经历过的最好的流程，包括这个流程是如何形成和改进的，以及我在这个流程建立和改进过程中所起到的作用；最后再举例说明一下我们在遇到紧急情况的时候是如何进行应变。我应该会着重去讲我思考、判断、决策的思路和依据。

    这个事情发生在06年，当时我们在做休闲小游戏平台，要发布的版本在内网测试过没问题就更新到外网。

    大家知道，客户端休闲游戏一般都会做上自动更新功能，当人数比较多时，可以自行选择从哪个服务器下载更新。这个服务器列表是配置的。我们用的格式是：

服务器1

服务器2

……

    为了能保证下载的安装包是正确的，我们加上了校验机制，于是格式修改如下：

服务器1

服务器1的checksum

服务器2

服务器2的checksum

……

    杯具发生了。

    当这个版本的服务端放出去以后，无法正确自动更新，客户端程序检查了很多次读配置文件的代码都没问题。直到有人突然醒悟：读配置文件的是外网的旧版本。赶紧紧急修改配置文件格式：

服务器1 服务器1的checksum

服务器2 服务器2的checksum

……

    于是，我们在发布流程里增加了发布测试，架一台中间服务器，测试从旧版本（可能不止一个旧版本）自动更新到新版本的过程。

    再后来，我们又把发布测试做了扩展，测试整个发布流程的操作有没有问题。后来发布基本上是写脚本执行的，所以实际上也是检查发布脚本。

　　有一次，我要在客厅里钉一幅画，请邻居来帮忙。画已经在墙上扶好，正准备砸钉子，他说：“这样不好，最好钉两个木块儿，把画挂上面。”我遵从他的意见，让他帮着去找木块儿。

　　木块儿很快就找来了，正要钉，他说：“等一等，木块儿有点儿大，最好能锯掉点儿。”于是便四处去找锯子。找来锯子，还没有锯两下，“不行，这锯子太钝了，”他说，“得磨一磨。”

　　他家有一把锉刀，锉刀拿来了，他又发现锉刀没有把柄。为了给锉刀安把柄，他又去校园边上的一个灌木丛里寻找小树。要砍下小树，他又发现我那把生满老锈的斧头实在是不能用。他又找来磨刀石，可为了固定住磨刀石，必须得制作几根固定磨刀石的木条。为此他又到校外去找一位木匠，说木匠家有现成的。然而，这一走，就再也没见他回来。当然了，那幅画，我还是一边一个钉子把它钉在了墙上。

　　读者感悟

　　在人生的旅途中，每走一段路程，不妨停下来沉思片刻，问一问：我要到哪里去？我去干什么？这样或许可以活得简洁些，也不至于走得太远，失去现在，失掉自我。

--------------------------

以上为转载

为啥呢

因为在工作中看到有些人，一味追求炫的技术，忘记了测试的目的和本质

这是一个浮躁的时代