上學(xué)時(shí)的總結(jié)，現(xiàn)在看不論是考試還是工作都很有用

軟件測試的定義

使用人工或自動(dòng)化手段，來運(yùn)行或測試某個(gè)系統(tǒng)的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。

軟件測試的目的

根本目的：發(fā)現(xiàn)問題、 解決問題；提高用戶滿意度、優(yōu)化軟件品質(zhì)

測試的對象：程序 文檔 數(shù)據(jù) (軟件開發(fā)過程中所產(chǎn)生的需求規(guī)格說明、概要
設(shè)計(jì)規(guī)格說明、詳細(xì)設(shè)計(jì)規(guī)格說明以及源程序、用戶文檔都是軟件測試的對象。 )

測試的原則

1、盡早地和及時(shí)地進(jìn)行測試（在需求階段開始測試）

2、測試前應(yīng)當(dāng)準(zhǔn)備好測試數(shù)據(jù)和與之對應(yīng)的預(yù)期結(jié)果這兩部分

3、測試輸入數(shù)據(jù)應(yīng)包括合理的輸入條件和不合理輸入條件

4、程序提交測試后，應(yīng)當(dāng)由專門的測試人員進(jìn)行測試

5、嚴(yán)格執(zhí)行測試計(jì)劃，排除測試的隨意性

6、測試用例的所有相關(guān)預(yù)期結(jié)果做全面的檢查

7、充分注意測試當(dāng)中的群集現(xiàn)象（二八原則）

8、注意保存測試計(jì)劃、測試用例、出錯(cuò)統(tǒng)計(jì)和最終分析報(bào)告，為維護(hù)工作提供充分的資料

9、缺陷具有免疫性（每修復(fù)3~4個(gè)缺陷就會(huì)出現(xiàn)一個(gè)新的缺陷）

測試的誤區(qū)（避免誤區(qū)）

1、軟件測試技術(shù)要求不高，至少比編程容易多了

2、若發(fā)布的軟件有質(zhì)量問題，那是軟件測試人員的錯(cuò)

3、軟件測試是測試人員的事，與開發(fā)人員無關(guān)

4、根據(jù)軟件開發(fā)瀑布模型，軟件測試是開發(fā)后期的一個(gè)階段

5、有時(shí)間就多測試一些，來不及就少測試一些

6、軟件測試是非建設(shè)性的工作，甚至是破壞性的

7、測試中發(fā)現(xiàn)錯(cuò)誤是對責(zé)任人工作的一種否定

軟件開發(fā)模型

大棒開發(fā)法：思路簡單，可能是開發(fā)者的突發(fā)奇想，結(jié)果不可預(yù)知

邊寫邊改法：

優(yōu)點(diǎn)：簡單考慮到了軟件的需求，產(chǎn)品周期短

缺點(diǎn)：沒有計(jì)劃和文檔的編制，后續(xù)維護(hù)難度大

測試工作： 由于新的版本不斷產(chǎn)生，測試工作長期循環(huán)

快速原型法：根據(jù)客戶需求在較短的時(shí)間內(nèi)解決用戶最迫切解決的問題，完成可演示的產(chǎn)品。這個(gè)產(chǎn)品只實(shí)現(xiàn)最重要功能，在得到用戶的更加明確的需求之后，原型將丟棄。

瀑布模型：

階段：需求分析-系統(tǒng)設(shè)計(jì)-程序設(shè)計(jì)-編碼-測試-運(yùn)行及維護(hù)

特點(diǎn)：依線性順序聯(lián)接

優(yōu)點(diǎn)：易理解 階段性 強(qiáng)調(diào)需求分析 明確測試階段 提供了一套模板

缺點(diǎn)：

線性嚴(yán)格——成果晚出——風(fēng)險(xiǎn)

階段固定——反復(fù)&迭代——靈活性

單次需求——需求變更——適應(yīng)性

測試滯后——缺陷晚查——代價(jià)

適用場合：功能性能明確完整 需求固定 無重大變動(dòng)

螺旋模型法

