测试部年终总结

时间：2024-07-09 15:00:35 学人智库我要投稿

相关推荐

测试部年终总结

在实践中二者常常是揉合在一起，相得益彰。运用所学知识处理实际工作的能力主要通过实践培养起来的，绝不是天生的。因此，总结是提高能力的重要手段。本文为测试部年终总结范文，让我们通过以下的文章来了解。

测试部年终总结

范文一

回顾这一年里的工作收获颇多。年初一直在参与中行对公系统的测试工作，中国银行对公代客资金管理系统已2月份对公系统顺利投产。紧接着春节后又开始了xx银行的X-FUND2.0项目的全程介入测试。跟随项目组一同到北京现场开发测试，以及后期配合用户的压力测试，项目投产内部演练和支持等工作。目前中信X-FUNDS2.0系统也已经投产完毕。

8月份后回到公司，主要从事公司内部集成测试和系统测试工作，主要测试系统包括福建分行日积月累系统、SGE与K+接口管理系统、xx银行利率衍生品交易系统、浦发银行离岸交易系统、中国银行新一代做市商系统等。目前正忙于新一代做市商系统测试工作，该项目计划年底投产。

补丁测试方面主要有部分辖内对公系统补丁测试、部分中行对公代客管理系统补丁测试、澳门资金管理系统补丁测试、中信X-FUNDS2.0系统补丁测试等。

压力测试方面主要有中信X-FUNDS2.0系统、中信外汇电子交易系统压力测试、统一登录系统压力、浦发离岸系统压力、新一代做市商系统压力测试等。

从年初的中行对公项目到xx银行X-FUNDS2.0项目再到中行新一代做市商项目。一个个项目完成测试任务并顺利投产或进行中。

从本年度内主要项目的测试及跟进客户测试方面经验教训进行总结，以便更好的提高项目介入测试的质量和完善自己的能力与不足之处。

一、测试组内部要有计划。介入项目测试以后，理论上讲是应该配合项目组的测试工作。但个人认为这样测试组方面工作会比较被动，跟随项目组指定的测试并不能比较全面的覆盖到系统全部功能或者绝大多数功能。如更新一块，就让你测一块，这样无形中就会疏漏其他模块。测试组内部可以根据项目整体工作的安排情况也应该有自己的测试计划，即完整测试轮次的计划，这样能更好的把握系统整体功能情况。这部分工作在进驻客户现场测试时应与项目组长沟通，明确每日工作流程，如版本更新时间约定、内部更新测试安排以及配合指导用户测试等工作。

二、项目的测试进度控制。主要是按照项目计划进行的，按照项目组计划要求完成测试任务、提交测试类相关文档，包括制定内部测试计划、测试案例的完善、执行测试、缺陷跟踪以及BUG回归测试等。协调项目的内部测试工作，配合项目工作，共同保证项目质量。项目测试的问题跟踪及处理采用每日进行修改问题回归测试工作，每日同步更新问题跟踪单的模式，按照规划时间完成系统更新测试等。

三、要加强学习和沟通。在进驻客户现场测试后，测试人员的工作要配合项目组，也要指导和协调客户测试。项目组内部共同探讨解决问题的方法，向各模块负责人学习模块功能处理方式，向业务人员了解系统中涉及的业务知识点，两者结合起来进行模块功能测试。与客户接触吸收新的业务知识，积累测试方面必须的业务知识点，这些都做公司系统测试应有的测试基础，或者说银行金融行业项目测试工作的素养。也可以进步一提高与客户、与项目组内的沟通能力和协调能力。多参考客户测试的测试案例及测试过程中提出的问题，也能为自己的测试工作打下一个好的基础。

四、善于总结和吸收项目经验教训。总结回顾以往的项目测试经验可以更好的指导以后的测试工作，也会提高系统缺陷和业务处理流程方面不合理情况的发现率。测试出来的问题与项目组沟通也会比较容易.。鉴于以前的项目经验，也可以向项目组提出了一些完善性意见和功能实现的处理方式。

