架構是什麼，架構有什麼用（轉）

前兩天跟老闆出去做pre-sales. 主要是去賣我們的自動化測試服務，工具用的是HP UFT。做過自動化的人應該知道，UFT在自動化測試領域已經算是最好的工具之一了。客戶是個有技術背景的人，是以不那麼好忽悠。我們準備了一大堆自動化測試優點的幻燈片，他倒好，上來直接問，你們的工具的缺陷有哪些。然後我就開始巴拉巴拉地跟他說有哪些缺點，一發不可收拾的是，每解釋完一個問題，他就會有更多問題。最後口幹舌燥也沒能全部解釋清楚，除了感歎一聲錢不那麼好賺，隻能怪自己不能用英語流利地吹牛逼吧。

其中有一個問題，我回來以後又想了很久。當時他指着我做的POC（Prove of Concept）腳本，問道：”既然record & playback可以做一個腳本，那麼為什麼還需要自動化測試架構呢？” 簡而言之就是，我憑什麼要多花錢買你們的架構？我當時第一反應是，什麼？你在逗我嗎？自動化測試沒架構怎麼做？ 當然我的回答官方的很，主要是從維護，可重用性，易用性地角度去跟他解釋了一遍，他似乎也不是很滿意。

回頭我想了想，到底為什麼我們需要自動化測試架構呢？越想越覺得委屈，因為我想問問各位開發，你們做項目的時候為什麼要用架構呢？那自動化的本質不就是寫程式去測程式嘛，既然開發需要架構，那麼自動化測試為什麼不要呢。

牢騷歸牢騷。認真地查了些資料。

什麼是架構？

架構（Framework）是整個或部分系統的可重用設計，表現為一組抽象構件及構件執行個體間互動的方法;另一種定義認為，架構是可被應用開發者定制的應用骨架。前者是從應用方面而後者是從目的方面給出的定義。可以說，一個架構是一個可複用的設計構件，它規定了應用的體系結構，闡明了整個設計、協作構件之間的依賴關系、責任配置設定和控制流程，表現為一組抽象類以及其執行個體之間協作的方法，它為構件複用提供了上下文(Context)關系。是以構件庫的大規模重用也需要架構。其實目前為止，架構還沒有統一定義，我比較喜歡Ralph Johnson所給出的定義：

一個架構是一個可複用設計，它是由一組抽象類及其執行個體間協作關系來表達的 【Johnson 98】。這個定義是從架構内涵的角度來定義架構的，當然也可以從架構用途的角度來給出架構的定義：一個架構是在一個給定的問題領域内，一個應用程式的一部分設計與實作【Bosch 97】。

為什麼要用架構？

又是一個理所當然的問題。因為軟體系統發展到今天已經很複雜了，特别是伺服器端軟體，涉及到的知識，内容，問題太多。在某些方面使用别人成熟的架構，就相當于讓别人幫你完成一些基礎工作，你隻需要集中精力完成系統的業務邏輯設計。而且架構一般是成熟，穩健的，他可以處理系統很多細節問題，比如，事物處理，安全性，資料流控制等問題。還有架構一般都經過很多人使用，是以結構很好，是以擴充性也很好，而且它是不斷更新的，你可以直接享受别人更新代碼帶來的好處。

為什麼要搭建自動化測試架構？

從前我以為，自動化測試最重要的事情是找對象（Find Test Object）。現在我明白了一個道理，沒有架構的自動化測試是找不到對象的，即使找到了也不會幸福的。就跟現實中，沒有車沒有房的人是很難找到對象的一個道理。

自動化測試的開發，通常是由自動化測試的需求決定的。這個需求主要包括：

自動化測試更便于實施。這個說的是，你寫測試腳本要友善。一個好的自動化測試架構是可以讓不那麼懂技術的人也可以寫自動化測試腳本的，哼。

解決自動化測試腳本本身存在的問題，如異常處理和場景恢複。

測試易于維護。自動化測試項目，基本都是沒有好的管理以及維護，一定是個大坑。我可以很負責地說，自動化測試沒有一年半載，你是看不到産出的。是以管理及維護就成了最重要的事情。而好的架構，可以減少你在管理維護中所投入的人力物力精力。

可重用性。架構的意義之一就在于可重用吧。是以在架構裡，你可以實作一些通用功能，簡化腳本開發過程。

美觀易讀的測試報告。拿UFT來說，它産出的測試報告隻是基于測試腳本的，并沒有那種基于測試集的報告，是以如果你要，測試架構裡可以實作。

還有很多測試需求，我沒辦法一一列舉出來，多數需求我們都可以在測試架構裡去定制。現在可以回答上面那個問題了，record & playback是不會幸福的，你需要自動化測試架構。

請慎重考慮是否需要自動化測試（成本投入高，風險大）

自動化測試是個很傲嬌的東西，它很挑項目。首先項目周期要長，但是需求不會頻繁變更；其次系統中多數對象要可以被識别，并且不存在大量第三方插件。而且你要清楚，你不能指望自動化測試去幫你發現新的bug，自動化測試本身是不具備想象力的（相對于手工測試）。它的優勢在于反複疊代，它的價值産出在于長期的回歸測試，以保證被測産品長期穩定地版本更新。

關于自動化測試的切入點，通常要在完整的系統測試之後才算具備引入自動化測試的基本條件。

目前我所做的自動化測試成功案例，無一不具備良好的管理和優良的測試架構。二者缺一，自動化測試必然成為大坑。

最後，填坑這種事兒，收費可是很貴的~

http://www.cnblogs.com/ryansunyu/p/4080985.html