軟件測試知識(shí)總結(jié)

1、1、測試驅(qū)動(dòng)開發(fā)（ TDD）測試在先，編碼在后的開發(fā)方法（詳見書本12 頁）2、軟件質(zhì)量：功能、性能、可靠性（書本15 頁）3、軟件測試的工作范疇：測試的組織與管理（PDCA）、測試計(jì)劃、測試用例、測試的實(shí)施、測試結(jié)果分析、測試評(píng)審與報(bào)告（書本 29 頁小結(jié)中）第三章4、白盒測試（設(shè)計(jì)測試用例看書說明）（又稱邏輯驅(qū)動(dòng)測試 ,結(jié)構(gòu)測試 ）的意思是把程序看成裝在一個(gè)透明的白盒子里，測試人員知道程序的結(jié)構(gòu) 和處理算法 ,按照程序內(nèi)部的邏輯進(jìn)行測試， 檢測程序中的主要執(zhí)行通路是否都能按預(yù)定要求正確工作， 利 用白盒測試法進(jìn)行動(dòng)態(tài)測試時(shí)， 不需測試軟件產(chǎn)品的功能。 白盒測試主要用于單元測試。 （詳見書本

2、 31 頁） （ 1） 語句覆蓋設(shè)計(jì)若干測試用例，運(yùn)行被測試用例，使程序中的每個(gè)可執(zhí)行語句至少被執(zhí)行一次。（2）判定覆蓋： 設(shè)計(jì)若干測試用例， 運(yùn)行被測試用例， 使程序中每個(gè)判斷的取真分支和取假分支至少經(jīng)歷一 次。（針對(duì)每次判斷，又稱分支覆蓋）（3）條件覆蓋： 設(shè)計(jì)若干測試用例， 運(yùn)行被測試用例， 使程序中每個(gè)判斷中每個(gè)條件的可能取值至少滿足一 次。（針對(duì)每次判斷中的每一個(gè)條件）（4）判定 -條件覆蓋（5）條件組合覆蓋：每個(gè)判定結(jié)果至少出現(xiàn)一次，每個(gè)條件的所有可能至少出現(xiàn)一次。（6）路徑覆蓋：設(shè)計(jì)所有的測試用例，來覆蓋程序中的所有可能的執(zhí)行路徑。（7）基本路徑測試法： （根據(jù)流程圖判斷） 獨(dú)立

3、路徑：所謂獨(dú)立路徑，是指至少包含一條新邊的路徑，也就是包含一些前面的路徑未包含的語句， 當(dāng)所有的語句都包含了，基路徑集就夠了。5、黑盒測試（設(shè)計(jì)測試用例案例）（又稱功能測試或者數(shù)據(jù)驅(qū)動(dòng)測試）黑盒測試法把程序看作一個(gè)黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和處 理過程。也就是說，黑盒測試是在程序接口進(jìn)行的測試，它只檢查程序功能是否能按照規(guī)格說明書的規(guī)定 正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)并產(chǎn)生正確的輸出信息，程序運(yùn)行過程中能否保持外部信息的 完整性。（ 1） 等價(jià)劃分（見書本 40 頁） 有效等價(jià)類和無效等價(jià)類 輸入條件規(guī)定了取值范圍或者個(gè)數(shù)的情況下，則可以確立一個(gè)有效等價(jià)類和兩個(gè)無效等價(jià)類。 在輸

4、入條件規(guī)定了輸入值的集合或者規(guī)定了 “必須如何 ”的條件的情況下，可確立一個(gè)有效等價(jià)類和 一個(gè)無效等價(jià)類。在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下， 可確立一個(gè)有效等價(jià)類 （符合規(guī)則 ）和若干個(gè)無效等價(jià)類 （從不同角度違反規(guī)則 ）。（參考 40 頁實(shí)例）（ 2） 邊界值分析 如果輸入條件規(guī)定了值的范圍， 則應(yīng)取剛達(dá)到這個(gè)范圍的邊界的值以及剛剛超越這個(gè)范圍邊界的 值作為測試輸入數(shù)據(jù)。如果輸入條件規(guī)定了值的個(gè)數(shù)，則用最大個(gè)數(shù)、最小個(gè)數(shù)、比最小個(gè)數(shù)少一、比最大個(gè)數(shù)多一的 數(shù)作為測試數(shù)據(jù)。如果程序規(guī)格說明中提到的輸入或輸出是個(gè)有序的集合， 應(yīng)該注意選取有序集的第一個(gè)和最后一 個(gè)作為測試用例。（ 3） 正

