目錄

軟件測試期末復(fù)習(xí)系列

課件知識(shí)點(diǎn)整合：

1. 軟件測試基礎(chǔ)
2. 白盒測試
3. 黑盒測試

PTA習(xí)題匯總：

1. 軟件測試基礎(chǔ)
2. 白盒測試-邏輯覆蓋測試
3. 白盒測試-基本路徑測試
4. 白盒測試-靜態(tài)測試
5. 黑盒測試-等價(jià)類劃分
6. 黑盒測試-邊界值測試
7. 黑盒測試-場景法

概念與定義

1. 軟件危機(jī)：軟件危機(jī)是指落后的軟件生產(chǎn)方式無法滿足迅速增長的計(jì)算機(jī)軟件需求，從而導(dǎo)致軟件開發(fā)與維護(hù)過程中出現(xiàn)一系列嚴(yán)重問題的現(xiàn)象。

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

3. 軟件缺陷（Ron Patton在《軟件測試》一書中提出）：只有至少滿足下列五個(gè)規(guī)則之一，才稱發(fā)生了一個(gè)軟件缺陷。

   1. 軟件未實(shí)現(xiàn)產(chǎn)品說明書要求的功能；

   2. 軟件出現(xiàn)了產(chǎn)品說明書指明不應(yīng)該出現(xiàn)的錯(cuò)誤；

   3. 軟件實(shí)現(xiàn)了產(chǎn)品說明書未提到的功能；

   4. 軟件未實(shí)現(xiàn)產(chǎn)品說明書雖未明確提及但應(yīng)該實(shí)現(xiàn)的目標(biāo)；

   5. 軟件難以理解、不易使用、運(yùn)行緩慢或者——從測試員的角度看——最終用戶會(huì)認(rèn)為不好。

4. 軟件缺陷（IEEE729-1983標(biāo)準(zhǔn)的定義）：

   • 從產(chǎn)品內(nèi)部看，缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中產(chǎn)生的錯(cuò)誤、毛病等各種問題；
   • 從產(chǎn)品外部看，缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。

5. 測試用例（IEEE1990）：測試用例是一組測試輸入、執(zhí)行條件和預(yù)期結(jié)果，目的是要滿足一個(gè)特定的目標(biāo)，比如執(zhí)行一條特定的程序路徑或檢驗(yàn)是否符合一個(gè)特定的需求的用例。

6. 測試用例（百度百科的定義）：測試用例(Test Case)是指對(duì)一項(xiàng)特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略。其內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，最終形成文檔。

7. 軟件質(zhì)量（ISO8402）：反映實(shí)體滿足明確或隱含需要能力的特征總和。

8. 軟件質(zhì)量（GB/T 11457-2006《軟件工程術(shù)語》）：軟件質(zhì)量是

   • 軟件產(chǎn)品中能滿足給定需要的性質(zhì)和特性的總體。
   • 軟件具有所期望的各種屬性的組合程度。
   • 顧客和用戶覺得軟件滿足其綜合期望的程度。
   • 確定軟件在使用中將滿足顧客預(yù)期要求的程度。

9. 靜態(tài)測試：不運(yùn)行被測程序本身，僅通過分析或檢查源程序的語法、結(jié)構(gòu)、過程、接口等來檢查程序的正確性。

10. 動(dòng)態(tài)測試：通過運(yùn)行被測程序，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，并分析運(yùn)行效率、正確性和健壯性等性能指標(biāo)。

11. 手工測試：指測試人員按照事先為覆蓋被測軟件需求而編寫的測試用例，根據(jù)測試大綱中所描述的測試步驟和方法，手工地一個(gè)一個(gè)地輸入執(zhí)行，包括與被測軟件進(jìn)行交互（如輸入測試數(shù)據(jù)、記錄測試結(jié)果等)，然后觀察測試結(jié)果，看被測程序是否存在問題，或在執(zhí)行過程中是否會(huì)有異常發(fā)生，屬于比較原始但是必須執(zhí)行的一個(gè)步驟。

12. 自動(dòng)化測試：自動(dòng)測試是將大量的重復(fù)性的測試工作交給計(jì)算機(jī)去完成，通常是使用自動(dòng)化測試工具來模擬手動(dòng)測試步驟，執(zhí)行用某種程序設(shè)計(jì)語言編寫的測試程序的過程。

