軟件測試計劃書費

1、文檔標識：2010091601 學生信息管理系統(tǒng)學生信息管理系統(tǒng) 軟件測試計劃書軟件測試計劃書 編 寫 者 李寶剛 校 對 李寶剛 小組成員 李寶剛 孔維一 李宇杰 二 o 一 o 年七月 目錄目錄 1.引言引言.1 1.1.目的.1 1.2.背景.1 1.3.范圍.1 1.4.定義.1 1.5.參考資料.1 2.測試內(nèi)容測試內(nèi)容.1 3.測試規(guī)則測試規(guī)則.2 3.1.進入準則.2 3.2.暫停/退出準則.2 3.3.測試方法.2 3.4.測試手段.3 3.5.測試要點.3 3.6.測試工具.4 4.測試環(huán)境測試環(huán)境.4 4.1.硬件環(huán)境.4 4.2.軟件環(huán)境.4 4.3.安全性環(huán)境要求.4

2、5.項目任務項目任務.4 5.1.測試規(guī)劃.4 5.2.測試設計.4 5.3.測試執(zhí)行準備.5 5.4.測試執(zhí)行.6 5.5.測試總結(jié).7 6.實施計劃實施計劃.8 6.1.工作量估計.8 6.2.人員需求及安排.8 6.3.進度安排.8 6.4.其他資源需求及安排.9 6.5.可交付工件.9 7.風險管理風險管理.9 1. 引言引言 .目的目的 隨著學校規(guī)模不斷擴大,學生數(shù)量急劇增加，有關(guān)學生的信息量也成倍增長，面對龐大的信息量需要有 學生管理系統(tǒng)來提高學生管理工作的效率。本系統(tǒng)主要用于學校學生信息管理，總體任務是實現(xiàn)學生信息關(guān) 系的系統(tǒng)化、規(guī)范化、自動化，其主要任務是用計算機

3、對學生各種信息進行日常管理，如查詢、修改、增加、 刪除，另外還考慮到學生選課，針對了這些要求設計了學生信息管理系統(tǒng)。 .背景背景 在高校，計算機應用的非常普遍，在這種實用的學生信息管理系統(tǒng)可以使局面得到改觀。學生信息管理 系統(tǒng)主要提供了方便高校的管理功能以及網(wǎng)上信息的查閱平臺，學生可以通過該系統(tǒng)查詢相關(guān)信息，管理員 可以管理信息，本系統(tǒng)主要功能有： 1 學生管理功能：為了方便學生信息的增加、刪除、修改、查詢。 2 課程管理功能：管理員可以通過填寫表格的形式修改課程等相關(guān)信息。 3 成績管理功能：管理員可以通過數(shù)據(jù)庫中的學生成績信息進行增加、修改。 4 班級管理功能：管理員可以通過

4、此功能對班級信息進行增加、刪除、修改、查詢。 5 用戶管理功能：可以增加、刪除、修改、查看該程序的用戶登錄，超級管理員可以設置用戶的權(quán)限。 .范圍范圍 本學生信息管理系統(tǒng)主要應用在各個學校為了方便管理學生信息而成。 主要設計人員由在校學生以及老師組成。 測試風險有可能軟件應用過程中出現(xiàn)一些錯誤或者故障。 時間進度：2010-7 - .定義定義 學生管理系統(tǒng) 信息管理 數(shù)據(jù)庫 軟件測試 .參參考資料考資料 列出編寫本計劃及測試整個過程中所要參考的文件、資料。 編號編號 資料名稱資料名稱作者作者日期日期出版單位出版單位 1軟件測試自動化 鄧波 黃麗娟 曹青

5、春1987機械工業(yè)出版社 2有效軟件測試 elfriede dustin 1990清華大學出版社 3軟件測試周予濱 姚靜1996機械工業(yè)出版社 列出編寫本計劃時需查閱的 intenet 上雜志、專業(yè)著作、技術(shù)標準。 查閱內(nèi)容查閱內(nèi)容網(wǎng)點地址網(wǎng)點地址簡介簡介 軟件測試http:/www.china- 受控庫，不 經(jīng)過審批不能隨意更改 3) 按照集成構(gòu)件計劃及增量集成策略完成了整個系統(tǒng)的集成測試 4) 達到了測試計劃中關(guān)于集成測試所規(guī)定的覆蓋率的要求 5) 集成工作版本滿足設計定義的各項功能、性能要求 6) 在集成測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改，各級缺陷修復率達到標準 7) a、b 類 bug 不能

