资深测试经理，如何践行测试质量管理的工作

本文链接：https://blog.csdn.net/zh6526157/article/details/145710015

资深测试经理，如何践行测试质量管理的工作

一、软件需求评审阶段

（一）工作流程

提前准备
- 在需求评审会议之前，要求产品经理详细提供需求文档，包括功能描述、业务流程、用户故事等。测试团队要对这些文档进行预审，标记出可能存在模糊性、不一致性和可测试性问题的地方。
- 例如，对于一个电商软件的新需求，增加一种新的促销方式 “满减阶梯优惠”。测试人员在预审时，就要关注优惠规则的具体计算逻辑，如满 100 减 10、满 200 减 30 这种阶梯是如何确定的，以及与其他促销活动（如满赠、折扣）的叠加规则。
评审会议参与
- 测试经理带领测试团队全程参与需求评审会议。在会议上，积极提问和讨论预审时发现的问题。从测试的角度，确保需求是可测试的，即能够明确地设计测试用例来验证需求是否得到满足。
- 比如，对于上述电商促销需求，测试人员要询问清楚在各种商品组合、用户购买数量等情况下，优惠是否能正确计算。同时，要和开发团队、产品经理一起确定验收标准，如优惠金额计算准确率要达到 100%，优惠提示信息要在用户下单页面准确显示等。

（二）细节把控

需求完整性检查
- 仔细检查需求是否涵盖了所有可能的场景。以一个在线教育软件的需求为例，对于课程视频播放功能，除了正常的播放、暂停、拖动进度条等基本操作外，还要考虑网络不稳定时的播放情况，如是否会出现卡顿、加载失败等情况，以及不同设备（手机、平板、电脑）上的兼容性问题。
需求可追溯性建立
- 确保每个需求点都能追溯到相应的测试用例。在需求文档中，为每个需求编号，然后在测试用例管理工具中，将测试用例与对应的需求编号关联起来。这样在后续测试过程中，可以清晰地知道每个测试用例是针对哪个需求进行验证的，也方便在需求变更时，快速定位受影响的测试用例。

（三）质量门禁

需求通过标准确定
- 设定需求评审通过的标准，如需求描述清晰、完整、一致，验收标准明确等。如果需求没有达到这些标准，就不允许进入研发阶段。例如，对于一个新的社交软件的私信功能需求，如果对于消息加密方式、存储期限等关键细节没有明确说明，就要求产品经理补充完善，否则测试团队有权否决该需求进入下一步。
评审记录保存与跟踪
- 详细记录需求评审会议的内容，包括讨论的问题、达成的共识、确定的验收标准等。将这些记录保存在项目管理工具中，并定期跟踪需求的变更情况。如果在后续阶段发现与评审记录不符的情况，及时进行沟通和解决。

二、研发阶段

（一）工作流程

测试左移 - 参与设计阶段
- 测试团队在研发初期就参与系统设计讨论。开发人员分享系统架构、模块划分、接口设计等内容，测试人员从测试角度提出建议。例如，在开发一个金融软件的账户管理系统时，测试人员可以建议在数据库设计中，为关键账户信息字段添加校验规则，以便在数据录入阶段就能减少错误。
持续沟通与代码审查参与
- 测试人员与开发人员保持密切沟通，了解开发进度和代码实现情况。定期参与代码审查，虽然测试人员不是代码编写的专家，但可以从可测试性、边界条件处理等方面提出意见。比如，在审查一个涉及文件上传功能的代码时，测试人员可以关注代码是否对文件大小、格式等边界条件进行了有效处理。

（二）细节把控

接口测试用例设计
- 根据系统设计文档，提前设计接口测试用例。对于一个电商系统，商品服务、订单服务、用户服务之间存在大量的接口交互。测试人员要设计接口测试用例，验证接口的参数传递是否正确、返回值是否符合预期、接口的性能是否满足要求等细节。例如，商品服务向订单服务提供商品价格和库存信息的接口，测试用例要检查在库存不足、价格异常等情况下，接口返回的信息是否准确。
单元测试监督与协助
- 监督开发人员进行单元测试，并在必要时提供协助。要求开发人员提供单元测试报告，测试报告要包括测试覆盖率、测试通过率等指标。例如，对于一个算法模块的开发，测试人员要确保开发人员的单元测试覆盖了各种正常和异常的输入情况，并且测试通过率达到一定标准（如 90% 以上）。

（三）质量门禁

代码提交标准设定
- 设定代码提交的标准，如代码要经过开发人员自测（单元测试通过）、代码风格符合规范等。如果代码没有达到这些标准，不允许提交到版本控制系统。例如，开发人员在提交代码时，如果没有提供单元测试报告或者代码中存在明显的格式问题（如缩进不一致），测试团队可以要求开发人员重新修改后再提交。
接口测试通过标准确定
- 确定接口测试通过的标准，如接口功能正确、性能指标达标等。只有当接口测试通过后，才能进行集成测试。例如，对于一个支付接口，测试通过的标准包括支付成功率要达到一定比例（如 99% 以上）、响应时间要在规定范围内（如小于 3 秒）等。

三、测试阶段

（一）工作流程

