第一篇：軟件測(cè)試 填空題

1、軟件質(zhì)量工程包括軟件質(zhì)量保證、軟件質(zhì)量規(guī)劃和軟件質(zhì)量控制三大方面。

2、McCall模型產(chǎn)品修改緯度的質(zhì)量因素有 可維護(hù)性、可測(cè)試性、靈活性。

3、面向?qū)ο竽Ｐ筒煌谄渌Ｐ偷闹饕卣魇?組件的密集重用。

4、有兩種同行評(píng)審方法學(xué)：審查和走查。

5、RMA可以劃分成三組類別 內(nèi)部風(fēng)險(xiǎn)管理措施，分包風(fēng)險(xiǎn)管理措施，顧客風(fēng)險(xiǎn)管理措施

6、支持性質(zhì)量手段有模板和檢查表。

7、依據(jù)軟件系統(tǒng)的生命周期和其他階段，軟件質(zhì)量度量劃分為軟件過程度量和軟件產(chǎn)品度量。

8、軟件配置發(fā)布的版本有基線版本、中間版本、修訂版本。

9、SQA標(biāo)準(zhǔn)被劃分成軟件質(zhì)量管理標(biāo)準(zhǔn)和軟件項(xiàng)目過程標(biāo)準(zhǔn)兩類。

10、軟件缺陷的固有特征有軟件缺陷的固有性、軟件缺陷的敏感性、軟件缺陷的感染性。

11、McCall模型劃分了軟件運(yùn)行、軟件轉(zhuǎn)移、軟件修改三個(gè)緯度的11個(gè)軟件質(zhì)量因素。

12、螺旋模型任何一次迭代都可劃分為制定計(jì)劃、風(fēng)險(xiǎn)分析和化解、工程和顧客評(píng)估四個(gè)項(xiàng)限。

13、依據(jù)合同評(píng)審的目標(biāo)對(duì)合同評(píng)審主題進(jìn)行分類為建議草案評(píng)審主題和合同草案評(píng)審主題兩種類型。

14、典型的版本方針包括嚴(yán)格-單一活動(dòng)版本方針、多版本方針。

15、軟件對(duì)屬于各種質(zhì)量因素的需求的符合性是由軟件質(zhì)量度量來測(cè)量的。

16、CAPA過程的成功運(yùn)行包含如下活動(dòng)：信息收集、信息分析、解決方案和改進(jìn)方法的建立、改進(jìn)方法的執(zhí)行、跟蹤。

17、常見的軟件配置演化模型有線性演化模型和樹演化模型。

18、軟件更改的質(zhì)量保證工作需要每個(gè)更改的SCI的質(zhì)量保證和整個(gè)新軟件系統(tǒng)版本的質(zhì)量保證兩個(gè)級(jí)別的活動(dòng)。

19、從內(nèi)容和重點(diǎn)上我們可以把質(zhì)量管理標(biāo)準(zhǔn)劃分成認(rèn)證標(biāo)準(zhǔn)和評(píng)估標(biāo)準(zhǔn)兩種類型。

20、測(cè)試人員、SQA單位是SQA專職人員。

21、CMM內(nèi)容包含初始級(jí)、可重復(fù)級(jí)、已定義級(jí)、已管理級(jí)和可優(yōu)化級(jí)五個(gè)等級(jí)。

22、軟件質(zhì)量保證的目標(biāo)包括面向產(chǎn)品的軟件開發(fā)和面向過程的軟件維護(hù)兩大方面。

23、開發(fā)生命周期階段SQA部件可以劃分成三類：評(píng)審、專家觀點(diǎn)、軟件測(cè)試、軟件維護(hù)SQA部件和由第三方/分包商使用的SQA部件。

24、是維護(hù)方針的主要組成。

25、外部參與方可被分類為、COTS軟件和重用軟件模塊的供貨

商和顧客自身三組。

26、在任何機(jī)構(gòu)中，CAPA要正確發(fā)揮作用需要蹤、CAPA執(zhí)行的跟蹤和CAPA執(zhí)行結(jié)果的跟蹤三個(gè)要的跟蹤任務(wù)。

27、軟件更改的質(zhì)量保證工作需要每個(gè)更改的SCI的質(zhì)量保證和整個(gè)新軟件系統(tǒng)版本的質(zhì)量保證兩個(gè)級(jí)別的活動(dòng)。

28、軟件過程度量可以進(jìn)一步劃分為、軟件過程進(jìn)度度量和軟件過程生產(chǎn)率度量。

29、從內(nèi)容和重點(diǎn)上我們可以把質(zhì)量管理標(biāo)準(zhǔn)劃分成和評(píng)估標(biāo)準(zhǔn)兩種類型。

30、通常，軟件質(zhì)量的管理部件有項(xiàng)目進(jìn)展控制、軟件質(zhì)量度量、軟件質(zhì)量費(fèi)用和可用于控制軟件維護(hù)的工具SQA管理工具。

31、軟件測(cè)試過程包含的測(cè)試活動(dòng)有測(cè)試計(jì)劃，測(cè)試設(shè)計(jì)，測(cè)試實(shí)施，測(cè)試執(zhí)行，缺陷跟蹤和測(cè)試評(píng)估

32、軟件測(cè)試策略的確定過程通常經(jīng)歷確定測(cè)試需求、評(píng)估風(fēng)險(xiǎn)、確定測(cè)試策略三個(gè)階段組成。

33、變異測(cè)試的理論基礎(chǔ)是程序員能力假設(shè)和組合效應(yīng)假設(shè)。

34、軟件缺陷打開/關(guān)閉圖表、根本原因圖表、軟件缺陷關(guān)閉周期表是常用的軟件缺陷跟蹤圖表。

35、軟件測(cè)試規(guī)范可以分為行業(yè)規(guī)范和操作規(guī)范。

36、通常，由人工進(jìn)行的靜態(tài)測(cè)試方法包括桌面檢查、代碼審查、代碼走查和技術(shù)評(píng)審。

37、典型的測(cè)試設(shè)計(jì)活動(dòng)包括 測(cè)試用例設(shè)計(jì)、測(cè)試過程設(shè)計(jì)、設(shè)計(jì)驅(qū)動(dòng)程序和穩(wěn)定的樁。

38、按照測(cè)試的層次和策略,軟件測(cè)試可以分為單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試 和 系統(tǒng)測(cè)試。

39、為了考察測(cè)試用例的重要性，我們可以從有效性、可重用性、易組織性、可評(píng)估性、可管理性五方面理解。

40、面向?qū)ο蠹蓽y(cè)試常見方法包括 抽樣測(cè)試、正交矩陣（陣列）測(cè)試。

41、面向?qū)ο鬁y(cè)試充分性三個(gè)常用標(biāo)準(zhǔn)是基于狀態(tài)的覆蓋率、基于約束的覆蓋率 和基于代碼的覆蓋率。

42、常見的程序分析視角有句法視角，功能視角、文本視角和計(jì)算流視角

43、按照測(cè)試用例的設(shè)計(jì)方法，軟件測(cè)試可以分為白盒測(cè)試、黑盒測(cè)試和灰盒測(cè)試。

44、我們可以按照 編寫過程、執(zhí)行 過程和 組織過程三個(gè)緯度對(duì)測(cè)試用例屬性進(jìn)行歸類。

45、單元測(cè)試內(nèi)容包含如下方面：模塊接口測(cè)試、邊界條件測(cè)試、錯(cuò)誤處理測(cè)試、局部數(shù)據(jù)結(jié)構(gòu)測(cè)試 和重要路徑測(cè)試。

46、軟件質(zhì)量工程包括軟件質(zhì)量保證、軟件質(zhì)量規(guī)劃 和軟件質(zhì)量控制三大方面。

47、McCall模型產(chǎn)品修改緯度的質(zhì)量因素有可維護(hù)性、可測(cè)試性、靈活性。

1.3、面向?qū)ο竽Ｐ筒煌谄渌Ｐ偷闹饕卣魇墙M件的密集重用。

48、有兩種同行評(píng)審方法學(xué)：審查和走查。

49、RMA可以劃分成三組類別內(nèi)部風(fēng)險(xiǎn)管理措施、分包風(fēng)險(xiǎn)管理措施和顧客風(fēng)險(xiǎn)管理措施。

50、支持性質(zhì)量手段有模板和檢查表。

51、依據(jù)軟件系統(tǒng)的生命周期和其他階段，軟件質(zhì)量度量劃分為軟件過程度量 和軟件產(chǎn)品度量。

52、軟件配置發(fā)布的版本有基線版本、中間版本、修訂版本。

53、SQA標(biāo)準(zhǔn)被劃分成軟件質(zhì)量管理標(biāo)準(zhǔn)和軟件項(xiàng)目過程標(biāo)準(zhǔn)兩類。

54、軟件缺陷的固有特征有軟件缺陷的固有性、軟件缺陷的敏感性、軟件缺陷的感染性。

55、McCall模型劃分了軟件運(yùn)行、軟件轉(zhuǎn)移、軟件修改三個(gè)緯度的11個(gè)軟件質(zhì)量因素。

56、螺旋模型任何一次迭代都可劃分為制定計(jì)劃、風(fēng)險(xiǎn)分析和化解、工程和顧客評(píng)估四個(gè)項(xiàng)限。

57、依據(jù)合同評(píng)審的目標(biāo)對(duì)合同評(píng)審主題進(jìn)行分類為建議草案評(píng)審主題和 合同草案評(píng)審主題兩種類型。

58、典型的版本方針包括嚴(yán)格-單一活動(dòng)版本方針、多版本方針。

2.5、軟件對(duì)屬于各種質(zhì)量因素的需求的符合性是由軟件質(zhì)量度量來測(cè)量的。

59、CAPA過程的成功運(yùn)行包含如下活動(dòng)：信息收集、信息分析、解決方案和改進(jìn)方法的建立、改進(jìn)方法的執(zhí)行、跟蹤。

60、常見的軟件配置演化模型有線性演化模型和樹演化模型。

