軟件測試筆試必備參考模板

1、選擇題1、 系統(tǒng)測試使用（C）技術(shù), 主要測試被測應(yīng)用的高級互操作性需求, 而無需考慮被測試應(yīng)用的內(nèi)部結(jié)構(gòu)。A、 單元測試 B、 集成測試 C、 黑盒測試 D、白盒測試2、單元測試主要的測試技術(shù)不包括（B）。A、 白盒測試 B、 功能測試C、 靜態(tài)測試 D、 以上都不是3、（A）的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)。A、 系統(tǒng)測試 B、 集成測試C、 單元測試 D、 功能測試4、如果一個產(chǎn)品中次嚴(yán)重的缺陷基本完成修正并通過復(fù)測，這個階段的成品是（A）。A、 Alpha版 B、Beta版C、正版 D、以上都不是5、自底向上法需要寫（A）。A、 驅(qū)動程

2、序 B、 樁程序 C、驅(qū)動程序和樁程序D、 .以上都不是6、測試ATM取款功能，已知取款數(shù)只能輸入正整數(shù)，每次取款數(shù)要求是100的倍數(shù)且不能大于500，下面哪個是正確的無效等價(jià)類（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、輸入輸出明確，或輸入輸出因果關(guān)系明確的情況下B

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

4、源的創(chuàng)建、保持、釋放過程可觀察10、測試腳本的編寫規(guī)范強(qiáng)調(diào)：（ABCD ）A、可讀行 B、可重用性 C、可維護(hù)性 D、可移植性11、當(dāng)繼承某個特性是，通常會從哪些角度對該特性進(jìn)行測試分析？（AC ）A、失效影響度B、成熟度 C、繼承方式 D、用戶原始需求12、從下列關(guān)于軟件測試的敘述中，選出正確的敘述（2 / 17CD）A、用黑盒法測試時(shí)，測試用例是根據(jù)程序內(nèi)部邏輯設(shè)計(jì)的B、測試的目的是驗(yàn)證該軟件已正確的實(shí)現(xiàn)了用戶的要求C、發(fā)現(xiàn)錯誤多的程序塊，殘留在模塊中的錯誤也多D、測試設(shè)計(jì)時(shí)，應(yīng)充分考慮異常的輸入情況13、軟件驗(yàn)收測試的合格通過準(zhǔn)則是：（ABCD）A 軟件需求分析說明書中定義的所有功能已全

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

6、B 所有測試項(xiàng)沒有殘余一級、二級和三級錯誤。C 立項(xiàng)審批表、需求分析文檔、設(shè)計(jì)文檔和編碼實(shí)現(xiàn)一致。D 驗(yàn)收測試工件齊全。17軟件測試計(jì)劃評審會需要哪些人員參加？（ABCD）A項(xiàng)目經(jīng)理 BSQA 負(fù)責(zé)人 C配置負(fù)責(zé)人 D測試組18下列關(guān)于alpha 測試的描述中正確的是：（AD）Aalpha 測試需要用戶代表參加Balpha 測試不需要用戶代表參加Calpha 測試是系統(tǒng)測試的一種Dalpha 測試是驗(yàn)收測試的一種19測試設(shè)計(jì)員的職責(zé)有：（BC）A制定測試計(jì)劃 B設(shè)計(jì)測試用例C設(shè)計(jì)測試過程、腳本 D評估測試活動20軟件實(shí)施活動的進(jìn)入準(zhǔn)則是：（ABC）A需求工件已經(jīng)被基線化B詳細(xì)設(shè)計(jì)工件已經(jīng)被基線

7、化C構(gòu)架工件已經(jīng)被基線化D項(xiàng)目階段成果已經(jīng)被基線化判斷題1.軟件測試的目的是盡可能多的找出軟件的缺陷。（ Y）2.負(fù)載測試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。（N ）3.測試人員要堅(jiān)持原則，缺陷未修復(fù)完堅(jiān)決不予通過。（N）4.自動化測試能比手工測試發(fā)現(xiàn)更多的缺陷（N）5.錯誤猜測法基于這樣一種假設(shè)，以前犯過的錯誤，以后同樣會犯，我犯過的錯誤別人同樣會犯，前人犯過的錯誤，后人同樣會犯（N）6.軟件測試中的二八原則暗示著測試發(fā)現(xiàn)的錯誤中的80%很可能起源于程序模塊的20%（Y）7.某WEB系統(tǒng)設(shè)計(jì)中，用戶點(diǎn)擊“退出”按鈕從系統(tǒng)中退出，界面回到初始登陸界面。此時(shí)不關(guān)閉窗口，使用瀏覽器的回退功

