第一單元 測(cè)試?yán)碚?/h2>

1.1 軟件的分類

1.1.1 軟件的定義

一系列按照特定順序組織的計(jì)算機(jī)數(shù)據(jù)和指令的集合。
軟件 = 數(shù)據(jù) + 指令 + 文檔
問題：常見軟件有哪些？

1.1.2 根據(jù)應(yīng)用場(chǎng)景分類

工具類軟件、游戲型軟件、媒體型軟件、電商型軟件等

1.1.3 根據(jù)軟件架構(gòu)分類

單機(jī)版軟件、分布式軟件

1. 單機(jī)版軟件：office、紅警等
2. 分布式軟件：
   C/S架構(gòu)軟件：客戶端需安裝專門軟件，如QQ 微信等
   B/S架構(gòu)軟件：客戶端為瀏覽器 ，如百度、hao123等

1.2 軟件測(cè)試的定義與原則

1.2.1 為什么需要軟件測(cè)試

阿麗亞娜5號(hào)火箭.jpg

• 事故：阿麗亞娜5號(hào)火箭爆炸，造成重大經(jīng)濟(jì)損失。

• 原因：程序中試圖將64位浮點(diǎn)數(shù)轉(zhuǎn)換成16位整數(shù)時(shí)發(fā)生溢出-----缺少錯(cuò)誤程序?qū)?shù)據(jù)溢出進(jìn)行管理

  
  
  image.png
  
  

  事故：拼多多2019年用戶可以領(lǐng)取100元無門檻券。
  原因：程序中試圖將64位浮點(diǎn)數(shù)轉(zhuǎn)換成16位整數(shù)時(shí)發(fā)生溢出-----缺少錯(cuò)誤程序?qū)?shù)據(jù)溢出進(jìn)行管理

1.2.2 軟件測(cè)試的定義

通過人工或自動(dòng)化的方式來驗(yàn)證軟件的實(shí)際結(jié)果與用戶需求是否一致的過程

1.2.3 軟件測(cè)試的原則

• 原則一：測(cè)試顯示軟件存在缺陷
  測(cè)試只能證明軟件中存在缺陷，但并不能證明軟件中不存在缺陷。軟件測(cè)試是為了降低存在缺陷的可能性，即便是沒有找到缺陷，也不能證明軟件是完美的。
• 原則二：窮盡測(cè)試是不可能的
  現(xiàn)在軟件的規(guī)模越來越大，復(fù)雜度越來越高，想做到完全性的測(cè)試是不可能的。在測(cè)試階段，測(cè)試人員可以根據(jù)風(fēng)險(xiǎn)和優(yōu)先級(jí)來進(jìn)行集中和高強(qiáng)度的測(cè)試，從而保證軟件的質(zhì)量。
• 原則三：測(cè)試盡早介入
  為什么測(cè)試要盡早介入呢，簡(jiǎn)單的說就是保證軟件質(zhì)量，降低風(fēng)險(xiǎn)和成本。測(cè)試人員一般在需求階段就開始介入，使缺陷在需求或設(shè)計(jì)階段就被發(fā)現(xiàn)，缺陷發(fā)現(xiàn)越早，修復(fù)的成本就越小。
• 原則四：缺陷集群性（2/8原則）
  缺陷集群性表明小部分模塊包含大部分的缺陷。軟件測(cè)試中存在Pareto原則：80%的缺陷發(fā)現(xiàn)在20%的模塊中。
  一個(gè)功能模塊發(fā)現(xiàn)的缺陷越高，那存在的未被發(fā)現(xiàn)的缺陷也越高，故發(fā)現(xiàn)的缺陷與未發(fā)現(xiàn)的缺陷成正比。
• 原則五：殺蟲劑悖論
  反復(fù)使用相同的殺蟲劑會(huì)導(dǎo)致害蟲對(duì)殺蟲劑產(chǎn)生免疫而無法殺死害蟲。軟件測(cè)試也一樣。如果一直使用相同的測(cè)試方法或手段，可能無法發(fā)現(xiàn)新的bug。
  為了解決這個(gè)問題，測(cè)試用例應(yīng)當(dāng)定期修訂和評(píng)審，增加新的或不同的測(cè)試用例幫助發(fā)現(xiàn)更多的缺陷。
  測(cè)試人員不能一直依賴于現(xiàn)有的測(cè)試技術(shù)，而要不斷的提升測(cè)試方法以提高測(cè)試效率。
