。所以呢，趁着脑袋里还有点东西的时候发出来，要不然吃过早饭基本上就都进肚子里了。The Time is 4:05，半夜 2 点被一个电话吵醒就再也没睡着，这点坚决秒杀 Monkey 这种睡懒觉的大神 。所以呢，趁着脑袋里还有点东西的时候发出来，要不然吃过早饭基本上就都进肚子里了。
最近在各个群以及论坛都能发现一些话题：
测试工作范围、小白怎么去测试、公司不规范如何去测试、测试不受重视怎么办……
对于以上一系列的问题，我一般的回复是：“要么忍，要么走”，其实这个观点对于站着说话不腰疼的人比较适用，当一个人处在上有老，下有小，需要考虑的事情很多的一个时期，离职并不是能解决这类问题的方法。基于我目前的了解，如果你认为某个公司的某一个方面不是令你满意，仅仅因为这个事情离职，那么你下一家公司一定会出现不让你心仪的另一个问题。这个世界不可能有十全十美所有方面令你满意的公司，如果有,请告诉我，我也去~~
我下面就总结下我从业这几年所遇到的问题，如何进行解决：
无设计、无需求、无用户手册等文档测试
在这一点上，我相信很多公司都会有这种情况，开发打个包，直接说，过来测吧，作为测试人员的我就屁颠屁颠的去了，之后我向开发说，起码得让我了解下业务啊，开发回复：“XX，去给测试讲下业务”，我就傻傻的在那听开发口若悬河的在讲，具体讲的啥我也不清楚。所以在以后的测试中，对于类似项目我不再要求文档之类的辅助性资料，如果涉及业务流程等操作，我会直接要流程图，这个肯定会有；那么我一直会给开发灌输的思想就是，不要在语言上限制我的操作，如果系统没有相应限制，那么只能说在设计的时候考虑欠妥。如果有需要直接联系相应开发人员随时讲解，深入业务讨论，才能知道自己到底在测的是什么。
所谓的敏捷开发、敏捷测试
我承认我在一个反正不算二线的省会城市中，北上广的互联网春风刮到我这的时候，房价都快掉价了。敏捷开发、敏捷测试就成了每个开发嘴里的时髦名词，那么最后的结果是什么呢？每个开发都在弄那么一块小东西，最后集成的时候一系列的问题：项目迁移无法正常启动、功能失效、实现功能与需求不匹配……，最后以项目特殊性为由，测试需要介入，可以这么说在开发眼中的敏捷测试就是测试帮助开发完成功能的单元测试以及集成测试，并且对于迭代次数没有明显的限定，基本处于一个随提随改的状态。那么对于这种情况，只能说参与测试的测试人员对于 bug 的记录一定要清晰，以项目目前可测模块进行功能遍历，整体遍历一遍作为一次版本迭代，对于每次版本做好备份（不需要追溯就无所谓了），只有在这种状态下才能尽量的完善项目质量。
测试永远是背黑锅
这个问题我个人感觉应该是个普遍问题，IT 本身就是个服务行业，测试呢更是服务于 IT 的行业，那么对于一个服务行业来说，背个锅还是挺正常的，但是你要知道你背的冤不冤，提公司背锅就无所谓了，公司会记住你的，但是你要是替开发背，那么只能说你自己的道行不太够。对于测试来说，总听见的一句话是：“测试咋没测出来 bug”，如果这个 bug 你确实没测出来，那么没办法，你认命吧。如果说这个 bug 与你没有关系，是由于开发导致的，那么你应该针对你之前最后一次验证的版本进行追溯，如果确实没问题，那么你完全可以理直气壮的说这个是开发自己改的。即使处理的时候，或许没有你想要的那么公正，但是你的工作是有目共睹的。所以每次测试之后自己整理个总结还是有必要的，长期的测试你完全可以预估出哪里是风险点，哪里需要重视，这些都需要你去沟通协调，并不是说分配给我的任务我做完就完事了。
开发和测试之间的忽悠关系
曾经一个开发跟我说，我不好忽悠。这话对于一个软件质量来说并不是什么好现象，当工作需要忽悠才能去完成的时候，那么就别对这个项目的质量抱有信心了，最近很多人在学自动化、开发语言，我只想说的事，如果真的想提升自己那么学这些无可厚非，但是你仅仅是为了显得高大上，显得自己很厉害，并且你的公司其实根本用不到这些，我建议还是打打游戏舒心一点。现在很多人都在赶时髦，追求时尚，学自动化，学的半吊子水平，写两行代码、会录制、会用个框架就认为自己学会了，从而忽略了一个项目最本质的业务，那么开发不忽悠你忽悠谁。任何工具都是为你服务的，那么最终的结果你为了工具服务，学习各个工具，在简历上或许挺好看，最后结果呢，定位问题不会，分析问题不会，那么如果我是开发我也忽悠你。对于忽悠这个问题，我只能说这个只能靠你自己的能力去让开发信服，举个例子，你用扫描工具说某处有漏洞，或者说输入字符长度报错，那么这个很 low，如果你利用这个漏洞直接侵入了，或者你不利用字符长度你发现了系统设计的缺陷、业务逻辑的缺陷，那么开发肯定对你另眼相看。
暂时先写到这，每一天的工作如果你想去做都是有激情的一天。不要去发现你不喜欢的点，要去发现令你惊喜的闪光处，例如今天食堂换菜谱了。
Monkey！！起床啦！！！！！！