8、能，可以回到之前的用戶界面，繼續(xù)進(jìn)行用戶操作。這種合適的人性化設(shè)計(jì)，恩那個避免用戶誤點(diǎn)擊退出按鈕后重新登錄的繁瑣操作；這種說法是否正確（N）8.在確定性能測試指標(biāo)值時(shí)，參考的國際標(biāo)準(zhǔn)、國標(biāo)、運(yùn)營商規(guī)范中對此要求并不一樣，可以視情況選擇有利于我們的指標(biāo)值，但必須要比競爭對手高，這樣才有利于市場競爭力（N）9.測試執(zhí)行時(shí)，應(yīng)該對每一個測試結(jié)果做全面的檢查，包括日志，這種說法是否正確（ N）10.在測試執(zhí)行時(shí)，我們主要是基于用戶的使用場景來考慮功能實(shí)現(xiàn)的正確性，關(guān)鍵機(jī)要數(shù)據(jù)在數(shù)據(jù)庫內(nèi)是否加密存儲或日志輸出中是否采用加密、掩碼處理不是我們測試關(guān)注的范圍，畢竟那產(chǎn)品的內(nèi)部實(shí)現(xiàn)，用戶看不到的，自然也是不關(guān)

9、心的。這種說法是否正確。（ ）11軟件測試的目的是盡可能多的找出軟件的缺陷。（Y）12Beta 測試是驗(yàn)收測試的一種。（Y）13驗(yàn)收測試是由最終用戶來實(shí)施的。（N）14項(xiàng)目立項(xiàng)前測試人員不需要提交任何工件。（Y）15單元測試能發(fā)現(xiàn)約80%的軟件缺陷。（Y）16代碼評審是檢查源代碼是否達(dá)到模塊設(shè)計(jì)的要求。（N）17自底向上集成需要測試員編寫驅(qū)動程序。（Y）18負(fù)載測試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。（N）19測試人員要堅(jiān)持原則，缺陷未修復(fù)完堅(jiān)決不予通過。（N）20代碼評審員一般由測試員擔(dān)任。（N）21我們可以人為的使得軟件不存在配置問題。（N）22集成測試計(jì)劃在需求分析階段末提交。（

10、N）簡答一、區(qū)別階段評審的與同行評審?fù)性u審目的:發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤,只要是找錯誤;階段評審目的:評審模塊 階段作品的正確性 可行性 及完整性同行評審人數(shù):3-7人 人員必須經(jīng)過同行評審會議的培訓(xùn),由SQA指導(dǎo)階段評審人數(shù):5人左右 評審人必須是專家 具有系統(tǒng)評審資格同行評審內(nèi)容:內(nèi)容小 一般文檔 40頁, 代碼 500行二、為什么要在一個團(tuán)隊(duì)中開展軟件測試工作？ 因?yàn)闆]有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量，就好比 ISO 質(zhì)量認(rèn)證一 樣，測試同樣也需要質(zhì)量的保證，這個時(shí)候就需要在團(tuán)隊(duì)中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時(shí)讓開發(fā)人員得知并修改問題，在即將發(fā)

11、布時(shí)，從測試報(bào)告中得出軟件的質(zhì)量情況。 三、您在以往的測試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？ 我曾經(jīng)做過web 測試后臺測試客戶端軟件，其中包括功能測試，性能測試，用戶體驗(yàn)測試。最擅長的是功能測試 四、您所熟悉的軟件測試類型都有哪些？請?jiān)囍謩e比較這些不同。 測試類型有：功能測試，性能測試，界面測試。 功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒測試法進(jìn)行動態(tài)測試時(shí)，需要測試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。采用黑盒技術(shù)設(shè)計(jì)測試用例的方法有：等價(jià)類劃分、邊界值分析、錯 誤推測、因果圖和綜合策略。 性能測試是

