基于lua的接口自動化測試框架設計摘要本畢業(yè)設計主要設計一個接口自動化測試框架。然后實現(xiàn)一個接口自動化測試框架。由于接口測試會由部分單元測試主城，該測試框架從單元測試出發(fā)，單元測試部分使用的是Luaunit框架。該接口自動化測試工具的工作過程主要分為以下3個階段。1.測試用例自動執(zhí)行2.結果驗證3.報告生成其中測試用例執(zhí)行部分，由于測試的是接口程序需要實現(xiàn)http請求的模擬。采用lua官方提供的luasocket庫實現(xiàn)lua的網(wǎng)絡編程，為了驗證接口應答數(shù)據(jù)的正確性，需要對xml格式數(shù)據(jù)進行解析。xml解析采用的是lua-simple-xml-parser庫。為了能在本地模擬測試接口環(huán)境還用到了mockserver技術，使用flask框架實現(xiàn)了簡單的mock服務。結果驗證部分使用的大多是Luaunit框架自身自帶的驗證器，報告生成部分新增了html格式的測試報告。該接口自動化測試框架實現(xiàn)了測試代碼復用，分離了測試數(shù)據(jù)和測試代碼，優(yōu)化了測試結果展示，有利于提高測試效率。關鍵詞：自動化測試；接口測試；lua；目錄TOC\o"1-2"\h\z\u77181引言 1198452接口測試技術分析 2317652.1接口測試 2119122.2接口測試自動化 4164402.3Lua腳本語言簡介 796613測試需求與總體框架設計 993163.1測試需求 9240583.2Lua腳本 1017983.3接口測試框架 11264044接口自動化測試框架實現(xiàn) 12243104.1TestCase 12289754.2Assert 12181484.3Client 13297784.4Pasrsexml 1495554.5Output 14224334.6HtmlReport 14238634.7數(shù)據(jù)分離 14290944.8mockserver 1552965運行效果與分析 17232315.1測試環(huán)境 17190695.2使用效果 1718485.3效果分析 18307406總結與展望 1939756.1總結 19116616.2展望 1915801參考文獻 231622附錄 24