61、軟件更改的質(zhì)量保證工作需要每個(gè)更改的SCI的質(zhì)量保證和整個(gè)新軟件系統(tǒng)版本的質(zhì)量保證兩個(gè)級(jí)別的活動(dòng)。

62、從內(nèi)容和重點(diǎn)上我們可以把質(zhì)量管理標(biāo)準(zhǔn)劃分成認(rèn)證標(biāo)準(zhǔn)和評(píng)估標(biāo)準(zhǔn)兩種類型。

63、測(cè)試人員、SQA單位是SQA專職人員。

64、CMM內(nèi)容包含初始級(jí)、可重復(fù)級(jí)、已定義級(jí)、已管理級(jí)和可優(yōu)化級(jí)五個(gè)等級(jí)。

65、軟件質(zhì)量保證的目標(biāo)包括面向產(chǎn)品的軟件開發(fā)和面向過程的軟件維護(hù)兩大方面。

66、開發(fā)生命周期階段SQA部件可以劃分成三類：評(píng)審、專家觀點(diǎn)、軟件測(cè)試、軟件維護(hù)SQA部件和由第三方/分包商使用的SQA部件。

67、版本方針和更改方針 是維護(hù)方針的主要組成。

68、外部參與方可被分類為分包商、COTS軟件和重用軟件模塊的供貨商和 顧客自身三組。

69、在任何機(jī)構(gòu)中，CAPA要正確發(fā)揮作用需要CAPA記錄流的跟蹤、CAPA執(zhí)行的跟蹤和CAPA執(zhí)行結(jié)果的跟蹤三個(gè)要的跟蹤任務(wù)。

70、軟件更改的質(zhì)量保證工作需要每個(gè)更改的SCI的質(zhì)量保證和整個(gè)新軟件系統(tǒng)版本的質(zhì)量保證兩個(gè)級(jí)別的活動(dòng)。

71、軟件過程度量可以進(jìn)一步劃分為軟件過程質(zhì)量度量、軟件過程進(jìn)度度量和軟件過程生產(chǎn)率度量。

72、從內(nèi)容和重點(diǎn)上我們可以把質(zhì)量管理標(biāo)準(zhǔn)劃分成認(rèn)證標(biāo)準(zhǔn)和評(píng)估

73、通常，軟件質(zhì)量的管理部件有項(xiàng)目進(jìn)展控制、軟件質(zhì)量度量、軟件質(zhì)量費(fèi)用 和可用于控制軟件維護(hù)的工具SQA管理工具。

74、軟件測(cè)試的目的是盡可能多地發(fā)現(xiàn)軟件中存在的 錯(cuò)誤，將測(cè)試 測(cè)試結(jié)果作為糾錯(cuò)的依據(jù)。

75、測(cè)試階段的基本任務(wù)是根據(jù)軟件開發(fā)各階段的 文檔資料和程序的內(nèi)部結(jié)構(gòu)，精心設(shè)計(jì)一組 測(cè)試用例，利用這些實(shí)例執(zhí)行程序，找出軟件中潛在的各種錯(cuò)誤和 缺陷。

76、測(cè)試用例由 輸入數(shù)據(jù)和預(yù)期的 輸出數(shù)據(jù)兩部分組成。

77、軟件測(cè)試方法一般分為兩大類：動(dòng)態(tài)測(cè)試方法和靜態(tài)測(cè)試方法。

78、動(dòng)態(tài)測(cè)試通過 運(yùn)行程序發(fā)現(xiàn)錯(cuò)誤。根據(jù) 測(cè)試用例的設(shè)計(jì)方法不同，動(dòng)態(tài)測(cè)試又分為 黑盒測(cè)試與白盒測(cè)試兩類。

79、靜態(tài)測(cè)試采用 人工檢測(cè)和 計(jì)算機(jī)輔助靜態(tài)分析的手段對(duì)程序進(jìn)行檢測(cè)。

80、人工審查程序偏重于 編碼質(zhì)量的檢驗(yàn)，而軟件審查除了審查 編碼還要對(duì)各階段 軟件產(chǎn)品進(jìn)行檢驗(yàn)。

81、計(jì)算機(jī)輔助靜態(tài)分析利用 靜態(tài)分析工具對(duì)測(cè)試程序進(jìn)行 特性分析。

82、黑盒法只在軟件的 接口處進(jìn)行測(cè)試，依據(jù) 需求規(guī)格說明書，檢查程序是否滿足 功能要求。

83、白盒法必須考慮程序的 內(nèi)部結(jié)構(gòu)和 處理過程，以檢查 處理過程的細(xì)節(jié)為基礎(chǔ)，對(duì)程序中盡可能多的邏輯路徑進(jìn)行 測(cè)試。

84、白盒測(cè)試是 結(jié)構(gòu)測(cè)試，被測(cè)對(duì)象是 源程序，以程序的 內(nèi)部邏輯為基礎(chǔ)設(shè)計(jì)測(cè)試用例。

85、邏輯覆蓋是對(duì)程序內(nèi)部有判定存在的邏輯結(jié)構(gòu)設(shè)計(jì)測(cè)試用例，根據(jù)程序內(nèi)部的邏輯覆蓋程度又可分為 語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋6種覆蓋技術(shù)。

86、實(shí)際的邏輯覆蓋測(cè)試中，一般以 條件組合覆蓋為主設(shè)計(jì)測(cè)試用例，然后再補(bǔ)充部分用例，以達(dá)到 路徑覆蓋測(cè)試標(biāo)準(zhǔn)。

87、循環(huán)覆蓋是對(duì)程序內(nèi)部有 循環(huán) 存在的邏輯結(jié)構(gòu)設(shè)計(jì)測(cè)試用例，它通過限制 循環(huán)次數(shù)來測(cè)試。

88、基本路徑測(cè)試是在程序 控制流程圖基礎(chǔ)上，通過分析控制構(gòu)造的 環(huán)路復(fù)雜性，導(dǎo)出基本路徑集合，從而設(shè)計(jì)測(cè)試用例。

89、黑盒測(cè)試是 功能測(cè)試，用黑盒技術(shù)設(shè)計(jì)測(cè)試用例有4種方法：等價(jià)類劃分邊界值分析錯(cuò)誤推測(cè)因果圖。

90、等價(jià)類劃分從程序的功能說明，找出一個(gè)輸入條件（通常是一句話或一個(gè)短語），然后將每個(gè)輸入條件劃分成兩個(gè)或多個(gè) 等價(jià)類。

91、邊界值分析是將測(cè)試 邊界情況作為重點(diǎn)目標(biāo)，選取正好等于、剛剛大于或剛剛小于邊界值的測(cè)試數(shù)據(jù)。如果輸入或輸出域是一個(gè)有序集合，則應(yīng)選取集合的 第一個(gè)元素和 最后一個(gè)元素作為測(cè)試用例。

92、在測(cè)試程序時(shí)，根據(jù)經(jīng)驗(yàn)或直覺推測(cè)程序中可能存在的各種錯(cuò)誤，稱為 錯(cuò)誤推測(cè)法。

93、因果圖的基本原理是通過畫因果圖，把用自然語言描述的 功能說明轉(zhuǎn)換為判定表，最后為判定表每一列設(shè)計(jì)一個(gè)測(cè)試用例。

94、測(cè)試的綜合策略是在測(cè)試中，聯(lián)合使用各種測(cè)試方法。通常先用黑

95、軟件測(cè)試過程中需要3類信息：軟件配置、測(cè)試配置和測(cè)試工具。

23．軟件測(cè)試一般經(jīng)過4個(gè)測(cè)試：?jiǎn)卧獪y(cè)試集成測(cè)試確認(rèn)測(cè)試系統(tǒng)測(cè)試。

96、單元測(cè)試 指對(duì)源程序中每一個(gè)程序單元進(jìn)行測(cè)試，檢查各個(gè)模塊是否正確實(shí)現(xiàn)規(guī)定的功能，從而發(fā)現(xiàn)模塊在編碼中或算法中的錯(cuò)誤，它涉及編碼和 詳細(xì)設(shè)計(jì)的文檔。

97、單元測(cè)試主要測(cè)試模塊的5個(gè)基本特征：模塊接口局部數(shù)據(jù)結(jié)構(gòu)重要的執(zhí)行路徑錯(cuò)誤處理邊界條件。

98、在單元測(cè)試中，需要為被測(cè)模塊設(shè)計(jì)驅(qū)動(dòng)模塊和樁模塊。驅(qū)動(dòng)模塊用來模擬被測(cè)模塊的上級(jí)調(diào)用模塊，樁模塊用來代替被測(cè)模塊所調(diào)用的模塊。

99、集成測(cè)試指在單元測(cè)試基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成一個(gè)完整的系統(tǒng)進(jìn)行的測(cè)試。也稱組裝測(cè)試或聯(lián)合測(cè)試。

100、集成測(cè)試的方法有兩種：非漸增式測(cè)試漸增式測(cè)試。

29．漸增式測(cè)試有兩種不同的組裝模塊的方法：自頂向下結(jié)合自底向上結(jié)合。

101、自頂向下漸增式測(cè)試不需要編寫驅(qū)動(dòng)模塊，只需要編寫樁模塊，其步驟是從模塊開始，沿著被測(cè)程序的頂層的控制路徑逐步向下測(cè)試，它有兩種組合策略：軟件結(jié)構(gòu)圖和深度優(yōu)先策略寬度優(yōu)先策略。102、自底向上漸增式測(cè)試不需要編寫樁模塊，只需要編寫驅(qū)動(dòng)模塊。103、確認(rèn)測(cè)試指檢查軟件的功能與性能是否與需求規(guī)格說明書中確定的指標(biāo)相符合，又稱有效性測(cè)試。

104、確認(rèn)測(cè)試在模擬環(huán)境下運(yùn)用黑盒測(cè)試方法，由專門測(cè)試人員和用戶 參加的測(cè)試。

105、確認(rèn)測(cè)試開始前需要制定測(cè)試計(jì)劃，結(jié)束后要寫出測(cè)試分析報(bào)告。其測(cè)試用例要選用實(shí)際運(yùn)用的數(shù)據(jù)。