12、通過自動化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。通過負(fù)載測試，確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。 界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設(shè)計(jì)良好的界面能夠引導(dǎo)用戶自己完成相應(yīng)的操作，起到向?qū)У淖饔?。同時(shí)界面如同人的面孔，具有吸引用戶的直接優(yōu)勢。設(shè)計(jì)合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設(shè)計(jì)的失

13、敗，讓用戶有挫敗感，再實(shí)用強(qiáng)大的功能都可能在用戶的畏懼與放棄中付諸東流。 區(qū)別在于，功能測試關(guān)注產(chǎn)品的所有功能上，要考慮到每個細(xì)節(jié)功能，每個可能存在的功能問題。性能測試主要關(guān)注于產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測試更關(guān)注于用戶體驗(yàn)上，用戶使用該產(chǎn)品的時(shí)候是否易用，是否易懂，是否規(guī)范（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（盡量在前臺避免用戶無意輸入無效的數(shù)據(jù)，當(dāng)然考慮到體驗(yàn)性，不能太粗魯?shù)膹棾鼍妫?？做某個性能測試的時(shí)候，首先它可能是個功能點(diǎn)，首先要保證它的功能是沒問題的，然后再考慮該功能點(diǎn)的性能測試。 五、請?jiān)囍容^一下黑盒測試、白盒測試、單元測試、集成測試、

14、系統(tǒng)測試、驗(yàn)收測試的區(qū)別與聯(lián)系。 黑盒測試：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測試證明每個實(shí)現(xiàn)了的功能是否符合要求。 白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。 軟件的黑盒測試意味著測試要在軟件的接口處進(jìn)行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。黑盒 測試主要是為了發(fā)現(xiàn)以下幾類錯誤： 1、是否有不正確或遺漏的功能？ 2、在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？ 3、是

15、否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？ 4、性能上是否能夠滿足要求？ 5、是否有初始化或終止性錯誤？ 軟件的白盒測試是對軟件的過程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測試用例，對程序所有邏輯路徑進(jìn)行測試。通過在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試主要是想對程序模塊進(jìn)行 如下檢查： 1、對程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一遍。 2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。 3、在循環(huán)的邊界和運(yùn)行的界限內(nèi)執(zhí)行循

16、環(huán)體。 4、測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。 單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下 某個特定函數(shù)的行為。 單元測試是由程序員自己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責(zé)任編寫功能代碼，同時(shí)也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。 集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴(kuò)展。它的最簡單的形式是： 兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚

17、合。在現(xiàn)實(shí)方案中，許多單元組合成組件，而這些組件又聚合成程 序的更大部分。方法是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起 測試。最后，將構(gòu)成進(jìn)程的所有模塊一起測試。 系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試） 系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)。驗(yàn)收測試是部署軟件之前的最后一個測試操作。驗(yàn)收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。 驗(yàn)收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)

18、集成測試后，已經(jīng)按照設(shè)計(jì)把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)該進(jìn)一步驗(yàn)證軟件的有效性，這就是驗(yàn)收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。 六、測試計(jì)劃工作的目的是什么？測試計(jì)劃工作的內(nèi)容都包括什么？其中哪些是最重要的？ 軟件測試計(jì)劃是指導(dǎo)測試過程的綱領(lǐng)性文件，包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風(fēng)險(xiǎn)分析等內(nèi)容。借助軟件測試計(jì)劃，參與測試的項(xiàng)目成員，尤其是測試管理人員，可以明確測試任務(wù)和測試方法，保持測試實(shí)施過程的順暢溝通，跟蹤和控制測試進(jìn)度，應(yīng)對測試過程中的各種變更。 測試計(jì)劃和測試詳細(xì)規(guī)格、

19、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。所以其中最重要的是測試測試策略和測試方法（最好是能先評審） 七、您認(rèn)為做好測試計(jì)劃工作的關(guān)鍵是什么？ a. 明確測試的目標(biāo)，增強(qiáng)測試計(jì)劃的實(shí)用性 編寫軟件測試計(jì)劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計(jì)劃的價(jià)值取決于它對幫助管理測試項(xiàng)目，并且找出軟件潛在的缺陷。因此，軟件測試計(jì)劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實(shí)可行，測試工具并且具有較高的實(shí)用性，便于使用，生成的測試結(jié)果直觀、準(zhǔn)確。 b堅(jiān)持“5W”規(guī)則，明確內(nèi)容與過程

