软件测试电商项目实战之购物车测试

一、购物车的功能需求分析

1）电商项目的核心业务流程

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

首先:要了解产品的基本业务流程比如这是什么方面的项目，业务情况，具体怎么工作的？画出流程图，对其业务逻辑进行梳理

其次:要细分模块，针对每个小功能模块再进行详细的划分：

正常：覆盖正常核心业务流程--优先测试？？----单个功能冒烟测试

异常：各种异常？？---贴近用户使用场景，确保产品正确处理，提示友好！

注意：确保不遗漏，购物车输入项

第三:要针对具体功能，寻找每个输入项，从以下角度来具体分析测试点：

长度，数据类型，必填项，重复
需求的约束条件+隐形条件
结合业务流程的步骤
功能交互 -- 交叉

第四:要考虑的就是非功能测试点，包括界面、易用性、兼容性、安全性、性能压力

3） 购物车需求说明

二、购物车如何测试

三、bug的提交

1、 bug的内容

2、如何提交一个bug

发现bug是测试人员必须具备的能力，不管在什么公司，测试人员在执行测试任务的时候，发现bug和提bug,以及跟踪Bug是必要的工作。如何提出高质量的bug,是体现测试人员水平的重要标志。从功能测试人员，到测试开发，高级测试开发等，都避免不了与bug打交道。可是现在也存在这么一种现象：测试人员提的bug质量不高，开发人员看不明白。于是就来找测试人员，来解释这个bug是怎么回事，如此来回折腾浪费工作时间，在跨部门协作的时候，这样的情况尤其严重。

主要从以下几个方面入手。

bug编写规范：标题：【模块】do 了什么操作出现了什么情况，预期结果是怎么样的；

bug步骤：前置条件、操作步骤（3条）、预期结果、实际结果， 截图（报错图、视频、日 志、bug分析图）， 是否必现

bug严重程度：根据规范定义

bug分析：使用Fiddler抓包工具，分析入参、响应，定位是前端和后端的问题

项目情况：若项目是重要紧急项目，需要把优先级别高的bug 汇总出来，邮件发送相关人员，进行跟踪；

4、bug的类型
代码错误；设计缺陷；界面优化；配置相关；安装部署；性能问题；标准规范；测试代码。

5、bug的等级划分
A级：严重造成系统崩溃、死机、死循环，与数据库连接错误，主要功能丧失，基本模块缺失等。
B级：紧要系统主要功能不能使用，数据保存失败、丢失，功能与需求严重不符，存在安全性或者性能问题等。
C级：一般功能没有完全实现或者存在缺陷，但是不影响使用，对业务、数据及操作没有影响。
D级：轻微界面等其他建议类问题，不影响操作。如：错别字、界面格式不整齐、文字排版、提示语句、显示多余内容等等。

6、项目中bug总结–bug跟踪流程

1、bug跟踪流程：

2、项目中bug总结：

提交bug时描述一定要清晰（标题+正文）

bug记得一定要跟踪！！！并催着开发改bug！！！

提交bug时确认是否重读提交，开发说bug重复如何处理？

设计如此，不是缺陷的bug如何处理？

无法重现的bug如何处理？

不要局限在用例执行上面，要发散思维进行测试（细心耐心）

—可以一边测试一边完善测试用例！

做测试要有怀疑精神！！

----站在用户立场/真是产品运行环境怀疑，参考同类型已成熟产品，觉得不好一定要确认。

四、工作中遇到的问题，怎么处理？

提了一个bug，开发说不是bug，你怎么处理？开发人员说不是bug，有2种情况：

1、需求不确定

可以找来产品经理进行确认需不需要改动，三方商量确认好后再看要不要改。
 

2、这种情况下不可能发生，所以不需要修改

这个时候，我可以先尽可能的说出是bug的依据是什么。如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以把这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

学技术就是要下功夫，一天一点点进步，熟能生巧，来海学通学软件测试技术，项目经理亲手带你一起做项目。

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

​

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！