5、交試驗(yàn) 正交表具有兩條性質(zhì)： （1）每一列中各數(shù)字出現(xiàn)的次數(shù)都一樣多。（2） 任何兩列所構(gòu)成的各有序數(shù)對(duì)出現(xiàn)的次數(shù)都一樣多。所以稱之謂正交表。 （見書本 48 頁）（ 4） 錯(cuò)誤推測表 基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯(cuò)誤 , 從而有針對(duì)性的設(shè)計(jì)測試用例的方法。6、主動(dòng)測試與被動(dòng)測試主動(dòng)測試：測試人員主動(dòng)向被測試對(duì)象發(fā)送請求， 驗(yàn)證被測試對(duì)象的反應(yīng)和輸出結(jié)果。一般在測試環(huán)境下 進(jìn)行，測試人員需要設(shè)計(jì)若干測試用例，設(shè)法輸入各種數(shù)據(jù)。被動(dòng)測試：為了解決產(chǎn)品在線測試問題。在被動(dòng)測試方法中，軟件產(chǎn)品運(yùn)行在實(shí)際環(huán)境中，測試人員不干 預(yù)產(chǎn)品的運(yùn)行，而是被動(dòng)地監(jiān)控產(chǎn)品的運(yùn)行，通過一定的被動(dòng)機(jī)制來獲

6、取系統(tǒng)運(yùn)行的數(shù)據(jù)，測試人員不需要設(shè) 計(jì)測試用例。7、基于風(fēng)險(xiǎn)的測試 指評(píng)估測試的優(yōu)先級(jí)，先做高優(yōu)先的測試，如果時(shí)間或者精力不足，低優(yōu)先級(jí)的測試可以暫時(shí)先不做。影響測 試優(yōu)先級(jí)主要因素：對(duì)用戶的影響、出錯(cuò)的概率第四章8、V模型（ RAD模型 快速應(yīng)用開發(fā)模型）書本 66頁V 模型大體可以劃分為以下幾個(gè)不同的階段步驟: 需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、軟件編碼、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試。原理：在瀑布模型的基礎(chǔ)上，通過開發(fā)和測試同時(shí)進(jìn)行的方式來縮短開發(fā)周期，提高開發(fā)效率 適用條件：明確需求、需求變化不大V 模式是一種傳統(tǒng)軟件開發(fā)模型， 一般適用于一些傳統(tǒng)信息系統(tǒng)應(yīng)用的開發(fā)， 而一些高性能

7、高風(fēng)險(xiǎn)的系統(tǒng)、 互聯(lián)網(wǎng)軟件， 或一個(gè)系統(tǒng)難以被具體模塊化的時(shí)候， 就比較難做成 V 模式所需的各種構(gòu)件， 需要更強(qiáng)調(diào)迭代的 開發(fā)模型或者敏捷開發(fā)模型。優(yōu)缺點(diǎn)：（詳見瀑布模型的優(yōu)缺點(diǎn)）V 模型僅僅把測試過程作為在需求分析、系統(tǒng)設(shè)計(jì)及編碼之后的一個(gè)階段，忽視了測試對(duì)需求分析,系統(tǒng)設(shè)計(jì)的驗(yàn)證，需求的滿足情況一直到后期的驗(yàn)收測試才被驗(yàn)證。9、軟件質(zhì)量體系標(biāo)準(zhǔn)（1）CMM 針對(duì)軟件產(chǎn)品的質(zhì)量管理和質(zhì)量保證標(biāo)準(zhǔn)CMM 全稱為 （Capability Maturity Model）, 中文名稱為能力成熟度模型CMM 劃分為五級(jí) :級(jí)別越高表明該企業(yè)在提供合格軟件產(chǎn)品方面的能力越強(qiáng)（2） CMMI 為了整合不

8、同模型的最佳實(shí)踐 ,建議統(tǒng)一模型 ,覆蓋不同領(lǐng)域 ,供企業(yè)進(jìn)行整個(gè)組織的全面過程改進(jìn),并于 20XX年正式發(fā)布了能力成熟度集成模型 （CMMI） 。（3） ISO 9000 原本是硬件標(biāo)準(zhǔn)（見書本 83 頁） ISO9000不是指一個(gè)標(biāo)準(zhǔn)，而是一類標(biāo)準(zhǔn)的統(tǒng)稱。 ISO 9000族標(biāo)準(zhǔn)是用來提供一個(gè)通用的質(zhì)量體系標(biāo)準(zhǔn) 的核心，適用于廣泛的工業(yè)行業(yè)和經(jīng)濟(jì)部門。測試分類：單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試第五章 單元測試10 、單元測試（見書本 97 頁）：單元測試是對(duì)軟件基本組成單元進(jìn)行的測試 為什么要進(jìn)行單元測試？盡早發(fā)現(xiàn)錯(cuò)誤錯(cuò)誤發(fā)現(xiàn)越早 ,成本越低 .開發(fā)人員過于自信 ,后期復(fù)雜度高 ,發(fā)

