请选择行业
请选择职位
请选择省份
请选择城市

对团队内测试技术转型的思考

时间: 2018-07-30 13:17   作者: 周治平   点击次数: 
 

  近期感觉测试团队内部有一些问题,有的团队可能走的比较靠前,这些问题或许已经解决,也有的测试团队会遇到跟我们类似的问题, 还有的测试团队可能刚刚组建,在不久的将来或许也会遇到类似的技术问题。如果一个测试“老人”能在一个团队待的比较久,见证了 团队成长的过程的话,可能会对这些问题有更深的体会。

 

  1.从脚本化向平台化转变

  无论是自动化测试还是测试工具类的技术产出,其实都分布在以下几个层面:

 

  脚本化

  工具化

  服务化

  平台化

  先解释一下这个划分方法:从适用范围、时效性、使用方式几个维度来划分。

 

  适用范围从上到下依次变大,脚本化的东西可能只有编写脚本的那个人可以使用,只针对某个系统可以使用,按照顺序依次往下, 到工具化,可能整个小组内都可以使用,到服务化可能整个部门都可以使用,到平台化可能整个公司,整个行业都可以使用。

  时效性从上到下依次变长,一个测试脚本我们可能只能在一次测试过程中使用,到下一次测试可能就没有了使用场景, 可能就需要重新编写脚本。而平台化的工程,我们可以长久使用,代码被使用的时间长度和频率其实从另一个层面体现了代码的价值。

  从使用方式上来讲,脚本化的东西我们可能仅仅能在开发人员的本机使用,别的人要想用,非常不方便,要把脚本拷贝过去, 安装、配置好运行环境等,而服务化、平台化的东西,都有UI界面可以直接操作,直接打开浏览器就可以使用。 除此之外,外部系统要想使用系统里面的某些功能也很方便,以API接口提供出去即可。外部团队要想在不改原有代码的情况下增加某些功能,也可以通过插件的形式来解决。

  我们团队目前绝大多数的技术产出都在脚本化、工具化的层面。

 

  我们提倡服务化、平台化的原因,是因为我们团队已经渡过了脚本化的野蛮生长时代,每个人都有能力写脚本, 每个人都会产出大量的不太能够复用的、仅满足一次测试需求的脚本,而管理上统计产出的时候,每个人都乐于把自己所有写的脚本都展示出来, 好像大家都在说:“你看,我写的这么多脚本,我的绩效是不是应该好一点?” 这就从管理上形成了一个错误的导向,任何人写的任何脚本 (不管这脚本运行了几次,哪怕就一次;不管这脚本仅仅是我自己能用还是别人都可以用等)都属于管理上鼓励的范畴。 而事实上,我们已经渡过了那么一个鼓励每个人都写脚本的时代,这样的管理策略在前两年是没有问题的,但是放眼现在和未来我们的规划,这样的管理思路却是一种错误的导向了, 我们不缺脚本也不缺会写脚本的人,我们缺的是提取可以复用的脚本,将脚本整合、加强以服务化平台化的面貌展示出去,对内是技术能力的提升,对外也是影响力的体现。

 

  我们提倡服务化、平台化不是不允许写脚本了,在某些场景下写一些一次性的测试脚本可能也是必须的,也是一种用技术手段解决问题的一种方式; 你写的一次性脚本实质上是你测试过程中实现你测试思路的途径和工具,并不是说你写的脚本你就做的是自动化测试了, (写代码和做自动化测试实际上是两回事;写代码可能做的还是手工测试、做自动化测试可能在“基础设施“很完备的理想情况下,并不需要写代码), 所以实际操作的过程中,我们可以去写脚本,但是尽量避免去写大量的、运行一次就不在使用的、各种拷贝粘贴的脚本,在心理上也不要把这些脚本作为自己技术产出的一部分。

 

  2. 以“效能提升量”作为技术产出的唯一衡量标准

  以“效能提升量”作为技术产出的唯一衡量标准,而不是测试脚本、测试工具的产出量等;这是一个测试团队从鼓励野蛮的技术成长到精细化的技术管理的必经之路。

 

  “效能提升量”一定要有数据支撑,我做的这些工具、写的自动化测试用例对我有哪些实际的提升,减轻了我多少的重复工作量,提升了多少工作效率,节省了多少人日的工时等, 要有具体的数据来支撑。可能这些数据、指标一开始也不太好定义,这个定义、评估指标的过程也不是一蹴而就的过程, 需要经过不断的观察、调整、优化,和实际手工的、原始的、没有技术产出之前对比,尽可能的评估出一个尽量客观的数据,成为可参考度高的数据。

 

  为什么一定要有数据支撑? 数据更直观,横向比较,纵向拓展;对内激励,对外汇报展示; 而且这个数据不是拍脑袋拍出来的,而是经过相对客观的评估科学的统计的出来的。

 

  对系统有了很高的要求。这也正呼应了平台化的主张,如果只是分散的脚本化的东西,统计无从做起, 如果是平台化、服务化这些数据就相对容易可以收集得到。

 

  3. 在自动化测试、测试工具开发两方面的下阶段目标:自动化测试标准化、测试工具平台化

  自动化测试标准化:目前的自动化测试,大家各做各 的,采用不同的方式,不同的思路,不同的技术,彼此之间缺乏横向的比较和参考交流,也缺乏“效能提升量”的统计, 做了这么多工作,写了那么多自动化测试用例,实际带来有哪些好处,是带来的好处多还是投入的成本更大,没办法衡量。 本质是因为没有统一的自动化测试标准, 没有标准就不会形成规模,没有规模化也就很难产生收益。从“小作坊”到“富士康”的转变,对目前自动化测试来讲,势在必行。

 

  测试工具平台化:目前的测试工具多而零散,而且大多数功能比较单一、缺乏较好的UI交互页面、没有统一的入口,也没有“效能提升量“的相关统计; 我们只知道自己做了哪几个工具,同小组的其他人做了什么工具,不同小组的其他人我们也不清楚、也不关注他们做了什么工具, 我们也并不清楚这些工具做完之后,谁用了,用的好不好,哪些功能用的人多,哪些功能用的人少,这个工具到底给我带来了什么好处,还是我费劲做出来一个工具, 压根没人用,最后也就废弃了,等等。这些问题的原因,也基本上是因为工具还是脚本化、工具化的东西居多,缺乏服务化和平台化的东西, 不能统一风格,不能衡量效能提升等,是我们下阶段亟待解决的问题。


打印本页 | 加入收藏

上一篇:面试测试开发,公司主要考察哪些?    

关闭  
主要城市: 北京 上海 杭州 广州 南京 武汉 长沙
全部城市: