本文節(jié)選自霍格沃茲測試學(xué)院內(nèi)部教材

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

軟件

與計算機(jī)系統(tǒng)操作有關(guān)的計算機(jī)程序、可能有的文件、文檔及數(shù)據(jù)。

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

所以說程序、文檔、數(shù)據(jù)這三個結(jié)合起來，就是完整的軟件。

軟件開發(fā)流程的演變

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

軟件開發(fā)模型就是在軟件開發(fā)當(dāng)中，逐漸總結(jié)了很多的經(jīng)驗，這些經(jīng)驗經(jīng)過提煉總結(jié)就變成了開發(fā)模型。比如最開始的瀑布模型，后來到了敏捷開發(fā)模型，一直發(fā)展到現(xiàn)在最火的 DevOps 模型。

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

傳統(tǒng)瀑布模型

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

需求分析

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

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

設(shè)計

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

• 界面設(shè)計：UI 設(shè)計師根據(jù)需求設(shè)計出來前端界面的一個設(shè)計稿

• 程序設(shè)計：設(shè)計基本業(yè)務(wù)處理流程，模塊怎么劃分，接口的規(guī)范等等

都設(shè)計好了之后，開發(fā)人員就可以進(jìn)入編碼的階段了。

編碼

在軟件編碼階段，開發(fā)會根據(jù)設(shè)計好的方案，把這些方案通過代碼去進(jìn)行實現(xiàn)。

實現(xiàn)

實現(xiàn)就相當(dāng)于開發(fā)的代碼已經(jīng)實現(xiàn)了需求里面的這些功能了。

測試

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

發(fā)布維護(hù)

測試工作完成之后，再發(fā)布上線，并且繼續(xù)維護(hù)產(chǎn)品。

特點

在瀑布模型中，軟件開發(fā)的各項活動嚴(yán)格按照線性方式進(jìn)行，當(dāng)前活動接受上一項活動的工作結(jié)果，當(dāng)前活動的工作結(jié)果需要進(jìn)行驗證。

瀑布模型是線性模型的一種。它在所有的開發(fā)模型當(dāng)中占有重要的地位，是所有其他模型的一個基礎(chǔ)。其他的模型都是根據(jù)這個線性模型演變過來的。

瀑布模型的優(yōu)點很明顯，開發(fā)的各個階段比較清晰，強(qiáng)調(diào)早期計劃及需求調(diào)查，比較適合需求穩(wěn)定的產(chǎn)品開發(fā)。

但是因為開發(fā)模型是線性的，增加了開發(fā)的風(fēng)險，所以早期的錯誤可能要等到開發(fā)后期的階段才能發(fā)現(xiàn)。

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

敏捷開發(fā)模型

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

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

XP 極限編程

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

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

編程方法

首先是編程方法這個維度。在這個緯度當(dāng)中，對開發(fā)人員的開發(fā)方法做出了規(guī)定。

• 簡單設(shè)計：XP 要求用最簡單的辦法實現(xiàn)每個小需求。這些設(shè)計只要能滿足客戶在當(dāng)下的需求就可以了，不需做更高深的設(shè)計，這些設(shè)計都將在后續(xù)的開發(fā)過程中可以不斷地調(diào)整和優(yōu)化。

• 結(jié)對編程：指代碼由兩個人一起完成。一個人主要考慮編碼細(xì)節(jié)。另外一個人主要關(guān)注整體結(jié)構(gòu)，不斷的對第一個開發(fā)寫的代碼進(jìn)行評審。

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

• 重構(gòu)：XP 強(qiáng)調(diào)簡單的設(shè)計，但簡單的設(shè)計并代表是沒有任何結(jié)構(gòu)的流水，也不是缺乏重用性的程序設(shè)計。XP 提倡重構(gòu)代碼，主要是努力減少程序和設(shè)計中重復(fù)出現(xiàn)的部分，增強(qiáng)程序和設(shè)計的可重用性。

小組實踐

小組實踐是從團(tuán)隊合作的維度去規(guī)定工作方法。

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

• 編碼標(biāo)準(zhǔn)：因為大家可以都可以改代碼，那開發(fā)小組中的所有人都需要遵循一個統(tǒng)一的編程標(biāo)準(zhǔn)。這樣所有的代碼看起來好像是一個人寫的。因為有了統(tǒng)一的編程規(guī)范，每個程序員更加容易讀懂其他人寫的代碼，這是實現(xiàn)代碼集體所有的重要前提之一。

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