9、現(xiàn)解決 BUG困難 . 檢查代碼是否符合設(shè)計(jì)和規(guī)范 目標(biāo)：（1）主要目標(biāo)：確保各單元模塊被正確地編碼（2）確保代碼在結(jié)構(gòu)上可靠且健全，能夠在各種條件下給予正確的響應(yīng) 概括起來，單元測試是對(duì)代碼對(duì)單元的代碼規(guī)范性、正確性、安全性和性能等進(jìn)行驗(yàn)證。內(nèi)容（任務(wù)） ：單元中所有獨(dú)立執(zhí)行路徑、數(shù)據(jù)結(jié)構(gòu)、接口、邊界條件、容錯(cuò)性等測試。 （詳見 ppt 單元測試）10 、走查和審查（見 104 頁表 5-1）靜態(tài)測試三部曲：走查、審查、評(píng)審（1）走查 采用講解、討論和模擬運(yùn)行的方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。引導(dǎo)小組成員在走查前通讀設(shè)計(jì)和編碼。限時(shí)，避免跑題。發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場修改。 檢查要點(diǎn)是代碼是否符

10、合標(biāo)準(zhǔn)和規(guī)范，是否有邏輯錯(cuò)誤。2）審查采用講解、提問方式進(jìn)行，一般有正式的計(jì)劃、流程和結(jié)果。主要方法采用缺陷檢查表。以會(huì)議形式，制定會(huì)議目標(biāo)、流程和規(guī)則，結(jié)束后要編寫報(bào)告。按缺陷檢查表逐項(xiàng)檢查。發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場修改。發(fā)現(xiàn)重大缺陷，改正后會(huì)議需要重開。檢查要點(diǎn)是缺陷檢查表，所以該表要根據(jù)項(xiàng)目不同不斷積累完善。走查審查準(zhǔn)備通讀設(shè)計(jì)和編碼應(yīng)準(zhǔn)備好需求描述文檔、程序設(shè)計(jì)文檔、程序的源代碼清單、代碼編碼標(biāo)準(zhǔn)和代碼缺陷檢查表形式非正式會(huì)議正式會(huì)議參加人員開發(fā)人員為主項(xiàng)目組成員包括測試人員主要技術(shù)方法無缺陷檢查表注意事項(xiàng)限時(shí)、不要現(xiàn)場修改代碼限時(shí)、不要現(xiàn)場修改代碼生成文檔會(huì)議記錄靜態(tài)分析錯(cuò)誤報(bào)告目

11、標(biāo)代碼標(biāo)準(zhǔn)規(guī)范， 無邏 輯錯(cuò)誤代碼標(biāo)準(zhǔn)規(guī)范，無邏輯錯(cuò)誤12、驅(qū)動(dòng)程序與樁程序（在黑盒測試中） 驅(qū)動(dòng)程序：也稱驅(qū)動(dòng)模塊，用以模擬被測模塊的上級(jí)模塊，能夠調(diào)用被測模塊。在測試過程中，驅(qū)動(dòng)模塊接受測試 數(shù)據(jù)，調(diào)用被測模塊并把相關(guān)數(shù)據(jù)傳送給被測模塊，啟動(dòng)被測模塊，并打印出相應(yīng)的結(jié)果。樁程序：也稱樁模塊，用以模擬被測模型工作過程中所調(diào)用的下級(jí)模塊。樁模塊由被測模塊調(diào)用，它們一般只進(jìn)行 很少的數(shù)據(jù)處理。第六章 集成測試與系統(tǒng)測試13、集成測試模式（1）非漸增式測試模式 先分別測試每個(gè)模塊。再把所有模塊按設(shè)計(jì)要求放在一起結(jié)合成所要的程序。如：大棒模式概括地說，非增量式測試就是采用一步到位的方法構(gòu)造測試，即對(duì)

