软件测试工作述职模版

1、PPT模板下载： 软件测试工作述职 陈 鹏挑战未来目 录测试部规划测试部结构与职责测试部结构与职责测试部结构与职责职责职责u项目测试组：负责所测试版本的功能及非功能性需求的测试及自动化工作，并对版本进行商用风险评估，确保版本发布质量以及重大问题的提前暴露，并对版本上线质量负责。u自动化组：负责自动化工具、自动化框架以及持续集成能力的建设。u测试系统组：负责测试部的测试技术能力提升，包括但不限于测试设计、性能测试、稳定性测试、可靠性测试等软件测试部软件测试部测试系统组测试系统组自动化组自动化组项目测试组项目测试组全院自助测试组全院自助测试组病历本测试组病历本测试组软件研发部软件研发部定位定位u及

2、时暴露从需求、设计、开发、测试、发布各阶段在软件质量方面的风险，并协助系统、开发组给出有效解决措施，确保软件上线质量，并对版本上线质量负责。测试规划测试规划测试测试需求及设计需求及设计迭代开发迭代开发发布发布拧的清需求拧的清需求1 1、参与到需求分析及方案设、参与到需求分析及方案设计的评审，可提出有效建议计的评审，可提出有效建议及可测试性需求；及可测试性需求；2 2、输出性能、稳定性、可靠、输出性能、稳定性、可靠性测试方案与用例，输出场性测试方案与用例，输出场景验收用例景验收用例3 3、提出自动化需求并递交到、提出自动化需求并递交到自动化组实现框架自动化组实现框架讲的了实现讲的了实现1 1、和

3、开发结对，完成、和开发结对，完成storystory文档，并输出用例文档，并输出用例2、对于迭代期间的用例，在转测试前均可完成自动化；3 3、知道、知道storystory实现细节，可实现细节，可以独立画出以独立画出storystory的用例图、的用例图、时序图，可以评审每一种实时序图，可以评审每一种实现细节的弊端以及测试重点现细节的弊端以及测试重点4 4、和一线驻场维护人员建议、和一线驻场维护人员建议并维护长连接，知道软件现并维护长连接，知道软件现阶段的痛点及典型使用场景，阶段的痛点及典型使用场景，落实到落实到storystory测试设计中测试设计中做的好测试做的好测试1 1、通过开发工具、

4、打桩或提前、通过开发工具、打桩或提前准备等方式，可以完成全部用准备等方式，可以完成全部用例的执行例的执行2 2、评估被测试版本的功能、性、评估被测试版本的功能、性能、可靠性、安全等的质量，能、可靠性、安全等的质量，并输出测试报告及商用风险评并输出测试报告及商用风险评估报告估报告3、可得到版本的代码覆盖率，并能评估未覆盖部分的风险；4、将自动化用例集成到持续集成框架中，并能稳定运行5 5、有一套健壮的接口级及、有一套健壮的接口级及UIUI级级自动化用例，可一键式，可覆自动化用例，可一键式，可覆盖所有基本功能及基本异常盖所有基本功能及基本异常干的了攻关干的了攻关1 1、可完成一线紧急问题的快、可完

5、成一线紧急问题的快速定位，并给出规避解决措施；速定位，并给出规避解决措施；2 2、能通过负面反馈回溯之前、能通过负面反馈回溯之前的测试过程问题，并能进行关的测试过程问题，并能进行关联分析测试，保证类似问题不联分析测试，保证类似问题不再发生；再发生；时间表时间表20152015：完成红色部分：完成红色部分70%70%的成熟度建设的成熟度建设20162016：完成红色部分：完成红色部分90%90%的成熟度建设，并完成蓝色部分的成熟度建设，并完成蓝色部分50%50%的成熟度建设的成熟度建设团队协作（长期）1、系统组在输出干净的需求及方案设计的前提下，输出软件demo，确保方案的可行性，避免风险下沉到

6、开发、测试团队协作（长期）1、测试通过构建完善的一键式自动化用例集，逐步把功能测试移交到开发组内部，实现开发组内部可随时开展系统测试，提升开发人员整体思维能力的同时，解放测试人员时间，测试人员专注开展DFX测试及项目风险热图问题解决测试人员能力提升计划测试人员能力提升计划培养类别培养范围达标项培养手段培养时间产品专家全员1、 掌握产品实现细节，可独立画出功能的时序图；2、 详细掌握内部日志细节，可以独立定位出问题模块，并给出解决建议；3、 测试手段丰富，可以完成用例100%的测试执行。1、 测试串讲2、 UML建模培训，能熟练使用用例图、时序图 等工具对于产品做场景分析及内部功能分析。2015

7、.8.11 - 2015.9.15性能测试专家每个项目一名1、 可以依据产品的内部架构以及实现方式，分析出精准的测试点；2、 熟练使用loadrunner、jmeter等性能测试工具，或独立依据测试需求开发测试工具进行性能测试3、 可以进行性能问题定位，可以给性能调优给出有效解决方案1、 每个产品开展性能专项测试，并由测试系统组成员专项指导2、 组织性能测试培训2015.8.11 - 2015.10.30可靠性测试专家每个项目一名1、 可以依据一线的典型组网，分析出一线的全量故障模式；2、 具备测试手段模拟全量故障模式，通过测试，可以给产品提出有效的优化方案。1、 每个产品开展可靠性专项测试，

