测试人员201-年述职报告.docx

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

1、测试人员201*年述职报告 测试人员201*年述职报告述职报告测试部门xxx201*年已经离开我们了，对于我来说，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等刚好了解，为我们现场测试和维护供应有力的依托等。2

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

7、了解测试过程。假如能让开发人员了解测试过程，可以让测试工作更好开展，以及获得更好的协作。4、加强部门测试成果的积累与沉淀。现在的测试成果保存在服务器上，很简单发生测试成果丢失的状况。加上还有一些测试成果未提交服务器，只是保留在个人机器上，很简单发生人走成果也不在的状况。另外，保存在个人机器上，也不利于学问的传播与共享，不利于部门成员技能的提升。5、除了将已有测试成果进行有效管理外，还须要将已有的测试学问沉淀下来。例如，对项目的测试阅历，性能测试的阅历，测试用例设计阅历等等。五、201*年安排201*年，我希望能通过参加详细项目的实践，达到以下目标：1、能将测试过程在项目中真正的运用起来，并让项

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

9、产品质量会提高公司的声誉，使产品交付之后的维护成本削减，避开用户的埋怨。测试是一种带有风险性的管理活动，削减企业在将来因为产品质量低劣而花费不必要的成本。缺陷探测率：DDP=Bugstester/(Bugstester+Bugscustomer)表1客户发觉bug数统计月份6789101112合计客户发觉的bug数702303116数据是从201*年6月份起先统计表2测试人员发觉bug数统计由谁未解总计创建决周MM余GG合计7001325202571118设计重复外部已解如此Bug缘由决3847851426403555904197881207无法延期不予转为重现处理解决需求3133642161

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

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

12、后客户发觉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=BugsBugstestertester+Bugscustomer100%=680+13452041100%=99.22%表3测试投资回报分析测试成本项测试人工费环境运用费一

13、样成本测试投资测试工具费测试总投资发觉错误数开发测试每个错误成本内部（开发）故障成本发觉错误数非一样性独立测试每个错误成本成本内部（测试）故障成本发觉错误数客户支持每个错误成本外部故障成本一样性成本质量成本非一样性成本总质量成本ROI投资回报率DDP缺陷探测率质量成本项开发测试68050340001361201*272201*27560002756000N/A34.30%手工测试10000080001080006805034000134530040350016201*3201*108000469500577500201*.13%99.22%2.系统牢靠性分析平均每千行代码bug数后台代码总共3

14、42480行（由于前台代码较难统计，据开发人员估计是后台代码的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进行分析：对一个长度为3

15、42480行代码的系统进行测试，依据记录下来的数据如下：测试起先，发觉错误个数为0（假设为0，201*年测试出bug不计入统计）；经过了151天的测试，累计改正1137个错误，此时，MTTF=3.19小时；又经过214天的测试，累计改正2041个错误，此时，MTTF=4.29小时；由Shooman公式：MTTF=1/K(LTTEETtLT)其中，K是一个阅历常数，美国一些统计数字表明，K的典型值是200；ET是测试之前程序中原有的故障总数；LT是程序长度（机器指令条数或简洁汇编语句条数）；t是测试（包括排错）的时间；EC(t)是在0t期间内检出并解除的故障总数。公式的基本假定是：单位（程序）长

16、度中的故障数ETLT近似为常数，它不因测试与排错而变更。统计数字表明，通常ETLT值的改变范围在0.510-2210-2之间；故障检出率正比于程序中残留故障数，而MTTF与程序中残留故障数成正比；故障不行能完全检出，但一经检出马上得到改正。由已知条件、可解出K=31.22,ET=4598。系统中仍可能残留4598-2041=2557个问题。软件评测师教程友情提示：本文中关于测试人员201*年述职报告给出的范例仅供您参考拓展思维运用，测试人员201*年述职报告：该篇文章建议您自主创作。 本文来源：网络收集与整理，如有侵权，请联系作者删除，谢谢！第10页 共10页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页第 10 页 共 10 页