第一篇：軟件測試技術(shù)總結(jié)

IT公司面試手冊提供最全的IT類面試題, 包括

Java：Java面試題 J2EE面試題 Hibernate面試題 Spring面試題Struts面試題EJB面試題.NET:.net面試題 ASP.NET面試題 C#面試題

數(shù)據(jù)庫：數(shù)據(jù)庫面試題Oracle面試題 SQL Server面試題 MySql面試題

網(wǎng)絡(luò)：網(wǎng)絡(luò)技術(shù)面試題 網(wǎng)絡(luò)安全面試題

Web開發(fā)：PHP面試題 Web開發(fā)面試題

Linux Unix：Unix面試題Linux面試題

軟件測試： 軟件測試面試題

其他類： 英語面試 外企面試 Python面試題 程序員面試

更多面試題請訪問： http://

軟件測試技術(shù)總結(jié)

軟件測試就是為了發(fā)現(xiàn)程序中的錯誤而分析和執(zhí)行程序的過程。——概念

+基本知識+軟件開發(fā)過程-定義-計劃-實現(xiàn)-穩(wěn)定化-部署

一、軟件開發(fā)模型(四種典型的模型)

1、瀑布模型

概述：包括計劃，需求分析，設(shè)計，編碼，測試，運(yùn)行維護(hù)六個階段。六個階段自上而下、相互銜接，以固定的次序進(jìn)行。

特點：1.階段的順序性和依賴性；2.文檔驅(qū)動；3.推遲實現(xiàn)的觀點； 4.質(zhì)量保證。

缺點：不適合需求模糊的系統(tǒng)

2、原型模型

概述：先建立一個能夠反映用戶需求的原型系統(tǒng)，使得用戶和開發(fā)者可以對目標(biāo)系統(tǒng)的概貌進(jìn)行評價和判斷，然后對原型系統(tǒng)進(jìn)行反復(fù)的擴(kuò)充、改進(jìn)、求精，最終建立符合用戶需求的目標(biāo)系統(tǒng)。

特點：1.快速開發(fā)工具；2.循環(huán)； 3.低成本。

分類：按照對原型的處理方式，可以分為漸進(jìn)型和拋棄型。

3、增量模型

概述：在增量模型中每個階段都生成軟件的一個可發(fā)布版本，階段交錯進(jìn)行，版本逐漸完善。同原型模型的最大區(qū)別在于，在原型模型中每個階段發(fā)布一個原型而在增量模型中則完成一個正式版本。

4、螺旋模型

概述：適用于大型軟件的開發(fā)，它將瀑布模型和快速原型模型結(jié)合起來，并加入了風(fēng)險分析。特點：1.每個階段都包括制定計劃，風(fēng)險分析，實施工程，評審四個階段；2.開發(fā)過程迭代進(jìn)行，每迭代一次螺旋線增一周，工程前進(jìn)一個層次，系統(tǒng)生成一個新版本，投入新的時間成本，最終得到客戶滿意的版本。-軟件測試從需求開始：現(xiàn)代的軟件測試將測試滲入到軟件開發(fā)的各個階段，即使瀑布模型，表面看測試工作是在測試階段開始的，事實上，在計劃、需求、設(shè)計階段，測試人員便已經(jīng)開始了他們的工作，如：了解軟件需求，編寫測試計劃，搭建測試環(huán)境。

二、測試用例

1、三要素：前提條件和操作步驟、預(yù)期結(jié)果、實際結(jié)果。

2、必須以需求為依據(jù)。

三、軟件測試分類

1、是否關(guān)注軟件結(jié)構(gòu)和算法

-黑盒測試：基于軟件需求的測試方法。-白盒測試：基于軟件內(nèi)部設(shè)計和程序?qū)崿F(xiàn)的測試方法。

2、是否執(zhí)行被測試軟件

-動態(tài)測試：在測試過程中執(zhí)行被測試軟件的測試方法。-靜態(tài)測試：------------不----------------------。

3、基于不同的測試階段：

1、單元測試：主要測試軟件的單元模塊，需要編寫額外的測試驅(qū)動程序，采用白盒測試的方法，一般由 開發(fā)人員完成。

2、集成測試：將一些“構(gòu)件”集成在一起時測試他們是否能正常運(yùn)行，構(gòu)件可以是程序模塊，也可以是客戶機(jī)-服務(wù)器程序等，需要編寫測試仿真程序，采用白盒和黑盒相結(jié)合的方式，通常由 開發(fā)人員承擔(dān)。

3、系統(tǒng)測試：測試軟件系統(tǒng)是否符合所有的需求，包括功能性測試和非功能性測試。一般由獨立的測試人員完成，通常采用黑盒測試方法。

4、驗收測試：(α、β)與系統(tǒng)測試類似，但由客戶或最終用戶執(zhí)行，測試軟件是否符合需求規(guī)格說明書。

5、回歸測試：指在軟件開發(fā)過程中，每次錯誤被修正后或軟件的功能、環(huán)境發(fā)生變化后進(jìn)行的測試。

四、軟件測試的三個步驟：

1、測試計劃：測試人員首先對需求進(jìn)行分析，最終定義一個測試集合，通過刻畫和定義測試發(fā)現(xiàn)需求中的問題，然后根據(jù)軟件需求同測試主管制定并確認(rèn)“測試計劃”。

2、測試設(shè)計和開發(fā)：軟件測試人員根據(jù)軟件需求和軟件設(shè)計說明書完成測試用例的設(shè)計和必要的測試驅(qū)動程序的開發(fā)。

3、執(zhí)行測試：需要做的工作包括搭建測試環(huán)境、運(yùn)行測試、記錄測試結(jié)果、報告軟件缺陷、跟蹤軟件缺陷、分析測試結(jié)果，必要時進(jìn)行回歸測試。

五、測試工程師的能力要求：

1、5C

-Controlled /kEn'trEuld/ 接受管理，有條理的-Competent /'kCmpitEnt/了解正確的測試技術(shù)

-Critical /'kritikEl/專注于發(fā)現(xiàn)問題

-Comprehensive /.kCmpri'hensiv/ 注意細(xì)節(jié)

-Considerate /kEn'sidErit/能夠和開發(fā)人員很好的交談

2、職業(yè)素質(zhì)-責(zé)任心-學(xué)習(xí)能力-懷疑精神-溝通能力-專注力-洞察力-團(tuán)隊精神-注重積累

六、制定測試計劃的五個步驟：

1、分析和測試軟件需求

2、定義測試策略

3、定義測試環(huán)境

4、定義測試管理

5、編寫和審核測試計劃

如果在需求分析階段發(fā)現(xiàn)并結(jié)果問題需要花費(fèi)$1，則在設(shè)計階段解決同樣的問題需花費(fèi)$5，在編碼階段需$10，交付后解決同樣的問題需花費(fèi)$200?！皆鐪y試越好

七、在需求分析過程中測試人員需要進(jìn)行如下工作：

1)理解需求，參與審核需求文檔；2)理解項目的目標(biāo)、限制，了解用戶的應(yīng)用背景；

3)編寫測試計劃；4)準(zhǔn)備測試資源。

八、需求測試

-需求測試測試的對象是主意而不是代碼，針對文檔進(jìn)行測試。

九、好的需求文檔的特征

1、具有清晰的格式和文檔結(jié)構(gòu)

2、需求的內(nèi)容正確

3、需求的內(nèi)容完整

4、需求具有可行性需求的必要性

5、對不同的需求優(yōu)先等級進(jìn)行定義

6、描述明確

7、可證性和可測試性

8、可修改性-可追蹤

9、需求文檔被及時更新

十、需求測試內(nèi)容

1、需求文檔是否符合公司的格式要求

2、是否正確

3、要保證需求文檔中所描述的內(nèi)容是真實可靠的4、這是“真正的”需求嗎？描述的產(chǎn)品是否是要開發(fā)的產(chǎn)品？

