1. 程式人生 > >初窺項目構建

初窺項目構建

修改 時間短 團隊 程序 快速 是什麽 新的 頻率 cat

原文出自:

http://www.cnblogs.com/Ribbon/archive/2015/05/22/4517125.html

1.項目構建基本流程

  • 開發人員在他們的個人計算機上編寫源代碼文件
  • 他們將編寫好的文件存放在一個統一集中的地方,構建組將所有的源代碼編譯成可以在計算機上運行的二進制文件,且用安裝工具把各種需要安裝到服務器上的文件包裝成可以安裝到不同平臺的軟件包。
  • 組合成一個產品

構建的過程就好比一個組裝生產線,源代碼文件就像是各種大小配件,被存儲在一個大倉庫裏,源代碼中,有些在構建過程中還需要再加工。

2.構建過程

技術分享

3. 構建生產線時,軟件開發部門,特別是構建測試團隊需要考慮什麽?

  a. 儲存源代碼的“倉庫”
  b. 可以反復生產的“流水線”
  c. 快速簡單的測試以保證產品可以更全面深入地測試和利用系統備份技術來分享測試環境

4. 源代碼是構建過程的基礎,如何將源代碼放入安全可靠的地方?

  一般來講,源代碼會被存放在數據庫裏,運用版本控制系統管理源代碼。

5. 版本控制系統概述

  它用來幫助我們記錄文件更改的過程及細節,一般基於客戶端/服務端結構,可以同時為多個開發人員提供服務。

技術分享

6. 版本控制系統的功能有哪些?

  創建新文件、提取文件、存入新版本文件、協調或控制多人對同一個文件的同時修改、記錄文件的修改歷史且供查詢。

7. 構建產品的前提是什麽?

  建立構建的環境。

8. 在建立構建的環境時需要考慮哪些因素?

  a. 選擇構建使用的服務器
  b. 選擇構建環境平臺
  c. 構建所需要的軟件或工具

9. 軟件開發流程:

  a. 開發人員編寫軟件代碼,將源代碼交給構建組進行構建
  b. 構建組將源代碼文件做成可以安裝的軟件產品,再交給測試組進行測試
  c. 測試組將測試時發現的問題反饋給開發組
  d. 開發組修改代碼,再將修改後的代碼交給構建組來進行新版本的構建

技術分享

10. 在設計構建的過程時,一般還要考慮到整體構建及部分構建的需要,設計部分構建邏輯的關鍵是?

  每個源代碼文件與構建步驟時間的關系,一般版本控制系統都支持查詢階段間源代碼文件的變化,這保證了部分構建的可行性。

11. 自動化部分構建過程:

技術分享

12. 部分構建組合的好處有哪些?

  a. 如果有關源代碼自上一次構建沒有改變,構建可以被跳過,使整體構建時間縮短
  b. 部分構建之間如果沒有前後順序的關系,可以讓它們同時運行來縮短構建的時間
  c. 部分構建所產生的二進制代碼可以直接應用到測試環境來快速檢驗新的產品功能,測試若通過,部分構建代碼會進入下一個版本的測試產品

13. 如何避免讓構建過程稱為開發的瓶頸?

  縮短構建時間和減少構建過程中的問題,如實施自動化構建。

14. 自動化構建的好處?

  a. 保證軟件開發過程中能定制比較靈活的構建時間表
  b. 確保每一次構建過程的一致性,沒有因為認為的錯誤而引入產品的缺陷

15. 自動化構建程序的一般性原則:

  a. 在源代碼文件改變時,不需要構建程序的改變,即使有不可避免的改變,也應使改變過程盡量容易、簡單
  b. 避免把輸出或輸入的相關參數直接寫死在構建代碼中,這樣,在構建的環境改變時不需要改變構建程序
  c. 經常需要改變的一些變量采用屬性文件統一管理,需要改變時只需修改屬性文件中的參數值(如*.properties文件,或者*.xml文件)
  d. 使用Template文件和XSLT,在構建運行時依據構建需要生成構建程序文件,減少在更改構建程序文件方面的投入

16. 軟件構建的頻率如何確定?

  根據軟件測試的需要來確定。在敏捷開發模型的環境下,提供頻繁的測試產品非常關鍵。最大可能地保證構建的頻率是軟件敏捷開發模型中的一個很必要的保證。

17. 什麽是構建測試?--Build Verification Test

  構建測試也稱為構建可接受性測試(Build Acceptance Test),一般是在每一個測試產品生成之後,由構建測試團隊執行一組最基本的測試用例,來確定做成的測試產品的質量是否達到可以交到各個測試組來進行更全面、更深入的各項測試的要求。

如無大的問題,就可以進行相應的功能測試。BVT優點是時間短,驗證了軟件的基本功能。缺點是該種測試的覆蓋率很低。因為運行時間短,不可能把所有的情況都測試到。BVT測試也被稱為“冒煙測試”。

  構建測試主要從功能的角度對構建測試產品進行驗證,構建測是成功執行時其他測試開始的前提條件,高效的構建測試可以提高整個團隊的測試效率。

18. 構建測試的測試用例是如何選擇的?

  構建測試的測試用例基本都是功能測試用例,相對比較簡短,應著重於產品的最基本、最重要的功能,選擇原則:

    a. 只測試最重要,最基本的功能
    b. 只測試已經測試過且相對穩定的用例

19. 構建測試有什麽作用?

  a. 讓開發人員馬上知道新版本的源代碼是否可以被成功地構建成軟件產品
  b. 幫助測試團隊避免把時間浪費在不穩定的或者根本不工作的測試產品上

20. 構建測試的步驟:

  a. 安裝測試產品及需要的其他軟件
  b. 進行產品所需要的系統配置
  c. 測試幾個最基本的產品功能

21. 構建測試的內容?

  構建測是還包括對構建過程本身的檢驗,主要內容包括:

    a. 確認構建是否包括了源代碼文件新的改變
    b. 檢驗構建的日誌是否有報錯
    c. 最後產品文件的大小是否有異常等

22. 構建測試示意圖:

技術分享

23. 構建測試環境時的步驟?

  a. 采用一些能實現系統配置自動化的工具,作為構建測是的一部分,自動安裝所有構建測是需要的軟件。
  b. 使用一些系統備份和恢復工具:
    i. 備份安裝好的構建測試所需軟件的系統
    ii. 備份構建環境本身

24. 構建測試的目的是什麽?

  檢驗測試產品構建過程是否成功完成,構建出的產品是否具有可測性。

25. 什麽是靜態測試?

  靜態測試針對源文件直接做測試分析,發現問題,適用於在源文件中就能發現問題的情形。

26. 常見的靜態測試用例有哪些?

  語法及拼寫檢驗,網頁親和力檢驗,Java/Java EE最佳實踐或用戶化的規則檢驗

27. 全自動靜態測試示意圖:

技術分享

初窺項目構建