• 原則六：測(cè)試活動(dòng)依賴于測(cè)試內(nèi)容
  根據(jù)業(yè)務(wù)的不同，軟件測(cè)試內(nèi)部也分為不同的行業(yè)，比如游戲行業(yè)、電商行業(yè)、金融行業(yè)。不同的行業(yè)，測(cè)試活動(dòng)的開展都有所不同，比如測(cè)試技術(shù)、測(cè)試工具的選擇，測(cè)試流程都不盡相同，所以軟件測(cè)試的活動(dòng)開展依賴于所測(cè)試的內(nèi)容。
• 原則七：沒有錯(cuò)誤是好是謬論
  有可能99%沒有bug的軟件也是不能使用的。如果對(duì)錯(cuò)誤的需求進(jìn)行了徹底的測(cè)試，這種情況就發(fā)生了。軟件測(cè)試不僅是找出缺陷，同時(shí)也需要確認(rèn)軟件是否滿足需求。如果開發(fā)出來的產(chǎn)品不滿足用戶的需求，即便找到和修復(fù)了缺陷也作用不大。
• 原則八：程序員應(yīng)避免檢查自己的程序
• 原則九：嚴(yán)格執(zhí)行測(cè)試計(jì)劃，排除測(cè)試的隨意性
• 原則十：應(yīng)當(dāng)對(duì)每一個(gè)測(cè)試結(jié)果做全面的檢查
• 原則十一：妥善保存測(cè)試計(jì)劃、測(cè)試用例、出錯(cuò)統(tǒng)計(jì)和最終分析報(bào)告，為維護(hù)提供方便
• 原則十二：設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)當(dāng)包括合理的輸入數(shù)據(jù)和不合理的輸入數(shù)據(jù)
• 原則十三：測(cè)試用例應(yīng)由測(cè)試數(shù)據(jù)和與之對(duì)應(yīng)的預(yù)期輸出結(jié)果這兩部分組成

1.3 開發(fā)與測(cè)試模型的介紹

1.3.1 開發(fā)模型

1. 瀑布模型：

• 引入：做飯最終不能返回
• 定義：將軟件生命周期的各項(xiàng)活動(dòng)規(guī)定為按固定順序而連接的若干階段工作，形如瀑布流水，最終得到軟件產(chǎn)品的項(xiàng)目。

瀑布模型.jpg

• 優(yōu)點(diǎn)：
  為項(xiàng)目提供了按階段劃分的檢查點(diǎn)
  當(dāng)前一階段完成后，只需要去關(guān)注后續(xù)階段。
• 缺點(diǎn)：
  各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。
  由于開發(fā)模型是線性的，用戶只有等到整個(gè)過程的末期才能見到開發(fā)成果，從而增加了開發(fā)風(fēng)險(xiǎn)。
  通過過多的強(qiáng)制完成日期和里程碑來跟蹤各個(gè)項(xiàng)目階段。
  瀑布模型的突出缺點(diǎn)是不適應(yīng)用戶需求的變化。

2. 快速原型模型：在需求分析階段對(duì)軟件的需求進(jìn)行初步而非完全的分析和定義，用戶與開發(fā)者在過程中加強(qiáng)反饋，快速設(shè)計(jì)開發(fā)出軟件系統(tǒng)可以運(yùn)行的模型；
3. 增量模型：把待開發(fā)的軟件系統(tǒng)模塊化，第1個(gè)增量往往是產(chǎn)品的核心，將每個(gè)模塊作為一個(gè)增量組件，從而分批次地分析、設(shè)計(jì)、編碼和測(cè)試這些增量組件；
4. 敏捷開發(fā)：先選擇產(chǎn)品，再進(jìn)行開會(huì)、對(duì)產(chǎn)品計(jì)劃，然后對(duì)任務(wù)進(jìn)行分工，分工后開始按照計(jì)劃執(zhí)行，然后就做出了新的功能模塊，然后再進(jìn)行演示、回顧，最后再領(lǐng)取新的任務(wù)，依次循環(huán)。

1.3.2 測(cè)試模型

