测试者的困境

人的一生，总在无聊和痛苦之间徘徊。——叔本华

相对来说，测试的薪资较低

  之所以一上来说钱的事情，是因为这是大多数人选择工作时最关心的，也是最现实的问题。说低的原因有两点：

  1. 在各大招聘网站上搜索一下就能对比出互联网各个工作的薪资水平，测试人员一般要求的经验和能力都不会特别高,至今不断有猎头和HR找我推荐工作经验1年左右的测试员，这样的人员刚好有一定的工作经验，能够完成他们期望的工作内容，同时薪资要求不高。

  2. 测试同样参与项目研发过程，但在项目盈利后的分成比例可谓最低。很多公司会选择将测试做成平台或者找测试外包，其实也是为了进一步压缩测试成本，将测试排除在利益分配的圈子之外。

  针对原因1，是因为行业普遍认为测试是一个很简单的工作，也就是发现问题。并认为只要多跑跑，总能发现问题，那么不需要太高的能力就可以进入行业参与竞争，可替代性就很强，薪资低是很正常的。薪资低，就留不住人才，人员流动性就会大，技术发展就会缓慢，从而进一步加深测试水平低下的感观，形成恶性循环。所以写这本书的一个目的也是希望能将“游戏测试”这件事情尽可能地说清楚，不是为了说服别人测试也是一件不简单的工作，而是为了让所有人都能完成简单的测试工作，进一步压缩低端测试人员的生存空间，逼迫测试从业者追求更高的技术水平，整体上获得更高的专业性和价值回报。

  针对原因2，可以有两种做法。一种是接受被排除圈外，极力提升测试团队的专业性和高效性，将“外包”的路子走到极致，然后按单次服务进行收费。例如国内做的比较好的TestIn的移动端云测业务；这样的好处就是，测试可以从单个项目的泥潭中脱离出来，按次收费，虽然每次收益较小，但可复用性高，属于薄利多销。另一种就是想办法融入圈内，不仅仅只做测试结果的反馈，还可以积极主动、全方位参与开发过程，加强过程反馈，这也是质量管理、测试驱动、敏捷测试这类方法的思路。能做的事情也比较多，如进度管理，单元测试，自动化测试，性能测试等；这样做的好处就是，有较大的转型空间，遇到好的项目可以最大程度分享到胜利果实。

测试的价值很难衡量

  如果测试从业者想要更高的报酬，首先你要能证明自己能带来更大的价值，而测试的价值是很难衡量的。它可能没有，即便有，“看”起来也很有限，主要的原因有以下几点：

  1. 目标不那么明确。这里所说的目标不明确不是说测试行为本身是完全不带有目的性的，每条测试用例都有清晰明确的预期结果，测试的目标就是验证实际执行的结果是否与这个预期相符。所谓目标不明确是指测试结果即使通过，也无法证明产品就是没有问题的；这跟医生的工作相似，无法肯定地说某个人就是健康的。“没有问题”、“健康”这两个概念本身就很难定义清楚，严格的话只能这样说：哪些内容在哪些方法的验证下是没有发现问题的。测试员和医生的工作，都很大程度上受限于自身的认知水平和经验积累，传统医学传承几千年，现代医学也发展了300多年，分类细致繁多，但误诊、复发的问题依然很多，测试技术的发展还有很长的路要走。

  2. 作用不那么明显。一次测试，如果发现了问题，那么这次测试就显得是有必要和有意义的；但如果测试后没有发现任何问题，对产品没有带来任何的改变，这次测试做和不做似乎都是一样的结果。即便测试发现了99%的问题，但只要遗漏了1个严重问题，造成的损害都可以抵消掉之前所有的辛苦。很多人(包括测试从业者)都有这样的一个错误认知，都以为测试是可以提高产品质量的。其实产品质量在设计和实现的时候就已经决定了，测试只是尽可能真实地反应出产品质量的现状。测试可以发现问题，质量管理可以预防问题，但当问题一旦被解决，很快就会被人遗忘，这次测试的价值也随之消散。

  3. 最容易被压缩时间。不用设计、不用编码、不用画图和不用测试这四句话，看起来只有最后一句是可以成立的。日常工作中，策划想一个方案可能要3天，程序写代码可能要一周，美术绘图建模可能要半个月，到了测试这里，大家希望你1个小时就能给出结果。其实这里有个心理学效应，那就是每个人都会高估自己，低估他人。所有人都觉得自己做的事情才是最重要的，需要更多的时间，而别人应该很快就做完他应该做的事情。另外，完成测试同时表示着“大家的工作都完成了”，所以测试承担着所有人急切的期待，加上大家都认为自己完成的肯定是没问题，只需要查看自己完成结果的测试是多么轻松的一件事情啊~，这种“群众”氛围也会要求尽快完成测试甚至不需要测试。

  专业的测试是在寻找bug，非专业的测试只是遇到bug，测试工作一定要做好记录和总结，这样才能获得专业上的成长和认可。目标不明确，那就每次测试之前，公开你的测试策略和执行计划，让大家都清晰地看到你将如何去做，成本多少，会有人给予更多的建议和帮助的。作用不明显，那就通过累计的数据，用连续性，多维度的对比来体现测试行为的价值；还可以挖掘测试人员自身的价值，比如你更精于业务，更善于思考，更快捷高效，更细致体贴，既然你能比别人更擅长发现问题，那么你就有机会比别人更早地进行改进。测试时间被压缩，那就评估好风险，舍小保大，这样也能锻炼你的决断力。