106、軟件配置審查的任務(wù)是檢查軟件的所有文檔資料的 完整性和正確性。

107、調(diào)試也稱糾錯(cuò)，是在成功的測(cè)試之后才開始進(jìn)行，其目的是確定錯(cuò)誤的 原因和位置，并改正錯(cuò)誤。

108、調(diào)試技術(shù)包括簡(jiǎn)單調(diào)試歸納法調(diào)試演繹法調(diào)試回溯法調(diào)試109、回溯法調(diào)試是從程序產(chǎn)生錯(cuò)誤的地方出發(fā)，而歸納法調(diào)試是從測(cè)試結(jié)果發(fā)現(xiàn)的線索入手。

110、被測(cè)試程序不在機(jī)器上運(yùn)行，而是采用人工檢測(cè)和計(jì)算機(jī)輔助分析檢測(cè)的手段稱為靜態(tài)測(cè)試。

111、用等價(jià)類劃分法設(shè)計(jì)一個(gè)測(cè)試用例時(shí)，使其覆蓋盡可能多的尚未被覆蓋的合理等價(jià)類。

112、用等價(jià)類劃分法設(shè)計(jì)一個(gè)測(cè)試用例時(shí)，使其覆蓋一個(gè)不合理等價(jià)類。

113、在單元測(cè)試時(shí)，需要為被測(cè)模塊設(shè)計(jì)驅(qū)動(dòng)模塊與樁模塊。

114、在集成測(cè)試時(shí)有兩種測(cè)試方法，它們是漸增式和非漸增式。

115、軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。

116、運(yùn)行被測(cè)程序的方法稱為動(dòng)態(tài)測(cè)試。

117、動(dòng)態(tài)測(cè)試中，主要測(cè)試軟件功能的方法稱為黑盒法。

118、選擇測(cè)試用例，使得被測(cè)程序中每個(gè)判定的每個(gè)分支至少執(zhí)行一次，這種邏輯覆蓋標(biāo)準(zhǔn)稱為判定覆蓋。

119、要覆蓋含循環(huán)結(jié)構(gòu)的所有路徑是不可能的，一般通過限制循環(huán)次數(shù)來測(cè)試。

120、用等價(jià)類劃分法設(shè)計(jì)測(cè)試用例時(shí)，如果被測(cè)程序的某個(gè)輸入條件規(guī)定了取值范圍，則可確定一個(gè)合理的等在和兩個(gè)不合理的等價(jià)類。

121、憑經(jīng)驗(yàn)或直覺推測(cè)程序中可能存在的錯(cuò)誤而設(shè)計(jì)測(cè)試用例的方法是錯(cuò)誤推測(cè)法。

122、集成測(cè)試中的具體方法是漸增式和非漸增式測(cè)試方法。123、確認(rèn)測(cè)試階段的兩項(xiàng)工作是進(jìn)行確認(rèn)測(cè)試和軟件配置審查。124、在單元測(cè)試中，測(cè)試一個(gè)模塊時(shí)，需要設(shè)計(jì)驅(qū)動(dòng)模塊和樁模塊。

125、軟件配置管理，簡(jiǎn)稱SCM，它用于整個(gè)軟件工程過程。其主要目標(biāo)是：標(biāo)識(shí)變更 控制變更 確保變更正確地實(shí)現(xiàn) 報(bào)告有關(guān)變更

126、SCM是一組管理整個(gè)軟件生存期各階段中變更的活動(dòng)。

127、基線的作用是把各階段的開發(fā)工作劃分得更加明確，便于檢查與確認(rèn)階段成果。因此，基線可以作為項(xiàng)目的一個(gè)檢查點(diǎn)。

第二篇：軟件測(cè)試（推薦）

一、簡(jiǎn)答5*6’

1.為什么不讓時(shí)間有余的人做測(cè)試工作

表面上看這體現(xiàn)了管理的效率和靈活性，但實(shí)際上也體現(xiàn)了管理者對(duì)測(cè)試的輕視。測(cè)試和測(cè)試的人有很大關(guān)系。測(cè)試工作人員應(yīng)該是勤奮并富有耐心，善于學(xué)習(xí)、思考和發(fā)現(xiàn)問題，細(xì)心有條理，總結(jié)問題，如果具備這樣的優(yōu)點(diǎn)，做其它工作同樣也會(huì)很出色，因此這里還有一個(gè)要求，就是要喜歡測(cè)試這項(xiàng)工作。2.軟件測(cè)試風(fēng)險(xiǎn)主要體現(xiàn)在哪里

我們沒有對(duì)軟件進(jìn)行完全測(cè)試，實(shí)際就是選擇了風(fēng)險(xiǎn)，因?yàn)槿毕輼O有可能存在沒有進(jìn)行測(cè)試的部分。因此，我們要盡可能的選擇最合適的測(cè)試量，把風(fēng)險(xiǎn)降低到最小 3.所有軟件測(cè)試缺陷都需要修復(fù)嗎

從技術(shù)上講，所有的軟件缺陷都是能夠修復(fù)的，但是沒有必要修復(fù)所有的軟件缺陷。測(cè)試人員要做的是能夠正確判斷什么時(shí)候不能追求軟件的完美。對(duì)于整個(gè)項(xiàng)目團(tuán)隊(duì)，要做的是對(duì)每一個(gè)軟件缺陷進(jìn)行取舍，根據(jù)風(fēng)險(xiǎn)決定那些缺陷要修復(fù)。發(fā)生這種現(xiàn)象的主要原因如下：-沒有足夠的時(shí)間資源。在任何一個(gè)項(xiàng)目中，通常情況下開發(fā)人員和測(cè)試人員都是不夠用的，而且在項(xiàng)目中沒有預(yù)算足夠的回歸測(cè)試時(shí)間，修改缺陷可能引入新的缺陷。

-有些缺陷只是特殊情況下出現(xiàn)，這種缺陷處于商業(yè)利益考慮，可以在以后升級(jí)中進(jìn)行修復(fù)。-不是缺陷的缺陷。我們經(jīng)常會(huì)碰到某些功能方面的問題被當(dāng)成缺陷來處理，這類問題可以以后有時(shí)間時(shí)考慮再處理。缺陷是否修改要由軟件測(cè)試人員、項(xiàng)目經(jīng)理、程序員共同討論來決定是否修復(fù)，不同角色的人員從不同的角度來思考，以做出正確的決定。4.如何減少測(cè)試人員跳槽帶來的損失 建議我們從以下兩個(gè)方面做起：

-加強(qiáng)部門內(nèi)員工之間的互相學(xué)習(xí)，互相學(xué)習(xí)是建立學(xué)習(xí)型組織的基本要求，是知識(shí)互相轉(zhuǎn)移的過程。在此基礎(chǔ)上，可以把個(gè)人擁有的技術(shù)以知識(shí)的形式沉積下來，也就完成了隱性知識(shí)到顯性知識(shí)的轉(zhuǎn)化。

-管理者就應(yīng)該把員工的個(gè)人成長(zhǎng)和企業(yè)的發(fā)展聯(lián)系起來，為員工設(shè)定合理發(fā)展規(guī)劃并付諸實(shí)現(xiàn)。

5.驗(yàn)收測(cè)試的注意點(diǎn)有哪些 測(cè)試要注意下面的事項(xiàng)：

（1）用戶現(xiàn)場(chǎng)測(cè)試不可能測(cè)試全部功能，因此要測(cè)試核心功能。這需要提前做好準(zhǔn)備，這些核心功能一定要預(yù)先經(jīng)過測(cè)試，證明沒有問題才可以和用戶共同進(jìn)行測(cè)試。測(cè)試核心模塊的目的是建立用戶對(duì)軟件的信心。當(dāng)然如果這些模塊如果問題較多，不應(yīng)該進(jìn)行演示。（2）如果某些模塊確實(shí)有問題，我們可以演示其它重要的業(yè)務(wù)功能模塊，必要時(shí)要向用戶做成合理的解釋。爭(zhēng)得時(shí)間后，及時(shí)修改缺陷來彌補(bǔ)。（3）永遠(yuǎn)不能欺騙用戶，蒙混過關(guān)。6.完全測(cè)試程序是可能的嗎

實(shí)際上完全測(cè)試是不可能的。主要有以下原因：-完全測(cè)試比較耗時(shí)，時(shí)間上不允許；

-完全測(cè)試通常意味著較多資源投入，這在現(xiàn)實(shí)中往往是行不通的；-輸入量太大，不能一一進(jìn)行測(cè)試；-輸出結(jié)果太多，只能分類進(jìn)行驗(yàn)證；-軟件實(shí)現(xiàn)途徑太多；

-軟件產(chǎn)品說明書沒有客觀標(biāo)準(zhǔn)，從不同的角度看，軟件缺陷的標(biāo)準(zhǔn)不同；因此測(cè)試的程度要根據(jù)實(shí)際情況確定 7.是不是發(fā)現(xiàn)的缺陷越多就說明軟件缺陷越多 其中的原因主要如下：

-代碼復(fù)用、拷貝代碼導(dǎo)致程序員容易犯相同的錯(cuò)誤。類的繼承導(dǎo)致所有的子類會(huì)包含基類的錯(cuò)誤，反復(fù)拷貝同一代碼意味可能也復(fù)制了缺陷。-程序員比較勞累是可以導(dǎo)致某些連續(xù)編寫的功能缺陷較多。

“缺陷一個(gè)連著一個(gè)”不是一個(gè)客觀規(guī)律，只是一個(gè)常見的現(xiàn)象。如果軟件編寫的比較好，這種現(xiàn)象就不常見了。測(cè)試人員只要嚴(yán)肅認(rèn)真的測(cè)試程序就可以了。8.軟件測(cè)試就是QA嗎

