其實(shí)測試的流程這個描述不夠準(zhǔn)確，

在國際軟件測試委員會的大綱《ISTQB認(rèn)證測試工程師_FL大綱-2018版_V3_1》中，

把這個測試的過程和步驟叫做 測試過程（test process ）

它又牽扯到 測試活動 和 測試策略 的概念

?國際軟件測試認(rèn)證委員會 2018 版

盡管沒有統(tǒng)一的軟件測試過程，但是有一些常見的測試活動，如果沒有這些測試活動就不太可能實(shí)現(xiàn)既定的目標(biāo)。這些測試活動就組成了一個測試過程。

在任何給定的情況下，適當(dāng)?shù)?、特定的軟件測試過程取決于很多因素。

測試過程中涉及哪些測試活動，如何實(shí)施這些測試活動，以及何時(shí)開始這些測試活動，都可以測試過程中涉及哪些測試活動，如何實(shí)施這些測試活動，以及何時(shí)開始這些測試活動，都可以在組織的測試策略中進(jìn)行討論。在組織的測試策略中進(jìn)行討論。

感興趣的朋友可以去查一下測試過程、測試活動、測試策略的相關(guān)概念。

為了方便大家理解，我就統(tǒng)為測試過程。

前言：測試的過程并不是固定的，要靈活的變化

言歸正傳，其實(shí)這個測試的過程并不是固定的，它只是一種規(guī)范，也可以把它當(dāng)作一種指導(dǎo)。

但是真實(shí)的產(chǎn)品測試和項(xiàng)目測試中，一定是要靈活運(yùn)用的，甚至是在不斷的根據(jù)實(shí)際情況變化

我在其他平臺、app上討論軟件測試時(shí)，經(jīng)常提到：項(xiàng)目測試 和 產(chǎn)品測試 一定是不一樣的

產(chǎn)品測試一定有非常完整的發(fā)版計(jì)劃，有充足的的時(shí)間，有充足的資源進(jìn)行協(xié)調(diào)，

即使因?yàn)橐恍┨厥獾脑蛭茨馨磿r(shí)完成發(fā)版計(jì)劃，也可以進(jìn)行延期。

所以產(chǎn)品測試都會盡量的去進(jìn)行完成的全級別測試。

項(xiàng)目測試一般時(shí)間都非常緊，資源有限，發(fā)生意外的情況很多，任務(wù)時(shí)間都是被極度壓縮

到目前為止我經(jīng)歷過大大小小幾十個項(xiàng)目，沒有一個是能按計(jì)劃時(shí)間充足的上線。

所以項(xiàng)目測試一般會大量的精簡測試過程，甚至為了按時(shí)上線做出一些犧牲，

犧牲掉一些不重要的功能，來優(yōu)先保證 重點(diǎn)功能、常用功能。

一、文檔評審

首先是 需求文檔，

在系統(tǒng)開始開發(fā)之前，產(chǎn)品經(jīng)理會根據(jù)收集到的用戶意見和最終方案編寫需求文檔

編寫完成后，要進(jìn)行需求文檔評審；

說是評審，實(shí)際上主要是需求講解。

給開發(fā)們講解業(yè)務(wù)知識、我們要做什么東西、為什么這么做、要做成什么樣子。

從這個環(huán)節(jié)開始，測試人員就應(yīng)該介入進(jìn)來。

因?yàn)樾枨笪臋n是測試人員測試的唯一標(biāo)準(zhǔn)！

將來做測試的時(shí)候，如果開發(fā)做出來的東西和需求文檔里寫的、畫的不一樣，都屬于BUG！

如果開發(fā)說是需求改了或者說是產(chǎn)品經(jīng)理說的，那么抱歉，請修改需求文檔！

所以，嚴(yán)格來說，測試人員在測試時(shí)只認(rèn)文檔不認(rèn)人。

可能有人會說，那這樣測試人員就沒必要參加評審了，直接等文檔就行。

測試人員參加需求文檔的評審的必要性：

測試人員也需要了解和學(xué)習(xí)相關(guān)的業(yè)務(wù)知識。

測試人員需要知道產(chǎn)品最終的上線目標(biāo)是什么，來判斷什么時(shí)候能達(dá)到交付的程度。