1引言軟件測試是軟件可靠性和質(zhì)量保證的一個關鍵方面[1],目前國內(nèi)，因為軟件測試較晚的起步，與軟件開發(fā)相比較一直處于弱勢地位。同時，軟件行業(yè)的飛速發(fā)展，其令人難以想象的更新頻率，使得軟件測試也要跟上這種快速更迭變的十分困難。每當新版本軟件發(fā)布，要測試新功能和修改的功能是否和需求保持一致，又要執(zhí)行原有的測試用例保證來原有功能沒有被新添加的功能所影響，這就導致了測試用例重復執(zhí)行的現(xiàn)象。所以引入軟件自動化測試是必然的發(fā)展趨勢。[2]那么和一般的軟件項目一樣，要實現(xiàn)自動化測試需求，就不可避免的要搭建自動化測試框架來幫助實施自動化測試。自動化測試的過程通常包含三個要點：測試用例的輸入、測試結果的輸出、測試結果與預期結果的比較。測試用例的輸入包含測試數(shù)據(jù)與測試步驟的定義這兩個內(nèi)容。二者既可以一起寫在腳本程序中，也可以分離數(shù)據(jù)讓測試數(shù)據(jù)和測試代碼相獨立。執(zhí)行測試時，測試腳本通過讀取配置文件的方式獲取測試數(shù)據(jù)。作為測試腳本主體的測試步驟與被測軟件的行為息息相關。通常情況下，軟件的輸入存在隨意性，這不但會使得軟件行為的確定變得十分困難，而且在一定程度上讓測試腳本的編寫變得更加棘手。不僅如此軟件自己存在的漏洞和系統(tǒng)反應存在的時間偏差都大概率會引起測試腳本的執(zhí)行出現(xiàn)錯誤。比如腳本通常會設置一些操作延遲等待系統(tǒng)的執(zhí)行完成，但是一些系統(tǒng)操作的響應時間并不固定，如果在編寫腳本之時沒有考慮對應的容錯處理，就極容易導致腳本層面的錯誤。一般想要讓測試腳本的異常處理方法可以完美地囊括所有可以出現(xiàn)的問題是不現(xiàn)實的，這就加深了腳本的運行的不確定性。為了盡可能地減少這個不確定性對執(zhí)行結果帶來的影響，腳本程序自身就要有比較完備的異常處理方案。在自動化測試項目里，測試的結果和預期結果的比較與驗證部分比之人工測試，顯得十分繁瑣。幾百行代碼才完成一個規(guī)則繁復的校驗點是十分普遍的現(xiàn)象。當然，寫了如此多的測試代碼必然存在著功能相通的部分，此時用代碼執(zhí)行測試的好處就體現(xiàn)出來了，我們常?？梢栽O計一些公共函數(shù)，在減少編碼量的同時還能一定程度上提升腳本的可維護性和正確性。本論文研究的自動化測試框架采用lua作為測試框架的腳本。下面是測試框架要做的事情：第一、處理腳本中出現(xiàn)的異常和錯誤；然而相對自動化測試而言，我們不希望手動地一個一個腳本地執(zhí)行測試用例，而希望能夠更加隨心所欲地部署測試，基于此，我們希望測試框架可以幫我們實現(xiàn)：第二、根據(jù)需求驅(qū)動測試執(zhí)行；第三、測試場景恢復；第四、測試結果輸出。2接口測試技術分析2.1接口測試在企業(yè)，項目組和部門之間的協(xié)作大多需要依靠接口文件，而各個系統(tǒng)間接口能否保持正確和一致，對于整個軟件解決方案起著決定性作用。通過對一些項目的缺陷數(shù)據(jù)庫進行分析研究發(fā)現(xiàn)因為接口關系直接或間接產(chǎn)生的缺陷占整個缺陷數(shù)目的30%到40%左右,與此同時其中大多數(shù)缺陷的危害等級較高,并且由于此類缺陷的存在,導致產(chǎn)品質(zhì)量無法得到保障,因而對中間組件提出接口測試的需求。[3]2.1.1接口測試定義接口測試是運用軟件測試技術與方法對中間件的API進行測試的過程。接口測試包括了功能正確性、容錯性、性能測試等。[4]2.1.2接口測試層次通常，測試可以按以下階段劃分：1.單元2.集成3.系統(tǒng)4.驗收等四個層次單元測試單元測試，會對軟件的最小可測單元進行檢查和校驗，其中單元的含義，通常需要根據(jù)實際情況判斷，在不同情景下的單元含義有所不同?？偠灾?，單元一般被認為是最小的被測功能模塊，其在軟件測試過程中所屬的測試活動級別也是最低的。集成測試對單元測試進行邏輯上的擴展，得到的就是集成測試。最簡單的集成測試就是將兩個通過測試的單元組合成一個新的可測組件，測試這個新的組件的行為被稱為集成測試。在現(xiàn)實的解決方案中，所有的項目最后都有系統(tǒng)集成這個階段，很多時候在單元測試中沒有被發(fā)覺的問題，往往會在集成測試中顯現(xiàn)出來，所以集成測試必不可少。系統(tǒng)測試為了盡可能能夠發(fā)現(xiàn)軟件隱藏的問題，保證系統(tǒng)運行不出意外，系統(tǒng)測試會將經(jīng)過集成測試的軟件，作為計算機系統(tǒng)的一個部分，與系統(tǒng)中其他部分（經(jīng)過測試）相結合，在實際生產(chǎn)環(huán)境下對計算機系統(tǒng)進行的一系列嚴格有效地測試。驗收測試收測試是軟件開發(fā)環(huán)節(jié)結束后，用戶實際使用產(chǎn)品前的最后一次校驗軟件質(zhì)量的活動。驗收測試可以用來判斷開發(fā)者所開發(fā)的軟件產(chǎn)品能否滿足用戶最初的需求，以及用戶可以接受的差異范圍。驗收測試在開展測試工作初期，需要根據(jù)最初的需求文檔，進行軟件配置的評審、功能測試、性能測試等多方面進行檢測。驗收測試不單是檢驗軟件單個方面的質(zhì)量是否達標，而是要進行全面的軟件質(zhì)量的檢驗，并且是評判一個軟件是否合格的重要標準接口測試是針對接口進行的測試行為，在單元測試和集成測試中都包含了針對接口的測試，但二者側重的點與囊括的范圍不同。從這方面來說，接口測試的層次屬于這兩個層次圖1-1接口測試在測試階段的層次2.1.3接口測試的測試類型通常，根據(jù)測試方法的不同，軟件測試可以分為白盒、黑盒和灰盒白盒測試白盒測試又稱結構測試、透明盒測試、邏輯驅(qū)動測試或基于代碼的測試。作為一種設計測試用例的方法，白盒中的盒子指的是被測試的軟件，白盒的白是說盒子是透明的，即人們可以直觀地看到盒子內(nèi)部的東西運作規(guī)律。"白盒"法是在全面理解了程序內(nèi)部的邏輯構造后對全部的邏輯路徑進行的測試。"白盒"法屬于窮舉路徑測試法。這種測試方案，對測試者提出了必須了解程序的內(nèi)部構造的要求，需要測試者優(yōu)先檢查程序的邏輯，才能得出測試數(shù)據(jù)。[5]黑盒測試黑盒測試也稱功能測試,是軟件系統(tǒng)測試與確認測試中常用的測試方法。它是基于軟件規(guī)格對軟件進行的測試。在進行黑盒測試時，軟件內(nèi)部是如何運作的用戶一無所知,只關注程序外部構造,對軟件進行測試,通過軟件外部表現(xiàn)來判斷軟件是否存在其故障和缺陷。用戶對待程序就像是面對一個黑盒。黑盒測試方法主要有等價類劃分方法、邊界值分析方法、錯誤推測法、因果圖法、健壯性測試等?；液袦y試灰盒測試，是介于白盒測試與黑盒測試之間的一種測試，灰盒測試常常被用于集成測試階段，灰盒測試不但關注I/O的正確與否，而且也關注程序內(nèi)部的情況。和白盒測試相比，灰盒測試沒那么詳細、完整，但和黑盒測試相比，灰盒測試更關注程序的內(nèi)部邏輯。往往根據(jù)一些可以表明事物特征的現(xiàn)象、事件或標志來達到判斷運行狀態(tài)是否正常的目的。接口測試從測試方法上來分屬于灰盒測試，一般情況下為了保證驗證系統(tǒng)的核心算法，測試人員就需要了解被測文件系統(tǒng)核心的算法邏輯，并針對其設計合適的測試用例。2.1.4接口測試的意義1.更早的發(fā)現(xiàn)問題隨著敏捷測試的盛行，我們都知道測試工作開展的越早，bug的發(fā)現(xiàn)就越早，修復的成本就越低。然而功能測試通常都要等到系統(tǒng)提供可測試的UI界面后才可進行，單元測試專業(yè)性和人力成本要求又比較高，因此選擇了比較折中的接口測試。接口測試可以在功能界面未開發(fā)出來之前對系統(tǒng)的接口進行測試，從而更早的發(fā)現(xiàn)問題總是并以更低的成本修復問題。2.縮短產(chǎn)品周期接口測試更早的介入，更早的發(fā)現(xiàn)并解決bug，這可以大大地減少后續(xù)功能測試階段的bug量，最終加速項目的上線，這對于實現(xiàn)敏捷測試是大有裨益的。3.發(fā)現(xiàn)更底層的問題UI級測試有其局限性，系統(tǒng)里難免存在著一系列UI級測試難以察覺的bug，又或者是采用UI級測試難以構造測試用例。這時想要全面地覆蓋被測系統(tǒng)的代碼邏輯，進一步發(fā)現(xiàn)隱藏的漏洞，接口測試是不錯的選擇。同時想要復現(xiàn)一些極端現(xiàn)象，接口測試實現(xiàn)起來更為簡單。功能能完整的中間件，如果跳過單元測試直接進行集成測試，其存在的缺陷很有大概率會成倍地增加。例：子功能a存在4個bug，子功能b存在3個bug，對這兩個功能分別進行單元測試，可以發(fā)現(xiàn)3+4=7個bug，如果直進行集成測試，系統(tǒng)存在復雜性，全局的數(shù)據(jù)結構可能存在的問題，還有模塊之間的耦合都有可能導致bug數(shù)不在是加法，而是乘法bug數(shù)：3*4=12，這樣下來會導致無法定位原先單元測試就可以發(fā)現(xiàn)的問題最終增加軟件開發(fā)風險。為了應付此種情況，接口測試應運而生，其將測試的重點放在程序的核心模塊上面，比之單元白盒測試，有著低成本，高效（畢竟接口測試的層級在單元測試之上）等優(yōu)點?？偠灾?，接口測試，是在保證不提高軟件開發(fā)風險情況下最經(jīng)濟的解決方案。2.1.5接口測試難點雖然從上文我們了解了接口測試對保證軟件系統(tǒng)的質(zhì)量所起到的作用，但是在實際的測試項目中開展接口測試卻存在著較多問題，他們包括以下幾點：較高的軟件質(zhì)量和復雜的功能，所帶來的必然是越發(fā)復雜的系統(tǒng)結構。隨之而來的眾多接口會大幅提升測試工作量。從前文已知，接口測試從測試方法上來判斷是屬于灰盒測試，那么根據(jù)灰盒測試的特性我們不難得知，接口測試對測試人員軟件架構，接口關系的了解程度是一種考驗。各種各樣的測試對象，不同的軟件架構都將導致需要重新設計接口測試平臺，各平臺之間往往通用性較差。2.2接口測試自動化2.2.1軟件測試自動化的概念由于測試的許多工作是重復性的操作,而執(zhí)行重復操作正式計算機所擅長的。軟件自動化測試通常是通過開發(fā)所需的軟件測試工具以實現(xiàn)自動化。采用合適的自動化測試工具、正確地實現(xiàn)該測試工具以及高程度的自動化，帶來的將是高效的測試過程。[6]采用自動化測試是為了減少測試人員的工作量，在提高效率的同時縮短測試時間，以下是適合采取自動化測試的場景需要回歸測試[7]什么是回歸測試，參考網(wǎng)上的定義，每當軟件產(chǎn)品需要發(fā)布新的版本之時，需要對軟件的已有功能進行測試，而新版本與老版本的差異一般會比較小，這對回歸測試來說新的回歸測試的點不會和老的回歸測試有太大的差異，在這種情況下，自動化測試不需要做多大的改動就可以勝任，與手工測試相比自動化測試在回歸測試中可以極大地節(jié)約時間成本。軟件需要頻繁發(fā)布新版本軟件頻繁的版本更迭，會導致測試的功能點急劇增加，這時采用人工測試不僅耗時且流程繁瑣，這時人工測試就容易出現(xiàn)問題導致測試的質(zhì)量難以保證。需要非功能性測試非功能性測試一般指壓力測試、并發(fā)測試等用于檢查軟件的非功能方面（性能、可用性、可靠性）的測試，這些測試使用人工測試難以達到目的。而自動化測試其使用腳本來執(zhí)行測試用例這就保證了多次執(zhí)行的測試用例不會不同，且容易生成測試報告，這時使用自動測試，既可以提高測試質(zhì)量，又可以提高測試效率。同時自動化測試還有許多其他的閃光點：更好的利用資源如果任務可以自動化執(zhí)行，那么測試人員的積極性與測試結果的準確性將得到提高。讓測試技術人員可以從中解脫出來。這對與好的測試用例的編寫和設計顯然是有利的。有些測試的一部分可以自動化，另一部分卻不適合，這種情況，如果將可自動化的部分自動化了，不可自動化的部分的效率在某種程度上也會得到提升。測試具有一致性和可重復性。由于測試是自動執(zhí)行的，每次測試的結果與執(zhí)行的內(nèi)容的一致性是能夠得到證的，最終可以實現(xiàn)測試的可重復。3.測試的復用性。腳本技術是自動化測試中的常用技術，這使得在實現(xiàn)不同測試過程時如果有用到類似的用例，腳本的改動點會變得比較少，利于復用。增加軟件的信任度自動執(zhí)行的測試不會因執(zhí)行的錯誤出現(xiàn)問題，和手工測試不同，他更需要高質(zhì)量的測試用例的設計。相應的，軟件可以通過高質(zhì)量設計的測試用例，那么人們該軟件的信任度就會上升。2.2.2軟件測試自動化的技術

