202X年软件测试工作年终总结

《202X年软件测试工作年终总结》由会员分享，可在线阅读，更多相关《202X年软件测试工作年终总结（27页珍藏版）》请在金锄头文库上搜索。

1、软件测试工作年终总结篇一：软件测试工程师年终总结XX年终总结时光荏苒，如今 12 年的帷幕已经谢下， 13 年的钟声已 经敲响，在公司高层的正确领导下，我们佰腾科技又走过了 一年。而我也在自己的努力以及同事的帮助下完成了 XX 年 我所负责的工作，以下就是我对过去这一年的工作总结：一、测试工作及经验 作为软件部测试组的一员，首先要做好的就是自己的本 职工作，我在 XX 年中所做的工作主要有：测试用例的编写，对系统的测试、跟踪； 需求、高保图、界面和功能的测试； 功能测试用例的编写，高保图、系统的测试； 的静态页面测试和功能测试；5. xxxxxxxX勺功能测试；6. xxxxxxxX第一、二、

2、三迭代高保图测试，测试用例 编写，静态页面和功能测试，并主持参与测试用例评审；7. XXXXXXXX平台高保图的测试和系统静态页面、功能 勺测试；8. xxxxxxxX勺高保图测试和测试用例的编写；9. XXXXXXXX的静态页面和功能测试，参与测试用例的评审；10 . xxxxxxxX勺高保图测试、静态页面和功能测试；11. xxxxxxxX!户使用手册的编写；一年勺工作，让我获得很多方面勺经验：1 编写逻辑覆盖率全的测试用例甚为重要。在理解需 求的前提下编写测试用例，使得我掌握了多种测试用例编写 方法，更让我对产品的需求有更加深入的理解，须知对需求 是否理解透彻决定了能否有效、全面地对产品

3、进行测试；2. 要站在用户角度对系统进行测试。从一些项目中出 现的未能及时发现的 bug 中，我认识到用户体验的重要性， 现在能够越来越多的从这方面来执行测试；3对拿到手的项目有较清晰的思路，能够更加快速、 准确地发现问题；4. 越来越规范的工作流程的让我们的工作有条不紊的 进行，让我深刻认识到工作的规范性是多么的重要，并且从 中学习如何从文档和流程上规范工作。5. 同事间的沟通很重要。现在不管遇到什么不确定或疑 惑，都与开发人员、产品经理等及时沟通，大大提高了工作的效率。二、加强自我能力的提高 只有不断的提高自己各种的能力，才能胜任越来越艰巨 的任务，因此在工作相对不饱和的时候，我自己进行了

4、一些 学习。为提高对“用户体验”的理解，我学习了下一站用户体验，书中一些经验确实让我获益匪浅。不能总拿别人的 用户体验去改进自己的产品， 但是有一些却是通用的， 比如：太多弹出框、按钮会给用户带来愤怒感，要适当的给页面减深知单纯的界面测试和功能测试已经渐渐不能满足今 后平台的开发，所以我学习了性能测试的一些相关知识，并 在师父的指导下运用 LR 工具进行简单性能测试，以后必须 坚持学习。三、存在的不足及明年计划一年的工作让我有所进步，但是很多地方还是存在不足， 比如：有时候看问题比较主观，不是很细致，没能深入地去 测试，会有遗漏的 bug ；自身专业技术能力还不足，不能从 系统稳定性这一点上对

5、系统进行测试。在以后的工作中，我 会努力改善。在 XX 年的工作中，我计划：1、本着实事求是的态度， 更加认真、 负责的完成工作；2、要尽可能深刻的理解需求，坚持编写覆盖率强的测 试用例；3、按照系统稳定性测试方案， 要逐渐对系统的稳定性、 安全性进行测试；4、继续研究性能测试，并要将 LR 工具运用在实际工作中；5、多多的学习，参加一些有益的培训，在实际工作中 活学活用。四、个人建议这一年来我们部门有着的显著进步，越发规范的工作流 程，越来越明确的责任制度、管理体系等，都让我们更加有 凝聚力。在此，个人提出以下几个小建议：1、希望可以加强对项目的把控，尽量能将延期风险降 到最低；2、从各个组