12、所有模塊進(jìn)行單元測試后，按照程序結(jié) 構(gòu)圖將所有模塊連接起來，進(jìn)行整體測試 .其明顯缺點(diǎn)是容易出現(xiàn)混亂，判斷出錯(cuò)的原因和位置比較困難，因?yàn)闇y試時(shí)可能出現(xiàn)很多錯(cuò)誤，并且在修 正一個(gè)錯(cuò)誤的同時(shí)，可能會(huì)引入新的錯(cuò)誤。（2）漸增式測試模式 把下一個(gè)要測試的模塊同已經(jīng)測試好的模塊結(jié)合起來進(jìn)行測試， 測試完以后再把下一個(gè)應(yīng)該測試的模塊結(jié) 合進(jìn)來測試。具體優(yōu)缺點(diǎn)詳見書本 126 頁14、自頂向下與自底向上集成方法（ 1）自頂向下：從主程序開始，沿著軟件的控制層次向下移動(dòng)，從而逐漸把各個(gè)模塊結(jié)合起來。在組裝過程中， 可以使用深度優(yōu)先或者寬度優(yōu)先的策略。逐步集成和逐步測試是按照結(jié)構(gòu)圖自上而下進(jìn)行 深度優(yōu)先的集成是

13、先集成一個(gè)主控路徑下的所有模塊，主控路徑的選擇是任意的； 廣度優(yōu)先的集成首先是沿著水平方向，把每一層中所有直接屬于上一層的模塊集中起來，直到最底 層。集成測試的整個(gè)過程主要由 3 個(gè)步驟完成：1）主控模塊作為測試驅(qū)動(dòng)器；2）根據(jù)集成方式，下層的樁模塊依次被替換為真正模塊； 3）每個(gè)模塊集成時(shí)，進(jìn)行單元測試。（2）自底向上：從原子模塊開始集成以進(jìn)行測試。（ 3）改進(jìn)的自頂向下：基本使用 “自頂向下 ”，但在早期，使用自底向上測試少數(shù)關(guān)鍵模塊。 混合法：對(duì)軟件結(jié)構(gòu)中較上層，使用的是“自頂向下”法；對(duì)軟件結(jié)構(gòu)中較下層，使用的是“自底向上”法，兩者 相結(jié)合15、改進(jìn)的三明治集成方法 三明治方法：采用三

14、明治方法的優(yōu)點(diǎn)是： 它將自頂向下和自底向上的集成方法有機(jī)地結(jié)合起來， 不需要寫樁程序因?yàn)樵跍y試 初自底向上集成已經(jīng)驗(yàn)證了底層模塊的正確性。 采用這種方法的主要缺點(diǎn)是： 在真正集成之前每一個(gè)獨(dú)立的模 塊沒有完全測試過。改進(jìn)的三明治集成方法： 不僅自兩頭向中間集成，還保證了每個(gè)模塊得到單獨(dú)的測試，使測試進(jìn)行的比較徹底。16、持續(xù)集成（ 1）持續(xù)集成（ Continuous Integration， CI）是持續(xù)地編譯、測試、檢查和部署源代碼的過程。（ 2）優(yōu)點(diǎn)：持續(xù)集成可以減少集成階段"Bug"消耗的時(shí)間，從而最終提高軟件開發(fā)的質(zhì)量和效率。（3）持續(xù)集成測試的原理 持續(xù)集成，是

15、一種軟件開發(fā)實(shí)踐，即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成它們的工作，通常每個(gè)成員每天至少集成一次，也 就意味著每天可能會(huì)發(fā)生多次集成。每次集成都通過自動(dòng)化的構(gòu)建（包括編譯，發(fā)布，自動(dòng)化測試） 來驗(yàn)證，從而盡快地發(fā)現(xiàn)集成錯(cuò)誤。17、回歸測試（ 1）概念： 指修改了舊代碼后，重新進(jìn)行測試以確認(rèn)修改沒有引入新的錯(cuò)誤或?qū)е缕渌a產(chǎn)生錯(cuò)誤。（2） 方法: 再測試全部用例、基于風(fēng)險(xiǎn)選擇測試、基于操作剖面選擇測試、再測試修改的部分。（ 3） 目的： 所做的修改達(dá)到了預(yù)定的目的，如錯(cuò)誤得到了改正，新功能得到了實(shí)現(xiàn)，能夠適應(yīng)新的運(yùn)行環(huán)境等； 不影響軟件原有功能的正確性。18、非功能測試（設(shè)計(jì)測試用例主要看課件）（1）性能測試