5、需求是否完備？第一個發(fā)布的版本是否需要更多的功能？列出的需求可以減少一部分？

6、需求是否兼容？需求有可能是矛盾的。

7、需求是否可實現(xiàn)？如：需求設(shè)想的設(shè)備是否比實際運(yùn)行的要快？需求要求的內(nèi)存、I/0設(shè)備是否太多？需求的輸入或輸出設(shè)備要求的分辨率是否要求過高？

8、需求是否合理？在開發(fā)進(jìn)度、開發(fā)費(fèi)用、產(chǎn)品性能、可靠性和內(nèi)存使用之間存在著平衡關(guān)系。

9、需求是否可測？對于軟件測試人員來說判斷需求是否可測是這個過程中最重要的工作。

十一、需求測試方法

1、復(fù)查review2、走查walkthrough3、審查inspection

十二、測試策略的內(nèi)容

1、確定測試范圍 軟件是無法被完全測試的2、確定測試方法 不同的系統(tǒng)需要不同的測試方法

3、定義測試標(biāo)準(zhǔn) 入口標(biāo)準(zhǔn)，暫停和繼續(xù)的標(biāo)準(zhǔn)，出口標(biāo)準(zhǔn)等

十三、軟件測試結(jié)束的標(biāo)準(zhǔn)

-基于測試用例的使用規(guī)則

1)構(gòu)造測試用例（由相關(guān)人員進(jìn)行評審）

2)執(zhí)行測試用例中，當(dāng)測試用例的不通過率達(dá)到20%則拒絕繼續(xù)測試，待開發(fā)人員修正軟件后再繼續(xù)。

3)當(dāng)功能性測試用例通過率達(dá)到100%，非功能性測試用例通過率達(dá)到90%時，允許正常結(jié)束。

-基于“測試期缺陷密度”規(guī)則---------含義：對軟件測試一個CPU小時發(fā)現(xiàn)的缺陷數(shù)，比較適用于系統(tǒng)測試-基于“運(yùn)行期缺陷密度”規(guī)則---------含義：把軟件運(yùn)行一個CPU小時發(fā)現(xiàn)的缺陷數(shù)，比較適用于驗收測試注：一個階段的出口標(biāo)準(zhǔn)!=下一個階段的入口標(biāo)準(zhǔn)

系統(tǒng)測試結(jié)束的標(biāo)準(zhǔn)!=軟件的發(fā)布標(biāo)準(zhǔn)發(fā)布標(biāo)準(zhǔn)!=軟件0缺陷

-選擇測試工具 是否需要，需要什么工具，怎么獲取

-降低軟件測試代價是企業(yè)普遍關(guān)注的問題，可通過

a.減少冗余和無價值的測試；b.減少測試階段(萬般無奈下)

十四、測試環(huán)境

-基本內(nèi)容：設(shè)備環(huán)境、軟件環(huán)境、數(shù)據(jù)環(huán)境

-需考慮的因素-計算機(jī)平臺-操作系統(tǒng)-瀏覽器-軟件支持平臺-外圍設(shè)備-網(wǎng)絡(luò)環(huán)境-其他專用設(shè)備-搭建測試環(huán)境時的配置原則：-使用的頻度或范圍-實效的可能性-最大限度的模擬真實環(huán)境

十五、測試管理

由于測試工程中設(shè)計的人員、活動、工具是很多的，在制定測試計劃時需要對這些因素進(jìn)行管理-選擇缺陷管理工具和測試管理工具-定義工作進(jìn)度

-建立風(fēng)險管理計劃

(1)可能遇到的風(fēng)險

1.由于設(shè)計、編碼階段出現(xiàn)大量質(zhì)量問題，導(dǎo)致測試工作量時間增加

2.開始測試時所需的硬件、軟件沒有準(zhǔn)備好3.未能完成對測試人員的技術(shù)培訓(xùn)

4.測試時的人力資源安排不足5.測試過程中，發(fā)生了大量的需求變更

6.測試過程中，項目的開發(fā)計劃被大幅度調(diào)整7.不能及時準(zhǔn)備好測試所需的環(huán)境

8.不能及時準(zhǔn)備好測試數(shù)據(jù)

(2)風(fēng)險管理的過程

1.識別風(fēng)險2.評估風(fēng)險3.制定對策4.跟蹤風(fēng)險

+測試設(shè)計與開發(fā)

+總體設(shè)計

-投入產(chǎn)出：測試設(shè)計的輸入是測試計劃，輸出是評審過的測試用例集合-定義設(shè)計目標(biāo)遵循的原則

(-清楚地說明沒項測試的目標(biāo)-使每項測試的目標(biāo)單一，可以對應(yīng)到規(guī)格說明書中的一項需求-只說明測試應(yīng)該完成什么工作，而不說明如何完成)

-流程：總體設(shè)計-開發(fā)測試用例-評審測試用例

I.定義設(shè)計目標(biāo)II.定義輸入說明III.定義測試環(huán)境和配置

IV.測試設(shè)計文檔V.開發(fā)測試用例

+測試用例——概念：為特定目標(biāo)開發(fā)的測試輸入、執(zhí)行條件和預(yù)期結(jié)果的集合。

+好的測試用例：

1.容易發(fā)現(xiàn)軟件的錯誤2.精確的重復(fù)某測試失敗的情景，可重復(fù)性

3.清晰的定義一個或多個期望的結(jié)果4.沒有冗余

+測試用例的作用

-指導(dǎo)測試的實施-作為編寫測試腳本的“設(shè)計規(guī)格說明書”-評估測試標(biāo)準(zhǔn)的度量基準(zhǔn)-分析缺陷的標(biāo)準(zhǔn) +白盒測試用例設(shè)計

+設(shè)計方法

+邏輯覆蓋法

(-語句覆蓋-判定覆蓋-條件覆蓋-判定-條件覆蓋-條件組合覆蓋-路經(jīng)覆蓋-基本路經(jīng)法)

+輔助模塊設(shè)計

(1.驅(qū)動模塊：相當(dāng)于被測程序的主程序。接受測試數(shù)據(jù)，把這些數(shù)據(jù)傳給被測模塊然后輸出實際測試結(jié)果。

2.樁模塊：用于調(diào)用被測模塊調(diào)用的子模塊?？梢宰錾倭康臄?shù)據(jù)操作，不需要把子模塊的所有功能都帶進(jìn)來，但不容許什么都不做。)

+黑盒測試用例設(shè)計

-等價類劃分法

-邊界值法——“缺陷遺漏在角落里，聚集在邊界上?！?/p>

-因果圖法彌補(bǔ)等價類和邊界值法的不足

-錯誤推測法

-測試用例的管理可以通過配置管理工具cvs,vss,ClearCase等實現(xiàn)，以保證測試是可重復(fù)的。

+常見錯誤分析

-用戶界面問題

·輸入無合法性檢查和值域檢查。

·界面信息不能及時更新，不能正確反映數(shù)據(jù)狀態(tài)，甚至對用戶產(chǎn)生誤導(dǎo)。

·表達(dá)不清或過于模糊的信息提示。

·要求用戶輸入多余的本來系統(tǒng)可以自己得到的數(shù)據(jù)。

·為了得到某個設(shè)置或?qū)υ捒蛴脩舯仨氉鲈S多冗余的操作，如對話框嵌套太多。

·不能記憶用戶的設(shè)置或操作習(xí)慣，使每次進(jìn)入系統(tǒng)用戶都需重新操作一次初始環(huán)境。

·不經(jīng)用戶確認(rèn)就對系統(tǒng)或數(shù)據(jù)進(jìn)行了重大修改。

-形象類問題

·不符合用戶的操作習(xí)慣。如，快捷鍵定義不科學(xué)不實用，甚至無快捷鍵。

·不夠?qū)I(yè)，缺乏基本知識。

