軟件測試工程師面試題(有答案)及軟件測試規(guī)范

如軟件測試規(guī)范第5頁，共3頁1．軟件測試的目的是盡可能多的找出軟件的缺陷。（Y）

2．Beta測試是驗收測試的一種。（Y）

3．驗收測試是由最終用戶來實施的。（N）

4．項目立項前測試人員不需要提交任何工件。（Y）

5．單元測試能發(fā)現(xiàn)約80%的軟件缺陷。（Y）

6．代碼評審是檢查源代碼是否達到模塊設計的要求。（N）

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

8．負載測試是驗證要檢驗的系統(tǒng)的能力最高能達到什么程度。（N）

9．測試人員要堅持原則，缺陷未修復完堅決不予通過。（N）

10．代碼評審員一般由測試員擔任。（N）

11．我們可以人為的使得軟件不存在配置問題。（N）

12．集成測試計劃在需求分析階段末提交。（N）

二、選折

1．軟件驗收測試的合格通過準則是：（ABCD）

A．軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標全部達到要求。

B．所有測試項沒有殘余一級、二級和三級錯誤。

C．立項審批表、需求分析文檔、設計文檔和編碼實現(xiàn)一致。

D．驗收測試工件齊全。

2．軟件測試計劃評審會需要哪些人員參加？（ABCD）

A．項目經(jīng)理

B．SQA負責人

C．配置負責人

D．測試組

3．下列關于alpha測試的描述中正確的是：（AD）

A．a(chǎn)lpha測試需要用戶代表參加

B．a(chǎn)lpha測試不需要用戶代表參加

C．a(chǎn)lpha測試是系統(tǒng)測試的一種

D．a(chǎn)lpha測試是驗收測試的一種

4．測試設計員的職責有：（BC）

A．制定測試計劃

B．設計測試用例

C．設計測試過程、腳本

D．評估測試活動

5．軟件實施活動的進入準則是：（ABC）

A．需求工件已經(jīng)被基線化

B．詳細設計工件已經(jīng)被基線化

C．構架工件已經(jīng)被基線化

D．項目階段成果已經(jīng)被基線化

三、添空

1.軟件驗收測試包括：正式驗收測試，alpha測試，beta測試。

2.系統(tǒng)測試的策略有：功能測試，性能測試，可靠性測試，負載測試，易用性測試，強度測試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，故障恢復測試，界面測試，容量測試，兼容性測試，分布測試，可用性測試，（有的可以合在一起，分開寫只要寫出15就滿分哦）

3.設計系統(tǒng)測試計劃需要參考的項目文擋有：軟件測試計劃，軟件需求工件和迭代計劃。

4.對面向過程的系統(tǒng)采用的集成策略有：自頂向下，自底向上兩種。

5.（這題出的有問題哦，詳細的5步驟為~~）通過畫因果圖來寫測試用例的步驟為：

（1）分析軟件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），并給每個原因和結果賦予一個標識符。

（2）分析軟件規(guī)格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系?根據(jù)這些關系，畫出因果圖。

（3）由于語法或環(huán)境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。

（4）把因果圖轉換成判定表。

（5）把判定表的每一列拿出來作為依據(jù)，設計測試用例。

四、簡答（資料是搜集整理的，感謝前輩的解題）無

1.區(qū)別階段評審的與同行評審

同行評審目的:發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤,主要是找錯誤;

階段評審目的:評審模塊階段作品的正確性可行性及完整性

同行評審人數(shù):3-7人人員必須經(jīng)過同行評審會議的培訓,由SQA指導

階段評審人數(shù):5人左右評審人必須是專家具有系統(tǒng)評審資格

同行評審內容:內容小一般文檔<

40頁,代碼<500行階段評審內容:內容多,主要看重點

同行評審時間:一小部分工作產(chǎn)品完成

階段評審時間:通常是設置在關鍵路徑的時間點上!

2.什么是軟件測試

