前言

2014年以来，苏宁发票中心系统陆续接入开具电子普通增值税发票、增值税专用发票、增值税普通发票、增值税普通发票(卷式)四类发票。从业务来看，接收线上电商、零售云、金融、毛宁、当当、天猫配送、苏宁有房、京节能补贴、政企合作、港单、电商产能输出、苏宁卡、大润发、卜蜂莲花、苏鲜生等订单并提供发票服务。

自动化解决方案

俗话说，大问题让大头聪明；那么，我们先来说说为什么要做自动化。

前言中提到，苏宁发票中心的进销存系统负责苏宁集团所有内外部业务进销存服务，连接N个上下游业务和系统。在各相关系统中开发新的功能时，进销存中心是不变的，但往往需要配合联调提供进销存服务，而这种各种数据与联调的不定期配合，消耗了团队极大的时间和精力。

比如某个项目，票增是配合测试的，因为增值税专用票和普通票的开具需要先定位数据是否已收到，然后检查数据是否满足开票条件，再执行预定的任务进行开、锁、开票、邮件导入。

对于上面这么多操作步骤，我们计算了一下，人工开一张票平均需要6分钟，在3天左右的集中联试期内需要开具100多张发票，消耗100(张)*6(分钟/张)/60(分钟)/8(人-天)=1.25人-天，也就是说如果全自动化的话，是不需要的。为了提高联合测试的效率，释放团队资源，提高测试集中度，迫切需要解决这个问题。

我们设计了一个更好的解决方案。这是什么？有什么优势？

有人会说，MOCK，问题的解决方案n年前就有了！然而，模拟数据的“老少通吃”和“妄下结论”确实难以满足复杂的业务场景和真实的数据处理。总之，有风险，容易被扭曲。

以发票中心为例。上游系统下载真实的测试数据。我们需要判断和处理要求开具发票的数据的税率、会员资格、付款和收款状态。如前所述，所有复杂的流程都需要按照实际的计费环节来实现，这也是集成测试的基本准则要求之一，不宜采用模仿的方式。同时，发票中心还需要根据不同的源系统和票种，对数据进行合并或其他方式的处理。只有一个合并功能是很难用MOCK技术实现的。

为了解决这个问题，通过相关人员的配合，秉承最大程度用机器代替人工干预的理念，利用团队现有的自动化技术，最终有了一个相对较好的、独立的解决方案。

方案的简要说明

前台:为方便上游计费需求人员使用，采用网页进行数据输入，提供计费界面和计费结果查询界面；

背景:使用以简洁和胶水语言著称的Python为前端调用提供计费和计费结果查询的接口；对接收到的数据进行数据分析、数据校验、MySQL数据查询、逻辑运算，然后对可开票数据进行预定任务执行、IE开票、截图保存、日志写入保存等操作。，从而实现完整的开票流程。

该解决方案的优势:

1.通用性强，可用于目前任何需要开票的上游项目；

2.票种和环境可以随意切换；

3.精准的问题定位反馈；

4.第一用户的操作更简单直接，执行效率高；

5.无需切换系统查看执行结果，查询更直观；

6.测试人员基本是0占用，人力资源基本是0消耗。

Web前端，vue.js结合元素组件，打造极简界面

为开票人员提供查询接口，可以通过关键信息查询开票结果图片和开票明细日志。

开票结果查询明细:

将复杂的表单输入转化为简单的三个输入条件，流程执行日志、问题提示、错误信息、红色错误报告等。都被收藏了。

通过简单的权限限制，可以为我们的人员(计费人员是看不见的)提供一个数据流接口，方便统计和问题分析。

Web、Python和Command之间的化学反应，简单的权限控制设计

在局域网中，开关机或断网都有可能导致IP的改变，所以我们选择加域的计算机全名(其他唯一标识符也可以，为了确定具体人员，我们选择加域的计算机全名)作为权限控制的切入点。

通过WebAxios将接口数据传递给Python的flask，flask接收数据的同时，获取其请求ip，通过ip获取计算机全称(Windows系统中的nbtstat命令，linux中的nmblookup命令，Python也可以通过socket.getfqdn(ip)等获取配置。)，从而判断请求者可以看到的页面(如果未配置则为默认页面)；通过前端路由跳转，避免了跳过权限检查直接访问地址的情况。

Python的逻辑判断和自动运行，像机器一样运行

通过前端输入的三个条件，Python后台在接收到接口数据后会做出相关的业务判断，包括但不限于数据检查、数据校验、计费池检查、通过requests接口自动执行定时任务和获取执行结果等一系列的自动判断。如果不能开发票，它会返回到前端出错。如果可以开票，它会将获取的数据传输到selenium运营的IE浏览器开票接口进行自动开票。

为什么要用IE？

计费业务系统本身的设计是通过ActiveX调用本地航信客户端进行计费。所以，ActiveX，你懂的。

既然需要转移本地客户端，那问题就不~

是的，问题很多。

首先我们排除了调用抽屉本地客户端的方案(安装客户端，设置IE，调用本地程序等。，太复杂)。

其次，根据目前的业务量，我们选择使用一个Windows终端作为承载，在这里完成所有的代码部署和计费操作。

再次，开票后，由于开票软件本身的安全限制，直接保存账单会丢失一些信息，所以我们选择使用pywinauto最大化账单显示客户端，并通过Python进行全屏截图。

第四，截图和日志一起存储在这台机器上，前端可以通过界面直接请求查看详情。

第五，扩展增长计划:如果使用linux部署web和python的业务逻辑的代码，通过socket实现linux和Windows的指令和数据的传输，Windows performance machine充当IE开票和账单截图的负载。这样，多台性能机也可以承载单独的开票工作，从而实现并发开票请求。

这么乱，不总结了

总的来说，计费环节自动化的实现和问题解决过程如下:

摘要

整个过程到此结束，基本解决了我们联测联开发票的问题。工具上线以来，测试人员不再需要中断正在进行的新项目来配合开票，提高了项目成员自身的测试集中度，释放项目合作人力和时间约1.25人/项目(单个项目联合测试约3人/天)，提高开票效率近70%。我们提取了发票数据执行日志的详细信息，以最直观地展示复杂发票流程的效率:

随着时间的推移，项目的迭代，工具的完善，收益会逐渐积累，真正的随开发票减负开始凸显。这一切的实现对Python技术在测试自动化中的应用起到了关键作用。

下一版本规划

虽然我们这次实现了全链路自动开票能力，但由于从本次自助开票开始(2019年2月12日)到全面实施上线使用(2019年3月11日)仅用了一个月时间，所以很多工作项还没有开始，我们将在下一版本中加强几个功能:1。计费业务能力的分析与优化；2.一是直接用户体验提升，使用方便高效；3.多终端多线程计费支持能力建设；4.开票问题的自动处理机制等。

期待我们下一个更好的版本！