16、性能測試的目的： 為了驗(yàn)證系統(tǒng)是否達(dá)到用戶提出的性能指標(biāo)，同時(shí)發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，起到優(yōu)化系統(tǒng)的目的 。 性能測試指標(biāo)的來源： 用戶對(duì)各項(xiàng)指標(biāo)提出的明確需求；如果用戶沒有提出性能指標(biāo)則根據(jù)用戶需求、測試設(shè)計(jì)人員的經(jīng)驗(yàn)來設(shè) 計(jì)各項(xiàng)測試指標(biāo)。 （需求 +經(jīng)驗(yàn)）主要的性能指標(biāo)： 服務(wù)器的各項(xiàng)指標(biāo)（ CPU、內(nèi)存占用率等） 、后臺(tái)數(shù)據(jù)庫的各項(xiàng)指標(biāo)、網(wǎng)絡(luò)流量、響應(yīng)時(shí)間（2）壓力測試（累積效應(yīng)） 壓力測試是在一種需要反常數(shù)量、頻率或資源的方式下，執(zhí)行可重復(fù)的負(fù)載測試，以檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力，找出性能瓶頸。 壓力測試總是迫使系統(tǒng)在異常的資源配置下運(yùn)行。（ 4） 容量測試 容量測試目的是通過測試

17、預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項(xiàng)指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù) 據(jù)庫記錄數(shù)等） ，系統(tǒng)在其極限值狀態(tài)下還能保持主要功能正常運(yùn)行。 容量測試還將確定測試對(duì)象在給定時(shí) 間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。（ 5） 安全性測試 安全性測試是檢查系統(tǒng)對(duì)非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法 試圖突破防線。（ 6） 可靠性測試 可靠性（ Reliability）是產(chǎn)品在規(guī)定的條件下和規(guī)定的時(shí)間內(nèi)完成規(guī)定功能的能力，它的概率度量稱為可靠 度。軟件可靠性是軟件系統(tǒng)的固有特性之一，它表明了一個(gè)軟件系統(tǒng)按照用戶的要求和設(shè)計(jì)的目標(biāo)，執(zhí)行 其功能的可靠程度。軟件可靠性與軟件缺

18、陷有關(guān)，也與系統(tǒng)輸入和系統(tǒng)使用有關(guān)。理論上說，可靠的軟件 系統(tǒng)應(yīng)該是正確、完整、一致和健壯的。（ 7） 容錯(cuò)性測試 容錯(cuò)性測試是檢查軟件在異常條件下自身是否具有防護(hù)性的措施或者某種災(zāi)難性恢復(fù)的手段。如當(dāng)系統(tǒng)出 錯(cuò)時(shí)，能否在指定時(shí)間間隔內(nèi)修正錯(cuò)誤并重新啟動(dòng)系統(tǒng)壓力測試、容量測試和性能測試的測試目的雖然有所不同，但其手段和方法在一定程度上比較相似， 通常會(huì)使 用特定的測試工具，來模擬超常的數(shù)據(jù)量、負(fù)載等，監(jiān)測系統(tǒng)的各項(xiàng)性能指標(biāo)，如 CPU 和內(nèi)存的使用情況、 響應(yīng)時(shí)間、數(shù)據(jù)傳輸量等。19、（ 1）測試. 測試 測試是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對(duì)即將面市軟件產(chǎn)品 （稱為 版本）進(jìn)行測試

19、， 試圖發(fā)現(xiàn)錯(cuò)誤并修正。經(jīng)過 測試調(diào)整的軟件產(chǎn)品稱為 版本。緊隨其后的 測試是指軟件開發(fā)公司組織各方面的典型用 戶在日常工作中實(shí)際使用 版本，并要求用戶報(bào)告異常情況、提出批評(píng)意見。然后軟件開發(fā)公司再對(duì)版本進(jìn)行改錯(cuò)和完善。（2）文檔測試： 非代碼的文檔測試主要檢查文檔的正確性、完備性和可理解性。驗(yàn)證正確性驗(yàn)證完備性 驗(yàn)證可理解性 軟件驅(qū)動(dòng)的文檔還得像程序一樣運(yùn)行起來測試。第八章 面向?qū)ο筌浖y試20、分層與增量原理（ 160 頁）類 C 和其派生類 D 間的增量變化能夠用來幫助確定需要在 D 中測試什么。由于 D 是 C 的子類，那么所有的用 于 C 的基于規(guī)范的測試用例也都適用于 D 。引入術(shù)

