1. 軟體工程里，軟體測試報告怎麼寫
給你一個參考
GB/T 8567 計算機軟體文檔編制規范
2. 剛開始學軟體測試，可是公司要每個人寫軟體測試報告，怎麼寫
看《軟體測試實用技術與常用模板》這本書，裡面有好幾十個測試模板。
3. 軟體測試報告怎麼寫
摘要
測試報告是把測試的過程和結果寫成文檔，並對發現的問題和缺陷進行分析，為糾正軟體的存在的質量問題提供依據，同時為軟體驗收和交付打下基礎。本文提供測試報告模板以及如何編寫的實例指南。
關鍵字
測試報告 缺陷
正文
測試報告是測試階段最後的文檔產出物，優秀的測試經理應該具備良好的文檔編寫能力，一份詳細的測試報告包含足夠的信息，包括產品質量和測試過程的評價，測試報告基於測試中的數據採集以及對最終的測試結果分析。
下面以通用的測試報告模板為例，詳細展開對測試報告編寫的具體描述。
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測試方法(和工具)
簡要介紹測試中採用的方法(和工具)。
提示：主要是黑盒測試，測試方法可以寫上測試的重點和採用的測試模式，這樣可以一目瞭然的知道是否遺漏了重要的測試點和關鍵塊。工具為可選項，當使用到測試工具和相關工具時，要說明。注意要註明是自產還是廠商，版本號多少，在測試報告發布後要避免大多工具的版權問題。
4. 怎麼寫軟體測試報告
主要說明測試了軟體的什麼功能 用到了一些什麼方法 以及這個軟體的不足之處 有待完善的地方
5. 求軟體測試的報告怎麼寫~（游戲測試）
沒做過游戲測試，不過應該和其他軟體的測試報告區別不大的，要點就那麼幾個：
1、測試對象描述
2、測試范圍
3、測試環境
4、測試工具
5、測試方法
6、測試結果（功能測試結果和性能測試結果）
7、測試總結
6. 軟體測試報告（範文）
測試數據測試項總數 0 PASS 0 PASS率 #DIV/0! FAIL 0 FAIL率 #DIV/0! 嚴重度——高 0 其中：高-- #DIV/0! 嚴重度——中 0 中-- #DIV/0! 嚴重度——低 0 低-- #DIV/0! 測試項編號 測試項 通過與否 問題描述 問題嚴重度註： 問題嚴重度的界定：高——導致系統死機或後續部分測試項功能不能實現；中——影響該部分的測試功能的完整性且急需解決；低——僅屬於系統中的小bug，或根據測試過程發現的需要調整的部分，但並非急需解決。
7. 測試報告怎麼寫
1 簡介1.1編寫目的本測試報告為安天科技項目的測試報告，目的在於總結測試階段的測試以及分析測試結果，描述系統是否符合ATKJ-用戶需求說明書。預期參考人員包括用戶、測試人員、開發人員、項目管理者、質量管理人員和需要閱讀本報告的高層經理。TestAge 中國軟體測試時代!T/d5s P Al 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"_IS 主要測試人員：李志學 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表示不可測試或者用例不適用。▲表示為測試重點部分。DdSa6} 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%
8. 怎麼 寫軟體測試反饋報告
個人歸納以下幾點:1:首先對項目bug分布情況做個分析;Bug分布Bug總數備注嚴重重大一般輕微 Bug合計 2:測試周期;(實際測試時間與估測時間)3:後期項目建議(實用性,規范性等);3:項目評審結果;
9. 軟體測試報告例文
以前寫的東西 省略著寫
XX軟體測試報告 共 x 頁 擬制 年 月 日審核 年 月 日會簽 年 月 日批准 年 月 日
1 范圍本文檔適用於XX軟體的單元/集成測試。1.2 系統概述1.3 文檔概述本文檔用於對XX軟體的測試工作階段成果的描述。包括對軟體測試的整體描述，軟體測試的分類和級別，軟體測試的過程描述，軟體測試的結果等內容。2 引用文檔《XX軟體需求規格說明》《XX軟體設計說明》《XX系統介面協議》3 測試概述3.1被測軟體的基本概況使用的編程語言：XXX 匯編語言程序行數：1590子程序個數：11單行注釋行數：669注釋率：約為42%3.1.1. 測試小結本次測試對XX軟體進行了靜態分析和動態測試。測試工作分為兩個階段。第一階段進行了軟體靜態分析，軟體測試人員和開發人員分別對軟體V1.00版本的代碼進行走讀。在此基礎上軟體開發人員對代碼走查中發現的問題進行了修改，做了97處代碼變更並提交了V1.01版本進行動態測試。在測試過程中針對發現的軟體缺陷進行了初步分析，並提交程序設計人員對原軟體中可能存在的問題進行考查。在軟體測試中首先根據軟體測試的規范進行考核，將書寫規范，注釋等基礎問題首先解決，其次考核軟體測試中的問題是否存在設計上的邏輯缺陷，如果存在設計缺陷則應分析該缺陷的嚴重程度以及可能引發的故障。軟體開發人員在以上基礎上對軟體的不足做出相應的修改，同時通過軟體回歸測試驗證軟體修改後能夠得到的改善結果。 軟體代碼1.00與1.01版變更明細表： 編號 1.00版行號 1.01版行號 更改說明 1 19 22 注釋變更 2 26 29 注釋變更 3 29 32 注釋變更 4 95 98 注釋變更 5 108行後 113～116 增加新變數 6 171、172 180、181 命令字大小寫變更 7 以下略 從上表可以看出，注釋變更一共有15處，主要排除了對原程序的理解錯誤問題；根據程序的書寫規范要求，一行多條語句改為一行一條語句的更改一共有42處；命令字大小寫變更一共有7處；在代碼走查中對冗餘和無用的代碼作了更改，將這些代碼注釋掉，此類更改一共有14處。上述4類更改一共有78處，這些更改對程序本身的功能沒有任何影響，但從軟體規范的角度來看提高了程序的可讀性和規范性。其餘19處變更為代碼變更，主要是在軟體測試中發現原程序的可靠性不足，在不改變原程序功能的基礎上相應的增加了新變數、新語句、新程序以提高整個程序的可靠性。在動態測試階段進行了單元測試和集成測試。此階段發現的軟體問題經軟體測試人員修改，提交了V1.02版本，軟體測試人員對此版本的軟體代碼進行了回歸測試，確認對前階段發現的軟體問題進行了修改，消除了原有的軟體問題並且確認沒有引入新的軟體問題。認定V1.02版為可以發行的軟體版本。3.1.1.1 靜態分析小結靜態測試採用人工代碼走查的方式進行。參加代碼走查的軟體開發人員有：（略）；參加代碼走查的軟體測試人員有：（略）。代碼走查以代碼審查會議的形式進行。靜態分析過程中共進行了四次會議審查。靜態測試階段的主要工作內容是：l 根據對軟體匯編源代碼的分析繪制詳細的程序流程圖和調用關系圖（見附件1）；l 對照軟體匯編源代碼和流程圖進行程序邏輯分析、演算法分析、結構分析和介面分析；l 對軟體匯編源代碼進行編程規范化分析。通過靜態測試查找出軟體的缺陷18個，其中輕微的缺陷4個，占所有缺陷的22.2％中等的缺陷11個，占所有缺陷的61.1％嚴重的缺陷：3個，占所有缺陷的16.7％上述軟體缺陷見附件《軟體問題報告單》3.1.1.2 動態測試小結動態測試使用的測試工具為XXX軟體集成開發環境。總共的測試用例數：143個。全部由測試人員人工設計。其中單元測試用例138個，集成測試用例5個。發現的軟體缺陷有2個，都是在單元測試過程中發現的。集成測試階段未發現新的軟體缺陷。在發現的軟體缺陷中：中等的缺陷1個，占所有缺陷的50％嚴重的缺陷1個，占所有缺陷的50％上述軟體缺陷見附件《軟體問題報告單》動態測試中代碼覆蓋率：代碼行覆蓋率 100%分支覆蓋率 100%程序單元調用覆蓋率 100％3.1.1.3 回歸測試小結對軟體測試過程中發現的缺陷經軟體開發人員確認後進行了代碼更改，並對更改後的代碼進行了回歸測試。本報告中的數據是回歸測試後的測試數據。3.1.1.4 測試分析下面將對此次軟體測試中的所有缺陷以及改進設計進行分析。1． 靜態測試中的缺陷分析： 1） 4個輕微缺陷屬於代碼冗餘，由於在程序設計中加入了部分調試程序，在程序設計完成後未將這些調試代碼注釋或刪除掉而造成代碼冗餘，但對程序本身的功能並無影響。修改後程序的效率得到提高。2） 11個中等缺陷屬於注釋變更，在原程序代碼的注釋中存在注釋不準確的問題，會影響程序員對程序的理解，修改後的程序提高了程序的可讀性。3） 重點分析3個嚴重缺陷：第一個嚴重缺陷屬於XX號的無效判別和相應的處理問題，程序對XX號進行無效判別時，判別界限並不完全，在本跟蹤程序中XX號的有效數為01-10（用4位表示），而判別無效時只判了為00的情況，沒有判別大於10的情況。而且在為00時也沒有作相應的處理，修改後的程序對設計進行了改進，詳見改進設計分析3。第二個嚴重缺陷屬於程序設計中讀取地址錯誤問題，經分析在調試中讀取的數據是正確的，但是讀取的地址與設計初衷不相符，修改後問題得到了解決，詳見改進設計分析1。第三個嚴重錯誤是近區/遠區子程序判斷與進入條件反了，經分析對程序的影響不大，但與設計初衷不一致，修改後問題得到了解決，詳見改進設計5。2． 動態測試中的缺陷分析：1） 中等缺陷1個，在程序的注釋中出現錯誤，將近區注釋為遠區，修改後問題得到了解決，提高了程序的可讀性。2） 嚴重缺陷1個，在XX號無效的判別中，本應判斷大於10，但誤設計為0，修改後經回歸測試問題得到了解決。 3． 改進的設計分析：（因和產品相關，略） 3.1.2 測試記錄a 測試時間：2005年8月5日至2005年9月17日。b 地點：（略）。c 硬體配置：P4CPU/2.0G，內存256M，硬碟1Gd 軟體配置：Wondows98，e 被測軟體版本號：V1.0，V1.01，V1.02f 所有測試相關活動的日期和時間、測試操作人員等記錄見軟體測試記錄文檔。4 測試結果在兩個階段測試過程中共發現軟體缺陷20個，經軟體開發人員確認的缺陷為20個，經過改正的代碼消除了所有以確認的軟體缺陷並通過了回歸測試。因測試條件所限，未能進行軟體的確認測試和系統測試。5 評估和建議5.1 軟體評估 5.1.1 軟體編碼規范化評估經過回歸測試，未殘留的軟體編碼規范性缺陷。軟體代碼文本注釋率約為42%，代碼注釋充分，有利與代碼的理解和維護。5.1.2 軟體動態測試評估被測軟體單元的總數：11個使用的測試用例個數：143個達到軟體測試出口准則的軟體單元數為11個，通過率100％通過單元和集成測試得知：軟體代碼邏輯清晰、結構合理、程序單元間介面關系一致，運行穩定。5.2 改進建議a. 建議在軟體開發項目中全面實施軟體工程化，加強軟體開發的管理工作。b. 建議進一步加強軟體需求規格說明、軟體設計文檔編制以及編寫代碼的規范化。特別是應該將系統中的硬體研製和軟體研製分別管理，軟體文檔編制的種類和規格按照相關標准執行。c. 盡早開展軟體測試工作。在軟體研製計劃安排上給軟體測試留有必要的時間，在資源配置上給軟體測試必要的支撐。d. 建議結合系統聯試，開展軟體的確認和系統測試。附件：軟體問題報告單（略）軟體更改通知單（略）軟體測試記錄（略）
10. 游戲軟體測試報告怎麼寫
評測的主要內容：
1.操作性評測：即畫面的質理，滑鼠鍵盤的操作等方面
2.功能性評測：即是否達到游戲運營商所宣傳的功能，
如:人物飛天功能，需測試人物飛天功能在何時3能觸發，
飛行的感覺及飛行時的輔帶情況。
3.性能評測：即游戲的運行速度及測試機型－每秒FPS，
CPU佔用率，內存使用率等。
4.游戲特點：即列出所評測游戲的具體特點，適合的年齡
層次、性別、公會進駐的優劣。
5.其它：如網游的BUG，自己在游戲中的經驗（可省）
具體測試工具，如測每秒幀數可直接在網上搜索即得。
一篇測評文章需要對各類評測內容進行評分，而評分的方式多種多樣，但老K在這里也希望有一個評分規定，這需要各位能仔細思考下做一個綜合評定標准。可能適合DW公會這一塊佔比例較大，其它各占其中。