2016-2017年度测试工作总结

“唯一不可阻挡的是时间,它像一把利刃,无声的切开了坚硬和柔软的一切,恒定地向前推进着,没有任何东西能够使他的行进产生丝毫颠簸,它却改变着一切。”

16年的工作总结

想了想,16年值得聊聊的就几件事:

  1. 测试团队的重组。这个没啥可聊的,今年又要出大招…(生无可恋的表情ing…)
  2. 测试人员的培养。经历了三个季度的技术培训,虽然没达到我想要的效果,但至少每个人都可以写自己负责模块的UI和接口自动化了,唉…17年技能培训还是要继续的,但是打算换个方式提高大家的主动性和技术提升的责任感。会在17年的计划中详述。
  3. 接口自动化的尝试与总结。通过测试专家的指导,历经九九八十一难,我们搞了一套自己的接口自动化小框架出来,其中需要总结的是,这套框架并不适合类似应用商店这种高复杂度的项目,强硬的往进套只能适得其反,与后续接入的浏览器、搜索形成鲜明对比…而后通过两位测试技术负责人根据业务特点对框架的再次封装与修改,使得应用商店和主题美化也顺利的接入,不过这块还是17年需要优化的重点。
  4. 流程优化。我们在各个业务中都做了一些小的流程优化,比如:主题美化的各模块测试接入流程、桌面布局的发布流程、预装应用项目合入流程优化,这些优化在团队内部见到了一定的收效。但是由于各种沟通不畅或跨团队的合作,导致一些人不清楚已被优化过的流程,还会踩进一些老坑

      针对以上情况,我们在流程优化后,不仅需要在邮件中各种cc,还需要形成文档,并放到一些类似redmine的公共项目平台中,尽量避免此类事件。

      16年总结就酱吧…感觉今年写了好几遍了…

 

 

17年的目标与计划

主要从七个方面来讲:

  1. 建立BUG预防体系。预防BUG的出现,从源头上控制BUG的数量,我觉得这是个不错的话题。通过收集BUG的相关类型、描述、产生原因,来完善项目流程,制定开发、测试规范。收效可以通过千行BUG率及上线后的用户反馈数据来衡量。有一些小的想法,如下(BUG预防需要有足够的数据收集,这块会在测试管理平台的搭建中完成,完成平台搭建后再做预防体系的建立,所以这块预计会放到Q2或Q3的目标中):持续的项目、测试流程优化。16年多多少少做了一些项目的流程优化,不过绝大部分是从项目经理或咱们几个开始推的,17年我觉得可以把这块放到具体测试人员身上,毕竟执行者才是对流程最熟悉的人,只是大家可能对优化流程没有明确的想法,这块需要我们去鼓励推动。持续的项目、测试流程优化。16年多多少少做了一些项目的流程优化,不过绝大部分是从项目经理或咱们几个开始推的,17年我觉得可以把这块放到具体测试人员身上,毕竟执行者才是对流程最熟悉的人,只是大家可能对优化流程没有明确的想法,这块需要我们去鼓励推动。
    1. 可以将BUG分类为:功能类F,数据类D,界面类UI,性能类P,崩溃类C,偶现类A,其他类O
    2. 每个BUG级别中定义各种BUG的类型,每次测试人员对BUG的优先级标注可以是类似:F-1(功能类,严重级别),UI-5(界面类-建议级别)。
    3. 先收集数据:在BUG分析中填入BUG类型、描述、出现原因
  1. 持续的项目、测试流程优化。16年多多少少做了一些项目的流程优化,不过绝大部分是从项目经理或咱们几个开始推的,17年我觉得可以把这块放到具体测试人员身上,毕竟执行者才是对流程最熟悉的人,只是大家可能对优化流程没有明确的想法,这块需要我们去鼓励推动。17年关于这块的目标如下:
    1. 各个业务每个季度至少有一项流程优化成功推行
    2. 敏捷流程?(据说之后会有个敏捷专家来深分了解情况,提出建议,期待中)
    3. 测试驱动(待研究的领域)