測試人員可以憑借經(jīng)驗(yàn)對需求文檔中的部分設(shè)計(jì)提出不同的意見。

測試人員可以憑借經(jīng)驗(yàn)對需求文檔中沒有涉及到的一些異常情況和特殊場景進(jìn)行討論。

然后是 開發(fā)文檔

需求文檔定型之后，開發(fā)經(jīng)理會根據(jù)需求文檔來編寫開發(fā)文檔。

開發(fā)文檔的內(nèi)容大概包括：開發(fā)模型、代碼架構(gòu)、代碼規(guī)范、接口規(guī)范、數(shù)據(jù)庫設(shè)計(jì)…

為什么測試要參加開發(fā)文檔的評審？（其實(shí)主要是去聽）

測試人員需要了解系統(tǒng)的基本架構(gòu)和實(shí)現(xiàn)原理，方便分析問題原因

測試人員需要了解數(shù)據(jù)庫表結(jié)構(gòu)，對后續(xù)的測試很有必要

測試人員可以提出一些規(guī)范性的要求，便于后面的測試。（比如要求前端人員盡量給所有前端組件加上id或name屬性，方便自動化測試時(shí)定位元素）

測試人員可以發(fā)現(xiàn)代碼中缺少對某些異常場景的邏輯判斷。

最后是 測試計(jì)劃，

測試計(jì)劃是測試人員的工作量預(yù)估，也是將來測試人工作考核績效的重要依據(jù)。

測試計(jì)劃的內(nèi)容包括：測試范圍是什么、分為哪些階段、什么時(shí)間點(diǎn)完成什么、測試的具體內(nèi)容列表（流程、功能、接口）、測試資源的成本（人/天）等等。

測試計(jì)劃是測試人員的工作守則和規(guī)范。

但是產(chǎn)品的誕生過程中，免不了出現(xiàn)各種各樣的特殊情況，所以實(shí)際的測試可能會跟測試計(jì)劃有所出入。

所以測試報(bào)告中需要寫明與測試計(jì)劃產(chǎn)生偏差的原因，并計(jì)算變差量，分析偏差的風(fēng)險(xiǎn)。

最終的測試過程和測試結(jié)果還是以 測試報(bào)告 為準(zhǔn)。

二、單元測試（又稱組件測試 component testing）

單元測試其實(shí)在平時(shí)比較少做，并不是因?yàn)樗恢匾?，因?yàn)閱卧獪y試就是代碼級別的測試

組件測試（也稱為單元或模塊測試）關(guān)注在可單獨(dú)測試的組件。組件測試的目標(biāo)包括：

降低風(fēng)險(xiǎn)

驗(yàn)證組件的功能和 非功能行為是否符合設(shè)計(jì)和規(guī)定

建立對組件質(zhì)量的信心

發(fā)現(xiàn)組件中的缺陷

防止缺陷遺漏到更高的測試級別

簡單的舉個例子，現(xiàn)在開發(fā)做了一個新增的方法

單元測試就是要寫一個測試類或測試方法，調(diào)用開發(fā)的新增方法（新增肯定還要傳值），并且在調(diào)用過程中模擬一些異常情況或者傳輸錯誤的值

所以單元測試一般由開發(fā)人員來完成，

測試人員也可以去做，但是首先測試人員需要有一定的編碼能力并搭建開發(fā)環(huán)境，其次測試人員需要去理解和分析開發(fā)的相關(guān)代碼，甚至是要了解和學(xué)習(xí)相關(guān)架構(gòu)

現(xiàn)在成熟的開發(fā)框架已經(jīng)自帶的很多測試的組件和工具，以Springboot為例，

可以直接導(dǎo)入測試依賴包

<dependency>

? ? <groupId>org.springframework.boot</groupId>

? ? <artifactId>spring-boot-starter-test</artifactId>

? ? <scope>test</scope>

</dependency>

使用idea自動創(chuàng)建測試類,也可以自己手動創(chuàng)建

寫測試類

@RunWith(SpringRunner.class)

@SpringBootTest