在軟件自動測試系統(tǒng)的實現(xiàn)過程中，框架的設計可以最大限度地減少測試腳本的維護，但是大量的自動化測試工具都采用傳統(tǒng)的“記錄回放”模式。由于測試腳本程序中的測試數(shù)據(jù)是硬編碼的，因此腳本維護更高，除了測試應用程序的圖形用戶界面外，該工具的內(nèi)置測試用例也很方便。因此，在開始之前，選擇合適的測試自動化框架是測試自動化團隊的首要任務。自動化測試框架是一組支持自動化測試的假設、概念和實踐。下面是五個基本的自動化測試框架：模塊化測試腳本框架和測試庫體系結構框架、關鍵字驅(qū)動/表驅(qū)動測試框架、數(shù)據(jù)驅(qū)動測試框架、混合測試框架。1.模塊化測試框架測試模塊框架需要創(chuàng)建描述要測試的模塊、片段和應用程序的獨立的小腳本。樹結構中的這些小腳本可以組合成腳本，用于特定的測試用例。在這五類框架中，模塊化框架最容易掌握。眾所周知，抽象層是在組件上構建的，以便在應用程序的其余部分中隱藏它們。應用程序獨立于組件的更改，并為編程提供模塊化功能。模塊化測試腳本使用這些抽象或封裝的原則來提高自動化測試組合的可升級性與可維護性。2.測試庫體系結構框架測試庫的體系結構與模塊化測試腳本框架相似。他們的優(yōu)點相同。不同之處在于前者是將被測程序分解為過程和函數(shù)。后者將之分解為腳本，庫文件，待測片段和應用程序。3.關鍵字驅(qū)動/表驅(qū)動測試框架對于獨立于程序的自動化框架，I9LJJ關鍵字測試和表測試是可互換的術語。此框架實現(xiàn)的關鍵在于數(shù)據(jù)表與關鍵字的設計。設計的數(shù)據(jù)表和關鍵字與運行它們的測試自動化工具并無關聯(lián)，通常被用來“驅(qū)動”測試腳本代碼。面向全局的關鍵測試類似于手動測試用例。在關鍵字測試中，將要測試的應用程序的函數(shù)和每個測試需要執(zhí)行的執(zhí)行步驟寫入表內(nèi)。這個測試框架可以用較少的代碼生成大量的測試用例，在使用數(shù)據(jù)表生成單個測試用例時可以重用代碼。4.數(shù)據(jù)驅(qū)動測試框架基于數(shù)據(jù)，LJ是一個框架，這里測試的輸入輸出數(shù)據(jù)來自數(shù)據(jù)文件。在這個框架中，變量不僅用于存儲輸入值，還用于存儲輸出驗證值。測試腳本讀取值文件并記錄測試狀態(tài)和信息。這類似于基于表的測試，其測試用例包含在數(shù)據(jù)文件中，而不是腳本中。對于數(shù)據(jù)而言，腳本只是“讀取器”或傳輸機制。數(shù)據(jù)驅(qū)動測試和表驅(qū)動測試不同。數(shù)據(jù)驅(qū)動測試里，數(shù)據(jù)文件只含有測試數(shù)據(jù)。該框架旨在減少所有測試用例要執(zhí)行的測試腳本的總數(shù)，數(shù)據(jù)驅(qū)動程序可以用很少的代碼生成大量的測試用例，這與表驅(qū)動程序非常相似。5.混合測試自動化框架最常見的實現(xiàn)框架是將上述所有技術結合起來2.2.3API級自動化測試隨著越來越多互聯(lián)網(wǎng)公司采用敏捷開發(fā)，軟件開發(fā)與自動化測試的方式也產(chǎn)生了革新。在敏捷開發(fā)之前，大部分自動化時間都是通過圖形用戶界面（GUI）完成的。這是Selenium和UFT/QTP等工具處理的部分。但是，在進行了一段時間的自動化操作后，我們不難發(fā)現(xiàn)這些類型的測試是多么耗時，脆弱且難以維護。企業(yè)投入大量資金來創(chuàng)建自定義功能GUI測試自動化框架，單很可能最終使他們對其可靠性失去了信心，直到人們停止投入。同樣，針對用戶界面的GUI測試往往需要花費很長時間才能運行。對于某些敏捷實踐（例如連續(xù)構建），遷入新代碼時，從GUI回歸測試套件接收反饋所花費的時間是不能被接受的。API快速反饋在這些情況下，需要更快的反饋。發(fā)現(xiàn)錯誤的時間越早越好，因為開發(fā)人員會立即知道他們所做的代碼更改已破壞了構建，因此需要進行檢查。在測試驅(qū)動的流程中，用戶需要大量測試集才能快速且頻繁地運行，并且必須能夠?qū)⑺鼈兗傻介_發(fā)生命周期中。GUI測試仍然非常重要。它是唯一能夠真正測試用戶在生產(chǎn)過程中如何體驗應用程序的測試類型。某些缺陷只能通過GUI測試來捕獲。換句話說，盡管至關重要，但GUI不應是用戶關注的唯一自動化類型，也不應該是自動化測試總量中最大的一部分。敏捷關注的自動化類型是更可靠的API下層測試，而較少涉及GUI自動化。GUI自動化需要進行界面文件的解析、界面參數(shù)值的確定和整理等工作，比較繁瑣并且重復性強。通過對接口測試的研究，我們不難發(fā)現(xiàn)，雖然接口測試工作量很大但測試期望很容易形式化，這表明可以使用自動化測試技術進行接口測試。一般維護管理要求和測試用例易用性，所以這里使用Lua腳本作為執(zhí)行自動化測試的基礎實現(xiàn)接口級測試自動化。2.3Lua腳本語言簡介Lua是一種強大、高效、輕量級、可嵌入的腳本語言。它支持過程編程、面向?qū)ο缶幊?、函?shù)式編程、數(shù)據(jù)驅(qū)動編程和數(shù)據(jù)描述。Lua通過使用基于寄存器的虛擬機解釋字節(jié)碼實現(xiàn)了動態(tài)類型。并且具有自動內(nèi)存管理機制和增量垃圾收集機制。Lua作為一個語言引擎，占用空間小，易于嵌入到應用程序中。API簡單且文檔化，調(diào)用方便。允許與其他語言編寫的代碼進行集成和擴展。還可以用Lua擴展用其他語言編寫的程序。除了采用C和C++編寫的程序，甚至Java、C#、Smalltalk、Fortran和其他腳本語言，像Perl和Ruby編寫的程序都可以使用LUA進行擴展。[8]