6、对需求理解的不一致，以及信息更新不及 时等问题上看，沟通问题还是有待完善；3、希望能够在需求这一关卡上能更详细、准确的确定 产品的功能要求；4、虽然工作任务繁重， 还是希望部门能够多组织活动， 完善奖励制度，可以让大家更加激情的为部门、为公司奉献自己的全部力 量。以上是我个人的一些浅见，相信在大家共同的努力下， 向着同一个目标进发，软件部甚至整个公司必定会大展全新 的宏图伟业。篇二：软件测试工程师年终工作总结XX年终工作总结:XX年工作回顾及总结回顾 XX 年这一年来的工作，我在公司领导及各位同事 的支持和帮助下，严格要求自己，按照公司要求，比较好地 完成了本职工作。通过近一年的学习和工作，工

7、作模式上有 了新的突破，工作方式有了较大的改变。现将这一年的工作 情况总结如下:1、总体来说，XX年我主要完成了 “银行系统”、“ 渠道管理平台”、“”、“”、“” “”的日常 测试以及质量控制工作； “”已经稳定上线运行 6 个多 月，“”即将上线。2、日常我主要负责项目测试工作、测试文档编辑、参与功能需求设计、协调开发进度、总结经验分享、完成所需 知识积累、工具学习及研究、兼容性软件测试。就在银联项 目工作来说，主要的工作内容有：a、测试项目案例、测试用例的设计与编写；b、对测试过程中遇到的问题进行沟通， 并提供意见； c 、设计业务功能流程，提供参考意见，绘制关键业务流程；d、进行主要功

8、能的界面测试、 功能测试；e、 按照测试用例执行测试计划； f 、进行需求验证工作3、 知识的总结与分享，完成客户端在安卓/ ，以上系统 上出现的兼容等问题，完成了兼容性测试案例的编写以及兼 容性测试的培训工作。 在日常工作中， 发现兼容上重大问题，在测试部门群中发布分享。4、完成所需知识积累， 学习所需知识、 工具以及技能 在工作中学习了银行业务流程规范、学习公司研发规范、参 加了公司组织的技术培训、学习了各种测试工具的使用。二：对公司的建议与意见对公司和部门建设上，我有以下几点建议：1、对员工进行金融知识的系统培训，让测试人员了解 银行业务流程，有助于测试人员更加详细了解业务流程，测 试过

9、程会少走很多弯路。2、部门内希望多组织技术交流讨论，促进测试工作的 开展和提高。一年至少有 2 次这样的交流。3、公司在项目开发前期，希望尽可能的明确需求，尽 可能的详尽需求说明书内容。在测试过程中发现很多项目缺 少需求说明书，需求说明书不明确或者需求说明书内容错误， 误导了开发和测试，浪费了时间，影响了项目进度。4、建议项目需求设计可以有测试员参与讨论。5、公司管理有点混乱，个人感觉公司对每位员工的重 视程度不够！节假日公司应该给每位员工一定的福利和关心。6、个人感觉平时的效率比较低，希望测试部门能够有 所调整。希望公司能制定质量控制标准以及开发、测试工作 流程，让开发更好的了解测试的流程，

10、增强开发团队与测试团队的配合，提高工作效率。7、加强部门测试成果的积累与沉淀，提高团队测试水 准，希望我们的团队能够做的更好，能够已团队的形式参与 软件项目的开发，而不仅仅是一个项目中毫不起眼的小小测 试员。三：XX年工作计划与学习计划XX年工作计划就是希望通过自己的努力，让我们的产品更加完美，让自己在软件测试技能上有所提高，更多的关注 软件产品的开发过程，提高工作效率、做到与用户的需求一 致，提高公司软件产品用户满意度。具体来说 XX 年工作计划有：努力提高自身测试水准， 努力学习金融知识以及业务流程，学会需求分析，掌握需求 分析在测试中的作用，参与公司更多的开发项目的测试工作。*201*年

11、A月A日篇三：XX年终总结-软件测试年终总结时间飞逝，一转眼就到了年末，还记得来奥软面试后， 我跟一个同行说：很喜欢奥软的测试氛围。他问我为什么喜 欢？我说： 没有理由， 就像一见钟情。 在奥软工作 5 个月后， 证明我当初选择奥软是没有错的。在奥软我学到了很多，成 长了很多， 并且也很快乐。 开始的时候有很多地方做的不好， 比如发邮件时老忘记发附件， 提交的 buglist 表格不规范等， 经过万舒和其他同事的帮助，渐渐的改正了。工作内容：在前 3 个月里，主要跟万舒他们一起完成易 用汇商店 500 款 cp 的测试。测试商店 cp 的过程中，自己的 在测试技术上有了一定的进步，以前对 bu