13. 黑盒測試：忽略系統(tǒng)或部件的內(nèi)部機(jī)制只集中于響應(yīng)所選擇的輸入和執(zhí)行條件產(chǎn)生的輸出的一種測試。通過測試來檢測每個(gè)功能是否正常使用，通過軟件的外部表現(xiàn)來發(fā)現(xiàn)缺陷和錯(cuò)誤。

14. 白盒測試：又稱結(jié)構(gòu)測試或邏輯驅(qū)動(dòng)測試，指通過對(duì)程序內(nèi)部結(jié)構(gòu)的分析、檢測來尋找問題。

15. 灰盒測試：介于白盒測試與黑盒測試之間的一種測試，灰盒測試多用于集成測試階段，不僅關(guān)注輸出、輸入的正確性，同時(shí)也關(guān)注程序內(nèi)部的情況。

16. 單元測試（白盒）：單元測試又稱模塊測試，是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測代碼的一個(gè)很小的、很明確的功能是否正確。

    單元定義：（舉例）C中指一個(gè)函數(shù)，Java中指一個(gè)類，在圖形化的軟件中，單元一般指1個(gè)窗口，1個(gè)菜單。

17. 集成測試（灰盒）：又稱組裝測試或聯(lián)合測試。集成測試是檢驗(yàn)在單元測試的基礎(chǔ)上，將所有模塊（軟件單元)按照設(shè)計(jì)（概要設(shè)計(jì)）要求（如根據(jù)結(jié)構(gòu)圖)組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。集成測試就是測試這些軟件單元是否能夠進(jìn)行正確交互的測試。

18. 系統(tǒng)測試（黑盒）：將經(jīng)過集成測試的軟件，作為計(jì)算機(jī)系統(tǒng)的一個(gè)部分，與系統(tǒng)中其他部分結(jié)合走來，在實(shí)際運(yùn)行環(huán)境下對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行的一系列嚴(yán)格有效地測試，以發(fā)現(xiàn)軟件潛在的問題保證系統(tǒng)的正常運(yùn)行。

19. 功能測試：主要針對(duì)產(chǎn)品需求規(guī)格說明書對(duì)軟件進(jìn)行測試，逐項(xiàng)驗(yàn)收軟件功能是否符合要求。

20. 接口測試：指對(duì)各個(gè)模塊進(jìn)行系統(tǒng)聯(lián)調(diào)的測試，包含程序內(nèi)接口和程序外接口測試。

21. 性能測試：主要測試系統(tǒng)的性能是否滿足用戶要求，即在特定的運(yùn)動(dòng)條件下驗(yàn)證系統(tǒng)的能力狀況。主要是通過自動(dòng)化測試工具模擬正常、峰值及異常負(fù)載狀況，對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試，測試中得到的負(fù)荷和響應(yīng)時(shí)間等數(shù)據(jù)可以被用于驗(yàn)證軟件系統(tǒng)是否能夠達(dá)到用戶提出的性能指標(biāo)。

22. 壓力測試：是一種性能測試，指在超負(fù)荷環(huán)境中，檢驗(yàn)程序是否能夠正常運(yùn)行，檢驗(yàn)系統(tǒng)的穩(wěn)定性。

23. 負(fù)載測試：是一種性能測試，是通過測試系統(tǒng)在資源超負(fù)荷情況下的表現(xiàn)，以發(fā)現(xiàn)設(shè)計(jì)上的錯(cuò)誤或驗(yàn)證系統(tǒng)的負(fù)載能力。

簡答

軟件開發(fā)模型（瀑布模型）

1. 計(jì)劃
2. 需求分析
3. 設(shè)計(jì)
4. 程序編碼
5. 測試
6. 運(yùn)行維護(hù)

軟件測試模型

? 于2024-01-03補(bǔ)充

V模型

概念：V模型是軟件開發(fā)瀑布模型的變種，描述了基本的開發(fā)過程和測試行為，明確了測試階段與開發(fā)階段的對(duì)應(yīng)關(guān)系。V模型左側(cè)是開發(fā)過程的各個(gè)階段，右側(cè)是測試過程的各個(gè)階段，同一水平上的開發(fā)階段和測試階段存在對(duì)應(yīng)關(guān)系，每個(gè)測試階段需要測試對(duì)應(yīng)開發(fā)階段的成果物。