步驟：評估可選方案--計(jì)劃下一階段--確定下一階段方法--確定目標(biāo)、可選方案和限制條件--明確并化解風(fēng)險(xiǎn)--當(dāng)前階段開發(fā)和測試

優(yōu)點(diǎn)：嚴(yán)格的全過程風(fēng)險(xiǎn)管理；強(qiáng)調(diào)各開發(fā)階段的質(zhì)量；提供機(jī)會(huì)評估項(xiàng)目是否有價(jià)值繼續(xù)下去。(發(fā)現(xiàn)問題早)

軟件測試模型

V模型（是最具有代表意義的測試模型）

優(yōu)點(diǎn)：

?測試級別清晰（底層：單元測試 高層：系統(tǒng)測試）

?測試對應(yīng)開發(fā)

缺點(diǎn)：

線性執(zhí)行——測試滯后編碼? 關(guān)注程序——忽略需求、設(shè)計(jì)?? 需求變更——實(shí)用性差

W模型（盡早和不斷的進(jìn)行軟件測試）

優(yōu)點(diǎn)：測試伴隨著整個(gè)軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、 功能、設(shè)計(jì)同樣要測試。

缺點(diǎn)：1、在小的項(xiàng)目里，W模型不適用 2、不支持迭代，應(yīng)對需求變化方面不適用

軟件測試流程

制定測試流程 2、設(shè)計(jì)和生成測試用例 3、搭建測試環(huán)境

?4、實(shí)施測試 5、測試評估 6、測試總結(jié)

測試用例相關(guān)

1、解決的問題：要測什么 怎么測 如何衡量

2、靜態(tài)測試：不運(yùn)行程序，只對程序進(jìn)行檢查和審核 動(dòng)態(tài)測試：使用和運(yùn)行程序進(jìn)行檢查

3、黑盒測試

等價(jià)類劃分

邊界值分析（通常作為等價(jià)類劃分的補(bǔ)充）原則：剛剛等于 剛剛大于 剛剛小于

常用控件法：復(fù)選框 組合列表框 文本框 按鈕 單選按鈕 列表框 滾動(dòng)條（重點(diǎn)參考2-5PPT）

錯(cuò)誤推測法 借助經(jīng)驗(yàn)開展測試，推測軟件中可能存在或容易產(chǎn)生的缺陷的功能模塊

（經(jīng)驗(yàn)分享 在2-6PPT）

例題：測試一個(gè)對線性表（比如數(shù)組）進(jìn)行排序的程序，可推測列出以下幾項(xiàng)需要特別測試的情況：、

1. 輸入的線性表為空表；

2. 表中只含有一個(gè)元素；

3. 輸入表中所有元素已排好序；

4. 輸入表已按逆序排好；

5. 輸入表中部分或全部元素相同

4、白盒測試

·靜態(tài)測試

• 代碼檢查法

??? a.桌面檢查(程序員自己檢查自己編的代碼，目的是發(fā)現(xiàn)錯(cuò)誤)

b.代碼走查

C.代碼審查（逐條講解）

• 靜態(tài)結(jié)構(gòu)分析法

使用靜態(tài)結(jié)構(gòu)分析工具分析程序源代碼的內(nèi)部結(jié)構(gòu)（如：系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)接口、內(nèi)部控制邏輯）

• 代碼質(zhì)量度量

代碼行度量法（千行bug率）

McCabe度量法 V(G)=m-n+2（弧數(shù)減節(jié)點(diǎn)數(shù)加二）或等于判斷語句數(shù)+1

Halstead度量法

程序=運(yùn)算符號+運(yùn)算對象結(jié)構(gòu)度量

N=N1+N2=n1log2(n1)+n2log2(n2)（n1=不同運(yùn)算符的個(gè)數(shù) 也即– + - * / = if else for …… n2=不同運(yùn)算對象的個(gè)數(shù)）

結(jié)構(gòu)度量法

扇入：調(diào)用該模塊的模塊計(jì)數(shù)

扇出：該模塊所調(diào)用的模塊計(jì)數(shù)

