测试经理工作总结

2017测试经理工作总结范文

想知道测试经理工作总结怎么写的吗?想知道的话就让我们一起来看一2017测试经理工作总结范文吧。

3

篇一

时光荏苒，如今12年的帷幕已经谢下，13年的钟声已经敲响，在公司高层的正确领导下，我们佰腾科技又走过了一年。而我也在自己的努力以及同事的帮助下完成了2012年我所负责的工作，以下就是我对过去这一年的工作总结：

一、测试工作及经验

作为软件部测试组的一员，首先要做好的就是自己的本职工作，我在2012年中所做的工作主要有：

1.XXXXXXXX测试用例的编写，对系统的测试、跟踪;

2.XXXXXXXX需求、高保图、界面和功能的测试;

3.XXXXXXXX功能测试用例的编写，高保图、系统的测试;

4.XXXXXXXX的静态页面测试和功能测试;

5.XXXXXXXX的功能测试;

6.XXXXXXXX第一、二、三迭代高保图测试，测试用例编写，静态页面和功能测试，并主持参与测试用例评审;

7.XXXXXXXX平台高保图的测试和系统静态页面、功能的测试;

8.XXXXXXXX的高保图测试和测试用例的编写;

9.XXXXXXXX的静态页面和功能测试，参与测试用例的评审;

10.XXXXXXXX的高保图测试、静态页面和功能测试;

11.XXXXXXXX用户使用手册的编写;

一年的工作，让我获得很多方面的经验：

1.编写逻辑覆盖率全的测试用例甚为重要。在理解需求的前提下编写测试用例，使得我掌握了多种测试用例编写方法，更让我对产品的需求有更加深入的理解，须知对需求是否理解透彻决定了能否有效、全面地对产品进行测试;

2. 要站在用户角度对系统进行测试。从一些项目中出现的未能及时发现的bug中，我认识到用户体验的重要性，现在能够越来越多的从这方面来执行测试;

3.对拿到手的项目有较清晰的思路，能够更加快速、准确地发现问题;

4.越来越规范的工作流程的让我们的工作有条不紊的进行，让我深刻认识到工作的规范性是多么的重要，并且从中学习如何从文档和流程上规范工作。

5.同事间的沟通很重要。现在不管遇到什么不确定或疑惑，都与开发人员、

产品经理等及时沟通，大大提高了工作的效率。

二、加强自我能力的提高

只有不断的提高自己各种的能力，才能胜任越来越艰巨的任务，因此在工作相对不饱和的时候，我自己进行了一些学习。

为提高对“用户体验”的理解，我学习了《下一站用户体验》，书中一些经验确实让我获益匪浅。不能总拿别人的用户体验去改进自己的'产品，但是有一些却是通用的，比如：太多弹出框、按钮会给用户带来愤怒感，要适当的给页面减肥等等。

深知单纯的界面测试和功能测试已经渐渐不能满足今后平台的开发，所以我学习了性能测试的一些相关知识，并在师父的指导下运用LR工具进行简单性能测试，以后必须坚持学习。

三、存在的不足及明年计划

一年的工作让我有所进步，但是很多地方还是存在不足，比如：有时候看问题比较主观，不是很细致，没能深入地去测试，会有遗漏的bug;自身专业技术能力还不足，不能从系统稳定性这一点上对系统进行测试。在以后的工作中，我会努力改善。

在2013年的工作中，我计划：

1、本着实事求是的态度，更加认真、负责的完成工作;

2、要尽可能深刻的理解需求，坚持编写覆盖率强的测试用例;

3、按照系统稳定性测试方案，要逐渐对系统的稳定性、安全性进行测试;

4、继续研究性能测试，并要将LR工具运用在实际工作中;

5、多多的学习，参加一些有益的培训，在实际工作中活学活用。

四、个人建议

这一年来我们部门有着的显著进步，越发规范的工作流程，越来越明确的责任制度、管理体系等，都让我们更加有凝聚力。在此，个人提出以下几个小建议：

1、希望可以加强对项目的把控，尽量能将延期风险降到最低;

2、从各个组对需求理解的不一致，以及信息更新不及时等问题上看，沟通

问题还是有待完善;

3、希望能够在需求这一关卡上能更详细、准确的确定产品的功能要求;

4、虽然工作任务繁重，还是希望部门能够多组织活动，完善奖励制度，可

以让大家更加激情的为部门、为公司奉献自己的全部力量。

以上是我个人的一些浅见，相信在大家共同的努力下，向着同一个目标进发，软件部甚至整个公司必定会大展全新的宏图伟业。

