10.1微信红包诞生记—项目背景了解

10.1.1头脑风暴—红包想法的由来

      想法源自于一次的头脑风暴中，把公司农历新年后上班的第一天红包历时的习俗做成一个应用。

10.1.2红包创意的发展

红包创意的发展

10.1.4从想法到产品需求

STEP1：用户需求分析

①用户为什么要发红包？

②用户为什么会抢红包？

③用户是否会晒红包？

STEP2：用户入口设计

①用户会在什么场景下发红包？

②其他什么位置适合包含红包入口？

③查询红包的入口？

STEP3:界面样式设计

STEP4:业务流程

STEP5:交互设计

STEP6:产品需求文档

10.2微信红包需求分析—用户需求

1、说明

       将微信红包分为普通红包和拼手气红包。

       普通红包是指金额每份金额固定的红包包括群普通红包和个人普通红包，个人普通红包也就是红包个数为1的群普通红包。

2、用户需求分析

（1）用户为什么要发红包？

①体验快乐。

②成为焦点人物。

③获得关注卖广告。

④纯粹是一种祝福。

⑤游戏。

（2）用户为什么要抢红包？

①好玩刺激。

②抢钱—人类原始的欲望。

③炫耀。

④减少损失。

（3）为什么要晒红包？

①炫富心理—我发出的红包统计页面。

②攀比心理—红包结果页面。

3、用户入口设计

群红包默认为拼手气红包而不是定额红包。

拼手气群红包的优势：

①金额随机，时大时小的金额能给用户惊喜。

②可以看到其他用户抢了多少，引起攀比心理。

③产生很多新奇玩法，比如手气最佳。

4、界面设计

（1）发红包界面：

       在单人聊天窗口进入的普通（定向）红包的页面只需要输入红包金额和祝福语，点击【塞钱进红包】，如果已经绑定银行卡，则调起对话框浮层【输入密码】；如果未绑定银行卡则跳转到零钱支付页面，点击按钮【使用零钱支付】即可，无需输入密码，在这个过程中，如果零钱不足，则会跳转到输入银行卡号的页面，点击【下一步】之后需要结社输入姓名、银行预留手机号和短信验证码，填写完成后即可用银行卡支付。

       在群聊天进入红包后，当点击“改完普通红包”，从群手气红包切换到普通红包的过程中，已经输入的内容不会丢失，红包个数不变，此时的单个金额EditView中的值会有总金额/红包个数得出并自动填充；当点击“改为群手气红包”，从普通红包切换到群手气红包的过程中，已经输入的内容不会丢失，红包个数不变，此时的总金额EditView中的值会由单个金额*红包个数计算出并自动填充，不用用户重新输入。

（2）红包【抢】页面

         聊天窗口会显示出红包样式的聊天信息，点击红包后回出现拆的页面。

（3） 红包【拆】页面

       点击按钮【拆】之后，跳转到【红包结果页面】。

（4）红包结果页面

       红包结果页面会显示抢到红包的人的列表，其中金额最大的为手气红包。当有两个或者两个以上金额相同的时候，以时间最早的一个为最佳手气。叶念还会显示发红包的人的昵称、你自己领到的金额（如果没领到就不会显示），零钱入口和转发该红包的入口、我的红包记录入口。

①当领到红包的时候，会显示按钮“已存入零钱，可用于发红包”、“已存入零钱，可用于转账”、“已存入零钱，可用于体现”的其中一个，顺序或随机出现；并显示自己所获得的红包金额。

②当自己发的红包还没被领完，会显示“继续发送此红包”。

③领到别人发的红包时，会显示“查看我的红包记录”。

④对于群手气红包被领完时，如果红包时自己发的会显示字样“n个红包共n元，n秒被抢光”；如果是被人发的红包则会显示字样“n个红包，n秒被抢光”;对于（群）普通红包被领完时，会显示字样“n个红包共n元”。

⑤对于红包（个数大于1）没被领完，自己的红包会显示字样“已领取x/y,共x/y元”；别人发的红包字样“领取x/y个”。

⑥对于红包（个数等于1）没领完时，会显示字样“红包金额n元，等待对方领取”。

⑦对于群手气红包和自己发的普通红包都会显示抢到红包的人的列表。

⑧已经领完的群手气红包才会显示“最佳手气”的标识。

10.3红包项目管理流程解析—了解项目团队

10.3.1从需求到产品

10.3.2项目经理“打不死的小强”上线

      最初的产品分析完成，需求产生后，首先要确定的就是项目经理人选及项目立项。

    本次的项目经理小强。

10.3.3矩阵化管理模式

红包项目：

项目经理小强：

①启动阶段：设定项目目标，让项目团队有事可做。