意義：

• 單元測試和集成測試驗(yàn)證系統(tǒng)設(shè)計(jì)。
• 系統(tǒng)測試驗(yàn)證系統(tǒng)需求。
• 驗(yàn)收測試也稱為交付測試驗(yàn)收用戶需求。

局限性：未在需求階段進(jìn)入測試，不能體現(xiàn)“盡早開展測試”的原則。

W模型

概念：W模型是對(duì)V模型的改進(jìn)，明確地描述出了測試與開發(fā)的并行關(guān)系。強(qiáng)調(diào)測試與開發(fā)同步進(jìn)行。W模型由兩個(gè)V模型組成，分別代表測試與開發(fā)過程，同一水平的開發(fā)階段與測試階段一一對(duì)應(yīng)。

意義：

• 注重在軟件開發(fā)的各個(gè)階段應(yīng)用靜態(tài)測試技術(shù)。
• 強(qiáng)調(diào)盡早展開測試。

局限性：

• 對(duì)于很多項(xiàng)目，執(zhí)行過程中并不產(chǎn)生文檔，W模型無法適用。
• 需求、設(shè)計(jì)、編碼等活動(dòng)被視為串行，測試和開發(fā)活動(dòng)保持著一種線性的前后關(guān)系。無法有效支持迭代開發(fā)模型及變更調(diào)整。
• 該模型使用起來的技術(shù)復(fù)雜度高，對(duì)于需求和設(shè)計(jì)的測試要求很高，實(shí)踐困難。

H模型

概念：H模型將測試活動(dòng)完全分割出來，使得測試準(zhǔn)備活動(dòng)和測試執(zhí)行活動(dòng)清晰地體現(xiàn)出來。在H模型中，軟件測試模型是一個(gè)獨(dú)立的流程，貫穿于整個(gè)產(chǎn)品周期，與其他流程并發(fā)地進(jìn)行。當(dāng)某個(gè)測試時(shí)間點(diǎn)就緒時(shí)，軟件測試即從測試準(zhǔn)備階段進(jìn)入測試執(zhí)行階段。圖僅僅顯示了整個(gè)測試生命同期中某個(gè)層次的“微循環(huán)”。圖中其他流程可以是任意開發(fā)流程，如設(shè)計(jì)流程和編碼流程，也可以是其他非開發(fā)流程。

軟件測試的對(duì)象

軟件 = 程序 + 數(shù)據(jù) + 文檔 + 服務(wù)

因此，軟件測試的對(duì)象是程序、數(shù)據(jù)、文檔和服務(wù)。

軟件測試的目的

軟件測試是通過設(shè)計(jì)和運(yùn)行測試用例來校驗(yàn)被測系統(tǒng)的實(shí)際輸出與預(yù)期輸出是否一致，最終目標(biāo)是保證系統(tǒng)應(yīng)符合需求。

軟件測試的基本流程

1. 需求分析
2. 制定測試計(jì)劃
3. 設(shè)計(jì)測試方案
4. 執(zhí)行測試
5. 測試評(píng)估
6. 測試總結(jié)
7. 測試維護(hù)

測試用例的主要組成

• 輸入：測試數(shù)據(jù)和測試步驟（操作步驟）；
• 輸出：系統(tǒng)預(yù)期執(zhí)行結(jié)果；
• 測試環(huán)境：系統(tǒng)環(huán)境設(shè)置，即進(jìn)行軟件測試所必需的工作平臺(tái)和前提條件。

測試用例的基本屬性

• 典型性（代表性）：能揭示最有可能存在缺陷的地方，能代表和覆蓋合理與不合理、合法或不合法的情況。
• 可測試性（可判定性）：一個(gè)測試用例的預(yù)期輸出必須是可以檢驗(yàn)的，可以根據(jù)相關(guān)開發(fā)文檔得到明確的、可判定的結(jié)論。
• 可重現(xiàn)性：對(duì)于相同的測試用例，系統(tǒng)的預(yù)期執(zhí)行結(jié)果應(yīng)該完全相同。否則，如果系統(tǒng)預(yù)期輸出存在不確定性，一旦實(shí)際運(yùn)行該測試用例，也無法進(jìn)行校驗(yàn)。
• 獨(dú)立性：測試用例應(yīng)盡量獨(dú)立。