public class TestImpl2Test {

@Autowired

@Qualifier(“testImpl2”)

ITestServer iTestServer;

@Test

public void test(){

iTestServer.showClassName();

}

}

綜上所述，由開發(fā)人員來進(jìn)行單元測試，要更加便捷和高效，更節(jié)約成本，幾乎是 舉手之勞

而且能培養(yǎng)開發(fā)自測的良好習(xí)慣，關(guān)注代碼質(zhì)量的重要性

三、敏捷測試(Agile testing)（可選）

在開發(fā)人員進(jìn)行開發(fā)的這個階段，測試人員無法對產(chǎn)品直接進(jìn)行測試，工作任務(wù)較輕

可以安排測試人員進(jìn)行測試用例的編寫。

對于一些緊急的項(xiàng)目，可以引進(jìn)敏捷測試。

敏捷測試是最近幾年比較流行的測試方法，也擁有了眾多的擁護(hù)者。

還引出了一個測試思想——測試驅(qū)動開發(fā)（TDD ）

這個概念有時(shí)間我單拎出來寫。

敏捷測試的最大特點(diǎn)是高頻率的快速迭代，幾乎是一天一個迭代版本，甚至是一天多個版本。

敏捷測試是遵循敏捷宣言的一種測試實(shí)踐：

1、強(qiáng)調(diào)從客戶的角度，即從使用系統(tǒng)的用戶角度，來測試系統(tǒng)。

2、重點(diǎn)關(guān)注持續(xù)迭代地測試新開發(fā)的功能，而不再強(qiáng)調(diào)傳統(tǒng)測試過程中嚴(yán)格的測試階段。

3、建議盡早開始測試，一旦系統(tǒng)某個層面可測，比如提供了模塊功能，就要開始模塊層面的單元測試，同時(shí)隨著測試深入，持續(xù)進(jìn)行回歸測試保證之前測試過內(nèi)容的正確性。

這種高頻率的迭代測試，可以極大地提升產(chǎn)品成型的速度，bug能在最短時(shí)間內(nèi)被處理。

這種測試非?？简?yàn)測試人員的抗壓、責(zé)任心、領(lǐng)導(dǎo)力和溝通協(xié)調(diào)能力。

但是敏捷測試也有很多的缺點(diǎn)，

在這里我只談自己的感受，如果有不對的地方可以留言和我討論：

測試人員工作壓力大，休息時(shí)間少，幾乎沒有喘息的時(shí)間。

不同版本的bug管理比較混亂，驗(yàn)證起來需要梳理清楚，最好是借助專業(yè)的管理工具。

bug反復(fù)性高，可能在短時(shí)間內(nèi)甚至不會出現(xiàn)bug逐步下降的正常趨勢，而是產(chǎn)生較大的波動。

開發(fā)無法按照bug等級來確定工作優(yōu)先級，因?yàn)榭赡茉诟囊粋€中等bug，突然來了嚴(yán)重bug，也得等上一個bug改完的。

需求改動頻繁，可能昨天做的功能或者做一半的功能突然就舍棄掉了

所以我們正常的測試中一般不會去做敏捷測試，但是有些公司比較推崇

四、集成測試（integration testing）、系統(tǒng)測試（system testing）

集成測試的重點(diǎn)就是測試各模塊的接口，也就是組件或系統(tǒng)之間的交互。

集成測試側(cè)重于集成測試的目標(biāo)包括：

減少 風(fēng)險(xiǎn)

驗(yàn)證接口的功能和非功能行為是否符合設(shè)計(jì)和規(guī)定

建立對接口質(zhì)量的信心

發(fā)現(xiàn)缺陷（ 可能存在于接口本身，也可能存在于組件或系統(tǒng)內(nèi)部

防止缺陷遺漏到更高的測試級別

與組件測試一樣，在某些情況下，自動化集成的回歸測試可以增強(qiáng)信心，因?yàn)榧词巩a(chǎn)品有變更

也不會破壞已有的接口、組件或系統(tǒng) 。

系統(tǒng)測試側(cè)重于整個系統(tǒng)或產(chǎn)品的行為和能力 ，通常會考慮系統(tǒng)可開展的端到端任務(wù)和開展這些任務(wù)時(shí)所展現(xiàn)的非功能行為。

