Devops业务价值流:敏捷测试最佳实践

在迭代增量开发模式下,我们强调按照用户故事的优先级进行软件小功能的频繁交付。由于迭代周期紧凑,测试与开发活动往往并行进行,测试时间相对有限。为确保在这种快节奏的开发环境中依然能够保持产品质量,我们特制定以下测试阶段的工作流规范,旨在明确测试的准入准出标准,以及各相关活动的执行规则。

测试驱动开发的思想

我们秉承测试驱动开发(Test-Driven Development, TDD)的核心理念,将测试视为开发过程不可或缺的一部分。通过先编写测试用例,再编写满足这些用例的代码的方式,我们确保每个功能在开发之初就经过了充分的思考和验证。这一思想不仅有助于提前发现潜在问题,还能促进代码的可测试性和可维护性。

测试工作流规范
  1. 准入标准:

    1. 需求文档清晰明确,无歧义。

    2. 开发计划已确定,包括迭代周期、功能点等。

    3. 测试环境已搭建完毕,且与开发环境保持一致。

    4. 测试用例已根据需求文档编写完成,并通过了评审。

  2. 测试活动执行规则:

    1. 功能测试:验证每个功能点是否按照需求文档实现,确保功能完整性和正确性。

    2. 系统测试:从整体上检查系统的稳定性和性能,确保各功能点之间的协同工作正常。

    3. 探索性测试:测试人员根据对系统的理解和直觉,进行非预设路径的测试,以发现可能的缺陷或改进点。

    4. 补充测试:针对已发现的缺陷进行回归测试,确保问题得到修复,并验证修复后的系统稳定性。

  3. 准出标准:

    1. 所有测试用例均已通过,无未解决的严重缺陷。

    2. 系统性能和稳定性满足既定的质量标准。

    3. 测试报告已编写完成,详细记录了测试过程、结果及建议。

规范测试上下游活动

为确保测试工作的顺利进行,我们还需要规范测试上下游的活动。这包括但不限于:

  • 需求阶段:测试人员需积极参与需求评审,确保对需求有充分理解,并能提出潜在的测试挑战。

  • 开发阶段:与开发团队保持密切沟通,及时了解开发进度和潜在问题,以便及时调整测试计划。

  • 缺陷管理:建立有效的缺陷管理流程,确保缺陷得到及时记录、跟踪和解决。

  • 验收阶段:邀请产品经理、UI团队等相关方进行产品验收,确保产品符合业务需求和设计标准。

6.1 需求评审

6.1.1目标:

确保测试团队对需求有充分理解,指出不明确或需要澄清的地方。

6.1.2具体流程:
  1. 测试工程师提前阅读并熟悉需求文档。

  2. 参与迭代需求评审会议,与产品经理、开发团队等共同讨论需求。

  3. 在会议中及时提出对需求不明确或有疑问的地方,寻求澄清。

  4. 会后整理并输出《Xmind 测试点》或其他形式的思维导图,明确测试重点。

6.2 评估工作量

6.2.1目标:

根据需求文档和测试点,合理评估测试工作量,制定测试计划。

6.2.2具体流程:
  1. 测试工程师根据需求讲解和测试点,估算每个功能模块的测试时间。

  2. 使用《测试计划》模板,详细列出测试活动的时间节点、负责人和预期工作量,测试计划与迭代计划匹配。

  3. 测试负责人收集各功能模块的测试时间,确认工作量估算的准确性和合理性。

  4. 输出《xx项目版本名称测试计划》文档,作为后续测试工作的依据。

6.3 编制测试用例

6.3.1目标:

根据需求文档和测试点,编制全面、详细的测试用例。

6.3.2具体流程:
  1. 测试工程师按照场景描述法,基于测试点编制测试用例。

  2. 每个测试用例应包括前置条件、测试步骤、期望结果和优先级等信息。

  3. 确保每个功能点的测试用例数量不低于10条,以满足测试覆盖率和质量的要求。

  4. 输出Xmind及测试用例文档,供后续测试使用。

6.4 评审测试用例

6.4.1目标:

通过评审确保测试用例的准确性和完整性,提高测试质量。

6.4.2具体流程:
  1. 测试工程师组织测试用例评审会议,邀请产品经理、开发团队等参加。

  2. 在会议中详细介绍测试用例,并接受其他团队成员的提问和建议。

  3. 根据评审结果,对测试用例进行修改和完善,确保覆盖率和质量。

  4. 输出《测试用例》和《自测清单》文档,作为后续测试执行的依据。

6.5 执行迭代测试

6.5.1目标:

根据测试计划,系统性执行测试任务,精准识别并记录产品中的问题,确保产品质量符合预期。

