1、 軟件的開發階段劃分程序員
一、 需求分析階段面試
由需求分析師完成數據庫
產出物:《需求文檔》瀏覽器
二、 設計階段架構
1) 概要設計分佈式
產出物:《概要說明書》函數
2) 詳細設計工具
產出物:《詳細說明書》性能
通常是由系統架構師(分析師)完成單元測試
三、 編碼階段
程序員
注:通常公司只有產品文檔和原型,,因此若是你的公司這些文檔都有,那麼請珍惜吧。。。。
常見面試題:哪一個階段bug最多?哪一個階段bug最小?
需求分析階段引入的bug最多,其次是設計階段,在編碼階段引入的bug的最少。
因此:
1)測試不能只測程序,文檔也要測。
2)測試工做應該從開發開始就介入,而且應該貫穿整個開發週期始終。
注:身在小公司的我,不得不告訴大家,文檔不須要測,通常是不須要編寫測試用例的(測試我負責),可是咱們得要求本身編寫用例,由於這家公司只是咱們測試路上的路人甲,並非咱們的重點。測試時間短暫,感受領導不過重視,測試可能沒有測完,領導就喊着要上線。我但願從我手上流出去的產品不說完美,可是儘可能沒有那麼多bug,總感受有那麼點憂桑。
2、軟件測試的階段劃分
1、單元測試
1)單元測試是最小的測試單位,通常就是一個功能模塊,一個方法(函數),一個類等
2)單元測試依據的是《詳細設計文檔》 (單元測試是根據詳細設計文檔寫功能)
3)單元測試以白盒測試爲主,可能輔助以黑盒測試
4)單元測試可能要求測試人員編寫驅動模塊和樁模塊
A)驅動模塊:模擬被測模塊的上一級模塊(調用被測模塊的那個模塊)
B)樁模塊:模擬被測模塊的下一級模塊 (被被測模塊調用的那個模塊)
總結:驅動模塊à被測模塊à樁模塊
5)在實際工做中,單元測試每每由程序員完成--(節約成本,可是不嚴格)
2、集成測試
1)集成測試也叫組裝測試,在單元測試的基礎上把軟件的功能模塊逐步合併在一塊兒進行的過程
2)功能合併的過程通常是逐步完成的,會造成不少的臨時的版本
3)集成測試依據的是《概要設計文檔》
4)集成測試階段以黑盒測試爲主,核心模塊適當採用白盒測試。
名詞解釋:冒煙測試(版本驗證測試)使用較少的人(1-3人,經驗豐富)、較少的時間(0.5-2天),對軟件的核心功能進行測試,若是軟件核心功能沒問題,就讓全組投入全面測試,若是問題較多,,版本不穩定,就打回開發組。
5)集成測試中,拿到新的內部版本,基本工做思路:
l 首先要進行冒煙測試(有可能省略),驗證該版本是否能夠接受
l 返測 :對以前的bug,在本版本中解決的,檢查是否經過。
l 迴歸測試 :對上一版本中的全部功能再測試一遍----驗證修改的代碼或新加了功能,之前的功能是否依然正常。
l 對該版本新組裝的功能進行測試 ---- 但若是有些版本只是用於修復之前的bug,也有可能沒有新功能。
3、系統測試
1)整個功能所有組裝完成後,對模擬集成了硬件、軟件的完整系統進行的測試。
2)系統測試的重點在於
A)整個系統在模擬真實環境下是否能夠正確運行
B)系統與硬件、軟件的兼容性問題
3)系統測試的依據是《需求文檔》
4)系統測試所有爲黑盒測試
5)在系統測試以前,通常會安排「確認測試」,主要確認:
A、確認該系統是否進入全面的系統測試階段(能夠理解爲一次大的冒煙測試)
B、確認相關文檔是否準備齊全(尤爲是給用戶的文檔,參與認證的文檔)
說明:確認測試通常時間相對較短,參與的人員較少。因此不把其與單元測試、集成測試、系統測試所並列
四、 用戶驗收階段 --- 驗收測試
UAT(User acceptance Testing)用戶接受度測試
1) 用戶參與的一個檢查過程
2) 能夠分爲兩個小階段:
A)Alpha測試 :在開發環境中,由最終用戶對軟件進行檢查,通常常常由軟件公司代用戶完成。
B)Beta測試 :在用戶的實際環境中,由最終用戶對軟件進行檢查
對於公共類軟件(操做系統,遊戲,輸入法),通常把軟件免費發放給最終用戶,經過用戶使用收集bug ---- 公測版本
3、軟件測試的模型
1、軟件測試模型表達的是測試階段和開發階段的對應關係。
2、兩個常見模型
1)V模型(重點)
A、會畫
B、優缺點
優勢:
(1)開發和測試階段劃分明確,對應關係明確
(2)測試階段既包含單元測試(代碼、專業級)又包含驗收測試(用戶級)
缺點:沒有體現需求、設計階段的文檔測試工做,容易形成誤解,覺得測試工做只是開發完成後的收尾工做
2)W模型(瞭解)
A、能夠理解爲雙V模型,第一個V是開發活動,第二個V是測試活動
B、比V 模型更增強調了文檔測試階段的重要,體現了測試對象不只是程序需求和設計一樣須要測試。測試與開發是同步進行的
C、W模型更符合儘早測試和不斷測試的原則
4、軟件測試的分類
1、按測試技術劃分
1)黑盒測試 :(功能測試的基本特徵)又叫功能測試、數據驅動測試,是不考慮程序內部結構,只需考慮輸入和輸出狀況下進行的功能測試
2)白盒測試 :又稱爲結構測試,基於程序的測試。只考慮程序內部結構,而不去考慮程序功能的測試
3)灰盒測試 :結合黑盒和白盒測試的要素,對軟件進行測試,通常先作黑盒測試,當發現有bug,對bug進行定位,對有可能有問題的代碼再進行白盒測試的過程(在集成測試中常用)
補充說明:
1)測試階段中黑盒測試爲主
2)白盒測試測試經常對風險較大,難度較大的模塊進行測試
3)白盒測試要求測試人員懂得代碼,效率較低,時間成本高
4)白盒測試也須要編寫測試用例
2、按是否須要運行代碼劃分:
1)靜態測試 :不須要運行程序
2)動態測試 :須要運行程序才能進行的測試
黑盒(功能)測試通常都是動態測試
白盒測試即有多是動態的,也有多是靜態的
3) 靜態測試包括:
A、 界面測試 :主要測實際界面與需求要求是否符合
B、 文檔測試 :主要測試文檔和說明是否真正符合
C、 代碼測試 :主要測試代碼是否符合相應的標準和規範
常見問題:靜態的代碼測試和白盒測試的區別:
(1) 白盒測試主要關注代碼的邏輯功能實現,測試者必需要懂代碼,要求寫測試用例
(2) 靜態代碼測試主要關注代碼的規範性、標準性,測試人員不須要懂代碼,不須要寫測試用例,只需參考代碼審查單檢查便可
3、按軟件的特性分類
1)功能測試 :
(1) 任何軟件都必需要作功能測試
(2) 軟件要先作功能測試,保證其功能正確。
分佈式軟件須要在功能正確的前提下,在考慮性能
(3) 功能測試分爲:手工功能測試和功能自動化測試(須要藉助於工具完成)
2)性能測試 :
(1)分佈式(c/s,b/s)須要作性能測試
(2)性能測試只有自動化(要藉助工具完成)
4、其它(常見的名詞術語)
1)返 測 :在新版本中對程序員修改的bug進行測試,驗證bug是否被修改
2)迴歸測試 :對上個版本中的全部功能從新測試一遍,檢驗新版本中原有的功能是否依然正確,迴歸測試存在大量的重複性工做,因此企業會使用自動化工具實現
3)隨機測試(猴子測試):在測試用例執行完成以後,對軟件進行隨意的測試的過程【只是時間充足時,對正常測試用例以外的補充測試】
4)兼容測試 :指對被測軟件與硬件、軟件之間的兼容性的測試,
兼容性測試能夠分爲三大類:
(1)硬件兼容
A、與整機兼容
B、與外設兼容
(2)軟件兼容
A、操做系統
B、應用軟件之間的兼容:殺毒軟件,工具類軟件
C、不一樣瀏覽器的兼容
D、數據庫的兼容
(3)數據兼容
不一樣版本間的數據兼容
5)測試流程(步驟)
(1)需求 :閱讀需求,理解需求
(2)測試計劃 :測試經理對整個項目作一個宏觀的計劃
(3)設計測試用例
(4)執行測試
(5)記錄測試執行結果,並填寫《缺陷報告》,記錄缺陷
(6)跟蹤管理缺陷
(7)測試總結報告或測試評估報告