技術分享 | 想測試入門就必須要懂的軟件開發流程

從事軟件測試行業，每天面對的被測對象都是軟件。如果想要更好的去完成測試工作，首先需要對被測對象，也就是對軟件要有基本的了解。

軟件

與計算機系統操作有關的計算機程序、可能有的文件、文檔及數據。

程序好理解，就是可以操作的產品。比如 wps、微信、QQ、網頁等等這些都是程序。比如說需求文檔、設計文檔、用戶手冊這些東西都屬于文檔。在頁面中展示的，還有用戶輸入的內容這些都是數據。

所以說程序、文檔、數據這三個結合起來，就是完整的軟件。

軟件開發流程的演變

流程的演變其實就是軟件開發模型的演變過程。

軟件開發模型就是在軟件開發當中，逐漸總結了很多的經驗，這些經驗經過提煉總結就變成了開發模型。比如最開始的瀑布模型，后來到了敏捷開發模型，一直發展到現在最火的 DevOps 模型。

下面，分別介紹一下這幾種開發模型。

傳統瀑布模型

瀑布大家都熟悉，水是從上到下的流下來的。那瀑布模型也是一樣，像水流一樣從上往下一步一步進行的。

不管做任何事情，分析的工作是肯定是必不可少的。瀑布模型里面也是這樣，首先要做的就是需求分析。

需求文檔是產品人員從用戶那里了解并搜集到的。了解清楚用戶想要什么之后，再把它細化成為一個文檔。文檔會清楚列出系統大致的大功能模塊，大功能模塊有哪些小功能模塊，并且還列出相關的界面和界面功能。有了這個文檔，產品的 UI 界面、功能就都確定下來了。

需求分析之后就開始做設計，需要設計的包括兩個方面：

界面設計：UI 設計師根據需求設計出來前端界面的一個設計稿

程序設計：設計基本業務處理流程，模塊怎么劃分，接口的規范等等

都設計好了之后，開發人員就可以進入編碼的階段了。

在軟件編碼階段，開發會根據設計好的方案，把這些方案通過代碼去進行實現。

實現就相當于開發的代碼已經實現了需求里面的這些功能了。

實現之后測試人員就可以介入了。這就是瀑布模型的流程，有了代碼，再去做測試。

測試工作完成之后，再發布上線，并且繼續維護產品。

在瀑布模型中，軟件開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結果，當前活動的工作結果需要進行驗證。

瀑布模型是線性模型的一種。它在所有的開發模型當中占有重要的地位，是所有其他模型的一個基礎。其他的模型都是根據這個線性模型演變過來的。

瀑布模型的優點很明顯，開發的各個階段比較清晰，強調早期計劃及需求調查，比較適合需求穩定的產品開發。

但是因為開發模型是線性的，增加了開發的風險，所以早期的錯誤可能要等到開發后期的階段才能發現。

為了解決瀑布模型里面的這些問題，后面又慢慢發展出來了別的開發模型。

敏捷開發模型

敏捷開發模式是一種從 90 年代開始逐漸引起廣泛關注的一些新型軟件開發方法。這種開發模型更適用于需求頻繁變化和需要快速開發的場景。

常見的敏捷開發模型有 XP 和 Scrum，下面分別介紹下這兩種開發模型。

XP 極限編程

XP（eXtreme Programming）是一種近螺旋式的開發方法。它是把復雜的開發過程分解為一個個相對比較簡單的小周期。在每一個周期里面，項目人員和客戶都可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，而且可以根據實際情況及時地調整開發過程。

在上圖中可以看出，極限編程是從 3 個維度去組織開發流程的。

首先是編程方法這個維度。在這個緯度當中，對開發人員的開發方法做出了規定。

簡單設計：XP 要求用最簡單的辦法實現每個小需求。這些設計只要能滿足客戶在當下的需求就可以了，不需做更高深的設計，這些設計都將在后續的開發過程中可以不斷地調整和優化。

結對編程：指代碼由兩個人一起完成。一個人主要考慮編碼細節。另外一個人主要關注整體結構，不斷的對第一個開發寫的代碼進行評審。

測試驅動開發：測試驅動開發的基本思想就是在開發功能代碼之前，先編寫測試代碼。測試代碼編寫好了之后，再去編寫可以通過測試代碼的功能代碼。這樣就可以讓測試來驅動整個開發過程的進行。這樣做，有助于編寫簡潔可用和高質量的代碼，有很高的靈活性和健壯性。

