開發和測試微服務

　　在 Agile Testing Days 2015會議上，來自Redgate軟件的 Jose Lima分享了自己有關開發與測試微服務的經驗。InfoQ有幸對他進行了采訪，主要關于用微服務開發產品的優點和缺點、如何應用微服務提高產品質量、測試微服務和測試人員需要的技能、以及他從開發與測試微服務中學到的經驗和教訓。

　　InfoQ：您能詳細說明采用微服務開發產品的優點和缺點嗎?

　　Lima：首先要指出的是我有關微服務框架的經驗大部分來自為內部客戶開發服務時獲得的。我們唯一可以接觸“顧客”(我在一個內部開發團隊內工作，因此我們的客戶大多數是 Redgate軟件的員工 )的地方是在我們網站內，比如通過訂單查詢。跟優點一樣，也有很多的缺點，但是我們的情況是，在我們大量的成功中有一件事情是每個服務都有的，松散耦合。我們需要集成相當數量的外部服務和應用程序，以便有能力做到這一點，將其看成一個設計原則是一件很棒的事情。

　　我想說的是其中一個缺點可能會影響其性能，比如那些需要接通通道的系統，如果通信時間過長可能會影響其性能。這里我說“可能”是因為它對我們不適用。我曾在 Agile Testing Days的演講中提過，我們不在乎信息經過一段時間達到目的地，但是如果你在一個不同的環境里(比如銀行)，那么你可能需要注意這一點。

　　InfoQ：您有案例說明如何應用微服務提高產品質量?

　　Lima：最好的案例是我們自己訂單查詢時的結賬處理。它不僅僅需要收錢，還需要處理發票、連接授權系統、記錄顧客詳細信息等等。盡管我們還在分離他們的過程中，但是我們已經構建了一個微服務，用于負責訂單完成后標記付款，并且只有付款完成后它才會做另外一件事情。

　　InfoQ：您能描述一下您的團隊如何測試微服務?

　　Lima：這么多年我們的測試方法已經改變了很多，因為我沒有在其他團隊工作過，因此我只能給你提供我看到的現在的測試跟過去測試不同的地方。在我們測試之前我們會花大量的時間跟開發人員、產品擁有者等等進行溝通，有時我們扮演的幾乎就是顧問角色。在我的團隊里，我不是負責寫單元測試和集成測試的人，盡管有時我會被派去審查這些代碼(或者審查任何因此發生改變的代碼)。

　　但是當時為了達到目的我們調整了一些開發原則，我認為與其稱他們為測試改變我覺得開發/工程改變更合適。其中一個案例是我們的一位負責部署產品到生產環境的主管，你最好不要將任何與產品質量無關的事情推給他。在實際技術工作方面，我發現我比以前執行了更多的測試(探索)，因為我不會發現更多愚蠢的錯誤(在我看來多虧了測試改變)，并且可以花更多的時間通過測試學習和研究系統。

　　InfoQ：哪些技能是測試人員為了測試微服務所必須的?

　　Lima：在我的演講中我提到了三種不同的類別。第一是熟練的技術技能，比如自動化環境構建或者學習優秀的持續部署實踐。有些人可能會說自動化測試也是一個必須的技能，盡管我不認同。首先我不信任自動化測試，其次檢查自動化也可以由團隊的其他人完成，而不只是測試人員。根本就沒有自動化測試，但是確實存在自動化檢查——對我而言，測試不僅僅是檢查，并且檢查過程可以實現自動化，但是必須在你研究或者學習了你要檢查的內容和它想要實現什么，你才能正確檢查(自動化或者不是)，檢查執行情況是否跟設計一樣。

　　這么多年來，我的業務分析能力也得到了提高，我發現自己跟利益相關者和產品負責人的溝通越來越多，并能找出更多的信息(盡管我們有專門的 BA可以完成這些工作)，因此我可以更有效率地執行探索性測試。最后，社交技能也是你最應該具備的，并且我的社交技能這些年也得到了提高，因為我每天都將不同的事情進行對比。

　　InfoQ：您能分享一下您在開發和測試微服務中學到的東西嗎?

　　Lima：我想更多的是技術技能的變化，還有態度的變化，因為你可能最終擁有比團隊其他成員更多的服務。每個人都應該承認所有的服務是一個集合而不是個人擁有部分。這允許知識在團隊內均勻傳播，因此讓維修變得更加容易，這樣新服務的構建將來源不同人的豐富經驗。

　　InfoQ：如果人們正在考慮采用微服務，您對他們有什么建議嗎?

　　Lima：我建議人們認真考慮一下這種架構方法的利弊，尋找已經完成這些轉型的公司或者個人，不僅僅是成功轉型的，還包括失敗的。當然，你應該關注實施這種架構方法積極的一面，但是確實有缺點，因此你必須考慮你的環境和這種方法是否比你目前的方法更好，或者其它一些因素。如果你決定實施這種方法，一定要小心，并確保擁有技術熟練的人(正如我前面說的)和愿意忍受這種改變的人。

原文轉自：http://www.infoq.com/cn/news/2015/12/developing-testing-microservices