20、語“繼承的測試用例”來代表從父類測試用例中選取出來的、用 于子類的測試用例。 可以通過簡單的分析來確定繼承的測試用例中哪些適用于測試子類、 哪些在測試子類時(shí)不必執(zhí) 行。21、分類測試要點(diǎn)（泛化）與組裝結(jié)構(gòu)（聚合） 分類測試：體現(xiàn)了問題空間實(shí)例中的一般與特殊的關(guān)系 組裝結(jié)構(gòu)：體現(xiàn)了問題空間實(shí)例中整體與局部的關(guān)系第九章 基于應(yīng)用服務(wù)器的測試21、解釋下列故障名稱及原理 數(shù)據(jù)庫并發(fā)能力 : 多個(gè)應(yīng)用請求的并發(fā)處理過程 并發(fā)主要考慮的幾個(gè)方面 :（詳見書本 196 頁） （1）數(shù)據(jù)丟失（解釋）（2）不可重復(fù)數(shù)據(jù)（解釋）（3）讀臟數(shù)據(jù)（解釋）（4）數(shù)據(jù)庫的鎖第十章 軟件本地化測試22、翻譯錯(cuò)誤測試方法翻

21、譯錯(cuò)誤：(1)產(chǎn)生原因：1)翻譯人員不熟悉翻譯要求。2)翻譯人員工作疏漏。3)用戶界面的翻譯與標(biāo)準(zhǔn)詞匯表不一致。(2)表現(xiàn)特征：1)應(yīng)該翻譯而沒有翻譯的英文字符。2)不應(yīng)該翻譯而翻譯的中文字詞。3)錯(cuò)誤翻譯的字詞。4)只在本地化版本中存在該類型錯(cuò)誤。5)較多隱含在對(duì)話框各控件以及幫助文檔中。(3)測試要求：1)明確需要翻譯和不需要翻譯的內(nèi)容。2)明確正確的翻譯方式。3)根據(jù)術(shù)語表，確認(rèn)術(shù)語翻譯的正確性與一致性。(4)測試方法：1)主要同時(shí)打開中英文版本，執(zhí)行相同的操作。2)結(jié)合標(biāo)準(zhǔn)界面詞匯翻譯表，參照對(duì)比。（5） 說 明1） 對(duì)于對(duì)話框，如果含有下拉列表框，要打開列表框查看全部項(xiàng)。23、布局錯(cuò)

22、誤測試方法原因：(1)產(chǎn)生1） 軟件本地化后，由于源語言和本地化語言的表達(dá)方式不同，本地化后的字符數(shù)與源語言不同，每個(gè)字符所占空間尺寸不同，使得在英文版本正確顯示的控件字符，可能在本地化版本顯示不正確。2)本地化人員調(diào)整程序資源不當(dāng)引起，例如，對(duì)話框及其控件高度或?qū)挾鹊牟徽_調(diào)整。(2)表現(xiàn)特征：1)控件相互重疊或排列不均勻。2)控件中字符顯示不完整。3） 主要出現(xiàn)在本地化版本的對(duì)話框中。(3)測試要求：1)對(duì)話框中控件布局均勻，字符顯示完整正確。2)對(duì)話框中控件數(shù)量相等，沒有多余或丟失的控件(4)測試方法：1)執(zhí)行將要打開對(duì)話框的菜單或工具欄按鈕，觀察打開對(duì)話框中的控件布局。2)對(duì)比檢查源語

23、言軟件和本地化軟件對(duì)應(yīng)的對(duì)話框中控件的數(shù)量（5） 說 明1） 可能在執(zhí)行不同的操作后，如選擇了不同單選或復(fù)選按鈕后，編輯框顯示重疊等。第十一章 軟件測試自動(dòng)化24、測試自動(dòng)化（1）概念：自動(dòng)化測試是把以人為驅(qū)動(dòng)的測試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過程。（2）與手工測試的辯證關(guān)系 測試自動(dòng)化能：顯著降低重復(fù)手工測試的時(shí)間建立可靠、重復(fù)的測試，減少人為錯(cuò)誤增強(qiáng)測試質(zhì)量和覆蓋率測試自動(dòng)化不能：完全替代手工測試和手工測試工程師保證 100%的測試覆蓋率軟件測試自動(dòng)化 （TA）雖然具有很多優(yōu)點(diǎn)，但只是對(duì)手工測試的一種補(bǔ)充，TA絕不能代替手工測試，有各自的特點(diǎn)：在系統(tǒng)功能邏輯測試、驗(yàn)收測試等多采用黑盒測試的手工