6、存在 8) c、d 類 bug 允許存在,但不能超過單元測試總 bug 的 50 9) e 類 bug 允許存在 3.2.2 系統(tǒng)測試退出標準 1) 系統(tǒng)測試用例設計已經(jīng)通過評審 2) 按照系統(tǒng)測試計劃完成了系統(tǒng)測試 3) 系統(tǒng)測試的功能覆蓋率達 100 4) 系統(tǒng)的功能和性能滿足產(chǎn)品需求規(guī)格說明書的要求 5) 在系統(tǒng)測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改并且各級缺陷修復率達到標準 6) 系統(tǒng)測試后不存在 a、b、c 類缺陷 7) d 類缺陷允許存在，不超過總?cè)毕莸?5 8) e 類缺陷允許存在，不超過總?cè)毕莸?10 .測試方法測試方法 單元測試：純代碼的測試（白盒測試）。主要測試代碼語句

7、的正確性，如所有的代碼是否都可以跑到，是否 有冗余的代碼等等。 集成測試：接口測試（灰盒測試，結(jié)合白盒和黑盒測試）。主要測試代碼塊之間的接口。看看數(shù)據(jù)的傳輸是 否有問題。 系統(tǒng)測試：黑盒測試。不接觸代碼，只對整個系統(tǒng)做功能的測試和性能的測試。 確認測試：是客戶做的測試。也可以叫做驗收測試?？蛻魧λ岢龅男枨?，對應要交付的軟件看看是否達到 其要求。 .測試手段測試手段 3.4.1 手工測試 就是由人去一個一個的輸入用例，然后觀察結(jié)果，和機器測試相對應，屬于比較原始但是必須的一 個步驟。 在測試過程中，手工測試的比重一般在30%左右。手工測試一般能夠發(fā)現(xiàn)一些 自動化測試 所不 能發(fā)現(xiàn)

8、的問題，這也是為什么自動化測試取代不了手工測試的原因！ 3.4.2 自動測試 對程序的回歸測試更方便。這可能是自動化測試最主要的任務，特別是在程序修改比較頻繁時，效果是 非常明顯的。由于回歸測試的動作和用例是完全設計好的，測試期望的結(jié)果也是完全可以預料的，將回歸測 試自動運行，可以極大提高測試效率，縮短回歸測試時間。 .測試要點測試要點 3.5.1測試思想 質(zhì)量意識（責任）：站在客戶的立場 好奇心（動力）：探索所有的功能，深入理解系統(tǒng)內(nèi)核 進攻（激情）：多角度發(fā)現(xiàn)所有可能的問題，測試和開發(fā)之間是進攻和防守的關(guān)系 幫助（溝通）：以幫助而不是找茬的心態(tài)與開發(fā)團隊一起分析問題，協(xié)同工作

9、 3.5.2測試工程 測試目的：盡可能多地發(fā)現(xiàn)缺陷 測試階段：測試計劃、測試需求、測試設計、測試執(zhí)行、測試報告 測試用例設計：測試環(huán)境，測試數(shù)據(jù)，執(zhí)行步驟，期望結(jié)果 缺陷跟蹤：提交、分派、修復、驗證、審計；回歸測試； 測試結(jié)束準則：嚴重缺陷數(shù)在一定范圍內(nèi)、測試用例執(zhí)行完畢、或規(guī)定時間到（取決于項目/組織質(zhì)量要求 ） 測試人員考核：沒有可靠的定量指標（比如不能拿缺陷數(shù)來做） 3.5.3測試技術(shù) 單元測試，模塊測試，產(chǎn)品測試，集成測試，系統(tǒng)測試，用戶驗收測試 功能測試，性能測試，壓力測試，冒煙測試，猴子測試 內(nèi)部測試，外部測試（客戶試用） 白盒測試，黑盒測試 .測試工具測試工具 軟件

