测试人员201*年述职报告

测试人员201*年述职报告

述职报告

测试部门xxx

201*年已经离开我们了，对于我来说，201*年就是一本厚厚的书，书中所有的故事都是那么让我回味，当我回过头，看看走过的这一年，虽然在这一年里也有过不如意不顺利和许多错误的事情发生，但是我知道人正是在经历了这些之后才能够成长、成熟。201*年在公司各级领导的带领下，和各部门同事的紧密协作下也圆满的完成了一年的工作。针对201*年的工作情况，我对本年度的工作作出以下总结阐述，我的述职报告分以下几个部分：工作职责，工作总结，知识与经验分享，201*年计划以及我的一些建议，希望各位领导和同事能对我的总结进行批评指正。一、

工作职责

1、主要负责贝尔1-2、2-1，1-2C、A8-C、A8-B、1-2P、2-1P等企业网关的测试和售后技术支持等工作；

2、贝尔RG200O-CA、240W-Q等家庭网关测试和售后技术支持等工作；3、贝尔3G、4G无线网卡和3G路由器，电话支持等售后工作。二、

工作总结

201*年我主要完成了以下几方面的工作：1、项目测试工作

（1）配合ICG广州xx研究院A8-C测试，xx电信1-2C测试，南通电信1-2C测试，重庆电信A8-C测试，配合ICGxx电信A8-C测试，西安电信A8-C、A8-B测试，福建泉州电信A8-C测试等。各项测试的主要内容分别为对测试用例的编写提供反馈意见；对测试过程及测试情况进行分析，并提供意见；设计业务测试数据的例子；绘制系统关键业务流程；进行主要功能的界面测试、功能测试；按照测试用例执行测试，并提交测试汇报；进行需求验证工作。（2）贝尔企业网关，各地测试网络、ITV功能部分，语音功能部分，ITMS+下发工单部分等。以及与各个厂家OLT互通问题等。局方当地的测试要求，及时给后方研发，让其按照当地预配置及时做出版本等。与当地测试的不同厂家兄弟了解当地测试方式和相关文档，掌握合理的测试时间和方法，尽快完成测试。测试中出现不符合要求的项目，及时抓包和log等，与后方和研发及时联系。每天测试中出现的问题，和解决的进展等及时反馈，让各位领导了解。可以帮助督促研发解决以及协调其他等。

2、xx电信1-2C放装支持

（1）主要是xx1-2C放装支持，现场处理用户投诉，解决用户当时出现的问题，并把处理结果反馈给电信报障的工作人员和后方研发。有些问题，电信师傅电话咨询，尽量电话中就解决师傅的问题，不行就去现场。把固件版本和操作排障方法教给电信师傅，做些现场演示，简单培训（包括发邮件给电信的师傅等）。现场处理不了的一些问题，把现场的故障现象和抓包等，及时提供给研发，尽快解决故障。包括局方要求的设备升级等，都及时到达现场处理。放装支撑主要是需要和用户建立良好的沟通，第一时间处理问题，给用户良好的售后体验。

（2）用户投诉的问题，尤其注意。及时去现场解决并与局方沟通，把问题尽量大事化小。现场解决不了的问题，及时反馈回研发和领导，找出最好的解决途径及时与局方沟通。

3、贝尔移动终端MIFI等电话技术支持（1）用户电话咨询的问题，第一时间给予处理。

（2）关于保修等问题，进行解答。与后方领导联系妥善处理一些移动公司投诉的问题。保证移动投诉的问题尽快解决，当天能给用户满意的答复。三、

知识与经验分享

目前知识与经验分享，主要是以下：

1、服务中心支撑企业网关的工程师，邮件及时反馈出各地出现的问题，把故障现象，现场抓包等及时反馈回研发。例如POS机刷卡问题，需要关闭静音抑制，能处理大部分问题。还有语音版本不断更新，出现一些新的BUG等及时了解，为我们现场测试和维护提供有力的依托等。

