软件测试理论基础知识
一、測試基礎?
1. 軟件測試的定義
（1）IEEE：通過人工或者自動化的手段執(zhí)行某個程序或者運行某個系統(tǒng)的過程，其目的是為了驗證符合規(guī)定的需求以及發(fā)現(xiàn)實際結果和預期結果之間的偏差。
（2）Glenford J.Mayer：?測試是為了發(fā)現(xiàn)缺陷，好的測試方案是發(fā)現(xiàn)了迄今為止未發(fā)現(xiàn)缺陷的方案，成功的測試是發(fā)現(xiàn)了迄今為止未發(fā)現(xiàn)的缺陷。
2. 測試的目的
（1）證明
①60年代
②證明軟件可用，能夠滿足需求
③測試是不能窮盡的，不能百分之百證明軟件沒有問題
（2）檢測
①70年代
②發(fā)現(xiàn)軟件系統(tǒng)的不足，除了功能方面，對其他方面比如性能；易用性可靠性提出更多的要求
③針對不足與問題要做分析
（3）預防
①90年代~至今
②全面管理質量，做好預防
③測試工作要盡早
二、軟件生命周期
計劃--》需求分析--》設計--》編碼實現(xiàn)--》測試--》運行與維護--》評價
三、軟件的開發(fā)過程
1. 軟件開發(fā)模型
（1）?順序開發(fā)模型
? ? ? ? ①瀑布模型
? ? ? ? ②V模型
（2）迭代-增量開發(fā)模型
? ? ? ①螺旋模型
? ? ? ②RUP模型
? ? ? ③IPPD模型
四、常用的測試術語
? ? ? ? ①測試用例
? ? ? ?②缺陷
? ? ? ?
五、軟件測試流程
1. 單元測試
（1）概念
針對組成軟件系統(tǒng)的最基本的單位（函數(shù)或者類）進行測試，叫做單元測試，也稱組件測試。
（2）測試依據(jù)
詳細設計說明書（LLD）
（3）方法
白盒測試方法為主
（4）考察基準
邏輯覆蓋率
（5）英文
Unit Testing（UT）或Component Testing（組件測試）
（6）補充
孤立的測試策略：自頂向下，自底向上
2. 集成測試
（1）概念
將測試完成的單元進行組裝，或者將組裝好的模塊集成為系統(tǒng)，叫做集成測試。
（2）測試依據(jù)
概要設計說明書（HLD）
（3）方法
灰盒（黑盒+白盒）測試方法為主
（4）考察基準
接口覆蓋率
（5）英文
Integration Testing（IT）
（6）補充
大爆炸集成，自頂向下，自底向上，三明治集成
3. 系統(tǒng)測試
（1）概念
將組裝完成的軟件系統(tǒng)作為一個元素和其他軟件或者硬件系統(tǒng)集成在一起的測試，叫做系統(tǒng)測試。
（2）測試依據(jù)
軟件需求規(guī)格說明書（SRS）
（3）方法
黑盒測試方法為主
（4）考察基準
需求覆蓋率
（5）英文
System Testing（ST）
（6）補充
常見的系統(tǒng)測試類型：功能測試，性能測試，安全測試，易用性測試
4. 驗收測試
（1）概念
用戶參與的測試叫做驗收測試（驗收合同或者潛在用戶參與的測試）。
（2）依據(jù)
驗收合同，用戶的原始需求
（3）方法
黑盒測試方法
（4）考察基準
原始需求覆蓋率
（5）英文
User Acceptance Testing（UAT）
（6）補充
Alpha測試（內測）
潛在用戶在開發(fā)現(xiàn)場，有開發(fā)人員進行記錄，整個測試過程可控。
Beta測試（公測）
直接發(fā)布到市場，沒有開發(fā)人員記錄，環(huán)境比較復雜多樣，整個測試過程不可控。
5. 回歸測試
（1）概念
執(zhí)行用例失敗而提交了缺陷，針對缺陷修改后再次驗證缺陷是否修改正確以及缺陷修改后受到影響的測試用例再次測試；回歸測試發(fā)生在任何階段。
（2）流程
①在測試方案中確定回歸測試的版本
②等待回歸測試版本發(fā)布
③回歸測試版本發(fā)布
④回歸測試（按照確定回歸測試策略）
（3）策略
完全重復回歸測試
選擇重復回歸測試（周邊影響法；指標達成法；覆蓋修改法）
六、軟件測試模型
1. 瀑布模型
2. V模型?
??
3. H模型?
4. 雙V模型（Verification and Validation）?
七、測試活動與規(guī)范
1. 測試計劃
針對測試階段做規(guī)劃：
①時間的安排
②人員安排
③任務的分配
④測試目標的要求
⑤測試范圍的劃定
⑥測試計劃文檔（單元測試計劃；系統(tǒng)測試計劃；集成測試計劃；驗收測試計劃）
2. 測試設計
①針對測試計劃給出時間要求，給定的人員要完成分配的測試任務進行各種策略（詳細說明怎么做：具體的工具；方法；模板；任務的順序）
②測試方案文檔（單元測試方案；集成測試方案；系統(tǒng)測試方案；驗收測試方案）
3.?測試實現(xiàn)
①針對方案中給出如何編寫測試用例，編寫測試腳本完成測試用例；測試腳本以及測試規(guī)程
②測試用例（單元測試用例；集成測試用例；系統(tǒng)測試用例；驗收測試用例）
③測試腳本（單元測試腳本；集成測試腳本；系統(tǒng)測試腳本；驗收測試腳本）
④測試規(guī)程（單元測試規(guī)程；集成測試規(guī)程；系統(tǒng)測試規(guī)程；驗收測試規(guī)程）
⑤測試規(guī)程（Test Procedure）：規(guī)定一組測試用例的執(zhí)行順序
4. 測試執(zhí)行
針對計劃中安排的測試執(zhí)行時間、人員、按照方案中給定的環(huán)境搭建數(shù)據(jù)選取等策略，對測試實現(xiàn)中的用例，腳本按照測試規(guī)程編排的順序執(zhí)行，具體的測試執(zhí)行工作：
①搭建測試環(huán)境
②準備測試數(shù)據(jù)
③執(zhí)行測試用例
④記錄測試用例執(zhí)行結果
⑤提交缺陷
⑥跟蹤缺陷
⑦回歸測試
⑧測試報告
八、測試方法及分類
1. 黑盒測試和白盒測試
（1）白盒測試（White Box Testing）
①概念：針對軟件系統(tǒng)的內部細節(jié)做測試，考察內部的邏輯結構，好比盒子是開發(fā)的或者透明的，所以叫做白盒測試。（Open Box Testing；Glass Box Testing；Logic Driven Testing）
②白盒的靜態(tài)測試：控制流分析，數(shù)據(jù)流分析，信息流分析
③白盒的動態(tài)測試：程序插裝與邏輯覆蓋率
【解析】
程序插裝：將測試代碼插入到被測試代碼，通過運行插入測試代碼的程序得出測試結果，查出被測試代碼中是否有問題。
邏輯覆蓋率：語句覆蓋率；判定覆蓋率；條件覆蓋率；路徑覆蓋率
④白盒測試特點
優(yōu)點：問題發(fā)生容易定位
????????????測試的比較徹底
????????????解決問題的成本比較低
缺點：對測試人員的代碼能力要求高
? ? ? ? ? ? 測試的工作的工作量大
? ? ? ? ? ? 測試的成本比較高
? ? ? ? ? ? 對規(guī)格問題不做驗證
（2）黑盒測試（Black Box Testing）
①概念：
針對軟件系統(tǒng)的整體規(guī)格做測試，看不到內部的細節(jié)結構，好比一個黑色的盒子，所以叫黑盒測試
②黑盒的方法
等價類劃分法；邊界值分析法；判定表法；因果圖法；正交實驗法；狀態(tài)遷移圖法；流程分析法
③常見的黑盒測試類型
功能測試；性能測試；負載測試；容量測試
④黑盒測試特點
優(yōu)點：對代碼能力要求低，只測試最終的貴，測試效率高，容易理解
缺點：解決問題的成本高，問題定位比較難，不測試軟件系統(tǒng)內部細節(jié)邏輯結果，對軟件需求規(guī)格說明書的要求比較高
（3）灰盒測試
①概念：綜合運用黑盒測試與白盒測試，灰度取決于被測試對象的顆粒度
2. 靜態(tài)測試和動態(tài)測試
（1）靜態(tài)測試
①概念
被測試對象沒有被運行（比如代碼的編譯，文檔的評審），主要是針對軟件生產(chǎn)過程中的中間產(chǎn)品
②自動化手段（靜態(tài)分析，語法分析，符號執(zhí)行）
③人工手段（評審：代碼走讀；設計文檔技術評審；需求規(guī)格說明書的正規(guī)檢視）
④正規(guī)檢視：必須嚴格遵守流程規(guī)范（角色分配；活動安排），目的是為了發(fā)現(xiàn)缺陷
⑤技術評審：對技術文檔進行評估，選擇方案
⑥走讀：形式比較隨意，作者自己講解，目的是為了發(fā)現(xiàn)缺陷，同時可以交流學習
（2）動態(tài)測試
概念：被測試對象被運行
3. 自動化測試和人工測試
（1）人工測試
需要智能的，執(zhí)行一次的
（2）自動化測試
機械的重復的，不需要智能的，人工無法完成的（大并發(fā)量，查看微妙級的時間相應的）
九、軟件質量
1. 軟件質量的概念
軟件這類產(chǎn)品基于軟件特性的滿足條件（ISO9126）
2. 軟件質量鐵三角
（1）流程
為生產(chǎn)某個產(chǎn)品而進行的一系列相關聯(lián)的活動，將最終目標分解到各個活動使得整個生產(chǎn)過程可見
（2）技術
①技術本身
②技術人才
③工作經(jīng)驗
④專利
⑤案例庫開發(fā)技術
⑥黑盒測試技術
⑦白盒測試技術
⑧自動化技術
⑨測試分析技術
⑩測試設計技術
（3）組織
間接影響軟件質量
①對流程：引進流程；按照流程執(zhí)行；監(jiān)督流程；改進流程
②對技術：引進新技術；購買設備儀器；吸引技術人才；案例庫；專利的申請
3. 軟件質量模型
（1）功能性
| 子特性 | 說明 | 舉例 |
| 適合性 | 軟件系統(tǒng)應該具備的功能是否有缺失以及是否做了額外的實現(xiàn)（功能少了嗎，多了嗎（畫蛇添足）） | ATM自動存取款機：存款；取款；轉賬；查詢。 缺失：只做了存款取款和查詢。 額外的實現(xiàn)：存款；取款；轉賬；查詢；天氣預報。 |
| 準確性 | 軟件系統(tǒng)的功能對數(shù)據(jù)處理的精準能力（對不對） | ATM自動存取款機：存款（20,000RMB，每次最多100張面值100的RMB）；取款（20,000RMB，每次最多3,000RMB，每天最多8次）；轉賬（同行同地轉賬50,000RMB）；查詢（每天查詢8次）。 存款（最多50張100RMB）；取款；轉賬；查詢 |
| 互操作性 | 軟件系統(tǒng)和其他軟件硬件的交互能力。 | 微信的聊天可以發(fā)送圖片（相冊）；餓了么點外賣支付（支付寶；微信）；圖形處理軟件中的圖片傳送到手機。 |
| 安全保密性 | 信息安全（1.防止未被授權用戶訪問到未被授權信息；2.保證被授權用戶能夠訪問到授權的信息） | 微信付賬指紋（你的指紋可以確認付款；防止其他人的指紋確認付款）； 銀行轉賬50萬元RMB（允許本人當天轉賬50萬元RMB；防止其他人轉你銀行的賬） |
| 功能依從性 |
（2）可靠性?
| 子特性 | 說明 | 舉例 |
| 成熟性 | 內部存在的問題比較少 | 微信運行一年不閃退。 |
| 容錯性 | 外部的異常操作，攻擊的處理能力。 | 微信朋友圈每次試圖添加十張圖片。 |
| 易恢復性 | 對問題進行處理恢復正常的能力。 | 重啟APP；重新啟動操作系統(tǒng)。 |
| 可靠依從性 |
（3）效率?
| 子特性 | 說明 | 舉例 |
| 時間 | 軟件系統(tǒng)的某個功能運行的響應時間。 | ATM機群看5，000RMB3秒吐出； |
| 資源 | 軟件系統(tǒng)運行或者某個功能運行資源占有率。 | |
| 效率依從性 |
?（4）易用性
| 子特性 | 說明 | 舉例 |
| 易理解性 | 使用控件資源都一致，提示信息框沒有誤解。 | 快捷鍵；提示信息；Tooltip（工具貼士） |
| 易學性 | 提供軟件系統(tǒng)學習的資料。 | 幫助手冊；用戶手冊；操作向導 |
| 易操作性 | 軟件系統(tǒng)操作的步驟簡單不繁瑣。 | 蘋果手機鈴聲設置 |
| 易吸引性 | 吸引用戶的能力 | 標題黨； |
| 易用依從性 |
?（5）可移植性
| 子特性 | 說明 | 舉例 |
| 適應性 | 軟件系統(tǒng)對不同環(huán)境的適應能力，環(huán)境發(fā)生變化對軟件的修改比較少。 | 微信可以Andriod系統(tǒng)；IOS；Windows都可用。可以在不同版本的Andriod；IOS；Windows下可用。 |
| 易安裝性 | 軟件系統(tǒng)的安裝步驟簡單，能夠在不同環(huán)境下進行安裝，不需要做過多的安裝配置。（卸載） | 手機App。 |
| 易替換性 | 軟件系統(tǒng)的升級、更新和打補丁。 | 手機APP。 |
| 共存性 | 在同一個環(huán)境下，類似軟件共存的能力不能相互影響和抵制。 | 360和騰訊瀏覽器。 |
| 可移植依從性 |
?（6）可維護性
| 子特性 | 說明 | 舉例 |
| 易分析性 | 出現(xiàn)缺陷或者bug，能夠分析出來缺陷產(chǎn)生的原因。 | 注釋行 |
| 易改變性 | 缺陷發(fā)生后有解決缺陷的方案。 | 教學管理系統(tǒng)報表出錯，找不到合適的解決方案。 |
| 穩(wěn)定性 | 對缺陷修復之后造成的影響有多大。 | 代碼的耦合度要低 |
| 易測試性 | 能夠被量化，能夠編寫測試用例，有能夠確定的輸入數(shù)據(jù)。 | ATM自動存取款機：存款一定金額；取款允許范圍內的金額； |
| 可維護依從性 |
（7）依從性
對國家法律、行業(yè)法規(guī)、企業(yè)內部規(guī)則的遵守
【作者的話：點滴積累，成長無限】
總結
以上是生活随笔為你收集整理的软件测试理论基础知识的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 机器人学导论二
- 下一篇： 软件测试基础知识整理