测试人员2023年年述职报告.docx

《测试人员2023年年述职报告.docx》由会员分享，可在线阅读，更多相关《测试人员2023年年述职报告.docx（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 测试人员201*年述职报告 测试人员201*年述职报告 述职报告 测试部门xxx 201*年已经离开我们了，对于我来说，201*年就是一本厚厚的书，书中全部的故事都是那么让我回味，当我回过头，看看走过的这一年，虽然在这一年里也有过不如意不顺当和很多错误的事情发生，但是我知道人正是在经受了这些之后才能够成长、成熟。201*年在公司各级领导的带着下，和各部门同事的严密协作下也圆满的完成了一年的工作。针对201*年的工作状况，我对本年度的工作作出以下总结阐述，我的述职报告分以下几个局部：工作职责，工作总结，学问与阅历共享，201*年规划以及我的一些建议，盼望各位领导和同事能对我的总结进展批判指正。

2、一、 工作职责 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测试等。各项测试的主要内容分别为对测试用例的编写供应反应意见

3、；对测试过程及测试状况进展分析，并供应意见；设计业务测试数据的例子；绘制系统关键业务流程；进展主要功能的界面测试、功能测试；根据测试用例执行测试，并提交测试汇报；进展需求验证工作。（2）贝尔企业网关，各地测试网络、ITV功能局部，语音功能局部，ITMS+下发工单局部等。以及与各个厂家OLT互通问题等。局方当地的测试要求，准时给前方研发，让其根据当地预配置准时做出版本等。与当地测试的不同厂家兄弟了解当地测试方式和相关文档，把握合理的测试时间和方法，尽快完成测试。测试中消失不符合要求的工程，准时抓包和log等，与前方和研发准时联系。每天测试中消失的问题，和解决的进展等准时反应，让各位领导了解。可以

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

5、决并与局方沟通，把问题尽量大事化小。现场解决不了的问题，准时反应回研发和领导，找出最好的解决途径准时与局方沟通。 3、贝尔移动终端MIFI等电话技术支持（1）用户电话询问的问题，第一时间赐予处理。 （2）关于保修等问题，进展解答。与前方领导联系妥当处理一些移动公司投诉的问题。保证移动投诉的问题尽快解决，当天能给用户满足的答复。三、 学问与阅历共享 目前学问与阅历共享，主要是以下： 1、效劳中心支撑企业网关的工程师，邮件准时反应出各地消失的问题，把故障现象，现场抓包等准时反应回研发。例如POS机刷卡问题，需要关闭静音抑制，能处理大局部问题。还有语音版本不断更新，消失一些新的BUG等准时了解，为我

6、们现场测试和维护供应有力的依托等。 2、每周的集体视频会议，把一些问题和大家总结出来的工作阅历等准时沟通。3、学习相关企业网关的文档网络局部抓包分析，语音的SIP协议等新学问。抓包后自己先分析下问题出在哪里，假如的确是局方问题需要与局方准时沟通。4、完成工程测试后准时阅历总结。 四、对部门建立的建议在部门建立上，我想可以从以下几方面逐步开展部门建立工作： 1、对人员进展分工，或者说是团队成员的侧重方向进展明确。例如，同一测试技术或测试工具，可以不需要多个人同时讨论，这样可能造成资源的铺张。2、强化制度建立。 3、加大对测试过程的实施力度：现有测试过程，过程文件上存在不易操作的地方。所以在实施上

7、也相应的存在一些问题。另外，争取能让开发人员了解测试过程。假如能让开发人员了解测试过程，可以让测试工作更好开展，以及获得更好的协作。 4、加强部门测试成果的积存与沉淀。现在的测试成果保存在效劳器上，很简单发生测试成果丧失的状况。加上还有一些测试成果未提交效劳器，只是保存在个人机器上，很简单发生人走成果也不在的状况。另外，保存在个人机器上，也不利于学问的传播与共享，不利于部门成员技能的提升。 5、除了将已有测试成果进展有效治理外，还需要将已有的测试学问沉淀下来。例如，对工程的测试阅历，性能测试的阅历，测试用例设计阅历等等。 五、201*年规划 201*年，我盼望能通过参加详细工程的实践，到达以下