24、測試方法； 系統(tǒng)性能、穩(wěn)定性、可靠性測試等比較適合采用TA；對(duì)那種不穩(wěn)定軟件的測試、開發(fā)周期很短的軟件、一次性的軟件等不適合測試自動(dòng)化 工具本身并沒有想象力和靈活性，根據(jù)經(jīng)驗(yàn)報(bào)道，自動(dòng)測試只能發(fā)現(xiàn)15%的缺陷，而手工測試可以發(fā)現(xiàn)85%的缺陷； TA工具在進(jìn)行功能測試時(shí)，其準(zhǔn)確的含義是回歸測試工具，因?yàn)楣ぞ卟荒馨l(fā)現(xiàn)更多的新問題， 但可以保證對(duì)已經(jīng)測試過部分進(jìn)行測試的準(zhǔn)確性和客觀性3）黑盒測試的主要步驟（自動(dòng)化測試有哪些主要步驟？） 錄制測試過程成為自動(dòng)化測試腳本 增強(qiáng)和改進(jìn)錄制的自動(dòng)化測試腳本 執(zhí)行自動(dòng)化測試腳本完成自動(dòng)化測試（4）性能測試測什么？ 各種操作的響應(yīng)速度、最大并發(fā)用戶數(shù) 最大數(shù)據(jù)容

25、量（5）單元測試、集成測試、系統(tǒng)測試的區(qū)別與聯(lián)系 單元測試 單元測試是對(duì)軟件基本組成單元（軟件設(shè)計(jì)的最小單位）進(jìn)行正確性檢驗(yàn)的測試工作，如 函 數(shù) 、 過 程 （function,procedure） 或 一 個(gè) 類 的 方 法 （method） 集成測試 集成測試是在單元測試的基礎(chǔ)上，將所有模塊按照概要設(shè)計(jì)要求組裝成為子系統(tǒng)或系統(tǒng)， 驗(yàn)證組裝后功能以及模塊間接口是否正確的測試工作。集成測試也叫組裝測試、聯(lián)合測試、 子系統(tǒng)測試或部件測試 系統(tǒng)測試 系統(tǒng)測試是將已經(jīng)集成好的軟件系統(tǒng)，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬 件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際使

26、用環(huán)境下， 對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測試和確認(rèn)測試的工作單元測試 白盒測試 集成測試 灰盒測試單元內(nèi)部的數(shù)據(jù)結(jié)構(gòu)，邏輯控制，異常處理等邏輯覆蓋率模塊間接口以及模塊組合后的整體功能接口覆蓋率系統(tǒng)測試 黑盒測試整個(gè)系統(tǒng)對(duì)需求的符合度測試用例對(duì)需求的覆蓋率詳設(shè)概設(shè)需求第十三章 部署測試環(huán)境（設(shè)計(jì)測試環(huán)境）25、測試環(huán)境重要性（詳見書本 289 頁） 使用錯(cuò)誤的測試環(huán)境，可能引起下列一系列問題： 得出錯(cuò)誤結(jié)果 與實(shí)際誤差很大 忽略了實(shí)際使用可能出現(xiàn)的嚴(yán)重錯(cuò)誤 導(dǎo)致項(xiàng)目返工，成本加大 導(dǎo)致項(xiàng)目延期26、（ 1）測試環(huán)境 5 要素硬件軟件數(shù)據(jù)準(zhǔn)備網(wǎng)絡(luò)環(huán)境測試工具（2）數(shù)據(jù)準(zhǔn)備（需要理解透徹） 數(shù)據(jù)準(zhǔn)備

27、包括數(shù)據(jù)量和真實(shí)性兩個(gè)方法。 （詳見書本 294 頁） 第十五章 報(bào)告所發(fā)現(xiàn)的缺陷27、（1）軟件缺陷 軟件缺陷指的是系統(tǒng)或系統(tǒng)部件中那些導(dǎo)致系統(tǒng)或部件不能實(shí)現(xiàn)其功能的缺陷。如 果在執(zhí)行中遇到一個(gè)缺陷，可能引起系統(tǒng)的失效。那么準(zhǔn)確有效的定義和描述軟件缺陷， 可以使軟件缺陷得以快速修復(fù)，節(jié)約了軟件測試項(xiàng)目的成本和資源，提高產(chǎn)品質(zhì)量。（2）軟件缺陷描述的基本要求 軟件缺陷的描述是軟件缺陷報(bào)告中測試人員對(duì)問題的陳述的一部分并且是軟件缺陷 報(bào)告的基礎(chǔ)部分。同時(shí)，軟件缺陷的描述也是測試人員就一個(gè)軟件問題與開發(fā)小組交流的 最初且最好的機(jī)會(huì)。一個(gè)好的描述，需要使用簡單的、準(zhǔn)確的、專業(yè)的語言來抓住缺陷的 本質(zhì)