12、g 的定位不确定， 常常提交无效 bug ，经过这一百多款 cp 的测试，对 android 平台的应用软件有了进一步的了解。 11 月份开始测试各机型 的几款内置cp。负责内置cp测试的阶段是最锻炼我的时候。 虽然在测试商店 cp 时，对 bug 有了新的认识，但还是有点 失望，开始还可以，但到后面进步明显小了。由于我们只是 负责测试，然后提交 bug，与其他部门和第三方的接触沟通 都由万舒负责，导致我们对 cp 不了解，测试的很浅，并且 在综合能力上没有得到锻炼。 尤其在后期， cp 不能及时提供， 每天上午要浪费一两个小时等待测试包，且下班后对明天的 工作是个谜，根本无法安排第二天的计划

13、，一周的计划就更 不用说了， 导致效率明显下降。 内置 cp 由组员独立跟进后， 我觉得综合素质方面开始得到锻炼。比如在与其他部门和第 三方沟通时，沟通能力有了很大提高。并且通过跟第三方的 电话沟通，让我对 cp 有了更深的了解，这样会少提交无效 bug，也可以测试的更深入。在这半年里，有两件事给了我很大的信心。 第一：刚开始独立跟进项目时， 能够在项目计划进度内，将百度快搜联问题解决。由于之前在工作中没有与其他部门 交流过，当 cp 组会议结束后，心理有点慌， buglist 要发给 谁、有 cp 上的问题去问谁等一系列的问题使我有些不安。 不过几天后，渐渐的开始适应了，分工后，遇到的第一个

14、比 较大的问题是百度快搜联问题，以前就写上cmwap高概率联失败，没有详细的步骤。当时没有意识到这样的bug 描述对于开发人员来说是没有帮助的。经过多次来回回复后，最终 问题还是没有得到解决，浪费了时间也浪费了精力。跟百度 研发人员联系上后，我决定查找复现路径，经过不断测试， 最终找出了两条必现路径，提交给了百度快搜的研发人员， 他回复中的第一句话是“我按照你的两条 case 验证，确实 如此”，后面是问题原因的分析，并表示有解决方法。看到 第一句话时，我很激动，也很高兴，纠缠了这么久的问题终 于有了结果。解决第一个大问题后，我感触很深：首先，提 高了自己的责任心，以前只管发现问题，至于解决问

15、题似乎 不太关心。由于有些路径很难查找（比如这次的百度快搜是 经过几天的加班才找到必现路径） ，发现问题后，描述时， 偶尔会有敷衍了事的心态，只知道问题确实存在，但具体的 路径不一定清晰，只写上概率出现。通过这次的锻炼，我知 道了：测试人员不只是发现问题， bug 描述、查找复现路径 一样很重要；我们关心的不仅仅是问题存在，还需关心问题 是否有解决。其次，在与百度快搜研发人员沟通中，让我受 益匪浅的是，他们分析问题的能力，从不同的角度去分析， 并且尝试不同的方法，直到问题得到解决。第二：s009淘宝buglist提交后，测试能力得到了淘宝 研发人员的肯定。他们给予的评价是：提交的问题很专业。 让我没有想到的是，有个bug，他们看到后，回复说：这个bug 隐藏的很深而且隐藏了很久，他们合作的所有客户，经 过这么多版本后都没有发现， 只有我们公司提交了这个 bug。 虽然这个 bug 比较难修改（修改的话影响太大） ，最终选择 暂时不修改。但能得到研发人员的肯定，是值得高兴的。作 为测试人员最怕的就是遭到研发人员的排斥。当然，有值得高兴的也有很多不足的地方，比如1、最初回复总部提的bug时，就简单的几个字“设计如此”、“无 法复现”，开始不觉得这样的回复有什么问题，会议之后才 有了改善，即使是设计如此，也该写上原因，为什么要这样 设计。最初以为为了完成任务就该这么做，但提交