·界面中英文混雜，甚至拼寫錯誤。

·說明書或幫助的排版格式不專業(yè)：中英文不對應(yīng)，標(biāo)點的半全角問題，沒有排版準(zhǔn)則。

·界面元素參差不齊，文字不能完全顯示。

－穩(wěn)定性問題

·不可重現(xiàn)的死機(jī)，或不斷申請但不能完全釋放資源，使系統(tǒng)性能越來越低。

·主系統(tǒng)和子系統(tǒng)使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時文件名、使用同樣的數(shù)據(jù)庫字段名或登陸帳號。

·不能重現(xiàn)的錯誤，許多與代碼中的未初始化變量有關(guān)，有些與系統(tǒng)不檢查異常情況(網(wǎng)絡(luò)中斷、內(nèi)存申請不成功、長時間無響應(yīng)等)有關(guān)。

-其他問題

·運(yùn)行時不檢查內(nèi)存、硬盤空間、數(shù)據(jù)庫等。

·無根據(jù)的假設(shè)用戶環(huán)境：硬件/網(wǎng)絡(luò)情況；有些動態(tài)庫；假設(shè)網(wǎng)絡(luò)隨時都是聯(lián)通的。

·提供的版本帶病毒。

·提供錯誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。

·用戶現(xiàn)場開放和修改，又沒有記錄和保留。

·版本中部分內(nèi)容或接口倒退，或出現(xiàn)版本管理混亂。

·有些選項永遠(yuǎn)都是灰的，或有些在該變灰時沒變灰。

+測試用例的評審

-測試或測試組件完全針對的是需求中列出的功能嗎？

-測試組件是否覆蓋了所有的需求？

-有冗余的嗎？

-每個測試步驟都有清楚描述的預(yù)期結(jié)果嗎？

+優(yōu)先級

+3級

優(yōu)先級1：此測試用例必須執(zhí)行-2：有時間就執(zhí)行-3：可以不執(zhí)行

+5級

1：此測試必須通過，否則產(chǎn)品發(fā)布存在危險2：在發(fā)布前必須執(zhí)行3：時間允許就執(zhí)行4：此測試可以在下一次發(fā)布或發(fā)布后短期內(nèi)執(zhí)行5：可以不測試

第二篇：軟件測試技術(shù)面試總結(jié)

軟件測試就是為了發(fā)現(xiàn)程序中的錯誤而分析和執(zhí)行程序的過程?！拍?/p>

+基本知識+軟件開發(fā)過程-定義-計劃-實現(xiàn)-穩(wěn)定化-部署

+軟件開發(fā)模型(四種典型的模型)

+瀑布模型

-概述：包括計劃，需求分析，設(shè)計，編碼，測試，運(yùn)行維護(hù)六個階段。六個階段自上而下、相互銜接，以固定的次序進(jìn)行。

-特點：1.階段的順序性和依賴性；2.文檔驅(qū)動； 3.推遲實現(xiàn)的觀點；4.質(zhì)量保證。-缺點：不適合需求模糊的系統(tǒng)

+原型模型-概述：先建立一個能夠反映用戶需求的原型系統(tǒng)，使得用戶和開發(fā)者可以對目標(biāo)系統(tǒng)的概貌進(jìn)行評價和判斷，然后對原型系統(tǒng)進(jìn)行反復(fù)的擴(kuò)充、改進(jìn)、求精，最終建立符合用戶需求的目標(biāo)系統(tǒng)。

-特點：1.快速開發(fā)工具；2.循環(huán)； 3.低成本。

-分類：按照對原型的處理方式，可以分為漸進(jìn)型和拋棄型。

+增量模型

-概述：在增量模型中每個階段都生成軟件的一個可發(fā)布版本，階段交錯進(jìn)行，版本逐漸完善。

-同原型模型的最大區(qū)別在于，在原型模型中每個階段發(fā)布一個原型而在增量模型中則完成一個正式版本。+螺旋模型

-概述：適用于大型軟件的開發(fā)，它將瀑布模型和快速原型模型結(jié)合起來，并加入了風(fēng)險分析。

-特點：1.每個階段都包括制定計劃，風(fēng)險分析，實施工程，評審四個階段；

2.開發(fā)過程迭代進(jìn)行，每迭代一次螺旋線增一周，工程前進(jìn)一個層次，系統(tǒng)生成一個新版本，投入新的時間成本，最終得到客戶滿意的版本。

-軟件測試從需求開始：現(xiàn)代的軟件測試將測試滲入到軟件開發(fā)的各個階段，即使瀑布模型，表面看測試工作是在測試階段開始的，事實上，在計劃、需求、設(shè)計階段，測試人員便已經(jīng)開始了他們的工作，如：了解軟件需求，編寫測試計劃，搭建測試環(huán)境。

-測試用例

-三要素：前提條件和操作步驟、預(yù)期結(jié)果、實際結(jié)果。

-必須以需求為依據(jù)。

-軟件測試分類

-是否關(guān)注軟件結(jié)構(gòu)和算法

-黑盒測試：基于軟件需求的測試方法。

-白盒測試：基于軟件內(nèi)部設(shè)計和程序?qū)崿F(xiàn)的測試方法。

-是否執(zhí)行被測試軟件

-動態(tài)測試：在測試過程中執(zhí)行被測試軟件的測試方法。

-靜態(tài)測試：------------不----------------------。

-基于不同的測試階段：

-單元測試：主要測試軟件的單元模塊，需要編寫額外的測試驅(qū)動程序，采用白盒測試的方法，一般由 開發(fā)人員完成。

-集成測試：將一些“構(gòu)件”集成在一起時測試他們是否能正常運(yùn)行，構(gòu)件可以是程序模塊，也可以是

客戶機(jī)-服務(wù)器程序等，需要編寫測試仿真程序，采用白盒和黑盒相結(jié)合的方式，通常由 開發(fā)人員承擔(dān)。

-系統(tǒng)測試：測試軟件系統(tǒng)是否符合所有的需求，包括功能性測試和非功能性測試。一般由

獨立的測試

人員完成，通常采用黑盒測試方法。

-驗收測試：(α、β)與系統(tǒng)測試類似，但由客戶或最終用戶執(zhí)行，測試軟件是否符合需求規(guī)格說明書。

-回歸測試：指在軟件開發(fā)過程中，每次錯誤被修正后或軟件的功能、環(huán)境發(fā)生變化后進(jìn)行的測試。

-軟件測試的三個步驟：

-測試計劃：測試人員首先對需求進(jìn)行分析，最終定義一個測試集合，通過刻畫和定義測試發(fā)現(xiàn)需求中的問題，然后根據(jù)軟件需求同測試主管制定并確認(rèn)“測試計劃”。

-測試設(shè)計和開發(fā)：軟件測試人員根據(jù)軟件需求和軟件設(shè)計說明書完成測試用例的設(shè)計和必要的測試驅(qū)動 程序的開發(fā)。

-執(zhí)行測試：需要做的工作包括搭建測試環(huán)境、運(yùn)行測試、記錄測試結(jié)果、報告軟件缺陷、跟蹤軟件缺陷、分析測試結(jié)果，必要時進(jìn)行回歸測試。

-測試工程師的能力要求：

+5C

-Controlled /kEn'trEuld/ 接受管理，有條理的-Competent /'kCmpitEnt/了解正確的測試技術(shù)

-Critical /'kritikEl/專注于發(fā)現(xiàn)問題

-Comprehensive /.kCmpri'hensiv/ 注意細(xì)節(jié)

-Considerate /kEn'sidErit/能夠和開發(fā)人員很好的交談

+職業(yè)素質(zhì)-責(zé)任心-學(xué)習(xí)能力-懷疑精神-溝通能力-專注力-洞察力-團(tuán)隊精神-注重積累 +制定測試計劃的五個步驟：-分析和測試軟件需求-定義測試策略