V模型：
V 模型的左邊下降的是開發(fā)過程各階段，與此相對(duì)應(yīng)的是右邊上升的部分，即各測(cè)試過程的各個(gè)階段。
V 模型的優(yōu)點(diǎn)在于它非常明確地標(biāo)明了測(cè)試過程中存在的不同級(jí)別，并且清楚地描述了這些測(cè)試階段和開發(fā)各階段的對(duì)應(yīng)關(guān)系。

V模型.jpg

W模型：
相對(duì)于V模型，W模型更科學(xué)。W模型是V模型的發(fā)展，強(qiáng)調(diào)的是測(cè)試伴隨著整個(gè)軟件開發(fā)周期，而且測(cè)試的對(duì)象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測(cè)試。測(cè)試與開發(fā)是同步進(jìn)行的，從而有利于盡早地發(fā)現(xiàn)問題。

W模型.jpg

1.4 軟件測(cè)試的流程

階段名	工作內(nèi)容	產(chǎn)出物
測(cè)試準(zhǔn)備階段	項(xiàng)目立項(xiàng)、需求分析、需求評(píng)審	需求文檔、產(chǎn)品PRD
測(cè)試計(jì)劃階段	編寫測(cè)試計(jì)劃、計(jì)劃評(píng)審	測(cè)試計(jì)劃
測(cè)試設(shè)計(jì)階段	提取測(cè)試點(diǎn)、編寫測(cè)試用例、用例評(píng)審	測(cè)試用例
測(cè)試執(zhí)行階段	冒煙測(cè)試、執(zhí)行測(cè)試用例、提bug、回歸測(cè)試	缺陷報(bào)告
測(cè)試完成階段	驗(yàn)收測(cè)試、編寫測(cè)試報(bào)告、項(xiàng)目上線	測(cè)試報(bào)告

image.png

1.5 軟件測(cè)試的分類

image.png

1.5.1 按技術(shù)劃分

黑盒測(cè)試、白盒測(cè)試、灰盒測(cè)試

• 黑盒測(cè)試(Black Box -Test)：把被測(cè)試的軟件看做一個(gè)黑盒子，我們不去關(guān)心盒子里邊的結(jié)構(gòu)是什么樣子，只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果
  有人把黑盒測(cè)試比作中醫(yī)，通過“望聞問切”來判斷是否有問題。
  “望”：觀察軟件的行為是否正常。
  “聞”：檢查輸出的結(jié)果是否正確。
  “問”：輸入各種信息，結(jié)合“望”，“聞”來觀察軟件的響應(yīng)。
  “切”：像中醫(yī)一樣給軟件“把把脈”，敲擊一下軟件的某些“關(guān)節(jié)”
• 白盒測(cè)試：是一種按照程序內(nèi)部邏輯結(jié)構(gòu)和編碼結(jié)構(gòu)設(shè)計(jì)測(cè)試數(shù)據(jù)并完成測(cè)試的測(cè)試方法

• 灰盒測(cè)試：一種基于程序運(yùn)行時(shí)的外部表現(xiàn)同時(shí)又結(jié)合程序內(nèi)部結(jié)構(gòu)來設(shè)計(jì)測(cè)試數(shù)據(jù)的測(cè)試方法

  
  
  image.png

1.5.2 按階段劃分

單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試

• 單元測(cè)試：對(duì)一個(gè)模塊、一個(gè)函數(shù)或者一個(gè)類來進(jìn)行正確性檢驗(yàn)的測(cè)試方法
• 集成測(cè)試：?jiǎn)卧獪y(cè)試后，將單獨(dú)的模塊按照設(shè)計(jì)要求組裝成為子系統(tǒng)或系統(tǒng)，作為整體進(jìn)行測(cè)試的測(cè)試方法
• 系統(tǒng)測(cè)試：集成測(cè)試后，將硬件、軟件看作一個(gè)整體,對(duì)系統(tǒng)的功能及性能的總體測(cè)試

• 驗(yàn)收測(cè)試：系統(tǒng)測(cè)試后以用戶測(cè)試為主，或有測(cè)試人員共同參與檢驗(yàn)軟件質(zhì)量的測(cè)試方法

  
  
  image.png

1.5.3 按內(nèi)容劃分

功能測(cè)試、性能測(cè)試、兼容性測(cè)試