五、个人得失及不足。作为几次项目测试的负责人，对于日常的测试流程、测试任务分配、测试执行、缺陷跟踪、协调内部测试及协调客户测试方面能力均得到了进一步提高，理清了项目整个过程中测试小组的工作过程以及后期的项目移交工作。同时也对系统相应的业务知识有了更进一步认知。相关业务知识方面还需要进一步加强，测试技能及测试管理方面还需要进一步完善学习。更好的吸收项目经验，做好以后的补丁测试工作及其他项目的测试工作。

项目测试中，维护部门配合介入的测试工作比较难分配及管理。维护人员并不是很积极从事项目的测试工作，且分配的任务也不情愿去完成。在中信X-FUNDS2.0项目和新一代做市商项目组中都能明显体现出来。他们多是认为项目组的测试过程中的工作不属于自己的职责范围，认为自己只是一个简单的配合过程，要求加班时间要么不来，要么就做其他无关工作的事情。项目组也认为维护人员只是做自己的维护工作，抱怨时只会对测试人员。项目测试工作量也比较繁重，频繁的超负荷工作，给测试人员也造成比较大的压力。

公司是否可以通过下放部分考核比例，由测试负责人给组内测试人员和维护人员的工作进行考核打分，来约束和督促内部测试工作的合理进行。

公司是否应该考虑制定比较合理项目开发和测试周期计划及人员分配比例，切实减少超负荷工作带来的压力。

公司的业务逐年扩展，测试部门人员缺口较大，主要测试工作基本都落在了部门几个人身上，望明年公司能合理补充人员，并能在薪资待遇方面能有比较合理的增长。

测试部内部是否应该经常在和合适的时间组织测试技能、业务知识以及项目经验方面交流的讨论会等，以便更好的分享各自的经验教训，为今后的工作提供更多的基础支持，同时也应加强新人的培训力度。

范文二

在支付宝测试分析的角色和系统分析的角色是对应的，只不过一个是测试类的另外一个是开发类的。系分下面会有相应开发，测分下面会有相应的测试用例编写和执行人员。也就是说测试分析文档是对测试执行人员的一个指导(在我原来的理解方式上，觉得测试分析人员应该是用例编写人员;而在这里测试分析人员是从业务上去分析的，用例是用例执行人员来写并且执行的)。

而通过这次的这次分析觉得自己的测分还存在以下的问题：

1、太关注开发的内部实现逻辑。建议：将开发内部实现逻辑看成一个黑盒子，测试分析要从这个黑盒子的输入和输出上去看开发内部实现逻辑是不是有问题，而不应该先去了解开发的实现逻辑然后按照他们的思路去分析。

2、分析文档写的过于详细，甚至将用例的步骤都写了出来。建议：测试分析要从全局上去看问题，细节的东西即便是知道的，也要留给之后的用例编写人员去了解(就像系分之后的开发需要去写详细设计的道理一样)，这样后面的人才会自己主动去想问题。

3、分析文档要考虑维护性问题，不要出现类似比如还款中状态为“R”这种具体的数据内容。因为我的分析是对后续用例编写人员的一个指导性的文档，所以如果侧分这么写很有可能导致用例也照着这么写，其实不管侧分和用例都不应该具体写到R这么细节，否则的话开发稍作变动我们就要相应变动我们的用例

4、没有明确测试目的。review用例的时候，没有提出每个用例需要明确一个测试目的，让别人来看这个用例的时候能明白到底是怎么回事。

总结：

1、以后写测试分析文档，依据仅仅是prd文档，必须抛开开发实现逻辑部分(即不去看系分文档)，待测分出来之后，再去看系分文档，互相看看彼此考虑的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去互相明确更细节的东西。

2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析，细到看输出的时候会关注到数据库表的一个变化。但是除了以上部分，其实还少了对整体流程的关注，需要增加业务流程的各条路径的一个覆盖，在针对路径的用例中不需要关注到数据库表级那么细。

3、在做流程路径覆盖之前应该画一个路径图，这个图的画法考虑各个入口的不同分开画流程图，分别进行路径覆盖。

[测试部年终总结]

【测试部年终总结】相关文章：