使用人工和自動手段來運行或測試摸個系統(tǒng)的過程。其目的在于驗證他是否滿足規(guī)定的需求或弄清楚預期結果和實際結果的差別。

3簡述集成測試的過程

系統(tǒng)集成測試主要包括以下過程：

1.構建的確認過程。

2.補丁的確認過程。

3.系統(tǒng)集成測試測試組提交過程。

4.測試用例設計過程。

5.測試代碼編寫過程。

6.Bug的報告過程。

7.每周/每兩周的構建過程。

8.點對點的測試過程。

9.組內培訓過程。

4怎么做好文檔測試

仔細閱讀，跟隨每個步驟，檢查每個圖形，嘗試每個示例。P142

檢查文檔的編寫是否滿足文檔編寫的目的

內容是否齊全，正確

內容是否完善

標記是否正確

5白盒測試有幾種方法

總體上分為靜態(tài)方法和動態(tài)方法兩大類。

靜態(tài)：關鍵功能是檢查軟件的表示和描述是否一致,沒有沖突或者沒有歧義

動態(tài)：語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。

6系統(tǒng)測試計劃是否需要同行審批，為什么

需要，系統(tǒng)測試計劃屬于項目階段性關鍵文檔，因此需要評審。

7Alpha測試與beta的區(qū)別

Alpha測試在系統(tǒng)開發(fā)接近完成時對應用系統(tǒng)的測試；測試后仍然會有少量的設計變更。這種測試一般由最終用戶或其它人員完成，不能由程序或測試員完成。

Beta測試當開發(fā)和測試根本完成時所做的測試，最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。

8比較負載測試，容量測試和強度測試的區(qū)別

負載測試：在一定的工作負荷下，系統(tǒng)的負荷及響應時間。

強度測試：在一定的負荷條件下，在較長時間跨度內的系統(tǒng)連續(xù)運行給系統(tǒng)性能所造成的影響。

容量測試：容量測試目的是通過測試預先分析出反映軟件系統(tǒng)應用特征的某項指標的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在其極限值狀態(tài)下沒有出現(xiàn)任何軟件故障或還能保持主要功能正常運行。容量測試還將確定測試對象在給定時間內能夠持續(xù)處理的最大負載或工作量。容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理。容量測試是面向數(shù)據(jù)的，并且它的目的是顯示系統(tǒng)可以處理目標內確定的數(shù)據(jù)容量。

9測試結束的標準是什么？

用例全部測試。

覆蓋率達到標準。

缺陷率達到標準。

其他指標達到質量標準

10描述軟件測試活動的生命周期？

測試周期分為計劃、設計、實現(xiàn)、執(zhí)行、總結。其中：

計劃：對整個測試周期中所有活動進行規(guī)劃，估計工作量、風險，安排人力物力資源，安排進度等；

設計：完成測試方案，從技術層面上對測試進行規(guī)劃；

實現(xiàn)：進行測試用例和測試規(guī)程設計；

執(zhí)行：根據(jù)前期完成的計劃、方案、用例、規(guī)程等文檔，執(zhí)行測試用例。

總結：記錄測試結果，進行測試分析，完成測試報告。

11軟件的缺陷等級應如何劃分？

A類—致命錯誤，包括以下各種錯誤：1．由于程序所引起的死機,非法退出2．死循環(huán)3．數(shù)據(jù)庫發(fā)生死鎖4．因錯誤操作導致的程序中斷5．功能錯誤6．與數(shù)據(jù)庫連接錯誤7．數(shù)據(jù)通訊錯誤（可能導致本模塊以及其他相關模塊異常，死機等問題；）

B類—嚴重錯誤，包括以下各種錯誤：1．程序錯誤2．程序接口錯誤3．數(shù)據(jù)庫的表、業(yè)務規(guī)則、缺省值未加完整性等約束條件（問題局限在本模塊，導致模塊功能失效或異常退出）

