選擇題1、系統測試使用(C）技術,重要測試被測應用的高級互操作性需求,而無需考慮被測試應用的內部結構。

Ａ、單元測試

B、集成測試

Ｃ、黑盒測試

D、白盒測試

2、單元測試重要的測試技術不涉及（B

）。

A、白盒測試

B、功能測試?Ｃ、靜態測試

D、以上都不是

３、（A

)的目的是對最終軟件系統進行全面的測試,保證最終軟件系統滿足產品需求并且遵循系統設計。?Ａ、系統測試

B、集成測試

C、單元測試

D、功能測試

４、假如一個產品中次嚴重的缺陷基本完畢修正并通過復測，這個階段的成品是（

A

)。

A、Alpｈa版

B、Ｂeta版?C、正版

D、以上都不是

５、自底向上法需要寫（Ａ

)。?Ａ、驅動程序

B、樁程序

C、驅動程序和樁程序

D、.以上都不是6、測試ATM取款功能，已知取款數只能輸入正整數，每次取款數規定是100的倍數且不能大于５０0，下面哪個是對的的無效等價類（C)

Ａ、(0，100)、（１00,200)、（200,300)、(300，400）、(40０,5００)、（５00,+∞);?Ｂ、（50０,+∞）?Ｃ、（5０0,+∞）、任意大于0小于５00的非100倍數的整數;

Ｄ、(－∞，100）、(100，2０0）、（２0０,300)、(３00，4０0）、（400，50０）、（50０,+∞）；?7、因果圖／鑒定表工程方法在以下那種情況下不合用（Ｃ）?Ａ、輸入輸出明確,或輸入輸出因果關系明確的情況下

B、被分析的特性或功能點復雜，輸入項目很多的情況下

C、系統輸入之間互相約束多，需要做大范圍的組合測試情況下

Ｄ、系統輸入之間基本沒有互相聯系?8、以下說法不對的的是(D）?Ａ、測試原始需要明確了產品將要實現了什么

Ｂ、產品測試規格明確了測試設計內容?C、測試用例明確了測試實現內容

D、以上說法均不對的?9、可測試性中,有關系統可觀測性的理解,下面說法那個是錯誤的(

B)?Ａ、系統所有的輸出結果可觀測,錯誤輸出易于辨認；

B、系統運營狀態和內部解決的過程信息可觀測;

Ｃ、系統內部變量名及其取值可觀測；

D、系統內部重要對象的狀態和屬性可觀測;

E、系統內部重要的操作的解決時間可觀測；

F、系統內部重要的資源的占用情況及單個資源的創建、保持、釋放過程可觀測?１0、測試腳本的編寫規范強調:(ABCＤ）

Ａ、可讀行

B、可重用性

C、可維護性

D、可移植性11、當繼承某個特性是，通常會從哪些角度對該特性進行測試分析？（AＣ

）?A、失效影響度

B、成熟度

C、繼承方式

D、用戶原始需求?１２、從下列關于軟件測試的敘述中，選出對的的敘述（ＣD)

Ａ、用黑盒法測試時，測試用例是根據程序內部邏輯設計的

B、測試的目的是驗證該軟件已對的的實現了用戶的規定?Ｃ、發現錯誤多的程序塊，殘留在模塊中的錯誤也多

D、測試設計時，應充足考慮異常的輸入情況?１３、軟件驗收測試的合格通過準則是:（ＡＢCD)

A．軟件需求分析說明書中定義的所有功能已所有實現,性能指標所有達成規定。?Ｂ.所有測試項沒有殘余一級、二級和三級錯誤。

C．立項審批表、需求分析文檔、設計文檔和編碼實現一致。?D．驗收測試工件齊全。?13、軟件測試計劃評審會需要哪些人員參與？（AＢCD)

A.項目經理

B.SQＡ負責人

Ｃ．配置負責人?D.測試組

14．測試設計員的職責有：(BC)?A．制定測試計劃?B．設計測試用例

C.設計測試過程、腳本?D．評估測試活動?1５．軟件實行活動的進入準則是：（AＢC)