軟件測(cè)試人員的職責(zé)是盡可能早的找出軟件缺陷，確保得以修復(fù)。而質(zhì)量保證人員（QA）主要職責(zé)是創(chuàng)建或者制定標(biāo)準(zhǔn)和方法，提高促進(jìn)軟件開發(fā)能力和減少軟件缺陷。測(cè)試人員的主要工作是測(cè)試，質(zhì)量保證人員日常工作重要內(nèi)容是檢查與評(píng)審，測(cè)試工作也是測(cè)試保證人員的工作對(duì)象。軟件測(cè)試和質(zhì)量是相輔相成的關(guān)系，都是為了提高軟件質(zhì)量而工作。9.測(cè)試產(chǎn)品和測(cè)試項(xiàng)目區(qū)別

習(xí)慣上把開發(fā)完成后進(jìn)行商業(yè)化、幾乎不進(jìn)行代碼修改就可以售給用戶使用的軟件成為軟件產(chǎn)品，也就是可以買“賣拷貝”的軟件，軟件項(xiàng)目是一種個(gè)性化的產(chǎn)品，可以是按照用戶要求全部重新開發(fā)，也可以修改已有的軟件產(chǎn)品來滿足特定的用戶需求。項(xiàng)目和產(chǎn)品的不同特點(diǎn)，決定我們測(cè)試產(chǎn)品和測(cè)試項(xiàng)目仍然會(huì)有很多不同的地方：

-質(zhì)量要求不同。通常產(chǎn)品的質(zhì)量要高一些，修復(fù)發(fā)布后產(chǎn)品的缺陷成本較高，甚至?xí)砗芏嘭?fù)面的影響。而做項(xiàng)目通常面向某一用戶，雖然質(zhì)量越高越好，但是一般只要滿足用戶要求就可以了。測(cè)試資源投入多少不同。做軟件產(chǎn)品通常是研發(fā)中心來開發(fā)，進(jìn)度壓力要小些。同時(shí)由于質(zhì)量要求高，因此會(huì)投入較多的人力、物力資源。項(xiàng)目最后要和用戶共同驗(yàn)收測(cè)試，這是產(chǎn)品測(cè)試不具有的特點(diǎn)。此外，測(cè)試產(chǎn)品與測(cè)試項(xiàng)目在缺陷管理方面、測(cè)試策略制定都會(huì)有很大不同，測(cè)試管理者應(yīng)該結(jié)合具體的環(huán)境，恰如其分的完成工作 10.如何編寫提交給用戶的測(cè)試報(bào)告

測(cè)試報(bào)告一般分為內(nèi)部測(cè)試報(bào)告和外部測(cè)試報(bào)告。內(nèi)部報(bào)告是我們?cè)跍y(cè)試工作中的項(xiàng)目文檔，反映了測(cè)試工作的實(shí)施情況,一般外部測(cè)試報(bào)告要滿足下面幾個(gè)要求：

根據(jù)內(nèi)部測(cè)試報(bào)告進(jìn)行編寫，一般可以摘錄；不可以向客戶報(bào)告嚴(yán)重缺陷，即使是已經(jīng)修改的缺陷，開發(fā)中的缺陷也沒有必要讓客戶知道；報(bào)告上可以列出一些缺陷，但必須是中級(jí)的缺陷，而且這些缺陷必須是修復(fù)的；報(bào)告上面的內(nèi)容盡量要真實(shí)可靠；整個(gè)測(cè)試報(bào)告要仔細(xì)審閱，力爭(zhēng)不給項(xiàng)目帶來負(fù)面作用，尤其是性能測(cè)試報(bào)告。總之，外部測(cè)試報(bào)告要小心謹(jǐn)慎的編寫。

二、論述2*12’

1.請(qǐng)論述為什么要進(jìn)行軟件測(cè)試，并列舉歷史上2~3個(gè)著名軟件測(cè)試（缺陷）案例，說明測(cè)試重要性

軟件測(cè)試的目的,第一是確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望做的事情（，另一方面是確認(rèn)軟件以正確的方式來做了這個(gè)事情。第二是提供信息，比如提供給開發(fā)人員或程序經(jīng)理的回饋信息，為風(fēng)險(xiǎn)評(píng)估所準(zhǔn)備的信息。第三軟件測(cè)試不僅是在測(cè)試軟件軟件產(chǎn)品本身，而且還包括軟件開發(fā)的過程。如果一個(gè)軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。因此，軟件測(cè)試的第三個(gè)目的是保證整個(gè)軟件開發(fā)過程是高質(zhì)量的。

愛國者導(dǎo)彈防御系統(tǒng)把“槍口”對(duì)準(zhǔn)了自己人 美國迪斯尼公司的獅子王游戲軟件的兼容性問題 售票系統(tǒng)性能問題

2.論述軟件測(cè)試科學(xué)的發(fā)展歷程 1957年之前－調(diào)試為主 20世紀(jì)50年代，計(jì)算機(jī)剛誕生不久，只有科學(xué)家級(jí)別的人才會(huì)去編程，需求和程序本身也遠(yuǎn)遠(yuǎn)沒有現(xiàn)在這么復(fù)雜多變，相當(dāng)于開發(fā)人員一人承擔(dān)需求分析，設(shè)計(jì)，開發(fā)，測(cè)試等所有工作，當(dāng)然也不會(huì)有人去區(qū)分調(diào)試和測(cè)試。

1957–1978－證明為主 當(dāng)時(shí)計(jì)算機(jī)應(yīng)用的數(shù)量，成本和復(fù)雜性都大幅度提升，隨之而來的經(jīng)濟(jì)風(fēng)險(xiǎn)也大大增加，測(cè)試就顯得很有必要了，這個(gè)時(shí)期測(cè)試的主要目就是確認(rèn)軟件是滿足需求的，也就是我們常說的“做了該做的事情”。

1979–1982－破壞為主 我們不僅要證明軟件做了該做的事情，也要保證它沒做不該做的事情，這會(huì)使測(cè)試更加全面，更容易發(fā)現(xiàn)問題。

1983–1987－評(píng)估為主 人們提出了在軟件生命周期中使用分析，評(píng)審，測(cè)試來評(píng)估產(chǎn)品的理論。軟件測(cè)試工程在這個(gè)時(shí)期得到了快速的發(fā)展.1988–至今－預(yù)防為主 預(yù)防為主是當(dāng)下軟件測(cè)試的主流思想之一。測(cè)試不是在編碼完成后才開始介入，而是貫穿于整個(gè)軟件生命周期。3.論述軟件缺陷的由來

軟件缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點(diǎn)和開發(fā)過程決定的。

軟件本身：①需求不清晰，導(dǎo)致設(shè)計(jì)目標(biāo)偏離客戶的需求，從而引起功能或產(chǎn)品特征上的缺陷。②系統(tǒng)結(jié)構(gòu)非常復(fù)雜，而又無法設(shè)計(jì)成一個(gè)很好的層次結(jié)構(gòu)或組件結(jié)構(gòu)，結(jié)果導(dǎo)致意想不到的問題或系統(tǒng)維護(hù)、擴(kuò)充上的困難；即使設(shè)計(jì)成良好的面向?qū)ο蟮南到y(tǒng)，由于對(duì)象、類太多，很難完成對(duì)各種對(duì)象、類相互作用的組合測(cè)試，而隱藏著一些參數(shù)傳遞、方法調(diào)用、對(duì)象狀態(tài)變化等方面問題。③對(duì)程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯(cuò)誤。④對(duì)一些實(shí)時(shí)應(yīng)用，要進(jìn)行精心設(shè)計(jì)和技術(shù)處理，保證精確的時(shí)間同步，否則容易引起時(shí)間上不協(xié)調(diào)，不一致性帶來的問題。⑤沒有考慮系統(tǒng)崩潰后的自我恢復(fù)或數(shù)據(jù)的異地備份、災(zāi)難性恢復(fù)等問題，從而存在系統(tǒng)安全性、可靠性的隱患。⑥系統(tǒng)運(yùn)行環(huán)境的復(fù)雜，不僅用戶使用的計(jì)算機(jī)環(huán)境千變?nèi)f化，包括用戶的各種操作方式或各種不同的輸入數(shù)據(jù)，容易引起一些特定用戶環(huán)境下的問題；在系統(tǒng)實(shí)際應(yīng)用中，數(shù)據(jù)量很大。從而會(huì)引起強(qiáng)度或負(fù)載問題。⑦由于通信端口多、存取和加密手段的矛盾性等，會(huì)造成系統(tǒng)的安全性或適用性等問題。⑧新技術(shù)的采用，可能涉及技術(shù)或系統(tǒng)兼容的問題，事先沒有考慮到。

團(tuán)隊(duì)工作：系統(tǒng)需求分析時(shí)對(duì)客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。不同階段的開發(fā)人員相互理解不一致。對(duì)于設(shè)計(jì)或編程上的一些假定或依賴性，相關(guān)人員沒有充分溝通。項(xiàng)目組成員技術(shù)水平參差不齊技術(shù)問題。算法錯(cuò)誤：在給定條件下沒能給出正確或準(zhǔn)確的結(jié)果。語法錯(cuò)誤：對(duì)于編譯性語言程序，編譯器可以發(fā)現(xiàn)這類問題；但對(duì)于解釋性語言程序，只能在測(cè)試運(yùn)行時(shí)發(fā)現(xiàn)。計(jì)算和精度問題：計(jì)算的結(jié)果沒有滿足所需要的精度。系統(tǒng)結(jié)構(gòu)不合理、算法選擇不科學(xué)，造成系統(tǒng)性能低下。接口參數(shù)傳遞不匹配，導(dǎo)致模塊集成出現(xiàn)問題。

項(xiàng)目管理的問題：缺乏質(zhì)量文化，不重視質(zhì)量計(jì)劃，對(duì)質(zhì)量、資源、任務(wù)、成本等的平衡性把握不好，容易擠掉需求分析、評(píng)審、測(cè)試、等時(shí)間，遺留的缺陷會(huì)比較多。系統(tǒng)分析時(shí)對(duì)客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。開發(fā)周期短，需求分析、設(shè)計(jì)、編程、測(cè)試等各項(xiàng)工作不能完全按照定義好的流程來進(jìn)行，工作不夠充分，結(jié)果也就不完整、不準(zhǔn)確，錯(cuò)誤較多；周期短，還給各類開發(fā)人員造成太大的壓力，引起一些人為的錯(cuò)誤。開發(fā)流程不夠完善，存在太多的隨機(jī)性和缺乏嚴(yán)謹(jǐn)?shù)膬?nèi)審或評(píng)審機(jī)制，容易產(chǎn)生問題。文檔不完善，風(fēng)險(xiǎn)估計(jì)不足等。4.軟件測(cè)試V模型