8、目标： 1、能将测试过程在工程中真正的运用起来，并让工程的开发人员了解我们的测试过程；2、在工程中沉淀出一些部门成果； 3、除了保质保量的完成工程测试工作外，我还将积极、主动的参加部门建立工作，和部门全部成员一起努力，在领导的指导下，将我们部门做成受到公司认可，有肯定地位的部门。 以上是本人201*年度的个人工作述职，请各位领导和同事能够提出意见，我将虚心承受，勇于改正。 扩展阅读：201*年测试工作总结 201*年测试工作总结 经常，我们会听到老板或者老总等领导说，你们测试团队的奉献率或是价值在哪？软件系统的稳定性如何？下面我将依据这两个问题，作出一些解答。 1.测试投资回报率 企业为了获得

9、利润，需花费大量的资金进展测试。在质量方面的投资会产生利润，例如提高产品质量会提高公司的声誉，使产品交付之后的维护本钱削减，避开用户的埋怨。测试是一种带有风险性的治理活动，削减企业在将来由于产品质量低劣而花费不必要的本钱。缺陷探测率： DDP=Bugstester/(Bugstester+Bugscustomer) 表1客户发觉bug数统计 月份6789101112合计客户发觉的bug数702303116数据是从201*年6月份开头统计 表2测试人员发觉bug数统计由谁未解总计创立决周MM余GG合计7001325202571118设计重复外部已解如此Bug缘由决3847851426403555

10、904197881207无法延期不予转为重现处理解决需求31336421618273966有效率12778.29%31084.08%43782.07%数据统计时间：201*年1月1日到201*年12月31日，其中有效率的计算公式=（已解决+延期处理+转为需求）/总计*100% 属于质量预防方面的全都性本钱只考虑软件测试的投资，把公布之前和之后发觉及修改的错误堪称非全都性本钱，依据表1和表2，发觉的错误为2041个，故障本钱已知，测试过程的估算如下：各阶段花费在发觉及修改错误的本钱假设如下： 在开发过程单元测试阶段，软件开发人员发觉及修改一个错误需要50元；建立独立的测试进展集成和系统测试，测试

11、人员发觉错误，开发人员修改后，测试人员再确认，一个错误需要300元； 在产品公布后，由客户发觉，报告技术支持人员、相关开发人员修改，测试组再进展回归测试，一个错误需要201*元。 第1种状况，开发单位未建立独立测试队伍，有开发人员进展测试，发觉680个错误，而产品公布后客户发觉错误1361，只存在故障本钱构成的总本钱为50*680+201*1361=2756000元，缺陷探测率为33.32%。 第2种状况，开发单位建立了独立测试队伍，进展手工测试。投资预算人员费用为100000元，测试环境使用费为8000元，测试投资（全都性本钱）为108000元，除了开发过程中开发人员发觉并修改680个（假设

12、开发人员只能发觉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 1

13、00%= 680+13452041 100%=99.22% 表3测试投资回报分析 测试本钱项测试人工费环境使用费全都本钱测试投资测试工具费测试总投资发觉错误数开发测试每个错误本钱内部（开发）故障本钱发觉错误数非全都性独立测试每个错误本钱本钱内部（测试）故障本钱发觉错误数客户支持每个错误本钱外部故障本钱全都性本钱质量本钱非全都性本钱总质量本钱ROI投资回报率DDP缺陷探测率 质量本钱项开发测试68050340001361201*272201*27560002756000N/A34.30%手工测试10000080001080006805034000134530040350016201*3201*1

14、08000469500577500201*.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分的

15、可信度，参考这个，相当于我们系统的可信度大约为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)是在0t期间内检出并排解的故障总数。公式的根本假定是： 单位（程序）长度中的故障数ETLT近似为常数，它不因测试与排错而转变。统计数字说明，通常ETLT值的变化范围在0.510-2210-2之间；故障检出率正比于程序中残留故障数，而MTTF与程序中残留故障数成正比；故障不行能完全检出，但一经检出马上得到改正。 由已知条件、可解出K=31.22,ET=4598。系统中仍可能残留4598-2041=2557 个问题。【