电商项目实战测试流程

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

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如何处理？