具有大扇入和大扇出的模塊可能是不良設(shè)計(jì)。程序復(fù)雜性與扇出的平方成正比

·動(dòng)態(tài)測試（重點(diǎn)PPT2-9）

• 邏輯覆蓋
• 語句覆蓋
• 判定覆蓋
• 條件覆蓋

單元測試

單元：一個(gè)最小的單元應(yīng)有明確的功能、性能定義、接口定義而且可以清晰地與其他單元區(qū)

分開來。

單元測試：

• 定義：單元測試又稱為模塊測試, 是針對程序模塊（軟件設(shè)計(jì)的最小單位）來進(jìn)行正確性檢驗(yàn)的測試工作。程序單元是應(yīng)用的最小可測試部件
• 目標(biāo)：確保每個(gè)模塊都能正常工作
• 時(shí)間：編碼--編譯--單元測試
• 依據(jù)：詳細(xì)設(shè)計(jì)說明
• 單元測試的內(nèi)容：（詳見PPT 4.1 page 24）

模塊接口 ：檢查進(jìn)出程序單元的數(shù)據(jù)流是否準(zhǔn)確（在其他測試之前進(jìn)行）也即檢查輸入?yún)?shù)與模塊的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配

局部數(shù)據(jù)結(jié)構(gòu)：如類型說明是否一致，初始化或默認(rèn)值是否一致、溢出檢測、拼寫錯(cuò)誤的變量名等

邊界條件：可能與邊界值有關(guān)的數(shù)據(jù)類型，如字符、數(shù)值、位置等如：運(yùn)算或判斷中取最大值、最小值時(shí)是否有錯(cuò)誤。在n次循環(huán)的第0次、 1次、 n次是否有錯(cuò)誤。數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值是否出現(xiàn)錯(cuò)誤

出錯(cuò)處理：關(guān)注模塊在工作中發(fā)生錯(cuò)誤時(shí)，出錯(cuò)處理設(shè)施是否有效。如：HTTP500錯(cuò)誤：web服務(wù)器不能執(zhí)行此請求 HTTP404 找不到您所請求的文本或腳本。

路徑測試：

• 定義：針對程序路徑進(jìn)行測試，關(guān)注由于計(jì)算錯(cuò)誤、判定錯(cuò)誤或不正常的控制流二產(chǎn)生的錯(cuò)誤。
• 實(shí)例：

軟件缺陷相關(guān)

1、什么是缺陷

從產(chǎn)品內(nèi)部看：軟件缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中所存在的錯(cuò)誤、毛病等各種問題；

從產(chǎn)品外部看：軟件缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。

2、如何編寫缺陷報(bào)告（一個(gè)缺陷一個(gè)報(bào)告）

舉例：使用“記事本”僅保存“聯(lián)通”二字后再打開該文件，出現(xiàn)亂碼。

?描述步驟：

–點(diǎn)擊“開始” ->“程序” ->“附件” ->“記事本”打開記事本軟件；

–僅輸入“聯(lián)通”二字后，點(diǎn)擊“文件” ->“保存”；

–在打開的“另存為”對話框中保存文件， 退出（文件名、保存位置任意）；

–打開保存的文件，出現(xiàn)亂碼，不是“聯(lián)通”二字。

缺陷的嚴(yán)重性和優(yōu)先級

• Fault? 致命的錯(cuò)誤 造成系統(tǒng)或應(yīng)用程序崩潰，主要功能完全喪失
• Critical：嚴(yán)重錯(cuò)誤，主要指功能或特性沒有實(shí)現(xiàn)，主要功能部分喪失，次要功能完全喪失
• Major：主要錯(cuò)誤，這樣的缺陷雖然不影響系統(tǒng)的使用，但沒有很好地實(shí)現(xiàn)功能。
• Minor: 一些小問題，不影響功能
• Suggestion：一些友好的建議

一般情況下，嚴(yán)重程度高的缺陷優(yōu)先級高，班沒有必然聯(lián)系，需結(jié)合實(shí)際綜合思考

缺陷狀態(tài)