篇二

20xx年本人作为应用小组的经理，和ys一起负责应用小组的工作计划制定、日常事务组织等工作。日常工作主要围绕以下四个方面展开:

1.制定应用小组的每周、每月工作计划，并落实追踪。

2.做好项目性的管理工作

3.根据404的要求推进日常规范化工作

4.根据年初制定的信息技术部考核指标，对地市信息进行绩效辅导。

回顾20xx年，应用小组的年度重点项目有以下十个方面:

1.协助各个部门完成核心系统运维23888件，平均每个月2179件，这是我们小组成员日常化的一项工作。通过这项工作让我们了解了公司的经营管理、理解了客户和内部员工的需求、了解了风险管控对于公司的重要性。

2.3-6月份我和cf参加总部服务台项目开发，同时担任该项目的现场经理。通过这个项目我了解了it部门的基础管理的先进理念，这对我进一步从事it方面的工作影响深远。

3.我们完成了业务受理系统在新契约方面的上线工作，这是一项非常具有开拓性意义的项目，它承载了我们三个方面的理念：第一将中国人寿集中处理的优势转变为集中管理的优势，将网点的优势转变为服务的优势;第二实现受理和处理分离提高工作效率，提升公司的服务形象;第三这是对新一代核心系统“瘦核心”的一项有益的尝试。

4.协助个险部门完成收展系统全省上线，同时实现全省孤儿保单的区域化划分，利用现有的资源，深度开发，拓展业务;建立新的销售渠道，培育新的增长点。在高效利用客户资源的同时做好差异化的经营准备。

5.协助总部完成统一收付费项目开发和上线工作，这个项目包括统一收付费、统一转账、银联收付费等，提升了公司的市场服务能力。其中银联收付费项目，不旦可以为柜面零现金工作作出巨大的贡献，并且我们构建的银联前置系统，在整个保险行业也属于领先的水平，这从这个意义上来说我们构建了一套保险公司和银联交易系统的交换标准，为将来进一步的应用打下坚实基础.

6.协助总部完成首期代扣流程调整的开发和上线工作新单首期代扣是我省引导客户缴纳新单保费的一种非现金收费方式，通过首期代扣可以减少现金流，提高非现金收费率，降低经营风险和管理成本;同时新的流程大大缩短代扣的周期，这一点将深受营销员拥戴也有利于销售部门对业绩的追踪。

7.协助财务部门完成新一代财务系统上线工作，这个系统结合了中国人寿未来发展战略和经营管理模式，“矩阵式经营管理体系”是整个系统设计的核心;流程设计方面，在兼顾各级业务流程差异性的基础上，系统进一步规范“省级集中”的管理流程。

8.协助个险部门完成amis5.0上线amis5.0是基本法的最主要载体，是营销管理的核心制度，这次amis5.0的上线，在做好基础应用的基础上，我们在“利益导向”、“佣金激励”、营销员保障三个方面继续保持了福建省基本法在全国的领先地位。

9.20xx年我们构建了数据质量监控系统，我们认为治理的关键在于预防，通过主动发现将数据安全的隐患扼杀在摇篮中，今后这项工作将成为我们日常工作的一个重要组成部分。

10.协助总部完成了航意险实时出单的开发和上线工作，为将来这种类型的'销售模式探索了一条可行的道路

另外我们还协助相关部门完成了各个阶段基础率分析、精算、留存业务清理、数据报送等阶段性工作，由于时间关系不做一一列举。

20xx年对我个人来说，有两个方面得到了提升

1.团队经营的能力有所提升

20xx年我们尝试将应用小组作为一家公司来经营，以公司运营来看待团队管理，我们经常这样问自己：如果我们这十多个人的团队作为市场竞争的一个主体，人寿保险公司凭什么把每年的基础运维工作交给我们来做?我们的竞争优势在什么地方?我们如何“盈利”?我们必须在成本分析、基础服务、创新等方面提高市场竞争力。

2.对于itil理念的理解加深(信息技术基础设施库)

我认为公司的404教会了我们应该如何去做工作，itil教会我们如何将这些工作落地。未来it的服务是可以定价的，公司员工作为it的客户，能够很清楚知道自己可以得到什么样的it基础服务，以及服务的时效。现阶段我们要实现这些方面还很难，从平凡到卓越的路程有很长，当前我们应该着手去构建的it基础应该有：it服务台(作为it服务的透明窗口)、突发事件管理、问题管理、配置管理、变更管理、版本发布管理等。只有把这些基础工作做好了，我们才能够逐步实现it管理的卓越。