重構：XP 強調簡單的設計，但簡單的設計并代表是沒有任何結構的流水，也不是缺乏重用性的程序設計。XP 提倡重構代碼，主要是努力減少程序和設計中重復出現的部分，增強程序和設計的可重用性。

小組實踐是從團隊合作的維度去規定工作方法。

代碼集體所有：代碼集體所有意味著每個人都對所有的代碼負責。反過來又意味著每個人都可以更改代碼的任意部分。

編碼標準：因為大家可以都可以改代碼，那開發小組中的所有人都需要遵循一個統一的編程標準。這樣所有的代碼看起來好像是一個人寫的。因為有了統一的編程規范，每個程序員更加容易讀懂其他人寫的代碼，這是實現代碼集體所有的重要前提之一。

穩定高速的步伐：團隊只有持久才有獲勝的希望。可以把項目看作是馬拉松長跑，而不是全速短跑。需要團隊成員保持長期穩定的工作節奏。

持續集成：集成就是要把大家的代碼合并到一起。團隊開發成員需要經常集成它們的工作。每次集成都通過自動化的構建（這其中還包括了自動化測試)來驗證，這樣才能盡快地發現集成錯誤。

隱喻：為了幫助每個人一致清楚地理解要完成的客戶需求、要開發的系統功能，團隊需要用很多形象的比喻來描述系統或功能模塊是怎樣工作的。比如，對于一個搜索引擎，它的系統隱喻可能就是“一大群蜘蛛，在網上四處尋找要捕捉的東西，然后把東西帶回家中。”

最后一個就是發布管理的維度了。交付是把產品交到客戶手上。發布就是把產品上線，讓用戶可以訪問。總體來說，交付和發布都是讓用戶可以拿到產品去使用。

小規模發布：那規模有多小呢？就是每個迭代 1-3 周時間。在每個迭代結束的時候，團隊交付可運行的，經過測試的功能，這些功能可以馬上投入使用。

計劃游戲：預測在交付日期前可以完成多少工作，確定現在和下一步該做些什么。不斷的回答這兩個問題，就是直接服務于如何實施及調整開發過程。

完整的團隊：每一個項目貢獻者都是“團隊”完整的一部分。這個隊伍是圍繞著一個每天和隊伍坐在一起共同工作的商業代表——“客戶”建立起來的。

現場客戶：在 XP 中，“客戶”并不是為系統付賬的人，而是真正使用該系統的人。XP 認為客戶應該時刻在現場解決問題。

從 XP 開發模型可以看出來，里面開發和客戶是占據主導地位的。測試的工作基本都是通過自動化的方式來進行。比如在編碼過程中的測試驅動開發這個環節，還有持續集成中也包含了自動化的測試。總體而言這個開發模型對開發和測試的要求都是非常高的，團隊里面的人必須都有非常高的水平，這個模型才能運轉成功。這是開發小型項目的一個理想狀態下的情況，比較難實現。

SCRUM

在 Scrum 模型里面，最基本的概念是 Sprint。Sprint 其實就是一個沖刺，通俗一點來說就是一個迭代周期。

整個項目開始之前，會先有一個產品 Backlog。使用產品 Backlog 來管理產品的需求的。它是整個項目的概要文檔。Backlog 是一個按照商業價值排序的需求列表，列表條目的體現形式通常為用戶故事。

Scrum 團隊從產品 Backlog 中挑選最高優先級的需求進行開發。挑選的需求在 Sprint 計劃會議討論。

在 Sprint 上經過討論、分析和估算得到相應的任務列表，可以稱為 Sprint Backlog。

Scrum 中，整個開發過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個 Sprint，每個 Sprint 的建議長度是二至四周。

在每個迭代周期中，Scrum 團隊會舉行每日站會。在每日站會上檢驗 Sprint 目標的進展，做出調整，從而優化次日的工作。

每個迭代結束時，Scrum 團隊將遞交潛在可交付的產品增量。

在每個迭代周期最后，需要進行一次 Sprint 評審會議，讓團隊向產品負責人和利益相關者展示已完成的功能。

Sprint 評審會議結束之后，下一個 Sprint 計劃會議之前，需要進行 Sprint 回顧會議。回顧會議是要找出 Sprint 過程中，哪些地方執行的很好，哪些地方執行的不好，團隊可以做哪些改進。