-定義測試環(huán)境

-定義測試管理

-編寫和審核測試計劃

如果在需求分析階段發(fā)現(xiàn)并結(jié)果問題需要花費(fèi)$1，則在設(shè)計階段解決同樣的問題需花費(fèi)$5，在編碼階段需$10，交付后解決同樣的問題需花費(fèi)$200?！皆鐪y試越好-在需求分析過程中測試人員需要進(jìn)行如下工作：

1)理解需求，參與審核需求文檔；

2)理解項目的目標(biāo)、限制，了解用戶的應(yīng)用背景；

3)編寫測試計劃；

4)準(zhǔn)備測試資源。

+需求測試

-需求測試測試的對象是主意而不是代碼，針對文檔進(jìn)行測試。

+好的需求文檔的特征-具有清晰的格式和文檔結(jié)構(gòu)-需求的內(nèi)容正確-需求的內(nèi)容完整-需求具有可行性需求的必要性

-對不同的需求優(yōu)先等級進(jìn)行定義-描述明確-可證性和可測試性-可修改性-可追蹤-需求文檔被及時更新

+需求測試內(nèi)容

-需求文檔是否符合公司的格式要求

-是否正確

-要保證需求文檔中所描述的內(nèi)容是真實可靠的-這是“真正的”需求嗎？描述的產(chǎn)品是否是要開發(fā)的產(chǎn)品？

-需求是否完備？第一個發(fā)布的版本是否需要更多的功能？列出的需求可以減少一部分？-需求是否兼容？需求有可能是矛盾的。

-需求是否可實現(xiàn)？如：需求設(shè)想的設(shè)備是否比實際運(yùn)行的要快？需求要求的內(nèi)存、I/0設(shè)備是否太多？

需求的輸入或輸出設(shè)備要求的分辨率是否要求過高？

-需求是否合理？在開發(fā)進(jìn)度、開發(fā)費(fèi)用、產(chǎn)品性能、可靠性和內(nèi)存使用之間存在著平衡關(guān)系。

-需求是否可測？對于軟件測試人員來說判斷需求是否可測是這個過程中最重要的工作。+需求測試方法-復(fù)查review-走查walkthrough-審查inspection

+測試策略的內(nèi)容

-確定測試范圍 軟件是無法被完全測試的-確定測試方法 不同的系統(tǒng)需要不同的測試方法

-定義測試標(biāo)準(zhǔn) 入口標(biāo)準(zhǔn)，暫停和繼續(xù)的標(biāo)準(zhǔn)，出口標(biāo)準(zhǔn)等

+軟件測試結(jié)束的標(biāo)準(zhǔn)

-基于測試用例的使用規(guī)則

1)構(gòu)造測試用例（由相關(guān)人員進(jìn)行評審）

2)執(zhí)行測試用例中，當(dāng)測試用例的不通過率達(dá)到20%則拒絕繼續(xù)測試，待開發(fā)人員修正軟件后再繼續(xù)。

3)當(dāng)功能性測試用例通過率達(dá)到100%，非功能性測試用例通過率達(dá)到90%時，允許正常結(jié)束。

-基于“測試期缺陷密度”規(guī)則

--------------含義：對軟件測試一個CPU小時發(fā)現(xiàn)的缺陷數(shù)，比較適用于系統(tǒng)測試-基于“運(yùn)行期缺陷密度”規(guī)則

--------------含義：把軟件運(yùn)行一個CPU小時發(fā)現(xiàn)的缺陷數(shù)，比較適用于驗收測試注：一個階段的出口標(biāo)準(zhǔn)!=下一個階段的入口標(biāo)準(zhǔn)

系統(tǒng)測試結(jié)束的標(biāo)準(zhǔn)!=軟件的發(fā)布標(biāo)準(zhǔn)

發(fā)布標(biāo)準(zhǔn)!=軟件0缺陷

-選擇測試工具 是否需要，需要什么工具，怎么獲取

-降低軟件測試代價是企業(yè)普遍關(guān)注的問題，可通過

a.減少冗余和無價值的測試；

b.減少測試階段(萬般無奈下)

+測試環(huán)境

-基本內(nèi)容：設(shè)備環(huán)境、軟件環(huán)境、數(shù)據(jù)環(huán)境

-需考慮的因素-計算機(jī)平臺-操作系統(tǒng)-瀏覽器-軟件支持平臺-外圍設(shè)備-網(wǎng)絡(luò)環(huán)境-其他專用設(shè)備

-搭建測試環(huán)境時的配置原則：-使用的頻度或范圍-實效的可能性-最大限度的模擬真實環(huán)境 +測試管理 由于測試工程中設(shè)計的人員、活動、工具是很多的，在制定測試計劃時需要對這些因素進(jìn)行管理

-選擇缺陷管理工具和測試管理工具

-定義工作進(jìn)度

-建立風(fēng)險管理計劃

+可能遇到的風(fēng)險

·由于設(shè)計、編碼階段出現(xiàn)大量質(zhì)量問題，導(dǎo)致測試工作量時間增加

·開始測試時所需的硬件、軟件沒有準(zhǔn)備好

·未能完成對測試人員的技術(shù)培訓(xùn)

·測試時的人力資源安排不足

·測試過程中，發(fā)生了大量的需求變更

·測試過程中，項目的開發(fā)計劃被大幅度調(diào)整

·不能及時準(zhǔn)備好測試所需的環(huán)境

·不能及時準(zhǔn)備好測試數(shù)據(jù)

+風(fēng)險管理的過程

·識別風(fēng)險

·評估風(fēng)險

·制定對策

·跟蹤風(fēng)險

+測試設(shè)計與開發(fā)

+總體設(shè)計

-投入產(chǎn)出：測試設(shè)計的輸入是測試計劃，輸出是評審過的測試用例集合-定義設(shè)計目標(biāo)遵循的原則

-清楚地說明沒項測試的目標(biāo)

-使每項測試的目標(biāo)單一，可以對應(yīng)到規(guī)格說明書中的一項需求

-只說明測試應(yīng)該完成什么工作，而不說明如何完成-流程：總體設(shè)計-開發(fā)測試用例-評審測試用例

I.定義設(shè)計目標(biāo)

II.定義輸入說明

III.定義測試環(huán)境和配置

IV.測試設(shè)計文檔

V.開發(fā)測試用例

+測試用例

-概念：為特定目標(biāo)開發(fā)的測試輸入、執(zhí)行條件和預(yù)期結(jié)果的集合。

+好的測試用例：

-容易發(fā)現(xiàn)軟件的錯誤

-精確的重復(fù)某測試失敗的情景，可重復(fù)性

-清晰的定義一個或多個期望的結(jié)果

-沒有冗余

+測試用例的作用

-指導(dǎo)測試的實施

-作為編寫測試腳本的“設(shè)計規(guī)格說明書”

-評估測試標(biāo)準(zhǔn)的度量基準(zhǔn)

-分析缺陷的標(biāo)準(zhǔn)

+白盒測試用例設(shè)計

+設(shè)計方法

+邏輯覆蓋法

-語句覆蓋

-判定覆蓋

-條件覆蓋

-判定-條件覆蓋

-條件組合覆蓋

-路經(jīng)覆蓋

-基本路經(jīng)法

+輔助模塊設(shè)計

-驅(qū)動模塊：相當(dāng)于被測程序的主程序。接受測試數(shù)據(jù)，把這些數(shù)據(jù)傳給被測模塊然后輸出實際測試結(jié)果。

-樁模塊：用于調(diào)用被測模塊調(diào)用的子模塊?？梢宰錾倭康臄?shù)據(jù)操作，不需要把子模塊的所有功能都帶進(jìn)來，但不容許什么都不做。

+黑盒測試用例設(shè)計

-等價類劃分法

-邊界值法——“缺陷遺漏在角落里，聚集在邊界上?！?/p>