20、“5W”規(guī)則指的是“What （做什么）”、“Why （為什么做）”、“When （何時(shí)做）”、“Where （在哪里）”、“How （如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計(jì)劃，可以幫助測試團(tuán)隊(duì)理 解測試的目的（Why ），明確測試的范圍和內(nèi)容（What ），確定測試的開始和結(jié)束日期（When ）， 指出測試的方法和工具（How ），給出測試文檔和軟件的存放位置（Where ）。 c采用評審和更新機(jī)制，保證測試計(jì)劃滿足實(shí)際需求 測試計(jì)劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團(tuán)隊(duì)，測試計(jì)劃內(nèi)容的可能不準(zhǔn)確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計(jì)劃的內(nèi)容沒有及時(shí)更新，

21、誤導(dǎo)測試執(zhí)行人員。 d. 分別創(chuàng)建測試計(jì)劃與測試詳細(xì)規(guī)格、測試用例 應(yīng)把詳細(xì)的測試技術(shù)指標(biāo)包含到獨(dú)立創(chuàng)建的測試詳細(xì)規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí) 行測試過程的測試用例放到獨(dú)立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計(jì)劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動的 范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。 八、您所熟悉的測試用例設(shè)計(jì)方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計(jì)工作中的應(yīng)用。 a等價(jià)類劃分 劃分等價(jià)類: 等價(jià)類是指某個輸入域的子集合.在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的.

22、并合理地假定:測試某等價(jià)類的代表值就等于對這一類其它值的測試. 因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價(jià)類,在每一個等價(jià)類中取一個數(shù)據(jù)作為測試的 輸入條件,就可以用少量代表性的測試數(shù)據(jù).取得較好的測試結(jié)果.等價(jià)類劃分可有兩種不同的情況:有效等價(jià)類和無效等價(jià)類. b邊界值分析法 邊界值分析方法是對等價(jià)類劃分方法的補(bǔ)充。測試工作經(jīng)驗(yàn)告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設(shè)計(jì)測試用例,可以查出更多的錯誤. 使用邊界值分析方法設(shè)計(jì)測試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價(jià)類的邊界, 就是應(yīng)著重測試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛

23、大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價(jià)類中的典型值或任意值作為測試數(shù)據(jù). c錯誤推測法 基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設(shè)計(jì)測試用例的方法. 錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據(jù)他們選擇測試用例. 例如, 在單元測試時(shí)曾列出的許多在模塊中常見的錯誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等, 這些就是經(jīng)驗(yàn)的總結(jié). 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為 0 的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯誤的情況. 可選擇這些情況下的例子作為測試用例. d因果圖方法 前面介紹的等價(jià)類劃分方法和邊界值分析方

24、法,都是著重考慮輸入條件,但未考慮輸入條 件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價(jià)類,他們之間的 合情況也相當(dāng)多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應(yīng)產(chǎn)生多個動作的形式來考慮設(shè)計(jì)測試用例. 這就需要利用因果圖（邏輯模型）。因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況. 九、軟件測試的目的？ 測試的目的是想以最少的人力、物力和時(shí)間找出軟件中潛在的各種錯誤和缺陷，通過修正種錯誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造

25、成的隱患帶來的商 業(yè)風(fēng)險(xiǎn)。 十、什么是軟件測試？ 使用人工或自動手段來運(yùn)行或測定某個系統(tǒng)的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或是弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。 軟件測試就是在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 十一、基于WEB 信息管理系統(tǒng)測試時(shí)應(yīng)考慮的因素有哪些？ 1、功能測試 a) 鏈接測試 b) 表單測試 c) Cookies 測試d) 設(shè)計(jì)語言測試e) 數(shù)據(jù)庫測試 2、性能測試 a) 連接速度測試 b) 負(fù)載測試 c) 壓力測試3、可用性測試 a) 導(dǎo)航測試 b) 圖形測試c) 內(nèi)容