• 持續(xù)集成：集成就是要把大家的代碼合并到一起。團(tuán)隊開發(fā)成員需要經(jīng)常集成它們的工作。每次集成都通過自動化的構(gòu)建（這其中還包括了自動化測試)來驗證，這樣才能盡快地發(fā)現(xiàn)集成錯誤。

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

交付和管理

最后一個就是發(fā)布管理的維度了。交付是把產(chǎn)品交到客戶手上。發(fā)布就是把產(chǎn)品上線，讓用戶可以訪問?？傮w來說，交付和發(fā)布都是讓用戶可以拿到產(chǎn)品去使用。

• 小規(guī)模發(fā)布：那規(guī)模有多小呢？就是每個迭代 1-3 周時間。在每個迭代結(jié)束的時候，團(tuán)隊交付可運行的，經(jīng)過測試的功能，這些功能可以馬上投入使用。

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

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

• 現(xiàn)場客戶?：在 XP 中，“客戶”并不是為系統(tǒng)付賬的人，而是真正使用該系統(tǒng)的人。XP 認(rèn)為客戶應(yīng)該時刻在現(xiàn)場解決問題。

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

SCRUM

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

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

Scrum 團(tuán)隊從產(chǎn)品 Backlog 中挑選最高優(yōu)先級的需求進(jìn)行開發(fā)。挑選的需求在 Sprint 計劃會議討論。

在 Sprint 上經(jīng)過討論、分析和估算得到相應(yīng)的任務(wù)列表，可以稱為 Sprint Backlog。

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

在每個迭代周期中，Scrum 團(tuán)隊會舉行每日站會。在每日站會上檢驗 Sprint 目標(biāo)的進(jìn)展，做出調(diào)整，從而優(yōu)化次日的工作。

每個迭代結(jié)束時，Scrum 團(tuán)隊將遞交潛在可交付的產(chǎn)品增量。

在每個迭代周期最后，需要進(jìn)行一次 Sprint 評審會議，讓團(tuán)隊向產(chǎn)品負(fù)責(zé)人和利益相關(guān)者展示已完成的功能。

Sprint 評審會議結(jié)束之后，下一個 Sprint 計劃會議之前，需要進(jìn)行 Sprint 回顧會議?；仡檿h是要找出 Sprint 過程中，哪些地方執(zhí)行的很好，哪些地方執(zhí)行的不好，團(tuán)隊可以做哪些改進(jìn)。

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

DevOps開發(fā)模型

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

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

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

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

DevOps生命周期

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

持續(xù)開發(fā)

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

這個階段包括計劃、編碼和構(gòu)建階段

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

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

• 構(gòu)建階段：使用打包工具，比如 Maven 工具，把代碼打包到可執(zhí)行文件中

持續(xù)測試

在這個階段，開發(fā)出來的軟件會被持續(xù)地進(jìn)行測試。

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

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

持續(xù)集成（CI）

一旦新提交進(jìn)來的代碼測試通過，就會不斷地與現(xiàn)有代碼進(jìn)行集成。這就是持續(xù)集成的過程了。

這個時候可以使用 Jenkins，這是現(xiàn)在最流行的持續(xù)集成的工具。使用 Jenkins，可以從 Git 庫提取最新的代碼，并生成一個構(gòu)建，最終可以部署到測試或生產(chǎn)服務(wù)器。

還可以把 Jenkins 設(shè)置成發(fā)現(xiàn) Git 庫里有新提交的代碼，就可以自動觸發(fā)新構(gòu)建，也可以在單擊按鈕時手動觸發(fā)一個新的構(gòu)建。有了 Jenkins 這款利器，就可以非常方便的完成持續(xù)集成的工作。

持續(xù)部署

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

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

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

持續(xù)監(jiān)控

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

這里也會涉及運營團(tuán)隊的參與，他們也會監(jiān)控用戶在使用產(chǎn)品過程中的一些錯誤行為，為以后需求的進(jìn)一步優(yōu)化提供數(shù)據(jù)支持。

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

上面這些內(nèi)容就是 DevOps 整個的生命周期。