A．需求工件已經被基線化?B．具體設計工件已經被基線化?Ｃ．構架工件已經被基線化

D．項目階段成果已經被基線化16.軟件驗收測試的合格通過準則是:(ＡＢCD)Ａ.軟件需求分析說明書中定義的所有功能已所有實現,性能指標所有達成規定。B.所有測試項沒有殘余一級、二級和三級錯誤。C．立項審批表、需求分析文檔、設計文檔和編碼實現一致。D．驗收測試工件齊全。

17．軟件測試計劃評審會需要哪些人員參與？（ABCＤ)

Ａ.項目經理B.ＳQＡ負責人Ｃ.配置負責人D.測試組?1８.下列關于ａｌpha測試的描述中對的的是：（ＡD)?A.ａlpha測試需要用戶代表參與?B.ａlpha測試不需要用戶代表參與

C．alｐhａ測試是系統測試的一種?D.aｌphａ測試是驗收測試的一種

19.測試設計員的職責有：（BC）?Ａ．制定測試計劃B．設計測試用例C．設計測試過程、腳本Ｄ．評估測試活動

20.軟件實行活動的進入準則是：(ABC)?A．需求工件已經被基線化Ｂ．具體設計工件已經被基線化Ｃ.構架工件已經被基線化Ｄ．項目階段成果已經被基線化判斷題1．軟件測試的目的是盡也許多的找出軟件的缺陷。(Y)?2．負載測試是驗證要檢查的系統的能力最高能達成什么限度。(N)

3.測試人員要堅持原則,缺陷未修復完堅決不予通過。(N)?4.自動化測試能比手工測試發現更多的缺陷(N）?５.錯誤猜測法基于這樣一種假設，以前犯過的錯誤,以后同樣會犯，我犯過的錯誤別人同樣會犯,前人犯過的錯誤,后人同樣會犯（N)

６.軟件測試中的二八原則暗示著測試發現的錯誤中的８０%很也許起源于程序模塊的2０%（Y)

7.某WEＢ系統設計中,用戶點擊“退出”按鈕從系統中退出,界面回到初始登陸界面。此時不關閉窗口，使用瀏覽器的回退功能，可以回到之前的用戶界面，繼續進行用戶操作。這種合適的人性化設計,恩那個避免用戶誤點擊退出按鈕后重新登錄的繁瑣操作；這種說法是否對的（Ｎ)

8.在擬定性能測試指標值時,參考的國際標準、國標、運營商規范中對此規定并不同樣,可以視情況選擇有助于我們的指標值,但必須要比競爭對手高,這樣才有助于市場競爭力（N）?９.測試執行時，應當對每一個測試結果做全面的檢查，涉及日記,這種說法是否對的(N)

１0.在測試執行時，我們重要是基于用戶的使用場景來考慮功能實現的對的性,關鍵機要數據在數據庫內是否加密存儲或日記輸出中是否采用加密、掩碼解決不是我們測試關注的范圍,畢竟那產品的內部實現,用戶看不到的，自然也是不關心的。這種說法是否對的。（)

