軟件測試筆試必備

1、.選擇題1、 系統(tǒng)測試使用（C）技術, 主要測試被測應用的高級互操作性需求, 而無需考慮被測試應用的內(nèi)部結(jié)構(gòu)。A、 單元測試      B、 集成測試       C、 黑盒測試       D、白盒測試2、單元測試主要的測試技術不包括（B  ）。A、 白盒測試                    B、 功能測試C、

2、 靜態(tài)測試                    D、 以上都不是3、（A  ）的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設計。A、 系統(tǒng)測試               B、 集成測試C、 單元測試            

3、   D、 功能測試4、如果一個產(chǎn)品中次嚴重的缺陷基本完成修正并通過復測，這個階段的成品是（ A ）。A、 Alpha版              B、Beta版C、正版                 D、以上都不是5、自底向上法需要寫（A  ）。A、 驅(qū)動程序      B、 樁程序 

4、     C、驅(qū)動程序和樁程序  D、 .以上都不是6、測試ATM取款功能，已知取款數(shù)只能輸入正整數(shù)，每次取款數(shù)要求是100的倍數(shù)且不能大于500，下面哪個是正確的無效等價類（C）A、（0，100）、（100，200）、（200，300）、（300，400）、（400，500）、（500，+）;B、（500，+）C、（500，+）、任意大于0小于500的非100倍數(shù)的整數(shù)；D、（-，100）、（100，200）、（200，300）、（300，400）、（400，500）、（500，+）;7、因果圖/判定表工程方法在以下那種情況下不適用（C）A、

5、輸入輸出明確，或輸入輸出因果關系明確的情況下B、被分析的特性或功能點復雜，輸入項目很多的情況下C、系統(tǒng)輸入之間相互約束多，需要做大范圍的組合測試情況下D、系統(tǒng)輸入之間基本沒有相互聯(lián)系8、以下說法不正確的是（D）A、測試原始需要明確了產(chǎn)品將要實現(xiàn)了什么B、產(chǎn)品測試規(guī)格明確了測試設計內(nèi)容C、測試用例明確了測試實現(xiàn)內(nèi)容D、以上說法均不正確9、可測試性中，有關系統(tǒng)可觀察性的理解，下面說法那個是錯誤的（ B）A、系統(tǒng)所有的輸出結(jié)果可觀察，錯誤輸出易于識別；B、系統(tǒng)運行狀態(tài)和內(nèi)部處理的過程信息可觀察；C、系統(tǒng)內(nèi)部變量名及其取值可觀察；D、系統(tǒng)內(nèi)部重要對象的狀態(tài)和屬性可觀察；E、系統(tǒng)內(nèi)部重要的操作

6、的處理時間可觀察；F、系統(tǒng)內(nèi)部重要的資源的占用情況及單個資源的創(chuàng)建、保持、釋放過程可觀察10、測試腳本的編寫規(guī)范強調(diào)：（ABCD ）A、可讀行     B、可重用性      C、可維護性      D、可移植性11、當繼承某個特性是，通常會從哪些角度對該特性進行測試分析？（AC  ）A、失效影響度  B、成熟度       C、繼承方式       D、用戶原始需求

7、12、從下列關于軟件測試的敘述中，選出正確的敘述（CD）A、用黑盒法測試時，測試用例是根據(jù)程序內(nèi)部邏輯設計的B、測試的目的是驗證該軟件已正確的實現(xiàn)了用戶的要求C、發(fā)現(xiàn)錯誤多的程序塊，殘留在模塊中的錯誤也多D、測試設計時，應充分考慮異常的輸入情況13、軟件驗收測試的合格通過準則是：（ABCD）A 軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標全部達到要求。B 所有測試項沒有殘余一級、二級和三級錯誤。C 立項審批表、需求分析文檔、設計文檔和編碼實現(xiàn)一致。D 驗收測試工件齊全。13、軟件測試計劃評審會需要哪些人員參加？（ABCD）A項目經(jīng)理BSQA 負責人C配置負責人D測試組14測試設計員的