-因果圖法彌補(bǔ)等價類和邊界值法的不足

-錯誤推測法

-測試用例的管理可以通過配置管理工具cvs,vss,ClearCase等實現(xiàn)，以保證測試是可重復(fù)的。+常見錯誤分析

-用戶界面問題

·輸入無合法性檢查和值域檢查。

·界面信息不能及時更新，不能正確反映數(shù)據(jù)狀態(tài)，甚至對用戶產(chǎn)生誤導(dǎo)。

·表達(dá)不清或過于模糊的信息提示。

·要求用戶輸入多余的本來系統(tǒng)可以自己得到的數(shù)據(jù)。

·為了得到某個設(shè)置或?qū)υ捒蛴脩舯仨氉鲈S多冗余的操作，如對話框嵌套太多?！げ荒苡洃浻脩舻脑O(shè)置或操作習(xí)慣，使每次進(jìn)入系統(tǒng)用戶都需重新操作一次初始環(huán)境?！げ唤?jīng)用戶確認(rèn)就對系統(tǒng)或數(shù)據(jù)進(jìn)行了重大修改。

-形象類問題

·不符合用戶的操作習(xí)慣。如，快捷鍵定義不科學(xué)不實用，甚至無快捷鍵。

·不夠?qū)I(yè)，缺乏基本知識。

·界面中英文混雜，甚至拼寫錯誤。

·說明書或幫助的排版格式不專業(yè)：中英文不對應(yīng)，標(biāo)點的半全角問題，沒有排版準(zhǔn)則?！そ缑嬖貐⒉畈积R，文字不能完全顯示。

－穩(wěn)定性問題

·不可重現(xiàn)的死機(jī)，或不斷申請但不能完全釋放資源，使系統(tǒng)性能越來越低。

·主系統(tǒng)和子系統(tǒng)使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時文件名、使用同樣的數(shù)據(jù)庫字段名或登陸帳號。

·不能重現(xiàn)的錯誤，許多與代碼中的未初始化變量有關(guān)，有些與系統(tǒng)不檢查異常情況(網(wǎng)絡(luò)中斷、內(nèi)存申請

不成功、長時間無響應(yīng)等)有關(guān)。

-其他問題

·運(yùn)行時不檢查內(nèi)存、硬盤空間、數(shù)據(jù)庫等。

·無根據(jù)的假設(shè)用戶環(huán)境：硬件/網(wǎng)絡(luò)情況；有些動態(tài)庫；假設(shè)網(wǎng)絡(luò)隨時都是聯(lián)通的?！ぬ峁┑陌姹編Р《?。

·提供錯誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。

·用戶現(xiàn)場開放和修改，又沒有記錄和保留。

·版本中部分內(nèi)容或接口倒退，或出現(xiàn)版本管理混亂。

·有些選項永遠(yuǎn)都是灰的，或有些在該變灰時沒變灰。

+測試用例的評審

-測試或測試組件完全針對的是需求中列出的功能嗎？

-測試組件是否覆蓋了所有的需求？

-有冗余的嗎？

-每個測試步驟都有清楚描述的預(yù)期結(jié)果嗎？

+優(yōu)先級

+3級

優(yōu)先級1：此測試用例必須執(zhí)行-2：有時間就執(zhí)行-3：可以不執(zhí)行

+5級

1：此測試必須通過，否則產(chǎn)品發(fā)布存在危險2：在發(fā)布前必須執(zhí)行3：時間允許就執(zhí)行4：此測試可以在下一次發(fā)布或發(fā)布后短期內(nèi)執(zhí)行5：可以不測試

第三篇：軟件測試總結(jié)

1.軟件測試定義：由人工或自動方法來執(zhí)行或評價系統(tǒng)或系統(tǒng)部分的過程，以驗證它是否滿足規(guī)定的需求，或識別出期望的結(jié)果和實際結(jié)果之間的差異。2.軟件測試的分類：

測試對象或范圍分類：需求評審、設(shè)計評審、單元測試、程序測試、系統(tǒng)

測試、文檔測試、Web應(yīng)用測試、客戶端測試、數(shù)據(jù)庫測試等；

測試目的分類：集成測試、功能測試、壓力測試、性能測試等等； 靜態(tài)測試、動態(tài)測試； 白盒測試、黑盒測試。3.軟件測試的基本流程與原則

基本流程：

測試用例設(shè)計-輸入數(shù)據(jù)、預(yù)期結(jié)果； 測試執(zhí)行-輸入數(shù)據(jù)執(zhí)行被測對象； 檢查實際輸出與預(yù)期結(jié)果?；驹瓌t：

開始測試時認(rèn)定軟件有錯，測試要證明有錯； 測試應(yīng)該由獨立的測試團(tuán)隊來完成； 測試設(shè)計必須設(shè)計對應(yīng)的預(yù)期輸出；

要對合理、不合理（有效、無效）輸入數(shù)據(jù)都進(jìn)行測試； 檢查軟件的完備性、多余； 完整保留測試文檔；

一個被測對象中有錯誤的概率與已發(fā)現(xiàn)錯誤的個數(shù)成正比。4.Beizer測試成熟度級別：

0級：沒有區(qū)分測試與調(diào)試；

1級：測試的目的是證明軟件能用； 2級：測試的目的是證明軟件不能用；

3級：測試的目的不是為了證明什么，而是為了降低軟件使用風(fēng)險； 4級：測試是一種智能訓(xùn)練，能夠幫助專業(yè)人員開發(fā)出更高質(zhì)量的軟件。5.軟件測試與軟件工程，軟件過程的關(guān)系：

軟件工程：在給定的條件下（成本、時間）開發(fā)出高質(zhì)量的軟件產(chǎn)品。軟件生產(chǎn)過程的特性決定了軟件產(chǎn)品中不可避免包含有錯誤。軟件測試則是盡可能多地發(fā)現(xiàn)錯誤，從而保障軟件產(chǎn)品的質(zhì)量。6.McCall的質(zhì)量因素：

產(chǎn)品修改：

可維護(hù)性，靈活性，可測試性 產(chǎn)品轉(zhuǎn)移：

可移植性，可復(fù)用性，互操作性 產(chǎn)品運(yùn)行：

正確性，易用性，可靠性，效率，完整性 7.軟件質(zhì)量困境

軟件質(zhì)量必須足夠好：存在價值

軟件產(chǎn)品無法完美：需要消耗過多的資源、時間、成本

軟件開發(fā)需要在兩個極端之間進(jìn)行平衡：軟件足夠好的同時又不完美。8.質(zhì)量控制、質(zhì)量保證和質(zhì)量管理

軟件質(zhì)量控制其實是基本方法，通過一系列的技術(shù)來科學(xué)地測量過程的狀態(tài)。如缺陷率、測試覆蓋率等。

軟件質(zhì)量保證則是過程的參考、指南的集合，如ISO9000、CMM/CMMI等，著重內(nèi)部的檢查，確保已獲取認(rèn)可的標(biāo)準(zhǔn)和步驟都已經(jīng)遵循。

軟件質(zhì)量管理則是實際操作的思想，質(zhì)量管理控制和協(xié)調(diào)組織的質(zhì)量活動，包括質(zhì)量控制、質(zhì)量保證和質(zhì)量改進(jìn)。9.WebApp應(yīng)用的屬性：

網(wǎng)絡(luò)密集型應(yīng)用；并發(fā)性；大負(fù)載量；性能；高可靠性、高可用性；安全性-內(nèi)容敏感；

10.軟件評審的目的，評審度量及其應(yīng)用

評審的目標(biāo)在于：盡早發(fā)現(xiàn)軟件過程中的錯誤，防止錯誤傳遞、蔓延至后續(xù)活動，防止錯誤轉(zhuǎn)化為缺陷。

