当公司又买了6个QTP Licenses时，我悲催仰面。。

   一切从钱说起。。

   据我所知，公司买进的6个共享的Licenses是每个16k美元一年，相当于每个106.2k人民币。

   以我们组的规模14人分享总公司一半的Licenses,加上原有总公司的6个Licenses就是，我们可以实际使用6个licenses。

   除去老大做管理外，实际可能用到上述资源的就13个人。相当于2个人就分享一个一年十多万元的软件。而我们组的平均薪酬除去老大外，也就大概比这个数高一点。

  也就是说，公司还是很重视QAteam的，投入了不少资金，只是至少有三分之一是给软件的。

  而我的哀伤在于，首先，这个数额不菲的再投资不能给我们增强任何战斗力，我们该牛马的还是一样牛马。

                        其次，这份资源不能给我们加工资！

 

       很诚恳的说，原先的3个Licenses还是有用的，同是也是够用的。

       毕竟我们有一半以上的自动化测试代码在QTP上躺着。在没有任何多余精力把它们也转向Selenium之前，我们还需要他们在每次发布前乖乖的跑回归测试，并且保证对每一次新特性的跟进。

 

       下面具体说明一下"够用"和“牛马”的问题：

 

       1. 使用情况分析

        我们一个发布周期是6周，也就是30天的工作时间，在13人的测试一线团队中，最乐观的估计将投注于自动化测试中的时间平均下来也就是2天，相当于可怜的2%的时间。

        这2%是一个平均值，在每次发布中参加新自动化脚本编写的也就6-9个人。这6-9人中，最多的5天，最少的不足两天，所以以8人加梯度估计(5,4,3,3,2,2,2,1)，估计也就只能达到1.7%这个数目。我们仁慈一点，把每次维护老测试的成本大约25%算上是2.1%。再现实一点，把自动化测试总是被当做"additional effort","low priority"，被挤到自愿主动加班，不补贴不补假，除了电费不增加公司成本的宏观指示算上，就暂且允许在下给个2%的数值吧。

        当然在面对License冲突问题上，如果指示用平均值是说明不好问题的。

       我们再一起看看，在总周期6周中，有4周QA比较经常使用QTP, 其中包括4周的测试中的后两周，1周半的回归测试时间，和半周的上线准备时间。那么假设原有的3个License中有1个专门派去给周而复始不断地运行已有QTP脚本(实际总是有间断的),剩下两个给编写和维护。那么我们可以得到如下信息:

        4周的工作时间是20天。有两个Licenses就相当于有40天QTP的可用时间。

        基于上面的估算，一个周期内最多需要22天的QTP可用期。

       所以可以说在只有3个License的情况下, 在集中使用时期，我们也有1 - (20+22)/(20*3) = 30%的空余。

        于是，在原先就已有16%的测试资金成本投注到仅仅占用2%的人员成本的基础上，公司又追加了16%的成本，给测试人员在这2%的时间中武装到牙齿。真可谓是一件体贴到令人泪流的人本关怀啊~

 

       2. 下一步自动化测试趋势

       不错我们开始转向Selenium。Selenium和QTP的优劣势对比不是本文主题，所以在此不予赘述。在此仅表达下我们的现状，目前75%以上的新自动化脚本在Selenium上编写(RC)。所以QTP的主要任务只是维护之前的脚本，在其上添砖加瓦或打补丁。请停顿2秒，参考下上文的数字。

       在士气方面，我们自动化的主力成员现在都颇为反感继续维护QTP脚本，乐意扩充Selenium的覆盖率，其中的许多理由，也暂请留给其他文章细表。

       这里还是忍不住揣度下老板偏爱QTP,而漠视Selenium的原因：a, 出了问题，担心没有专业人士提供技术支持. b. 已经付了高价，如果不好用岂不是说决策失利？

       对于第一点，我们非常无奈。首先QTP的基础支持是实实在在的“零”。据说很久以前有人来做过极其基础主旨兼含推销的培训，之后就撒手没人管。其次，开源软件如果想找支持应该是便宜的多吧。

      对于第二点，我多少还理解些。

 

       3. 我们提高自动化测试覆盖率的主要症结

        为啥我们该痛的还继续痛，该加班的还继续加班。我们要的不是工具，是人！

        当任务压在面前，你知道要做好必须人工自动化两手抓两手都要硬的时候。你知道要的还有很多。

        当每次老板无比美好的许诺在下这次终于可以给你50%的时间深化开拓我们自由的自动化Framework，并交给一堆任务和期待的情况下，却对着资源分配数字摇头，说15%给自动化是过多。你知道路不好走。

        当拉着队友一起为提高自动化测试覆盖率，更为以后不需要如此辛苦而加班的时候。你不知道这样的路还要走多久。

        当自动化省下的时间，被直接划入整体应当缩短的测试时间，并且在每周期新项目数目点数都不断增加时。你是如此真切的希望自己再能跑快一点，快过新项目的增加。

        这时候，工具不是我们的心结，活很多，要人做呀。

 

       4. 人本问题的深化

        老板的出发点应该是好的，想让产品更有质量，卖得更好。那么老板为什么不选择聘人，培训，加薪，而是选择买工具呢？那么这里的理由又忍不住揣度下了。

        a. 测试的脑力技术含量不算高，也就敲敲键盘，开拓和创造力不作高要求。所以高薪人才是一定的浪费。

        b. 测试需要重复劳作，所以更需要机械测试。

        c. 测试是产品上线最后的关卡。不加大筹码也不太说的过去。

        综上，测试是power最小(因为技术含量，因为话语权)，而责任最大(肩负产品成功)。

        这也直接导致了在开发集体加薪和升职的时候，测试总是编外人员。而一旦产品有什么Bug，业务问题，系统问题，第一个找的人是测试，即便测试已经提交了相关的缺陷信息，而开发选择不予修复；即使测试已经发出了对业务的质疑，而设计人员不予理会..

         在长期的负面信息冲击下，花钱培养测试人员本身似乎在某种程度上是一种滑稽的浪费，与其砸钱买废材，不如买一堆”明码实价“的软件，安稳妥帖有回报的多。。

转载于:https://www.cnblogs.com/susanjiang/archive/2010/11/13/1876404.html