8、職責有：（BC ）A制定測試計劃B設計測試用例C設計測試過程、腳本D評估測試活動15軟件實施活動的進入準則是：（ABC）A需求工件已經(jīng)被基線化B詳細設計工件已經(jīng)被基線化C構(gòu)架工件已經(jīng)被基線化D項目階段成果已經(jīng)被基線化16軟件驗收測試的合格通過準則是：（ABCD）A 軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標全部達到要求。B 所有測試項沒有殘余一級、二級和三級錯誤。C 立項審批表、需求分析文檔、設計文檔和編碼實現(xiàn)一致。D 驗收測試工件齊全。17軟件測試計劃評審會需要哪些人員參加？（ABCD）A項目經(jīng)理 BSQA 負責人 C配置負責人 D測試組18下列關于alpha 測試的描述中正確的

9、是：（AD）Aalpha 測試需要用戶代表參加Balpha 測試不需要用戶代表參加Calpha 測試是系統(tǒng)測試的一種Dalpha 測試是驗收測試的一種19測試設計員的職責有：（BC）A制定測試計劃 B設計測試用例C設計測試過程、腳本 D評估測試活動20軟件實施活動的進入準則是：（ABC）A需求工件已經(jīng)被基線化B詳細設計工件已經(jīng)被基線化C構(gòu)架工件已經(jīng)被基線化D項目階段成果已經(jīng)被基線化判斷題1.軟件測試的目的是盡可能多的找出軟件的缺陷。（ Y）2.負載測試是驗證要檢驗的系統(tǒng)的能力最高能達到什么程度。（N ）3.測試人員要堅持原則，缺陷未修復完堅決不予通過。（N）4.自動化測試能比手工測試發(fā)現(xiàn)更多的

10、缺陷（N）5.錯誤猜測法基于這樣一種假設，以前犯過的錯誤，以后同樣會犯，我犯過的錯誤別人同樣會犯，前人犯過的錯誤，后人同樣會犯（N）6.軟件測試中的二八原則暗示著測試發(fā)現(xiàn)的錯誤中的80%很可能起源于程序模塊的20%（Y）7.某WEB系統(tǒng)設計中，用戶點擊“退出”按鈕從系統(tǒng)中退出，界面回到初始登陸界面。此時不關閉窗口，使用瀏覽器的回退功能，可以回到之前的用戶界面，繼續(xù)進行用戶操作。這種合適的人性化設計，恩那個避免用戶誤點擊退出按鈕后重新登錄的繁瑣操作；這種說法是否正確（N）8.在確定性能測試指標值時，參考的國際標準、國標、運營商規(guī)范中對此要求并不一樣，可以視情況選擇有利于我們的指標值，但必須要比競

11、爭對手高，這樣才有利于市場競爭力（N）9.測試執(zhí)行時，應該對每一個測試結(jié)果做全面的檢查，包括日志，這種說法是否正確（ N）10.在測試執(zhí)行時，我們主要是基于用戶的使用場景來考慮功能實現(xiàn)的正確性，關鍵機要數(shù)據(jù)在數(shù)據(jù)庫內(nèi)是否加密存儲或日志輸出中是否采用加密、掩碼處理不是我們測試關注的范圍，畢竟那產(chǎn)品的內(nèi)部實現(xiàn)，用戶看不到的，自然也是不關心的。這種說法是否正確。（ ）11軟件測試的目的是盡可能多的找出軟件的缺陷。（Y）12Beta 測試是驗收測試的一種。（Y）13驗收測試是由最終用戶來實施的。（N）14項目立項前測試人員不需要提交任何工件。（Y）15單元測試能發(fā)現(xiàn)約80%的軟件缺陷。（Y）16代碼評

12、審是檢查源代碼是否達到模塊設計的要求。（N）17自底向上集成需要測試員編寫驅(qū)動程序。（Y）18負載測試是驗證要檢驗的系統(tǒng)的能力最高能達到什么程度。（N）19測試人員要堅持原則，缺陷未修復完堅決不予通過。（N）20代碼評審員一般由測試員擔任。（N）21我們可以人為的使得軟件不存在配置問題。（N）22集成測試計劃在需求分析階段末提交。（N）簡答一、區(qū)別階段評審的與同行評審同行評審目的:發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤,只要是找錯誤;階段評審目的:評審模塊 階段作品的正確性 可行性 及完整性同行評審人數(shù):3-7人 人員必須經(jīng)過同行評審會議的培訓,由SQA指導階段評審人數(shù):5人左右 評審人必須是專家 具有系統(tǒng)