C類—一般性錯誤，包括以下各種錯誤：1．操作界面錯誤（包括數(shù)據(jù)窗口內列名定義、含義是否一致）2．打印內容、格式錯誤3．簡單的輸入限制未放在前臺進行控制4．刪除操作未給出提示5．數(shù)據(jù)庫表中有過多的空字段（模塊功能部分失效；）

D類—建議問題，包括以下各種錯誤：1．界面不規(guī)范2．輔助說明描述不清楚3．輸入輸出不規(guī)范4．長操作未給用戶提示5．提示窗口文字未采用行業(yè)術語6．可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志

E類—測試建議

(由問題提出人對測試對象的改進意見；)如果能夠執(zhí)行完美的黑盒測試，還需要進行白盒測試嗎？

黑盒測試：從用戶角度出發(fā)，根據(jù)規(guī)格說明設計測試用例，并不涉及程序的內部特性和內部結構，只依靠被測程序輸入和輸出之間的關系或程序的功能設計測試用例。黑盒測試有兩個顯著特點：黑盒測試與軟件的具體實現(xiàn)過程無關，在軟件實現(xiàn)的過程發(fā)生變化時，測試用例仍然可以用。黑盒測試用例的設計可以和軟件實現(xiàn)同時進行，這樣能夠壓縮總的開發(fā)時間。

黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤1、是否有不正確、遺漏或額外的功能實現(xiàn)？ 2、在接口上，輸入是否能正確的接受？能否輸出正確的結果？

3、是否有數(shù)據(jù)結構錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？

4、性能上是否能夠滿足要求？

5、是否有初始化或終止性錯誤？白盒測試：已知程序的內部結構，檢查內部操作是否按規(guī)定執(zhí)行。主要對程序細節(jié)進行嚴密檢驗，針對特定條件和循環(huán)設計測試用例，對程序的邏輯路徑進行測試。通過在程序的不同點檢查程序狀態(tài)，確定實際狀態(tài)是否與預期的狀態(tài)一致。

白盒測試主要是想對程序模塊進行如下檢查：程序的所有語句至少執(zhí)行一次。對所有的邏輯條件都能至少執(zhí)行一次。在循環(huán)的邊界和運行的界限內執(zhí)行循環(huán)體。測試內部數(shù)據(jù)結構的有效性，等等。

