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

其實測試的過程并不是固定的仁堪，它只是一種規(guī)范，也可以把它當作一種指導(dǎo)填渠。但是真實的產(chǎn)品測試和項目測試中弦聂，一定是要靈活運用的，甚至是在不斷的根據(jù)實際情況變化氛什。我在其他平臺莺葫、app上討論軟件測試時，經(jīng)常提到：項目測試和 產(chǎn)品測試一定是不一樣的枪眉。

　　產(chǎn)品測試一定有非常完整的發(fā)版計劃捺檬，有充足的的時間，有充足的資源進行協(xié)調(diào)贸铜，即使因為一些特殊的原因未能按時完成發(fā)版計劃堡纬，也可以進行延期。所以產(chǎn)品測試都會盡量的去進行完成的全級別測試蒿秦。

　　項目測試一般時間都非常緊烤镐，資源有限，發(fā)生意外的情況很多棍鳖，任務(wù)時間都是被極度壓縮炮叶。到目前為止我經(jīng)歷過大大小小幾十個項目，沒有一個是能按計劃時間充足的上線渡处。所以項目測試一般會大量的精簡測試過程镜悉，甚至為了按時上線做出一些犧牲，犧牲掉一些不重要的功能医瘫，來優(yōu)先保證 重點功能侣肄、常用功能。

　　一登下、文檔評審

　　首先是需求文檔

在系統(tǒng)開始開發(fā)之前茫孔，產(chǎn)品經(jīng)理會根據(jù)收集到的用戶意見和最終方案編寫需求文檔，編寫完成后被芳，要進行需求文檔評審缰贝；說是評審，實際上主要是需求講解畔濒。給開發(fā)們講解業(yè)務(wù)知識剩晴、我們要做什么東西、為什么這么做、要做成什么樣子赞弥。從這個環(huán)節(jié)開始毅整，測試人員就應(yīng)該介入進來。

　　因為需求文檔是測試人員測試的唯一標準绽左！

將來做測試的時候悼嫉，如果開發(fā)做出來的東西和需求文檔里寫的、畫的不一樣拼窥，都屬于BUG戏蔑！如果開發(fā)說是需求改了或者說是產(chǎn)品經(jīng)理說的，那么抱歉鲁纠，請修改需求文檔总棵！所以，嚴格來說改含，測試人員在測試時只認文檔不認人情龄。可能有人會說捍壤，那這樣測試人員就沒必要參加評審了骤视，直接等文檔就行。

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

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

　　2.測試人員需要知道產(chǎn)品最終的上線目標是什么尚胞，來判斷什么時候能達到交付的程度。

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

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

　　然后是開發(fā)文檔

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

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

為什么測試要參加開發(fā)文檔的評審橄碾？其實主要是去聽測試人員需要了解系統(tǒng)的基本架構(gòu)和實現(xiàn)原理卵沉，方便分析問題原因：

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

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

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

　　最后是測試計劃

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

　　測試計劃的內(nèi)容包括：測試范圍是什么艰猬、分為哪些階段、什么時間點完成什么埋市、測試的具體內(nèi)容列表（流程冠桃、功能、接口）道宅、測試資源的成本（人/天）等等食听。

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

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

所以測試報告中需要寫明與測試計劃產(chǎn)生偏差的原因省咨，并計算變差量肃弟，分析偏差的風(fēng)險。

　　最終的測試過程和測試結(jié)果還是以 測試報告 為準零蓉。

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

單元測試其實在平時比較少做，并不是因為它不重要敌蜂，因為單元測試就是代碼級別的測試箩兽。組件測試（也稱為單元或模塊測試）關(guān)注在可單獨測試的組件。組件測試的目標包括：

　　1.降低風(fēng)險

　　2.驗證組件的功能和 非功能行為是否符合設(shè)計和規(guī)定

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

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

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

　　簡單的舉個例子章喉，現(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ā)人員來進行單元測試，要更加便捷和高效髓需，更節(jié)約成本许师，幾乎是舉手之勞。而且能培養(yǎng)開發(fā)自測的良好習(xí)慣，關(guān)注代碼質(zhì)量的重要性微渠。

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