6.5.2具体流程:
  1. 版本接收与验证

    1. 测试工程师接收开发团队提交的测试版本,并进行必要的验证工作,确保版本无误且具备测试条件。
  2. 冒烟测试

    1. 迅速执行冒烟测试,验证测试环境的基本可用性和关键功能的初步实现情况,确保测试能够顺利进行。
  3. 第一轮全量测试

    1. 全面执行测试计划中的全量测试用例,详细记录测试结果与通过率,对功能的完整性和正确性进行全面评估。

    2. 功能性测试:严格对照需求文档,逐一验证每个功能点的实现情况,确保功能的准确性和完整性。

  4. 缺陷管理与回归测试

    1. 根据第一轮测试的详细结果,及时录入新发现的缺陷,并启动回归测试流程,验证已修复缺陷的准确性和修复后系统的稳定性。
  5. 第二轮全量测试

    1. 再次执行全量测试用例,进一步验证产品的质量,确保所有已知问题均得到有效解决,并巩固第一轮测试的成果。
  6. 第三轮全量测试

    1. 系统性测试:从宏观角度全面审视系统的整体性能和稳定性,确保各功能模块之间的协同运作流畅无阻,满足系统级需求。

    2. 探索性测试:测试人员凭借对系统的深入理解与直觉,灵活开展非预设路径的测试,旨在发掘潜在缺陷或改进空间,提升系统的健壮性和用户体验。

6.6 产品验收

6.6.1目标:

邀请产品经理和UI团队进行验收,确保产品符合业务需求和设计标准。

6.6.2具体流程:
  1. 测试工程师在第一轮测试完成后,通知产品经理和UI团队进行验收。

  2. 产品经理和UI团队根据验收标准对产品进行验收,并给出验收结论。

  3. 测试工程师记录验收结论,并在测试报告中体现。

6.7 迭代回顾

6.7.1目标:

从整体上了解团队的研发效能情况,及时发现研发过程的问题,通过问题分解和深入分析,找出问题根因和改进点,从而驱动团队的持续改进

6.7.2具体流程:
  1. 确立复盘会议基调:

    1. 明确复盘会议的基本原则,强调开放、诚实、建设性的沟通氛围。

    2. 重申复盘会议的目的,即促进团队学习与成长,而非指责与批评。

  2. 跟踪改进项进度:

    1. 回顾上一次复盘会议中提出的所有改进项,检查其完成情况。

    2. 对已完成的改进项进行效果评估,对未完成项分析原因并调整计划。

  3. 展示当前效能数据:

    1. 利用图表和数据直观展示团队当前的研发效能,包括进度、质量、效率等方面的关键指标。

    2. 对比目标与实际效能,明确差距所在。

  4. 迭代燃尽图与工作项分析:

    1. 详细解读本次迭代的燃尽图,分析工作项的完成情况、剩余工作量及潜在风险。

    2. 突出关键路径上的工作项,评估其对整体进度的影响。

  5. 收集并整合反馈:

    1. 采用匿名或开放的方式收集参会人员的反馈,涵盖做得好的方面和需改进的方面。

    2. 对反馈进行分类整理,提炼出共性问题与个性建议。

  6. 深入分析与制定方案:

    1. 基于数据和反馈,进行综合分析,找出问题的根源。

    2. 针对每个问题制定具体的改进方案,明确改进方向、预期效果及实施步骤。

  7. 明确责任与时间表:

    1. 为每个改进方案指定负责人,确保责任到人。

    2. 设定合理的期望完成时间,确保改进计划得以有效执行。

  8. 形成改进项列表:

    1. 编制详细的改进项列表,包括改进内容、负责人、期望完成时间等信息。

    2. 确保列表清晰明了,便于跟踪与监督。

  9. 会议纪要撰写与分享:

    1. 整理复盘会议的会议纪要,准确记录会议讨论的重点、决策及改进措施。

    2. 及时将会议纪要发送给所有参会人员及相关利益方,确保信息透明与共享。

  10. 持续优化与跟踪:

    1. 设立定期跟踪机制,确保改进方案得到有效执行。

    2. 根据执行情况适时调整改进策略,形成持续改进的良性循环。

相关推荐
难以触及的高度30 分钟前
MySQL5.7.37安装配置
linux·运维·服务器
朝九晚五ฺ37 分钟前
【Linux探索学习】第十三弹——进程状态:深入理解操作系统进程状态与Linux操作系统中的进程状态
linux·运维·学习
StringKai40 分钟前
表单自动化填写-JavaScript脚本
运维·自动化
2401_870042391 小时前
CISAW- CDF 认证电子数据取证训练: Linux 取证分析实战
linux·运维·服务器
喝旺仔la1 小时前
Linux的基本用法
linux·运维·服务器
wowocpp2 小时前
ubuntu 22.04 shell
linux·运维·ubuntu
dreams_dream2 小时前
nginx证书流式响应配置
运维·nginx
DisonTangor2 小时前
【个人笔记】如何将 Linux 文件系统扩容
linux·运维·笔记
源来猿往2 小时前
问题An object named ‘ResNetArcFace‘ was already registered in ‘arch‘ registry!
linux·运维·服务器