28、。單一準(zhǔn)確可以再現(xiàn)完整統(tǒng)一短小簡練特定條件補(bǔ)充完善不做評(píng)價(jià)28、分離和再現(xiàn)缺陷原理 開發(fā)人員有時(shí)可以根據(jù)相對(duì)簡單的錯(cuò)誤信息就能找出問題所在。因?yàn)殚_發(fā)人員熟悉代 碼，因此看到癥狀、測試用例步驟和分離問題的過程時(shí)，可能得到查找軟件缺陷的線索。一個(gè)軟件缺陷的分離和再現(xiàn)問題有時(shí)需要小組的共同努力。如果軟件測試人員盡最大努力 分離軟件缺陷，也無法表達(dá)準(zhǔn)確的再現(xiàn)步驟，那么仍然需要記錄和報(bào)告軟件缺陷。29、缺陷描述的主要內(nèi)容軟件缺陷的詳細(xì)描述，由三部分組成：操作/ 重現(xiàn)步驟、期望結(jié)果、實(shí)際結(jié)果，有必要再做進(jìn)一步的討論：“步驟 ”提供了如何重復(fù)當(dāng)前缺陷的準(zhǔn)確描述，應(yīng)簡明而完備、清楚而準(zhǔn)確。這些信息對(duì)開發(fā)人員是

29、關(guān)鍵的， 視為修復(fù)缺陷的向?qū)В?開發(fā)人員有時(shí)抱怨糟糕的缺陷報(bào)告， 往往集中在這里；“期望結(jié)果 ”與測試用例標(biāo)準(zhǔn)或設(shè)計(jì)規(guī)格說明書或用戶需求等一致，達(dá)到軟件預(yù)期的 功能。測試人員站在用戶的角度要對(duì)它進(jìn)行描述，它提供了驗(yàn)證缺陷的依據(jù)?！皩?shí)際結(jié)果 ”測試人員收集的結(jié)果和信息，以確認(rèn)缺陷確實(shí)是一個(gè)問題，并標(biāo)識(shí)那些 影響到缺陷表現(xiàn)的要素。優(yōu)秀的缺陷報(bào)告重現(xiàn)步驟 :a） 打開一個(gè)編輯文字的軟件并且創(chuàng)建一個(gè)新的文檔（這個(gè)文件可以錄入文字）b） 在這個(gè)文件里隨意錄入一兩行文字c） 選中一兩行文字，通過選擇 Font 菜單然后選擇 Arial 字體格式d） 一兩行文字變成了無意義的亂字符期望結(jié)果：當(dāng)用戶選擇已錄入

30、的文字并改變文字格式的時(shí)候，文本應(yīng)該顯示正確的文字格 式不會(huì)出現(xiàn)亂字符顯示。實(shí)際結(jié)果 :它是字體格式的問題，如果改變文字格式成Arial 之前，你保存文件，缺陷不會(huì)出現(xiàn)。缺陷僅僅發(fā)生在 Windows98 并且改變文字格式成其它的字體格式， 文字是顯示正常的第十七章 軟件測試項(xiàng)目管理30、測試目標(biāo)與準(zhǔn)則（詳見書本 359 頁） （1）目標(biāo)（為什么要進(jìn)行軟件測試）（2）準(zhǔn)則（3）測試范圍優(yōu)先級(jí)最高的需求功能新功能和編碼改動(dòng)較大 （提高性能表現(xiàn) ）的舊功能 運(yùn)用有效的測試技術(shù)去提高測試效果 經(jīng)常容易出現(xiàn)問題部分的功能 一些經(jīng)常被用戶使用的功能和配置31、測試計(jì)劃內(nèi)容（詳見書本 360 頁）測試計(jì)劃制定的第一步就是將軟件分解較小而且相對(duì)獨(dú)立的功能模塊，寫成測試需求。 測試需求有很多分類方法，最普通的一種就是按照功能分類：測試需求是測試設(shè)計(jì)和開發(fā)測試用例