26、測試d) 整體界面測試4、客戶端兼容性測試 a) 平臺測試 b) 瀏覽器測試 5、安全性測試 十二、軟件本地化測試比功能測試都有哪些方面需要注意？ 軟件本地化測試的目的： 軟件本地化測試的測試策略：1.本地化軟件要在各種本地化操作系統(tǒng)上安裝并測試。2.源語言軟件安裝在另一臺相同源語言操作系統(tǒng)上，作為對比測試。3.重點(diǎn)測試因本地化引起的軟 件的功能和軟件界面的錯誤。4.測試本地化軟件的翻譯質(zhì)量。5.手工測試和自動測試相結(jié)合。 十三、軟件測試項(xiàng)目從什么時(shí)候開始？為什么？ 軟件測試應(yīng)該在需求分析階段就介入,因?yàn)闇y試的對象不僅僅是程序編碼,應(yīng)該對軟件開發(fā)過程中產(chǎn)生的所有產(chǎn)品都測試,并且軟件缺陷存在放大

27、趨勢.缺陷發(fā)現(xiàn)的越晚,修復(fù)它所花費(fèi)的成本就越大. 十四、需求測試注意事項(xiàng)有哪些？ 一個良好的需求應(yīng)當(dāng)具有一下特點(diǎn)： 完整性：每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設(shè)計(jì)和實(shí)現(xiàn)這些功能所需的所有必要信息。 正確性：每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開發(fā)的功能。 一致性：一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務(wù)）需求不相矛盾。 可行性：每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的。 無二義性：對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導(dǎo)致二義性，所以盡量把每項(xiàng)需求用簡潔明了的用戶性的語言表達(dá)出來。 健壯性：需求的說明中是否對可能出現(xiàn)的異常進(jìn)行

28、了分析，并且對這些異常進(jìn)行了容錯處理。 必要性：“必要性”可以理解為每項(xiàng)需求都是用來授權(quán)你編寫文檔的“根源”。要使每項(xiàng)需求 都能回溯至某項(xiàng)客戶的輸入，如Use Case 或別的來源。 可測試性：每項(xiàng)需求都能通過設(shè)計(jì)測試用例或其它的驗(yàn)證方法來進(jìn)行測試。 可修改性：每項(xiàng)需求只應(yīng)在 S R S中出現(xiàn)一次。這樣更改時(shí)易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明書更容易修改。 可跟蹤性：應(yīng)能在每項(xiàng)軟件需求與它的根源和設(shè)計(jì)元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項(xiàng)需求以一種結(jié)構(gòu)化的，粒度好（f i n e - g r a i n e d ）的方式編寫并單獨(dú)

29、標(biāo)明，而不是大段大段的敘述。 十五、簡述一下缺陷的生命周期 軟件缺陷的生命周期指的是一個軟件缺陷被發(fā)現(xiàn)、報(bào)告到這個缺陷被修復(fù)、驗(yàn)證直至最后關(guān)閉的完整過程。 簡單的軟件缺陷生命周期： 1、發(fā)現(xiàn)打開：測試人員找到軟件缺陷并將軟件缺陷提交給開發(fā)人員； 2、打開修復(fù)：開發(fā)人員再現(xiàn)、修復(fù)缺陷，然后提交測試人員去驗(yàn)證； 3、修復(fù)關(guān)閉：測試人員驗(yàn)證修復(fù)過的軟件，關(guān)閉已不存在的缺陷。 但是這是一種理想的狀態(tài)，在實(shí)際的工作中是很難有這樣的順利的，需要考慮的各種情況都還是非常多的。 復(fù)雜的軟件缺陷生命周期： 1、新建一個軟件缺陷，這個軟件缺陷是（open）狀態(tài)，進(jìn)行bug 審查，不是代碼問題，就是設(shè)計(jì)需要修改；

30、2、新建一個軟件缺陷，這個軟件缺陷是（open）狀態(tài)，進(jìn)行bug 審查，以后修改的，就可以延期； 3、新建一個軟件缺陷，這個軟件缺陷是（open）狀態(tài)，進(jìn)行bug 審查，實(shí)際沒有這個bug，可以將其關(guān)閉； 4、新建一個軟件缺陷，這個軟件缺陷是（open）狀態(tài)，看是否清楚可重現(xiàn)，如果不能重現(xiàn)，就是缺少信息，需要返回到（open）狀態(tài)；如果能夠重現(xiàn)，就進(jìn)行修正，修正后關(guān)閉，進(jìn)行回歸測試。 十六、為什么要寫用例： 我們編寫測試用例，有如下的好處： 便于團(tuán)隊(duì)交流：假如說一個測試團(tuán)隊(duì)有 10 個成員，大家測試的時(shí)候都各自為政，沒有統(tǒng)一的標(biāo)準(zhǔn)，測試的效率無疑會大打折扣；如果大家都遵循統(tǒng)一的用例規(guī)范去寫，就