②规划阶段：制定工作路线，让项目团队“有法可依”。

③执行阶段：“按图索骥”，让项目团队“有法必依”。

④监控阶段：测量项目绩效，让项目团队“违法必究”，并且尽量做到“防患于未然”。

⑤收尾阶段：了解项目（阶段）“恩怨”，让一切圆满。

研发负责人小宇：

①沟通：沟通需求，评审可行性，制定开发标准；处理团队负面情绪，组织个评审会议。

②开发：指导和编写开发文档，参与编写模板代码，代码审查评审，保证代码质量。

③团队建设：培养质量意识，易用性认识，研发人员互备等。

测试负责人小花：

①负责软件产品/项目测试工作的组织。

②负责软件产品/项目测试工作的管理。

③承担重要项目的具体测试任务。

④组织测试组配合公司其他部门的工作。

⑤负责测试组的管理工作。

10.4高效进行微信需求分析和需求评审—测试工作第一步

10.4.1测试需求分析

What?测试也需要做需求分析？

       测试需求分析是测试工作的第一步，经过需求分析，对原始需求列表中列出的每一个需求点，找到我们需要测试的测试要点；针对所确定的测试要点，分析测试执行时对应的测试方案。

测试需求分析是测试工作的第一步：

（1）了解红包需求实现的背景。

（2）分析测试红包需求合理性。

（3）确定测试范围和优先级。

（4）查缺补漏。

需求的目的：

①对内：对标的是阿里的支付宝红包。希望客户引流，增加微信使用的活跃度，增加微信新用户，增加微信支付签约客户。

②对外：希望用户能够吧把线下红包模式转换到微信红包上；增加过年的氛围；使用便捷。

用户的使用场景：

需求合理化：

①是否满足客户/用户的需求：满足

②在系统原有基础上，尽量减少改动成本：红包—微信支付  红包订单—订单系统  性能压力。

10.5实战拆分微信红包并评估测试点—用XMind将微信红包拆分5个模块

黄色表示后续需要跟开发者对接交流之后再进行设计的操作；

红色表示的是优先级比较高的操作。

10.7浅聊测试依赖文档—进入开发阶段需要项目文档

10.7.1项目文档—测试用例之间的故事

①需求分析—测试设计阶段核心依赖。

②业务流程图，页面流程图—测试模块划分参照物。

③原型设计—具象化业务流程及预期结果。

④设计文档—辅助进行算法、逻辑、队列等技术方向上的测试设计。

eg:微信红包

生成订单—落数据库

待支付—支付成功

订单流转

微信红包与订单处理：

        订单在完成支付前可以先落在缓存中，完成支付后再持久化。（订单生成时未存入数据库，待支付成功才落库）。

支付过程

微信红包—微服务器

红包数据流：

包红包过程：预下单待支付（数据存储缓存）—支付状态查询—支付成功下单（存储数据库）。   消息流：微信—微信红包系统—微信支付—微信红包

发红包过程：增加数据库发放记录流水—下发微信消息。          消息流：微信红包—微信

抢红包：先计算红包金额（算法）—写领取红包流水表—更新发红包订单—转零钱。

信息流：微信—微信红包—微信支付

红包系统：

hb_order  红包订单表

hb_record  红包记录流水表

memcache  缓存

预下单—缓存—支付成功—hb_order 产生一条记录  —发放到群/个人    hb_recode 增加一条发放记录 ，关联hb_order中order_id（hbdirection=0）

拆红包  hb_recode 关联红包id hbdirection=1  -更新  hb_order剩余金额&剩余个数

推消息：

实时转异步

MQ队列的模式   tag event_code定义  发送方

消费方   tag event_code 执行后续操作（处理失败，将消息退回队列，下次再处理）

 hb_recode异步执行  测试点： listener 接收消息   —处理    -mq

红包领取流水   --微信支付   要进行对账处理

检验数据：红包流水的倒数二三为来分库分表   hb_order_000    001    002    099

红包生成失败会重试

红包随机金额设计：每个红包最大值min（（红包剩余金额/红包剩余个数）*2  , 红包剩余金额 -0.01*红包剩余个数）        最小值   0.01

隐含逻辑   最后一个红包   获得全部剩余余额

       红包的业务包含包、发、抢、拆、查询发送红包和收红包数量，其中最关键的步骤是发红包和抢红包。

       微信红包时微信支付的商户，微信红包这个商户出售的是钱。发红包用户在微信平台使用微信支付购买一份钱，微信红包将钱发放到相应的微信群。群里的用户抢红包得到微信零钱。这个过程中，微信红包和微信支付之间的关系是商家和第三方支付平台的关系。

        微信红包和微信支付之间的交互，与普通商家与微信支付的交互一样，需要经过六个步骤。用户发红包时，进入微信红包下一笔订单，系统记录发红包用户、发红包金额、红包数量和要发送到的微信群。然后微信红包系统请求微信支付服务器进行下单，用户使用微信支付进行支付。

       支付成功后，微信支付后台系统通知微信红包后台系统支付成功结果，微信红包后台系统收到通知后推送微信红包消息到微信群。微信群里用户可抢红包。这就是微信红包和微信支付的关系以及交互过程。