準(zhǔn)備工作量Ep-實際評審會之前所需工作量； 評估工作量Ea-實際評審所花費(fèi)的工作量 返工工作量Er-修改評審所發(fā)現(xiàn)錯誤的工作量 工作產(chǎn)品規(guī)模WPS-評審對象的規(guī)模

發(fā)現(xiàn)的主要錯誤數(shù)Errmajor-多于預(yù)期的改錯工作量的錯誤數(shù)目 發(fā)現(xiàn)的次要錯誤數(shù)Errminor-少于預(yù)期的改錯工作量的錯誤數(shù)目 總評審工作量Ereview = Ep+Ea+Er 錯誤總數(shù)Errtot = Errmajor+Errminor 錯誤密度：評審的每單位工作產(chǎn)品發(fā)現(xiàn)的錯誤數(shù)Ed = Errtot / WPS 錯誤密度數(shù)值的含義：較?。óa(chǎn)品質(zhì)量非常好或評審不夠徹底）；較大（產(chǎn)品質(zhì)量存在缺陷）

11.軟件測試計劃：描述對計算機(jī)軟件配置項、子系統(tǒng)、系統(tǒng)進(jìn)行測試的計劃安排，內(nèi)容包括測試的環(huán)境、測試工作的標(biāo)識及測試工作的時間安排。

軟件測試報告：是對計算機(jī)軟件配置項、軟件系統(tǒng)或子系統(tǒng)，或與軟件相關(guān)項目執(zhí)行合格性測試的記錄 12.軟件測試活動

制訂測試計劃（測試分析員）

測試設(shè)計（測試設(shè)計人員）－方案設(shè)計 測試及測試用例設(shè)計 測試過程

樁模塊、驅(qū)動模塊設(shè)計

測試實施（測試設(shè)計員）－實現(xiàn)測試設(shè)計 單元測試（測試員）集成測試（測試員）系統(tǒng)測試（測試員）

評估測試（測試設(shè)計人員）

13.無向圖的相關(guān)定義：

連接性：節(jié)點ni、nj是連接的，當(dāng)且僅當(dāng)ni、nj在同一條路徑上。組件：圖的組件是相連節(jié)點的最大集合

圖G的圈復(fù)雜度V（G)＝e－n＋2p，其中e為G的邊數(shù)，n為節(jié)點數(shù)，p為組件數(shù)。14.圖覆蓋：給定一個關(guān)于圖G的準(zhǔn)則C的測試需求集合TR，測試集合T在圖G上滿足準(zhǔn)則C當(dāng)且僅當(dāng)對TR中每個測試需求tr，path(T)中至少存在一條測試路徑p滿足tr。

簡單路徑：如果從ni到nj的一條路徑中，除了始節(jié)點和終節(jié)點可以相同外，沒有任何節(jié)點出現(xiàn)次數(shù)多于一次，則該路徑為簡單路徑。

主路徑：如果從ni到nj是一條簡單路徑，并且它不作為任何其他簡單路徑的子路徑出現(xiàn)，則稱之為主路徑。

主路徑覆蓋（PPC）準(zhǔn)則：TR包含圖中每一條主路徑。

指定路徑覆蓋（SPC)：TR包含一個測試路徑集S，S為指定參數(shù)。15.白盒測試方法

白盒測試：根據(jù)被測對象的內(nèi)部結(jié)構(gòu)和運(yùn)行機(jī)制來設(shè)計測試用例的方法，又稱為結(jié)構(gòu)測試、邏輯驅(qū)動測試、覆蓋測試

被測對象的獨立路徑至少覆蓋一次； 所有邏輯取值測試[真、假]； 循環(huán)邊界測試；

檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)、邊界條件。16.黑盒測試方法

黑盒測試方法又稱功能測試方法、數(shù)據(jù)驅(qū)動測試方法，測試設(shè)計時不考慮被測對象的內(nèi)部結(jié)構(gòu)，以檢查系統(tǒng)功能（功能的正確、完整、邏輯流程、人機(jī)界面、文檔內(nèi)容、系統(tǒng)安裝/初始化）

以被測對象的外部特征為測試依據(jù)。17.模糊測試方法

模糊測試方法：構(gòu)造大量的隨機(jī)數(shù)據(jù)作為系統(tǒng)的輸入，從而檢驗系統(tǒng)在各種數(shù)據(jù)情況下是否出現(xiàn)問題。

18.增量測試：單元測試、調(diào)用依賴的模塊集成測試，逐步擴(kuò)展直到形成整個軟件系統(tǒng)。

19.突擊測試：所有模塊一次性集成為一個完整的系統(tǒng)，然后進(jìn)行完全測試。20.等價類劃分：

等價類劃分基于對輸入或輸出數(shù)據(jù)情況的評估，劃分成兩個或多個子集（等價類），然后從每個子集中選取一定的代表進(jìn)行測試的測試用例設(shè)計方法。21.極限測試

極限編程：利用輕量、敏捷的開發(fā)過程，使開發(fā)人員能夠更快地完成應(yīng)用程序的開發(fā)。強(qiáng)調(diào)頻繁測試、測試驅(qū)動的方式保證軟件質(zhì)量。

極限測試：為滿足極限編程思想和過程而設(shè)計的一套測試策略和流程，原來的測試技術(shù)、方法均可以使用 22.配置項測試的內(nèi)容

功能: 適合性

準(zhǔn)確性：功能的準(zhǔn)確與精度要求 互操作性：與外部設(shè)備、系統(tǒng)的接口 安全保密性：數(shù)據(jù)訪問的可控制性 可靠性: 成熟性：容錯處理、平均無故障時間

容錯性：邊界條件、功能、性能的降級情況、誤操作模式、故障模式 易恢復(fù)性：自動修復(fù)能力/時間、平均宕機(jī)時間、平均恢復(fù)時間、恢復(fù)能力等 易用性

易理解性：功能描述清晰、準(zhǔn)確；界面含義精確

易學(xué)性：在線幫助、幫助定位、各類手冊的易學(xué)、易用 易操作性：數(shù)據(jù)的有效檢查、解釋信息明確、界面切換 吸引性：人機(jī)界面定制 效率

時間特性：響應(yīng)時間、平均響應(yīng)時間、響應(yīng)極限時間、吞吐量、平均吞吐量、極限吞吐量，多任務(wù)并行測試

資源利用：大量并發(fā)任務(wù)下I/O設(shè)備利用、極限負(fù)載下I/O設(shè)備的負(fù)載、大量并發(fā)任務(wù)下用戶等待時間、內(nèi)存使用情況、數(shù)據(jù)傳輸能力等

維護(hù)性

易分析性：運(yùn)行狀態(tài)數(shù)據(jù)易分析 易變更性：軟件的可配置、修改能力 易測試性：變更之后的易測試情況 可移植性

適應(yīng)性：不同軟件、硬件環(huán)境的適應(yīng)能力 易安裝性：安裝、配置的復(fù)雜程度、難以程度 共存性：與其他軟件協(xié)同的能力 易替換性：版本的替換難以程度 依從性

以上所有特性遵循標(biāo)準(zhǔn)、規(guī)范的情況測試

23系統(tǒng)測試：系統(tǒng)非功能性測試，以檢驗系統(tǒng)在超常數(shù)據(jù)規(guī)模或負(fù)載下，線程、CPU、內(nèi)存資源的利用和響應(yīng)時間、數(shù)據(jù)傳輸?shù)刃阅苤笜?biāo)是否滿足要求

24.測試計劃

確定測試充分性要求：覆蓋范圍、覆蓋程度 確定測試終止要求； 確定測試所需資源； 確定測試的軟件特性； 確定測試技術(shù)、方法； 確定測試準(zhǔn)出條件； 確定測試進(jìn)度計劃； 測試風(fēng)險分析。

25.測試設(shè)計：測試設(shè)計人員、測試程序員