13、評審資格同行評審內(nèi)容:內(nèi)容小 一般文檔 < 40頁, 代碼 < 500行二、為什么要在一個團隊中開展軟件測試工作？ 因為沒有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量，就好比 ISO 質(zhì)量認證一 樣，測試同樣也需要質(zhì)量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質(zhì)量情況。 三、您在以往的測試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？ 我曾經(jīng)做過web 測試后臺測試客戶端軟件，其中包括功能測試，性能測試，用戶體驗測試。最擅長的是功能測試 四、您所熟悉的軟件測試類型都

14、有哪些？請試著分別比較這些不同。 測試類型有：功能測試，性能測試，界面測試。 功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒測試法進行動態(tài)測試時，需要測試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。采用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯 誤推測、因果圖和綜合策略。 性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進行。通過負載測試，確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指標的變化情況。壓力測

15、試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務級別的測試。 界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設計良好的界面能夠引導用戶自己完成相應的操作，起到向?qū)У淖饔谩Ｍ瑫r界面如同人的面孔，具有吸引用戶的直接優(yōu)勢。設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。 區(qū)別在于，功能測試關注產(chǎn)品的所有功能上，要考慮到每個細節(jié)功能，每個可能存在的功能問題。性能測試主要關注于產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測試更關注于用戶體驗上，

16、用戶使用該產(chǎn)品的時候是否易用，是否易懂，是否規(guī)范（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（盡量在前臺避免用戶無意輸入無效的數(shù)據(jù)，當然考慮到體驗性，不能太粗魯?shù)膹棾鼍妫孔瞿硞€性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然后再考慮該功能點的性能測試。 五、請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗收測試的區(qū)別與聯(lián)系。 黑盒測試：已知產(chǎn)品的功能設計規(guī)格，可以進行測試證明每個實現(xiàn)了的功能是否符合要求。 白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設計規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。 軟件的黑盒測試意

17、味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。黑盒 測試主要是為了發(fā)現(xiàn)以下幾類錯誤： 1、是否有不正確或遺漏的功能？ 2、在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？ 3、是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？ 4、性能上是否能夠滿足要求？ 5、是否有初始化或終止性錯誤？ 軟件的白盒測試是對軟件的過程性細節(jié)做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關

18、信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態(tài)，確定實際狀態(tài)是否與預期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試主要是想對程序模塊進行 如下檢查： 1、對程序模塊的所有獨立的執(zhí)行路徑至少測試一遍。 2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。 3、在循環(huán)的邊界和運行的界限內(nèi)執(zhí)行循環(huán)體。 4、測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。 單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下 某個特定函數(shù)的行為。 單元測試是由程序員自

19、己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。 集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴展。它的最簡單的形式是： 兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程 序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起 測試。最后，將構(gòu)成進程的所有模塊一起測試。 系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢

20、驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試） 系統(tǒng)測試的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設計。驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務。 驗收測試是向未來的用戶表明系統(tǒng)能夠像預定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。 六、測試計劃工作的目的是什么？測試計劃工作的內(nèi)容都包括什

21、么？其中哪些是最重要的？ 軟件測試計劃是指導測試過程的綱領性文件，包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風險分析等內(nèi)容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。 測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術的關系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務的具體戰(zhàn)術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審） 七、您認為做好測試計劃工作的關鍵是什么？ a.

22、明確測試的目標，增強測試計劃的實用性 編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結(jié)果直觀、準確。 b堅持“5W”規(guī)則，明確內(nèi)容與過程 “5W”規(guī)則指的是“What （做什么）”、“Why （為什么做）”、“When （何時做）”、“Where （在哪里）”、“How （如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團隊理 解測試的目的（Why ），明確測試的范圍和內(nèi)

23、容（What ），確定測試的開始和結(jié)束日期（When ）， 指出測試的方法和工具（How ），給出測試文檔和軟件的存放位置（Where ）。 c采用評審和更新機制，保證測試計劃滿足實際需求 測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團隊，測試計劃內(nèi)容的可能不準確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內(nèi)容沒有及時更新，誤導測試執(zhí)行人員。 d. 分別創(chuàng)建測試計劃與測試詳細規(guī)格、測試用例 應把詳細的測試技術指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔，把用于指導測試小組執(zhí) 行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細規(guī)格、測試用