3測試需求與總體框架設計3.1測試需求在明確測試需求前先簡單的介紹下要測試的接口程序Transmid在架構中所處的位置。交易系統(tǒng)框架主要包含下單終端、委托主站、Transmid事物處理機和券商。其中，下單客戶端主要是為用戶提供委托下單操作用的程序，用戶通常利用電腦軟件、手機APP進行炒股，所用的客戶端工具，即為下單客戶端，用戶利用自己的客戶號或資金賬號等，進行登錄后，可以實現(xiàn)股票的功能，例如委托、查詢功能等；基金的功能，如基金申購基金認購等。所有交易類的請求的接入主要由委托主站（委托網(wǎng)關也會接入交易類請求，但請求的最終目的地還是委托主站）。券商券商事務處理機Transmid下單終端委托主站圖3-1交易系統(tǒng)架構圖[9]券商券商事務處理機Transmid下單終端委托主站測試的主要需求是對公司的Transmid代碼進行測試，確定接口程序在收到客戶端http請求后返回的數(shù)據(jù)內(nèi)容正確。測試程序需要模擬客戶端行為1.發(fā)送http請求到委托主站2.解析應答數(shù)據(jù)3.對應答數(shù)據(jù)正確與否進行判斷3.1.1測試數(shù)據(jù)與測試代碼分離通常情況下測試代碼需要執(zhí)行以下測試邏輯運行要測試代碼運行要測試代碼驗證測試結果正確性結束開始處理測試數(shù)據(jù)圖3-2測試代碼處理邏輯這時，測試數(shù)據(jù)和測試代碼的混合，極其容易導致測試數(shù)據(jù)的難以維護。所以為了達到簡化測試代碼處理邏輯的同時提高測試數(shù)據(jù)可維護性的目的。將測試數(shù)據(jù)和測試代碼分離開來必不可少。3.1.2測試環(huán)境從測試代碼和腳本的可重用性角度出發(fā)，如果接口測試框架能夠在不改代碼的情況下多平臺運行，是最理想的情況。這種情況下得到的結論是，接口測試框架應該是可移植的并和平臺無關。3.1.3自動執(zhí)行測試對于自動化測試測試用例的執(zhí)行，我們希望部署測試可以更加得心應手，在選擇要執(zhí)行的用例后，自動化測試框架能夠執(zhí)行相應的用例并給出測試結果。3.1.4自動生成測試結果對在自動執(zhí)行測試代碼后，還要能夠?qū)⒌玫降臏y試結果和我們的預期進行比較，自動地生成測試報告3.1.5能處理腳本中出現(xiàn)的異常和錯誤在執(zhí)行測試用例過程中，肯定有部分測試用例會導致腳本出現(xiàn)一些異常錯誤，這時需要測試框架能對腳本的異常和錯誤進行處理，如拋出異常。否則如果測試腳本本身就存在漏洞的，那么測試結果的可信度就大大降低了。在有了一系列的容錯處理后我們當讓希望這些異常在最后的測試報告中也能有所體現(xiàn)，為后續(xù)問題的排查提供便利，提高這個測試報告的價值。3.2Lua腳本3.2.1為什么要用腳本自動化測試為什么要用腳本。在自動化測試中我們需要代碼能夠被動態(tài)配置的同時易于維護，而腳本代碼通常具有以下特點：快速開發(fā)：腳本語言極大得簡化了開發(fā)周期容易部署：大多腳本語言不需要編譯和打包易學：通常對語言技術要求較低，容易找到技術人員支持動態(tài)代碼：腳本代碼能實時生成和執(zhí)行從這些方面來看腳本是比較符合自動化測試的需求的3.2.2為什么要用LuaLua是一種擴展的程序設計語言，同時對那些具有數(shù)據(jù)描述機制的一般過程式編程語言。它還為對象語言、函數(shù)式編程和數(shù)據(jù)驅(qū)動編程提供了良好的支持[10]Lua具有以下特點輕量級:Lua是以標準C語言編寫的，并且開放源代碼，編譯后體量只有百余k，在別的程序里嵌入lua是十分便捷的?？蓴U展:Lua提供了許多非常易于使用的擴展接口和機制：這些功能同通常由宿主語言提供，Lua可以想使用內(nèi)置功能一樣使用這些功能的時候。支持面向過程編程和函數(shù)式編程自動內(nèi)存管理；只用一種通用類型的表（table）實現(xiàn)了實現(xiàn)數(shù)組，哈希表，集合，對象3.3接口測試框架單元測試部分從前文可知，接口測試在測試中的層級，而要從頭設計一個自動化測試框架是十分復雜的，這里我采用的是比較取巧的方法，先用的Luaunit框架（一個針對Lua實現(xiàn)的單元測試框架）搭配相應的http庫和接口文檔實現(xiàn)對接口的自動化測試。3.3.1LuaUnit介紹Luaunit是Lua語言的一套用于編寫lua的單元測試的框架，可以運行在很多平臺上（包括Linux、MacOSX、Windows、Cygwin等等）。基于xUnit架構支持很多好用的特性，支持生成Test，TAP，JUnit和XML報告等等，這些格式的結果報名可以很好地集成于Jenkins和Hudson的持續(xù)集成環(huán)境luaunit支持通過傳遞一些命令去挑選測試用例，見下文LuaUnit的命令部分描述uaunit支持lua5.1到lua5.3，支持luaJIT2.0和LuaJIT2.1beta，以及其它各種操作系統(tǒng)，Windows，MacOSX和Ubuntu[8]3.3.2使用LuaUnit實現(xiàn)接口測試單元測試關心的通常是一個代碼的實現(xiàn)部分與內(nèi)部邏輯，往往是針對函數(shù)功能。通常單元測試需要調(diào)用被測的函數(shù)或方法，傳參然后得到一個結果。接著對結果進行斷言。根據(jù)編寫斷言用于判斷結果否合乎預期來確定測試是否通過。而接口測試往往關注的是業(yè)務邏輯。這里通過將修改單元測試三部分的具體實現(xiàn)來實現(xiàn)對接口的測試。首先將單元測試的輸入部分改為發(fā)送http請求，然后將輸出部分改為接收接口返回數(shù)據(jù)，最后的斷言部分和單元測試類似。所以要做的就分成三部分，實現(xiàn)測試輸入部分：請求的發(fā)送，實現(xiàn)測試輸出部分：請求的接收，實現(xiàn)測試的斷言部分：對得到的接口數(shù)據(jù)進行斷言操作。