①繪制示意圖

②闡述每個(gè)步驟是做什么 需求分析

即首先要明確客戶需要的是什么，需要軟件作成什么樣子，需要有那幾項(xiàng)功能

概要設(shè)計(jì)

主要是架構(gòu)的實(shí)現(xiàn)，指搭建架構(gòu)、表述各模塊功能、模塊接口連接和數(shù)據(jù)傳遞的實(shí)現(xiàn)等項(xiàng)事務(wù)。詳細(xì)設(shè)計(jì)

對(duì)概要設(shè)計(jì)中表述的各模塊進(jìn)行深入分析，對(duì)各模塊組合進(jìn)行分析等。軟件編碼

按照詳細(xì)設(shè)計(jì)好的模塊功能表，編程人員編寫出實(shí)際的代碼。單元測(cè)試

按照設(shè)定好的最小測(cè)試單元進(jìn)行按單元測(cè)試，主要是測(cè)試程序代碼，為的是確保各單元模塊被正確的編譯，單元的具體劃分按不同的單位與不同的軟件有不同。集成測(cè)試

經(jīng)過了單元測(cè)試后，將各單元組合成完整的體系，主要測(cè)試各模塊間組合后的功能實(shí)現(xiàn)情況，以及模塊接口連接的成功與否，數(shù)據(jù)傳遞的正確性等，其主要目的是檢查軟件單位之間的接口是否正確。根據(jù)集成測(cè)試計(jì)劃，一邊將模塊或其他軟件單位組合成系統(tǒng)，一邊運(yùn)行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各組成部分是否合拍。系統(tǒng)測(cè)試

經(jīng)過了單元測(cè)試和集成測(cè)試以后，我們要把軟件系統(tǒng)搭建起來，按照軟件規(guī)格說明書中所要求，測(cè)試軟件其性能功能等是否和用戶需求相符合，在系統(tǒng)中運(yùn)行是否存在漏洞，等。驗(yàn)收測(cè)試

主要就是用戶在拿到軟件的時(shí)候，在使用現(xiàn)場(chǎng)，會(huì)根據(jù)前邊所提到的需求，以及規(guī)格說明書來做相應(yīng)測(cè)試，以確定軟件達(dá)到符合效果的。

第三篇：軟件測(cè)試復(fù)習(xí)資料

1． 黑盒測(cè)試法是通過分析程序的功能來設(shè)計(jì)測(cè)試用例的方法。

2． 黑盒測(cè)試除了測(cè)試程序外，它還適用于對(duì)需求分析階段的軟件文檔進(jìn)行測(cè)試。3． 白盒測(cè)試除了測(cè)試程序外，它也適用于對(duì)軟件具體設(shè)計(jì)階段的軟件文檔進(jìn)行測(cè)試。4． 單元測(cè)試一般以白盒測(cè)試法為主，測(cè)試的依據(jù)是模塊功能規(guī)格說明。5． 軟件測(cè)試中常用的靜態(tài)分析方法是引用分析和接口分析。

6． 測(cè)試人員的基本素質(zhì)為計(jì)算機(jī)專業(yè)技能、測(cè)試專業(yè)技能、行業(yè)知識(shí)

7． 軟件危機(jī)的體現(xiàn)為：A、開發(fā)成本和進(jìn)度估計(jì)不正確B、用戶對(duì)完成的軟件不滿足C、軟件經(jīng)常不可維護(hù)；

8． 軟件測(cè)試按照開發(fā)階段劃分：A、單元測(cè)試

B、集成測(cè)試；系統(tǒng)測(cè)試C、確認(rèn)測(cè)試；驗(yàn)收測(cè)試

9． 軟件測(cè)試按照測(cè)試技術(shù)劃分：A、性能測(cè)試、負(fù)載測(cè)試、壓力測(cè)試B、恢復(fù)測(cè)試、安全測(cè)試、兼容測(cè)試

10． 軟件測(cè)試項(xiàng)目周期是指：A、需求階段、測(cè)試計(jì)劃B、階段測(cè)試、設(shè)計(jì)階段測(cè)試、執(zhí)行階段 11． 軟件測(cè)試原則有：A、制定嚴(yán)格的測(cè)試計(jì)劃 B、保留所有的測(cè)試文檔C、功能測(cè)試中的缺陷確認(rèn) 12． 制定測(cè)試計(jì)劃的步驟：確定測(cè)試范圍、確定測(cè)試策略、確定測(cè)試標(biāo)準(zhǔn)、確定測(cè)試構(gòu)架、確定項(xiàng)目管理機(jī)制、預(yù)計(jì)測(cè)試工作量、測(cè)試計(jì)劃評(píng)審 13． 對(duì)于軟件的β測(cè)試，β測(cè)試就是在軟件公司外部展開的測(cè)試，由非專業(yè)的測(cè)試人員執(zhí)行的測(cè)試。14． 正式的技術(shù)評(píng)審FTR（Formal Technical Review）是軟件質(zhì)量保證活動(dòng)，其相關(guān)的描述為： A.FTR是評(píng)審產(chǎn)品而不是評(píng)審生產(chǎn)者的能力B.FTR要有嚴(yán)格的評(píng)審計(jì)劃并遵守日程安排C.FTR限制參與者人數(shù)并要求評(píng)審會(huì)之前做好預(yù)備 15． 在進(jìn)行單元測(cè)試時(shí)，常用的方法是采用白盒測(cè)試，輔之以黑盒測(cè)試

16． 側(cè)重于觀察資源耗盡情況下的軟件表現(xiàn)的系統(tǒng)測(cè)試被稱為壓力測(cè)試 17． 必須要求用戶參與的測(cè)試階段是驗(yàn)收測(cè)試 18． 系統(tǒng)測(cè)試的目的是對(duì)最終軟件系統(tǒng)進(jìn)行全面的測(cè)試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)。

19． 測(cè)試通常可分為白盒測(cè)試和黑盒測(cè)試。白盒測(cè)試是根據(jù)程序的內(nèi)部邏輯來設(shè)計(jì)測(cè)試用例,黑盒測(cè)試是根據(jù)軟件的規(guī)格說明來設(shè)計(jì)測(cè)試用例。20． 一個(gè)程序中所含有的路徑數(shù)與程序的復(fù)雜程度有著直接的關(guān)系。

1． 測(cè)試階段的根本目標(biāo)是盡可能多地發(fā)現(xiàn)并排除軟件中潛藏的錯(cuò)誤，最終把一個(gè)高質(zhì)量的軟件系統(tǒng)交給用戶使用。2． 功能測(cè)試時(shí)系統(tǒng)測(cè)試的主要內(nèi)容，檢查系統(tǒng)的功能、性能是否與需求規(guī)格說明相同。3． 軟件測(cè)試主要分為單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試四類測(cè)試。4． 漸增方式把模塊結(jié)合到程序中去時(shí)，有自頂向下和自底向上兩種集成策略。5． 編寫測(cè)試用例的依據(jù)是單元測(cè)試計(jì)劃和詳細(xì)設(shè)計(jì)說明書。6． 系統(tǒng)測(cè)試時(shí)在集成測(cè)試完成后，確認(rèn)測(cè)試之前進(jìn)行的測(cè)試。

7． 設(shè)計(jì)系統(tǒng)測(cè)試計(jì)劃需要參考的項(xiàng)目文檔有軟件測(cè)試計(jì)劃、軟件需求工件、和迭代計(jì)劃。

8． 測(cè)試設(shè)計(jì)員的職責(zé)有設(shè)計(jì)測(cè)試用例、設(shè)計(jì)測(cè)試過程、腳本。

9． 軟件驗(yàn)收測(cè)試包括正式驗(yàn)收測(cè)試、alpha測(cè)試、beta測(cè)試三種類型。10． 軟件測(cè)試按照開發(fā)階段劃分單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、確認(rèn)測(cè)試、驗(yàn)收測(cè)試。11． 軟件測(cè)試按照測(cè)試技術(shù)劃分性能測(cè)試、負(fù)載測(cè)試、壓力測(cè)試、恢復(fù)測(cè)試、安全測(cè)試、兼容測(cè)試

12． 靜態(tài)測(cè)試基本特征是在對(duì)軟件進(jìn)行分析、檢查和審閱，不實(shí)際運(yùn)行被測(cè)試的軟件 13． 軟件測(cè)試項(xiàng)目周期是指需求階段、測(cè)試計(jì)劃、階段測(cè)試、設(shè)計(jì)階段測(cè)試、執(zhí)行階段 14． 軟件測(cè)試的角色分析人員、設(shè)計(jì)人員、開發(fā)人員、執(zhí)行人員 15． 軟件測(cè)試原則有制定嚴(yán)格的測(cè)試計(jì)劃、、保留所有的測(cè)試文檔、功能測(cè)試中的缺陷確認(rèn)

16． 測(cè)試工作的文檔主要有：測(cè)試計(jì)劃、測(cè)試模型和用例設(shè)計(jì)或規(guī)格說明、測(cè)試分析報(bào)告等

17． 測(cè)試計(jì)劃的制定必須要注重測(cè)試策略、測(cè)試范圍、測(cè)試方法、測(cè)試安排、測(cè)試風(fēng)險(xiǎn)、測(cè)試治理

18． 缺陷的分類為：需求文檔的缺陷、軟件配置引起的缺陷、分析、設(shè)計(jì)的缺陷、靜態(tài)文檔的缺陷、軟件開發(fā)引起的缺陷、短視將來的缺陷 19． 測(cè)試用例工作主要是如何添加測(cè)試用例、如何編寫測(cè)試用例、將測(cè)試用例和需求關(guān)聯(lián)