這就整個 SCRUM 模型的工作流程。在每一個 Sprint，也就是一個迭代周期中，其實是一個小的瀑布。在每個迭代周期中，都會完成一個從需求分析 - 設計 - 編碼 - 測試 - 上線這樣的完整流程。不同的迭代周期可能是部分重合的。比如說第一個迭代周期進行到了測試階段，第二個迭代周期的需求分析可能已經開始了。這樣不停的循環迭代往下進行。

DevOps開發模型

DevOps（Development 和 Operations 的組合詞），它涉及軟件在整個開發生命周期中各個階段。

DevOps 是非常關注開發（Dev）、運維（Ops）、以及測試人員之間溝通合作的一個開發模型。

在 DevOps 里，是通過自動化的軟件交付的流程，來讓構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。

它的出現其實就是因為現在的軟件需要更加快速的上線，如果想實現每天都能上線新功能。但是敏捷開發模型，它再快也得一周的時間，實現不了這個需求。所以大家意識到了，為了能夠更加快捷的上線，開發、測試和運維工作必須緊密合作。所以說 DevOps 更適合使用在需求頻繁變化、開發、測試運維都需要敏捷的場景下。

DevOps生命周期

下面來看看 DevOps 模型中又包含了哪些階段。

這是 DevOps 生命周期中軟件不斷開發的階段。與瀑布模型不同的是，軟件可交付成果被分解為短開發周期的多個任務節點，在很短的時間內開發并交付。

這個階段包括計劃、編碼和構建階段

計劃階段：可以使用一些項目管理工具，比如 JIRA 來管理整個項目

編碼階段：可以使用 Git 或者 SVN 來維護不同版本的代碼

構建階段：使用打包工具，比如 Maven 工具，把代碼打包到可執行文件中

在這個階段，開發出來的軟件會被持續地進行測試。

對于持續測試，可以使用一些自動化測試工具，比如說 Selenium、Appium。Selenium 是做 web 自動化的工具，Appium 是做 app 自動化的工具。自動化的工具還需要配合測試框架一起去使用，比如 Java 中的 TestNG、JUnit，python 中的 unittest、pytest。有了這些自動化測試的工具，就可以持續的對開發出來的軟件進行測試了。

在這個階段，使用 Docker 容器實時模擬“測試環境”也是非常方便的。

一旦新提交進來的代碼測試通過，就會不斷地與現有代碼進行集成。這就是持續集成的過程了。

這個時候可以使用 Jenkins，這是現在最流行的持續集成的工具。使用 Jenkins，可以從 Git 庫提取最新的代碼，并生成一個構建，最終可以部署到測試或生產服務器。

還可以把 Jenkins 設置成發現 Git 庫里有新提交的代碼，就可以自動觸發新構建，也可以在單擊按鈕時手動觸發一個新的構建。有了 Jenkins 這款利器，就可以非常方便的完成持續集成的工作。

持續集成完成之后，就可以直接把代碼部署到各種環境中。在這個階段，需要保證只有通過了持續測試的正確代碼，才能被部署到服務器上。

因為如果上線了新功能，產品就會有更多用戶去使用。這樣的話，運維人員可能還需要擴展服務器來容納更多用戶。如果可以實現持續部署，就可以通過配置管理工具快速、頻繁地執行部署任務。讓產品能夠更快的和用戶見面。這就打通了開發、測試到上線的一個快速通道。

在這個階段，容器化工具 Docker 也發揮著重要作用。它可以幫助保持各種環境是一致的。比如說測試環境、生產環境等等這些，因為環境的不同也可能會導致一些 Bug 出現。

部署上線之后，就到了持續監控的階段。這是 DevOps 生命周期中非常關鍵的階段。通過線上的監控可以幫助提高軟件的質量，監控軟件的性能。

這里也會涉及運營團隊的參與，他們也會監控用戶在使用產品過程中的一些錯誤行為，為以后需求的進一步優化提供數據支持。

在這個階段，可以使用 ELK Stack。這是一個搜集線上數據，并且分析展示的平臺。通過這個工具可以自動的去搜集用戶的動作，產品的一些線上的 bad case，通過分析這些數據，可以為產品將來的發展方向做出指導。

上面這些內容就是 DevOps 整個的生命周期。

獲取更多相關資料：請添加vx,ceshiren001

https://qrcode.ceba.ceshiren.com/link?name=article&project_id=qrcode&from=hwyun×tamp=1651023852

軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。