從以上可以看出就算執(zhí)行了完美的黑盒測試也是無法測試程序內部特定部位，另外當規(guī)格說明本身有誤，也不能發(fā)現(xiàn)問題。而白盒測試能對程序的內部特定部位進行覆蓋測試，所以黑盒和白盒測試為互補關系，結合起來進行測試用例的設計更為合理。經(jīng)驗表明，通常在進行單元測試時采用白盒測試方法，集成測試采用灰盒測試方法，系統(tǒng)測試采用黑盒測試方法。軟件測試標準規(guī)范目的為了確保軟件產(chǎn)品質量，使產(chǎn)品能夠順利交付和通過驗收，特編寫本文檔，以作參考適用范圍本文檔適用于項目開發(fā)過程中的單元測試、集成測試、系統(tǒng)測試、業(yè)務測試、驗收測試以及一些專項測試。職責項目測試負責人組織編制《測試計劃》、《測試方案》，指導和督促測試人員完成各階段的測試工作。項目組測試人員按照《測試計劃》、《測試方案》完成所承擔的測試任務，并按要求填寫《問題報告及維護記錄》。測試經(jīng)理依照確認規(guī)程和準則對工作產(chǎn)品進行確認，提出對確認規(guī)程和準則的修改意見項目負責人組織測試環(huán)境的建立。項目經(jīng)理審核負責控制整個項目的時間和質量。研發(fā)人員確認修改測試人員提交的bug。工作流程測試依據(jù)詳細設計是模塊測試的依據(jù)。因此設計人員應向測試人員提供《系統(tǒng)需求規(guī)格書名書》、《詳細設計》、《概要設計》等有關資料。測試人員必須認真閱讀，真正弄懂系統(tǒng)需求和詳細設計。制訂《測試方案》在測試之前，由項目負責人根據(jù)《測試計劃》的要求，組織人員編制相應的《測試方案》，《測試方案》應包括以下內容：測試目的；所需人員及相應培訓要求；測試環(huán)境、工具和測試軟件；測試用例、測試數(shù)據(jù)和預期的結果。單元測試項目開發(fā)實現(xiàn)過程中，每個程序單元（程序單元的劃分視具體開發(fā)工具而定，一般定為函數(shù)或子程序級）編碼調試通過后，要及時進行單元測試。單元測試由單元開發(fā)者自己進行，使用白盒測試方法，根據(jù)程序單元的控制流程，爭取達到分支覆蓋。對于交互式運行的產(chǎn)品，不便于進行自動測試的，可以采用功能測試的方法進行。單元測試針對程序模塊，從程序的內部結構出發(fā)設計測試用例。多個模塊可以獨立進行單元測試。單元測試內容包括模塊接口測試、局部數(shù)據(jù)結構測試、路徑測試、錯誤處理測試等；單元測試組織原則一遍根據(jù)開發(fā)進度安排對已開發(fā)完成的單一模塊進行測試；單元測試停止標準：完成了所有規(guī)定單元的測試，單元測試中發(fā)現(xiàn)的bug已經(jīng)得到修改。集成測試編碼開發(fā)完成，項目組內部應進行組裝測試。集成測試由項目負責人組織策劃（編寫測試計劃、測試用例）并實施。集成測試著重對各功能模塊之間的接口進行測試，驗證各功能模塊是否能協(xié)調工作、參數(shù)傳遞及功能調用是否正常。測試采用交叉方法，即個人開發(fā)的軟件應由其他的項目組成員進行測試。集成測試過程應填寫《問題報告及維護記錄》，測試結果應形成《測試報告》。系統(tǒng)測試在項目開發(fā)完成之后，應對整個系統(tǒng)軟件和硬件進行系統(tǒng)測試。對性能、可靠性、健壯性、壓力承受力等方面分別進行評價，以驗證系統(tǒng)是否滿足規(guī)定的需要。系統(tǒng)測試由測試負責人組織策劃（編寫測試計劃、測試用例）并實施，系統(tǒng)測試過程應形成《問題報告及維護記錄》。系統(tǒng)測試一般進行如下幾種情況的測試：正常情況非正常情況破壞性測試邊界情況非法情況強度測試性能測試兼容性測試用戶友好性測試界面設計規(guī)范測試：光標的初始位置字體是否統(tǒng)一字號是否符合規(guī)定標題顏色按鈕的名稱是否規(guī)范界面布局是否合理，整體效果如何輸入值測試：數(shù)據(jù)類型數(shù)據(jù)長度約束條件是否滿足，是否完整TAB和Enter鍵是否起作用鍵盤操作能否全部代替鼠標操作輸入（光標）是否按照順序前進按鈕測試：將按鈕放開和封閉是否嚴格、準確，不能使用的按鈕必須封閉檢查“退出”、“取消”等具有共性按鈕的功能異常情況測試：在完成正常功能測試后，安正常處理的相同操作順序，執(zhí)行與正常處理不同的動作例如正常處理中要求輸入日期的字段，這時輸入字符或數(shù)字正常處理中輸入字段有范圍要求，這時輸入超過范圍的值正常處理中用兩個值限定范圍，這時用一個值或不限定正常處理中要求用“Tab”鍵，這時安“Enter”鍵或其他鍵正常處理中單選框、多選框、下拉框等，十一偶那個非指定鍵操作使用不同于指定的按鈕操作業(yè)務測試在組裝測試與系統(tǒng)測試結束后，均可由最終用戶或測試人員對系統(tǒng)進行測試。業(yè)務測試著重測試業(yè)務流程，功能、用戶界面等方面。項目、測試負責人負責組織相關人員制定測試方案和測試用例，并進行測試。測試的結果應形成《問題報告及維護記錄》。驗收測試驗收測試的條件按照項目計劃規(guī)定的驗收測試進度安排進行測試準備在驗收測試前，各項內部的測試活動都受到監(jiān)控并爭取執(zhí)行交付版本的要求按照集成測試用例完成了整個系統(tǒng)的集成測試集成版本滿足設計定義的各項功能、性能要求提交的數(shù)據(jù)庫腳本樣本需要完整，沒有冗余數(shù)據(jù)在集成測試中發(fā)現(xiàn)的bug已經(jīng)得到解決，各級缺陷修改率達到標準軟件需求分析說明書中定義的所有功能都已經(jīng)實現(xiàn)，性能指標全部達到性能需求指標提交階段性測試報告，包括功能和性能測試報告所有文檔齊備完整版本發(fā)布的準則軟件產(chǎn)品通過了單元測試、集成測試、業(yè)務測試、系統(tǒng)測試、性能測試測試部提交文檔：測試計劃、測試方案、測試用例、測試分析報告所有測試項必須符合以下標準致命錯誤：無功能錯誤：無功能缺陷：項目經(jīng)理、技術經(jīng)理、測試負責人審核通過界面缺陷：項目經(jīng)理、技術經(jīng)理、測試負責人審核通過建議：項目經(jīng)理、技術經(jīng)理、測試負責人審核通過以上幾項其中之一不滿足要求，視為不合格在產(chǎn)品交付和用戶驗收之前，通過驗收測試來確認在規(guī)定的使用環(huán)境下整個產(chǎn)品的運行情況是否滿足規(guī)定的要求。在產(chǎn)品交付之前，由指定的驗收負責人組織制定測試方案和測試用例，主持驗收。驗收測試過程應形成《問題報告及維護記錄》。用戶現(xiàn)場測試將軟件部署到用戶實際生產(chǎn)環(huán)境后，由于環(huán)境差異，需要在用戶現(xiàn)場進行確認測試，保證系統(tǒng)功能、性能完備，可正常運行。測試內容：根據(jù)軟件系統(tǒng)規(guī)模，準備現(xiàn)場測試用例，涵蓋所有重要功能點，若規(guī)模小，需要將全部功能點全部測試一遍對于后臺已定義好的工作流、功能欄目路徑以及用戶信息等數(shù)據(jù)，不可進行修改和刪除操作，新增的測試數(shù)據(jù)也需要在測試完成后給予清楚重點檢查上傳、下載的數(shù)據(jù)是否可以正常的打開或保存確認界面美觀，基本信息和鏈接無錯誤考慮用戶實際的軟件環(huán)境和網(wǎng)絡環(huán)境，以客戶端最為復雜的軟硬件環(huán)境作為測試機器，檢查有無異常情況出現(xiàn)針對前期發(fā)現(xiàn)的bug進行回歸測試，以保證發(fā)布版本為最新版本編寫測試文檔測試點將測試模塊分解成多個功能點，測試點應涵蓋功能點，也涵蓋了正常測試和異常測試。輸入數(shù)據(jù)輸入數(shù)據(jù)包括界面輸入數(shù)據(jù)、數(shù)據(jù)庫的初始數(shù)據(jù)及其他外部輸入數(shù)據(jù)。特別是數(shù)據(jù)庫的初始所需屬性一一列出，全面是指：數(shù)據(jù)能達到模塊所涉及的全部功能，典型是指這個數(shù)據(jù)能充分反映功能特點。測試描述描述測試步驟，包括：操作員所執(zhí)行的動作（包括鼠標、鍵盤、加載外部數(shù)據(jù)等操作）；系統(tǒng)的反應，包括：光標定位、光標聚焦、顯示字段值、按鈕的封閉和放開、功能鍵的封閉和放開、系統(tǒng)提示和系統(tǒng)消息等。預期輸出數(shù)據(jù)按準備的輸入數(shù)據(jù)和設計要求的處理過程，模塊應輸出的數(shù)據(jù)。輸出數(shù)據(jù)包括：屏幕輸出數(shù)據(jù)、輸出到數(shù)據(jù)庫的數(shù)據(jù)、輸出到其他外部介質上的數(shù)據(jù)，并指出斷點結果或最終結果。實際輸出填寫本測試點程序運行后的實際輸出。正確與否程序運行后，實際輸出結果和預期輸出結果一致時，為正常，否則為不正常。測試結論填寫本次測試的結論，是合格或不合格。若不合格時，應總結存在的問題，可以讓修改者一目了然。缺陷管理缺陷的定義及其基本屬性缺陷是指在軟件開發(fā)過程中的針對軟件產(chǎn)品和開發(fā)過程中的問題，這些問題已經(jīng)影響或可能會影響軟件產(chǎn)品的質量。缺陷應該具備以下屬性，也就是往缺陷管理庫或者缺陷列表中提交的缺陷應該具備以下屬性：屬性名稱描述缺陷標識標記某個缺陷的一組符號，每個缺陷必須有一個唯一的標識缺陷類型根據(jù)缺陷的自然屬性劃分的缺陷種類缺陷驗證程度因缺陷引起的故障對軟件產(chǎn)品的影響程度缺陷所處的模塊或子系統(tǒng)缺陷分步的模塊或子系統(tǒng)缺陷出現(xiàn)幾率指發(fā)現(xiàn)錯誤的幾率缺陷的重現(xiàn)步驟詳細的缺陷重現(xiàn)步驟附件與缺陷相關的附件（截圖、附件、用例等）備注對缺陷的其他描述缺陷分類根據(jù)缺陷的定義，將缺陷分為如下列：文檔缺陷：是指對文檔的靜態(tài)檢查過程中發(fā)現(xiàn)的缺陷。檢查活動包括同行評審、產(chǎn)品審計等。評審的缺陷要根據(jù)被評審對象的類型來確定，被評審的對象包括最終出產(chǎn)物和中間過程產(chǎn)出物，比如需求文檔、設計文檔、計劃、報告、用例等代碼缺陷：是指對代碼進行同行評審、審計或代碼走查過程中發(fā)現(xiàn)的缺陷測試缺陷：是指由測試活動發(fā)現(xiàn)的測試對象（被測對象一般是指可運行的代碼、系統(tǒng)，不包括靜態(tài)測試發(fā)現(xiàn)的問題）的缺陷，測試活動包括單元測試、集成測試、系統(tǒng)測試、性能測試等過程缺陷：有稱為不符合項問題，是指通過過程審計、過程分析、管理評審、質量評估、質量審核等活動發(fā)現(xiàn)的關于過程的缺陷和問題。過程缺陷的發(fā)現(xiàn)者一般是測試人員、項目經(jīng)理等文檔缺陷分類缺陷分類描述描述不完整文檔內容缺失，或文檔應該包括的范圍沒有涵蓋不一致一致性問題有兩類：一是與源頭說明書不一致，比如需求和客戶業(yè)務需求不一致、設計與需求不一致等二是上下文或者與前提不一致描述錯誤文檔描述是錯誤的，不可實現(xiàn)或導致錯誤的輸出或結果功能問題該缺陷將會導致用戶功能的錯誤、不滿足、不可用不清楚或有歧義內容的描述不清楚、不能準確表達、或表達的意思有歧義邏輯錯誤內容組織邏輯不清楚、邏輯錯誤接口問題與最終用戶接口問題、與外部系統(tǒng)的接口問題、內部子系統(tǒng)或模塊的接口問題輸入輸出問題輸入輸出不完整、不正確、不可測試或驗證不細化內容還需要進一步細化性能問題文檔的設計或實現(xiàn)方式存在性能問題安全性問題文檔的設計或實現(xiàn)方式存在安全性問題代碼缺陷分類缺陷分類描述常量變量定義問題不滿足設計或需求編寫代碼不符合規(guī)范條件判斷處理循環(huán)處理錯誤異常處理算法邏輯問題注釋問題代碼冗余性能問題系統(tǒng)測試缺陷分類缺陷類型描述功能錯誤影響了重要的特性、用戶界面、產(chǎn)品接口或全局數(shù)據(jù)結構，并且設計文檔需要爭取的變更。如邏輯、循環(huán)、遞歸、功能等缺陷結構錯誤Web應用程序結構化頁面無法顯示，或者顯示錯誤腳本錯誤Web應用程序當中出現(xiàn)腳本錯誤，包括客戶端對數(shù)據(jù)進行校驗和運算的各種情況下產(chǎn)生的錯誤頁面鏈接錯誤Web應用程序頁面出現(xiàn)空鏈接、錯誤鏈接、死鏈接頁面文字錯誤Web應用程序頁面出現(xiàn)的中外文拼寫、使用、以及不同語種頁面的編碼錯誤頁面圖形錯誤Web應用程序頁面出現(xiàn)圖片內容使用不當，或者無法顯示ALT錯誤Web應用程序頁面當中超文本標識語言、文本標簽解釋錯誤排版錯誤Web應用程序頁面排版不符合要求或者不符合使用習慣業(yè)務邏輯不合理應用程序的實現(xiàn)流程和規(guī)定業(yè)務流程不一致，或者實現(xiàn)流程無法正確完成。包括流程數(shù)據(jù)的部分并行、爭用、同步等操作，引起的流程斷裂、死鎖、以及其他異常情況業(yè)務邏輯不方便應用程序實現(xiàn)流程在實際情況下雖然可以完成，但是存在不必要的反復、等待、冗余等影響使用效率的情況其他錯誤其他未分類錯誤建議系統(tǒng)改進建議缺陷等級定義缺陷的嚴重程度對以上所述的缺陷類型都是適合的，缺陷的嚴重程度反映的是對缺陷的發(fā)現(xiàn)對象可能造成的影響或后果來定義的。缺陷等級缺陷性質系統(tǒng)中對應的錯誤分類描述一級致命錯誤系統(tǒng)崩潰系統(tǒng)死鎖導致對被描述的主要對象的理解錯誤、不可行、不可運轉、對業(yè)務和整個系統(tǒng)造成重大損失或損害；對使用、維護或保管人員有危險或不安全，以及對產(chǎn)品的基本功能有致命影響的缺陷二級嚴重缺陷嚴重錯誤對被描述的部分對象的理解或實現(xiàn)錯誤，部分的模塊或系統(tǒng)不可行或不能運轉或部分模塊和系統(tǒng)缺失，對整個系統(tǒng)有重大影響或可能造成部分的損失或損害；嚴重影響使用安全三級一般缺陷次要錯誤布局不合理文字錯誤系統(tǒng)中部分單元模塊或單個功能描述和實現(xiàn)有錯誤、有偏差、不一致或有缺失，不影響模塊的正常運行，或有影響，但可以有替代的辦法或避免辦法四級微小缺陷微不足道基本不影響系統(tǒng)的運行和功能的實現(xiàn)。但是與標準、規(guī)范和定義不一致五級建議缺陷新特性不在定義、標準、范圍的定義和約束之內，但是從提出者來看是需要完善的建議缺陷優(yōu)先級定義缺陷優(yōu)先級描述特急需要立刻進行修改加急一天到兩天之內必須修改高介于中和加急之間中缺陷需要正常排隊等待修復或列入軟件發(fā)布清單低留到組后解決，如果項目的進度跟緊張可以在產(chǎn)品發(fā)布以前不解決缺陷狀態(tài)定義缺陷狀態(tài)描述初始狀態(tài)（New）測試或開發(fā)人員提交一個新的缺陷，等待開發(fā)人員或項目經(jīng)理分配修改負責人打回（FeedBack）要求缺陷的報告者再次對缺陷進行說明已分配（Assigned）是指已經(jīng)分配給屬主，等待修改。已解決（Resolved）缺陷被屬主修改，等待測試人員驗證關閉（Closed）測試人員驗證缺陷