测试总是在反人性操作

• 测试的过程是需要被打断，反复尝试的。很多人做测试，就是按照正常的流程跑一遍，觉得可以顺利跑通这就是没问题的了。但真实的测试却需要去分解过程步骤，在每个环节去发散思考，尝试各种错误的可能性；我们的大脑是极为不喜欢这样的行为方式的，它更喜欢如行云流水般顺畅、丝滑的过程体验。做测试一定要有比常人更好的耐性，所以做不好程序开发的人我觉得同样做不好测试。

• 测试总是带来坏消息，而且会夸大问题的影响。我们的心理机制让我们觉得自己永远是正确的，所以突然有一个声音告诉你哪里出错了，第一反应一定是否认和厌恶的。又因为“每个人都觉得自己做的事情是最重要的”，测试在发现了问题之后，往往也会夸大问题的严重性，进一步刺激被发现错误的人的情绪。当问题解决后，大家又会慢慢忘掉这次教训，同时被遗忘的还有测试的价值，让测试人员觉得失去了被关注，于是下一次，测试发现了问题会继续夸大，重新唤起大家的重视。如果测试不能做好记录和总结，这将形成又一个恶性循环。团队中，好的测试会让人几乎感觉不到他的存在，你只会觉得自己做的事情大都能够顺利流畅地到达终点；而糟糕的测试则不断喧嚣着自己的存在，用各种突发问题来刺激你的神经。

• 测试发现问题不是越多越好。曾今我也以为测试发现的问题越多代表测试人员的能力越强，下次测试产品的质量情况会更好；某个范围内，确实是这样的。但一旦超过某个限制，问题越多只表示这个产品的质量越差！测试发现的问题多了，会遮蔽一些隐藏更深，影响更严重的问题，而且修改问题的同时还可能会引发新的问题。更糟糕的是有些开发人员会将完成度很低的东西直接丢给测试，然后等着测试人员给他们报bug，再逐一修改。这不但不能带来效率的提升，反而会增加沟通的成本，增加工作人员的负面情绪。

