1.1 軟件的分類
1.1.1 軟件的定義
一系列按照特定順序組織的計算機數(shù)據(jù)和指令的集合。
軟件 = 數(shù)據(jù) + 指令 + 文檔
問題：常見軟件有哪些输莺？
1.1.2 根據(jù)應(yīng)用場景分類
工具類軟件玲献、游戲型軟件朋凉、媒體型軟件、電商型軟件等
1.1.3 根據(jù)軟件架構(gòu)分類
單機版軟件低滩、分布式軟件
- 單機版軟件：office顽冶、紅警等
- 分布式軟件：
C/S架構(gòu)軟件：客戶端需安裝專門軟件欺抗，如QQ 微信等
B/S架構(gòu)軟件：客戶端為瀏覽器 ，如百度强重、hao123等
1.2 軟件測試的定義與原則
1.2.1 為什么需要軟件測試
阿麗亞娜5號火箭.jpg
- 事故：阿麗亞娜5號火箭爆炸绞呈，造成重大經(jīng)濟損失。
-
原因：程序中試圖將64位浮點數(shù)轉(zhuǎn)換成16位整數(shù)時發(fā)生溢出-----缺少錯誤程序?qū)?shù)據(jù)溢出進行管理
image.png
事故：拼多多2019年用戶可以領(lǐng)取100元無門檻券间景。
原因：程序中試圖將64位浮點數(shù)轉(zhuǎn)換成16位整數(shù)時發(fā)生溢出-----缺少錯誤程序?qū)?shù)據(jù)溢出進行管理
1.2.2 軟件測試的定義
通過人工或自動化的方式來驗證軟件的實際結(jié)果與用戶需求是否一致的過程
1.2.3 軟件測試的原則
-
原則一：測試顯示軟件存在缺陷
測試只能證明軟件中存在缺陷佃声，但并不能證明軟件中不存在缺陷。軟件測試是為了降低存在缺陷的可能性拱燃，即便是沒有找到缺陷秉溉，也不能證明軟件是完美的力惯。 -
原則二：窮盡測試是不可能的
現(xiàn)在軟件的規(guī)模越來越大碗誉，復(fù)雜度越來越高召嘶，想做到完全性的測試是不可能的。在測試階段哮缺，測試人員可以根據(jù)風(fēng)險和優(yōu)先級來進行集中和高強度的測試弄跌，從而保證軟件的質(zhì)量。 -
原則三：測試盡早介入
為什么測試要盡早介入呢尝苇，簡單的說就是保證軟件質(zhì)量铛只，降低風(fēng)險和成本。測試人員一般在需求階段就開始介入糠溜，使缺陷在需求或設(shè)計階段就被發(fā)現(xiàn)淳玩，缺陷發(fā)現(xiàn)越早，修復(fù)的成本就越小非竿。 -
原則四：缺陷集群性（2/8原則）
缺陷集群性表明小部分模塊包含大部分的缺陷蜕着。軟件測試中存在Pareto原則：80%的缺陷發(fā)現(xiàn)在20%的模塊中。
一個功能模塊發(fā)現(xiàn)的缺陷越高红柱，那存在的未被發(fā)現(xiàn)的缺陷也越高承匣，故發(fā)現(xiàn)的缺陷與未發(fā)現(xiàn)的缺陷成正比。 -
原則五：殺蟲劑悖論
反復(fù)使用相同的殺蟲劑會導(dǎo)致害蟲對殺蟲劑產(chǎn)生免疫而無法殺死害蟲锤悄。軟件測試也一樣韧骗。如果一直使用相同的測試方法或手段，可能無法發(fā)現(xiàn)新的bug零聚。
為了解決這個問題袍暴，測試用例應(yīng)當(dāng)定期修訂和評審，增加新的或不同的測試用例幫助發(fā)現(xiàn)更多的缺陷隶症。
測試人員不能一直依賴于現(xiàn)有的測試技術(shù)容诬，而要不斷的提升測試方法以提高測試效率。 -
原則六：測試活動依賴于測試內(nèi)容
根據(jù)業(yè)務(wù)的不同沿腰，軟件測試內(nèi)部也分為不同的行業(yè)览徒，比如游戲行業(yè)、電商行業(yè)颂龙、金融行業(yè)习蓬。不同的行業(yè)，測試活動的開展都有所不同措嵌，比如測試技術(shù)躲叼、測試工具的選擇，測試流程都不盡相同企巢，所以軟件測試的活動開展依賴于所測試的內(nèi)容枫慷。 -
原則七：沒有錯誤是好是謬論
有可能99%沒有bug的軟件也是不能使用的。如果對錯誤的需求進行了徹底的測試，這種情況就發(fā)生了或听。軟件測試不僅是找出缺陷妄讯，同時也需要確認(rèn)軟件是否滿足需求吝沫。如果開發(fā)出來的產(chǎn)品不滿足用戶的需求，即便找到和修復(fù)了缺陷也作用不大。 - 原則八：程序員應(yīng)避免檢查自己的程序
- 原則九：嚴(yán)格執(zhí)行測試計劃默垄，排除測試的隨意性
- 原則十：應(yīng)當(dāng)對每一個測試結(jié)果做全面的檢查
- 原則十一：妥善保存測試計劃捉邢、測試用例播急、出錯統(tǒng)計和最終分析報告再沧，為維護提供方便
- 原則十二：設(shè)計測試用例時，應(yīng)當(dāng)包括合理的輸入數(shù)據(jù)和不合理的輸入數(shù)據(jù)
- 原則十三：測試用例應(yīng)由測試數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成
1.3 開發(fā)與測試模型的介紹
1.3.1 開發(fā)模型
- 瀑布模型：
- 引入：做飯最終不能返回
- 定義：將軟件生命周期的各項活動規(guī)定為按固定順序而連接的若干階段工作斩跌，形如瀑布流水绍些，最終得到軟件產(chǎn)品的項目。
瀑布模型.jpg
- 優(yōu)點：
為項目提供了按階段劃分的檢查點
當(dāng)前一階段完成后耀鸦，只需要去關(guān)注后續(xù)階段遇革。 - 缺點：
各個階段的劃分完全固定，階段之間產(chǎn)生大量的文檔揭糕，極大地增加了工作量萝快。
由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果著角，從而增加了開發(fā)風(fēng)險揪漩。
通過過多的強制完成日期和里程碑來跟蹤各個項目階段。
瀑布模型的突出缺點是不適應(yīng)用戶需求的變化吏口。
- 快速原型模型：在需求分析階段對軟件的需求進行初步而非完全的分析和定義奄容，用戶與開發(fā)者在過程中加強反饋，快速設(shè)計開發(fā)出軟件系統(tǒng)可以運行的模型产徊；
- 增量模型：把待開發(fā)的軟件系統(tǒng)模塊化昂勒，第1個增量往往是產(chǎn)品的核心，將每個模塊作為一個增量組件舟铜，從而分批次地分析戈盈、設(shè)計、編碼和測試這些增量組件谆刨；
- 敏捷開發(fā)：先選擇產(chǎn)品塘娶，再進行開會、對產(chǎn)品計劃痊夭，然后對任務(wù)進行分工刁岸，分工后開始按照計劃執(zhí)行，然后就做出了新的功能模塊她我，然后再進行演示虹曙、回顧迫横，最后再領(lǐng)取新的任務(wù)，依次循環(huán)酝碳。
1.3.2 測試模型
V模型：
V 模型的左邊下降的是開發(fā)過程各階段矾踱，與此相對應(yīng)的是右邊上升的部分，即各測試過程的各個階段击敌。
V 模型的優(yōu)點在于它非常明確地標(biāo)明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)各階段的對應(yīng)關(guān)系拴事。
V模型.jpg
W模型：
相對于V模型沃斤，W模型更科學(xué)。W模型是V模型的發(fā)展刃宵，強調(diào)的是測試伴隨著整個軟件開發(fā)周期衡瓶，而且測試的對象不僅僅是程序，需求牲证、功能和設(shè)計同樣要測試哮针。測試與開發(fā)是同步進行的，從而有利于盡早地發(fā)現(xiàn)問題坦袍。
W模型.jpg
1.4 軟件測試的流程
| 階段名 | 工作內(nèi)容 | 產(chǎn)出物 |
|---|---|---|
| 測試準(zhǔn)備階段 | 項目立項十厢、需求分析、需求評審 | 需求文檔捂齐、產(chǎn)品PRD |
| 測試計劃階段 | 編寫測試計劃蛮放、計劃評審 | 測試計劃 |
| 測試設(shè)計階段 | 提取測試點、編寫測試用例奠宜、用例評審 | 測試用例 |
| 測試執(zhí)行階段 | 冒煙測試包颁、執(zhí)行測試用例、提bug压真、回歸測試 | 缺陷報告 |
| 測試完成階段 | 驗收測試娩嚼、編寫測試報告、項目上線 | 測試報告 |
image.png
1.5 軟件測試的分類
image.png
1.5.1 按技術(shù)劃分
黑盒測試滴肿、白盒測試岳悟、灰盒測試
-
黑盒測試(Black Box -Test)：把被測試的軟件看做一個黑盒子，我們不去關(guān)心盒子里邊的結(jié)構(gòu)是什么樣子泼差，只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果
有人把黑盒測試比作中醫(yī)竿音，通過“望聞問切”來判斷是否有問題。
“望”：觀察軟件的行為是否正常拴驮。
“聞”：檢查輸出的結(jié)果是否正確春瞬。
“問”：輸入各種信息，結(jié)合“望”套啤，“聞”來觀察軟件的響應(yīng)宽气。
“切”：像中醫(yī)一樣給軟件“把把脈”随常，敲擊一下軟件的某些“關(guān)節(jié)” - 白盒測試：是一種按照程序內(nèi)部邏輯結(jié)構(gòu)和編碼結(jié)構(gòu)設(shè)計測試數(shù)據(jù)并完成測試的測試方法
-
灰盒測試：一種基于程序運行時的外部表現(xiàn)同時又結(jié)合程序內(nèi)部結(jié)構(gòu)來設(shè)計測試數(shù)據(jù)的測試方法
image.png
1.5.2 按階段劃分
單元測試、集成測試萄涯、系統(tǒng)測試绪氛、驗收測試
- 單元測試：對一個模塊、一個函數(shù)或者一個類來進行正確性檢驗的測試方法
- 集成測試：單元測試后涝影，將單獨的模塊按照設(shè)計要求組裝成為子系統(tǒng)或系統(tǒng)枣察，作為整體進行測試的測試方法
- 系統(tǒng)測試：集成測試后，將硬件燃逻、軟件看作一個整體,對系統(tǒng)的功能及性能的總體測試
-
驗收測試：系統(tǒng)測試后以用戶測試為主序目，或有測試人員共同參與檢驗軟件質(zhì)量的測試方法
image.png
1.5.3 按內(nèi)容劃分
功能測試、性能測試伯襟、兼容性測試
1.5.3.1 功能測試：
- 界面測試猿涨、冒煙測試、回歸測試姆怪、業(yè)務(wù)邏輯測試叛赚、易用性測試
- 功能測試：根據(jù)產(chǎn)品操作描述和需求文檔，測試一個產(chǎn)品的特性和可操作行為是否滿足用戶需求的測試方法
- 界面測試：測試用戶界面的功能模塊的布局是否符合客戶使用習(xí)慣稽揭，界面操作便捷性俺附、導(dǎo)航簡單易懂性的測試
- 冒煙測試：驗證系統(tǒng)的核心功能是否能夠正常運行的測試方法
- 回歸測試：指修改了舊代碼后，重新進行測試以確認(rèn)修改沒有引入新的錯誤或?qū)е缕渌a產(chǎn)生錯誤的測試方法
- 業(yè)務(wù)邏輯測試：在基本的功能點都已合格的基礎(chǔ)上溪掀，準(zhǔn)備多種測試數(shù)據(jù)昙读，來驅(qū)動各種約束條件下業(yè)務(wù)流程，確定最終輸出的結(jié)果是否符合預(yù)期的測試
- 易用性測試：指用戶使用軟件時是否感覺方便的測試
1.5.3.2 性能測試：
- 性能測試：通過自動化的測試工具模擬多種正常膨桥、峰值以及異常負(fù)載條件來對系統(tǒng)的各項性能指標(biāo)進行校驗的測試方法
- 壓力測試：通過逐步增加系統(tǒng)負(fù)載蛮浑，測試系統(tǒng)性能的變化，并確定在什么條件下系統(tǒng)性能處于失效狀態(tài)
- 負(fù)載測試：通過逐步增加系統(tǒng)負(fù)載只嚣，測試系統(tǒng)性能的變化沮稚，在滿足性能指標(biāo)的情況下，系統(tǒng)所能承受的最大負(fù)載量的測試
- 并發(fā)測試：是一個負(fù)載測試和壓力測試的過程册舞，即逐漸增加并發(fā)用戶數(shù)負(fù)載直到系統(tǒng)的瓶頸蕴掏，通過分析資源監(jiān)控指標(biāo)等來確定系統(tǒng)并發(fā)性能
1.5.3.3 兼容性測試：
- app
- Android/IOS版本
- 廠商
- 型號
- 分辨率
- 屏幕：全屏、水滴屏调鲸、劉海屏盛杰、曲面屏、折疊屏藐石、雙面屏
- web
- 瀏覽器：四類即供，根據(jù)瀏覽器內(nèi)核（78）
1.5.4 按其他劃分
- 冒煙測試、隨機測試于微、安全性測試逗嫡、探索性測試青自、回歸測試、Alpha測試驱证、Beta測試
- 隨機測試：隨機測試主要是根據(jù)測試者的經(jīng)驗無需測試用例對軟件進行功能和性能抽查的測試方法
- 安全性測試：通過不同的測試方法延窜，檢驗程序、網(wǎng)絡(luò)抹锄、數(shù)據(jù)庫安全性的測試方法
- 探索性測試：碰到問題時能隨機應(yīng)變逆瑞，強調(diào)測試人員的主觀能動性明確整體的測試計劃的測試方法
- Alpha測試：俗稱內(nèi)測，α測試伙单。內(nèi)部環(huán)境下的測試获高；開發(fā)人員或測試人員在現(xiàn)場
- Beta測試：俗稱外測、公測车份，β測試谋减。生產(chǎn)環(huán)境下的測試牡彻；開發(fā)人員和測試人員都不在現(xiàn)場3