10、測試方面的工具很多，主要有 mercuryinteractive（mi） 、segue、rational、 compuware 和 empirix 等等 4. 測試環(huán)境測試環(huán)境 .硬件環(huán)境硬件環(huán)境 就是指由傳播活動所需要的那些物質(zhì)條件、有形條件之和構(gòu)筑而成的環(huán)境。 .軟件環(huán)境軟件環(huán)境 就是指運行于計算機硬件之上的驅(qū)動計算機及其外圍設備實現(xiàn)某種目的的軟件系統(tǒng)。如測 試軟件等 .安全性環(huán)境要求安全性環(huán)境要求 必須在無病毒，無入侵的環(huán)境下進行測試。 5. 項目任務項目任務 .測試規(guī)劃測試規(guī)劃 學生信息管理系統(tǒng)是一個典型的數(shù)據(jù)庫應用程序,由班級管

11、理、學生檔案管理、學生交費管 理、課程管理、成績管理等模塊組成,特規(guī)劃如下: 5.1.1 系統(tǒng)管理模塊 該模塊的主要任務是維護系統(tǒng)的正常運行和安全性設置,包括添加用戶、修改密碼、重新登 錄等等。 5.1.2 班級管理模塊 該模塊的功能是實現(xiàn)對全校班級的管理工作，包括：班級游覽、班級添加、班級查詢等， 這三個功能模塊各自獨立，完成學校的全部班級的管理。 5.1.3 學生檔案管理模塊 該模塊的主要功能是實現(xiàn)對學生的個人信息的管理工作，包括檔案添加、檔案瀏覽、檔案 查詢等功能，從而方便學校管理部門對學校的基本情況的快速查詢和了解。 5.1.4 課程管理模塊 該模塊對各個班級的課程進行設置，并可在其中

12、設置各門課程的教材選用情況，方便了學 校教材管理部門和教務處的教學管理人員的工作。該模塊包括基本課程設計和班級課程設置兩 個模塊。 5.1.5 成績管理模塊 學校的成績管理工作是檢驗學生學習情況的一個主要手段，本模塊包括考試類型設置，共 有期中考試和期未考試兩種類型，還設置了成績添加、成績游覽、成績查詢等功能模塊。 .測試設計測試設計 5.2.1. 測試方案設計 測試方案的設計要除了要明確定義各個測試活動的對象、執(zhí)行人員、測試進度、放行標準等一系列屬性 外，還要充分考慮到成本與技術(shù)可行性。一個好的測試方案總是遵循著以下設計原則：(1) 測試成本與測試 工作產(chǎn)生的效益處于最佳比值；

13、（2）各具體測試活動描述清晰，目標明確，內(nèi)容完備；（3）測試手段是可 行的；（4）測試產(chǎn)生的結(jié)果是可以用于指導產(chǎn)品質(zhì)量改進的。筆者注意到一些企業(yè)對于第（3）點存在認識 上的誤區(qū)，盲目購置的一批自動化測試工具，卻無人懂操作，或者根本就不適合自己的開發(fā)環(huán)境。這些問題 在測試方案設計過程中應該努力避免的。 在進行測試方案的具體設計時，常常也暴露出來一些難題和障礙。最常見的就是角色安排多，測試人員 少。解決這一問題的根本途徑是招募測試人才，建設高效測試團隊。然而，遠水解不了近渴。如果你的測試 團隊遭遇到此類尷尬，那么，你就需要考慮一下變通之策：前面提到的外包和外協(xié)都是不錯的處理辦法。另 外，建議你適當

14、考慮自動測試工具，某些工具的確能減少你的工作壓力（如自動集成工具能實現(xiàn)每日建構(gòu)、 壓力測試工具能緩解你編寫模擬并發(fā)程序的壓力）。除了人手的問題，了解你所在的測試團隊各成員的專業(yè) 技能也是很重要的。有些項目測試方案設計得很好，但由于缺乏相應素質(zhì)的測試團隊成員擔當測試方案中的 相應角色，測試方案只能無限期擱淺，結(jié)果不了了之。除此之外，測試方案設計人員還應多多參考軟件開發(fā) 管理類文檔，在測試的時間進度安排上與開發(fā)保持同步，如果開發(fā)進度有變動，應及時調(diào)整相應的測試進度 安排。 5.2.2. 測試用例設計 測試用例設計是對測試方案實現(xiàn)技術(shù)部分更為細致描述，相關(guān)設計技術(shù)已經(jīng)相對成熟注：目前測試用例 設計的