20xx年也有两个方面的不足

1.团队经营管理的能力不足，这个课程对我来说还很长，需要在工作中用心摸索实践

2.对于工作的追踪落实力度不足

对公司业务发展、经营管理的合理化建议有五点(站在it的角度)

1.加大流程再造速度

流程改造可以降低成本、节约时间、提高效率。流程的再造依据四个方面的原则：第一全流程的考虑，是多部门的事情不是一个部门的事情;第二强调运用it工具的重要性，以自动化、电子化取代人的工作;第三重新思考流程的目的性，使流程和经营管理目的相结合;第四重视逆向思考。

2.充分利用我们职场的优势，将服务延伸到销售的终端，充分发挥国寿网点的优势，制衡同业，应对竞争。

3.继续深入收展体制改革，完善收展基本法。将区域收展和精英化服务思想融入日常经营管理中。

4.统一客户的视图，逐步建立较为科学的客户分析指标体系，实现客户宏观分析、细分分析。建立投保人保险缴费模型，被保险人保险保障模型，挖掘客户保险需求、一般性销售规律，辅助公司产品销售。

5.提供适合市场竞争的各种技术支持，从某种意义上这是一个将公司做“小”，客户做大的过程。可以通过三种方式将公司做“小”：一个是合理外包、二是强强联手，比如通知书邮政寄送、三是借助互联网。这些市场竞争的支持包括：航意险、城镇医疗、困难家庭救助、乘意险等。

20xx年部门的工作指导思想是：建立以价值为导向的工作思路，更加关注公司管理层、应用部门以及基层公司的年度经营管理思路，通过精细化的it服务，体现it的工作价值，发挥其生产力引擎的作用，在组织流程优化和提升市场服务方面做出努力，提高公司的整体运营能力和效率、降低成本。新的一年我们仍然会围绕这一主题开展工作。

篇三

我是在20xx年5月到新单位工作的，新单位是一个很不错的单位，项目饱满，资金等方面也没有太多的问题，但就测试部门工作的情况却很不乐观。具体表现是人员少，任务重，人员不稳定。领导对测试部门的工作很不满意，在面试我的时候就多次表示了对公司目前测试不满，期待我来之后能够带领测试部门有一个比较好的发展。

首先说说我们公司测试部门在这四个月的变化吧

1 测试人员大量增加，原来的测试人员为3人，现在为14人，人员扩充了3倍，目前来说，测试人员的数量还不是很多，但相比原来部门的扩充速度还是很快的，另外一个方面，由于我们工作比较有成效，领导基本认可开发人员和测试人员比例可以达到1：0.8或1的比例。我想这个比例对一个国内的企业来说已经是很高的比例了。

2 个人素质的提高。具体的个人素质提高不是很好说，还是用项目来说吧，我刚来的时候，测试人员在一个系统测试的时候，一般测试需求点位500个左右，后来一个项目在作回归测试的时候，测试需求点达到15000个，第二次回归测试的时候测试需求点达到了49000个，这里要说明的是，我们测试需求点的增加不是为了增加而增加，而是对被测试需求各种使用情况分析的更详细，程序覆盖强度越来越大的结果，测试发现的问题深度逐步增强的反应。

3 机器设备的变化，测试人员是开发群体的弱势群体，他们的机器配置也是公司最低的，刚来的时候，全部测试人员都使用P4 1.7完全不能满足自动化测试的需要，目前，测试人员基本都是P4 3.0双核，液晶，测试人员很高兴。另外我们还有专门的测试流程管理服务器，一些淘汰下来的老机器作为专门跑测试用例的测试专用机。

4 开发人员对测试人员的态度改变。测试人员在开发过程中处于弱势地位，这是一个不可回避的现象，原来开发人员可以随意的让测试人员作自己认为需要的测试，而测试人员是没有办法拒绝的，甚至连具体测试的方法和手段开发人员都要干涉，而一旦出问题，首先怪罪测试人员，而不是找自己的责任，测试人员成了项目失败的替罪羊。而现在这种已经发生了很大的改变，至少测试人员有能力展示他们的特长。而不是开发人员的附属。

5 领导对测试工作的态度转变

我刚到单位的时候，领导们对测试工作很不满意，给我印象最深的是领导说，测试部门的工作人员，可用的就留下，不可用的就直接开除，这对测试人员的工作评价实在不高，现在好多了，首先测试部门现在的工作得到了领导的认可(原来我们总是被批评，而现在总是被表扬)，其次，人员、设备的配置在增加，最重要的是，我们要求的测试时间可以得到保证。