全面测试策略制定
- 根据需求和系统设计，制定全面的测试策略，包括功能测试、性能测试、安全测试、兼容性测试等多个方面。对于一个医疗软件，功能测试要覆盖患者预约、挂号、就诊、缴费等全流程；性能测试要考虑医院高峰期的用户并发量；安全测试要关注患者隐私数据的保护；兼容性测试要确保软件在不同操作系统（如 Windows、Mac OS）和浏览器（如 Chrome、Firefox）上都能正常运行。
测试执行与缺陷管理
- 按照测试策略执行测试用例，记录测试结果。发现缺陷后，使用缺陷管理工具（如 JIRA）详细记录缺陷信息，包括缺陷描述、重现步骤、严重程度、优先级等。开发人员根据这些信息进行缺陷修复，测试人员在缺陷修复后进行回归测试。例如，在测试一个办公软件的文档编辑功能时，发现输入特殊字符后软件崩溃，测试人员将该缺陷标记为高严重程度、高优先级，开发人员修复后，测试人员再次进行测试，确保缺陷已经解决且没有引入新的问题。

（二）细节把控

测试数据管理
- 重视测试数据的准备和管理。对于一个金融软件的测试，要准备各种类型的测试数据，如正常的账户余额数据、异常的交易数据（如负数交易金额）等。同时，要确保测试数据的安全性和保密性，不能使用真实的用户数据进行测试。在测试过程中，对测试数据进行备份和恢复，保证测试环境的稳定性。
测试环境维护
- 确保测试环境与生产环境尽可能一致。对于一个大型的电商网站，测试环境要模拟真实的服务器配置、网络环境、数据库版本等。定期对测试环境进行维护，如更新软件版本、修复漏洞等。例如，在测试过程中，如果发现由于测试环境的数据库版本与生产环境不一致导致的问题，要及时更新测试环境的数据库版本，以保证测试结果的准确性。

（三）质量门禁

测试通过标准设定
- 设定测试通过的标准，如功能测试通过率达到一定比例（如 95% 以上）、关键缺陷全部修复等。只有当软件满足这些标准后，才能进入上线准备阶段。例如，对于一个游戏软件，测试通过的标准包括游戏主要玩法功能正常、没有严重的游戏卡顿和崩溃问题等。
缺陷修复标准确定
- 确定缺陷修复的标准，如高严重程度的缺陷必须全部修复，中严重程度的缺陷要在不影响主要功能的情况下进行修复或记录风险，低严重程度的缺陷可以根据项目进度和资源情况进行评估。例如，在一个企业资源规划（ERP）软件的测试中，对于影响财务数据准确性的高严重程度缺陷，必须在上线前全部修复；对于一些界面显示的小问题，如果不会影响用户操作，可以在上线后记录为待优化项。

四、上线阶段

（一）工作流程

上线前最后检查
- 在软件上线前，进行最后的检查，包括部署环境的检查、配置文件的核对、上线包的验证等。对于一个移动应用的上线，要检查应用商店的配置信息是否正确，如应用图标、版本号、描述等。同时，要验证上线包的完整性和正确性，确保安装和启动没有问题。
测试右移 - 上线后监控与用户反馈收集
- 软件上线后，持续监控系统的运行状态，包括服务器性能、用户访问情况等。通过日志分析工具，及时发现潜在的问题。同时，收集用户反馈，对于用户反馈的问题，及时进行分析和处理。例如，在一个社交软件上线新功能后，通过服务器监控发现部分用户在使用新功能时出现加载缓慢的情况，及时定位问题并进行优化。

（二）细节把控

上线文档审核
- 审核上线文档，包括部署手册、用户手册等。部署手册要详细说明软件的安装、配置和启动步骤，确保运维人员能够按照手册顺利部署软件。用户手册要清晰地介绍软件的功能和使用方法，方便用户快速上手。例如，在一个在线客服软件上线时，审核部署手册中的数据库配置部分，确保参数设置正确；审核用户手册中的聊天功能介绍，确保用户能够理解如何发起聊天、发送文件等操作。
回滚策略制定与验证
- 制定详细的回滚策略，以应对可能出现的上线失败情况。在上线前，验证回滚策略的可行性。例如，对于一个电商平台的大版本更新，如果在上线后发现严重影响用户购物体验的问题，要能够快速回滚到旧版本。回滚策略包括数据回滚、代码回滚等内容，要提前在测试环境中进行验证，确保回滚过程不会造成数据丢失或系统故障。

（三）质量门禁

上线批准标准确定
- 设定上线批准的标准，如软件通过了上线前的最后检查、没有未解决的关键问题等。只有当软件满足这些标准后，才能正式上线。例如，对于一个金融交易软件，只有在通过了安全测试、性能测试，并且所有关键功能正常的情况下，才能获得上线批准。
上线后质量跟踪标准设定
- 确定上线后质量跟踪的标准，如系统稳定性指标（如服务器 uptime 达到一定比例）、用户满意度指标（如用户投诉率低于一定比例）等。如果软件在上线后没有达到这些标准，要及时进行问题分析和解决。例如，在一个视频播放软件上线新版本后，如果用户投诉视频播放卡顿的比例超过 5%，就要及时排查问题，可能是服务器带宽不足或者视频编码问题等原因导致的。