24、例之間是戰(zhàn)略和戰(zhàn)術的關系，測試計劃主要從宏觀上規(guī)劃測試活動的 范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務的具體戰(zhàn)術。 八、您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。 a等價類劃分 劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試. 因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價類,在每一個等價類中取一個數(shù)據(jù)作為測試的 輸入條件,就可以用少量代表性的測試數(shù)據(jù).取得較好的測試結(jié)果.等價類劃分可有兩種不同的情況:有效等價

25、類和無效等價類. b邊界值分析法 邊界值分析方法是對等價類劃分方法的補充。測試工作經(jīng)驗告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤. 使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界, 就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù). c錯誤推測法 基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法. 錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易

26、發(fā)生錯誤的特殊情況,根據(jù)他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等, 這些就是經(jīng)驗的總結(jié). 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為 0 的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯誤的情況. 可選擇這些情況下的例子作為測試用例. d因果圖方法 前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條 件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的 合情況也相當多. 因此必須考慮采

27、用一種適合于描述對于多種條件的組合,相應產(chǎn)生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）。因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況. 九、軟件測試的目的？ 測試的目的是想以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷，通過修正種錯誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造成的隱患帶來的商 業(yè)風險。 十、什么是軟件測試？ 使用人工或自動手段來運行或測定某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預期結(jié)果與實際結(jié)果之間的差別。 軟件測試就是在軟件投入運行前，對軟件需求分析、設計規(guī)格說明和編碼的最終復審，

28、是軟件質(zhì)量保證的關鍵步驟。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 十一、基于WEB 信息管理系統(tǒng)測試時應考慮的因素有哪些？ 1、功能測試 a) 鏈接測試 b) 表單測試 c) Cookies 測試d) 設計語言測試e) 數(shù)據(jù)庫測試 2、性能測試 a) 連接速度測試 b) 負載測試 c) 壓力測試3、可用性測試 a) 導航測試 b) 圖形測試c) 內(nèi)容測試d) 整體界面測試4、客戶端兼容性測試 a) 平臺測試 b) 瀏覽器測試 5、安全性測試 十二、軟件本地化測試比功能測試都有哪些方面需要注意？ 軟件本地化測試的目的： 軟件本地化測試的測試策略：1.本地化軟件要在各種本地化操作系統(tǒng)上安裝并測試

29、。2.源語言軟件安裝在另一臺相同源語言操作系統(tǒng)上，作為對比測試。3.重點測試因本地化引起的軟 件的功能和軟件界面的錯誤。4.測試本地化軟件的翻譯質(zhì)量。5.手工測試和自動測試相結(jié)合。 十三、軟件測試項目從什么時候開始？為什么？ 軟件測試應該在需求分析階段就介入,因為測試的對象不僅僅是程序編碼,應該對軟件開發(fā)過程中產(chǎn)生的所有產(chǎn)品都測試,并且軟件缺陷存在放大趨勢.缺陷發(fā)現(xiàn)的越晚,修復它所花費的成本就越大. 十四、需求測試注意事項有哪些？ 一個良好的需求應當具有一下特點： 完整性：每一項需求都必須將所要實現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設計和實現(xiàn)這些功能所需的所有必要信息。 正確性：每一項需求都必須

30、準確地陳述其要開發(fā)的功能。 一致性：一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務）需求不相矛盾。 可行性：每一項需求都必須是在已知系統(tǒng)和環(huán)境的權能和限制范圍內(nèi)可以實施的。 無二義性：對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。 健壯性：需求的說明中是否對可能出現(xiàn)的異常進行了分析，并且對這些異常進行了容錯處理。 必要性：“必要性”可以理解為每項需求都是用來授權你編寫文檔的“根源”。要使每項需求 都能回溯至某項客戶的輸入，如Use Case 或別的來源。 可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測

