軟體開發過程自動化原理及技術（完整樣本）

標籤：

軟體開發過程自動化原理及技術一個簡單完整的自動化樣本1   概述

關於本文，最開始只是想寫一些關於 軟體自動化測試開發 的文章，但是後來寫著寫著，發現不先在宏觀上的軟體開發過程進行介紹，不會引起大家對 自動化 技術形成瞭解和重視。所以本文從軟體工程宏觀層次進行了介紹，並和傳統的實現方法做了一些對比，並附了一些代碼，讓有興趣的朋友對自動化的理念及具體的實現技術手段有一些初步的認識。

既然是要 自動化 那麼肯定就是衝著 效率 來的。在正式開始系統化的自動化技術學習之前，先來一個完整的樣本來有個對 自動化 的概念整體認識。

2   使用情境

可以先定義一個最簡單的情境：提供第三方前端js庫的產品（例如： jQuery）。

使用過 jQuery 的人，可以很清楚這樣的產品具有如下的特徵：

• 靜態檔案支援CDN方式的線上引用，可以不必下載成離線檔案
• js檔案後面有版本號碼標識
• 靜態檔案是增量式發布，而非覆蓋替換式

下面是一些jquery的備忘，方便讀者瞭解前面所談到的一些特點的具體表現形式。

jQuery 的CDN線上引用的方式

<script src="https://code.jquery.com/jquery-2.1.4.min.js"></script>

每個 jQuery 的庫檔案都帶有版本號碼，例如： jquery-2.1.4.min.js

如果有新的檔案版本發布，則增加一個帶新版本號碼的檔案即可。

基本上這樣的產品的開發和上線的步驟如下：

1. 開發工程師本地開發好js項目，並做好單元測試和功能性自測
2. 使用構建工具打包成js檔案（為簡化問題，此處假設最終只有一個檔案）
3. 發布工程師收到構建好的檔案，向公網上發布靜態檔案
4. 檢查靜態檔案是否成功部署成功且能正常被公網訪問

3   傳統方案

在前面所定義的步驟裡面，傳統的方案就是：

1. 開發人員開發完畢，並進行簡單自測，和 手動 功能測試

2. 開發人員利用IDE 手動 打包

3. 發布工程師將構建後的檔案 手動 複製到公網伺服器指定目錄

4. 發布工程師在瀏覽器裡面  手動 輸入檔案的公網連結，確定可以訪問到相應的資源

   有可能出現公網檔案許可權或者伺服器配置問題，導致即使檔案在那個位置，但是不一定能夠訪問到。比如出現 403forbidden 的情況

這樣的過程都是要通過程式員去手動完成，在現在講究快速迭代的軟體研究趨勢下，長期這樣手動重複的後果就是：

1. 一直手工操作導致效率低下
2. 重複工作會扼殺人的創造性

對於會持續做加法迭代的有穩定產品線路的項目，最好還是能夠做自動化的的操作，一方面是為瞭解放程式員，另外一方面也確實提升效率以適應現在的快速開發和迭代的客觀需求。

4   自動化方案4.1   自動化單元測試

其實開發人員在開發過程，就是為了讓程式能夠達到預期的目標，那麼就肯定是存在一定的自測過程。但是僅僅是當時自測之後是不行，還需要對於核心的演算法函數進行單元測試代碼的編寫，以保證後續的迭代和重構的時候，不會出現拆東補西的情況。

此時的情況是：

• 核心函數---- 自動化 單元測試
• 介面功能---- 手動 功能性自測

一般情況，功能測試都特指 端到端 的直接面向使用者的介面型測試，由於介面存在太多的不確定性，這一塊不是適合編寫自動化測試代碼的，雖然對於介面的自動化已經有一部分的指令碼錄製工具或者開發工具，但是都不提倡。

注意

自動化測試涉及到自動化代碼的編寫，這部分的額外付出成本是在 迴歸測試 的時候收回的，迴歸的次數越多，邊際成本就越小。所以只有相當穩定下來的功能才有迴歸的價值。

由於目前很多產品的開發，都不再是獨立的系統，都往往會存在一些外部調用的介面，所以在自動化打包構建之前，還要在測試環境下進行介面測試。此處的在做自動化方案的時候，基本原理和單元測試差不多，所以本文略去不表，後面會專門有專門介紹自動化測試部分的內容。

4.2   自動化打包構建

有相當多的IDE提供了一些打包的可視化操作工具。但是這些工具需要人工在IDE裡面根據嚮導，進行一步步地點擊操作，這樣的做的好處就是降低了打包構建的門檻，普通人也可以在不瞭解原理，不用編寫構建代碼的情況下，也能完成相應的構建工作。當然缺點就是： 無法實現無人值守的自動化。

