小說閱讀系統的系統測試報告

A. 測試報告怎麼寫

1 簡介1.1編寫目的本測試報告為安天科技項目的測試報告，目的在於總結測試階段的測試以及分析測試結果，描述系統是否符合ATKJ-用戶需求說明書。預期參考人員包括用戶、測試人員、開發人員、項目管理者、質量管理人員和需要閱讀本報告的高層經理。TestAge 中國軟體測試時代!T/d5sPAl 1.2項目背景本產品是為天安科技有限公司開發的外貿企業管理系統。本產品依據EasyTrade基礎模型研發，形成一個完善的以業務管理系統為核心，以基礎信息、系統維護支持的外貿企業管理系統。主要功能是對該公司生產銷售過程，財務過程實現信息化管理。 1.3系統簡介1.4術語和縮寫詞 無1.5參考資料1、 安天科技項目需求與設計、2、 安天科技項目測試計劃、3、 安天科技項目測試用例、4、 安天科技項目缺陷報告單、系統測試報告5、 公司CMMI體系文件《TS002_測試報告》 2 測試概要2.1測試用例設計 本次測試用例設計主要採用黑盒測試方法，功能模塊及集成測試採用的具體方法有等價類劃分、邊界值劃分、正交分解、因果圖分析和錯誤猜測。在系統測試時依據業務流程採用回歸測試。2.2測試環境與配置測試伺服器配置： 伺服器地址：10.0.0.39 操作系統：Windows XP Professional SP2 CPU: Intel(R) Pentium(R)4 CPU 3.00HZ 硬碟可用空間：74GB 資料庫：Microsoft SQL Server 8.00.2039 應用伺服器：EasyTrade伺服器 測試對象：EasyTradeS3.exe 缺陷工具：Mercury Interactive TD8.0 SP22.3測試方法(和工具)主要是黑盒測試，測試的重點集中在業務流程、數據提取和各功能模塊間的介面。其中單元測試由開發人員直接完成；功能模塊採用黑盒測試的常用方法；集成測試模塊採用非漸增式測試，偏重系統的介面和數據提取方面；系統測試主要體現在業務流程的測試，主要採用回歸測試3 測試結果及缺陷分析3.1測試執行情況與記錄3.1.1測試組織3j5Ylc i2r/{8TestAge 中國軟體測試時代 `4Nri0N,_$T9X測試經理：劉義照TestAge 中國軟體測試時代m!iL)S"_I­S 主要測試人員：李志學 TestAge 中國軟體測試時代(tWA ]3lh$t#K陳龍 參與測試人員：張士紅（模塊測試用例編寫） 3.1.2測試時間 測試類型 實際開始時間 實際結束時間 總工作日 功能測試 貿易管理 2008-04-14 2008-04-15 2 生產管理 2008-04-14 2008-04-15 2 采購管理 2008-04-14 2008-04-16 3 財務管理 2008-04-15 2008-04-16 2 發運單 2008-04-15 2008-04-16 2 集成測試 2008-04-16 2008-04-18 2 系統測試 2008-04-18 2008-04-24 6 安裝測試 2008-04-25 2008-04-25 1 3.1.3測試版本 版本號 修訂日期 修訂人 修訂內容說明 EASYTRADE 2008.04.16 劉義照 EASYTRADE3 2008.04.26 劉義照 3.2覆蓋分析3.2.1需求覆蓋 功能模塊 功能名稱 編號 是否通過 備注 基礎資料（JC） 國家代碼 JC01 Y 世界港口 JC02 Y 貨幣設定 JC03 Y 計量單位 JC04 Y 退稅率設定 JC05 Y 附件類別 JC06 Y 材料類別 JC07 Y 單據編號 JC08 Y 工藝說明 JC09 Y 線說明 JC10 Y 銀行利息設定 JC11 Y 貿易管理（MY） 客戶資料 MY01 Y 款式工藝 MY02 Y ▲ 客戶訂單 MY03 Y ▲ 訂單款式工藝 MY04 Y ▲ 大貨跟蹤表 MY06 Y ▲ 通訊錄 MY05 Y 排產管理（PC） 服裝工廠資料 PC01 Y 訂貨合同 PC02 Y ▲ 生產工藝資料 PC03 Y ▲ 大貨生產狀態確認 PC04 Y 采購管理（CG） 供應商資料 CG01 Y 訂購單 CG02 Y ▲ 發貨單 CG03 Y ▲ 退貨單 CG04 Y ▲ 產品清單匯總 CG05 Y 單證管理（DZ） 發運單 DZ01 Y ▲ 成本核算單 DZ02 Y ▲ 財務管理（CW） 服裝工廠往來帳目 CW01 Y 服裝廠配料擔保賬目 CW02 Y 服裝工廠結算單 CW03 Y ▲ 供應商擔保賬目 CW04 Y 註：TestAge 中國軟體測試時代­r*fm:Z1W3~?[Y][P][N][N/A]四項值依據TestAge 中國軟體測試時代測試結果，按編號給出每一測試需求的通過與否結論。P表示部分通過，N/A表示不可測試或者用例不適用。▲表示為測試重點部分。D­dS­a6} ihV WW8需求覆蓋率=Y項數/需求項數 ×100％=33/33×100％=100％3.2.2測試覆蓋 模塊 用例個數 執行數 未執行數 未執行/漏測原因 貿易管理 28 28 生產管理 38 38 采購管理 39 39 單證管理 17 17 財務管理 11 11 合計 133 133 .o Knz)u5 ~5_zD }mI-N9c8測試覆蓋率=執行總數/用例總數 ×100％=133/133×100％=100％ 3.3缺陷的統計與分析3.3.1缺陷匯總缺陷總數：105按缺陷嚴重程度：1-Low： 16個 所佔百分比：15.238% 2-Medium: 77個 所佔百分比：73.342% 3-High: 12個 所佔百分比：11.420%

B. 軟體系統測試報告怎麼寫

摘要

測試報告是把測試的過程和結果寫成文檔，並對發現的問題和缺陷進行分析，為糾正軟體的存在的質量問題提供依據，同時為軟體驗收和交付打下基礎。本文提供測試報告模板以及如何編寫的實例指南。

關鍵字

測試報告 缺陷

正文

測試報告是測試階段最後的文檔產出物，優秀的測試經理應該具備良好的文檔編寫能力，一份詳細的測試報告包含足夠的信息，包括產品質量和測試過程的評價，測試報告基於測試中的數據採集以及對最終的測試結果分析。

下面以通用的測試報告模板為例，詳細展開對測試報告編寫的具體描述。

PARTⅠ 首頁

0.1頁面內容：

密級

通常，測試報告供內部測試完畢後使用，因此密級為中，如果可供用戶和更多的人閱讀，密級為低，高密級的測試報告適合內部研發項目以及涉及保密行業和技術版權的項目。

XXXX項目/系統測試報告

報告編號

可供索引的內部編號或者用戶要求分布提交時的序列號

部門經理 ______項目經理______

開發經理______測試經理______

XXX公司 XXXX單位 （此處包含用戶單位以及研發此系統的公司）

XXXX年XX月XX日

0.2格式要求：

標題一般採用大體字（如一號），加粗，宋體，居中排列

副標題採用大體小一號字（如二號）加粗，宋體，居中排列

其他採用四號字，宋體，居中排列

0.3版本控制：

版本 作者 時間 變更摘要

新建/變更/審核

PARTⅡ 引言部分

1.1編寫目的

本測試報告的具體編寫目的，指出預期的讀者范圍。

實例：本測試報告為XXX項目的測試報告，目的在於總結測試階段的測試以及分析測試結果，描述系統是否符合需求（或達到XXX功能目標）。預期參考人員包括用戶、測試人員、、開發人員、項目管理者、其他質量管理人員和需要閱讀本報告的高層經理。

提示：通常，用戶對測試結論部分感興趣，開發人員希望從缺陷結果以及分析得到產品開發質量的信息，項目管理者對測試執行中成本、資源和時間予與重視，而高層經理希望能夠閱讀到簡單的圖表並且能夠與其他項目進行同向比較。此部分可以具體描述為什麼類型的人可參考本報告XXX頁XXX章節，你的報告讀者越多，你的工作越容易被人重視，前提是必須讓閱讀者感到你的報告是有價值而且值得浪費一點時間去關注的。

1.2項目背景

對項目目標和目的進行簡要說明。必要時包括簡史，這部分不需要腦力勞動，直接從需求或者招標文件中拷貝即可。

1.3系統簡介

如果設計說明書有此部分，照抄。注意必要的框架圖和網路拓撲圖能吸引眼球。

1.4術語和縮寫詞

列出設計本系統/項目的專用術語和縮寫語約定。對於技術相關的名詞和與多義詞一定要註明清楚，以便閱讀時不會產生歧義。

1.5參考資料

1．需求、設計、測試用例、手冊以及其他項目文檔都是范圍內可參考的東東。

2．測試使用的國家標准、行業指標、公司規范和質量手冊等等

PARTⅢ 測試概要

測試的概要介紹，包括測試的一些聲明、測試范圍、測試目的等等，主要是測試情況簡介。（其他測試經理和質量人員關注部分）

2.1測試用例設計

簡要介紹測試用例的設計方法。例如：等價類劃分、邊界值、因果圖，以及用這類方法(3-4句)。

提示：如果能夠具體對設計進行說明，在其他開發人員、測試經理閱讀的時候就容易對你的用例設計有個整體的概念，順便說一句，在這里寫上一些非常規的設計方法也是有利的，至少在沒有看到測試結論之前就可以了解到測試經理的設計技術，重點測試部分一定要保證有兩種以上不同的用例設計方法。

2.2測試環境與配置

簡要介紹測試環境及其配置。

提示：清單如下，如果系統/項目比較大，則用表格方式列出

資料庫伺服器配置

CPU：

內存：

硬碟：可用空間大小

操作系統：

應用軟體：

機器網路名：

區域網地址：

應用伺服器配置

…….

客戶端配置

…….

對於網路設備和要求也可以使用相應的表格，對於三層架構的，可以根據網路拓撲圖列出相關配置。

2.3測試方法(和工具)

簡要介紹測試中採用的方法(和工具)。

提示：主要是黑盒測試，測試方法可以寫上測試的重點和採用的測試模式，這樣可以一目瞭然的知道是否遺漏了重要的測試點和關鍵塊。工具為可選項，當使用到測試工具和相關工具時，要說明。注意要註明是自產還是廠商，版本號多少，在測試報告發布後要避免大多工具的版權問題。

C. 實驗報告系統調試及測試怎麼寫

先寫測試目的、測試項目、測試方法、測試結果、系統漏洞的補救等

D. 系統測試,驗收測試,確認測試有什麼區別和關系

1、測試目的不同：

確認測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作。

系統測試的目的是發現軟體潛在的問題，保證系統的正常運行。

驗收測試的目的是確保軟體准備就緒，並且可以讓最終用戶將其用於執行軟體的既定功能和任務。

2、測試任務不同：

確認測試是為了進一步驗證軟體的有效性。

系統測試是將經過集成測試的軟體，作為系統計算機的一個部分，與系統中其他部分結合起來，在實際運行環境下對計算機系統進行的一系列嚴格有效地測試。

驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。

3、測試順序不同：

確認測試和系統測試都是在集成測試之後，位於倒數第二位。

驗收測試是部署軟體之前的最後一個測試操作。

關系：

所有的測試都是保證產品最終符合需求（包括明確要求的和隱含需求），只不過粒度不一樣。

(4)小說閱讀系統的系統測試報告擴展閱讀

系統測試的步驟

1、 制定系統測試計劃

系統測試小組各成員共同協商測試計劃。測試組長按照指定的模板起草《系統測試計劃》。該計劃主要包括：

測試范圍（內容）

測試方法

測試環境與輔助工具

測試完成准則

人員與任務表

項目經理審批《系統測試計劃》。該計劃被批准後，轉向2。

2、設計系統測試用例

系統測試小組各成員依據《系統測試計劃》、需求規格說明書、設計原型以及指定測試文檔模板，設計（撰寫）《測試需求分析》《系統測試用例》。

測試組長邀請開發人員和同行專家，對《系統測試用例》進行技術評審。該測試用例通過技術評審後，轉向3。

3、執行系統測試

系統測試小組各成員依據《系統測試計劃》和《系統測試用例》執行系統測試。

將測試結果記錄在《系統測試報告》中，用「缺陷管理工具」來管理所發現的缺陷，並及時通報給開發人員。

4、缺陷管理與改錯

從1至3，任何人發現軟體系統中的缺陷時都必須使用指定的「缺陷管理工具」。該工具將記錄所有缺陷的狀態信息，並可以自動產生《缺陷管理報告》。

開發人員及時消除已經發現的缺陷。

開發人員消除缺陷之後應當馬上進行回歸測試，以確保不會引入新的缺陷。

E. web網站後台管理系統的測試報告怎麼寫

測試報告一般是一下內容：
兼容IE7、8、chrome、firefox，有沒有錯位
首頁廣告圖是否居中顯示，切換是否正常，內頁廣告圖是否對應顯示，能否正常上傳
各欄目、列表頁等鏈接是否正確，特別是more這類按鈕鏈接
各系統縮略圖上傳是否正常，顯示是否正常，多圖切換是否正常
在線留言是否正常提交，格式、必填項提示是否正確
語言版本切換是否正常
頁面SEO標題，關鍵詞，描述是否正確顯示
手機版蘋果瀏覽器，安卓主流瀏覽器（UC，自帶瀏覽器）兼容，有沒有錯位

F. 測試報告包含哪些內容

測試報告是把測試的過程和結果寫成文檔，並對發現的問題和缺陷進行分析，為糾正軟體的存在的質量問題提供依據，同時為軟體驗收和交付打下基礎。

測試模塊（每個模塊里需要記錄測試的開始時間、結束時間、設計多少用例、通過多少、失敗多少、有多少BUG、遺留多少BUG、解決多少BUG、追後對這個模塊總結一下）

BUG的統計，根據時間軸來統計BUG的數量，例如：XXXX年X月X日，發現BUG多少，關閉BUG多少，剩餘BUG多少，高級的BUG有多少，中級的BUG有多少，低級和建議的BUG有多少，一直羅列到項目完結

項目總結，匯報一下測試的大致結果。

遺留和風險，該軟體還有什麼遺留問題，還有什麼風險，都要一一說明

最後評判該軟體是否符合上線標准，日期，簽字，加蓋章等

G. 軟體測試報告（範文）

測試數據測試項總數 0 PASS 0 PASS率 #DIV/0! FAIL 0 FAIL率 #DIV/0! 嚴重度——高 0 其中：高-- #DIV/0! 嚴重度——中 0 中-- #DIV/0! 嚴重度——低 0 低-- #DIV/0! 測試項編號 測試項 通過與否 問題描述 問題嚴重度註： 問題嚴重度的界定：高——導致系統死機或後續部分測試項功能不能實現；中——影響該部分的測試功能的完整性且急需解決；低——僅屬於系統中的小bug，或根據測試過程發現的需要調整的部分，但並非急需解決。

H. 系統開發報告應該怎麼寫

1.1編寫目的
<br>說明這份測試分析報告的具體編寫目的，指出預期的閱讀范圍。
<br>
<br>1.2背景
<br>說明：
<br>
<br>a.被測試軟體系統的名稱；
<br>
<br>b.該軟體的任務提出者、開發者、用戶及安裝此軟體的計算中心，指出測試環境與實際運行環境 之間可能存在的差異以及這些差異對測試結果的影響。
<br>
<br>1.3定義
<br>列出本文件中用到的專問術語的定義和外文首字母組詞的原片語。
<br>
<br>1.4參考資料
<br>列出要用到的參考資料，如：
<br>
<br>a.本項目的經核準的計劃任務書或合同、上級機關的批文；
<br>
<br>b.屬於本項目的其他已發表的文件；
<br>
<br>c.本文件中各處引用的文件、資料，包括所要用到的軟體開發標准。列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。
<br>
<br>2測試概要
<br>用表格的形式列出每一項測試的標識符及其測試內容，並指明實際進行的測試工作內容與測試計劃中預先設計的內容之間的差別，說明作出這種改變的原因。
<br>
<br>3測試結果及發現
<br>3.1測試1（標識符）
<br>把本項測試中實際得到的動態輸出（包括內部生成數據輸出）結果同對於動態輸出的要求進行比較，陳述其中的各項發現。
<br>
<br>3.2測試2（標識符）
<br>用類似本報告3.1條的方式給出第 2項及其後各項測試內容的測試結果和發現。
<br>
<br>4對軟體功能的結論
<br>4.1功能1（標識符）
<br>4.1.1能力
<br>簡述該項功能，說明為滿足此項功能而設計的軟體能力以及經過一項或多項測試已證實的能力。
<br>
<br>4.1.2限制
<br>說明測試數據值的范圍（包括動態數據和靜態數據），列出就這項功能而言，測試期間在該軟體中查出的缺陷、局限性。
<br>
<br>4.2功能2（標識符）
<br>用類似本報告4.l的方式給出第2項及其後各項功能的測試結論。
<br>
<br>．．．．．．
<br>
<br>5分析摘要
<br>5.1能力
<br>陳述經測試證實了的本軟體的能力。如果所進行的測試是為了驗證一項或幾項特定性能要求的實現，應提供這方面的測試結果與要求之間的比較，並確定測試環境與實際運行環境之間可能存在的差異 對能力的測試所帶來的影響。
<br>
<br>5.2缺陷和限制
<br>陳述經測試證實的軟體缺陷和限制，說明每項缺陷和限制對軟體性能的影響，並說明全部測得的性能缺陷的累積影響和總影響。
<br>
<br>5.3建議
<br>對每項缺陷提出改進建議，如：
<br>
<br>a． 各項修改可採用的修改方法；
<br>
<br>b． 各項修改的緊迫程度；
<br>
<br>c． 各項修改預計的工作量；
<br>
<br>d． 各項修改的負責人。
<br>
<br>5.4評價
<br>說明該項軟體的開發是否已達到預定目標，能否交付使用。
<br>
<br>6測試資源消耗
<br>總結測試工作的資源消耗數據，如工作人員的水平級別數量、機時消耗等。

或者
以下資料需要你的精心的文字和格式整理

基於CMM的項目級軟體測試
楊忠秀，潘雪增，平玲娣
(浙江大學計算機科學與工程系，浙江杭州31ooz} >
摘要:從CMM的角度分析了項目級軟體測試的活動過程，並且討論了側試用例的編寫和各側試階段的輸出。
關鍵詞:CMM;軟體測試;測試用例;測試報告
中圖法分類號:TP311. 5文獻標識碼:A文章編號:1001-3695(2004)05-0009-03
CMM是由SEI提出的軟體能力成熟度模型，它描述了有
效的軟體過程單元的框架，為從事軟體開發的機構描述廠從混
亂、不成熟的軟體過程向成熟、有紀律的軟體過程改進的一條
途徑，它是基於實際實踐，並月_根據過程式控制制達到控制產品質
量的日的。「說你要做的，做你要說的」是CMM的底線，CMM
的關鍵過程域的突出特點是以「依據書面規程」或者「遵循書
面的機構管理策略」這樣的用語作為引導。CMM強調過程文
檔化，並按文檔進行實踐。本文對於具體的CMM不作介紹，
而是根據實際CMM的軟體開發中所進行的測試過程來分析。
基於CMM的軟體測試階段及其活動性
隨著社會對計算機的依賴程度的增加，軟體產品應用到社
會的各個領域，用戶為了保證業務的順利完成，對軟體產品的
質量要求也越來越高。作為一個軟體開發公司，軟體的質量成
為公司生存的關鍵。軟體測試就是在軟體投人運行前，對軟體
需求分析、設計規格說明和編碼的最終復審，是軟體質量保證
的關鍵步驟。軟體測試是軟體開發質量保證的重要環節，因
此，現在軟體開發商越來越多地重視軟體測試過程，軟體測試
已經佔到整個軟體開發過程的40%到50%。下面從軟體的生
命周期來對軟體測試階段和各階段活動特點進行分析。
1. 1軟體測試的三個階段及其作用
根據CMM軟體生命周期來看，測試分為三個階段。
(1)單元測試。本階段是對軟體的基本組成單元進行的
測試，是在軟體開發過程中要進行的最低級別的測試活動，它
在編碼完成後馬上進行。在單元測試活動中，軟體的獨立單元
將在與程序的其他部分相隔離的情況下進行測試。單元測試
的日的是:①使軟體盡早正常運行;②為集成測試奠定基礎;③快速定位錯誤;④使修改缺陷成本更低。單元測試在整個軟體
測試中佔有很重要的地位。在軟體開發過程中有一個盡早測
試原則:缺陷發現越早，消耗的成本就越低。由於單元測試具
有不徹底性，對於模塊間介面信息內容的正確性、相互調用的
關系是否符合設計無能為力。
(2)集成測試。本階段是一個應用系統的各個部件的聯
合測試，以決定它們能否在一起共同工作，部件可以是代碼塊、
獨立的應用、網路上的客戶端或伺服器端程序。由於集成測試
具有可重復性強，對測試人員透明的特點，發現問題後很容易
定位。這種類型的測試尤其與客戶伺服器和分布式系統有關。
(3)系統測試。本階段是基於系統整體需求說明書的測
試，它是驗證整個系統需求的最終測試，屬於黑盒測試，它應覆
蓋系統所有聯合的部件。
1.2三個測試階段在CMM軟體生命周期中的活動性分析
(1)需求分析階段
這個階段主要根據開發軟體的需求進行收集和分析，形成
明確的文檔。系統測試計劃就是根據軟體需求文檔制定出的，
一旦需求發生變化，系統測試計劃也要及時更新。
(2)概要設計階段
這個階段主要實現為各種需求設計各個模塊，以及各個模
塊的關系和介面。一旦概要設計定型，相對應的測試計劃就是
集成測試計劃書。在集成測試計劃中，我們要考慮到各種消息
的介面、模塊的功能流程、模塊的數據表、需要調用到的樁函
數、模塊的處理性能等。
(3)詳細設計階段
這個階段是各個模塊的具體實現，一般用偽代碼編寫，便於
檢視。詳細設計文檔確定後，相應地就要制定單元測試計劃。
單元測試的用例編寫要考慮到各種情況，即每一個條件分支都
要走到。在單元測試階段強調代碼的覆蓋率和條件覆蓋率。(4)編碼階段
這個階段就是實現詳細設計的偽代碼，在此階段要為馬上
進行的單元測試作準備。
(5)單元測試階段
在編碼階段完成後就著手進行單元測試，並輸出單元測試
報告。在測試中單元的劃分如果過大，將使定位的工作量增
大，過小的話又使得測試的回報率低。因此，合適地劃分單元
的大小是非常重要的。
(6)集成測試階段
這個階段是根據集成測試計劃進行集成測試並輸出集成
測試報告。對集成測試階段，不同的開發人員有不同的看法，
有的人認為集成測試可以省略，或者歸屬到單元測試或者系統
測試;筆者個人認為這要看其體開發的系統，如果涉及到較多
的消息傳輸，集成測試還是應該獨立進行，要不然在系統測試
時一定還得補上。
(7)系統測試階段
這個階段根據系統測試計劃進行，並輸出系統測試報告。
整個軟體生命周期的幾個階段的示意圖如圖l所示。
需求確認
需求分析及
系統測試設計
驗收測試
系統測試
概要設計及
集成測試設計
集成測試
詳細設計及
單元測試設計
單兀測試
編碼調試
圖l軟體生命周期的各階段示意圖
1. 3三個階段的比較
(I)單元測試。它針對模塊內部的程序錯誤，其目的是清
除局部模塊的邏輯與功能上的錯誤和缺陷。它的測試依據是
軟體開發流程中的模塊的詳細設計，在測試中大量採用白盒測
試方法。
(2)集成測試。它是基於模塊間的組裝和調用關系，其目
的是找出與軟體相關的程序結構、模塊間的調用關系、模塊間
的介面等方面的問題。它的測試依據是軟體開發流程中的概
要設計階段，在測試中使用白盒與黑盒測試方法，較多地採用
黑盒方法構造測試用例。
(3)系統測試。它測試的對象是整個軟體系統，對整個系
統進行一系列的整體、有效性測試。它的測試依據是軟體需求
規格說明書，採用黑盒測試。
2測試用例的編寫
在CMM的軟體生命周期中，各個階段的測試計劃絕大部
分工作是寫測試用例。測試用例的編寫對整個測試效果起著
舉足輕重的作用，可以這么說，整個軟體測試效果在測試用例
編寫完後已經被初步決定。
2. 1測試用例的編寫技巧和方法
2.1.1命名規則
由於一個項目的測試階段分為單元測試、集成測試和系統
測試，為了區分各個階段，我們一般用L1T表不單元測試階段
( Unit Test) , IT表示集成測試階段(Integration Test) , ST表示系統測試(System Test)每個項目由若+個模塊組成，我們根
據模塊名來區分每個模塊，給每一個模塊的每一個測試用例順
序編號，這樣，每一個測試用例命名就完成了。通過這樣命名，
測試用例就非常清楚是什麼項目、什麼階段、什麼模塊的測試
用例
<項目名>_<測試階段>_<模塊名>_<模塊內的測試用例編號>
2.1.2單元測試用例編寫
單元測試強調代碼覆蓋率和條件覆蓋率，我們在編寫測試
用例的時候要保證代碼中的每一個條件分支都能執行到。單
元測試用例編寫常用到以下幾種方法:
(1)規格導出法。根據相關的需求規格描述來設計測試
用例，每一個測試用例用來測試一個或者多個規格陳述語句。
(2)邊界值分析法。用邊緣特殊值測試，程序往往在邊緣
情況時犯錯誤，故測試邊緣情況比較有效。例如輸人數據值的
范圍是1一16，則可選1,16,14,17等數據作為測試數據c
(3)等價類劃分法。等價分類法是將輸人數據的可能值
分成若干「等價類」，每一類以一個代表性的測試數據進行測
試，這個數據就等價於這一類中的其他數據，該方法的關鍵在
於如何將輸人數據分類。例如輸人的數據范圍是1一999，則
可以劃分氣類:x<l;l}x<999;x}999o
(4)錯誤猜測法。這種用例的編寫需要有一定測試經驗，
根據以前的測試經驗，猜測容易出錯點，針對這個點所寫的測
試用例。
2.1.3集成測試用例編寫
集成測試強調的是模塊間的組裝和調用關系、模塊間的接
口方面的問題。作為一個良好的集成測試用例應該包括一個
合適的檢查點，以下幾個方面要注意:①功能的正確性;②消息
的流程是否正確;③來往的消息中的數據項、參數是否正確;④
消息異常、錯誤、超時等問題是否能正常處理;⑤各個模塊的狀
態遷移及相關數據結構的正確性;⑥資源的佔用和釋放情況，
運行過程中，資源的佔用和釋放是否正常;⑦全局數據的正確
J性，如全局變數、全局數組、全局數據表;⑧樁函數參數;⑨函數
調用順序。在寫集成測試用例時，從覆蓋率來講可以從以下幾
個方面來考慮:
(1)模塊的消息接日。①每類消息的每個具體消息都應
該設計測試用例;②對於消息結構中每一個數據成員的各種合
法取值情況都應該設計測試用例;③對於消息結構中每個數據
成員的非法取值情況應該設計測試用例;④模擬各種消息丟失
的情況;⑤模擬各種消息超時到達的情況;⑥模擬收到各種不
期望的消息的情況(如收到的消息超長、超短等)。
(2)模塊的功能流程。根據概要設計文檔描述中所確定
的模塊應該完成的功能，每個功能描述都應該設計測試用例驗
證。需要多個模塊以及它們之間的介面共同完成的功能，需要
設計測試用例驗證。
(3)模塊間使用數據表。針對數據的修改操作，如增加、
刪除、增加滿、刪除空、頻繁地增加、刪除等
(4)樁函數。對於無返回值或者返回值對被測模塊沒有
作用的樁，主要是檢查傳給樁的參數是否正確、合理，一個測試每一個或者每一類返回值都應設計相應的測試用例。
(5)對外介面。它是函數對外提供的函數介面，一般來
說，模塊的對外函數介面都是完成一個完整的子功能。因此，
測試函數用例①要驗證該介面能否正確完成該功能;②應驗證
函數介面各個參數輸人非法值的情況，介面函數)}}i該對所有的
輸入參數的合法性進行檢查;③函數介面的各個參數的邊界值
測試;④函數介面各個參數的合法輸人組合測試;⑤函數介面
各個參數的非法輸人組合測試。
(6)處理性能。對於處理速度有要求的模塊，應測試其處
理數據是否能達到規格要求。對於測試模塊在大負荷(大量
呼叫、大話量)等情況下的處理能力應該設計測試用例進行驗
證。
應該說集成測試在整個測試過程中是非常重要的，它起著
承卜啟下的功能。由於集成測試是屬於灰盒測試，相對於系統
測試而言，它的缺陷定位比較容易，因此，在測試過程中應該重
視集成測試。
2.1.4系統測試用例編寫
系統測試是針對整個系統進行的一系列整體的、有效的測
試。它測試的依據是軟體需求規格說明書，對於系統測試用例
的編寫，可以從軟體需求說明書中導出。在進行系統測試用例
編寫時應注意以下幾個問題:①多個需求是否可以在測試中合
並。有時一個需求值完成一件很簡單的事情，我們在進行系統
測試時是不是口f以和其他的測試用例合並呢?一般來說是可
以的，但是有可能會增加測試的復雜度。②要控制好系統測試
中的力度。③需求的分析。需求是測試用例寫作的基本，我們
要對需求進行仔細分析，不要漏寫或者錯寫了測試用例。
2. 2測試用例的編寫格式
文檔對於測試是非常重要的，由於我們在測試中是按照測
試計劃文檔來執行測試過程，因此一定要重視測試用例編寫的
格式。
對於單元測試用例的編寫，我們在寫測試用例時應明確以
下幾個問題:被測試的單元編號(用以指明該測試用例是屬於
哪一個單元)、函數原型(被測試函數)、輸人參數、輸出結果、
返回值、驅動程序、用例功能描述、預期結果。在編寫單元測試
用例時一般以一個函數為單位，這個函數的測試可能包括多個
測試用例，這樣看起來比較方便。如果形成表格形式，可採用
如表1的格式。採用這種格式編寫單元測試用例明顯，比如單
元測試編號為MMC_ UT_ DBCLASS一OS，那麼它的測試用例1
的編號就可以寫作MMG_ IlT_ DBCLASSes 005ee 001，這樣這個測
試用例屬於哪一個單元一看便知。
對於系統測試，每一個需求對應一個測試用例。編寫時，
確定寫明測試用例編號、測試標題、測試級別、對應規格、測試
預置條件、測試輸人過程、測試結果。同樣，我們採用如表2所
示的表格形式。
集成測試的格式與系統測試類似，只是關注點不一樣。
3測試報告的生成
根據測試計劃進行測試，測試完成後必須生成測試報告，質量監測部門根據提供的測試報告進行產品數據分析，可以根
據數據分析結果來指導產品的開發和質量的監控。
(I)測試匯總報告。它是對總的測試結果進行匯總的報
告，包括有多少測試用例、通過了的測試用例數量、沒有通過的
測試用例數量。
(2)缺陷報告。包括測試用例編號、缺陷產生函數、缺陷
產生原因、缺陷級別、修訂日期、修訂人。其格式如表3所示。
表1單元測試用例編寫格式
┌———————┬—————————————————————┐
│被測試單元編號│被i}單元的編號測試用例的編號緊 │
│ │跟其後 │
├———————┼—————————————————————┤
│函數原型 │該單元測試的函數 │
├———————┼—————————————————————┤
│功能簡述 │介紹函數的功能 │
├———————┼—————————————————————┤
│輸人 │輸人的參數 │
├———————┼—————————————————————┤
│輸出 │ │
├———————┤ │
│返回值 │ │
├—┬—————┼—————————————————————┤
│陣│論提條件 │ │
├—┼—————┼—————————————————————┤
│F │港動 │ │
├—┴—————┼—————————————————————┤
│各種可能 │l,ll │
│存存的條件 │ │
├———————┼——————┬——————┬——┬————┤
│測試用例編號 │lfilf}l=}Rn │輸人數據及 │霎鬢│用例功能│
│ │ │相關變數描述│ │ 描沐 │
├———————┼——————┴——————┴——┴————┤
│(1) │ │
├———————┼—————————————————————┤
│cz> │ │
└———————┴—————————————————————┘
表2系統測試用
例編寫格式
┌——————┬—┐
│測試編號 │ │
├——————┼—┤
│測試標題 │ │
├——————┼—┤
│測試級別 │ │
├——————┼—┤
│對應規格 │ │
├——————┼—┤
│測試預置條件│ │
├——————┼—┤
│測試輸人過程│ │
├——————┼—┤
│測試預期結果│ │
└——————┴—┘
表3缺陷報告
(3)測試報告。它是所有的測試用例通過情況的報告，其
格式如表4所示。測試一般分成三輪，如果第一輪沒有通過，
在第一輪測試完畢後，進行缺陷修訂;然後進行第二輪的測試，
第二輪測試仍舊沒有通過的，或者修改r前面的問題又引出了
新問題，進行第三輪測試。在單元測試報告中還強調一個覆蓋
率，包括代碼覆蓋率和條件覆蓋率。一般覆蓋率報告的生成要
用相應的工其，如用V (:開發程序的單元測試覆蓋率報告就可
藉助C-cover ,True-cover來實現。
表4測試報告
4總結
軟體質量的控制除了上面講到的幾個測試階段外，其實
CMM還非常強調各個設計階段的檢視(Review )工作。編碼完
成後的檢視階段也在軟體質量控制中起著非常有效的、重要的
作用，如果進行了充分的檢視，它可以發現一些在後面要花很
多力氣來檢測出的缺陷。
參考文獻;
川Camegie Melton SoRware Engineering Institute. Software Test Manage-
meat [ EB/OL ].http;//www. lei. emu. e/emm/cmm-v2/test-mgt-
kpa. html, 2003一04.
[ 2 ] IPL Information Pros esaing Ltd. Software Telling and Software Deve-
lopment Lifecycles[EB/OL].lute;//www.iplbath.com,1996-08
[3J軟體工程專家網.軟體測試的組織與管理{EB/OL]. http://
www.5lcmm. c;om/SoftTesting,2003一03.
作者簡介:
楊忠秀( I 974- )，女，碩士研究生，主要研究方向為網路妥全與工程管
理;潘雪增(1945-)，男，博士生導師，主要研究方向為網路安全與網路
資料庫;平玲娣(1946-)，女，博士生導師，主要研究方向為網路安全與
網路教據庫
用例就足夠了;對於返回值對被測試模塊產生影響的樁，則對

I. 系統分析報告該怎麼寫啊

軟體測試分析報告包括內容及大體格式：

1.1編寫目的
說明這份測試分析報告的具體編寫目的，指出預期的閱讀范圍。

1.2背景
說明：

a.被測試軟體系統的名稱；

b.該軟體的任務提出者、開發者、用戶及安裝此軟體的計算中心，指出測試環境與實際運行環境 之間可能存在的差異以及這些差異對測試結果的影響。

1.3定義
列出本文件中用到的專問術語的定義和外文首字母組詞的原片語。

1.4參考資料
列出要用到的參考資料，如：

a.本項目的經核準的計劃任務書或合同、上級機關的批文；

b.屬於本項目的其他已發表的文件；

c.本文件中各處引用的文件、資料，包括所要用到的軟體開發標准。列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。

2測試概要
用表格的形式列出每一項測試的標識符及其測試內容，並指明實際進行的測試工作內容與測試計劃中預先設計的內容之間的差別，說明作出這種改變的原因。

3測試結果及發現
3.1測試1（標識符）
把本項測試中實際得到的動態輸出（包括內部生成數據輸出）結果同對於動態輸出的要求進行比較，陳述其中的各項發現。

3.2測試2（標識符）
用類似本報告3.1條的方式給出第 2項及其後各項測試內容的測試結果和發現。

4對軟體功能的結論
4.1功能1（標識符）
4.1.1能力
簡述該項功能，說明為滿足此項功能而設計的軟體能力以及經過一項或多項測試已證實的能力。

4.1.2限制
說明測試數據值的范圍（包括動態數據和靜態數據），列出就這項功能而言，測試期間在該軟體中查出的缺陷、局限性。

4.2功能2（標識符）
用類似本報告4.l的方式給出第2項及其後各項功能的測試結論。
5分析摘要
5.1能力
陳述經測試證實了的本軟體的能力。如果所進行的測試是為了驗證一項或幾項特定性能要求的實現，應提供這方面的測試結果與要求之間的比較，並確定測試環境與實際運行環境之間可能存在的差異 對能力的測試所帶來的影響。
5.2缺陷和限制
陳述經測試證實的軟體缺陷和限制，說明每項缺陷和限制對軟體性能的影響，並說明全部測得的性能缺陷的累積影響和總影響。
5.3建議
對每項缺陷提出改進建議，如：

a． 各項修改可採用的修改方法；

b． 各項修改的緊迫程度；

c． 各項修改預計的工作量；

d． 各項修改的負責人。

5.4評價
說明該項軟體的開發是否已達到預定目標，能否交付使用。

6測試資源消耗
總結測試工作的資源消耗數據，如工作人員的水平級別數量、機時消耗等。