8、并由测试系统组成员专项指导2、 组织可靠性测试培训2015.8.11 - 2015.10.30测试人员能力提升计划测试人员能力提升计划培养类别培养范围达标项培养手段培养时间自动化测试专家每一个测试小组内部至少2名自动化测试专家1、 熟练掌握web、桌面应用、android、ios、协议 的自动化测试工具，依据既定的测试框架，可以完成所负责用例的自动化；2、 掌握至少一门语言（推荐python 或者 java）1、 自动化用例实现任务下沉到测试项目组；2、 组织自动化培训，覆盖selenium、autoIT、robotium、appium、GT 等测试工具；2015.8.11 - 2015.12

9、.31质量设计师每个项目至少一名1、 从需求到发布阶段，可以给出精准的风险热图，并持续推动解决；2、 可以独立进行产品质量评估，输出有价值的测试报告，能给商用提供有效指导；1、 项目实战中辅导2015.8.11 - 2015.12.31安全专家测试组12名与开发一起培养，达标目的待定待定2015.8.11 - 2015.12.31与开发的合作模式与开发的合作模式项目上强矩阵的管理模式：测试人员同时给测试负责人和项目负责人汇报。人员上资源池的管理模式：测试人员在项目测试结束后，回测试资源池，并建设测试技术能力，如自动化、性能、可靠性等。思考思考论分工论分工亚当.斯密的国富论以英国的一个小作坊作为

10、开篇： 在一个小镇的做针的作坊里面，一共有10个工人，他们一个人抽铁线，一个人拉直，一个人切截，一个人削尖线的一端，一个人钻鼻等，他们一天可以生产四万八千枚针，平均每人一天四千八百枚，但是如果他们各自独立工作，独立生产，一天都不可能制造出哪怕二十枚。系统开发 过于细致的分工，在软件领域是否合适？分工细致的大公司在软件领域普遍存在的问题：三种角色组成一个甩锅团队，擅长内部扯皮。1、不了解软件实现2、输出的设计文档过粗，对于开发的参考价值不大3、 站的位置太高，不接地气，导致设计落地不下去1、不参考系统人员输出的设计文档，按照自己的想法重新设计，往往还更实用2、 只关注实现基本的拉通功能代码，只做

11、简单的测试。反正还有测试人员在后面，输出的软件质量类似于demo，不具备DFX能力3、 普通开发人员不具备整体思维，不会搭建测试环境，只是码代码测试1、按照系统组的需求文档以及设计文档输出的测试用例，怎么转测试后，和预期的完全不一致？2、 成为了开发人员的测试工具，过多的精力在简单的功能测试中，导致软件的性能、稳定性、可靠性、安全、易用性等问题大量漏测解决方案？解决方案？思考思考-测试行业测试行业1 1、测试人员均是产品专家，、测试人员均是产品专家，对于产品内部的模块划分与实对于产品内部的模块划分与实现细节熟练掌握，可以手工测现细节熟练掌握，可以手工测试，自动化测试较少；试，自动化测试较少；2

12、 2、测试团队、测试团队70%70%以上的时间在以上的时间在功能测试，性能、稳定性、可功能测试，性能、稳定性、可靠性等开展较少；靠性等开展较少；3 3、没有持续集成等工程能力；、没有持续集成等工程能力；4 4、没有取得代码覆盖度等数、没有取得代码覆盖度等数据，没法评估测试充分性；据，没法评估测试充分性；测试高级阶段测试高级阶段测试初级阶段测试初级阶段测试中级阶段测试中级阶段1 1、建成了完善的灰盒、黑盒自、建成了完善的灰盒、黑盒自动化框架，并辅助开发，逐步动化框架，并辅助开发，逐步把功能测试移交到开发团队内把功能测试移交到开发团队内部进行；部进行；2 2、进行充分的性能、可靠性、进行充分的性能

13、、可靠性、稳定性、安全等测试，并可以稳定性、安全等测试，并可以给予评估；给予评估；3 3、具备持续集成等工程能力，、具备持续集成等工程能力，且可有效提高归档、测试效率；且可有效提高归档、测试效率；4 4、可以评估代码覆盖度，并能、可以评估代码覆盖度，并能分析未覆盖代码的风险；分析未覆盖代码的风险；5 5、可以对产品做商用风险评估。、可以对产品做商用风险评估。1 1、测试工作已完全融入团队内每一、测试工作已完全融入团队内每一个人的基础工作中；个人的基础工作中；2 2、测试设计师规划测试范围、风险、测试设计师规划测试范围、风险热图，并分别将这些测试工作分散到热图，并分别将这些测试工作分散到开发人员、内部试用者、早期客户及开发人员、内部试用者、早期客户及众包测试人员等；众包测试人