31、會解決這一 問題。 便于重復(fù)測試 ：大家知道，軟件在實(shí)際開發(fā)過程中是會有不同版本的，比如會從 1.0 升級到 10.0，那么如果不寫測試用例的話，在測試 10.0 版本的時(shí)候，你能完全記得 1.0 版本時(shí)你做過哪些測試嗎？測試用例就像一個備忘錄一樣，便于重復(fù)測試。 便于跟蹤統(tǒng)計(jì)：這一點(diǎn)是針對測試經(jīng)理或是項(xiàng)目經(jīng)理來說的，項(xiàng)目負(fù)責(zé)人通過看測試用例的執(zhí)行情況，就能了解到項(xiàng)目目前的概況，比如已經(jīng)執(zhí)行了哪些測試，還有哪些測試沒有執(zhí)行，測試沒有通過的地方主要集中在哪些模塊等。 便于用戶自測：尤其是項(xiàng)目軟件，有的時(shí)候用戶希望自己測試一下軟件產(chǎn)品，但是用戶大都 是非專業(yè)人士，他需要根據(jù)你寫好的用例來更好的檢驗(yàn)

32、產(chǎn)品的質(zhì)量。 說了這么多編寫測試用例的優(yōu)點(diǎn)，那它有沒有缺點(diǎn)呢？有一個明顯的缺點(diǎn)就是需要花費(fèi)大量 的時(shí)間，通常編寫測試用例的時(shí)間比實(shí)際執(zhí)行測試的時(shí)間還要長，這一點(diǎn)大家會在實(shí)際工作中有深刻的體會 十七、測試的種類很多，大概有1、代碼、函數(shù)級測試2、模塊、組件級測試3、系統(tǒng)測試，請說出這些測試最好由那些人員完成，測試的依據(jù)是什么，并說明理由。代碼、函數(shù)級測試一般由白盒測試人員完成，他們需要測試的是對代碼的測試模塊、組件級測試主要有灰盒或者黑盒人員測試，需要對所測試的程序內(nèi)部結(jié)構(gòu)與原理有較強(qiáng)的了解，屬于各模塊間的銜接與關(guān)系，能夠測試出模塊之間變動而造成對其他模塊的影響系統(tǒng)測試在于模塊測試與單元測試的基

33、礎(chǔ)上進(jìn)行測試。了解系統(tǒng)功能與性能，根據(jù)測試用例進(jìn)行全面的測試。十八、設(shè)計(jì)測試用例和測試數(shù)據(jù)時(shí)應(yīng)該考慮哪些方面，即不同的測試用例和數(shù)據(jù)各自針對那些方面進(jìn)行測試。 設(shè)計(jì)測試用例時(shí)需要注意的是，除了對整體流程及功能注意外，還要注意強(qiáng)度測試、性能測試、壓力測試、邊界值測試、穩(wěn)定性測試、安全性測試等多方面。設(shè)計(jì)測試用例在除了常用數(shù)據(jù)外，還需要考慮極限值、邊界值、重復(fù)值、0值及負(fù)值，即不同的測試用例需要不同類型的數(shù)據(jù)值來進(jìn)行測試。測試用例的設(shè)計(jì)一、某程序規(guī)定：輸入三個整數(shù) a 、 b 、 c 分別作為三邊的邊長構(gòu)成三角形。通過程序判定所構(gòu)成的三角形的類型，當(dāng)此三角形為一般三角形、等腰三角形及等邊三角形時(shí)，

34、分別作計(jì)算 。用等價(jià)類劃分方法為該程序進(jìn)行測試用例設(shè)計(jì)。（三角形問題的復(fù)雜之處在于輸入與輸出之間的關(guān)系比較復(fù)雜。） 分析題目中給出和隱含的對輸入條件的要求： （1）整數(shù) （2）三個數(shù) （3）非零數(shù) （4）正數(shù) （5）兩邊之和大于第三邊 （6）等腰 （7）等邊 如果 a 、 b 、 c 滿足條件（ 1 ） （ 4 ），則輸出下列四種情況之一： 1)如果不滿足條件（5），則程序輸出為 非三角形 。 2)如果三條邊相等即滿足條件（7），則程序輸出為 等邊三角形 。 3)如果只有兩條邊相等、即滿足條件（6），則程序輸出為 等腰三角形 。 4)如果三條邊都不相等，則程序輸出為 一般三角形 。 列出等價(jià)類