測試用例設(shè)計：依據(jù)測試特性； 獲取測試數(shù)據(jù)；

確定測試順序：資源、被測特性； 獲取測試資源：軟硬件、工具； 編寫測試程序； 建立測試環(huán)境； 撰寫測試設(shè)計說明。

26.測試總結(jié)：

測試分析員－測試報告

總結(jié)測試計劃、測試說明的變化情況； 異常終止時測試未覆蓋范圍； 未能解決的測試問題； 總結(jié)測試結(jié)果（發(fā)現(xiàn)問題）； 編寫測試報告；

根據(jù)問題報告、測試記錄，編寫測試問題報告。

27.軟件可靠性：在給定的運(yùn)行時間內(nèi)和給定的系統(tǒng)配置環(huán)境下，運(yùn)行給定的軟件功能時所 表現(xiàn)出來的質(zhì)量能力 28.系統(tǒng)性能指標(biāo)

系統(tǒng)資源利用率：分析性能指標(biāo)，改善性能系統(tǒng)行為指標(biāo) 請求響應(yīng)時間：一次請求完成時間

事務(wù)響應(yīng)時間：一個事務(wù)所有請求完成的總時間

數(shù)據(jù)吞吐量：單位時間內(nèi)服務(wù)器接收、發(fā)送的數(shù)據(jù)量。

29.驗收測試：用戶執(zhí)行的、使用真實數(shù)據(jù)進(jìn)行的測試，依據(jù)需求規(guī)格中的確認(rèn)標(biāo)準(zhǔn)進(jìn)行測試?；貧w測試：驗證已測試過的內(nèi)容不受變更影響，確認(rèn)變更沒有引入新的錯誤。

30.α測試是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實際操 作環(huán)境下進(jìn)行的測試。

Beta測試由軟件的最終用戶在一個或多個客戶場所進(jìn)行，開發(fā)者通常不在Beta測試的現(xiàn)場。

31.WebApp測試關(guān)注的主要內(nèi)容 Web內(nèi)容測試 界面 構(gòu)件

導(dǎo)航測試 安全性 性能

32.測試用例（Test Case）是為某個特殊目標(biāo)而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個程序路徑或核實是否滿足某個特定需求。

33.軟件生存期定義：從軟件產(chǎn)品設(shè)計到軟件被淘汰的時間段。又稱軟件生命周期、生存周期。進(jìn)一步劃分為兩個階段：開發(fā)階段和維護(hù)階段（40%+60%）。

34.軟件安全定義：一種軟件質(zhì)量保證活動，他主要用來識別和評估可能對軟件產(chǎn)生負(fù)面影響并促使整個系統(tǒng)失效的潛在災(zāi)難。

35.軟件評審的目標(biāo)在于：盡早發(fā)現(xiàn)軟件過程中的錯誤，防止錯誤傳遞、蔓延至后續(xù)活動，防止錯誤轉(zhuǎn)化為缺陷。36.V模型

優(yōu)點：既有底層測試又有高層測試。底層：單元測試。高層：系統(tǒng)測試。

將開發(fā)階段清楚的表現(xiàn)出來，便于控制開發(fā)的過程。當(dāng)所有階段都結(jié)束時，軟件開發(fā)就結(jié)束了。

缺點：容易讓人誤解為測試是在開發(fā)完成之后的一個階段。

由于它的順序性，當(dāng)編碼完成之后，正式進(jìn)入測試時，這時發(fā)現(xiàn)的一些bug可能不容易找到其根源。

實際中，由于需求變更較大，導(dǎo)致要重復(fù)變更需求、設(shè)計、編碼、測試，返工量大。37.W模型：

優(yōu)點：

將測試貫穿到整個軟件生命周期中，且除了代碼要測試，需求、設(shè)計等都要測試。更早介入軟件開發(fā)中，能盡早發(fā)現(xiàn)缺陷并修復(fù)。

測試與開發(fā)獨立起來，并與開發(fā)并行。缺點：

對有些項目，開發(fā)過程中根本沒有文檔產(chǎn)生，故W模型無法使用。

對于需求和設(shè)計的測試技術(shù)要求很高，實踐起來很困難。

從N0中某節(jié)點開始到Nf中某節(jié)點結(jié)束的一條路徑稱為一條測試路徑。

1.軟件缺陷：（符合下列規(guī)則的叫軟件缺陷)：

１）．軟件未達(dá)到產(chǎn)品說明書的功能

２）．軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤

３）．軟件功能超出產(chǎn)品說明書指明范圍

４）．軟件未達(dá)到產(chǎn)品說明書雖未指出但應(yīng)達(dá)到的目標(biāo)

５）．軟件測試員認(rèn)為難以理解、不易使用、運(yùn)行速度緩慢、或者最終用戶認(rèn)為不好

2.單元測試：單元測試是對軟件設(shè)計的最小單元——模塊進(jìn)行正確性檢驗的測試工作，主要測試模塊在語法、格式和邏輯上的錯誤。3.回歸測試

指軟件系統(tǒng)被修改或擴(kuò)充（如系統(tǒng)功能增強(qiáng)或升級）后重新進(jìn)行的測試，是為了保證對軟件所做的修改沒有引入新的錯誤而重復(fù)進(jìn)行的測試。

4.等價類：指某個輸入域的子集合，在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。

第四篇：軟件測試總結(jié)

面向?qū)ο蟪绦虻能浖y試方法

在軟件生命周期過程中，軟件測試是保證軟件質(zhì)量的關(guān)鍵環(huán)節(jié)之一。面向?qū)ο蠓椒▽W(xué)在軟件工程中的引入極大地方便了軟件的設(shè)計、開發(fā)和維護(hù)，為創(chuàng)建高可靠性的軟件系統(tǒng)提供了重要保證。但面向?qū)ο蟪绦虻姆庋b、繼承、多態(tài)和異常處理機(jī)制等新特性卻給測試帶來新的挑戰(zhàn)。一方面需要調(diào)整、改進(jìn)傳統(tǒng)的測試策略和方法；另一方面探索出適應(yīng)面向?qū)ο蟪绦蛱卣鞯臏y試?yán)碚撆c技術(shù)也尤為必要。

面向?qū)ο?Object Oriented,OO)是當(dāng)前計算機(jī)界關(guān)心的重點，它是90年代軟件開發(fā)方法的主流。面向?qū)ο蟮母拍詈蛻?yīng)用已超越了程序設(shè)計和軟件開發(fā)，擴(kuò)展到很寬的范圍。如數(shù)據(jù)庫系統(tǒng)、交互式界面、應(yīng)用結(jié)構(gòu)、應(yīng)用平臺、分布式系統(tǒng)、網(wǎng)絡(luò)管理結(jié)構(gòu)、CAD技術(shù)、人工智能等領(lǐng)域。

面向?qū)ο蟮亩x或說明對象的定義的非常少。其初，“面向?qū)ο蟆笔菍Ｖ冈诔绦蛟O(shè)計中采用封裝、繼承、抽象等設(shè)計方法?？墒?，這個定義顯然不能再適合現(xiàn)在情況。面向?qū)ο蟮乃枷胍呀?jīng)涉及到軟件開發(fā)的各個方面。如，面向?qū)ο蟮姆治觯∣OA，Object Oriented Analysis），面向?qū)ο蟮脑O(shè)計（OOD，Object Oriented Design）、以及我們經(jīng)常說的面向?qū)ο蟮木幊虒崿F(xiàn)（OOP，Object Oriented Programming）。許多有關(guān)面向?qū)ο蟮奈恼露贾皇侵v述在面向?qū)ο蟮拈_發(fā)中所需要注意的問題或所采用的比較好的設(shè)計方法?？催@些文章只有真正懂得什么是對象，什么是面向?qū)ο?，才能最大程度地對自己有所裨益。這一點，恐怕對初學(xué)者甚至是從事相關(guān)工作多年的人員也會對它們的概念模糊不清。