11．軟件測試的目的是盡也許多的找出軟件的缺陷。(Y）12．Beta測試是驗收測試的一種。(Ｙ）

1３．驗收測試是由最終用戶來實行的。（Ｎ）

14．項目立項前測試人員不需要提交任何工件。（Ｙ)

1５．單元測試能發現約80%的軟件缺陷。（Ｙ）?16．代碼評審是檢查源代碼是否達成模塊設計的規定。(N)

１7．自底向上集成需要測試員編寫驅動程序。(Y)

18.負載測試是驗證要檢查的系統的能力最高能達成什么限度。（N）

１9.測試人員要堅持原則,缺陷未修復完堅決不予通過。(N）

20．代碼評審員一般由測試員擔任。（Ｎ）?21.我們可以人為的使得軟件不存在配置問題。(Ｎ)

2２.集成測試計劃在需求分析階段末提交。(Ｎ)簡答一、區別階段評審的與同行評審

同行評審目的:發現小規模工作產品的錯誤,只要是找錯誤；

階段評審目的:評審模塊階段作品的對的性可行性及完整性?同行評審人數:３－７人人員必須通過同行評審會議的培訓，由SＱＡ指導

階段評審人數:5人左右評審人必須是專家具有系統評審資格

同行評審內容:內容小一般文檔＜40頁,代碼<５００行二、為什么要在一個團隊中開展軟件測試工作？由于沒有通過測試的軟件很難在發布之前知道該軟件的質量,就好比ISＯ質量認證一樣,測試同樣也需要質量的保證,這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題,及時讓開發人員得知并修改問題,在即將發布時,從測試報告中得出軟件的質量情況。三、您在以往的測試工作中都曾經具體從事過哪些工作?其中最擅長哪部分工作？我曾經做過web測試后臺測試客戶端軟件，其中涉及功能測試，性能測試,用戶體驗測試。最擅長的是功能測試四、您所熟悉的軟件測試類型都有哪些？請試著分別比較這些不同。測試類型有：功能測試,性能測試,界面測試。功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。運用黑盒測試法進行動態測試時，需要測試軟件產品的功能,不需測試軟件產品的內部結構和解決過程。采用黑盒技術設計測試用例的方法有:等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試,兩者可以結合進行。通過負載測試，擬定在各種工作負載下系統的性能,目的是測試當負載逐漸增長時，系統各項性能指標的變化情況。壓力測試是通過擬定一個系統的瓶頸或者不能接受的性能點,來獲得系統能提供的最大服務級別的測試。界面測試，界面是軟件與用戶交互的最直接的層,界面的好壞決定用戶對軟件的第一印象。并且設計良好的界面可以引導用戶自己完畢相應的操作,起到向導的作用。同時界面如同人的面孔，具有吸引用戶的直接優勢。設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺,相反由于界面設計的失敗,讓用戶有挫敗感，再實用強大的功能都也許在用戶的畏懼與放棄中付諸東流。區別在于,功能測試關注產品的所有功能上,要考慮到每個細節功能,每個也許存在的功能問題。性能測試重要關注于產品整體的多用戶并發下的穩定性和健壯性。界面測試更關注于用戶體驗上，用戶使用該產品的時候是否易用,是否易懂，是否規范(快捷鍵之類的)，是否美觀(能否吸引用戶的注意力）,是否安全（盡量在前臺避免用戶無意輸入無效的數據，當然考慮到體驗性，不能太粗魯的彈出警告)?做某個性能測試的時候，一方面它也許是個功能點，一方面要保證它的功能是沒問題的,然后再考慮該功能點的性能測試。五、請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯系。黑盒測試:已知產品的功能設計規格,可以進行測試證明每個實現了的功能是否符合規定。白盒測試:已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格規定,所有內部成分是否以通過檢查。軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子,測試人員完全不考慮程序內部的邏輯結構和內部特性,只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試重要是為了發現以下幾類錯誤:1、是否有不對的或漏掉的功能？２、在接口上，輸入是否能對的的接受?能否輸出對的的結果？３、是否有數據結構錯誤或外部信息（例如數據文獻）訪問錯誤?4、性能上是否可以滿足規定?5、是否有初始化或終止性錯誤？軟件的白盒測試是對軟件的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子,它允許測試人員運用程序內部的邏輯結構及有關信息，設計或選擇測試用例,對程序所有邏輯途徑進行測試。通過在不同點檢查程序狀態，擬定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試重要是想對程序模塊進行如下檢查：１、對程序模塊的所有獨立的執行途徑至少測試一遍。２、對所有的邏輯鑒定，取“真”與取“假”的兩種情況都能至少測一遍。3、在循環的邊界和運營的界線內執行循環體。4、測試內部數據結構的有效性，等等。單元測試（模塊測試)是開發者編寫的一小段代碼，用于檢查被測代碼的一個很小的、很明確的功能是否對的。通常而言,一個單元測試是用于判斷某個特定條件(或者場景)下某個特定函數的行為。單元測試是由程序員自己來完畢，最終受益的也是程序員自己。可以這么說,程序員有責任編寫功能代碼,同時也就有責任為自己的代碼編寫單元測試。執行單元測試,就是為了證明這段代碼的行為和我們盼望的一致。集成測試(也叫組裝測試，聯合測試)是單元測試的邏輯擴展。它的最簡樸的形式是:兩個已經測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講,組件是指多個單元的集成聚合。在現實方案中,許多單元組合成組件,而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。系統測試是將通過測試的子系統裝配成一個完整系統來測試。它是檢查系統是否的確能提供系統方案說明書中指定功能的有效方法。(常見的聯調測試)系統測試的目的是對最終軟件系統進行全面的測試,保證最終軟件系統滿足產品需求并且遵循系統設計。驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是保證軟件準備就緒,并且可以讓最終用戶將其用于執行軟件的既定功能和任務。驗收測試是向未來的用戶表白系統可以像預定規定那樣工作。經集成測試后，已經按照設計把所有的模塊組裝成一個完整的軟件系統,接口錯誤也已經基本排除了，接著就應當進一步驗證軟件的有效性，這就是驗收測試的任務,即軟件的功能和性能如同用戶所合理期待的那樣。六、測試計劃工作的目的是什么？測試計劃工作的內容都涉及什么?其中哪些是最重要的？軟件測試計劃是指導測試過程的大綱性文獻,包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成員,特別是測試管理人員,可以明確測試任務和測試方法，保持測試實行過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。測試計劃和測試具體規格、測試用例之間是戰略和戰術的關系，測試計劃重要從宏觀上規劃測試活動的范圍、方法和資源配置,而測試具體規格、測試用例是完畢測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最佳是能先評審）七、您認為做好測試計劃工作的關鍵是什么？a.明確測試的目的,增強測試計劃的實用性編寫軟件測試計劃得重要目的就是使測試過程可以發現更多的軟件缺陷,因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求,測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結果直觀、準確。b．堅持“5W”規則,明確內容與過程“5W”規則指的是“What(做什么）”、“Ｗｈy（為什么做）”、“When(何時做）”、“Whｅｒｅ（在哪里)”、“Hｏw(如何做)”。運用“5W”規則創建軟件測試計劃，可以幫助測試團隊理解測試的目的(Ｗhy）,明確測試的范圍和內容（Ｗhat）,擬定測試的開始和結束日期（When)，指出測試的方法和工具（How)，給出測試文檔和軟件的存放位置(Ｗhｅre)。c.采用評審和更新機制，保證測試計劃滿足實際需求測試計劃寫作完畢后,假如沒有通過評審,直接發送給測試團隊，測試計劃內容的也許不準確或漏掉測試內容，或者軟件需求變更引起測試范圍的增減,而測試計劃的內容沒有及時更新，誤導測試執行人員。d.分別創建測試計劃與測試具體規格、測試用例應把具體的測試技術指標包含到獨立創建的測試具體規格文檔，把用于指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試具體規格、測試用例之間是戰略和戰術的關系，測試計劃重要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試具體規格、測試用例是完畢測試任務的具體戰術。八、您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。a．等價類劃分劃分等價類：等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對于揭露程序中的錯誤都是等效的．并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把所有輸入數據合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.b.邊界值分析法邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.使用邊界值分析方法設計測試用例，一方面應擬定邊界情況.通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況.應當選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.ｃ.錯誤推測法基于經驗和直覺推測程序中所有也許存在的各種錯誤,從而有針對性的設計測試用例的方法.錯誤推測方法的基本思想：列舉出程序中所有也許有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例．例如,在單元測試時曾列出的許多在模塊中常見的錯誤．以前產品測試中曾經發現的錯誤等,這些就是經驗的總結.尚有，輸入數據和輸出數據為0的情況.輸入表格為空格或輸入表格只有一行．這些都是容易發生錯誤的情況.可選擇這些情況下的例子作為測試用例．d．因果圖方法前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系,互相組合等.考慮輸入條件之間的互相組合,也許會產生一些新的情況.但要檢查輸入條件的組合不是一件容易的事情,即使把所有輸入條件劃提成等價類，他們之間的合情況也相稱多.因此必須考慮采用一種適合于描述對于多種條件的組合，相應產生多個動作的形式來考慮設計測試用例.這就需要運用因果圖(邏輯模型)。因果圖方法最終生成的就是鑒定表．它適合于檢查程序輸入條件的各種組合情況.九、軟件測試的目的?測試的目的是想以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷,通過修正種錯誤和缺陷提高軟件質量，回避軟件發布后由于潛在的軟件缺陷和錯誤導致的隱患帶來的商業風險。十、什么是軟件測試?使用人工或自動手段來運營或測定某個系統的過程,其目的在于檢查它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。軟件測試就是在軟件投入運營前,對軟件需求分析、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵環節。軟件測試是為了發現錯誤而執行程序的過程。十一、基于WEＢ信息管理系統測試時應考慮的因素有哪些?1、功能測試鏈接測試表單測試Ｃookies測試設計語言測試數據庫測試2、性能測試連接速度測試負載測試壓力測試3、可用性測試導航測試圖形測試內容測試整體界面測試4、客戶端兼容性測試平臺測試瀏覽器測試5、安全性測試十二、軟件本地化測試比功能測試都有哪些方面需要注意?軟件本地化測試的目的：軟件本地化測試的測試策略:1．本地化軟件要在各種本地化操作系統上安裝并測試。２．源語言軟件安裝在另一臺相同源語言操作系統上,作為對比測試。3.重點測試因本地化引起的軟件的功能和軟件界面的錯誤。4.測試本地化軟件的翻譯質量。5.手工測試和自動測試相結合。十三、軟件測試項目從什么時候開始？為什么?軟件測試應當在需求分析階段就介入,由于測試的對象不僅僅是程序編碼,應當對軟件開發過程中產生的所有產品都測試，并且軟件缺陷存在放大趨勢．缺陷發現的越晚，修復它所花費的成本就越大.十四、需求測試注意事項有哪些?一個良好的需求應當具有一下特點：完整性：每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。對的性：每一項需求都必須準確地陳述其要開發的功能。一致性:一致性是指與其它軟件需求或高層(系統,業務）需求不相矛盾。可行性：每一項需求都必須是在已知系統和環境的權能和限制范圍內可以實行的。無二義性:對所有需求說明的讀者都只能有一個明確統一的解釋,由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。健壯性：需求的說明中是否對也許出現的異常進行了分析,并且對這些異常進行了容錯解決。必要性：“必要性”可以理解為每項需求都是用來授權你編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入,如ＵｓeＣaｓe或別的來源。可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測試。可修改性：每項需求只應在SRS中出現一次。這樣更改時易于保持一致性。此外，使用目錄表、索引和互相參照列表方法將使軟件需求規格說明書更容易修改。可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈,這種可跟蹤性規定每項需求以一種結構化的，粒度好(fｉne-graｉned)的方式編寫并單獨標明,而不是大段大段的敘述。十五、簡述一下缺陷的生命周期軟件缺陷的生命周期指的是一個軟件缺陷被發現、報告到這個缺陷被修復、驗證直至最后關閉的完整過程。簡樸的軟件缺陷生命周期：１、發現——打開：測試人員找到軟件缺陷并將軟件缺陷提交給開發人員;2、打開——修復：開發人員再現、修復缺陷，然后提交測試人員去驗證;3、修復——關閉：測試人員驗證修復過的軟件,關閉已不存在的缺陷。但是這是一種抱負的狀態,在實際的工作中是很難有這樣的順利的，需要考慮的各種情況都還是非常多的。復雜的軟件缺陷生命周期：1、新建一個軟件缺陷，這個軟件缺陷是（open）狀態，進行ｂｕｇ審查,不是代碼問題,就是設計需要修改；2、新建一個軟件缺陷，這個軟件缺陷是(opｅｎ）狀態,進行bｕg審查，以后修改的，就可以延期；3、新建一個軟件缺陷，這個軟件缺陷是(opeｎ)狀態,進行bug審查，實際沒有這個bug，可以將其關閉;4、新建一個軟件缺陷，這個軟件缺陷是（open)狀態,看是否清楚可重現，假如不能重現，就是缺少信息，需要返回到（ｏpen）狀態；假如可以重現,就進行修正,修正后關閉,進行回歸測試。十六、為什么要寫用例：我們編寫測試用例，有如下的好處：便于團隊交流:假如說一個測試團隊有10個成員,大家測試的時候都各自為政,沒有統一的標準，測試的效率無疑會大打折扣;假如大家都遵循統一的用例規范去寫，就會解決這一問題。便于反復測試：大家知道,軟件在實際開發過程中是會有不同版本的,比如會從1.０升級到10.０,那么假如不寫測試用例的話,在測試10．0版本的時候,你能完全記得1.0版本時你做過哪些測試嗎?測試用例就像一個備忘錄同樣,便于反復測試。便于跟蹤記錄:這一點是針對測試經理或是項目經理來說的,項目負責人通過看測試用例的執行情況,就能了解到項目目前的概況，比如已經執行了哪些測試，尚有哪些測試沒有執行,測試沒有通過的地方重要集中在哪些模塊等。便于用戶自測：特別是項目軟件,有的時候用戶希望自己測試一下軟件產品,但是用戶大都是非專業人士，他需要根據你寫好的用例來更好的檢查產品的質量。說了這么多編寫測試用例的優點，那它有沒有缺陷呢?有一個明顯的缺陷就是需要花費大量的時間,通常編寫測試用例的時間比實際執行測試的時間還要長,這一點大家會在實際工作中有深刻的體會十七、

測試的種類很多,大約有1、代碼、函數級測試2、模塊、組件級測試3、系統測試,請說出這些測試最佳由那些人員完畢，測試的依據是什么，并說明理由。代碼、函數級測試一般由白盒測試人員完畢,他們需要測試的是對代碼的測試?模塊、組件級測試重要有灰盒或者黑盒人員測試，需要對所測試的程序內部結構與原理有較強的了解,屬于各模塊間的銜接與關系，可以測試出模塊之間變動而導致對其他模塊的影響?系統測試在于模塊測試與單元測試的基礎上進行測試。了解系統功能與性能，根據測試用例進行全面的測試。?十八、設計測試用例和測試數據時應當考慮哪些方面，即不同的測試用例和數據各自針對那些方面進行測試。?設計測試用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測試、性能測試、壓力測試、邊界值測試、穩定性測試、安全性測試等多方面。?設計測試用例在除了常用數據外，還需要考慮極限值、邊界值、反復值、0值及負值，即不同的測試用例需要不同類型的數據值來進行測試。測試用例的設計一、某程序規定:"輸入三個整數ａ、b、ｃ分別作為三邊的邊長構成三角形。通過程序鑒定所構成的三角形的類型，當此三角形為一般三角形、等腰三角形及等邊三角形時，分別作計算…＂。用等價類劃分方法為該程序進行測試用例設計。(三角形問題的復雜之處在于輸入與輸出之間的關系比較復雜。）

分析題目中給出和隱含的對輸入條件的規定：

(１)整數

(２)三個數

(3)非零數

(4)正數

（5)兩邊之和大于第三邊

(6)等腰

(7)等邊?

假如ａ、b、c滿足條件(1）~(４）,則輸出下列四種情況之一:

1)假如不滿足條件(５），則程序輸出為"非三角形"。?

２)假如三條邊相等即滿足條件（７）,則程序輸出為"等邊三角形"。?

3)假如只有兩條邊相等、即滿足條件（６),則程序輸出為"等腰三角形"。