15、某些分支仍是研究熱點。市面上，關(guān)于測試用例的理論著作也是琳瑯滿目。下表列出了各類測試用例 設計技術(shù)，在本文中筆者不打算一一介紹，而是根據(jù)測試實踐和個人個人取向，選出了幾個有代表性的方法，供 讀者參考。有興趣的讀者，可以進一步查閱論述更細致一些的書籍。 .測試測試執(zhí)行準備執(zhí)行準備 按照開發(fā)階段劃分，軟件測試可分為單元測試、集成測試，系統(tǒng)測試和驗收測試。 單元測試：針對每個單元的測試， 以確保每個模塊能正常工作為目標。 集成測試：對已測試過的模塊進行組裝，進行集成測試。目的在于檢驗與軟件設計相關(guān)的程序結(jié)構(gòu)問題。 確認（有效性）測試：是檢驗所開發(fā)的軟件能否滿足所有功能和性能需求的最后手

16、段。有的劃分方法中，也 將確認測試合并入系統(tǒng)測試中。 系統(tǒng)測試：檢驗軟件產(chǎn)品能否與系統(tǒng)的其他部分（比如，硬件、數(shù)據(jù)庫及操作人員）協(xié)調(diào)工作。 驗收（用戶）測試：檢驗軟件產(chǎn)品質(zhì)量的最后一道工序。主要突出用戶的作用，同時軟件開發(fā)人員也應有一 定程度的參與。 驗收測試可以分成 alpha 測試和 beta 測試。 alpha 測試是由用戶在開發(fā)環(huán)境下完成的測試，beta 測試是由用戶在用戶環(huán)境下完成的測試。 如果一個軟件的做成了，那么首先應該進行單元測試，查看每個單元是否出現(xiàn)錯誤或者發(fā)生故障，如果 出現(xiàn)了錯誤或者故障，那樣該及時處理和改正，之后再進行測試，就這樣每個部分進行一次小測試，如果都 正常的話

17、，就可以進行，系統(tǒng)測試和驗收測試。 .測試執(zhí)行測試執(zhí)行 軟件測試就是利用測試工具按照測試方案和流程對產(chǎn)品進行功能和性能測試，甚至根據(jù)需要編寫不同的 測試工具，設計和維護測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進行分析和評估。執(zhí)行測試用例后，需要跟蹤 故障，以確保開發(fā)的產(chǎn)品適合需求。 1.在單元測試中，測試者需要依據(jù)詳細設計說明書和源程序清單，了解該模塊的i/o 條件和模塊的邏輯 結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的 輸入，都能鑒別和響應。 (1) 模塊接口測試 * 在單元測試的開始，應對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括：

18、調(diào)用本模塊的輸入?yún)?shù)是否正確； 本模塊調(diào)用子模塊時輸入給子模塊的參數(shù)是否正確； 全局量的定義在各模塊中是否一致； * 在做內(nèi)外存交換時要考慮： 文件屬性是否正確； open 與 close 語句是否正確； 緩沖區(qū)容量與記錄長度是否匹配； 在進行讀寫操作之前是否打開了文件； 在結(jié)束文件處理時是否關(guān)閉了文件； 正文書寫輸入錯誤， io 錯誤是否檢查并做了處理。 (2) 局部數(shù)據(jù)結(jié)構(gòu)測試 * 不正確或不一致的數(shù)據(jù)類型說明 * 使用尚未賦值或尚未初始化的變量 * 錯誤的初始值或錯誤的缺省值 * 變量名拼寫錯或書寫錯 * 不一致的數(shù)據(jù)類型 * 全局數(shù)據(jù)對模塊的影響 (3) 路徑測試 * 選擇適當?shù)臏y試用