• 做的好是本分，做不好要背锅。我们都喜欢邀功自己做了什么让事情变的更好，而测试做了什么是为了确保事情不会变得更糟。很多团队中都有这样的角色，就像行军打仗的后勤人员，足球队中的守门员，平时可以没有你，但情况危急的时候需要你立即出现，承担起责任。这样的合作方式，也减少了测试与其他工种之间的交流，使得大家更难建立对彼此的了解，也就进一步降低了测试在团队中的重要性。

  我说这些的意思不是想说这些反人性的操作都是应该的、正常的，用什么“良药苦口，忠言逆耳”之类的来劝诫大家理解和接受。而是希望测试从业者能够明白，自身工作本身带有的这种“天然属性”也在某种程度上阻碍着工作的顺利进行，当我们在做事情的时候，要能用更为合适的方式与人沟通，尽量愉快地解决问题。比如平时多跟策划、程序交流，不要等到发现问题的时候才大喊大叫催着别人来看。多了解他们的想法，多告诉对方一些好消息，比如这次没有问题啦，发现什么地方有亮点，点个赞什么的。总盯着问题和缺点是会让你锻炼出一双火眼金睛，但同时也会慢慢改变你的性情，变得难以相处。在我的工作经历中，还是碰到了很多那种懂得互相帮助的同事的，相处下来，了解了彼此的做法之后，他们会主动告诉你一些有风险的测试点，主动帮你开发测试接口，主动帮你配置测试数据，这些都是可以极大提高测试效率的。永远记得，这个世上是可以通过规章制度要求别人为你做什么，以便达到想要的结果，但这种看似快捷做法同时也会限制双方的能力；真正的合作一定是建立在了解和信任的基础上的，绝不是靠所谓的管理手段。

  在我自己当前的工作当中，除了完成测试的本职工作外，我还会去评估产品整体的质量和团队的研发能力，如果有需要我会给出自己的一些建议，或者帮忙做一些实际的事情，这些还是取得了不少良好效果的，比如扭转了研发进度delay的问题，提升了产品上线的质量，减少了线上需要处理的问题等等。另外在跟别人讨论做一件事情的时候，我会提出各种可能存在的问题，以及带来的影响；倒不是说想要以此证明这样做不可行，而是希望做之前能将可预见的障碍都扫清，确保事情的顺利执行，以免过程中问题百出，疲于奔命。所以我很不赞同那种“目标含糊不清，走一步看一步，遇到问题再改”的做事方式，但凡我经历过这种产品方向摇摆的项目，最后都无一例外地失败了。

做测试越久越难有成长感

其实这才是一直以来做测试最困扰我的地方。回顾前言中提到的，测试难的不是测试方法的设计，难的是对测试对象的认知。换句话说，测试大部分的工作内容都是建立在已经创造的事物之上，就好像影评人对电影的评论，换个地方“一文不值”。也不是说测试一点创造内容都没有，至少测试也是在写用例，写工具，但并没有真正意义上属于测试自己的东西。你会说那可以自己多学习啊，多找点有创造性的事情来做啊，你说的对！但是日常的测试工作总是没完没了，总有做事敷衍，态度散漫的同事不断用简单、重复、无聊的问题来塞满你的时间，消磨你的耐性。写到这里好像有点在抱怨了，其实谁的工作不都这样，程序时常吐槽策划各种糟糕奇葩的设计；策划也总说这不是我想要的，自己也是被老板逼着这么搞。算了，我还是删掉这段，重新考虑下应该怎样写吧，毕竟这本书的目的是指南，而不是吐槽。

测试效率再高，再全面，其实也没办法从根本上改善产品质量问题。而且测试总是能碰到文档写的浅，代码写的烂，却希望在经过测试之后，能一下子完善起来，这是不可能的！更要命的就是测试很难对此进行拒绝。好的策划、程序在快速完成自己的工作之后，就可以很开心地去做其他的事情了，而测试总是要不断面对简单重复的问题，这怎么能获得成长感和成就感？如果有一天工作和伙伴能够自由选择，而不是强制分派，我相信对于真正想要做好事情的人来说会是一个更大的帮助，也能尽快清除团队中的“裸泳者”。

其实最大的困扰还是我们会是想要用一种方式，也就是“我们自己的方式”去赢得整个世界。我们每一个人最终都会因此痛苦、困扰、迷茫、绝望，但在碰壁之前，我们还是会因此收到更多的好处，比如舒适、安全、利益、炫耀。曾今我很喜欢的一部动画片《游戏王》中，当法老王的灵魂因为傲慢在决斗中失败之后，容器的灵魂替代他被敌人抓走了。当法老王痛苦不堪想要追求更强大的力量来夺回自己伙伴的灵魂的时候，同伴的灵魂却现身，说了这样的一句话：我们并不能用一成不变的方式去面对这个世界。于是法老王的醒悟，不再憎恨与懊恼，而是坚定自己的决心，并尝试以宽容地方式劝敌人回头。