2、每周的集体视频会议，把一些问题和大家总结出来的工作经验等及时交流。3、学习相关企业网关的文档网络部分抓包分析，语音的SIP协议等新知识。抓包后自己先分析下问题出在哪里，如果确实是局方问题需要与局方及时沟通。4、完成项目测试后及时经验总结。

四、对部门建设的建议在部门建设上，我想可以从以下几方面逐步开展部门建设工作：

1、对人员进行分工，或者说是团队成员的侧重方向进行明确。例如，同一测试技术或测试工具，可以不需要多个人同时研究，这样可能造成资源的浪费。2、强化制度建设。

3、加大对测试过程的实施力度：现有测试过程，过程文件上存在不易操作的地方。所以在实施上也相应的存在一些问题。另外，争取能让开发人员了解测试过程。如果能让开发人员了解测试过程，可以让测试工作更好开展，以及获得更好的配合。

4、加强部门测试成果的积累与沉淀。现在的测试成果保存在服务器上，很容易发生测试成果丢失的情况。加上还有一些测试成果未提交服务器，只是保留在个人机器上，很容易发生人走成果也不在的情况。另外，保存在个人机器上，也不利于知识的传播与分享，不利于部门成员技能的提升。

5、除了将已有测试成果进行有效管理外，还需要将已有的测试知识沉淀下来。例如，对项目的测试经验，性能测试的经验，测试用例设计经验等等。

五、201*年计划

201*年，我希望能通过参与具体项目的实践，达到以下目标：

1、能将测试过程在项目中真正的运用起来，并让项目的开发人员了解我们的测试过程；2、在项目中沉淀出一些部门成果；

3、除了保质保量的完成项目测试工作外，我还将积极、主动的参与部门建设工作，和部门所有成员一起努力，在领导的指导下，将我们部门做成受到公司认可，有一定地位的部门。

以上是本人201*年度的个人工作述职，请各位领导和同事能够提出意见，我将虚心接受，勇于改正。

扩展阅读：201*年测试工作总结

201*年测试工作总结

常常，我们会听到老板或者老总等领导说，你们测试团队的贡献率或是价值在哪？软件系统的稳定性如何？下面我将根据这两个问题，作出一些解答。

1.测试投资回报率

企业为了获得利润，需花费大量的资金进行测试。在质量方面的投资会产生利润，例如提高产品质量会提高公司的声誉，使产品交付之后的维护成本减少，避免用户的抱怨。测试是一种带有风险性的管理活动，减少企业在未来因为产品质量低劣而花费不必要的成本。缺陷探测率：

DDP=Bugstester/(Bugstester+Bugscustomer)

表1客户发现bug数统计

月份6789101112合计客户发现的bug数702303116数据是从201*年6月份开始统计

表2测试人员发现bug数统计由谁未解总计创建决周MM余GG合计7001325202571118设计重复外部已解如此Bug原因决3847851426403555904197881207无法延期不予转为重现处理解决需求31336421618273966有效率12778.29%31084.08%43782.07%数据统计时间：201*年1月1日到201*年12月31日，其中有效率的计算公式=（已解决+延期处理+转为需求）/总计*100%

属于质量预防方面的一致性成本只考虑软件测试的投资，把发布之前和之后发现及修改的错误堪称非一致性成本，根据表1和表2，发现的错误为2041个，故障成本已知，测试过程的估算如下：各阶段花费在发现及修改错误的成本假设如下：

①在开发过程单元测试阶段，软件开发人员发现及修改一个错误需要50元；②建立独立的测试进行集成和系统测试，测试人员发现错误，开发人员修改后，测试人员再确认，一个错误需要300元；

③在产品发布后，由客户发现，报告技术支持人员、相关开发人员修改，测试组再进行回归测试，一个错误需要201*元。

第1种情况，开发单位未建立独立测试队伍，有开发人员进行测试，发现680个错误，而产品发布后客户发现错误1361，只存在故障成本构成的总成本为50*680+201**1361=2756000元，缺陷探测率为33.32%。