19、例，對模塊中重要的執(zhí)行路徑進行測試。 * 應當設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。 * 對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。 (4) 錯誤處理測試 * 出錯的描述是否難以理解 * 出錯的描述是否能夠?qū)﹀e誤定位 * 顯示的錯誤與實際的錯誤是否相符 * 對錯誤條件的處理正確與否 * 在對錯誤進行處理之前，錯誤條件是否已經(jīng)引起系統(tǒng)的干預等 (5) 邊界測試 * 注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細 地選擇測試用例，認真加以測試。 * 如果對模塊運行時間有要求的話，還要專門進行關(guān)鍵路徑測試，以確定最壞

20、情況下和平均意 義下影響模塊運行時間的因素。 2.還要進行有效的測試如黑盒測試： * 有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境 ) 下，運用黑盒測試的方法，驗證被測軟件是否 滿足需求規(guī)格說明書列出的需求。 * 首先制定測試計劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。 * 通過實施預定的測試計劃和測試步驟，確定 軟件的特性是否與需求相符； 所有的文檔都是正確且便于使用； 同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測 試 * 在全部軟件測試的測試用例運行完后，所有的測試結(jié)果可以分為兩類： 測試結(jié)果與預期的結(jié)果相符。這說明軟件的這

21、部分功能或性能特征與需求規(guī)格說明書相符合， 從而這部分程序被接受。 測試結(jié)果與預期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致， 因此要為它提交一份問題報告。 3. 軟件配置復查 軟件配置復查的目的是保證 軟件配置的所有成分都齊全； 各方面的質(zhì)量都符合要求； 具有維護階段所必需的細節(jié)； 而且已經(jīng)編排好分類的目錄。 應當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。 驗收測試（ acceptance testing） * 在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應開始系統(tǒng)的驗收測試。 * 驗收測試是以用戶為主的測試。軟件開發(fā)人員和qa

22、（質(zhì)量保證）人員也應參加。 * 由用戶參加設計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試。 * 在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的可移植性、兼容性、可維護 性、錯誤的恢復功能等進行確認。 .測試總結(jié)測試總結(jié) 隨著軟件產(chǎn)業(yè)的發(fā)展，軟件產(chǎn)品的質(zhì)量控制與質(zhì)量管理正逐漸成為軟件企業(yè)生存與發(fā)展的核心。幾 乎每個大中型 it 企業(yè)的軟件產(chǎn)品在發(fā)布前都需要大量的質(zhì)量控制、測試和文檔工作，而這些工作必須 依靠擁有嫻熟技術(shù)的專業(yè)軟件人才來完成。軟件測試工程師就是這樣的一個企業(yè)重頭角色。業(yè)內(nèi)人士分 析，該類職位的需求主要集中在沿海發(fā)達城市，其中北京和上海的需求量分別占去33%和 29

23、%。民 企需求量最大，占 19%，外商獨資歐美類企業(yè)需求排列第二，占15%。然而，目前的現(xiàn)狀是：一方面 企業(yè)對高質(zhì)量的測試工程師需求量越來越大越大，另一方面國內(nèi)原來對測試工程師的職業(yè)重視程度不夠， 使許多人不了解測試工程師具體是從事什么工作。這使得許多it 公司只能通過在實際工作中進行淘汰 的方式對測試工程師進行篩選，因此國內(nèi)在短期將出現(xiàn)測試工程師嚴重短缺的現(xiàn)象。根據(jù)對近期網(wǎng)絡招 聘 it 人才情況的了解，許多正在招聘軟件測試工程師的企業(yè)很少能夠在招聘會上順利招到合適的人才。 在具體工作過程中，測試工程師的工作是利用測試工具按照測試方案和流程對產(chǎn)品進行功能和性能測試， 甚至根據(jù)需要編寫不同的測

24、試用例，設計和維護測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進行分析和評估。 對軟件測試工程師而言，必須具有高度的工作責任心和自信心。任何嚴格的測試必須是一種實事求是的 測試，因為它關(guān)系到一個產(chǎn)品的質(zhì)量問題，而測試工程師則是產(chǎn)品出貨前的把關(guān)人，所以，沒有專業(yè)的 技術(shù)水準是無法勝任這項工作的。同時，由于測試工作一般由多個測試工程師共同完成，并且測試部門 一般要與其他部門的人員進行較多的溝通，所以要求測試工程師不但要有較強的技術(shù)能力而且要有較強 的溝通能力 。 所以這次軟件測試不僅僅鍛煉我們的技術(shù)能力，還要培養(yǎng)我們的溝通能力，只有這樣我們才能有機 會被一些知名企業(yè)所用。 6. 實施計劃實施計劃 6.1.6

