Day3-4-业务测试实战2
业务测试实战
简介
- Web 端业务测试。
知识模块
- 测试流程 L1
- 测试用例设计 L1
- 用户端 Web 功能测试 L1
- 用户端 Web 功能测试 L2
知识点
- 掌握测试用例的设计与编写。
- 掌握完整的测试流程。
- 掌握 Web 端的测试方法。
受众
- 初级测试开发工程师
场景简介
测试工程师将进行一个商城后台管理系统的全流程测试。他的主要任务是测试商品管理模块,包括对功能进行验证、处理缺陷并进行回归测试。剧本涵盖了从项目启动到上线的所有测试环节,特别强调了在缺陷管理中如何进行前后端定位。团队成员包括产品经理、测试组长、测试工程师、开发人员和项目经理。
人物简介
- 测试工程师:负责商品管理模块的测试工作。
- 项目经理:负责整体项目的协调和进度管理。
- 测试组长:负责测试团队的管理和支持。
- 产品经理:负责产品需求和功能设计。
- 开发人员:负责商品管理模块的开发工作。
剧本情节
1. 项目启动
场景介绍: 会议室
项目经理召开项目启动会,介绍商城后台管理系统项目的目标、时间线和关键里程碑。产品经理详细说明了产品的核心功能和用户需求。测试组长、测试工程师和开发工程师参加会议。
对话片段:
- 项目经理:“欢迎大家参加商城后台管理系统项目启动会。我们将分工明确,确保每个模块的顺利开发和测试。”
- 产品经理:“我们主要关注商品管理模块的开发和测试,这是商城系统的核心部分。”
- 测试组长:“测试工程师将负责商品管理模块的测试工作,大家有任何问题可以随时沟通。”
两周一个版本
时间线 | 内容 |
---|---|
第一天 | 项目启动会议 |
第二天 | 需求宣讲、需求评审、测试计划制定 |
第三天 | 测试用例设计 |
第四天 | 测试用例设计 |
第五天 | 测试用例评审、测试用例录入 |
第六天 | 冒烟测试、第一轮测试 |
第七天 | 第一轮测试 |
第八天 | 回归测试与验收测试 |
第九天 | 项目上线 |
第十天 | 项目总结 |
2. 需求评审
场景介绍: 会议室
产品经理详细讲解商品管理模块的需求文档。
对话片段:
- 产品经理:“商品管理模块包括商品的添加、编辑、删除和库存管理。我们需要确保每个功能都符合业务需求。”
- 测试工程师:“库存管理部分如果发生库存不足的情况是否会有提醒功能?”
- 产品经理:“是的,库存低于设定阈值时,系统会发出提醒。”
3. 测试计划制定
场景介绍: 测试组内讨论
测试团队内部会议,测试组长和测试工程师讨论测试计划。
对话片段:
- 测试组长:“我们需要先来制定一下这次迭代的测试计划。”
4. 测试用例设计
场景介绍: 测试工程师的工位
测试用例设计阶段,测试工程师在电脑前撰写测试用例。
对话片段:
- 测试工程师(自言自语):要设计测试用例,除了基本的功能测试外,还要考虑各种边界情况和异常情况。
5. 测试用例评审
场景介绍: 会议室
产品经理、开发工程师、测试组长、和其他测试人员评审测试工程师的测试用例。
对话片段:
- 测试组长:“测试工程师的测试用例很详细,但请确保包括所有可能的边界情况。”
- 测试工程师:“明白,我会补充相关的异常场景和边界值测试用例。”
6. 测试用例禅道平台管理
场景介绍: 测试工程师的工位
测试工程师将设计的测试用例录入禅道测试管理平台。
对话片段:
- 测试工程师:“测试用例已经录入禅道平台,提测之后就开始执行测试了。”
7. 测试执行与缺陷管理
场景介绍: 测试工程师的工位
测试工程师执行测试用例,发现了一个功能缺陷,并进行缺陷管理。
对话片段:
测试工程师(对自己说):“商品查询功能没有返回结果。我先检查一下前端代码,看看有没有输入错误或者接口调用问题。”
(打开浏览器的开发者工具,检查前端代码)
测试工程师(对自己说):“前端代码看起来没有问题,接口调用也正常。让我检查一下网络请求和响应。”
(检查网络请求和响应,发现接口返回的数据为空)
测试工程师(对自己说):“接口的响应状态码为 200,但是接口返回的数据为空,看来问题出在后端。我再检查一下后端日志和数据库查询。”
(连接到后端服务器,查看日志和数据库查询)
测试工程师(对自己说):“后端日志显示查询语句执行了,但返回了空结果。我确认数据库里有这个商品,看来是查询语句有问题。我要把这个问题记录下来。”
测试工程师:开发工程师,我在测试商品查询功能时发现了一个 bug。前后端我都检查过了,前端接口调用正常,问题出在后端查询语句。我已经在缺陷管理系统中记录了详细信息。
开发工程师:好的,我会查看缺陷管理系统中的记录,检查后端查询语句。
问题:
- 如何通过常见的响应状态码判断错误原因?
- 接口报错怎么处理?
- 前端 Bug 还是后端 Bug?
8. 回归测试与验收测试
场景介绍:测试工程师的工位
项目即将上线,测试工程师进行回归测试,确认修复的缺陷不会影响其他功能。
对话片段:
- 开发工程师:“测试工程师,我查到问题了。确实是查询语句中的一个过滤条件有误,导致了返回空结果。我已经修复了,现在你们可以重新测试一下。”
- 测试工程师:“我刚刚重新测试了商品查询功能,问题已经解决了,现在能够正确返回搜索结果。我去更新一下缺陷报告的状态。”
- 测试组长:“我们还需要做一次回归测试,确保这次修改没有影响到其他功能。”
- 测试工程师:“明白,我会尽快进行回归测试,确保所有相关功能都正常。”
9. 项目总结与上线
场景介绍:会议室
项目总结会议室,团队讨论项目上线前的准备和经验教训。
对话片段:
- 项目经理:“大家好,今天我们召开项目总结会议,回顾商城后台管理系统的开发和测试过程。感谢大家的努力和贡献。”
- 测试组长:“总体来说,这次商品管理模块的测试进行得比较顺利,但也遇到了一些挑战。测试工程师,你可以先说说你发现的主要问题和解决方案吗?”
- 测试工程师:“好的。我们在商品查询功能中发现了一个 Bug,最初开发团队认为不是 Bug,但经过详细的前后端定位,我们确认了问题出在后端查询语句。这个问题在修复后我们进行了全面的回归测试,确保没有影响其他功能。”
- 开发工程师:开发过程中,我们发现有些需求变更比较频繁,导致我们需要不断调整开发计划。这对我们的工作造成了一些影响。下次我们可以考虑在需求评审阶段把需求定义得更清晰。另外,我们会加强代码审查,避免类似的查询语句问题再次发生。
- 产品经理:“是的,我们在需求评审阶段确实有些地方没有考虑周全,导致后期的变更频繁。下次我们会在需求评审阶段多花些时间,确保所有需求都能被清晰定义和理解。同时,我们会加强与开发和测试团队的沟通,确保每次需求变更都能得到及时的反馈。”
- 项目经理:“感谢各位的总结和反馈。这次项目虽然有些挑战,但整体表现还是很不错的。总结几点改进措施:1. 增强需求评审阶段的细致程度,减少后期变更。2. 优化测试用例设计和管理,提高覆盖率和执行效率。3. 加强代码审查,避免类似问题的再次发生。还有其他要补充的吗?”
- 测试组长:“我觉得可以增加一些自动化测试,减轻手动测试的压力,尤其是在回归测试阶段。”
- 开发工程师:“这是个好主意,我们也可以在开发过程中加入更多的单元测试,确保每个模块的质量。”
- 产品经理:“我们也会在需求评审阶段加入更多实际业务场景的讨论,确保需求的可行性和合理性。”
- 项目经理:“非常好,大家的建议都很有建设性。我们会在下个项目中尝试这些改进措施,希望能提高我们的整体效率和质量。感谢大家的参与和努力,这次会议就到这里。祝大家在下一个项目中继续取得好成绩。”
剧本复盘
总结
通过这个完整的流程,展示了测试工程师如何从需求评审到缺陷管理,再到项目总结,全程参与项目的测试工作。