第2种情况，开发单位建立了独立测试队伍，进行手工测试。投资预算人员费用为100000元，测试环境使用费为8000元，测试投资（一致性成本）为108000元，除了开发过程中开发人员发现并修改680个（假设开发人员只能发现1/3的问题）错误外，测试过程中测试人员发现错误1345个，而产品发布后客户发现16个错误。总质量成本下降到50*680+300*1345+16*201*+108000=577500元（如表3所示），手工测试总质量成本节约了2756000-577500=2178500元，即为利润。投资回报率(ROI)为201*.13%，缺陷探测率为99.22%。

ROI=

原无独立测试质量成本i独立测试质量成本j

测试投资

100%

=（2756000-577500）/108000*100%=201*.13%

DDP=Bugs

Bugstester

tester

+Bugscustomer

100%=

680+13452041

100%=99.22%

表3测试投资回报分析

测试成本项测试人工费环境使用费一致成本测试投资测试工具费测试总投资发现错误数开发测试每个错误成本内部（开发）故障成本发现错误数非一致性独立测试每个错误成本成本内部（测试）故障成本发现错误数客户支持每个错误成本外部故障成本一致性成本质量成本非一致性成本总质量成本ROI投资回报率DDP缺陷探测率

质量成本项开发测试68050340001361201*272201*27560002756000N/A34.30%手工测试10000080001080006805034000134530040350016201*3201*108000469500577500201*.13%99.22%2.系统可靠性分析

平均每千行代码bug数

后台代码总共342480行（由于前台代码较难统计，据开发人员估计是后台代码的3倍），系统总代码数是1369920，属于一个大规模系统，平均每千行代码约为2个bug。

平均无故障时间MTTF

若设T是软件总的运行时间，M是软件在这段时间内的故障次数。内部平均无故障时间MTTF=T/M=365*24/2041=4.29小时；

外部平均无故障时间MTTF=T/M=(365-151)*24/16=321小时=13.375天。根据考察资料得知，航天科技一些精密系统平均无故障时间720小时对应90分的可信度，参考这个，相当于我们系统的可信度大约为40分。

下面用Shooman模型对平均无故障时间MTTF进行分析：

对一个长度为342480行代码的系统进行测试，根据记录下来的数据如下：①测试开始，发现错误个数为0（假设为0，201*年测试出bug不计入统计）；②经过了151天的测试，累计改正1137个错误，此时，MTTF=3.19小时；③又经过214天的测试，累计改正2041个错误，此时，MTTF=4.29小时；

由Shooman公式：MTTF=1/K(LT

TE

ETtLT

)

其中，K是一个经验常数，美国一些统计数字表明，K的典型值是200；ET是测试之前程序中原有的故障总数；LT是程序长度（机器指令条数或简单汇编语句条数）；t是测试（包括排错）的时间；EC(t)是在0～t期间内检出并排除的故障总数。公式的基本假定是：

单位（程序）长度中的故障数ETLT近似为常数，它不因测试与排错而改变。统计数字表明，通常ETLT值的变化范围在0.5×10-2～2×10-2之间；故障检出率正比于程序中残留故障数，而MTTF与程序中残留故障数成正比；故障不可能完全检出，但一经检出立即得到改正。

由已知条件②、③可解出K=31.22,ET=4598。系统中仍可能残留4598-2041=2557

个问题。【参考文献】《软件评测师教程》

友情提示：本文中关于《测试人员201*年述职报告》给出的范例仅供您参考拓展思维使用，测试人员201*年述职报告：该篇文章建议您自主创作。

来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。

《测试人员201*年述职报告》由互联网用户整理提供,转载分享请保留原作者信息,谢谢!
链接地址：http://www.bsmz.net/gongwen/642923.html

• 上一篇：201*年信访稳定述职报告
• 下一篇：报社副总编辑兼副社长述职报告