今天想谈谈测试人员和测试工具的关系问题。
从02年开始接触测试，我用过了无数的测试工具，通信行业需要的测试工具要比互联网复杂得多，因为需要仿真通信时遇到的各种问题。测试工具可以定制各种消息，各种网络环境，还有各种异常。一般非常专业的测试工具都是需要购买的，价格不菲。基于自动化回归，诺西做过robot，让测试人员通过表格化的方式来写测试用例。手工测试和自动化测试花费的时间比差不多是1:5到1:10(《人件》当中有详细的阐述)。自动化回归发现的bug是相当少的，也没有人会去统计这个数值。我相信除非禁止了手工测试，否则自动化回归发现的bug永远都是相当少的。自动化覆盖率大幅提高的同时，customer pronto的数量也在大幅提高。但我并不清楚其中有没有必然的联系。很值得去分析一下。
到了互联网企业，测试工具就要简单得多，基本上用于自动化回归。TC的管理也没有通信行业复杂，不需要把用例和需求关联起来，也不需要统计用例对需求的覆盖率。
互联网企业喜欢自己写测试框架，这可以理解，因为相对来说功能比较大众化，比较简单。用开源的框架就可以了。自己写框架，可以提高响应速度，任何个性化的需求都可以得到快速的满足，这挺好的，对测试人员来说也是一个写代码的锻炼机会。
但是工具仅仅是工具而已，测试人员会用工具，可以提高测试的工作效率，就够了。测试人员更重要的工作是发现bug，当我需要用工具的时候我就用工具，当我不需要工具的时候，我完全可以不用。
这么简单的道理，我相信人人都明白的吧。
可是，现在好像很多人都不明白这个道理了。
首先，我们来谈谈我们为什么要用工具。有句话叫做，磨刀不误砍柴工，磨刀是为了提高砍柴的效率。对吧？那么，到底是磨刀好呢，还是砍柴好呢？没人care，大家只care最后柴砍得好不好，快不快，多不多。如果只砍柴，不磨刀，柴就会砍得慢。如果只磨刀，不砍柴，那就更糟了，没柴用了。
我会认为，一个好的樵夫，肯定会重视磨刀，但是磨完了刀他会去砍柴，磨一次刀可以砍好几天的柴。一个好的测试人员，肯定会想办法提高自己的工作效率，善用工具，没有工具的时候会创造工具，但是他还是会专注于测试。
一个好的管理者，会在乎最后柴砍得好不好，而不是看这个人会不会磨刀。会不会磨刀不重要，重要的是，是不是需要磨刀，需要磨刀的时候才磨刀，不需要磨刀的时候硬要去磨刀，也不是一个好的樵夫。对吗？
测试人员和测试工具的关系，应该是使用和被使用的关系。一个好的测试人员，更关注于自己的测试工作是否能够高效率的完成。怎么样可以更好地做好自己的工作，就怎么做。没必要做任何工具都要去给别人用，都要做成一个框架，都要有影响力。考量KPI的时候，判断晋升的时候，看这个测试人员做了多少给别人用的工具是毫无意义的。
我不希望看到测试人员为工具所累，更不希望做工具会成为考量一个测试人员的标准。一个测试人员有好的开发技能不需要体现在做了一个测试框架和测试工具上面，而是需要体现在需求评审的时候拒绝了一个无用的产品，技术评审的时候阻止了一个愚蠢的设计。我记得有个老大曾经说过一句话，测试人员要比开发懂业务，要比业务懂技术。我觉得这句话很靠谱，我也是这么做的。我也常常做工具，只是为了提高效率，但不会以此为目的。有人说过，优秀的程序员需要三个宝贵的品质：懒惰、急躁和骄傲。懒惰就是讨厌重复的工作，重复劳动用自动化来替代，急躁就是不耐烦做复杂繁琐的事情，骄傲就是相信自己能做出最优秀的产品。其实测试人员也是一样的。一个好的测试人员，会用聪明的办法解决自己的问题，会在问题中总结经验教训，会在成功的产品中留下自己的身影。
所以，当测试人员都争先恐后地去做工具的时候，我感到非常的茫然。这是怎么了？在一个开源框架的基础上做出一个几十或几百人用的日常工具就这么有成就感吗？就这么容易被认同吗？难道去和PD、开发一起做一个几百万或上亿人使用的优秀产品反而没有那么大的魅力了吗？买家和卖家认同你的产品，可以从你的产品中得到服务，得到订单，去改变现状，难道不比做一个日常管理bug和用例，管理自动化回归的测试框架更有挑战，更有意义吗？