31、試。 可修改性：每項需求只應在 S R S中出現(xiàn)一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明書更容易修改。 可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結(jié)構(gòu)化的，粒度好（f i n e - g r a i n e d ）的方式編寫并單獨標明，而不是大段大段的敘述。 十五、簡述一下缺陷的生命周期 軟件缺陷的生命周期指的是一個軟件缺陷被發(fā)現(xiàn)、報告到這個缺陷被修復、驗證直至最后關閉的完整過程。 簡單的軟件缺陷生命周期： 1、發(fā)現(xiàn)打開：測試人員找到軟件缺陷并將軟件缺陷提交給開發(fā)人員；

32、2、打開修復：開發(fā)人員再現(xiàn)、修復缺陷，然后提交測試人員去驗證； 3、修復關閉：測試人員驗證修復過的軟件，關閉已不存在的缺陷。 但是這是一種理想的狀態(tài)，在實際的工作中是很難有這樣的順利的，需要考慮的各種情況都還是非常多的。 復雜的軟件缺陷生命周期： 1、新建一個軟件缺陷，這個軟件缺陷是（open）狀態(tài)，進行bug 審查，不是代碼問題，就是設計需要修改； 2、新建一個軟件缺陷，這個軟件缺陷是（open）狀態(tài)，進行bug 審查，以后修改的，就可以延期； 3、新建一個軟件缺陷，這個軟件缺陷是（open）狀態(tài)，進行bug 審查，實際沒有這個bug，可以將其關閉； 4、新建一個軟件缺陷，這個軟件缺陷是（o

33、pen）狀態(tài)，看是否清楚可重現(xiàn)，如果不能重現(xiàn)，就是缺少信息，需要返回到（open）狀態(tài)；如果能夠重現(xiàn)，就進行修正，修正后關閉，進行回歸測試。 十六、為什么要寫用例： 我們編寫測試用例，有如下的好處： 便于團隊交流：假如說一個測試團隊有 10 個成員，大家測試的時候都各自為政，沒有統(tǒng)一的標準，測試的效率無疑會大打折扣；如果大家都遵循統(tǒng)一的用例規(guī)范去寫，就會解決這一 問題。 便于重復測試 ：大家知道，軟件在實際開發(fā)過程中是會有不同版本的，比如會從 1.0 升級到 10.0，那么如果不寫測試用例的話，在測試 10.0 版本的時候，你能完全記得 1.0 版本時你做過哪些測試嗎？測試用例就像一個備忘錄一

34、樣，便于重復測試。 便于跟蹤統(tǒng)計：這一點是針對測試經(jīng)理或是項目經(jīng)理來說的，項目負責人通過看測試用例的執(zhí)行情況，就能了解到項目目前的概況，比如已經(jīng)執(zhí)行了哪些測試，還有哪些測試沒有執(zhí)行，測試沒有通過的地方主要集中在哪些模塊等。 便于用戶自測：尤其是項目軟件，有的時候用戶希望自己測試一下軟件產(chǎn)品，但是用戶大都 是非專業(yè)人士，他需要根據(jù)你寫好的用例來更好的檢驗產(chǎn)品的質(zhì)量。 說了這么多編寫測試用例的優(yōu)點，那它有沒有缺點呢？有一個明顯的缺點就是需要花費大量 的時間，通常編寫測試用例的時間比實際執(zhí)行測試的時間還要長，這一點大家會在實際工作中有深刻的體會 十七、 測試的種類很多，大概有1、代碼、函數(shù)

35、級測試2、模塊、組件級測試3、系統(tǒng)測試，請說出這些測試最好由那些人員完成，測試的依據(jù)是什么，并說明理由。代碼、函數(shù)級測試一般由白盒測試人員完成，他們需要測試的是對代碼的測試模塊、組件級測試主要有灰盒或者黑盒人員測試，需要對所測試的程序內(nèi)部結(jié)構(gòu)與原理有較強的了解，屬于各模塊間的銜接與關系，能夠測試出模塊之間變動而造成對其他模塊的影響系統(tǒng)測試在于模塊測試與單元測試的基礎上進行測試。了解系統(tǒng)功能與性能，根據(jù)測試用例進行全面的測試。十八、設計測試用例和測試數(shù)據(jù)時應該考慮哪些方面，即不同的測試用例和數(shù)據(jù)各自針對那些方面進行測試。 設計測試用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測試、

