不知道大家知不知道，测试人员最重要的责任是什么？
    是pass case吗？大错特错。
    测试人员写case不是用来pass的，而是用来证明我们的产品质量的。只有当我们的case全部pass的时候，能够证明我们的产品已经坚不可摧了，我们才真正完成了任务。
    如果case都pass了，如果我们还会被用户骂，那就是我们的失职。
    所以，别在乎project manager来催问你pass了几个case，如果你的case能够发现很多问题，那么这个case比不pass更有价值，你对公司的贡献更大。
    我们跟软件人员的思维是完全不同的。软件人员在创造产品，而我们是在破坏产品。我们每天都要想，我要怎么折腾，才能把这个系统给搞死？我们就好像网络***一样，无时无刻不在探索系统的瓶颈和漏洞，我们不是在粉饰太平，而是在不断地提醒管理者严酷的现实。我们是把关者，而不是放水的人。
    case有没有pass不是我们需要关心的，我们需要关心的是，我的case是否测到了所有的问题？我有没有放水？我对产品的质量究竟有多少贡献？我测试通过的产品会不会被客户投诉？我对我的case有多少信心？
    三年前，记得我有一次在公司大楼坐电梯的时候，有个清洁工在擦按钮，结果一下子把所有的无需验证的楼层全部擦亮了，我当时觉得很有意思，想这个电梯会不会每层都停呢，结果电梯停到最近的一层时，就把所有的按钮全部置灭，包括我按的需要验证的按钮。大家面对这个功能，想想看你该怎么去测试呢？这个功能的实现究竟合不合理？
    我们现在常常抱怨电梯的算法非常愚蠢，我们作为测试人员，该怎么测试才能证明这个算法是愚蠢的呢？

    我们的系统也常常会做很多愚蠢的事，但是很遗憾，我都没能从测试人员那里听到反馈。很多feature，我至今也只能获得N年前simulation的结果。这个feature已经做完了，带来了无数的bug，可是没有人能通过测试证明它当初吹嘘的那些好处。
    我们作为测试人员，代表的是最终用户，我们跟软件人员和项目经理的目的是不同的。我们不仅要证明那些说明书里号称的功能都能用，而且要证明用户会很满意。所以我们不仅仅要关注功能本身，还要关注整个产品的用户体验，产品是否够稳定，是否够快，是否够聪明，是否够安全，是否真如说明书吹得那样好？如果答案都是否定，那么我们的产品谁会喜欢呢？