3. 持续集成测试的建立。这点可以算是重中之重了吧,在我们考虑着如何从内部的众多平台中汲取精华结合业务特点建立我们自己的持续集成平台的过程中,项目组的目光也集中了过来,可以说持续集成测试不单单只是测试的一个环节,在敏捷盛行的今天,它直接影响着项目团队的迭代节奏。基于此,持续集成测试的建立,可以用项目的迭代周期及线上用户反馈率来衡量。17年Q1计划完成的目标如下:

    1. 全部业务移动端的基础功能及性能自动化覆盖100%,并接入ATS
    2. 全部业务服务端的接口自动化覆盖率达到80%以上,并做到持续集成
    3. 通过测试管理平台整合各个测试流程上的数据,达到初级的持续集成测试目标

4. 测试团队测试技能与技术的提升。16年通过对团队成员的Uiautomator及接口自动化的培训,使全部测试人员达到一个可以编写自己负责模块自动化用例的程度。17年主要方向是各个业务的代码走读,希望通过这种方式提高大家对业务逻辑的认知度和对BUG分析的深入程度。其实,从去年的培训中,我们也能看的到,技术的提升很大程度上取决于个人的兴趣程度,我们不是吃大锅饭的,所以今年的技术提升,会挑选合适的人员(对技术感兴趣,有基础,能在测试中找到成就感,有激情~~)。17年Q1计划完成的目标如下:

    1. 各个业务每周一次的团队代码走读(前两个月会先让几个业务中的技术负责人帮大家走读代码,有一定收效后,要求组内成员轮流进行代码走读)
    2. 会有针对性的高压一部分看似有能力的人,关于人员培养方面,与其说大家的建树不高,倒不如说我们给的机会不多,前两天也和资源池的负责人商量会给一些测试辅助工具开发的任务给到新同学身上,看下实际产出如何。

5. 引入人才与新技术提升测试效率。这点就不展开说了,从现状看,目前我们还达不到持续研究、接入新技术的层次。但还是要有些小目标的。So,17年Q1计划完成的目标如下:

    1. 性能测试小工具的研究与引入-弱网篇
    2. 期待新测试“砖家”的加入能够带来一些新技术~

6. 线上监控与故障定位(略远)。这一点是有辣么一点点远,前提还是建立了相对完善的持续集成测试,希望的场景是:从测试人员的角度出发,我们通过BUG的分析及数据的收集,对线上业务进行准实时的监控,能够针对报错的问题进行快速定位及反馈。这点木有目标啦…

    1. 对外交流。希望通过与其他高逼格测试团队的交流,引进新技术并优化现有流程吧!之前和丽艳也聊过,希望可以把咱们内部的一些同学推出去,我觉得这个可以算一个长期目标,我们试着努力从内部打造一个测试专家吧,哈哈,这个是不是巨远…

 

 

关于个人成长

  前段时间看过一篇文章:职场“中等收入陷阱”,有一句让我印象特别深刻的话:只要你所解决的问题,层次跟以前一样,你就无法通过努力工作变得更有钱。

  很直接的回想起老大在我的年终绩效评语中写的:避免一直埋在具体的工作细节中,分清主次,避免将大量经历投入到低价值的事情上。

  总结以上两点,16年给自己一个年度关键词:格局太小!另外,证明能力的关键在于,你解决了什么样的问题,而不是付出了多少努力。结果为导向意味着站在结果的角度去考虑问题。这让我不禁反思,任何事情努力做了,没有改变,没有输出成果,又占用了资源,这是一种“无与伦比”的浪费 -_-|||

  17年始,先给自己一个忠告:放开格局,以结果为导向考虑问题!

             

个人成长这块想说的还很多,但是要给自己一些时间来整理,所以就先不啰嗦了。为了不为无知、目光短浅买单,避免自己以后的职业生涯变得一塌糊涂,每一年都要重新整理一次长期职业规划,明确目标,并利用每一年的时间去追赶!吼吼!

 

 

posted @ 2017-01-07 19:53  kelfy_mu  阅读(1414)  评论(1编辑  收藏  举报