最近一段时间，凌晨性能测试的事情比较多，工作强度比较大，不过好在上一天休一天，一整天的休息确实能在家多陪陪老婆孩子。问了小猴子，小猴子说还是希望我不要加班比较好，熬过这个双十一后面应该就没什么了。
在凌晨压测的时候，还是发现了很多平时的隐患，具体问题就不细说了，就一个事儿今天早上好好的说一说。就是测试里的“过”与“不过”。
传统观念里，软件测试一般是开发的“对立面”，是要找产品的问题，程序的bug，一个比较极端的说法就是想方设法的让自己的测试“不过”；但是实际工作中，产品开发时间的压力，上线时间的迫近，测试时间的压缩，造成了为了让测试“过”而造数据来让测试过，而没有真正基于业务逻辑来让程序跑通，部分节点可能用了假数据让测试用例通过的情况。
这种做法无疑是不对的，但是却又有了TDD（测试驱动）的萌芽，其实只要测试用例设计得足够充分，覆盖的逻辑足够，造的数据能够测通，其实就是产品通过测试，如果这样都测不过，那程序的问题其实还真的比较严重。这对测试从业者最大的挑战在于，需要理解整个产品的业务逻辑，并且先用开发设计思路完成覆盖所有业务逻辑的测试用例，展示细节检查的测试用例可以在开发阶段完成，甚至一边开发一边测试也是可以的。
引入敏捷开发流程以后，很多环节无论是对开发还是测试，都提出了更高的要求，但是也经常被抱怨不知道从何入手，产品需求不明确的频繁进行方向性的改动，或许才是最大的障碍，scrum master这个重要角色没有起倒应有的作用也是造成其他伙伴敏捷不起来的重要原因。
不断的磨合吧，业务方、scrum master、产品人员、开发、测试，这个闭环如何转起来，信息及时互通，才能让敏捷更好的实施。无论如何，办法总比问题多，只要是问题，就总要去解决，总会有解决的办法。毕竟计算机这玩意儿的问题，不会是玄学问题，总有起产生的原因，不是1就是0。
END.