【51CTO.com原創稿件】

前言

蘇寧發票中心系統自2014年以來先后接入增值稅電子普通發票、增值稅專用發票、增值稅普通發票、增值稅普通發票(卷式)等四種發票類型的開具。從業務上來看，接收線上易購、零售云、金融、貓寧、當當、天貓分銷、蘇寧有房、北京節能補貼、政企對公、香港票據、電商能力輸出、蘇寧卡、大潤發、卜蜂蓮花、蘇鮮生等訂單并提供開票服務。

[[261778]]

自動化解決方案

俗話說，頭大的問題造就大頭的智慧;那，我們先來說說為什么要做自動化?

蘇寧發票中心開票系統，如前言所述，負責蘇寧集團內外部所有業務開票服務，對接上下游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】