20． 自動(dòng)化測(cè)試工具有：ratinal Robot、winrunner、quicktest 21． 軟件性能測(cè)試工具有： loadRunner、Ratinaol Visual Qantify、PureLoad 22． BUG的種類有：需求階段的BUG、分析設(shè)計(jì)階段的BUG、實(shí)現(xiàn)階段的BUG、配置階段的BUG、靜態(tài)文檔的BUG。23． 測(cè)試項(xiàng)目主要包括以下幾個(gè)階段：計(jì)劃階段、初始階段、執(zhí)行階段、總結(jié)評(píng)估階段、設(shè)計(jì)階段。

1． 缺陷報(bào)告

是描述軟件缺陷現(xiàn)象和重現(xiàn)步驟地集合。軟件缺陷報(bào)告Software Bug Report（SBR）或軟件問題報(bào)告Software Problem Report（SPR）

2． 回歸測(cè)試

是指重新執(zhí)行已經(jīng)做過的測(cè)試的某個(gè)子集，以保證修改變化沒有帶來非預(yù)期的副作用。

3． 動(dòng)態(tài)測(cè)試 通過運(yùn)行軟件來檢驗(yàn)軟件的動(dòng)態(tài)行為和運(yùn)行結(jié)果的正確性。動(dòng)態(tài)測(cè)試的兩個(gè)基本要素： 被測(cè)試程序、測(cè)試數(shù)據(jù)（測(cè)試用例）

4． 白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試和邏輯驅(qū)動(dòng)測(cè)試，允許測(cè)試人員對(duì)程序內(nèi)部邏輯結(jié)構(gòu)及有關(guān)信息來設(shè)計(jì)和選擇測(cè)試用例，對(duì)程序的邏輯路徑進(jìn)行測(cè)試。白盒測(cè)試是把測(cè)試對(duì)象看作一個(gè)打開的盒子，測(cè)試人員須了解程序的內(nèi)部結(jié)構(gòu)和處理過程，由于白盒測(cè)試是一種結(jié)構(gòu)測(cè)試，所以被測(cè)對(duì)象基本上是源程序，以程序的內(nèi)部邏輯和指定的覆蓋標(biāo)準(zhǔn)確定測(cè)試數(shù)據(jù)。

5． 黑盒測(cè)試又稱為功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試，把系統(tǒng)看成一個(gè)黑盒子，不考慮程序的內(nèi)在邏輯，只根據(jù)需求規(guī)格說明書的要求來檢查程序的功能是否符合它的功能說明。

6． 路徑覆蓋的含義是，選取足夠多的測(cè)試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次(如果程序圖中有環(huán)，則要求每個(gè)環(huán)至少經(jīng)過一次)。

7． 軟件測(cè)試 ：在軟件投入運(yùn)行前，對(duì)軟件需求分析、設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。8． 單元測(cè)試（模塊測(cè)試）：針對(duì)每個(gè)模塊進(jìn)行的測(cè)試，可從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例，多個(gè)模塊可以平行地對(duì)立地測(cè)試。通常在編碼階段進(jìn)行，必要的時(shí)候要制作驅(qū)動(dòng)模塊和樁模塊。9． 集成測(cè)試：在單元測(cè)試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成為系統(tǒng)，應(yīng)提交集成測(cè)試計(jì)劃、集成測(cè)試規(guī)格說明和集成測(cè)試分析報(bào)告。

10． 確認(rèn)測(cè)試：驗(yàn)證軟件的功能和性能及其它特性是否與用戶的要求一致。

11． 系統(tǒng)測(cè)試：將軟件放在整個(gè)計(jì)算機(jī)環(huán)境下，包括軟硬件平臺(tái)、某些支持軟件、數(shù)據(jù)和人員等，在實(shí)際運(yùn)行環(huán)境下進(jìn)行一系列的測(cè)試。

1． 測(cè)試過程中會(huì)產(chǎn)生哪些基本文檔？

（1）測(cè)試計(jì)劃（通常包括單元測(cè)試和集成測(cè)試）：確定測(cè)試范圍、方法和需要的資源

（2）測(cè)試過程：詳細(xì)描述和每個(gè)測(cè)試方案有關(guān)的測(cè)試步驟和數(shù)據(jù)（包括測(cè)試數(shù)據(jù)及預(yù)期的結(jié)果）；

（3）測(cè)試結(jié)果：把每次測(cè)試運(yùn)行的結(jié)果歸入文檔，如果運(yùn)行出錯(cuò)，則應(yīng)產(chǎn)生 問題報(bào)告，并且必須通過調(diào)試解決所發(fā)現(xiàn)的問題。

（4）

2.大型軟件系統(tǒng)的測(cè)試過程基本上由幾個(gè)步驟組成? 1）.模塊測(cè)試

在設(shè)計(jì)得好的軟件系統(tǒng)中，每個(gè)模塊完成一個(gè)清晰定義的子功能，而且這個(gè)子功能和同級(jí)其他模塊的功能之間沒有相互依賴關(guān)系。因此，有可能把每個(gè)模塊作為一個(gè)單獨(dú)的實(shí)體來測(cè)試，而且通常比較容易設(shè)計(jì)檢驗(yàn)?zāi)K正確性的測(cè)試方案。模塊測(cè)試的目的是保證每個(gè)模塊作為一個(gè)單元能正確運(yùn)行，所以模塊測(cè)試通常又稱為單元測(cè)試。在這個(gè)測(cè)試步驟中所發(fā)現(xiàn)的往往是編碼和詳細(xì)設(shè)計(jì)的錯(cuò)誤。2）.子系統(tǒng)測(cè)試

子系統(tǒng)測(cè)試是把經(jīng)過單元測(cè)試的模塊放在一起形成一個(gè)子系統(tǒng)來測(cè)試。模塊相互間的協(xié)調(diào)和通信是這個(gè)測(cè)試過程中的主要問題，因此，這個(gè)步驟著重測(cè)試模塊的接口。3）.系統(tǒng)測(cè)試

系統(tǒng)測(cè)試是把經(jīng)過測(cè)試的子系統(tǒng)裝配成一個(gè)完整的系統(tǒng)來測(cè)試。在這個(gè)過程中不僅應(yīng)該發(fā)現(xiàn)設(shè)計(jì)和編碼的錯(cuò)誤，還應(yīng)該驗(yàn)證系統(tǒng)確實(shí)能提供需求說明書中指定的功能，而且系統(tǒng)的動(dòng)態(tài)特性也符合預(yù)定要求。在這個(gè)測(cè)試步驟中發(fā)現(xiàn)的往往是軟件設(shè)計(jì)中的錯(cuò)誤，也可能發(fā)現(xiàn)需求說明中的錯(cuò)誤。不論是子系統(tǒng)測(cè)試還是系統(tǒng)測(cè)試，都兼有檢測(cè)和組裝兩重含義，通常稱為集成測(cè)試。4）.驗(yàn)收測(cè)試

驗(yàn)收測(cè)試把軟件系統(tǒng)作為單一的實(shí)體進(jìn)行測(cè)試，測(cè)試內(nèi)容與系統(tǒng)測(cè)試基本類似，但是它是在用戶積極參與下進(jìn)行的，而且可能主要使用實(shí)際數(shù)據(jù)(系統(tǒng)將來要處理的信息)進(jìn)行測(cè)試。驗(yàn)收測(cè)試的目的是驗(yàn)證系統(tǒng)確實(shí)能夠滿足用戶的需要，在這個(gè)測(cè)試步驟中發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯(cuò)誤。驗(yàn)收測(cè)試也稱為確認(rèn)測(cè)試。5）.平行運(yùn)行

關(guān)系重大的軟件產(chǎn)品在驗(yàn)收之后往往并不立即投入生產(chǎn)性運(yùn)行，而是要再經(jīng)過一段平行運(yùn)行時(shí)間的考驗(yàn)。所謂平行運(yùn)行就是同時(shí)運(yùn)行新開發(fā)出來的系統(tǒng)和將被它取代的舊系統(tǒng)，以便比較新舊兩個(gè)系統(tǒng)的處理結(jié)果。這樣做的具體目的有如下幾點(diǎn)：(1)可以在準(zhǔn)生產(chǎn)環(huán)境中運(yùn)行新系統(tǒng)而又不冒風(fēng)險(xiǎn)；(2)用戶能有一段熟悉新系統(tǒng)的時(shí)間；

(3)可以驗(yàn)證用戶指南和使用手冊(cè)之類的文檔；

(4)能夠以準(zhǔn)生產(chǎn)模式對(duì)新系統(tǒng)進(jìn)行全負(fù)荷測(cè)試，可以用測(cè)試結(jié)果驗(yàn)證性能指標(biāo)。3.一套完整的測(cè)試應(yīng)該由哪些階段組成？分別闡述一下各個(gè)階段。

計(jì)劃階段、設(shè)計(jì)階段、白盒單元、白盒集成、黑盒單元、黑盒集成、系統(tǒng)測(cè)試、回歸測(cè)試、驗(yàn)收測(cè)試一套完整的測(cè)試應(yīng)該由五個(gè)階段組成：

1）測(cè)試計(jì)劃首先，根據(jù)用戶需求報(bào)告中關(guān)于功能要求和性能指標(biāo)的規(guī)格說明書，定義相應(yīng)的測(cè)試需求報(bào)告，即制訂黑盒測(cè)試的最高標(biāo)準(zhǔn)。以后所有的測(cè)試工作都將圍繞著測(cè)試需求來進(jìn)行，符合測(cè)試需求的應(yīng)用程序即是合格的，反之即是不合格的；同時(shí)，還要適當(dāng)選擇測(cè)試內(nèi)容，合理安排測(cè)試人員、測(cè)試時(shí)間及測(cè)試資源等。2）測(cè)試設(shè)計(jì)將測(cè)試計(jì)劃階段制訂的測(cè)試需求分解、細(xì)化為若干個(gè)可執(zhí)行的測(cè)試過程，并為每個(gè)測(cè)試過程選擇適當(dāng)?shù)臏y(cè)試用例（測(cè)試用例選擇的好壞將直接影響測(cè)試結(jié)果的有效性）。