基本上現在各種語言都有自己相應的成熟的構建工具，本文所舉的前端的開發的例子，就有 grunt 這樣的打包構建工具。

可以完成的自動化任務有：

• 去除掉js源碼裡面的注釋
• 壓縮js
• 混淆js
• 合并檔案

通過寫好相應的設定檔，運行grunt的相應參數命令，可以很好地實現開發構建階段的自動化工作流程。

4.3   自動化發布

自動化發布的具體實現技術手段有很多種。

像指令碼型的語言（php,python,nodejs）可以使用 Git 這樣的版本管理工具，使用調用shell命令，或者第三方操作庫（例如python語言的Gitpython）可以實現代碼的自動化部署。

對於一些構建的產物本身是很大的二進位檔案的，比如exe檔案，或者Android的apk應用，動轍是幾百M的，顯然不適合使用Git這樣的精細化的版本管理工具來進行發布。可以使用FTP或者SSH的第三方編程介面進行自動化的發布。此處可以推薦一款基於python的三方擴充 fabric,可以完成檔案的遠程傳輸及遠端的伺服器的命令列操作。

本文的的jQuery靜態js發布方案使用整體檔案上傳到公網伺服器的方式(使用fabric工具)，以基本的流程如下：

• 掃描自動化構建的目錄
• 使用fabric上傳檔案到N台指定的伺服器的相應目錄
• 使用fabric操控N台伺服器設定靜態檔案的許可權

以下是一段程式碼範例（將本地的某個目錄下的檔案上傳分發到N台伺服器，並進行簡單的設定）：

#!coding:utf8"""自動上傳檔案到靜態伺服器上,和測試伺服器上面"""from __future__ import with_statementimport sysimport osfrom fabric.api import lcdfrom fabric.operations import put, runfrom dtlib.dtlog import dlogserver_folder_path = ‘/static_folder‘local_folder_path = server_folder_pathuser_name = ‘xxx‘#伺服器登入使用者名稱server_ssh_pwd = ‘xxxxxxxx‘#伺服器登入密碼lcoal_dirlist = []#所有的需要上傳檔案的伺服器的登入資訊列表server_list = [    # (host,user,password)    (‘192.168.1.201‘, user_name, server_ssh_pwd),    (‘xxx.xxx.xxx.xxx‘, user_name, server_ssh_pwd)]def scandir():    """    上傳本地某個目錄到伺服器的指定目錄    :return:    """    list = os.listdir(local_folder_path)    for i in list:        dirpath = os.path.join(local_folder_path, i)        if os.path.isdir(dirpath):            lcoal_dirlist.append(i)    dlog.debug(lcoal_dirlist)    for j in lcoal_dirlist:        dlog.debug("subdir:" + j)        with lcd(local_folder_path):            run(‘uname -s‘)            put(j, server_folder_path, use_sudo=True)  # 上傳本地檔案到伺服器端    # 在遠程機器上批量修改檔案許可權    run(‘chmod a+rw %s/js/jquery-2.1.4.min.js‘ % (server_folder_path))  # 修改檔案許可權為可讀寫    run(‘cp %s/js/jquery-2.1.4.min.js %s/js/jquery-2.1.4.min.js‘ % (server_folder_path,                                                                    server_folder_path))    print ‘%s has synced‘ % jif __name__ == ‘__main__‘:    currentpath = sys.path[0]    for item in server_list:        fab_cmd = ‘fab  -f scp_static.py -H %s -u %s -p %s scandir‘ % (item[0], item[1], item[2])        dlog.debug(fab_cmd)        os.system(fab_cmd)

4.4   自動化檢測發布結果

關於指定的版本的靜態檔案是否發布成功，最後還需要一道檢測，才能實現 閉環。當然，根據不同的要求，檢測的用例也會不同。一般情況下，如果前面的流程都比較規範，此處就不太需要對功能進行太多檢測了，但是需要對發布結果進行檢測：檢測指定版本的js是否能夠成功被公網訪問。

一般人可能不太理解，之前不是已經完成發布了麼，此處為何還要多此一舉？經驗告訴我們，一個 開環 的系統的結果往往是存在不可預知的，往往是不可信的。特別是在遠程發布的時候，網路環境穩定性、伺服器的硬體配額（磁碟容量已滿）、web伺服器配置（許可權問題）都會成為發布失敗的原因。只有形成 閉環 才會形成可靠的交付。

發布的目的不是執行發布的流程，而是最終能夠讓開發產出物能夠提供正常的服務。

關於 jQuery 是否發布成功，本文設計了兩個測試案例：

• 能夠Http請求到正常的js源碼
• jQuery的頭部資訊裡面支援跨域