35、表并編號覆蓋有效等價(jià)類的測試用例： a b c 覆蓋等價(jià)類號碼 3 4 5 （1）-（7） 4 4 5 （1）-（7），（8） 4 5 5 （1）-（7），（9） 5 4 5 （1）-（7），（10） 4 4 4 （1）-（7），（11） 覆蓋無效等價(jià)類的測試用例：二、如果測試程序向打印機(jī)輸送打印內(nèi)容，應(yīng)該選用那些破壞性測試用例。答：用此程序打印大量的文件長時(shí)間不停止的使用此軟件進(jìn)行打印操作長時(shí)間不停止的打印大數(shù)量及大文件的操作；在打印過程中斷電、重啟等破壞性操作三、下圖是windows保存對話框，如果為文件名建立測試用例，等價(jià)類應(yīng)該怎樣劃分？1長文件名2短文件名3特殊字符 /。；、=-等4中

36、文/英文等四、假設(shè)由一個文本框要求輸入10各字符的郵政編碼，對于該文本框應(yīng)該怎樣劃分等價(jià)類？1 特殊字符是否可以輸入2 英文字母是否可以輸入3 漢字是否4 是否可以不輸入字符就可以確定5 輸入超過10個字符6 字符可以混合中英數(shù)字五、給你一臺冰箱，你將如何測試它？ 首先分析冰箱的主要功能：制冷和保鮮。 首先通上電，檢查冰箱是否能啟動。這是最基本的，如果這一步都不滿足，后面的也就無法進(jìn)行了。然后找一小碗水放進(jìn)去，一段時(shí)間后觀察它是否可以變成冰塊。這個過程中還可以檢查一下冰箱運(yùn)行的時(shí)候聲音是否太大，是否漏水，冰箱里面是否有異味等。然后再找一盤蔬菜（熟的和生的）或水果，觀察可以保持幾天的新鮮。此時(shí)需

37、要設(shè)定期望值，參考一些數(shù)據(jù)和資料，事先要知道該種菜和水果在常溫下保鮮是多少天，有必要時(shí)還可以和其它品牌的冰箱做比較。最后可能還要附加的功能，比如里面的燈是否會亮，溫度是否可調(diào)等。六、水杯的測試一種：測試項(xiàng)目：杯子需求測試:查看杯子使用說明書界面測試:查看杯子外觀功能度：用水杯裝水看漏不漏；水能不能被喝到安全性：杯子有沒有毒或細(xì)菌可*性：杯子從不同高度落下的損壞程度可移植性：杯子再不同的地方、溫度等環(huán)境下是否都可以正常使用兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等易用性：杯子是否燙手、是否有防滑措施、是否方便飲用用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細(xì)描述疲勞測試：將杯子

38、盛上水（案例一）放24小時(shí)檢查泄漏時(shí)間和情況；盛上汽油（案例二）放24小時(shí)檢查泄漏時(shí)間和情況等壓力測試：用根針并在針上面不斷加重量，看壓強(qiáng)多大時(shí)會穿透跌落測試: 杯子加包裝(有填充物),在多高的情況摔下不破損震動測試: 杯子加包裝(有填充物),六面震動,檢查產(chǎn)品是否能應(yīng)對惡劣的鐵路公路航空運(yùn)輸測試數(shù)據(jù)：測試數(shù)據(jù)具體編寫此處略（最討厭寫測試數(shù)據(jù)了）。其中應(yīng)用到：場景法、等價(jià)類劃分法、因果圖法、錯誤推測法、邊界值法等方法期望輸出：該期望輸出需查閱國標(biāo)、行標(biāo)以及使用用戶的需求另一種：總體來說從以下幾個方面去考慮功能性、性能性、易用性、可操作性、穩(wěn)定性方面進(jìn)行測試功能性方面的測試，主要是考慮這個水杯是否能盛水，能盛多少水，能否盛熱水，盛熱水