前言
在開始本文之前芦岂，需要聲明以下關(guān)鍵詞：
? ? ? 1.mock測(cè)試: mock測(cè)試就是在測(cè)試過程中聚凹，對(duì)于某些不容易構(gòu)造或者不容易獲取的對(duì)象逼龟，用一個(gè)虛擬的對(duì)象來創(chuàng)建以便測(cè)試的測(cè)試方法臂外。
? ? ? 2.restful: 一種軟件架構(gòu)風(fēng)格伴澄，設(shè)計(jì)風(fēng)格而不是標(biāo)準(zhǔn)碰缔，只是提供了一組設(shè)計(jì)原則和約束條件金抡。它主要用于客戶端和服務(wù)器交互類的軟件榛瓮∥谆鳎基于這個(gè)風(fēng)格設(shè)計(jì)的軟件可以更簡(jiǎn)潔粹懒，更有層次凫乖，更易于實(shí)現(xiàn)緩存等機(jī)制帽芽。
? ? ? 3.第一階段: 項(xiàng)目開發(fā)分為三個(gè)階段，即通俗解釋的：需求評(píng)審階段披泪、開發(fā)編碼階段付呕、驗(yàn)收階段。而需求評(píng)審階段對(duì)應(yīng)第一階段佩厚。以此類推。
? ? ? 4.接口測(cè)試: 接口測(cè)試是測(cè)試系統(tǒng)組件間接口的一種測(cè)試钙姊。接口測(cè)試主要用于檢測(cè)外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個(gè)子系統(tǒng)之間的交互點(diǎn)煞额。測(cè)試的重點(diǎn)是要檢查數(shù)據(jù)的交換，傳遞和控制管理過程婚温，以及系統(tǒng)間的相互邏輯依賴關(guān)系等栅螟。在本文主要特指 “API測(cè)試”
? ? ? 5.API測(cè)試: API（Application Programming Interface力图，簡(jiǎn)稱：API），又稱為應(yīng)用編程接口，就是軟件系統(tǒng)不同組成部分銜接的約定惑朦。由于近年來軟件的規(guī)模日益龐大，常常需要把復(fù)雜的系統(tǒng)劃分成小的組成部分胃珍，編程接口的設(shè)計(jì)十分重要吩蔑。程序設(shè)計(jì)的實(shí)踐中烛芬，編程接口的設(shè)計(jì)首先要使軟件系統(tǒng)的職責(zé)得到合理劃分赘娄。良好的接口設(shè)計(jì)可以降低系統(tǒng)各部分的相互依賴遣臼，提高組成單元的內(nèi)聚性，降低組成單元間的耦合程度个榕，從而提高系統(tǒng)的維護(hù)性和擴(kuò)展性西采。
? ? ? 6.API功能測(cè)試： API測(cè)試是針對(duì)系統(tǒng)所提供的API做各方面的驗(yàn)證。API的性能和安全測(cè)試根據(jù)測(cè)試策略的不同霹崎，會(huì)是一個(gè)可選測(cè)試項(xiàng)尾菇。這個(gè)可以作為兩個(gè)單獨(dú)的問題來討論劳淆。API的功能測(cè)試類似于UI功能測(cè)試，都是在已知輸入內(nèi)容和期望結(jié)果的前提下曲掰，使用這個(gè)功能/調(diào)用這個(gè)API并且驗(yàn)證是否能返回期望的結(jié)果栏妖。不同的是API測(cè)試在返回結(jié)果被呈現(xiàn)給客戶前就完成了，從而對(duì)測(cè)試環(huán)境的依賴會(huì)比較小。
? ? ? 7.ATMS：API Automatic Testing and Mocking System,接口雙向服務(wù)系統(tǒng)翰守。
一.背景分析
經(jīng)過多次項(xiàng)目開發(fā)及對(duì)項(xiàng)目的測(cè)試工作蜡峰，總結(jié)到我們公司乃至社會(huì)上的同類企業(yè)都存在以下問題：
? 1.對(duì)開發(fā)編碼時(shí)期運(yùn)行過程中的測(cè)試工作不足，出現(xiàn)該情況的主要問題在于兩點(diǎn)：
? ? ? （1）測(cè)試人員對(duì)開發(fā)技術(shù)不了解油航，多數(shù)無法穿插到開發(fā)編碼時(shí)期進(jìn)行一些對(duì)接型的測(cè)試。
? ? ? （2）大多數(shù)企業(yè)的慣性思維镰踏，認(rèn)為測(cè)試就應(yīng)該是開發(fā)結(jié)束并成型后才引入沙合。
? 2.測(cè)試所使用的工時(shí)過短谨敛，該情況出現(xiàn)原因如下：
? ? ? （1）個(gè)別企業(yè)及開發(fā)團(tuán)隊(duì)有種“功能開發(fā)出來就好即舌，測(cè)試等上線再做”的先斬后奏的意識(shí)佣盒，從而導(dǎo)致在項(xiàng)目周期中，測(cè)試的工時(shí)安排被推到特特別后顽聂，甚至僅僅在上線前做一次臨上線的測(cè)試肥惭。從而帶來了更多的隱患。
? ? ? （2）個(gè)別企業(yè)及開發(fā)團(tuán)隊(duì)輕視測(cè)試紊搪，在測(cè)試方面的投入不足蜜葱，甚至讓開發(fā)自行進(jìn)行測(cè)試∫或者是把項(xiàng)目開發(fā)得七七八八的時(shí)候野崇，交由測(cè)試跟測(cè)試說：“隨便測(cè)試下就好了”
? 3.前端依賴后端開發(fā)扶镀，前端的進(jìn)度很大程度上受到了后端的制約。在當(dāng)下的技術(shù)氛圍中旭从，大多數(shù)是前端開發(fā)好頁面后褒繁，對(duì)接后端的數(shù)據(jù)，對(duì)接方式分為兩種：（1）后端渲染型磨澡，后端將前端頁面放到后端模板引擎中進(jìn)行渲染。（2）前端通過接口對(duì)后端交互數(shù)據(jù)霹菊，并在前端渲染饶碘。這兩種都有對(duì)后端強(qiáng)依賴的特點(diǎn)，因?yàn)楹蠖颂峁?shù)據(jù)源，前端無法在不修改代碼的情況下構(gòu)造合法數(shù)據(jù)示辈。
? ? 4.后端開發(fā)了接口一旦數(shù)量達(dá)到一定程度甩牺，檢查的成本會(huì)變得越來越高戒努。后端開發(fā)接口的過程中匣椰，當(dāng)開發(fā)了第N+1個(gè)接口纷跛，需要保證前N個(gè)接口仍然運(yùn)行正常邀杏，因此需要對(duì)前N個(gè)接口進(jìn)行測(cè)試（API測(cè)試）望蜡。當(dāng)已開發(fā)的接口達(dá)到一定程度，此時(shí)手工測(cè)試就是一個(gè)很痛苦的過程了。需要耗費(fèi)大量的時(shí)間去測(cè)試過往開發(fā)的接口少欺。
? ? 5.前端的請(qǐng)求中包含的數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)不一定是后端需要的數(shù)據(jù)結(jié)構(gòu)。在前后端開發(fā)同步進(jìn)行時(shí)崎页，前端接入后端的數(shù)據(jù)鞠绰，此時(shí)需要進(jìn)行接口交互。前端的請(qǐng)求可能沒有按照規(guī)則來飒焦，同樣的也會(huì)導(dǎo)致后端無法接收到預(yù)期的數(shù)據(jù)而不能按預(yù)期運(yùn)行蜈膨。當(dāng)發(fā)現(xiàn)此類問題后，需要耗費(fèi)時(shí)間成本和交流成本去修正牺荠。
? ? 6.上線前后無法在短時(shí)間內(nèi)將所有接口都測(cè)試一遍翁巍。項(xiàng)目上線前后都需要一次調(diào)試的過程，但是因?yàn)闀r(shí)間不足休雌，普遍功能覆蓋率不高灶壶，無法在短時(shí)間內(nèi)將所有的接口都檢查一遍（是否存在404,500等影響用戶體驗(yàn)或者影響業(yè)務(wù)的情況）
? ? 7.日常做定期的接口全面覆蓋測(cè)試的成本非常高。在項(xiàng)目上線后或者迭代頻次降低的時(shí)期杈曲，測(cè)試人員可能已經(jīng)在負(fù)責(zé)其他事務(wù)驰凛。這個(gè)時(shí)期容易出現(xiàn)以下問題：日常的全功能覆蓋無人負(fù)責(zé)，即使有人負(fù)責(zé)成本也會(huì)非常高鱼蝉，突發(fā)狀況出現(xiàn)的時(shí)候沒有一個(gè)預(yù)警機(jī)制洒嗤。
? ? 8.項(xiàng)目進(jìn)行迭代或者持續(xù)集成之后，不能保證新功能是否會(huì)影響已有功能的運(yùn)行魁亦。該問題同6
? ? 9.后端開發(fā)人員存在對(duì)測(cè)試依賴的情況渔隶，開發(fā)好的接口交給測(cè)試來測(cè)試。出現(xiàn)這個(gè)情況主要原因是開發(fā)任務(wù)重的時(shí)期洁奈，開發(fā)人員著重開發(fā)接口不愿意去自己進(jìn)行測(cè)試间唉。從而導(dǎo)致測(cè)試人員的工作量抬高。
綜上分析利术，我們公司及同類企業(yè)需要將開發(fā)階段的測(cè)試工作重視起來呈野，而同時(shí)需要滿足以下要求：
? ? ? 1.對(duì)測(cè)試人員的技術(shù)門檻要求不能太高，也不能耗費(fèi)太多的成本聘請(qǐng)?zhí)嗑ㄩ_發(fā)的測(cè)試人員印叁。
? ? ? 2.測(cè)試的過程盡量傻瓜化被冒，盡可能降低測(cè)試的用例錄入成本。
? ? ? 3.能夠有一個(gè)自動(dòng)化的平臺(tái)轮蜕，通過自動(dòng)化平臺(tái)對(duì)項(xiàng)目進(jìn)行批量自動(dòng)化測(cè)試昨悼，并生成報(bào)告（網(wǎng)頁報(bào)告、郵件報(bào)告等）
? ? ? 4.自動(dòng)化平臺(tái)能夠活對(duì)接持續(xù)集成或者其他形式的平臺(tái)跃洛，通過一個(gè)特定的請(qǐng)求發(fā)起測(cè)試率触，并獲得測(cè)試結(jié)果。
? ? ? 5.平臺(tái)能夠?qū)η岸说恼?qǐng)求進(jìn)行測(cè)試汇竭，保證前端請(qǐng)求按照要求的發(fā)送葱蝗。
? ? ? 6.平臺(tái)能夠在前端請(qǐng)求通過的情況下穴张，給前端發(fā)送虛構(gòu)的合法的數(shù)據(jù)。使前端脫離后端依賴两曼。
? ? ? 7.測(cè)試用例能夠用一種靈活的方式實(shí)現(xiàn)數(shù)據(jù)庫存取皂甘。
? ? ? 8.測(cè)試結(jié)果能夠存儲(chǔ)數(shù)據(jù)庫，并能夠進(jìn)行各方面統(tǒng)計(jì)合愈。
二.demo設(shè)計(jì)及開發(fā)
針對(duì)上文所提出的問題叮贩，在本文編寫之前開發(fā)了幾套demo，每個(gè)demo都經(jīng)過了真實(shí)項(xiàng)目的運(yùn)作佛析，并獲得了寶貴的經(jīng)驗(yàn)益老。
demo總共存在三代版本的五套系統(tǒng)：
第一代版本測(cè)試自動(dòng)化引擎：基于mocha.js+supertest.js的接口批量執(zhí)行工具。
該版本的自動(dòng)化測(cè)試引擎的性質(zhì)是工具寸莫，解決了以下問題：
? ? 1.解決了對(duì)特定項(xiàng)目的接口批量測(cè)試的問題捺萌，能夠針對(duì)每個(gè)接口錄入特定的測(cè)試用例并批量執(zhí)行。
? ? 2.解決了友好反饋的問題膘茎。該引擎測(cè)試完成后桃纯，生成.html文件格式的測(cè)試報(bào)告。
? ? 3.采用語義化程度高的斷言庫披坏，例如data.should.be.equal(10),代表：data必須等于10
同時(shí)該版本也存在以下問題：
? ? 1.未能實(shí)現(xiàn)平臺(tái)化态坦，需要執(zhí)行測(cè)試的人員在本機(jī)安裝對(duì)應(yīng)要求的開發(fā)環(huán)境，并且不是每個(gè)終端都能夠正常運(yùn)行該引擎棒拂。
? ? 2.測(cè)試用例維護(hù)成本高伞梯，需要維護(hù)測(cè)試用例的人員具有一定程度的js語言基礎(chǔ)，且測(cè)試用例代碼編寫繁雜帚屉。?
? ? 3.多終端測(cè)試用例不同步谜诫，甚至需要采用git來進(jìn)行同步。因?yàn)闇y(cè)試用例是采用文件流的形式存放攻旦，導(dǎo)致必須采用文件流的協(xié)同方式來維護(hù)各個(gè)終端的測(cè)試用例喻旷。
? ? 4.測(cè)試出現(xiàn)錯(cuò)誤沒有合理的預(yù)警機(jī)制。沒有類似郵件警報(bào)的形式對(duì)測(cè)試系統(tǒng)的錯(cuò)誤進(jìn)行實(shí)時(shí)匯報(bào)牢屋，僅僅只是html文件呈現(xiàn)當(dāng)前測(cè)試結(jié)果且预。
? ? 5.測(cè)試報(bào)告不夠靈活，不能實(shí)現(xiàn)對(duì)不同的情況的統(tǒng)計(jì)烙无。例如：xx接口測(cè)試共出現(xiàn)xx次錯(cuò)誤锋谐，錯(cuò)誤率xx%。
第一代mock服務(wù)工具：基于mock.js+kraken.js的接口數(shù)據(jù)模擬工具
該版本的mock生成工具屬于半平臺(tái)半工具的性質(zhì)皱炉，采用kraken（nodejs）作為接口服務(wù)的模擬器怀估，維護(hù)方式為文件流狮鸭。前端開發(fā)者只需要對(duì)其進(jìn)行發(fā)送特定路徑（事先擬定的）請(qǐng)求合搅，即可獲取到所需要的模擬數(shù)據(jù)多搀。其解決了以下問題：
? ? ? 1.使前端開發(fā)能夠大部分脫離后端進(jìn)行開發(fā)，解決了前后端開發(fā)強(qiáng)依賴問題灾部。
? ? ? 2.當(dāng)出現(xiàn)接口改動(dòng)的時(shí)候康铭，mock能夠相對(duì)起到一個(gè)緩沖的作用，前后端通過mock來快速同步修改赌髓。例如：需求中要求多加一個(gè)share字段从藤，前后端商量完畢后，先行在mock服務(wù)上修改锁蠕，之后前后端開發(fā)人員即可分頭進(jìn)行開發(fā)夷野，改變了以往開發(fā)需要等待后端開發(fā)完畢后再交由前端進(jìn)行對(duì)接，節(jié)約了交流成本荣倾，降低了滯后的風(fēng)險(xiǎn)悯搔。
同時(shí)也存在以下問題：
? ? 1.前端可以對(duì)對(duì)應(yīng)路徑的mock接口隨意發(fā)送數(shù)據(jù)既可以獲取到所需要的數(shù)據(jù)，此處忽略了對(duì)前端的限制舌仍，前端對(duì)接口的請(qǐng)求數(shù)據(jù)不合法的情況下沒有做攔截妒貌，導(dǎo)致接入測(cè)試時(shí)前后端對(duì)接失效，增加了返工的時(shí)間铸豁。
? ? 2.個(gè)別比較需要控制的數(shù)據(jù)在mock中無法直接控制（mock的數(shù)據(jù)是定向隨機(jī)數(shù)據(jù)）灌曙，例如status這個(gè)字段的值有多個(gè)情況，而前端開發(fā)者可能只需要其中一種节芥，可能需要重復(fù)請(qǐng)求非常多次才能獲取到需要的數(shù)據(jù)在刺，增加了開發(fā)的時(shí)間。
? ? 3.mock給出的數(shù)據(jù)中錯(cuò)誤碼是恒等于正常錯(cuò)誤碼的藏古，因此需要異常錯(cuò)誤碼的場(chǎng)景無法mock增炭。
? ? 4.維護(hù)方式為文件流，導(dǎo)致每次有新的接口需要同步到服務(wù)端都要git進(jìn)行協(xié)同拧晕，維護(hù)的成本變得非常高隙姿。
第二代自動(dòng)化測(cè)試服務(wù)：mocha.js+supertest.js+kraken.js+vue.js
這個(gè)版本的自動(dòng)化測(cè)試同樣也屬于半工具半服務(wù)的性質(zhì)，維護(hù)方式同樣是以文件流的形式厂捞，解決了上一代版本的以下問題：
? ? ? 1.該版本解決了上一代未能實(shí)現(xiàn)平臺(tái)化的問題输玷，采用了一個(gè)kraken服務(wù)打造的中間服務(wù)層，vue構(gòu)造的控制臺(tái)向服務(wù)發(fā)送指令即可調(diào)用第一代為基礎(chǔ)的測(cè)試機(jī)進(jìn)行測(cè)試靡馁。
? ? ? 2.通過封裝的shell腳本和js代碼欲鹏，實(shí)現(xiàn)了輸入多條指令即可批量構(gòu)造測(cè)試用例。
? ? ? 3.測(cè)試用例和斷言實(shí)現(xiàn)了傻瓜化臭墨，實(shí)現(xiàn)一條簡(jiǎn)單語法的測(cè)試用例即可檢查多項(xiàng)檢查點(diǎn)赔嚎。解決了對(duì)測(cè)試用例維護(hù)人員的門檻問題。
同時(shí)也發(fā)現(xiàn)了以下問題：
? ? ? 1.該版本的測(cè)試報(bào)告屬于一次性報(bào)告，下次測(cè)試將會(huì)把上次測(cè)試的記錄抹除尤误，無法回看侠畔。
? ? ? 2.測(cè)試用例同步問題未解決，依然需要使用git進(jìn)行協(xié)同损晤。
? ? ? 3.缺乏提醒及警報(bào)機(jī)制软棺，出現(xiàn)問題只有一個(gè)html文檔。
? ? ? 4.維護(hù)麻煩尤勋，每次有新項(xiàng)目必須要新建一個(gè)目錄進(jìn)行維護(hù)喘落。
第二代mock服務(wù)工具：adonis+mock.js:
該版本為過渡版本，系統(tǒng)底層從kraken轉(zhuǎn)向adonis最冰，并增加了部分功能瘦棋。解決了如下問題：
? ? ? 1.增加了post校驗(yàn)工具，前端發(fā)送的請(qǐng)求必須通過校驗(yàn)（事先設(shè)置）才能夠獲取到mock數(shù)據(jù)暖哨。
? ? ? 2.增加了數(shù)據(jù)控制方法兽狭，能夠控制需要控制的數(shù)據(jù)，可直接更改請(qǐng)求返回中的值鹿蜀。
第三代接口雙向服務(wù)平臺(tái)（ATMS）：adonis+supertest+mysql
這個(gè)版本解決了上面大部分問題箕慧，且為以后打下了一個(gè)平臺(tái)的基礎(chǔ)，具有良好的可拓展性茴恰，以后的迭代可以直接在本版本中進(jìn)行優(yōu)化而不是換代颠焦。解決了如下問題：
? ? ? ?1.通過mysql進(jìn)行數(shù)據(jù)維護(hù)，測(cè)試用例及接口信息可通過數(shù)據(jù)庫進(jìn)行存取往枣，解決了平臺(tái)性瓶頸問題伐庭。
? ? ? ?2.優(yōu)化了測(cè)試用例的錄制方法，測(cè)試用例錄制更簡(jiǎn)單分冈。
? ? ? ?3.增加了構(gòu)造表單的功能圾另，可對(duì)需要測(cè)試的接口進(jìn)行表單構(gòu)造（mock），可生成任意結(jié)構(gòu)雕沉，任意長(zhǎng)度的表單數(shù)據(jù)并測(cè)試集乔。
? ? ? ?4.mock和自動(dòng)化測(cè)試合并，一個(gè)測(cè)試用例可同時(shí)維護(hù)mock和自動(dòng)化測(cè)試坡椒，實(shí)現(xiàn)雙向服務(wù)扰路。
? ? ? ?5.繼承了前代的所有特性，并增加了測(cè)試報(bào)告回看功能倔叼。
? ? ? ?6.測(cè)試報(bào)告可郵件分發(fā)汗唱。
? ? ? ?7.增加了單點(diǎn)調(diào)試工具，可單獨(dú)對(duì)一個(gè)接口進(jìn)行測(cè)試丈攒。
? ? ? ?8.可按項(xiàng)目為單位進(jìn)行批量測(cè)試哩罪。
三.同類產(chǎn)品分析
本文編寫之前授霸，對(duì)以下幾款同類產(chǎn)品進(jìn)行了一些分析：
Postman: 一款非常經(jīng)典的接口調(diào)試工具，其帶有一定的測(cè)試自動(dòng)化功能际插，且有非常強(qiáng)大的可模擬所有環(huán)境的終端绝葡，甚至可以無視跨域。
其有以下優(yōu)勢(shì)可以進(jìn)行借鑒：?
? ? ? 1.可自由配置headers腹鹉，可以請(qǐng)求更復(fù)雜的接口。
? ? ? 2.可配置切換環(huán)境敷硅，可以多個(gè)環(huán)境進(jìn)行切換功咒，例如：由開發(fā)環(huán)境切換到生產(chǎn)環(huán)境進(jìn)行回歸測(cè)試。
? ? ? 3.可配置的接口測(cè)試腳本绞蹦，可以測(cè)試更復(fù)雜的接口數(shù)據(jù)力奋。
同時(shí)我們產(chǎn)品也有比其優(yōu)越的點(diǎn)：
? ? ? 1.postman的本質(zhì)是個(gè)工具，同樣的缺乏用例一致性的問題幽七，數(shù)據(jù)同步問題我們產(chǎn)品已經(jīng)解決景殷。
? ? ? 2.自動(dòng)化測(cè)試配置難，需要一個(gè)個(gè)用例寫js代碼澡屡，這個(gè)問題類似我們產(chǎn)品的二代版本猿挚，當(dāng)前已解決。
? ? ? 3.功能僅僅只能做接口調(diào)試驶鹉，不能像我們產(chǎn)品的mock那樣為前端進(jìn)行服務(wù)绩蜻。
? ? ? 4.測(cè)試記錄不保存。postman底層是文件流室埋，并無數(shù)據(jù)庫存儲(chǔ)办绝，因此測(cè)試報(bào)告不能保存。
RAP:由阿里巴巴開發(fā)的接口mock工具姚淆。
我們產(chǎn)品的mock服務(wù)部分參照該產(chǎn)品進(jìn)行開發(fā)孕蝉，它有很不錯(cuò)的項(xiàng)目管理機(jī)制：
它的接口管理功能比較復(fù)雜，mock的語法可讀性不高腌逢，錄入的成本相對(duì)我們產(chǎn)品要高很多降淮。
它不具有接口自動(dòng)化測(cè)試的功能，同時(shí)也不具有單接口調(diào)試的功能搏讶。
RAP具有以下優(yōu)勢(shì)可供我們進(jìn)行參考：
? ? 1.用例錄入可以以表單的形式進(jìn)行錄入骤肛，但是不宜太過于復(fù)雜，維護(hù)性很低窍蓝。
? ? 2.導(dǎo)入功能腋颠，可以降低用例錄入成本。
? ? 3.導(dǎo)出功能吓笙，編寫文檔時(shí)可以用于輔助淑玫。
貝塔貓：一個(gè)相對(duì)成熟的自動(dòng)API測(cè)試平臺(tái)
它可以按照項(xiàng)目進(jìn)行批量測(cè)試，并發(fā)送郵件。
可以繪制項(xiàng)目的缺陷圖表絮蒿，用于統(tǒng)計(jì)尊搬。
可切換測(cè)試環(huán)境，進(jìn)行多環(huán)境測(cè)試土涝。
測(cè)試報(bào)告具有回看功能佛寿。
具有以下優(yōu)點(diǎn)可供我們借鑒：
? ? 1.可對(duì)每個(gè)測(cè)試報(bào)告單獨(dú)設(shè)置郵件發(fā)送地址（我們平臺(tái)采用的是對(duì)管理員進(jìn)行發(fā)送。）
? ? 2.圖表統(tǒng)計(jì)功能但壮，我們目前只有數(shù)據(jù)統(tǒng)計(jì)冀泻，暫無圖表統(tǒng)計(jì)。
? ? 3.測(cè)試接口錄入中蜡饵，錄入數(shù)據(jù)比較自由弹渔，類似postman。
? ? 4.具有可切換環(huán)境的功能溯祸，類似postman肢专。
? ? 5.請(qǐng)求的數(shù)據(jù)結(jié)構(gòu)的錄入難度比較小，可參考表單錄入的方式焦辅。
同時(shí)具有以下問題：
? ? ? 1.不具有先置條件（有些接口需要登錄）
? ? ? 2.用例的的延展性不高博杖，例如：有些接口可能有字段的數(shù)據(jù)不能被限制，或者要求限制必須為某個(gè)數(shù)據(jù)類型筷登。
? ? ? 3.不能構(gòu)造表單欧募，如果表單復(fù)雜或者長(zhǎng)度非常大，需要一條條進(jìn)行錄入仆抵。
? ? ? 4.不具有mock的服務(wù)跟继，不能對(duì)前端進(jìn)行服務(wù)及控制。
? ? ? 5.測(cè)試報(bào)告不穩(wěn)定镣丑，有時(shí)候測(cè)試報(bào)告是一片空白（服務(wù)的bug）舔糖，且測(cè)試報(bào)告的信息不夠友好。例如：不能準(zhǔn)確且友好提示錯(cuò)誤信息莺匠。我們平臺(tái)這點(diǎn)做足了金吗。
? ? ? 6.郵件服務(wù)至今未發(fā)郵件過來，我們平臺(tái)的郵件服務(wù)在測(cè)試完畢后立即發(fā)送趣竣。
? ? 7.不能為持續(xù)集成做拓展摇庙，我們平臺(tái)做了預(yù)留，可通過一條請(qǐng)求讓平臺(tái)自動(dòng)測(cè)試并發(fā)送反饋郵件遥缕。（定時(shí)測(cè)試也不是問題）
四.ATMS的優(yōu)化方向
經(jīng)過以上分析卫袒，ATMS仍有以下問題需要進(jìn)行優(yōu)化：
? ? ?1.可錄入多個(gè)環(huán)境，項(xiàng)目通過環(huán)境進(jìn)行切換单匣，解決多環(huán)境回歸測(cè)試問題夕凝。
? ? ?2.header可配置化宝穗。實(shí)現(xiàn)復(fù)雜接口的測(cè)試。
? ? ?3.開發(fā)一個(gè)可供用例錄入码秉、報(bào)告查看逮矛、歷史查詢、系統(tǒng)配置的控制臺(tái)转砖。
? ? ?4.第三方測(cè)試發(fā)起功能须鼎，實(shí)現(xiàn)一個(gè)請(qǐng)求即可發(fā)起一個(gè)批量測(cè)試，并發(fā)送郵件或者其他形式的反饋府蔗。實(shí)現(xiàn)后可活接持續(xù)集成方案晋控。
? ? ?5.缺陷統(tǒng)計(jì)，實(shí)現(xiàn)基于多個(gè)維度的統(tǒng)計(jì)功能（例：基于接口統(tǒng)計(jì)某接口的測(cè)試記錄礁竞、錯(cuò)誤記錄等。）
? ? ?6.mock服務(wù)需要實(shí)現(xiàn)函數(shù)級(jí)別配置化杉辙，能夠?qū)崿F(xiàn)使用函數(shù)生成更復(fù)雜的和更定制化的mock數(shù)據(jù)模捂，提高前端的運(yùn)用效率。
? ? ?7.定時(shí)測(cè)試配置蜘矢，可控制周期測(cè)試狂男，并發(fā)送測(cè)試反饋。
? ? ?8.拓展：在項(xiàng)目的模型下品腹，再增加一個(gè)模塊的模型岖食，可通過模塊進(jìn)行批量測(cè)試。
? ? ?9.拓展：mock服務(wù)可進(jìn)行數(shù)據(jù)代理舞吭，前端可通過mock服務(wù)要求獲取的是mock數(shù)據(jù)還是真實(shí)數(shù)據(jù)泡垃，如果獲取真實(shí)數(shù)據(jù)，mock服務(wù)向真實(shí)服務(wù)進(jìn)行一次被動(dòng)測(cè)試羡鸥，測(cè)試成功則返回真實(shí)數(shù)據(jù)蔑穴，測(cè)試失敗則反饋。該功能考察中惧浴。
? ? 10.管理員分組存和。
? ? 11.拓展：設(shè)計(jì)復(fù)雜測(cè)試邏輯的錄入方式，在基本測(cè)試之外增加自定義測(cè)試條件衷旅。該功能考察中（安全性問題）
? ? 12.拓展：后期接入微信企業(yè)號(hào)捐腿，在微信端發(fā)起測(cè)試，查看報(bào)表等功能柿顶。
? ? 13.拓展：爬蟲茄袖，可開發(fā)爬蟲對(duì)后端渲染的頁面進(jìn)行抓取、檢查嘁锯。
