提交测试

我所在传统项目这样的工作经历，开发小组 提交给 QA小组的软件，经常是送到时就不能用、不能打开，或者刚启动就崩溃了。

所以提交测试时，需要有一个接收标准，达不到标准，测试小组不接收。

ShowCase和冒烟测试

维度	ShowCase	冒烟测试
目的	展示功能完成度，获取业务方的验收认可	验证系统基本功能是否正常，决定是否进入全面测试
执行者	开发人员为主，面向产品经理和业务方	测试人员为主，面向技术团队
形式	手动演示，注重用户体验和业务逻辑	自动化或半自动化，注重功能和技术验证
覆盖范围	关注具体功能模块或业务场景	关注核心功能和主流程
执行时机	提测前或迭代结束时	提测后，正式测试前

在实际项目中，ShowCase和冒烟测试可能会结合使用：

• ShowCase更倾向于业务验收，关注的是功能是否符合需求。
• 冒烟测试则是技术层面的初步验证，确保系统具备进一步测试的条件。
• ShowCase是“业务导向”，强调功能展示和验收。
• 冒烟测试是“技术导向”，强调系统稳定性和基础功能验证。

干货

1. 开发人员完成功能后，先进行ShowCase，向产品经理和测试人员演示功能。证明软件是可以运行的。
2. ShowCase通过后，开发人员发出 提交测试通知， 测试人员接手，测试人员执行冒烟测试。
3. 冒烟测试通过后，项目正式进入全面测试阶段。

ShowCase的目标

• 核心目标：

  • 向业务方展示功能实现情况，确保符合需求。
  • 获取反馈并确认功能是否达到验收标准。

• 适用场景：

  • 功能开发完成后，提测前或迭代结束时。

如何做好ShowCase

明确目标与范围

• 聚焦核心功能

  • 确保演示内容围绕核心需求，避免无关细节。
  • 提前与产品经理沟通，明确需要展示的功能点。

• 覆盖关键场景

  • 演示正常流程及重要异常处理（如错误提示）。
  • 展示用户操作的完整闭环（如从登录到完成任务）。

准备工作

• 环境准备

  • 确保演示环境稳定，避免因技术问题中断。
  • 准备必要的测试数据（如账号、初始化配置等）。

• 脚本编写

  • 制定清晰的演示脚本，包含操作步骤和预期结果。
  • 示例脚本：1. 打开系统登录页面。 2. 输入用户名“test”和密码“123456”，点击“登录”。 3. 验证跳转至首页，并显示欢迎信息。

• 演练与检查

  • 提前进行内部演练，确保演示流畅无误。
  • 检查UI效果、交互逻辑及数据一致性。

执行过程

• 参与人员

  • 开发人员主导演示，产品经理、测试人员、业务部门代表共同参与。

• 执行要点

  • 按照脚本逐步演示功能，突出关键点。
  • 解答业务方提出的问题，记录反馈意见。
  • 若发现问题，及时说明原因并承诺修复计划。

输出成果

• 形成文档

  • 收集并整理反馈，形成《ShowCase通过》邮件或文档。
  • 若未通过，需明确问题清单及后续改进计划。

• 通知机制

  • 发送《ShowCase结果通知》邮件，同步所有相关方。

ShowCase的注意事项

• 时间控制
  演示时间应控制在30分钟以内，避免冗长。

• 用户体验
  关注界面美观性、交互流畅性和响应速度。

• 沟通技巧

  • 用通俗易懂的语言解释技术实现，避免过于专业化的术语。
  • 主动引导讨论，获取有价值的反馈。

总结

ShowCase是功能验收的重要环节，通过明确目标、充分准备和高效执行，可以有效提升业务方对功能的认可度。做好ShowCase不仅能确保功能符合需求，还能为后续测试和上线奠定良好基础。