1.5.3.1 功能測(cè)試：

• 界面測(cè)試、冒煙測(cè)試、回歸測(cè)試、業(yè)務(wù)邏輯測(cè)試、易用性測(cè)試
• 功能測(cè)試：根據(jù)產(chǎn)品操作描述和需求文檔，測(cè)試一個(gè)產(chǎn)品的特性和可操作行為是否滿足用戶需求的測(cè)試方法
• 界面測(cè)試：測(cè)試用戶界面的功能模塊的布局是否符合客戶使用習(xí)慣，界面操作便捷性、導(dǎo)航簡(jiǎn)單易懂性的測(cè)試
• 冒煙測(cè)試：驗(yàn)證系統(tǒng)的核心功能是否能夠正常運(yùn)行的測(cè)試方法
• 回歸測(cè)試：指修改了舊代碼后，重新進(jìn)行測(cè)試以確認(rèn)修改沒有引入新的錯(cuò)誤或?qū)е缕渌a產(chǎn)生錯(cuò)誤的測(cè)試方法
• 業(yè)務(wù)邏輯測(cè)試：在基本的功能點(diǎn)都已合格的基礎(chǔ)上，準(zhǔn)備多種測(cè)試數(shù)據(jù)，來驅(qū)動(dòng)各種約束條件下業(yè)務(wù)流程，確定最終輸出的結(jié)果是否符合預(yù)期的測(cè)試
• 易用性測(cè)試：指用戶使用軟件時(shí)是否感覺方便的測(cè)試

1.5.3.2 性能測(cè)試：

• 性能測(cè)試：通過自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行校驗(yàn)的測(cè)試方法
• 壓力測(cè)試：通過逐步增加系統(tǒng)負(fù)載，測(cè)試系統(tǒng)性能的變化，并確定在什么條件下系統(tǒng)性能處于失效狀態(tài)
• 負(fù)載測(cè)試：通過逐步增加系統(tǒng)負(fù)載，測(cè)試系統(tǒng)性能的變化，在滿足性能指標(biāo)的情況下，系統(tǒng)所能承受的最大負(fù)載量的測(cè)試
• 并發(fā)測(cè)試：是一個(gè)負(fù)載測(cè)試和壓力測(cè)試的過程，即逐漸增加并發(fā)用戶數(shù)負(fù)載直到系統(tǒng)的瓶頸，通過分析資源監(jiān)控指標(biāo)等來確定系統(tǒng)并發(fā)性能

1.5.3.3 兼容性測(cè)試：

• app

1. Android/IOS版本
2. 廠商
3. 型號(hào)
4. 分辨率
5. 屏幕：全屏、水滴屏、劉海屏、曲面屏、折疊屏、雙面屏

• web

1. 瀏覽器：四類，根據(jù)瀏覽器內(nèi)核（78）

1.5.4 按其他劃分

• 冒煙測(cè)試、隨機(jī)測(cè)試、安全性測(cè)試、探索性測(cè)試、回歸測(cè)試、Alpha測(cè)試、Beta測(cè)試
• 隨機(jī)測(cè)試：隨機(jī)測(cè)試主要是根據(jù)測(cè)試者的經(jīng)驗(yàn)無需測(cè)試用例對(duì)軟件進(jìn)行功能和性能抽查的測(cè)試方法
• 安全性測(cè)試：通過不同的測(cè)試方法，檢驗(yàn)程序、網(wǎng)絡(luò)、數(shù)據(jù)庫安全性的測(cè)試方法
• 探索性測(cè)試：碰到問題時(shí)能隨機(jī)應(yīng)變，強(qiáng)調(diào)測(cè)試人員的主觀能動(dòng)性明確整體的測(cè)試計(jì)劃的測(cè)試方法
• Alpha測(cè)試：俗稱內(nèi)測(cè)，α測(cè)試。內(nèi)部環(huán)境下的測(cè)試；開發(fā)人員或測(cè)試人員在現(xiàn)場(chǎng)
• Beta測(cè)試：俗稱外測(cè)、公測(cè)，β測(cè)試。生產(chǎn)環(huán)境下的測(cè)試；開發(fā)人員和測(cè)試人員都不在現(xiàn)場(chǎng)3

最后編輯于 ：2021.08.10 11:35:50

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。