測試用例設(shè)計(jì)原則

根據(jù)《GB/T15532一2008計(jì)算機(jī)軟件測試規(guī)范》，設(shè)計(jì)測試用例時(shí)，應(yīng)遵循以下原則：

1. 基于測試需求的原則
   按照測試類別的不同要求設(shè)計(jì)測試用例。
2. 基于測試方法的原則
   比較成熟的測試用例設(shè)計(jì)方法與豐富的實(shí)踐經(jīng)驗(yàn)相融合才能設(shè)計(jì)出高品質(zhì)的測試用例。
3. 兼顧測試充分性和效率的原則
   測試用例集應(yīng)兼顧測試的充分性和測試的效率，每個(gè)測試用例的內(nèi)容也應(yīng)完整，具有可操作性。
4. 測試執(zhí)行的可再現(xiàn)性原則
   應(yīng)保證測試用例執(zhí)行的可再現(xiàn)性。

軟件質(zhì)量的特性（ISO/IEC 9126）

1. 功能性
2. 可靠性
3. 易用性
4. 效率
5. 可維護(hù)性
6. 可移植性

軟件測試基本原則（10條）

? 于2024-01-03補(bǔ)充

1. 盡早測試：盡早發(fā)現(xiàn)軟件缺陷，降低缺陷的修復(fù)成本。

2. 全面測試：兩層含義(1)對(duì)產(chǎn)品進(jìn)行全面的測試，(2)開發(fā)人員、測試人員、甚至用戶，全面地參與到測試工作中。

3. 全過程測試：兩層含義(1)測試人員充分關(guān)注開發(fā)全過程，(2)測試人員對(duì)測試全過程進(jìn)行全程跟蹤。

4. 獨(dú)立的、迭代的測試：兩層含義(1)將測試過程從開發(fā)過程中抽離，作為獨(dú)立過程，(2)由獨(dú)立的專業(yè)的軟件測試機(jī)構(gòu)完成。

5. Patero原則(缺陷聚集)：少數(shù)系統(tǒng)模塊分布了大部分缺陷。

   如果一個(gè)模塊已發(fā)現(xiàn)許多錯(cuò)誤，則剩余錯(cuò)誤可能很多，越需要進(jìn)行深入和多次測試。

6. 對(duì)測試出的結(jié)果一定要有一個(gè)確認(rèn)的過程。

7. 制訂嚴(yán)格的測試計(jì)劃。

8. 窮盡測試是不可能的，測試需要終止。（需要精心設(shè)計(jì)測試優(yōu)先級(jí)）

9. 注意回歸測試的關(guān)聯(lián)性。（注意修復(fù)一個(gè)錯(cuò)誤而引發(fā)更多錯(cuò)誤的現(xiàn)象）

10. 妥善保存一切測試過程文檔。（測試的重現(xiàn)性需要測試文檔）

補(bǔ)充：測試應(yīng)基于客戶要求。

總結(jié)

軟件測試

• 根本目的：確保被測系統(tǒng)符合用戶需求
• 基本過程：設(shè)計(jì)測試用例、執(zhí)行測試用例
• 測試手段：手工/自動(dòng)化
• 測試方式：動(dòng)態(tài)運(yùn)行（動(dòng)態(tài)測試）/靜態(tài)審閱（靜態(tài)測試）
• 基本流程：需求分析、計(jì)劃、設(shè)計(jì)、執(zhí)行、評(píng)估、總結(jié)、維護(hù)

軟件測試可以驗(yàn)證軟件質(zhì)量，但不能提高軟件質(zhì)量。

提高軟件質(zhì)量的途徑是改進(jìn)軟件開發(fā)過程的質(zhì)量。文章來源地址http://www.zghlxwxcb.cn/news/detail-765458.html

到了這里，關(guān)于[軟件測試] 第一部分 軟件測試基礎(chǔ)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！