3）測(cè)試開發(fā)建立可重復(fù)使用的自動(dòng)測(cè)試過程。

4）測(cè)試執(zhí)行執(zhí)行測(cè)試開發(fā)階段建立的自動(dòng)測(cè)試過程，并對(duì)所發(fā)現(xiàn)的缺陷進(jìn)行跟蹤管理，測(cè)試執(zhí)行一般由單元測(cè)試、組合測(cè)試、集成測(cè)試、系統(tǒng)聯(lián)調(diào)及回歸測(cè)試等步驟組成，測(cè)試人員應(yīng)本著科學(xué)負(fù)責(zé)的態(tài)度，一步一個(gè)腳印地進(jìn)行測(cè)試。

5）測(cè)試評(píng)估結(jié)合量化的測(cè)試覆蓋域及缺陷跟蹤報(bào)告，對(duì)于應(yīng)用軟件的質(zhì)量和開發(fā)團(tuán)隊(duì)的工作進(jìn)度及工作效率進(jìn)行綜合評(píng)價(jià)。4.軟件測(cè)試的流程

制訂測(cè)試計(jì)劃、設(shè)計(jì)測(cè)試用例、實(shí)施測(cè)試、提交缺陷報(bào)告、編寫測(cè)試總結(jié)。5.測(cè)試計(jì)劃的內(nèi)容都包括什么？其中哪些是最重要的？

1)測(cè)試計(jì)劃的內(nèi)容：測(cè)試目的和測(cè)試項(xiàng)目簡(jiǎn)介、測(cè)試參考文檔和測(cè)試提交文檔、術(shù)語和定義、測(cè)試策略、確定測(cè)試內(nèi)容、資源、測(cè)試進(jìn)度、測(cè)試員的職責(zé)與任務(wù)分配、項(xiàng)目通過或失敗的標(biāo)準(zhǔn)、暫停和重新啟動(dòng)測(cè)試的標(biāo)準(zhǔn)、風(fēng)險(xiǎn)和問題等。2)最重要的：測(cè)試策略、確定測(cè)試內(nèi)容、資源、測(cè)試進(jìn)度、測(cè)試員的職責(zé)與任務(wù)分配、項(xiàng)目通過或失敗的標(biāo)準(zhǔn) 6.測(cè)試計(jì)劃的目的是什么？

測(cè)試計(jì)劃的目的：編寫軟件測(cè)試計(jì)劃的目的是指導(dǎo)測(cè)試組成員進(jìn)行工作和讓測(cè)試組以外的項(xiàng)目成員了解測(cè)試工作的。7.簡(jiǎn)述靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試的區(qū)別？

a)靜態(tài)測(cè)試： 基本特征是在對(duì)軟件進(jìn)行分析、檢查和審閱，不實(shí)際運(yùn)行被測(cè)試的軟件。靜態(tài)測(cè)試約可找出30～70%的邏輯設(shè)計(jì)錯(cuò)誤。對(duì)需求規(guī)格說明書、軟件設(shè)計(jì)說明書、源程序做檢查和審閱。包括：是否符合標(biāo)準(zhǔn)和規(guī)范；通過結(jié)構(gòu)分析、流圖分析、符號(hào)執(zhí)行指出軟件缺陷。b)動(dòng)態(tài)測(cè)試：通過運(yùn)行軟件來檢驗(yàn)軟件的動(dòng)態(tài)行為和運(yùn)行結(jié)果的正確性。動(dòng)態(tài)測(cè)試的兩個(gè)基本要素：被測(cè)試程序和測(cè)試數(shù)據(jù)（測(cè)試用例）。動(dòng)態(tài)測(cè)試方法：(1)選取定義域有效值,或定義域外無效值；(2)對(duì)已選取值決定預(yù)期的結(jié)果；(3)用選取值執(zhí)行程序；(4)執(zhí)行結(jié)果與預(yù)期的結(jié)果相比,不吻和程序有錯(cuò)。8.白盒測(cè)試有哪幾種方法？

語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。9.壓力測(cè)試和性能測(cè)試的區(qū)別？

1)廣義上說壓力測(cè)試是包括在性能測(cè)試之中的，是性能測(cè)試項(xiàng)內(nèi)的一種。

2)性能測(cè)試：顧名思義就是測(cè)試軟件的運(yùn)行性能。驗(yàn)證SRS中的性能需求，是否實(shí)現(xiàn)。

3)壓力測(cè)試：測(cè)試軟件在超負(fù)荷下的工作情況，也是一種軟件的性能。因此是屬于性能測(cè)試范圍的。

10.測(cè)試結(jié)束的標(biāo)準(zhǔn)是什么？

測(cè)試計(jì)劃中所有規(guī)定的測(cè)試內(nèi)容和回歸測(cè)試都已經(jīng)運(yùn)行完成或根據(jù)上級(jí)主管對(duì)測(cè)試結(jié)果的意見，就可以結(jié)束本次測(cè)試。11.黑盒測(cè)試的測(cè)試用例設(shè)計(jì)方法包括哪些？：

a)等價(jià)類劃分：劃分等價(jià)類--確立測(cè)試用例--設(shè)計(jì)用例。b)邊界值分析：通過分析，考慮如何確立邊界情況 c)錯(cuò)誤推測(cè)法：靠經(jīng)驗(yàn)和直覺來推測(cè)程序中可能存在的各種錯(cuò)誤，從而有針對(duì)性地編寫用例。可以列舉出可能的錯(cuò)誤和可能發(fā)生錯(cuò)誤的地方，然后選擇用例。d)因果圖：通過畫因果圖，在圖上標(biāo)明約束和限制，轉(zhuǎn)換成判定表，然后設(shè)計(jì)測(cè)試用例。這適合于檢查程序輸入條件的各種組合情況。

12.缺陷報(bào)告的作用

缺陷報(bào)告是軟件測(cè)試人員的工作成果之一，體現(xiàn)軟件測(cè)試的價(jià)值缺陷報(bào)告可以把軟件存在的缺陷準(zhǔn)確的描述出來，便于開發(fā)人員修正缺陷報(bào)告可以反映項(xiàng)目、產(chǎn)品當(dāng)前的質(zhì)量狀態(tài)，便于項(xiàng)目整體進(jìn)度和質(zhì)量控制。軟件測(cè)試缺陷報(bào)告是軟件測(cè)試的輸出成果之一，可以衡量測(cè)試人員的工作能力。13.等價(jià)分類法的基本思想是什么？

根據(jù)程序的輸入特性，將程序的定義域劃分為有限個(gè)等價(jià)區(qū)段“等價(jià)類”，從等價(jià)類中選擇出的用例具有“代表性”，即測(cè)試某個(gè)等價(jià)類的代表值就等于對(duì)這一類其他值的測(cè)試。如果某個(gè)等價(jià)類的一個(gè)輸入數(shù)據(jù)（代表值）測(cè)試中查出了錯(cuò)誤，說明該類中其他測(cè)試用例也會(huì)有錯(cuò)誤。14.簡(jiǎn)單闡述一下軟件測(cè)試的目標(biāo)

(1)測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程；

(2)好的測(cè)試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試方案；(3)成功的測(cè)試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。15.軟件測(cè)試準(zhǔn)則有哪些？

(1)所有測(cè)試都應(yīng)該能追溯到用戶需求。

(2)應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測(cè)試” 作為軟件開發(fā)者的座右銘。(3)pareto原則：測(cè)試發(fā)現(xiàn)的錯(cuò)誤中的80%很可能是由程序中20%的模塊造成的。

（4）應(yīng)該從“小規(guī)模”測(cè)試開始，并逐步進(jìn)行“大規(guī)模”測(cè)試。

（5）測(cè)試用例應(yīng)由輸入數(shù)據(jù)和預(yù)期的輸出結(jié)果兩部分組成，并兼顧合理的輸入和不合理的輸入數(shù)據(jù)

（6）窮舉測(cè)試是不可能的。

（7）為了達(dá)到最佳的測(cè)試效果，應(yīng)該由獨(dú)立的第三方從事測(cè)試工作。

（8）程序修改后要回歸測(cè)試。

（9）應(yīng)長(zhǎng)期保留測(cè)試用例，直至系統(tǒng)廢棄。16.您認(rèn)為做好測(cè)試用例設(shè)計(jì)工作的關(guān)鍵是什么？

1)白盒測(cè)試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果

2)黑盒測(cè)試用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測(cè)試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題

1． 根據(jù)下面給出的規(guī)格說明，利用等價(jià)類劃分的方法，給出足夠的測(cè)試用例。

“一個(gè)程序讀入三個(gè)整數(shù)。把此三個(gè)數(shù)值看成是一個(gè)三角形的三個(gè)邊。這個(gè)程序要打印出信息，說明這個(gè)三角形是三邊不等的、是等腰的、還是等邊的。”

2． 某報(bào)表處理系統(tǒng)要求用戶輸入處理報(bào)表的日期，日期限制在2003年1月至2008年12月，即系統(tǒng)只能對(duì)該段期間內(nèi)的報(bào)表進(jìn)行處理，如日期不在此范圍內(nèi)，則顯示輸入錯(cuò)誤信息。系統(tǒng)日期規(guī)定由年、月的6位數(shù)字字符組成，前四位代表年，后兩位代表月。請(qǐng)用等價(jià)類劃分法和邊界值劃分法設(shè)計(jì)測(cè)試用例來測(cè)試程序的日期檢查功能。

3． 設(shè)要對(duì)一個(gè)自動(dòng)飲料售貨機(jī)軟件進(jìn)行黑盒測(cè)試。該軟件的規(guī)格說明如下：

“有一個(gè)處理單價(jià)為1元5角錢的盒裝飲料的自動(dòng)售貨機(jī)軟件。若投入1元5角硬幣，按下“可樂”、“雪碧”或“紅茶”按鈕，相應(yīng)的飲料就送出來。若投入的是2元硬幣，在送出飲料的同時(shí)退還5角硬幣。”

