电子商务相关业务问题解决方案

1、电子商务相关业务问题分析引言目前电子商务网站频繁出现生产BUG，甚至某些典型BUG反复出现，不仅损害了保险公司电子商务的业务形象，而且对今后的业务拓展产生了不利的影响，此外，电子商务新业务上线周期长导致新业务在市场竞争中处于被动地位。针对以上问题开发项目组未能及时反思，并采取提高客户体验、避免客户误操作、缩短新业务上线周期的有效措施。以下对电子商务网站的典型生产BUG和新业务上线周期长的原因进行分析，力求发现问题根源并找到解决思路。一、 电子商务网站典型生产BUG1. BUG说明下表所示BUG在电子商务网站曾多次出现，属于电子商务网站的典型BUG。BUG描述开发定位发生时间项目风险因素客户在电

2、子商务网站投保时，在线支付成功，但保单没能在核心生成。客户多次点击【立即支付】按钮，导致系统异常，未能成功向核心发送保单数据2013/3/15需求、开发经验不足，考虑不周2013/4/22修改验证和回归测试不充分2013/4/272013/5/62. BUG产生的原因分析BUG产生的直接原因是客户在支付页面快速多次地点击【立即支付】按钮，导致线程冲突，系统运行出现异常。下图是BUG产生的时序图：客户重复点击【立即支付】按钮，分别由后台服务的两个线程进行处理，由于操作系统任务调度因素的存在，具有后台处理线程1&2重复向第三方支付平台发起支付请求的故障场景，在第三方支付平台对重复的支付请求

3、返回支付失败后，投保申请单状态被误更新为“支付失败”。保单生成线程查询投保申请单后，对支付失败的投保申请单不进行保单生成处理，因此产生了生产BUG。上述BUG的产生原因反映出电子商务网站在系统设计和测试两个方面都存在问题。从初始系统需求分析设计上讲，开发人员的经验、能力略显不足，导致系统未能提前采取措施规避客户误操作；从系统验证测试上讲，测试人员对系统健壮性的测试不够充分。在BUG修复时，开发人员没有从理论上进行彻底分析验证，修改问题过于草率；测试人员在进行回归测试时只是流于形式，导致BUG反复在线上出现；同时也表现出项目组人员技术能力和责任心不足。3. 规避措施针对于该BUG，可以提出以下规

4、避措施：首先，开发人员应该从前台页面控制和后台逻辑控制两方面对系统进行设计。尽可能的避免客户的误操作和防止恶意攻击。关于禁止页面重复提交，目前互联网应用中已存在很多成熟的解决方案。例如，客户点击按钮后，在页面上增加灰色的屏蔽层，从而避免页面请求被再次提交。其次，测试人员在编写测试用例时需要有专业的指定。测试用例应该遍历所有功能，并对系统的健壮性进行专门的测试。目前电子商务系统的开发类似于测试驱动的开发，测试在整个软件开发周期中占有重要的地位。只有专业的测试用例设计并采用自动化测试工具才能高质量高效率的完成系统上线所必须的测试任务。二、 新业务上线周期长的问题1. 新旧架构的区别旧架构下的系统结

5、构图，相似的渠道业务单独地建立系统，系统间没有交集，新业务需要全新的开发和测试。这主要是因为开发人员在系统架构设计时，没能事先将可能变化的差异部分进行抽象，导致相同的一个功能可能只因为5%的差异而不能被重用，并且为了保障现有系统的稳定性，又不能对现有系统进行大面积的改造，导致只能重新新建一个系统，浪费了大量的人工和时间。新架构下，新架构从业务渠道、数据接入、业务服务等方面对系统进行了分层和抽象。可以看出，新架构具备了一定的信息隐藏和弹性扩展能力。对业务差异抽象后，新业务投入的工作量有所减少，主要是因为开发人员只需要为新业务单独开发差异部分的代码，测试也只需要关注新开发的功能，对复用的功能只需在

6、新业务中进行集成测试，现有业务完全不用测试。但是系统优化后，新业务依然不能达到预期的上线周期要求，并且投入的工作量仍然偏高，因此新架构目前仍然不能满足电子商务发展的需求。2. 新架构的不足就目前电子商务系统架构而言，只是将原有系统功能进行了分类整合，局部的提取抽象接口，整个系统架构的控制平面和数据平面在各个模块中没有确定的分割界限，才造成了整个系统各层间的隔离不够彻底，新增业务不可避免的需要对原有模块甚至接口进行修改，影响了系统的快速迭代能力和可维护性。以保费计算模块为例，如图3所示，目前只是按照现有的一个典型产品定义了一个计算模板，所有业务需要适配现有的计算模板方可完成保费计算，新增内容既需

7、要改变模块接口又需要改变模块内部实现，属于软件设计模式中“推”式模型，即一个模块既包含控制平面内容又包含数据平面内容，显然不能适应于电子商务所期望的快速迭代模式。图 1“推”式模型如果按图4所示，将控制平面与数据平面完全拆分隔离，以“拉”式模型设计保费计算模块，模块中的每个基本计算元素自主从数据平面拉取完成自身运算所需的业务数据，由产品定制实现基本计算元素的组合；那么新增业务只需要根据新产品定制来重新定义基本运算元素的组合，就可以实现功能，对模块接口和原有功能做到最小改变或不改变，最大程度的实现对现有元素的复用，同时保证了系统的快速迭代和可维护性。 图 2“拉”式模型从系统层次结构和保费计算模块可以推断，目前系统架构几乎完全按照“推”式模型设计，层与层、模块与模块之间既存在数据耦合又存在控制逻辑耦合，两个平面的交织组合造成系统功能扩展时更改范围广，更改影响不可控，进而导致新业务上线周期长，系统稳定性需经过多次震荡方可收敛。三、 总结通过对典型BUG的分析，可以认识到目前的系统仅实现了功能性需求，对系统的非功能需求实现粗陋，没有吸取业界成熟解决方案的经验和优