个人管理

先说下行业现状和职业发展

说到测试，尤其是游戏测试，其实行业内普遍（也有不少个例）都认为其价值是不如策划、程序、美术，乃至运营的，具体的原因请参考测试者的困境。

再谈个人如何成长

很多测试点的设计都是针对于具体实现的过程和结果，而对于其本身的规则思考显得并不足，当然这是早期的测试用例。如果说区分一个新手测试和老手测试之间的界限是，能否快速上手工作内容，那么区分测试民工和测试专家的区别就在于对规律规则的探索。

当我在整理曾今写过的所有旧用例的时候，我发现了很多奇奇怪怪的功能设计，然后促使我不得不写很多奇奇怪怪的测试用例去验证它。曾今的策划做的最糟糕的一件事就是，他自认为自己设计了一个与众不同的东西，这就是创新。而最后他可能只是强迫团队中的开发、美术、测试不得不跟随他做了一件很怪异的事情。有点像是：哦，这个世界上的所有人都是用嘴吃饭的，瞧~我发明了一个用鼻子吃饭的方法，而你们要配合我做出一个工具，还要帮助我完善使用方法，以便用户可以很好地使用他们的鼻子来吃饭！实际的项目中，除了策划以外的其他人，很难阻止和说服策划做出一些愚蠢的设计，而他们常常使用的理由总是让人无法辩驳：先这样试试又不会死，大不了我们再修改嘛！或者是，算了吧，不要用你那种非设计的思路来考虑问题，要相信我们，我们是专业的设计人员，我们在开创新时代！而恰恰这是所有设计方案评审过程中最应该要做的事情，但一直没有良好的组织管理手段去解决它。我曾今想过，是否应该让每次出主意和搞设计的人在做之前先写下保证书，如果将来没有达到预期的效果，甚至造成了问题，应该要担负起怎样的责任，以此来提醒他们下决策时要慎重考虑。但是做过管理的人都知道，这是不现实的，最终导致两个结果：1、没人愿意出主意，团队失去创新活力；2、所有的决定都会征求所有人的意见，效率低下，而出现问题时你又不可能惩罚所有的人。

回顾以往的测试用例，偶尔会看到别人写的或维护的，然后又发现一个问题：不说内容，单说格式方面。格式跟内容价值相比，几乎可以无视，但是格式的凌乱就可以看出一个人并没有认真对待自己的工作。人都有一种自我陶醉感，尤其是你在做一件你认为出色的事情的时候，你会尽量追求其尽善尽美。而一份结构凌乱，风格不一，看起来好像缝缝补补的文档，永远证明着你当时是多么厌恶你的工作。 我从来不反对想要追求格式上的美好，因为我觉得愿意美化自己工作结果的人就有着进步的动力。

看过那么多旧用例，不得不得出几个结论：1、功能测试用例的编写确实没啥技术含量，因为采用最简单的策略，把所有看到和想到的操作列出来，逐一尝试就好了，大部分人写用例都是遵从这个逻辑；2、功能测试用例编写的技术点不在于测试点的罗列，而在于如何用最少的步骤发现尽可能多的问题；

招聘

团队管理

回顾以前的旧用例，发现有一段时间，每个测试用例最后都会追加一个“界面标准测试用例”，这其实也是当时有一个人主推“标准测试”的结果。每个人写用例的方式不同，但最终都将“界面标准测试用例”附加在了自己写的用例的后面，这种行为怎么看起来都觉得有点搞笑。推行一种标准测试的目的不是为了看起来整齐划一，而是我们相信它能够提高效率，带来作用，所以推行标准发挥主要作用的端点不应该是在测试环节，而应该是在设计和开发环节。这种做法就有点想什么呢……一个程序开发了一个通用的接口模块，但使用的时候不是只调用他的API接口就可以了，而是不得不去复制粘贴他的整个实现代码，这看起来实在是太蠢了。所以我要牢记这个例子，每当我想要推行什么标准的时候，我都应该想清楚它具体是怎样被使用的，是否真正在发挥作用，还是只是看起来在被使用着。

情绪控制

两种极端： 1、不能危害他人；也不能什么都逆来顺受； 2、即便不满，也优先将事情做好，不要随便撂挑子；这不是退让，而是表现出职业化，专业性； 3、