4接口自動化測試框架實現(xiàn)前面說了框架的組成思路這里說下具體的實現(xiàn)，主要將測試框架分為以下6個對象分別實現(xiàn)4.1TestCase存放每個請求的獨特的入?yún)ⅲㄈ绻淙雲(yún)⑷缫涌诜祷乜梢郧短椎匕l(fā)送請求），請求的步驟，所需調(diào)用的驗證器。在使用測試用例時會將該表與公共測試用例（測試用例的公共部分）結合。Testcase.validatetable格式數(shù)據(jù)，記錄需要調(diào)用那些assert方法驗證請求Testcase.urltable格式數(shù)據(jù)，存放請求的cmd和其他信息

4.1.1TestCase作用TestCase作為測試用例對象，自動化測試，讓代碼代替手工執(zhí)行相應的操作，操作的流程當然需要預先設計的，這里就用到測試用例的編寫。4.1.2TestCase的實現(xiàn)測試用例類單獨在testcase文件夾中定義測試用例類通常包含了對一個接口模塊的特定功能的集成測試所以測試用例類中可能包含了多個單元測試的內(nèi)容，一個測試用例類的執(zhí)行包括以下幾個步驟調(diào)用測試用例的初始化方法初始化按照測試用例中的順序執(zhí)行測試用例中的單元測試調(diào)用測試用例的結束方法按以上的步驟分步講解一個測試用例類中需要定義的屬性定義初始化方法測試用例類需要初始化，就需要在testcase定義初始化方法在這里，測試用例類的初始化方法被定義為setUpClass，設置初始化方法的好處是可以將測試用例一些通用的操作都放到這里來，比如在執(zhí)行測試用例前需要先進行身份驗證等操作。而不用在單元測試中在一一添加這些操作。定義單元測試內(nèi)容單元測試的測試用例同樣包含三部分，第一部分就是單元測試的初始化方法這里定義為setUp，第二部分是http請求的請求參數(shù)和驗證器的選擇，第三部分則是單元測試的結束方法，定義為tearDown定義測試用例結束方法測試用例類的結束方法定義為tearDownClass，設置結束方法的好處也顯而易見，和設置初始化方法的目的一樣，是為了將測試用例類結束后需要進行的操作進行統(tǒng)一。其中定義單元測試內(nèi)容的實現(xiàn)是是否能將測試數(shù)據(jù)和測試代碼分離的關鍵。如果在單元測試的內(nèi)容中寫死請求地址，參數(shù)等信息。在要測試的接口增加的情況下，每個case都需要寫，這其中很大部分工作量是不必要的。為了解決這個問題，不在單元測試中寫死請求地址而是引用特定的api，后續(xù)只維護特定api文件就可以減少測試用例url部分的工作量。下面是最簡單情況下單元測試的程序流程圖發(fā)送發(fā)送http請求處理應答數(shù)據(jù)單元測試結束單元測試開始執(zhí)行api驗證執(zhí)行Teardown執(zhí)行setup圖4-1單元測試程序流程圖4.2Assert封裝了一些列參數(shù)校驗方法用于驗證客戶端的請求參數(shù)和應答參數(shù)。如果腳本執(zhí)行過程中出現(xiàn)異常，就拋出該異常，在后面的報告中會生成錯誤信息。4.2.1Assert作用驗證器類，里面封裝了可以驗證請求參數(shù)和測試用例執(zhí)行結果的各種參數(shù)校驗方法，從數(shù)據(jù)類型判斷，到數(shù)值是否相等的判斷。一個完善的校驗，是一個自動化測試的核心。在luaunit中校驗即使斷言操作。4.2.2Assert的實現(xiàn)Assert定義在luaunit.lua中，在luaunit框架中已經(jīng)定義了許多常用的斷言如相等斷言，值斷言，字符串斷言等。由于測試的接口程序返回內(nèi)容為xml格式進過xmlparser解析后以lua特有的table數(shù)據(jù)格式存在，有時候為滿足對table格式數(shù)據(jù)的直接處理需要新實現(xiàn)了以下斷言：assertXmlNodeExist--判斷xml節(jié)點是否存在assertXmlNodeNotExistassertXmlValueEquals --判斷xml節(jié)點值是否符合預期assertXmlValueNotEquals4.3Client用于模擬客戶端發(fā)送請求，根據(jù)測試用例中的參數(shù)生成url，使用luasocket庫實現(xiàn)請求發(fā)送。4.3.1Client的實現(xiàn)Client用來模擬客戶端，client要能實現(xiàn)客戶端的請求發(fā)送。已知客戶端和接口間的通訊是同過http請求，所以只要能夠模擬發(fā)送http請求并帶上相應參數(shù)（這里的參數(shù)大多在測試用例中定義）就可以模擬客戶端行為。Lua作為一門十分輕便的語言，在官網(wǎng)上有專門的luasocket庫可以用于網(wǎng)絡編程。這里要實現(xiàn)http請求發(fā)發(fā)送和接受，發(fā)送使用luasocket中的httpget方法。該方法需要請求的url。該url使用前文的testcase對象中的url的關鍵參數(shù)拼接而成。然后創(chuàng)建xmlparser實例，用于對應答xml數(shù)據(jù)的解析。4.3.2luasocket庫介紹LuaSocket是一個Lua擴展庫，它由兩部分組成：一個C內(nèi)核，提供對TCP和UDP傳輸層的支持；一組Lua模塊，添加對SMTP（發(fā)送電子郵件）的支持，HTTP（WWW訪問）和FTP（上傳和下載文件）協(xié)議以及處理Internet的應用程序通常需要的其他功能。這個介紹是關于C內(nèi)核的。LuaSocket中的通信通過I/O對象執(zhí)行。這些可以表示不同的網(wǎng)絡域。目前，提供了對TCP和UDP的支持，但沒有任何東西阻止其他開發(fā)人員實現(xiàn)SSL、本地域、管道、文件描述符等。I/O對象提供了跨不同域和操作系統(tǒng)的I/O標準接口。API設計有兩個目標。首先，使用過CAPI到套接字的用戶應該對使用LuaSocket感到舒服。第二，應該保留Lua語言的簡潔性和感覺。為了實現(xiàn)這些目標，luasocketapi盡可能地保留CAPI中的函數(shù)名和語義，但是它們在Lua中的用法已經(jīng)大大簡化了。其中一個簡化是接收模式功能。應用程序可以逐行、逐塊或直到連接關閉為止從流域（如TCP）讀取數(shù)據(jù)。所有I/O讀取都是緩沖的，不同接收模式之間的性能差異可以忽略不計。另一個優(yōu)點是靈活的超時控制機制。與C語言一樣，所有I/O操作在默認情況下都是阻塞的。例如，TCP域的send、receive和accept方法將阻止調(diào)用方應用程序，直到操作完成（如果有！）。但是，通過調(diào)用settimeout方法，應用程序可以指定LuaSocket可以阻止的時間上限（“總”超時）、LuaSocket可以被任何操作系統(tǒng)調(diào)用內(nèi)部阻止的時間上限（“塊”超時）或兩者的組合。每個LuaSocket調(diào)用可能執(zhí)行幾個OS調(diào)用，因此這兩個超時值不相等。最后，主機名解析是透明的，這意味著大多數(shù)函數(shù)和方法同時接受IP地址和主機名。如果給定了主機名，庫將查詢系統(tǒng)的解析程序并嘗試返回的主IP地址。請注意，直接使用IP地址當然更有效。DNS模塊提供的toip和tohostname函數(shù)用于在主機名和IP地址之間進行轉換?？偠灾?，這些變化使得LuaSocket中的網(wǎng)絡編程比C中的簡單得多4.4Pasrsexml用于解析應答的xml格式數(shù)據(jù)，將xml轉換成特定的table格式數(shù)據(jù)4.4.1xml格式XML全稱是EXtensibleMarkupLanguage，翻譯過來就是可擴展置標語言，可擴展標記語言或可延伸標示語言，是一種置標語言。XML的前身是SGML（TheStandardGeneralizedMarkupLanguage），是自IBM從60年代就開始發(fā)展的GML（GeneralizedMarkupLanguage）4.4.2Pasrsexml的實現(xiàn)接口的應答數(shù)據(jù)會經(jīng)過委托主站，由于測試的是面向手機客戶端的接口，數(shù)據(jù)在從主站到客戶端之間會經(jīng)過網(wǎng)關的轉化，總之最后客戶端端得到的數(shù)據(jù)會是xml格式的，具體的轉換協(xié)議這里不進行詳談。Xml文檔是一種樹行結構而想要用lua解析xml格式的數(shù)據(jù)，是非常容易實現(xiàn)的。這里采用Lua-Simple-XML-Parser來實現(xiàn)對xml文檔的解析。4.4.3Lua-Simple-XML-Parser[12]和這個庫的名字一樣調(diào)用起來非常簡單，只需要把要取的值當作lua中table表的屬性一樣取值就可以取到不同層級的xml結構中的數(shù)據(jù)。4.5Output用于存放testcase執(zhí)行過程中產(chǎn)生的各種日志信息和錯誤信息，還有執(zhí)行結果4.6HtmlReportLuaunit本身有三種測試結果數(shù)據(jù)模式，可以通過執(zhí)行腳本時用-o參數(shù)設置輸出模式。分別是nil、tap和junit。但是這些都只是簡單的羅列，作為測試報告的話不夠簡潔明了的。為了能更加直觀的展示測試結果，這里希望能將測試結果以html頁面的方式展示出來。4.6.1HtmlReport的實現(xiàn)要實現(xiàn)將測試結果展示為html需要做兩處改動，首先就是修改luaunit框架中的測試結果生成部分代碼。增加html類報告。其次就是報告格式及其具體內(nèi)容取值的實現(xiàn)。參考原有的TextOutput類編寫HtmlOutput類具體要實現(xiàn)以下方法startsuite測試用例集開始時執(zhí)行打開用于保存結果的html文件，需要讀取結果文件的文件名由用戶輸入。startclass在測試類開始執(zhí)行前的執(zhí)行，這里就只輸出日志表示測試類的開始執(zhí)行。starttest在單個測試步驟開始執(zhí)行前執(zhí)行，目前就輸出日志表示單個測試步驟的開始執(zhí)行。UpdateStatus測試用例執(zhí)行失敗時調(diào)用endtest測試步驟執(zhí)行完畢后調(diào)用endClass測試類執(zhí)行完畢后調(diào)用endsuite測試用例集結束時執(zhí)行。在這里將測試結果寫入前面打開的html文件。在文件htmlreport中定義具體html模板4.7數(shù)據(jù)分離前面提到了將測試數(shù)據(jù)與測試代碼分離開的種種好處，這里要如何實現(xiàn)測試數(shù)據(jù)的分離呢。這里要分離的數(shù)據(jù)主要是在http請求中的參數(shù)。通常改變?nèi)毯驮O備，http請求中相應的參數(shù)要做出更改，如果不將這些數(shù)據(jù)分離出來，測試用例的復用將會變的十分困難（每次面對新的券商都需要一一更改對應的接口ip之類的數(shù)據(jù)）。而將這些數(shù)據(jù)分離出來之后，只需要維護每個券商自己的券商配置表，請求的公共參數(shù)都從中讀取那么測試用例的可復用性將得到大大地提升。4.7.1數(shù)據(jù)分離的實現(xiàn)這里主要做的是將http和券商相關的部分做分離，每個券商對應一個qs_config文件夾下的一個文件。最外層還在config.lua中配置了默認ip，在執(zhí)行測試用例是如需加載相應配置只要修改all_tests.lua文件中如圖所示配置圖4-2quanshang.lua配置4.8mockserver如今的業(yè)務系統(tǒng)越來越復雜龐大，各個功能直接的調(diào)用也是多如牛毛，但如果在聯(lián)調(diào)的時候，恰好被調(diào)的接口正在開發(fā)，這時會搭建一些server來進行mock。使得被開發(fā)功能的調(diào)試和測試功能能夠正常進行下去。4.8.1mockserver特性[13]MockServer允許用戶通過HTTP或HTTPS模擬任何服務器或服務，例如REST或RPC服務。這在以下情況下很有用：測試輕松地為HTTP依賴項（如REST或RPC服務）重新創(chuàng)建所有類型的響應，以便輕松有效地測試應用程序隔離測試中的系統(tǒng)，以確保測試可靠地運行，并且只有在存在真正的錯誤時才會失敗。重要的是，只測試被測系統(tǒng)，而不測試其依賴項，以避免由于不相關的外部更改（如網(wǎng)絡故障或服務器重新啟動/重新部署）而導致測試失敗。輕松地為每個測試單獨設置模擬響應，以確保每個測試都封裝了測試數(shù)據(jù)。避免在難以管理和維護的測試之間共享數(shù)據(jù)，避免測試相互污染的風險創(chuàng)建測試斷言，以驗證被測試系統(tǒng)已發(fā)送的請求去耦合開發(fā)在服務可用之前開始使用服務API。如果API或服務處于尚未開發(fā)完成的情況，MockServer可以模擬API，使得使用該服務的所有團隊可以在不延遲的情況下開展工作當API/服務可能極不穩(wěn)定和不穩(wěn)定時，在初始開發(fā)階段隔離開發(fā)團隊。使用MockServer允許開發(fā)工作在外部服務失敗時繼續(xù)進行隔離單個服務在部署和調(diào)試服務期間，以Debug模式在本地計算機上運行單個應用程序或服務或處理請求的子集是很有幫助的。使用MockServer可以很容易地有選擇地將請求轉發(fā)到處于Debug模式運行的進程，所有其他請求都可以轉發(fā)到實際服務（例如在QA或UAT環(huán)境中運行的服務）4.8.2搭建mockserver目前實現(xiàn)的效果就是根據(jù)http請求中的cmd參數(shù)返回相應的xml格式數(shù)據(jù)，來達到模擬網(wǎng)關等一系列鏈路。這里選擇flask框架來搭建mock服務。Flask是由Python語言編寫的一個輕量級的靈活、輕便、安全且容易上手的可定制框架。Flask定制性較強，在保持核心功能簡單的同時實現(xiàn)了功能的豐富與擴展，用戶可以根據(jù)自己的需求來DIY相應的功能，利用其強大的插件庫可以讓用戶實現(xiàn)個性化的網(wǎng)站定制，開發(fā)出功能強大的網(wǎng)站。同時它和MVC開發(fā)模式可以完美契合，這讓開發(fā)人員可以充分分工合作最大限度地提高效率。使用Flask讓小型團隊想使用較短的時間實現(xiàn)功能豐富的中小型規(guī)模的網(wǎng)站成為可能。Flask的工作過程見圖。Flask的基本模式是在程序中將視圖函數(shù)和URL對應起來，當URL被訪問時，分配好的視圖函數(shù)會被系統(tǒng)執(zhí)行，然后在瀏覽器上將展示該函數(shù)的返回值。圖4-3框架的工作過程Mock服務搭建好后，針對每個cmd需要創(chuàng)建相應的xml文件用于應答的時候使用。