手工的檢測方式是在瀏覽器輸入連結：

https://code.jquery.com/jquery-2.1.4.min.js

觀看瀏覽器的顯示結果。

顯然：

• 瀏覽器的內容框裡面顯示了正常的返回了js的內容

• 瀏覽器的調試框裡面也可以看到頭部資訊裡面是支援跨域的

  當然此處還是使用了稍微進階的資料層面的檢測方式，如果不瞭解http的原理，可能還會專門做一個測試頁面，看能夠正常載入到js檔案。

這樣太耗時，所以本文推薦自動化的方案。上面的手式的方式，其實本質上就是利用瀏覽器對指定的http連結發起請求，然後用眼睛來判斷返回的資料結果，這一切都可以通過程式來實現。

做自動化的首要本領就是要會 透過現象看本質 ，即 透過介面看資料，以上兩個用例的主要的技術原理：

• 請求js資源，Http返回的狀態代碼是200。當然如果要更精細化，可以對其返回內容做進一步嚴格的判斷。
• Http的要求標頭部資料裡面的 access-control-allow-origin 欄位的值為 * （星號萬用字元）

下面貼上一段python的 pyunit 架構下的自動化檢測代碼：

# coding:utf-8"""測試靜態伺服器檔案是否發布成功"""import requestsimport unittest__author__ = ‘Harmo‘class StaticServerTest(unittest.TestCase):    """ 靜態檔案請求    """    def setUp(self):        pass    def tearDown(self):        pass    def test_jquery_js_release(self):        """http是否正常返回        :return:        """        test_js_url = ‘https://code.jquery.com/jquery-2.1.4.min.js‘        res = requests.get(test_js_url)        self.assertEqual(200, res.status_code, msg=‘檢查是否正常返回‘)    def test_http_static_allow_origin(self):        """http下不應該支援跨域        :return:        """        test_js_url = ‘https://code.jquery.com/jquery-2.1.4.min.js‘        res = requests.get(test_js_url)        self.assertNotEquals(‘*‘, res.headers["access-control-allow-origin"], msg=‘http不允許跨域‘)

上面的代碼是兩個小的自動化測試案例，為了作為對比，特意 做了一個運行成功的例子（成功請求到檔案）和一個運行失敗的檢測例子（要求檔案支援跨域，其實jquery是應該支援跨域引用的）。

為了簡單起見，在IDE下面運行此測試代碼並查看結果：

檢測伺服器上面的靜態庫檔案是否載入成功。 當然，正常的結果應該是這樣全成功的狀態：

如果檢測通過，那麼就證明是成功發布了。

5   總結

本文的目的是為了說明什麼叫自動化及自動化的好處，前面所介紹的內容的範圍並不局限於“測試自動化”，但是最後的落腳點還是要到 自動化測試 及現在進階的 測試 職責：持續整合。

自動化測試 還有如下一些需要深入研究的地方：

• 對不同的測試案例進行資料的抽象化，以達到自動化實現的目的

  這需要比較紮實的電腦的基礎知識

• 能夠通過程式碼群組織好成規模（比如幾千幾萬）的自動化測試指令碼

  這個就需要一定的軟體工程基礎和系統開發能力

• 能夠掌握和其它系統整合的能力以達到持續整合的全自動化軟體生產過程

這些技能也不是此處簡單的隻言片語就能道盡的，本文只能作為一個引子來進行後續內容的預熱吧。

持續整合 也是建立在前面所介紹的各個環節形成自動化之後，然後再使用一定的技術手段，將這一系列事件進行被扣，來觸發下一事件，從而環環相扣，形成穩定的軟體生產自動化 流水線。形成持續穩定的軟體交付物。

至於 持續整合 的好處，可以使用一個製造業的例子來描述：

1913年,福特將 流水線 應用到汽車組裝中，第一條流水線使每輛T型汽車的組裝時間由原來的12小時28分鐘縮短至10秒鐘，生產效率提高了4488倍！

在現代軟體工業領域也需要這樣：先自動化，然後持續整合，才可以實現快速迭代，以產生巨大的生產力，符合現代人對軟體工程的預期。希望相關從業人員一起努力吧，提升自己的知識結構的競爭力，也提升整體的行業的生產力。

（未完，待續。。。）

作者:	Harmo哈莫
作者介紹:	https://zhengwh.github.io
技術部落格:	http://www.cnblogs.com/beer
Email:	[email protected]
QQ:	1295351490
時間:	2015-11
著作權聲明:	歡迎以學習交流為目的讀者隨意轉載，但是請 【註明出處】
支援本文:	如果文章對您有啟發，可以點擊部落格右下角的按鈕進行 【推薦】

軟體開發過程自動化原理及技術（完整樣本）