軟件測試筆試試題
軟件測試是一種實際輸出與預期輸出間的審核或者比較過程。下面是CN人才網小編整理的軟件測試筆試試題，歡迎閱讀參考!
軟件的缺陷等級應如何劃分?
1.致命錯誤，可能導致本模塊以及其他相關模塊異常，死機等問題;
2.嚴重錯誤，問題局限在本模塊，導致模塊功能失效或異常退出
3.一般錯誤，模塊功能部分失效;
4.建議問題，由問題提出人對測試對象的改進意見;
如果能夠執行完美的黑盒測試，還需要進行白盒測試嗎?(白盒與黑盒的區別)
任何工程產品(注意是任何工程產品)都可以使用以下兩種方法之一進行測試。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能?
2、在接口上，輸入是否能正確的接受?能否輸出正確的結果?
3、是否有數據結構錯誤或外部信息(例如數據文件)訪問錯誤?
4、性能上是否能夠滿足要求?
5、是否有初始化或終止性錯誤?
軟件的白盒測試是對軟件的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：
1、對程序模塊的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
3、在循環的邊界和運行的界限內執行循環體。
4、測試內部數據結構的有效性，等等。
以上事實說明，軟件測試有一個致命的缺陷，即測試的不完全、不徹底性。由于任何程序只能進行少量(相對于窮舉的巨大數量而言)的有限的測試，在未發現錯誤時，不能說明程序中沒有錯誤。
軟件測試應該劃分幾個階段?簡述各個階段應重點測試的點?各個階段的含義?
大體上來說可分為單元測試,集成測試,系統測試,驗收測試,每個階段又分為以下五個步驟:
測試計劃，測試設計，用例設計，執行結果，測試報告
初始測試集中在每個模塊上，保證源代碼的正確性，該階段成為單元測試，主要用白盒測試方法。
接下來是模塊集成和集成以便組成完整的軟件包。集成測試集中在證實和程序構成問題上。主要采用黑盒測試方法，輔之以白盒測試方法。
軟件集成后，需要完成確認和系統測試。確認測試提供軟件滿足所有功能、性能需求的最后保證。確認測試僅僅應用黑盒測試方法。
單元測試
單元測試是對軟件中的基本組成單位進行的測試，如一個模塊、一個過程等等。它是軟件動態測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟件基本組成單位的正確性。
集成測試
集成測試是在軟件系統集成過程中所進行的測試，其主要目的是檢查軟件單位之間的接口是否正確。
系統測試
系統測試是對已經集成好的軟件系統進行徹底的測試，以驗證軟件系統的正確性和性能等滿足其規約所指定的要求，檢查軟件的行為和輸出是否正確并非一項簡單的任務，它被稱為測試的“先知者問題”。
驗收測試
驗收測試旨在向軟件的購買者展示該軟件系統滿足其用戶的需求。它的測試數據通常是系統測試的測試數據的子集.
回歸測試
回歸測試是在軟件維護階段，對軟件進行修改之后進行的測試。其目的是檢驗對軟件進行的修改是否正確。
針對缺陷采取怎樣的管理措施?
1. 要更好的管理缺陷，必須引入缺陷管理工具，商用的或者開源的都可。
2. 根據缺陷的生命周期，考慮缺陷提交的管理、缺陷狀態的管理和缺陷分析的管理。
3. 所有發現的缺陷(不管是測試發現的還是走讀代碼發現的)都必須全部即時的、準確的提交到缺陷管理工具中，這是缺陷提交的管理。
4. 缺陷提交后，需要即時的指派給相應的開發人員，提交缺陷的人需要密切注意缺陷的狀態，幫助缺陷的盡快解決。缺陷解決后需要即時對缺陷的修復進行驗證。這樣的目的有兩個：一個是讓缺陷盡快解決;二是方便后面缺陷的分析(保證缺陷相關的信息準確，如齡期等)，這是缺陷狀態的管理。
5. 為了更好的改進開發過程和測試過程，需要對缺陷進行分析，總結如缺陷的類別、缺陷的齡期分布等信息，這是缺陷分析的管理。
單元測試、集成測試、系統測試的側重點是什么?
單元測試是在軟件開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試，測試重點是系統的模塊，包括子程序的正確性驗證等。
集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求，組裝成為子系統或系統，進行集成測試。實踐表明，一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。測試重點是模塊間的銜接以及參數的傳遞等。
系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。測試重點是整個系統的運行以及與其他軟件的兼容性。
設計用例的方法、依據有那些?
白盒測試用例設計有如下方法:基本路徑測試\等價類劃分\邊界值分析\覆蓋測試\循環測試\數據流測試\程序插樁測試\變異測試.這時候依據就是詳細設計說明書及其代碼結構
黑盒測試用例設計方法:基于用戶需求的測試\功能圖分析方法\等價類劃分方法\邊界值分析方法\錯誤推測方法\因果圖方法\判定表驅動分析方法\正交實驗設計方法.依據是用戶需求規格說明書,詳細設計說明書。
測試用例通常包括那些內容?著重闡述編制測試用例的具體做法不同結構的用例包括的不一樣(版本、編號、項目、設計人員、設計日期、輸入、預期輸出……)
軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果。
用例編號：測試用例的編號有一定的規則，比如系統測試用例的編號這樣定義規則： PROJECT1-ST-001 ，命名規則是項目名稱+測試階段類型(系統測試階段)+編號。定義測試用例編號，便于查找測試用例，便于測試用例的跟蹤。
測試標題：對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。比如 “ 測試用戶登錄時輸入錯誤密碼時，軟件的響應情況 ” .重要級別：定義測試用例的優先級別，可以籠統的分為 “ 高 ” 和 “ 低 ” 兩個級別。一般來說，如果軟件需求的優先級為 “ 高 ” ，那么針對該需求的測試用例優先級也為 “ 高 ” ;反之亦然，測試輸入：提供測試執行中的各種輸入條件。根據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測試用例設計中會遇到很大的障礙。
操作步驟：提供測試執行過程的步驟。對于復雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出。
預期結果：提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。如果在實際測試過程中，得到的實際測試結果與預期結果不符，那么測試不通過;反之則測試通過。
（小常識）軟件測試是伴隨著軟件的產生而產生的。早期的軟件開發過程中軟件規模都很小、復雜程度低，軟件開發的過程混亂無序、相當隨意，測試的含義比較狹窄，開發人員將測試等同于“調試”，目的是糾正軟件中已經知道的故障，常常由開發人員自己完成這部分的工作。
【軟件測試筆試試題】相關文章：
軟件測試常見的筆試題目08-08
軟件測試面試題07-18
軟件測試面試題06-27
軟件測試的面試題04-20
外企軟件測試面試題08-23
各大公司軟件測試面試題08-06
匯豐筆試題10-08
最新經典筆試題08-11
產品經理筆試題10-14