标签：同步 修复 inf 执行 引入 特性 核心 测试的 技术分享
从年前工作调动进入维护测试组到现在有快5个月的时间了。开始对维护测试的工作职责、工作内容有了大概的了解。同时也在思考维护测试对于产品的价值、在部门组织架构
中的位置、维护测试工作的核心以及对维护测试团队设置自己的技能要求，包括业务能力、技术能力、沟通能力等等。下面就从几个方面简述一下个人看法。
维护测试就是软件产品发布之后的维护阶段的测试， 就是处于产品GA(全球发布)~EOS阶段。下面先是软件测试生命周期图-IPD和PTM各阶段的对应：
缩写解释：GA（全球发布）、EOP（停止生产）、EOM（停止维护）、EOS（停止服务）
（Charter~GA）这个阶段的需求测试，它和维护测试有什么区别？
1、版本启动入口：需求测试是以现场调研、客户需求驱动，维护测试是以现网问题单，小部分补丁会合入需求。
2、工作量：需求测试整体测试工作量会更大，以需求版本号发布。维护测试主要以补丁版本发布，以补丁版本形式发布。
3、交付件：需求测试是功能，维护测试是问题单修复。两者都包括资料。
维护测试职责，个人并没有看到专门针对维护测试的工作职责，根据个人理解，应该包括但不限如下：
1、负责维护现网运行产品稳定、提供有效解决方法。
2、负责支撑现一线和客户业务类问题答疑、分析。
3、负责补丁版本测试各项工作，包括提供给一线的工具验证。
4、负责现网操作指导书验证，保证不出现现网操作类导致的事故。
维护测试工作内容包括但不限如下：
1、负责补丁版本测试，包括问题单和需求分析、测试方案和用例设计、测试执行。
2、负责现网操作指导书验证。包括补丁升级、平台升级、割接测试、镜像测试操作指导书等验证，
3、快速复现、分析现网问题，跟踪并验证问题解决方案。
4、快速响应一线和客户针对业务、操作等问题答疑。
总结就是：测补丁、测升级、现网问题复现、现网支撑。针对当前所在产品的特点和测试要求再细化说工作内容：
补丁版本测试：补丁版本的测试内容就像上述说的主要是问题单，合入补丁的问题单有几种类型：新开发、同步单、需求、资料单，需要针对这些问题单做测试设计和执
行。另外一部分是例行的质量保障测试工作，包括ATP用例执行、自动化工厂用例批跑、代码覆盖率扫描、内存泄漏扫描和周边配套产品（固定接口）的测试以及补丁不同
升级路径的验证。补丁版本发布质量要求就是不能有已知缺陷发布、上线不能引入新问题。
升级验证测试：升级验证工作在当前工作内容中占用相当大的一个比重，各种各样的升级验证、割接测试都有。因此，项目组也积累了大量的经验并固化到规范文档、工
具，可以确保升级验证的质量和效率。在验证升级前一定要仔细阅读升级规范，了解升级前准备、升级过程中操作和观察点、过程数据收集、升级后的检查和用例验证、回
退等等操作。一定要符合规范。
现网问题复现、分析和答疑：现网问题的定位分析通常是与开发配合完成。测试要保证快速搭建现网环境、完成场景复现、熟悉各种测试工具和分析方法以及与客户的沟通。
对比需求测试来说，维护测试要直接面对现网问题，而现网问题出现通常来说有几个特点：业务形态不确定、问题复现难度高、触发问题出现的面广。因此对维护测试人
员的要求就是要对业务熟悉面更广、技能更全面、测试分析能力强、问题推动解决能力高等。就是说要全才，但是全才意味着不精通。具体怎么做对项目组、对自己的发展
更有利，可以权衡思考一下。从个人发展角度来看，可以从业务型和技术型两个方向考虑，如果是业务类的你就把业务搞熟悉、不仅仅局限于某个需求、某个特性。如果技
术型的，就好好打磨自己的编码能力、基础能力（OS、网络、数据库）、问题分析能力等等。当然，这都不能偏离测试本质工作能力，包括测试需求分析、测试设计能力。
最明显的一点要求就是对现网问题复现的实时性，需要保持个人通讯顺畅，加上如果你的产品遍布全球，由于时差的关系，就需要做好睡觉时间起来定位问题的准备了，
如果你的产品质量不行，那就有的忙活了。所以有合适机会也可以跟领导诉说诉说，把质量做在前面。
本文仅是根据个人所在产品的特点和总结了维护测试的工作内容、工作特点，难免有偏颇。仅是供需要的人在做选择时参考。不论在哪个领域，想办法提升自己的实力。因为能力越
强，选择越广。
标签：同步 修复 inf 执行 引入 特性 核心 测试的 技术分享
原文地址：https://www.cnblogs.com/linyfeng/p/8905708.html
