【51CTO.com原创稿件】
前言
苏宁发票中心系统自2014年以来先后接入增值税电子普通发票、增值税专用发票、增值税普通发票、增值税普通发票(卷式)等四种发票类型的开具。从业务上来看，接收线上易购、零售云、金融、猫宁、当当、天猫分销、苏宁有房、北京节能补贴、政企对公、香港票据、电商能力输出、苏宁卡、大润发、卜蜂莲花、苏鲜生等订单并提供开票服务。
自动化解决方案
俗话说，头大的问题造就大头的智慧;那，我们先来说说为什么要做自动化?
苏宁发票中心开票系统，如前言所述，负责苏宁集团内外部所有业务开票服务，对接上下游N个业务和系统，在各相关系统有新的功能开发时，涉及发票中心无改动，但常需要配合联测，提供开票服务，而这不定时的各种各样的数据配合联测，耗费了团队巨大的时间和精力。
举个例子，某项目增票配合测试，因为增值税专、普票开具需要先定位数据是否接收到，然后检查数据是否符合开票条件，然后执行定时任务转待开，锁定，开票，邮寄导入。
对于如上这么多的操作步骤，我们做过测算，人工平均开一张票需6min，在项目3天左右的集中联测周期内共需配合开具100张以上发票，消耗测试资源100(张)*6(min/张)/60(min)/8(人天)=1.25人天，也就是说，如果实现完全自动化，无需测试人员介入，单张发票开具在2min内完成，联测周期内***可节省42%的测试总人天。要提升配合联测效率，释放团队资源，提高测试专注度，这个问题的解决，则变得刻不容缓。
我们设计了一个较优的解决方案是什么?有哪些优点?
有人会说，MOCK啊，N年前就有的问题解决方案!可是，MOCK数据的“老少通吃”，“呆头呆脑”的“妄下结论”，实在难以满足复杂的业务场景和真实数据的处理，用一句概括就是存在风险且容易失真。
拿发票中心来讲，上游系统下传真实的测试数据，我们需要对请求开票的数据的税率、会员、支付、收货状态做判断并处理。如上所述复杂过程都需要按实际开票链路实现，这也是集成测试基本准则要求之一，采用MOCK方式不可取。同时，发票中心针对来源系统不同、票种不同也需要合并或者其他方式的处理数据，仅就一个合并功能，MOCK技术难以实现。
为解决此问题，经过相关人员的通力合作，秉承***程度用机器替代人工干预的思路，利用团队内现有的自动化技术，总算是有了一个相对不错且相对单独的解决方案。
方案简述
前台：为方便上游开票需求人员的使用，使用Web页面进行数据输入，提供开票界面和开票结果查询界面;
后台：使用以”简洁”和“胶水语言”著称的Python实现,提供开票和开票结果查询接口,供前端调用;并将接收到的数据进行数据分析、数据校验、MySQL数据查询、逻辑计算,进而将可开票数据进行定时任务执行、调用IE开票、屏幕截图保存、日志写入保存等操作,实现完整的开票流程。
此解决方案优点：
1、普适性高，目前任何上游需开票项目均可使用;
2、票种和环境随意切换;
3、问题定位反馈精准;
4、***用户操作更简单直接，执行效率高;
5、执行结果无需切换系统查看，查询更直观;
6、测试人员基本0占用，人力资源基本0消耗。
Web前端，vue.js结合element组件，打造极简界面
为开票人员提供查询界面，可通过关键信息查询开票结果图片，开票详细日志。
开票结果查询详情：
复杂的表单输入，转化为简单的三个输入条件，并且将过程执行日志，问题提示，错误信息，红色报错等，全数收入。
通过简单的权限限制，为我方人员提供数据流水界面(开票人员不可见)，方便统计与问题分析。
Web，Python与Command的化学反应，设计简单的权限控制
局域网内，开关机，断联网均可能导致IP的变更，故我们选择加域的计算机全名(其他唯一标识也可，为确定具体人员，故我们选择加域的计算机全名)，作为权限控制切入点。
Web通过axios将接口数据传给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性能机作为IE开票和票据截图的承载，以此来说，多台性能机亦可承载分别的开票工作，故而实现并发的开票请求。
那么乱，还不归纳一下
整体来说，开票链路自动化实现和问题解决过程如下：
- 在Windows性能机上部署Python代码和Web代码，设置ip和端口，启动flask监听;
- 开票人员即可通过相应的http地址访问开票页面，输入数据，开始开票;
- 接口接收到开票数据，通过Python后台的逻辑处理，有问题则返回前端，无问题则自动调用IE开票，IE调用本地航信开票;
- 开票结束自动截图保存在本地，过程日志同样记录在本地，开票流水日志记录在MySQL;
- 之后返回开票结果至前端，实际开票人员通过相关信息即可查询票据图片，开票日志，管理人员即可通过开票流水日志进行相关的数据统计和管理工作。
总结
整个流程到此结束了，基本解决了我们联测配合开票的问题。工具上线以来，测试人员不再需要中断正在进行的新项目去配合开票，提升了项目成员本身测试专注度，释放了项目配合人力和时间约1.25人天/项目(单项目联测人天3左右) ，提升开票效率近70%，我们抽取了一条开票数据的执行log详情，最直观来展示复杂开票过程的效率：
随着时间的推移、项目的迭代和工具的完善，收益会也在逐步累加，配合开票真正的减负也开始突显。而这一切的实现Python技术在测试自动化中的应用，起到了关键的作用。
下一版本规划
本次虽然我们已经实现了完整链路自动开票的能力，但由于从开始着手做这个自助开票(2019.2.12)到完整实现上线使用(2019.3.11)仅用1月，有很多工作项还未开展，我们将在下一个版本加强几方面功能：1、开票服务能力分析和优化;2、***直接用户体验提升，便捷高效的使用;3、多端多线程开票支持能力建设;4、开票问题自动处理机制等等。
期待我们下一个更优的版本吧!
作者简介
仲崇瑞，苏宁科技集团员工平台研发中心高级测试经理，有多年的业务及产品设计经验和测试管理经验，负责集团财务核算、财务共享、税务会计及智能应用等产品的测试及管理工作，涉及功能、性能、自动化、安全等测试领域，带领团队多次出色完成财务系统变革和切换的测试工作，致力于构建苏宁财务类自动化测试产品解决方案，打造高效便捷的测试应用产品。
金业帅，苏宁科技集团员工平台研发中心测试开发工程师，负责测试工具产品的技术研究、实施，主要对接集团财务、共享、税务等系统的自动化实现，参与苏宁发票中心，财务中台等系统的自动化测试开发工作。精通Python应用接口\后台\客户端开发，掌握Python与Java应用、MySQL/hive/ES等数据库调用技术及应用调优;在自动化测试框架实施过程中，有比较深入的分析设计能力和搭建经验。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
