软件测试电商类项目介绍模版
参考项目一：xx商城（WEB端和APP端）
项目背景：我最近做的项目是xx商城，这个项目是一款综合性的B2C购物平台，用户可
以在商城浏览商品，下订单，以及参与商城的各种活动；商家可以入驻商城，在平台开店
出售自己的商品，并且会得到平台的服务支持。主要通过商家的入驻或者给商家提供服务
来盈利。
项目模块：
前台：首页，商品分类，发现，购物车，我的
后台：商品管理，订单管理，交易管理，会员管理
负责的模块（可选）：
（1）我主要负责购物车模块。
对于购物车这个模块，根据业务流程去分析，主要考虑到加入购物车和购物车的编辑查看这两个点。
加入购物车根据客户的业务场景，主要分为功能入口、权限、商品属性、场景覆盖这几个点去分析。首先考虑到购物车的功能入口，每个入口是否可以正常进入购物车，然后考虑加入购物车的功能权限，在用户已经登录账户的情况下，商品是否可以正常加入购物车，也要考虑用户未登录账户的情况下，商品是否可以加入入购物车，然后考虑加入购物车时商品属性测试，比如旅行箱的属性有尺寸：20寸、24寸、26寸，颜：黄、红、蓝和紫，那就要根据边界值去考虑商品属性组合与库存的情况，另外还要去检查前台展示商品属性是否与后台展示一致，还有后台商品属性的添加、删除、修改前台展示数据是否同步，检查展示数据是否正确，再有就是商品数量的组件测试，点击加减控键数量是否正常加1或减1，还要考虑商品数量加到最大库存以及减到最小数量数量组件是否置灰，还有输入框测试，用到等价类边界值去分析设计用例，还要根据业务场景覆盖，考虑到同一商品同一属性加入购物车，同一商品不同属性加入购物车以及不同的商品加入购物车，购物车页面商品展示情况。
购物车的编辑查看主要考虑商品的数量编辑，商品管理，失效商品以及点击商品页面正常跳转这几个点，商品的数量编辑主要考虑商品数量键和输入框，也是加减空键的正常使用，运用到等价类边界值去考虑输入框的长度、类型、必填项、默认值。商品管理主要根据页面的功能键去考虑商品删除和商品收藏这两个点，站在用户的角度要去考虑删除或收藏单个商品，多个商品以及全选删除的情况，然后还要去检查页面展示情况以及数据库的检查。失效商品主要考虑商家下架商品或库存为0的商品是否
展示在失效商品栏，以及失效商品验证后台上架或库存不足的商品添加库存前台是否不再显示失效商品，在购物车页面，还要检查点击标题或图片是否正常跳转到商品详情页面，点击立即下单是否正常跳转到订单结算
页面。
（2）我主要负责订单模块。
订单方面可以从订单的状态转换方面来考虑，从订单的生成，到待付款，到待收货，到待评价，到订单完成，最后到售后/退款这几个状态来分析，还要结合后台的数据跟数据库表的数据来进行验证。
订单的生成，首先从用户权限考虑，没登录的用户无法生成订单，只有登录的用户才可以进行购买操作；一个订单的生成也包括几个方面，比如入口的测试，地址的编辑，积分、优惠券的使用规则，会员优惠，快递，支付方式的选择。1.入口测试方面，可以从我们通过怎样的操作进入支付页面；2.地址方面首先要区分之前有无地址，没有地址的情况下我们要先创建地址，有地址的时候我们可以选择其他的地址；3.积分方面我们要知道积分的兑换比例，以及积分的使用规则；4.会员优惠方面要知道有多少种会员，每种会员的优惠力度是怎样的，我们要怎样达到更高的会员；5.备注信息的话要测试备注输入框的合法性以及必须性；
7.支付方式我们要知道有哪些支付方式，是否可以组合支付，比如积分跟余额，优惠券跟余额，积分跟优惠券之类的组合是否可以使用；6.还有一个需要详细考虑的是优惠券方面的分析，从有无优惠券，到有哪些种类的优惠券，到每种优惠券的可用、不可用情况的分析，到不同种类的优惠券组合分析；比如满减优惠券，一个无优惠券，这个没得想，没优惠券就是现实没优惠券，但是有优惠券的时候我们要考虑优惠券的分类，像通用满减，品类满减，专属商品满减，比如通用满减券满100减20，我们要分析什么时候是可用的，比如单件商品价格满100，多件商品价格满100，商品价格超过100，我们还要分析什么时候是不可用的，比如已使用过的优惠券我们是不可用的，后台操作优惠券失效后我们也是不可用的，超过使用期限的优惠券也是不可用的，商品价格没达到100的也是不可用的，这个是通用满减优惠券的分析；品类优惠券的话我们不仅要考虑通用优惠券的所有情况，还要考虑商品是不是这个品类的，是的话才可以使用，不是这个品类的话品类满减优惠券时不能使用的，专属商品满减券情况类似，最后我们还要分析，如果我们有三种优惠券都有，一件商品价格满100，商品同时是品类商品，专属商品的情况，商品是品类商品，但不是专属商品的情况，商品不是品类商品，但是是专属商品的情况，还要分析意见商品不是品类商品，不是专属商品的情况，那我只有两种优惠券的情况呢，我们也要一一分析到；无门槛券同理，之后，我们还要考虑满减券跟无门槛券组合的情况，还有就是我有多张可用的优惠券，是否可以进行切换，我有可用的优惠券，但我不想使用是否可以选择不使用优惠券，还有默认优惠券方式是否正确，这样一分析下来思路就清晰了，也可以很好的避免遗漏现象的发生。
最后我们还要进行一次弱网测试跟重复支付测试，订单生成之后要在后台查看是否有这个订单的数据，还要到数据库表里面去查看是否有这个订单的信息生成，尽量做到100%全覆盖测试。
待付款方面的话要考虑待付款的订单能保存多久，什么时候会失效，比如一般未支付订单15分钟未支付就会失效，订单就会被取消，还有我们自己主动取消订单要进行哪些操作之类的，如果取消订单或者是付款成功，我们还要看看后台的订单是否也同步取消或增加，还要查看数据库表的数据是否增加或者是删除。
然后待发货状态，待收货状态，已完成状态，售后/退款状态都是比较简单的，比如说查看订单详情，查看物流，复制订单编号，，确认收货，删除订单，再次购买都是比较简单的检测点，其中要注意的是每个状态下的退款申请跟评价以及每种购买情况退款后的返还情况，退款申请跟评价里面有输入框的地方要测试它的合法性跟空值，照片上传要测试照片的数量上限跟照片格式还有照片是否必须上传；然后就是退款后的返还情况分析，比如只用积分购买只返回积分，优惠券购买不返回优惠券，余额购买返还余额，组合购买之后的退款返还情况；最后要记得前后端的数据检查对比，以及数据库表的检查对比，避免前端
操作了，后端跟数据库没反应，造成重大bug。
参考项目二：xx精选（APP端）
项目背景：xx精选是一个商店一站式采购平台，以“更快更便宜”为终极目标，用户在平
台上下订单，下订单后平台会根据订单去经销商取货到仓库，然后进行配送，最后再进行资金结算，平台从中收取中间费，从而解决了中小商超的进货问题，也为批发商带来了更多的订单。
项目模块：
用户端：首页进货购物车我
商家端：商品管理订单管理评价中心设置中心
平台端：订单管理配货中心消息个人
我主要负责用户端。用户端主要有商品的搜索、购买以及订单这三个模块。
搜索主要是首页的搜索框，这里我首先考虑端是：1.搜索框的合法性和功能，搜索框的合法性结合等价类边界值的方法去覆盖，主要考虑：字符类型，长度，必填项测试，另外还需要考虑是否支持复制、粘贴、剪切等。功能结合业务场景去覆盖，主要考虑搜索结果的匹配机制，精确搜索或模糊搜索，是否可以搜索到商品/经销商，平台里面没有的商品/经销商是否可以搜索到，输入多个关键字的匹配机制是怎样的，点击搜索控键是否可以跳转到搜索商品结果页面。搜索的结果页面站在客户角度上
主要考虑页面展示情况，展示的数据是否与后台一致，后台下架，上架，修改了商品信息，前台的展示情况是否同步；另外，“今日优惠”“热销品类”推荐模块的显示机制是怎样的，是根据什么条件进行推荐的，如果商户没有设置商店类型等信息是否有默认推荐，点击商品是否会进行商品详情页的跳转等方面进行考虑。
另外就是搜索框后置端扫描二维码或商品条形码功能，主要考虑：扫描成功后是否成功跳转到该商品详情页，扫描失败是否有提示，有无网络时对扫描结果的影响，弱网状态下扫描的结果，失效的二维码/条形码是否可以扫描，扫描功能在未开启手机相机权限时的情况。3.语音搜索商品功能，主要考虑：验证语音识别内容的准确性，识别成功后能否跳转到商品详情页；语音内容不在系统语音词库中能否搜索成功，搜索失败的提示信息。
第二个就是商品的购买。这个的话首先考虑权限问题，已登录的用户进行购买，如果未登录，点击立即购买会跳转到登录界面，登录完成后会跳转到订单确认界面，商品购买可以从商品详情页面点击立即购买或从购物车里面选择加入购物车的商品进行结算进行购买，进入到订单确认界面，界面展示商品信息、支付金额以及支付方式等信息，支付方式可以选择支付或者支付宝支付，点击立即付款，跳转到支付界面，支付完成后生成订单信息，并跳转到订单界面。
测试主要考虑用户状态，登录用户可以进行结算，如果是未登录用户能否进行结算，未登录用户点击结算是否会进行页面重定向，重定向页面是否为登录界面，登录完成后是否能
进行页面跳转，跳转订单确认页信息是否与用户选择信息一致，前后关联页面信息是否一致，页面跳转是否正常，是否正确，是否能够正常进行购买，支付失败或支付成功是否生成订单信息，订单信息是否正确，支付成功经销商是否会收到订单信息，后台是否同步生成订单信息，商户、后台订单信息是否一致，如果从购物车进行结算，购物车无商品是否能进行结算，购物车商品被下架或无库存是否能够选择商品进行结算。
再一个就是订单。订单包含未支付订单、已支付订单、已取消订单等状态，未支付订单主要为用户取消支付、支付失败的订单，未支付订单信息包括订单金额、商品信息，具有时效性，未支付订单如果未在30分钟内进行支付，订单状态将自动更新为已取消订单，未支付订单用户可以进行取消操作，取消后将更新为已取消订单，另外，未支付订单可以进行支付操作，支付完成后会更新为已支付订单，已支付订单可以进行查看订单详情，详情包括支付时间、支付金额、支付方式以及对应的商品信息，已取消订单包括取消原因为用户取消或超时未支付，包括订单金额、商品信息，已取消订单可以进行再次下单处理。
测试时主要考虑订单状态之间的转换，未支付订单超时未支付是否会正常更新为已取消订单、未支付订单是否可以进行支付或用户取消操作，进行对应操作订单是否会进行状态更新，更新前后订单内信息是否一致，已支付订单展示信息是否与用户进行支付的金额、选择的商品一致，已取消订单信息展示是否正常，金额信息是否正确，是否能够再次进行下单操作，后台进行订单管理，删除、修改、增
加订单信息，是否会进行同步，前端订单状态改变，后台订单状态是否会进行同步更改，分别在APP端和web进行订单操作，订单状态是否会同步等。
参考项目三：XX好物（APP端）
项目背景：xx好物app，这是一款跨境购物软件，通过它不仅可以帮助用户购买到海外的美妆产品、护肤品、专柜产品，还有日用品、母婴用品、盲盒手办、食品零食等海量商品，可以很好的满足用户们的购物需求。
主要模块：
软件测试app客户端：注册，登录，夜市主页面，商品搜索，消息（在线客户服，售后消息），购物车，邀请有礼，我的
夜市主页面：滚动广告展示页，夜市公告，商品展示
我的->我的订单（细分-待付款，待发货，代收货，待评价，售后）、特价商品列表
后端：订单管理，会员管理，商品管理，促销管理
我主要负责：客户端所有模块的功能测试和接口测试，后端是我另外一个同事负责的。
电商是现在市面上比较火的产品之一，大家都不陌生，它主要的功能就是实现客户能成功购买商品，购买的基本流程如下：搜索商品-选择商品-加入购物车-结算-添加收货地址-提交订单-确认付款-待发货-待收货-待评价-结束
我们的接口测试是边开发边测试的，因为当时项目时间相对紧张，人力也有限，所以我们等后端开发开发好一个模块后，就做那个模块的接口测试。接口测试我们一般是根据接口文档来分析，提炼测试点的，主要会考虑请求参数是否必填，数据类型啊，长度啊，还有各种组合情况，枚举值呀，以及返回码和错误码去设计用例，用例设计好之后，我们会借用jmeter工具编写脚本，然后执行脚本，查看执行结果，然后拿执行的结果与接口文档里的结
果进行对比，主要看的是返回码和返回体中的核心数据，看我们的接口是不是正常。如果不正常，那我们就需要复测一遍，确定是bug的话，我们就会提bug给开发修复，修复完后再复测，直到问解决为止。
功能测试的话，首先是熟悉测试文档，然后是分析需求，提炼测试点，然后编写用例，用例编写好后会开一个用例评审会，当时我们产品和开发比较忙没参与评审，所以就改为组内成品评审了，评审的目的就是查缺补漏让用例覆盖更完全。用例完善后就可以执行用例了，当时执行期间发现了不少bug，分别都有提交给对应的开发了，等bug修复后，我们会做对应的回归测试，最后输出一份测试报告，再然后就是等待发版上线了。
像功能测试的话，我的测试思路是这样的：首先，输入框类的，我会根据测试文档例的限制条件，用等价类，边界值等设计方法去设计用例，也会考必填的情况。第二类，各种按钮键，在正常场景下点击后可以跳转到对应的页面或跳出相应的提示信息出来，然后在异常场景下点击的结果是怎么样的；第三类，也是最重要的，就是模块关联块。
举例一：购物页面的结算按钮
首先，我会考虑正常场景下（原则是用一条用例覆盖尽可能多的测试点），比如在库存充足，没有限购的情况下，点击结算按钮，结果是：页面跳转到订单详情页页面，且订单详情页上的商品信息正确；异常场景：第一，在库存充足，没有限购的情况下频繁点击结算按钮，预期结果：有效点击只有1次，跳转到订单详情页，且订单详情页上的商品信息正确，如果点击了10下，然后跳转10下的话，这种用户体验非常不好，如果我是客户的话，会很讨厌这个app；第二，在库存不足的情况下，点击结算按钮，比如，我们买的商品时5件，库存数量只有4件，那么预期结果：页面提示：商品库存只有4件；第三，如果是零库存呢，预期结果：页面提示：您购买的商品太热销，暂无库存；第四，如果不选择商品，点击立即下单，预计结果：结算按钮置灰，不可点击；第五：购物车中的某个商品下架了，选择后点击结算按钮，预期结果：当前页面跳出提示框信息：该商品已下架，请选购其他商品；第五：购物车里的商品加入购物车时，价格为199，因促销，后台将对应的商品价格下调至169，此时点击结算按钮，预期结果：商品价格刷新，价格变更为169，针对这个点我当时大概想到了这些。
举例二：优惠券
针对优惠券的话，我会从四个方向考虑：优惠券的发放，可使用，不可使用，退回。
1.优惠券的发放：首先我们要考虑，达到什么条件可以发放优惠券，比如，特定商品可以发放，同类商品满足多少金额可以发放，购买多少金额可以发放，节日促销可以发放，等等。
2.可使用优惠券：这个模块的测试点比较明确，比如：在有效期内的，购买金额达到要求的，在商品品类显示内的等等，这个主要看优惠券使用条件怎么限制。
3.不可使用：这个点其实就是可使用优惠券的异常场景：不在有效期内的，购买金额未达到要求的，不在商品品类内的，不可叠加使用，等等
4.退回：这个点的话，主要场景是考虑客户取消订单后，优惠券会不会退回。
除了场景之外，我还会从增删改查去考虑：
1.增：假设我已经有了一张优惠券，未使用的，后台派发了同样的优惠券，两者是否可以兼容存放在列表中；同名称的，只是优惠金额不同是否可以兼容，
2.删：支持删除、，不支持删除两种情况。
3.改：这个点可以不考虑，因为客户端没权限修改优惠券的内容。
4.查：这个点主要是考虑优惠券是从哪里查到？一是可以从我的页面里的我的优惠券查询，二是，提交订单页面的使用优惠券类表查询。优惠券这块的话，我大概是这么分析的

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。