电商项目实战测试流程 个人外汇业务测试包括什么内容和方法

寰球优品电商项目内-购物车的功能需求分析

01 寰球优品电商项目的核心业务流程

注册登录》浏览商品》添加购物车》提交订单》订单支付》查看订单

02 软件测试点分析基本原则–通用

第一步：先了解产品的基本业务流程逻辑：是个什么项目，做什么的，怎么工作的？画出流程图，业务逻辑梳理第二步：细分模块，针对每个小功能模块进行详细的划分：正常：覆盖正常核心业务流程--优先测试？？ ----单个功能冒烟测试异常：各种异常？？---贴近用户使用场景，确保产品正确处理，提示友好！注意：确保不遗漏，购物车输入项第三步：针对具体功能，寻找每个输入项，从以下角度来具体分析测试点长度，数据类型，必填项，重复需求的约束条件+隐形条件结合业务流程的步骤功能交互 -- 交叉

第四步：考虑非功能测试点，包括界面、易用性、兼容性、安全性、性能压力

03 购物车需求说明 二、购物车如何测试

三、如何提交bug 01 bug的内容 所属产品，所属模块，所属项目，影响版本，当前指派，截止如日期，bug类型，bug等级，bug优先级，操作系统，浏览器，bug标题，重现步骤 – 步骤-结果-期望 02、如何提交一个bug bug标题–标题要清晰简洁，写明bug描述：bug的功能模块+bug的操作+bug的结果。 重现步骤-详细写下发现bug的测试过程，能指导开发重现这个bug，附上测试数据。 实际结果–出现bug的结果，粘贴bug截图、日志截图。 预期结果–记得写清楚预期。 bug的类型和严重程度–便于后续测试结果分析，bug的统计。 bug测试环境–例如：什么系统，那个版本等。兼容性问题、难以重现问题。 附件–日志文件，文件测试时是数据。出现bug视频。图片、崩溃日志文件等。 03、bug编写格式要求 A、标题：出现bug的功能+出现bug的操作（输入数据）+bug具体结果（现象） B、步骤、结果、预期：换行写，写明bug的预期，添加bug的截图、测试数据、日志截图 C、附件：日志、测试数据（文件）图片、视频（效率不是特别高） D、bug类型、严重程度、测试环境、bug指派、所属模块 04、bug的类型 代码错误；设计缺陷；界面优化；配置相关；安装部署；性能问题；标准规范；测试代码。 05、bug的等级划分 A、严重造成系统崩溃、死机、死循环，与数据库连接错误，主要功能丧失，基本模块缺失等。 B、紧要系统主要功能不能使用，数据保存失败、丢失，功能与需求严重不符，存在安全性或者性能问题等。 C、一般功能没有完全实现或者存在缺陷，但是不影响使用，对业务、数据及操作没有影响。 D轻微界面等其他建议类问题，不影响操作。如：错别字、界面格式不整齐、文字排版、提示语句、显示多余内容等等。 06、项目中bug总结–bug跟踪流程 1、bug跟踪流程： 2、项目中bug总结： 提交bug时描述一定要清晰（标题+正文） bug记得一定要跟踪！！！并催着开发改bug！！！ 提交bug时确认是否重读提交，开发说bug重复如何处理？ 设计如此，不是缺陷的bug如何处理？ 无法重现的bug如何处理？ 不要局限在用例执行上面，要发散思维进行测试（细心耐心） —可以一边测试一边完善测试用例！ 做测试要有怀疑精神！！ ----站在用户立场/真是产品运行环境怀疑，参考同类型已成熟产品，觉得不好一定要确认。

四、工作中遇到的问题，怎么处理？ 01、提了一个bug，开发说不是bug，你怎么处理？ 开发人员说不是bug，有2种情况， 1、需求不确定 可以找来产品经理进行确认需不需要改动，三方商量确认好后再看要不要改。 2、这种情况下不可能发生，所以不需要修改 这个时候，我可以先尽可能的说出是bug的依据是什么》如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以把这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有 大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。 3、设计如此，不是缺陷的bug如何处理？