到单位工作4个月了，测试部门出现这么多的变化，有很多原因，但最重要的就是那句话：做正确的事情，正确地做事情。

个人认为做正确的事情比正确地做事情要重要，道理很简单，中国的一句成语，南辕北辙是最好的解释了，如果不能了解什么事情是正确的事情，那么你做事情的.效果越好，则整个项目失败的可能性越大。下边先说说我到单位做的几个事情。

1和领导达成一个协议

和领导达成一个协议是一个很关键的事情，我在面试的时候，就了解到了领导们对测试部门的工作很不满意，希望很快扭转测试部门目前的工作状态，但一个部门工作状态的改变不是一件很容易的事情，在面试的时候，我就和领导们达成了一个协议，争取测试部门在3个月内有一个小变化，6个月内有一个大变化，12个月内形成一个良好的工作环境。领导是 一个明白人，没有强迫我在几天或几周内就要 有一个大变化，这为我们部门以后的发展打下了一个良好的基础。

2了解单位的工作情况

3了解单位工作的问题

4订立规则

5组建自己的团队以及核心团队

6协助其他人做工作

测试人员工作分配不均，严重影响工作情绪

在我来的时候，测试人员都是被配置到项目组，开发人员有测试需求的时候都是直接找到本项目组的测试人员，由于各项目进度不一，造成在不同阶段测试人员的工作量严重不一，真是忙的忙死，闲的闲死。另外还有一个问题，有一些比较好的测试人员会主动帮助其他测试人员，而一些懒惰的测试人员作会坐在一边装作什么都不知道，结果是好的测试人员忙死，其他人闲死。

4订立规则

在了解了测试部门当前的主要问题，解决的方法就确定了，具体方法：

A：首先是订立规则，说简单点先确定测试部门内部规则，我规定测试部门只接受系统测试，不接受单元测试和集成测试，说简单点，测试人员进行的测试必须是一个完整的测试周期，最短时间是2周，这样才能保证测试工作的最低测试强度。

B：我向测试人员明确测试人员是软件开发过程中的专业技术人员，他们的特长就是测试技术，在测试技术上测试人员不能比开发人员水平低，所以，他们的测试工作要保持自己的独立性，问题的发现是他们作主，至于发现的问题是否是BUG，是否需要修改，这是开发人员(确切的说是项目经理)和质量保证人员来确定，但是否是问题是测试人员来决定，测试人员判断是否是问题的标准就是测试结果和测试预期结果是否相同，只要不相同，就算问题。其他人员无权对这个原则提出异议。

C：为了保证测试的独立性，我要求测试人员在测试过程中，不要和开发人员有过多的交流，如果有交流也仅仅限制于关于系统如何使用方面(我们没有很好的开发文档)，其他的一概不和开发人员讨论，这种方法虽然会对开发工作有一些阻碍工作，但在测试工作当时的工作状态下是很必要的，否则整个测试工作的独立性根本无法保持。

D：使用测试流程管理工具，我们原来的测试计划、测试用例都使用word文档来管理，很不方便，我来单位后，采用了专门的测试流程管理工具，也就是说一个完整的测试，首先写测试计划(主要内容是测试人员，系统需求，时间等方面的信息,这个东西还是使用word来编写)，其次是测试需求点、测试计划(这个测试计划是我们测试用例执行的先后次序)，每个测试用例的测试步骤，以及发现的所有问题。在最近的一段时间，通过测试工具的使用，使我们测试需求点的管理从不规范，随意写，到有条理，有顺序，有了很大的变化，我们的一个系统，在我来以前测试需求点大约是600个。在我们后来的几次回归测试中，测试需求点，分别为20000，500000，60000个，测试需求点的变化，说明了测试强度的增加和规范。

E：测试结果需求评审，否则不进行回归测试。这是一个原则问题，确切的说测试人员在开发过程中不能直接创造价值，他们的工作必须通过开发人员才可以得到体现。开发人员是否重视测试中发现的问题，是否对这些问题进行认真的评判和修改，不但关系到测试人员工作价值的体现，而且对测试部门工作安排也很重要。在我们测试的几个项目中，如果开发人员认真对待测试结果，一般来说，进行1到2次回归测试，整个系统bug就会呈现出收敛状态，否则，测试人员需要无休止的测试。在测试过程中，我一方面保证测试周期的时间的要求(最少2周)。一方面，和质量保证人员配合，对于那些不认真对待测试结果的项目组，采取不评审，就不进行回归测试的方法。(反正项目延期不是测试部门的责任，有点无赖，但有时候也是没有办法)。保证了测试的有效性。