5運行效果與分析5.1測試環(huán)境因為本地沒有接口環(huán)境所以使用mockserver模擬接口返回數(shù)據(jù)。5.1.1硬件環(huán)境CPU英特爾i7-7700HQ內(nèi)存：8GB硬盤：223GB5.1.2軟件環(huán)境操作系統(tǒng)：windowsLua：使用效果5.2.1啟動mock服務器安裝好falsk庫，在命令行中執(zhí)行mockserver.pypython文件如圖所示。圖5-1啟動mock服務器Mock服務啟動成功，后續(xù)請求url會打印在這個終端。保持這個終端。5.2.2運行測試腳本測試腳本在運行前需在腳本文件all_tests.lua中配置好要加載的配置文件。這里選擇加載配置好的qs_config.test.lua。該配置文件配置內(nèi)容如下圖5-2test.lua配置接著選擇要執(zhí)行的測試用例文件，可以選擇一個也可以選擇多個，這里選擇執(zhí)行testcase.test.lua。執(zhí)行all_tests.lua在控制臺中輸入luaall_tests.lua-ohtml-ntest-o指定輸出測試結果格式，luaunit框架原本是沒有html格式報告，可以通過修改luaunit.lua增加測試結果格式選擇，這里不多贅述。-n指定生成的html文件名不需要帶后綴html這里得到執(zhí)行結果圖5-3執(zhí)行all_tests.lua圖5-4執(zhí)行結果可以看到執(zhí)行了幾個個測試用例，執(zhí)行的時間，成功失敗的數(shù)量，錯誤的數(shù)量。5.2.3查看生成報告前面執(zhí)行測試用例得到了執(zhí)行結果html文件，這里通過瀏覽器查看。圖5-5測試報告測試報告分總覽和細節(jié)部分，細節(jié)部分分4個欄目。分別是測試用例執(zhí)行狀態(tài)，測試用例名稱，應答時間，詳情。點擊詳情欄的log按鈕可以進入log頁面。這里我們選