利用等價(jià)類劃分的方法，設(shè)計(jì)測(cè)試該軟件的全部測(cè)試用例。

第四篇：軟件測(cè)試小結(jié)

第二階段學(xué)習(xí)小結(jié)

1.白盒測(cè)試需要了解其內(nèi)部結(jié)構(gòu)和運(yùn)行機(jī)制。白盒測(cè)試，也稱之為結(jié)構(gòu)測(cè)試和邏輯驅(qū)動(dòng)測(cè)試。黑盒測(cè)試不需了解程序內(nèi)部結(jié)構(gòu)和內(nèi)部特征。主要著眼于程序外部的用戶界面，關(guān)注軟件的輸入和輸出，關(guān)注用戶的需求，從用戶的角度來驗(yàn)證軟件的功能。黑盒測(cè)試也稱之為功能測(cè)試和數(shù)據(jù)驅(qū)動(dòng)測(cè)試。

2.黑盒測(cè)試技術(shù)主要有：等價(jià)類劃分法、邊界值分析法、判定表方法、因果圖法、錯(cuò)誤推測(cè)法。

3.白盒測(cè)試主要技術(shù)有：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋、路徑覆蓋。

4.測(cè)試用例的定義：測(cè)試用例就是一個(gè)文檔，描述輸入、動(dòng)作、或者時(shí)間和一個(gè)期望的結(jié)果，其目的是確定應(yīng)用程序的某個(gè)特性是否正常的工作。

軟件測(cè)試的基本格式：軟件測(cè)試用例的基本要素包括測(cè)試用例編號(hào)、測(cè)試標(biāo)題、重要級(jí)別、測(cè)試輸入、操作步驟、預(yù)期結(jié)果。{系統(tǒng)測(cè)試用例的編號(hào)這樣定義規(guī)則： PROJECT1-ST-001，命名規(guī)則是項(xiàng)目名稱+測(cè)試階段類型（系統(tǒng)測(cè)試階段）+編號(hào)。定義測(cè)試用例的優(yōu)先級(jí)別，可以籠統(tǒng)的分為 “ 高 ” 和 “ 低 ” 兩個(gè)級(jí)別。測(cè)試用例設(shè)計(jì)方法：（1）逐級(jí)細(xì)分法（2）輸入域測(cè)試法（3）輸出域分析法（4）正交試驗(yàn)設(shè)計(jì)法（5）業(yè)務(wù)流程分析法（6）狀態(tài)遷移法（7）因果圖法（8）判定表法（9）錯(cuò)誤猜測(cè)法(10)等價(jià)類劃分法（11）邊界值分析法}。

5.Bug的描述：

① 和 bug 產(chǎn)生對(duì)應(yīng)的軟件版本。

② 開發(fā)的接口人員。

③ bug 的優(yōu)先級(jí)。

④ bug 的嚴(yán)重程度。

⑤ bug 可能屬于的模塊，如果不能確認(rèn)，可以用開發(fā)人員來判斷。

⑥ bug 標(biāo)題，需要清晰的描述現(xiàn)象。

⑦ bug 描述，需要盡量給出重新 bug 的步驟。

⑧ bug 附件中能給出相關(guān)的日志和截圖。

6.軟件測(cè)試環(huán)境的主要要素：配置測(cè)試環(huán)境是測(cè)試實(shí)施的一個(gè)重要階段，測(cè)試環(huán)境適合與否會(huì)嚴(yán)重影響測(cè)試結(jié)果的重要性和真實(shí)性。一般來說，配置測(cè)試環(huán)境要滿足五個(gè)基本元素：硬件、軟件、網(wǎng)絡(luò)環(huán)境、數(shù)據(jù)準(zhǔn)備、測(cè)試工具。

7.測(cè)試環(huán)境的搭建:單機(jī)版測(cè)試環(huán)境搭建，b/s架構(gòu)測(cè)試環(huán)境的搭建，c/s架構(gòu)測(cè)試環(huán)境的搭建。

8.測(cè)試環(huán)境的管理：設(shè)置專門的測(cè)試環(huán)境管理員角色、明確測(cè)試環(huán)境管理所需的各種文檔、測(cè)試環(huán)境訪問權(quán)限的管理、測(cè)試環(huán)境的變更管理、測(cè)試環(huán)境的備份和恢復(fù)。

9.自動(dòng)化測(cè)試工具介紹：性能測(cè)試—Loadrunner、Robot、Silk performer，功能測(cè)試—QTP、Winrunner、Robot、Silk test，其他測(cè)試—Xenu、AiRoboForm。

第五篇：軟件測(cè)試簡(jiǎn)答題

一、軟件測(cè)試有哪些基本原則？答：1，所有的測(cè)試都應(yīng)追溯到用戶需求。2，應(yīng)當(dāng)把

盡早和不斷的測(cè)試作為座右銘。3，測(cè)試工作應(yīng)該由獨(dú)立的專業(yè)的軟件測(cè)試機(jī)構(gòu)來完成。4，Pareto原則。5，設(shè)計(jì)用例時(shí)，應(yīng)該考慮各種情況。6，對(duì)測(cè)試出的錯(cuò)誤結(jié)果一定要有一個(gè)確認(rèn)的過程。7，制定嚴(yán)格的測(cè)試計(jì)劃。8，完全測(cè)試是不可能的，測(cè)試需要終止。9，注意回歸測(cè)試的關(guān)聯(lián)性。10，妥善保存一切測(cè)試過程文檔。

二、軟件測(cè)試人員需要哪些基本素質(zhì)？答：1，具有良好的計(jì)算機(jī)編程基礎(chǔ)。2，具有

創(chuàng)新精神和超前意識(shí)。3，不懈努力，追求完美。4，具有很強(qiáng)的溝通和交流能力。5，具有整體觀念，對(duì)細(xì)節(jié)敏感。6，團(tuán)隊(duì)合作精神。

三、什么的黑盒測(cè)試？什么是白盒測(cè)試？答：黑盒測(cè)試：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格和

用戶手冊(cè)，可以進(jìn)行測(cè)試驗(yàn)證每個(gè)功能是否實(shí)現(xiàn)每個(gè)實(shí)現(xiàn)了的功能是否符合要求，以及產(chǎn)品的性能是否滿足用戶的需求。白盒測(cè)試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測(cè)試驗(yàn)證每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否已經(jīng)過檢查。

四、黑盒測(cè)試包括功能 非功能測(cè)試部分，說明幾種測(cè)試方法。答：黑盒測(cè)試一般可分

為功能測(cè)試和非功能測(cè)試兩大類：功能測(cè)試主要包括等價(jià)類劃分、邊值分析、因果圖法、錯(cuò)誤推測(cè)、功能圖法等，主要用于軟件確認(rèn)測(cè)試；非功能測(cè)試主要包括使用性能測(cè)試、性能測(cè)試、強(qiáng)度測(cè)試、兼容性測(cè)試、配置測(cè)試、安全測(cè)試等。

五、簡(jiǎn)述集成測(cè)試的實(shí)施方案有哪些？答：集成測(cè)試的實(shí)施方案有很多種，如非增量

式集成測(cè)試和增量式集成測(cè)試，三明治集成測(cè)試，核心集成測(cè)試，分層集成測(cè)試，基于使用的集成測(cè)試等；常用的是前兩種。

六、簡(jiǎn)述增量式集成測(cè)試中的自頂山下和自底向上的兩種測(cè)試方法？答：自頂向下增

量式集成測(cè)試表示逐步集成和逐步測(cè)試是按結(jié)構(gòu)圖自上向下進(jìn)行的，即模塊集成的順序是首先集成主控模塊，然后按照軟件控制層結(jié)構(gòu)向下進(jìn)行集成。自底向上增量是集成測(cè)試是從最底層的模塊開始，按結(jié)構(gòu)圖自下向上逐步進(jìn)行測(cè)試工作。

七、什么是軟件缺陷？軟件缺陷的類型？答：軟件缺陷是1軟件未達(dá)到軟件規(guī)格說明

書中規(guī)定的功能；2軟件超出軟件規(guī)格說明書中指出的范圍；3軟件未達(dá)到軟件規(guī)格說明書中指出的應(yīng)達(dá)到的目標(biāo)；4軟件運(yùn)行出現(xiàn)錯(cuò)誤；5軟件測(cè)試人員認(rèn)為軟件難于理解，不易使用，運(yùn)行速度慢，或者最終用戶認(rèn)為軟件使用效果不好。類型：1功能缺陷；2用戶見面缺陷；3文檔缺陷；4軟件配置缺陷；5性能缺陷；6系統(tǒng)模塊接口缺陷。

八、可采取哪些方法來分離和再現(xiàn)軟件缺陷？答：1，確保所有的步驟都被記錄；2，注意時(shí)間和運(yùn)行條件上的因素；3，注意軟件的邊界條件、內(nèi)容容量和數(shù)據(jù)溢出的問題；4,注意事件發(fā)生次序?qū)е碌能浖毕荩?，考慮資源依賴性和內(nèi)存、網(wǎng)絡(luò)、硬件共享的相互作用；6，不要忽視硬件。

九、什么是測(cè)試用例？測(cè)試用例的分類？答：測(cè)試用例是測(cè)試執(zhí)行的最小實(shí)體，是為

特定的目的而設(shè)計(jì)的一組測(cè)試輸入、執(zhí)行條件和預(yù)期的結(jié)果。分類：1白盒測(cè)試用例；2軟件各項(xiàng)功能的測(cè)試用例；3用戶界面測(cè)試用例；4軟件的各項(xiàng)非功能測(cè)試用例；5對(duì)軟件缺陷修正所確認(rèn)的測(cè)試用例。

十、測(cè)試用例設(shè)計(jì)的基本原則是什么？答：1用成熟測(cè)試用例設(shè)計(jì)方法來指導(dǎo)設(shè)計(jì)；2

測(cè)試用例的正確性；3測(cè)試用例的代表性；4測(cè)試結(jié)果的可判定性；5測(cè)試結(jié)果的可再現(xiàn)性；6足夠詳細(xì)、準(zhǔn)確和清晰的步驟。