4)假如三條邊都不相等,則程序輸出為"一般三角形＂。

列出等價類表并編號覆蓋有效等價類的測試用例:

a

ｂ

ｃ

覆蓋等價類號碼

3

４

5

（1）--(7)

４

4

5

（1)--(７)，（8)?

４

5

5

(１）-－（7）,(9)

?

5

4

5

（1）--(7)，(１0)

4

4

4

（1）－-（7）,（11）?

覆蓋無效等價類的測試用例:

二、假如測試程序向打印機輸送打印內容,應當選用那些破壞性測試用例。

答：用此程序打印大量的文獻?長時間不斷止的使用此軟件進行打印操作?長時間不斷止的打印大數量及大文獻的操作;?在打印過程中斷電、重啟等破壞性操作

三、下圖是ｗindoｗs保存對話框，假如為文獻名建立測試用例，等價類應當如何劃分??1

長文獻名?２

短文獻名

3

特殊字符/‘。‘;、＝－等?4

中文／英文等

四、假設由一個文本框規定輸入10各字符的郵政編碼,對于該文本框應當如何劃分等價類？?1特殊字符是否可以輸入

2英文字母是否可以輸入

３漢字是否`｀｀``````｀｀｀`｀｀`?4是否可以不輸入字符就可以擬定

5輸入超過1０個字符

6字符可以混合中英數字

五、給你一臺冰箱，你將如何測試它?

一方面分析冰箱的重要功能：制冷和保鮮。

一方面通上電，檢查冰箱是否能啟動。這是最基本的，假如這一步都不滿足，后面的也就無法進行了。然后找一小碗水放進去,一段時間后觀測它是否可以變成冰塊。這個過程中還可以檢查一下冰箱運營的時候聲音是否太大,是否漏水,冰箱里面是否有異味等。

然后再找一盤蔬菜（熟的和生的)或水果，觀測可以保持幾天的新鮮。此時需要設定盼望值,參考一些數據和資料,事先要知道該種菜和水果在常溫下保鮮是多少天,有必要時還可以和其它品牌的冰箱做比較。最后也許還要附加的功能，比如里面的燈是否會亮，溫度是否可調等。六、水杯的測試一種:

測試項目：杯子?需求測試：查看杯子使用說明書

界面測試：查看杯子外觀

功能度:用水杯裝水看漏不漏;水能不能被喝到

安全性:杯子有沒有毒或細菌

可*性：杯子從不同高度落下的損壞限度?可移植性：杯子再不同的地方、溫度等環境下是否都可以正常使用

兼容性:杯子是否可以容納果汁、白水、酒精、汽油等

易用性：杯子是否燙手、是否有防滑措施、是否方便飲用?用戶文檔:使用手冊是否對杯子的用法、限制、使用條件等有具體描述?疲勞測試：將杯子盛上水（案例一）放２４小時檢查泄漏時間和情況;盛上汽油（案例二)放2４小時檢查泄漏時間和情況等?壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透?跌落測試：杯子加包裝（有填充物）,在多高的情況摔下不破損

震動測試:杯子加包裝（有填充物),六面震動,檢查產品是否能應對惡劣的鐵路\公路＼航空運送?測試數據：測試數據具體編寫此處略（最討厭寫測試數據了）。其中應用到:場景法、等價類劃分法、因果圖法、錯誤推測法、邊界值法等方法

盼望輸出:

該盼望輸出需查閱國標、行標以及使用用戶的需求?另一種:?總體來說從以下幾個方面去考慮

功能性、性能性、易用性、可操作性、穩定性方面進行測試

功能性方