@槽神刘叫兽

前言&摘要       工作中总难免遇到一些不想见到的问题，但是遇到问题总需要去解决。解决问题的时候我们不提倡一条路走到黑，但是也绝不鼓励“朝三暮四”、“朝秦暮楚”等各种浅尝辄止。就像我们在做自动化测试的过程中，有些问题是始终无法回避的，如：测试工具缺陷、测试数据使用难以及开发人力投入较多等诸多妖魔鬼怪。我们若不去逐个斗过，也不知道自己战斗力到底有多强，最终也无法取得真经、修成正果。

话说我们部门巅峰时期曾经有150多人，后来由于集团业务发展，测试部门分成了两个，我们部门保有110人左右，另一个测试部门约有70多人吧。新生的部门我不了解，单看我所在的这个庞大的测试部门，我这两年来（除了今年，今年笔者不吱声了）一直不断地诟病方方面面的问题，向领导反馈但由于没有给出实际解决方案而最终无法“上达天听”，最后也就变成了敢怒不屑言，现在索性写出来给自己、给大家看看吧，或许从字面上能发现一

笔者在别的贴子里面曾提过，自己所在部门的自动化测试经历了几次步进式的建设，都具有阶段性的成果，但是总的看来却不是一个成功的案例。因为赶进度，仓促的投入让一大堆的脚本质量比较低下，有几个测试组由于没有人力投入自动化开发而又不得不完成自动化的KPI，只好聘请外包来帮忙完成自动化。理智地想一想，咱们花的那点钱请到过真正精通自动化技术又肯主动深入考察我们公司业务系统特征的外包么？况且外包终究还是要离开的，

细细算起来，在部落格里面前前后后写了约10万字关于测试或者自动化方面的看法，虽然看法未必成熟，但是回头看看都还挺有意思的。这一坨坨啰嗦的文字倒是记录了一个测试工程师的成长历程，我不想再拿新的观点和说法来博取诸君眼球，下面只简单摘抄一些以前写过的内容，补充点例子进去，再次强调并且与大家分享一下我对我测试工作的看法。   质量效益来自管理          质量大师约瑟夫·朱兰

题记：对于我们将要讨论的问题来说，以本人做看客的本领，只能观察体会个万一，要解决问题可以去咨询职业顾问。关于吸引员工或者挽留员工的办法，专家们能够提供很多精彩的案例，请大家移步去搜索“IT员工流动”等相关关键字，相信不会让你们失望。 离开比我早——不断惋惜和等待      年复一年，伴随固定的那几个月的员工流动大潮，不经意间我们身边的同事一个个各奔东西，他们的出走有的是为了更高的收入，

从一张表的索引想到的         我们有一张保单基础信息表pol_main，大约有500万条记录，算是一张中等数量级的表，它关系着大量的保险业务操作和相关查询功能。这张表的pol_sts（保单状态）字段的cardinality（基数）是26，这个字段上有个独立的索引；另外一个常用的查询字段plan_code（险种代码）的cardinality在1000以上，并且在逐年随着新业务模式的出现而增