• 定義：缺陷通過一個(gè)跟蹤修復(fù)過程的進(jìn)展情況，也就是在缺陷生命周期中的狀態(tài)基本定義
• 缺陷狀態(tài)：

缺陷狀態(tài)流轉(zhuǎn)

易用性測試：易用性是交互的適應(yīng)性、功能性和有效性的集中體現(xiàn)

• 界面（UI）

??? 標(biāo)準(zhǔn)和規(guī)范

直觀 正確 一致（如果軟件或者平臺(tái)有統(tǒng)一標(biāo)準(zhǔn)，遵循標(biāo)準(zhǔn)。如果沒有，就注意軟件的特性，確保相似操作以相似的方式進(jìn)行） 靈活（狀態(tài)終止和跳轉(zhuǎn)、數(shù)據(jù)輸入和輸出） 舒適 實(shí)用

• 輔助功能選項(xiàng)（為有殘疾障礙的人測試）

操作系統(tǒng)內(nèi)置

平臺(tái)

• 為什么要進(jìn)行易用性測試：軟件難以理解，不易使用，運(yùn)行緩慢，或者從測試人員或用戶的角度認(rèn)為不好。

兼容性測試：指軟件之間能否正確的交互和共享信息。

兼容性測試標(biāo)準(zhǔn)

• 向前兼容（可以使用軟件以前的版本 如：Office 2007/2013 可以打開Office 2003下存儲(chǔ)的文檔）
• 向后兼容（可以使用軟件以后的版本 如：Office 2003可以打開Office2013存儲(chǔ)的文檔）

2、

數(shù)據(jù)兼容性指要在應(yīng)用程序之間共享數(shù)據(jù)

安全性測試

• 定義：檢查系統(tǒng)對非法侵入的防范能力
• 原因：驗(yàn)證安裝在系統(tǒng)內(nèi)的保護(hù)機(jī)制能否在實(shí)際中保護(hù)系統(tǒng)且不受非法入侵， 不受非法干擾。（應(yīng)對入侵）
• 如何做安全性測試：

代碼角度

使用安全函數(shù)

防止緩沖區(qū)溢出

外部攻擊角度

跨站腳本攻擊

SQL注入（通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令）如：穿過防火墻，入侵檢測系統(tǒng)；執(zhí)行增、刪、改、查腳本；嘗試輸入特殊字符

回歸測試

• 定義：驗(yàn)證被修復(fù)軟件缺陷是否已經(jīng)被解決，并且保證以前運(yùn)行的功能依舊保持正常，而不受修改的影響
• 測試點(diǎn)

測試修改的模塊

有可能會(huì)受到影響的模塊

驗(yàn)收測試

定義：對軟件的新的版本測試時(shí)，對新版本進(jìn)行重新測試，這時(shí)的測試不僅是驗(yàn)證被修復(fù)的軟件缺陷是否被解決了，且要保證以前所有運(yùn)行正常的功能依舊保持正常，而不要受到這次修改的影響

驗(yàn)收測試依據(jù)：軟件需求說明文檔

誰來做驗(yàn)收測試

產(chǎn)品軟件驗(yàn)收

項(xiàng)目軟件驗(yàn)收

驗(yàn)收測試的實(shí)施

α測試：開發(fā)公司組織內(nèi)部人員進(jìn)行測試

β測試：內(nèi)測之后的公測，組織外部典型性用戶進(jìn)行測試

軟件質(zhì)量相關(guān)（見）

質(zhì)量定義范圍-3A

可說明性

有效性

易用性

2、軟件質(zhì)量標(biāo)準(zhǔn)

產(chǎn)品質(zhì)量模型（人們實(shí)踐產(chǎn)物的屬性和行為）：McCall? ISO9126? Boehm

過程質(zhì)量模型（人們產(chǎn)生產(chǎn)品的過程的好壞）: CMM ISO9000

SQA

?????? QA職責(zé)：（過程管理和過程改進(jìn)） QC職責(zé)（發(fā)現(xiàn)軟件問題）

總結(jié)

以上是生活随笔為你收集整理的软件测试必须知道的精华总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。