系統(tǒng)測試的目標(biāo)包括：

減少風(fēng)險(xiǎn)

驗(yàn)證系統(tǒng)的功能和非功能行為是否按照設(shè)計(jì)和指定的要求進(jìn)行驗(yàn)證系統(tǒng)的功能和非功能行為是否按照設(shè)計(jì)和指定的要求進(jìn)行

確認(rèn)已完成系統(tǒng)成且系統(tǒng)按預(yù)期工作確認(rèn)已完成系統(tǒng)成且系統(tǒng)按預(yù)期工作

建立對整個系統(tǒng)質(zhì)量的信心建立對整個系統(tǒng)質(zhì)量的信心

發(fā)現(xiàn)缺陷發(fā)現(xiàn)缺陷

防止缺陷遺漏到更高的測試級別或生產(chǎn)防止缺陷遺漏到更高的測試級別或生產(chǎn)

一般情況下，系統(tǒng)測試的測試環(huán)境應(yīng)該與集成測試的相同。

我為什么把集成測試和系統(tǒng)測試放在一起，因?yàn)槲覀冊谧鰷y試的時(shí)候，經(jīng)常是集成測試和系統(tǒng)測試同時(shí)進(jìn)行。

集成測試意味著開發(fā)已經(jīng)完成所有模塊的開發(fā)，并且對產(chǎn)品有了一定的信心。

所以我們通常是直接進(jìn)行集成和系統(tǒng)測試，也就是全用例、全流程、全功能、全接口的測試

測試環(huán)境由測試人員進(jìn)行搭建，盡量與生產(chǎn)環(huán)境一致。

測試期間測試環(huán)境不允許開發(fā)人員訪問，直到一輪測試結(jié)束。

一輪結(jié)束后會將測試環(huán)境包括數(shù)據(jù)庫移交給開發(fā)，用來復(fù)現(xiàn)相關(guān)問題，并查找問題原因。

開發(fā)提交新一輪測試后，測試人員重新搭建環(huán)境進(jìn)行測試。

五、驗(yàn)收測試（acceptance testing）

驗(yàn)收測試通常側(cè)重于整個系統(tǒng)或產(chǎn)品的行為和功能。

驗(yàn)收測試通常是由客戶、業(yè)務(wù)用戶、產(chǎn)品負(fù)責(zé)人 或系統(tǒng)操作員負(fù)責(zé)，也可能涉及其他利益相關(guān)方 。

驗(yàn)收測試的目標(biāo)包括：

建立對整個系統(tǒng)質(zhì)量的信心

確認(rèn)系統(tǒng) 是否完整 且系統(tǒng)將按預(yù)期工作

驗(yàn)證系統(tǒng)的功能和非功能行為 符合規(guī)范

六、其他（確認(rèn)測試、回歸測試）

確認(rèn)測試：修復(fù)缺陷后， 應(yīng)該在軟件的最新版本上，重新執(zhí)行之前因該缺陷而導(dǎo)致失敗的測試用例 。 為了覆蓋修復(fù)缺陷所 需 的變化， 也可以使用新的測試來測試軟件。至少必須在新的軟件版本上重新執(zhí)行這些由缺陷引起失效的步驟。

確認(rèn)測試的目的是確認(rèn)是否已成功修復(fù)原來的缺陷。

回歸測試： 部分代碼所做的變更， 無論是修復(fù)代碼，還是其他類型的更改，都可能會意外地 影響到除更改代碼外的其他部分代碼的行為，不管是在同一組件內(nèi)，還是在同一系統(tǒng)的其他組件中，甚至在其他系統(tǒng)中。 變更也可能包括環(huán)境的變化 ，例如操作系統(tǒng)或數(shù)據(jù)庫管理系統(tǒng)的新版本。這種意外的副作用被稱為回歸。

回歸測試的目的是運(yùn)行測試來檢測這些意外的副作用。

七、技術(shù)類測（自動化測試、性能測試、接口測試）

上面這些是我的收集和整理，這些資料，對于【軟件測試】的朋友來說應(yīng)該是最全面的倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你

測試資源免費(fèi)領(lǐng)取~~~