25、.1.工作量估計工作量估計 根據(jù)工作內(nèi)容和項目任務對包括測試設計的工作量、測試執(zhí)行和測試總結(jié)的工作量，以人月或人 日計， 并詳細注釋測試設計、測試執(zhí)行和測試總結(jié)工作所占的比重。軟件測試工作量應為開發(fā)工作量 的 30%-40%為宜。 工作階段工作階段所需工作日所需工作日占項目的比例占項目的比例 測試規(guī)劃階段 5 天20% 測試設計階段7 天 30% 測試實施階段7 天30% 測試執(zhí)行階段3 天15% 測試總結(jié)階段 2 天5% .人員需求及安排人員需求及安排 下表列出了在此測試活動的人員安排： 角色角色人員人員具體職責具體職責/備注備注 測試經(jīng)理楊建國負責監(jiān)督其他人員工作及處理事項

26、測試設計楊建國負責軟件開發(fā)的測試程序 測試人員楊建國 負責測試軟件的可實用性 .進度安排進度安排 下表列出了測試的時間安排： 項目里程碑項目里程碑開始時間開始時間結(jié)束時間結(jié)束時間輸出要求輸出要求/備注備注 測試規(guī)劃 2010.07.102010.07.15 完成測試準備階段 測試設計 2010.07.162010.07.23 需要完成測試的設計階段 測試設計實施 2010.07.242010.07.31 按照測試的設計進行實施 測試執(zhí)行 2010.08.012010.08.03 開始進行測試的執(zhí)行階段 測試總結(jié) 2010.08.042010.08.06 測試總結(jié)階段 6.4.6.

27、4.其他資源需求及安排其他資源需求及安排 軟件測試安排如下： 1.軟件開發(fā)人員即程序員應當避免測試自己的程序，不管是程序員還是開發(fā)小組都應當避免測試 自己的程序或者本組開發(fā)的 功能模版。若條件允許，應當由獨立于開發(fā)組和客戶的第三方測試組或測 試機構(gòu)來進行軟件測試。但這并不是說程序員不能測試自己的程序，而且更加鼓勵程序員進行調(diào)試，因 為測試由別人來進行可能會會更加有效、客觀，并且容易成功，而允許程序員自己調(diào)試也會更加有效和 針對性。 2.應盡早地和不斷地進行軟件 測試，應當把軟件測試貫穿到整個軟件開發(fā)的過程中，而不應該把軟 件測試看作是其過程中的一個獨立階段。因為在軟件開發(fā)的每一環(huán)節(jié)都有可能產(chǎn)生

28、意想不到的問題，其 影響因素有很多，比如軟件本身的抽象性和復雜性、軟件所涉及問題的復雜性、軟件開發(fā)各個階段工作 的多樣性，以及各層次工作人員的配合關(guān)系等。所以要堅持軟件開發(fā)各階段的技術(shù)評審，把錯誤克服在 早期，從而減少成本，提高軟件質(zhì)量。 3.對測試用例要有正確的態(tài)度：第一，測試用例應當由測試輸入數(shù)據(jù)和預期輸出結(jié)果這兩部分組成； 第二，在設計測試用例時，不僅要考慮合理的輸入條件，更要注意不合理的輸入條件。因為軟件投入實 際運行中，往往不遵守正常的使用方法，卻進行了一些甚至大量的意外輸入導致軟件一時半時不能做出 適當?shù)姆磻?，就很容易產(chǎn)生一系列的問題，輕則輸出錯誤的結(jié)果，重則癱瘓失效！因此常用一些不合理 的輸入條件來發(fā)現(xiàn)更多的鮮為人知的 軟件缺陷。 4.人以群分，物以類聚，軟件測試也不例外，一定要充分注意軟件測試中的群集現(xiàn)象，也可以認為 是“80-