微信红包的系统流程：

微信红包系统角度上的流程，业务主流程是包、发、抢、拆四个操作，每个操作包括几个关键步骤。

包红包，系统为每个红包分配一个唯一的ID，即红包发送订单号，然后将发红包用户、红包个数、红包数额写入存储，最后去微信支付下单。

发红包，用户使用微信支付完成付款，微信红包后台系统收到微信支付系统的支付成功通知。红包系统将红包发送订单状态更新为用户已支付，并写入用户发红包记录（用户发红包记录，就是微信钱包中，查看到的用户每一年总共发出及收到的红包记录）。最后微信红包后台系统发送红包消息到微信群。

抢红包，指微信群里的用户收到微信红包消息后，点开红包消息。这个过程，微信红包后台系统会检查红包是否已被抢完，是否已过期，是否已经抢过。

拆红包是最复杂的业务操作。包括查询这个红包发送订单，判断用户是否可拆，然后计算本次可拆到的红包金额。然后写入一条抢红包记录。如果把拆红包过程，类比为一个秒杀活动的过程，相当于扣库存与写入秒杀记录的过程。更新库存对应于更新发红包订单，写入秒杀记录对应于写入这个红包的领取红包记录。另外，还要写入用户整体的红包领取记录。最后请求微信支付系统给拆到红包用户转入零钱，成功后更新抢红包的订单状态为已转账成功。

10.9拆分红包功能模式—“切蛋糕”的艺术

10.9.1测试模块划分

从红包需求文档出发：

①功能流程法拆解红包模块。

②层次划分法划分红包功能点。

③类型划分法拆分子功能。

10.9.2测试用例设计—抉择篇

10.9.2.1选择测试方法的办法

①输入分类选等价。

②给定范围加边界。

③条件孤立想判定。

④无线穷举取正交。

⑤业务复杂场景法。

⑥测试充分全覆盖。

10.9.2.2实际设计的思路

       任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。

       必要时用等价类划分方法补充一些测试用例。

       如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用判定表法。

       如果程序业务复杂度比较高，则适当使用场景法补充一部分测试用例。

eg:测试用例综合设计—微信零钱充值

①边界值考虑充值金额：0元，1元，负数，非金额参数，多位小数（小数后3位），银行卡限额。

②等价类考虑多个不同的银行和渠道。

③由于整体功能尚不包含输入条件的组合情况，所以无需加上因果图。

④充值成功后，余额将在零钱展示同时包含充值记录：流程-微信唤起充值-充值金额-我的零钱-零钱明细。

10.10设计测试计划—知己知彼

测试方案：

一、需求说明

1.1需求汇总

1.2需求变更

1.3功能模块

二、总体计划安排和负责人

2.1测试计划进度表

三、测试方案

3.1测试重点

包红包流程：金额、支付渠道

发红包：微信消息、数据库、消息推送

拆红包：红包金额算法、红包结果、零钱到账逻辑、数据库、消息推送

查红包：零钱余额、对账

退红包：余额返还、未领返还

3.2联测方案

微信-消息推送、红包入口

微信支付-支付、塞钱进红包、红包零钱到账

3.3测试策略方法

场景法、边界值、等价类、因果图

3.4测试工具平台

Jmeter   、黑盒测试

四、环境搭建部署及数据准备

4.1环境拓扑

环境测试   1台云服务器    1数据库     1套队列

4.2应用部署

Jenkins持续集成+自动部署（docker部署）

4.3数据准备

账户数据、微信支付签约数据

五、测试执行计划

5.1测试用例及执行结果（可附附件）

5.2用例评审结果

六、测试工单

6.1冒烟测试结果

6.2功能测试结果

6.3自动化测试用例及覆盖率

是否进行自动化测试？如果进行标明自动化测试用例

6.4性能测试结果

是否进行了性能测试？如果有注明测试场景及结果

6.5安全测试结果

是否进行了安全测试？如果有注明安全处测试模块、策略及测试结果

七、测试限制及无法测试功能列表

生产上队列信息可能与测试环境不同

大数据量并发情况下验证

部分快捷银行支付没有测试环境，需要生产验证

八、测试风险点、待确认列表

生产队列消费配置问题

并发抢红包 （超中）

银行支付渠道