1、面向?qū)ο蟮幕靖拍?/p>

(1)對象。

對象是人們要進(jìn)行研究的任何事物，從最簡單的整數(shù)到復(fù)雜的飛機(jī)等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規(guī)則、計劃或事件。

(2)對象的狀態(tài)和行為。

對象具有狀態(tài)，一個對象用數(shù)據(jù)值來描述它的狀態(tài)。

對象還有操作，用于改變對象的狀態(tài)，對象及其操作就是對象的行為。

對象實現(xiàn)了數(shù)據(jù)和操作的結(jié)合，使數(shù)據(jù)和操作封裝于對象的統(tǒng)一體中

(3)類。具有相同或相似性質(zhì)的對象的抽象就是類。因此，對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。

類具有屬性，它是對象的狀態(tài)的抽象，用數(shù)據(jù)結(jié)構(gòu)來描述類的屬性。

類具有操作，它是對象的行為的抽象，用操作名和實現(xiàn)該操作的方法來描述。

(4)類的結(jié)構(gòu)。

在客觀世界中有若干類，這些類之間有一定的結(jié)構(gòu)關(guān)系。通常有兩種主要的結(jié)構(gòu)關(guān)系，即一般--具體結(jié)構(gòu)關(guān)系，整體--部分結(jié)構(gòu)關(guān)系。

①一般——具體結(jié)構(gòu)稱為分類結(jié)構(gòu)，也可以說是“或”關(guān)系，或者是“is a”關(guān)系。

②整體——部分結(jié)構(gòu)稱為組裝結(jié)構(gòu)，它們之間的關(guān)系是一種“與”關(guān)系，或者是“has a”關(guān)系。

(5)消息和方法。

對象之間進(jìn)行通信的結(jié)構(gòu)叫做消息。在對象的操作中，當(dāng)一個消息發(fā)送給某個對象時，消息包含接收對象去執(zhí)行某種操作的信息。發(fā)送一條消息至少要包括說明接受消息的對象名、發(fā)送給該對象的消息名（即對象名、方法名）。一般還要對參數(shù)加以說明，參數(shù)可以是認(rèn)識該消息的對象所知道的變量名，或者是所有對象都知道的全局變量名。

類中操作的實現(xiàn)過程叫做方法，一個方法有方法名、參數(shù)、方法體。消

2、面向?qū)ο蟮奶卣?/p>

(1)對象唯一性。

每個對象都有自身唯一的標(biāo)識，通過這種標(biāo)識，可找到相應(yīng)的對象。在對象的整個生命期中，它的標(biāo)識都不改變，不同的對象不能有相同的標(biāo)識。

(2)分類性。

分類性是指將具有一致的數(shù)據(jù)結(jié)構(gòu)(屬性)和行為(操作)的對象抽象成類。一個類就是這樣一種抽象，它反映了與應(yīng)用有關(guān)的重要性質(zhì)，而忽略其他一些無關(guān)內(nèi)容。任何類的劃分都是主觀的，但必須與具體的應(yīng)用有關(guān)。

(3)繼承性。

繼承性是子類自動共享父類數(shù)據(jù)結(jié)構(gòu)和方法的機(jī)制，這是類之間的一種關(guān)系。在定義和實現(xiàn)一個類的時候，可以在一個已經(jīng)存在的類的基礎(chǔ)之上來進(jìn)行，把這個已經(jīng)存在的類所定義的內(nèi)容作為自己的內(nèi)容，并加入若干新的內(nèi)容。繼承性是面向?qū)ο蟪绦蛟O(shè)計語言不同于其它語言的最重要的特點，是其他語言所沒有的。

在類層次中，子類只繼承一個父類的數(shù)據(jù)結(jié)構(gòu)和方法，則稱為單重繼承。

在類層次中，子類繼承了多個父類的數(shù)據(jù)結(jié)構(gòu)和方法，則稱為多重繼承。

在軟件開發(fā)中，類的繼承性使所建立的軟件具有開放性、可擴(kuò)充性，這是信息組織與分類的行之有效的方法，它簡化了對象、類的創(chuàng)建工作量，增加了代碼的可重性。

采用繼承性，提供了類的規(guī)范的等級結(jié)構(gòu)。通過類的繼承關(guān)系，使公共的特性能夠共享，提高了軟件的重用性。

(4)多態(tài)性(多形性)多態(tài)性使指相同的操作或函數(shù)、過程可作用于多種類型的對象上并獲得不同的結(jié)果。不同的對象，收到同一消息可以產(chǎn)生不同的結(jié)果，這種現(xiàn)象稱為多態(tài)性。

多態(tài)性允許每個對象以適合自身的方式去響應(yīng)共同的消息。

多態(tài)性增強(qiáng)了軟件的靈活性和重用性。

面向?qū)ο蠓椒ǖ幕舅枷胧且唬好嫦驅(qū)ο蠓椒ㄊ且环N運(yùn)用對象、類、封裝、繼承、多態(tài)和消息等概念來構(gòu)造、測試、重構(gòu)軟件的方法。

二： 面向?qū)ο蠓椒ㄊ且哉J(rèn)識論為基礎(chǔ)，用對象來理解和分析問題空間，并設(shè)計和開發(fā)出由對象構(gòu)成的軟件系統(tǒng)（解空間）的方法。由于問題空間和解空間都是由對象組成的，這樣可以消除由于問題空間和求解空間結(jié)構(gòu)上的不一致帶來的問題。簡言之，面向?qū)ο缶褪敲嫦蚴虑楸旧?，面向?qū)ο蟮姆治鲞^程就是認(rèn)識客觀世界的過程。

面向?qū)ο蠓椒◤膶ο蟪霭l(fā)，發(fā)展出對象，類，消息，繼承等概念。

面向?qū)ο蠓椒ǖ闹饕獌?yōu)點是：符合人們通常的思維方式；從分析到設(shè)計再到編碼采用一致的模型表示具有高度連續(xù)性；軟件重用性好。

面向?qū)ο筌浖y試的特點是: 1.掌握代碼檢查、走查與評審的基本方法和技術(shù)； 2.掌握白盒測試和黑盒測試的測試用例的設(shè)計原則和方法； 3.掌握單元測試和集成測試的基本策略和方法；

4.了解系統(tǒng)測試、性能測試和可靠性測試的基本概念和方法； 5.了解面向?qū)ο筌浖蚖EB應(yīng)用軟件測試的基本概念和方法； 6.掌握軟件測試過程管理的基本知識和管理方法； 7.熟悉軟件測試的標(biāo)準(zhǔn)和文檔；

8.掌握QESuite軟件測試過程管理平臺和QESat/C++軟件分析和工具的使用方法。

第五篇：軟件測試方法和技術(shù)—課程總結(jié)作業(yè)

軟件測試方法和技術(shù) 課程總結(jié)作業(yè) 2012-2013學(xué)年

軟件測試方法和技術(shù) 課程總結(jié)作業(yè) 2012-2013學(xué)年第一學(xué)期 任務(wù)2：（20分）設(shè)有一個檔案管理系統(tǒng)，要求用戶輸入以年月表示的日期。假設(shè)日期限定

在1990年1月~2049年12月，并規(guī)定日期由6位數(shù)字字符組成，前4位表示年，后2位表示月?，F(xiàn)用等價類劃分法設(shè)計測試用例，來測試程序的“日期檢查功能”。任務(wù)3：（50分）用你已經(jīng)設(shè)計好的系統(tǒng)或借用其他系統(tǒng)，來進(jìn)行軟件系統(tǒng)測試，編寫出系統(tǒng)測試報告。

3、補(bǔ)充說明

課程總結(jié)作業(yè)必須自己獨立、認(rèn)真完成，不得抄襲，如發(fā)現(xiàn)抄襲別人，則視本門課程為不及格處理。希望大家切記。