舉個例子，某項目增票配合測試，因爲增值稅專、普票開具需要先定位數據是否接收到，然後檢查數據是否符合開票條件，然後執行定時任務轉待開，鎖定，開票，郵寄導入。

對於如上這麼多的操作步驟，我們做過測算，人工平均開一張票需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開票和票據截圖的承載，以此來說，多臺性能機亦可承載分別的開票工作，故而實現併發的開票請求。

那麼亂，還不歸納一下

整體來說，開票鏈路自動化實現和問題解決過程如下：

總結

整個流程到此結束了，基本解決了我們聯測配合開票的問題。工具上線以來，測試人員不再需要中斷正在進行的新項目去配合開票，提升了項目成員本身測試專注度，釋放了項目配合人力和時間約1.25人天/項目(單項目聯測人天3左右) ，提升開票效率近70%，我們抽取了一條開票數據的執行log詳情，最直觀來展示覆雜開票過程的效率：

隨着時間的推移、項目的迭代和工具的完善，收益會也在逐步累加，配合開票真正的減負也開始突顯。而這一切的實現Python技術在測試自動化中的應用，起到了關鍵的作用。

下一版本規劃

本次雖然我們已經實現了完整鏈路自動開票的能力，但由於從開始着手做這個自助開票(2019.2.12)到完整實現上線使用(2019.3.11)僅用1月，有很多工作項還未開展，我們將在下一個版本加強幾方面功能：1、開票服務能力分析和優化;2、第一直接用戶體驗提升，便捷高效的使用;3、多端多線程開票支持能力建設;4、開票問題自動處理機制等等。

期待我們下一個更優的版本吧!

聲明：該文觀點僅代表作者本人，搜狐號系信息發佈平臺，搜狐僅提供信息存儲空間服務。