36、性能測試、壓力測試、邊界值測試、穩(wěn)定性測試、安全性測試等多方面。設計測試用例在除了常用數(shù)據(jù)外，還需要考慮極限值、邊界值、重復值、0值及負值，即不同的測試用例需要不同類型的數(shù)據(jù)值來進行測試。測試用例的設計一、某程序規(guī)定："輸入三個整數(shù) a 、 b 、 c 分別作為三邊的邊長構(gòu)成三角形。通過程序判定所構(gòu)成的三角形的類型，當此三角形為一般三角形、等腰三角形及等邊三角形時，分別作計算 "。用等價類劃分方法為該程序進行測試用例設計。（三角形問題的復雜之處在于輸入與輸出之間的關系比較復雜。）  分析題目中給出和隱含的對輸入條件的要求：   （1）整數(shù) &#

37、160;  （2）三個數(shù)    （3）非零數(shù)   （4）正數(shù)     （5）兩邊之和大于第三邊     （6）等腰     （7）等邊    如果 a 、 b 、 c 滿足條件（ 1 ） （ 4 ），則輸出下列四種情況之一：   1)如果不滿足條件（5），則程序輸出為 " 非三角形 " 。   2)如果三條邊相等即滿足條件（7），則程序輸出為 &q

38、uot; 等邊三角形 " 。   3)如果只有兩條邊相等、即滿足條件（6），則程序輸出為 " 等腰三角形 " 。   4)如果三條邊都不相等，則程序輸出為 " 一般三角形 " 。    列出等價類表并編號覆蓋有效等價類的測試用例：    a      b      c       

39、0;      覆蓋等價類號碼    3      4      5             （1）-（7）    4      4      5  

40、           （1）-（7），（8）    4      5      5             （1）-（7），（9）        5   

41、60;  4      5             （1）-（7），（10）    4      4      4             （1）-（7），（11）

42、60;  覆蓋無效等價類的測試用例：二、如果測試程序向打印機輸送打印內(nèi)容，應該選用那些破壞性測試用例。答：用此程序打印大量的文件長時間不停止的使用此軟件進行打印操作長時間不停止的打印大數(shù)量及大文件的操作；在打印過程中斷電、重啟等破壞性操作三、下圖是windows保存對話框，如果為文件名建立測試用例，等價類應該怎樣劃分？1 長文件名2 短文件名3 特殊字符 /。；、=-等4 中文/英文等四、假設由一個文本框要求輸入10各字符的郵政編碼，對于該文本框應該怎樣劃分等價類？1 特殊字符是否可以輸入2 英文字母是否可以輸入3 漢字是否4 是否可以不輸入字

43、符就可以確定5 輸入超過10個字符6 字符可以混合中英數(shù)字五、給你一臺冰箱，你將如何測試它？ 首先分析冰箱的主要功能：制冷和保鮮。 首先通上電，檢查冰箱是否能啟動。這是最基本的，如果這一步都不滿足，后面的也就無法進行了。然后找一小碗水放進去，一段時間后觀察它是否可以變成冰塊。這個過程中還可以檢查一下冰箱運行的時候聲音是否太大，是否漏水，冰箱里面是否有異味等。然后再找一盤蔬菜（熟的和生的）或水果，觀察可以保持幾天的新鮮。此時需要設定期望值，參考一些數(shù)據(jù)和資料，事先要知道該種菜和水果在常溫下保鮮是多少天，有必要時還可以和其它品牌的冰箱做比較。最后可能還要附加的功能，比如里面的燈是否會亮，溫度是否可

44、調(diào)等。六、水杯的測試一種：測試項目：杯子需求測試:查看杯子使用說明書界面測試:查看杯子外觀功能度：用水杯裝水看漏不漏；水能不能被喝到安全性：杯子有沒有毒或細菌可*性：杯子從不同高度落下的損壞程度可移植性：杯子再不同的地方、溫度等環(huán)境下是否都可以正常使用兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等易用性：杯子是否燙手、是否有防滑措施、是否方便飲用用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透跌落測試: 杯子加包裝(有填充物),在多高的情況摔下不破損震動測試: 杯子加包裝(有填充物