　　在開發(fā)人員進行開發(fā)的這個階段，測試人員無法對產(chǎn)品直接進行測試逞盆，工作任務(wù)較輕可以安排測試人員進行測試用例的編寫檀蹋。

對于一些緊急的項目，可以引進敏捷測試云芦。敏捷測試是最近幾年比較流行的測試方法俯逾，也擁有了眾多的擁護者。還引出了一個測試思想——測試驅(qū)動開發(fā)（TDD ）這個概念有時間我單拎出來寫舅逸。

　　敏捷測試的最大特點是高頻率的快速迭代桌肴，幾乎是一天一個迭代版本，甚至是一天多個版本琉历。

　　敏捷測試是遵循敏捷宣言的一種測試實踐：

　　1.強調(diào)從客戶的角度坠七，即從使用系統(tǒng)的用戶角度，來測試系統(tǒng)旗笔。

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

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

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

這種測試非成喑考驗測試人員的抗壓、責(zé)任心忿薇、領(lǐng)導(dǎo)力和溝通協(xié)調(diào)能力裙椭。

　　但是敏捷測試也有很多的缺點，在這里我只談自己的感受署浩，如果有不對的地方可以留言和我討論：

　　測試人員工作壓力大揉燃，休息時間少，幾乎沒有喘息的時間筋栋。

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

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

　　開發(fā)無法按照bug等級來確定工作優(yōu)先級迈倍，因為可能在改一個中等bug伤靠，突然來了嚴重bug，也得等上一個bug改完的啼染。

需求改動頻繁宴合，可能昨天做的功能或者做一半的功能突然就舍棄掉了。所以我們正常的測試中一般不會去做敏捷測試迹鹅，但是有些公司比較推崇卦洽。

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

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

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

　　1.減少風(fēng)險

　　2.驗證接口的功能和非功能行為是否符合設(shè)計和規(guī)定

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

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

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

　　與組件測試一樣脂新，在某些情況下，自動化集成的回歸測試可以增強信心粗梭，因為即使產(chǎn)品有變更

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

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

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

　　1.減少風(fēng)險。

　　2.驗證系統(tǒng)的功能和非功能行為是否按照設(shè)計和指定的要求進行驗證系統(tǒng)的功能和非功能行為是否按照設(shè)計和指定的要求進行鉴嗤。

　　3.確認已完成系統(tǒng)成且系統(tǒng)按預(yù)期工作確認已完成系統(tǒng)成且系統(tǒng)按預(yù)期工作斩启。

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

　　5.發(fā)現(xiàn)缺陷發(fā)現(xiàn)缺陷醉锅。

　　6.防止缺陷遺漏到更高的測試級別或生產(chǎn)防止缺陷遺漏到更高的測試級別或生產(chǎn)兔簇。一般情況下，系統(tǒng)測試的測試環(huán)境應(yīng)該與集成測試的相同硬耍。

　　我為什么把集成測試和系統(tǒng)測試放在一起垄琐，因為我們在做測試的時候，經(jīng)常是集成測試和系統(tǒng)測試同時進行经柴。

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

　　所以我們通常是直接進行集成和系統(tǒng)測試坯认，也就是全用例翻擒、全流程氓涣、全功能、全接口的測試陋气。測試環(huán)境由測試人員進行搭建劳吠，盡量與生產(chǎn)環(huán)境一致。

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

　　一輪結(jié)束后會將測試環(huán)境包括數(shù)據(jù)庫移交給開發(fā)，用來復(fù)現(xiàn)相關(guān)問題晶渠，并查找問題原因凰荚。開發(fā)提交新一輪測試后，測試人員重新搭建環(huán)境進行測試褒脯。

　　五便瑟、驗收測試（acceptance testing）

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

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

　　驗收測試的目標包括：

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

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

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

　　六践啄、其他（確認測試、回歸測試）

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

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

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

　　回歸測試的目的是運行測試來檢測這些意外的副作用羊初。