|
測試的完整流程/過程 Hello~大家好，我是祁麗蕊，主要負(fù)責(zé)智家平臺服務(wù)端測試工作。今天我要和大家分享 的是智家平臺服務(wù)端測試的完整流程。 其實(shí)測試流程這個(gè)描述不夠準(zhǔn)確，在國際軟件測試委員會(huì)的大綱中，把這個(gè)測試的過程和步驟叫做測試過程（test process ）。 這個(gè)測試過程并不是固定的，它只是一種規(guī)范，也可以把它當(dāng)作一種指導(dǎo)。 但在實(shí)際的產(chǎn)品和項(xiàng)目測試中，一定要靈活運(yùn)用，甚至是需要根據(jù)實(shí)際情況不斷變化和調(diào)整的。 下面開始介紹智家平臺服務(wù)端測試的完整過程，也就是測試人員拿到一個(gè)需求該怎么開展測試工作。 總體來看，共有6大步： 測試計(jì)劃，測試設(shè)計(jì)，測試開發(fā)，測試執(zhí)行，質(zhì)量評估，功能發(fā)布 第一步：制定測試計(jì)劃 要制定測試計(jì)劃，那首先就要了解需求： （1）需求分析，也可以說是文檔評審，哪些文檔呢？ 需求文檔、開發(fā)文檔 ① 需求文檔 在系統(tǒng)開始開發(fā)之前，要進(jìn)行需求評審，說是評審，實(shí)際上主要是需求講解。 給開發(fā)們講解業(yè)務(wù)、我們要做什么東西、為什么這么做、要做成什么樣子。 從這個(gè)環(huán)節(jié)開始，測試人員就該介入。因?yàn)樾枨笪臋n是測試人員測試的唯一標(biāo)準(zhǔn)！ 在后續(xù)測試過程中，如果開發(fā)做出來的東西和需求文檔中寫的、畫的不一樣，都屬于bug! 所以，嚴(yán)格來說，測試人員在測試時(shí)只認(rèn)文檔不認(rèn)人。 那可能有人會(huì)說，那這樣測試人員就沒有必要參加評審了，直接等文檔不就好了。 其實(shí)不是，那我說下 測試人員參加需求評審的必要性: 1. 測試人員也需要了解和學(xué)習(xí)相關(guān)的業(yè)務(wù)知識 2. 測試人員需要知道產(chǎn)品最終的上線目標(biāo)是什么，來判斷什么時(shí)候能達(dá)到交付的程度。 3. 測試人員可憑經(jīng)驗(yàn)對需求文檔中的部分設(shè)計(jì)提出不同的意見。 4. 測試人員可憑經(jīng)驗(yàn)對需求文檔中沒有涉及到的一些異常情況和特殊場景進(jìn)行討論。 5. 提出疑問點(diǎn)，以保證產(chǎn)品、研發(fā)、測試對需求的理解一致。 ② 開發(fā)文檔 需求文檔定型后，研發(fā)負(fù)責(zé)人會(huì)根據(jù)需求文檔來編寫開發(fā)文檔。 開發(fā)文檔的內(nèi)容大概包括：代碼架構(gòu)、代碼規(guī)范、接口規(guī)范、數(shù)據(jù)庫設(shè)計(jì)..... 為什么測試要參加開發(fā)文檔的評審？（其實(shí)主要是去聽） 1. 測試人員需要了解系統(tǒng)的基本架構(gòu)和實(shí)現(xiàn)原理，方便分析問題原因 2. 測試人員需要了解數(shù)據(jù)庫表結(jié)構(gòu)，對后續(xù)的測試很有必要 3. 測試人員可以提出一些規(guī)范性的要求，便于后續(xù)測試 4. 測試人員可以發(fā)現(xiàn)代碼中缺少對某些異常場景的邏輯判斷 （2）制定測試計(jì)劃 需求明確后，就可以制定測試計(jì)劃，測試計(jì)劃的內(nèi)容包括： 測試范圍是什么， 分哪些階段， 什么時(shí)間點(diǎn)完成什么， 測試的具體內(nèi)容列表（流程、功能、接口）..... 測試計(jì)劃是測試人員的工作量評估，是績效考核的重要依據(jù)，也是測試人員的工作守則和規(guī)范。 但在產(chǎn)品的誕生過程中，免不了出現(xiàn)各種各樣的特殊情況，所以實(shí)際的測試可能會(huì)跟計(jì)劃有所出入。 所以測試報(bào)告中需要寫明與測試計(jì)劃產(chǎn)生偏差的原因，分析偏差的風(fēng)險(xiǎn)。 第二步：測試設(shè)計(jì)（很重要） 第三步：測試開發(fā) 第四步：測試執(zhí)行 1. 單元測試（又叫組件測試 component testing） 單元測試其實(shí)在平時(shí)比較少做，并不是因?yàn)樗恢匾驗(yàn)閱卧獪y試就是代碼級別的測試。關(guān)注點(diǎn)在 可單獨(dú)測試的組件。 簡單的舉個(gè)例子，現(xiàn)在開發(fā)新增了一個(gè)方法。 單元測試就是要寫一個(gè)測試類或測試方法，調(diào)用開發(fā)的新增方法，并且在調(diào)用過程中模擬一些異常情況或者傳輸錯(cuò)誤的值。 所以單元測試一般由開發(fā)人員來完成， 測試人員也可以去做，但是首先測試人員要有一定的編碼能力并能搭建開發(fā)環(huán)境，其次測試人員需要去理解和分析開發(fā)的相關(guān)代碼，甚至是要了解和學(xué)習(xí)相關(guān)架構(gòu)。 綜上所述，由開發(fā)人員來進(jìn)行單元測試，要更加便捷和高效，更節(jié)約成本，幾乎是舉手之勞。而且能培養(yǎng)開發(fā)自測的良好習(xí)慣，關(guān)注代碼質(zhì)量的重要性。 2. 集成測試（integration testing）、系統(tǒng)測試（system testing） ① 集成測試 重點(diǎn)是測試各模塊的接口，也就是組件或系統(tǒng)之間的交互。 與組件測試一樣，在某些情況下，自動(dòng)化集成的回歸測試可以增強(qiáng)信心，因?yàn)榧词巩a(chǎn)品有變更也不會(huì)破壞已有的接口、組件或系統(tǒng) 。 ② 系統(tǒng)測試 側(cè)重于整個(gè)系統(tǒng)或產(chǎn)品的行為和能力 ，通常會(huì)考慮系統(tǒng)可開展的端到端任務(wù)和開展這些任務(wù)時(shí)所展現(xià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ì)將測試環(huán)境包括數(shù)據(jù)庫移交給開發(fā)，用來復(fù)現(xiàn)相關(guān)問題，并查找問題原因。 開發(fā)提交新一輪測試后，測試人員重新搭建環(huán)境進(jìn)行測試。 3. 確認(rèn)測試 修復(fù)缺陷后， 一定要在最新版本上，重新執(zhí)行之前因該缺陷而導(dǎo)致失敗的測試用例 。目的是確認(rèn)是否已成功修復(fù)原來的缺陷。 4. 回歸測試 部分代碼所做的變更， 無論是修復(fù)代碼，還是其他類型的更改，都可能會(huì)意外地 影響到除更改代碼外的其他部分代碼的行為，不管是在同一組件內(nèi)，還是在同一系統(tǒng)的其他組件中，甚至在其他系統(tǒng)中。 變更也可能包括環(huán)境的變化 ，例如操作系統(tǒng)或數(shù)據(jù)庫管理系統(tǒng)的新版本。回歸測試的目的是運(yùn)行測試來檢測這些意外的副作用。 第五步、質(zhì)量評估 第六步、功能發(fā)布
|
|
|
