① 求一份軟體測試的報告，大體上要寫什麼，格式怎麼樣的。求救。我做的是軟體的其中一個模塊。謝謝了。
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. 建議結合系統聯試，開展軟體的確認和系統測試。附件：軟體問題報告單（略）軟體更改通知單（略）軟體測試記錄（略）
② 程序分析怎麼寫
1. 引言
1.1編寫目的:編寫此文檔的目的是進一步定製軟體開發的細節問題,便於用戶與開發商協調工作.本文檔面向的讀者主要是項目委託單位的管理人員.希望能使本軟體開發工作更具體.
1.2項目背景
1.2.1項目委託單位:****公司
1.2.2開發單位:***公司
1.3定義
1.4參考資料
2. 任務概述
2.1目標:
決策支持:根據公司的要求及時提供所需報表及文件,並在適當時候對各部門領導給予銷售及進貨等方面的提示
提高效率:利用軟體進行管理,避免人工管理的失誤以及 延遲性,從而實現高效率的管理.
2.2運行環境:
硬體方面:Pentium級處理晶元
1兆顯存的兼容顯卡
256色,800*600的兼容顯示器
標准兼容列印並絕機
軟體方面: WIN95操作系統
2.3條件與限制:
編程用計算機一台
完成期限2000/7/1
無資金供給
3. 數據概述
數據流程圖如下:
3.1靜態數據:包括系統登錄密碼,各資料庫所在位置,系統分析原始數據
3.2 動態數據:包括各資料庫內各項顯示數據,用戶登錄信息,系統時間
3.3資料庫描述:
人事管理資料庫:公司內人員的個人詳細信息,包括檔案信息
銷售管理資料庫:當日銷售記錄及以前的銷售統計,用於銷售分析
財務管理資料庫:公司內部賬目及收支情況詳表
技術管理資料庫:公司所需各技術檔案的詳細記錄(包括文檔)
3.4 數據字典:
數據流詞條描述:
1.數據流名:登錄信息
來源:用戶的輸入
去向:系統內部檢驗部分
組成:用戶名,密碼
流通量:每次登錄輸入一次
2.數據流名:登錄結果
來源:系統
去向:用戶
組成:返回信息
流通量:每次登錄返回一次
3.數據流名:輸入修改信息
來源:用戶
去向:系統判斷部分
組成:根據各資料庫內容而不同
流通量:依用戶輸入而定
4.數據流名:反饋信息
來源:系統判斷部分
去向:用戶
組成:系統經判斷後發回的字元數據
流通量: 依系統當前信息而定
5.數據流名:識別信息
來源:系統內部檢驗部分
去向:系統判斷部分
組成:系統各資料庫的標識信息
流通量:用戶每次輸入流通一次
6.數據流名:處理信息
來源:系統判斷部分
去向:各資料庫處理部分
組成:讀取/修改標識,讀取/修改的變數名稱
流通量:用戶每次輸入流通一次
7.數據流名:讀取修改
來源:系統判斷部分
去向:系統各資料庫
組成:讀取/修改標識,讀取/修改內容
流通量: 用戶每次輸絕吵姿入流通一次
數據文件詞條描述:
1.數據文件名:人事數據
簡述:存儲人員信息
數據文件組成:人員的各項信息(以CString類型為主)
2.數據文件名:銷售數據
簡述:存儲當日及從前的銷售記錄
數據文件組成:銷售的各項信息
3.數據文件名:財務數據
簡述:存儲財務管理信息
數據文件組成:財務管理的各項記錄
4.數據文件名:技術數據
簡述:存儲公司內部使用的技術檔案信息
數據文件組成:技術檔案名稱,內容
加工邏輯詞條描述:
1.加工名:檢驗
簡要描述:判斷用戶的許可性
輸入數據流碰櫻:登錄信息
輸出數據流:登錄結果
加工邏輯:判斷是否與系統內部用戶信息相符合
2.加工名:判斷
簡要描述:判斷用戶的操作並進行相應的讀取/存儲工作
輸入數據流:輸入修改信息
輸出數據流:反饋信息
加工邏輯:判斷用戶的操作->調用資料庫->讀取/修改->反饋
3.加工名:人事檔案管理
簡要描述:對人事資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息
4.加工名:銷售統計
簡要描述:對銷售資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息
5.加工名:財務統計
簡要描述:對財務資料庫進行相應要求的操作,並與判斷部分交互
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息
6.加工名:技術管理
簡要描述:對技術統計資料庫進行相應要求的操作,並與判斷部分交互信息
輸入數據流:處理信息,讀取修改
輸出數據流: 讀取修改, 處理信息
加工邏輯:判斷用戶要讀取/修改的內容->反饋用戶所需信息
源點及匯點詞條描述:
名稱:用戶
簡要描述:既是源點又是匯點,發出動作信息給"檢驗"和"判斷"加工,通過交互界面接受反饋信息有關數據流:登錄結果,登錄信息,輸入修改信息,反饋信息
數目:一個
4. 功能需求
4.1功能劃分
可細分為四部分:人事管理,銷售管理,財務管理,技術檔案管理
4.2功能描述
人事功能:
(1)能對公司內部的所有人員有關檔案詳細資料記錄並保存。
(2)能對資料庫內人事檔案的數據進行查閱和修改。
(3)能按部門或姓名檢索人員。
(4)當某員工的僱用期限達到整年時，按時提醒。
銷售統計功能
(1)按日對公司的銷售情況進行統計,包括銷售額\銷售數量\各地區銷售比例\不同銷售方式的銷售量比例以及銷售毛利潤情況
(2)制定銷售情況的月報表\季報表以及年報表對銷售情況進行分析,對不同銷售人員的業績進行評定
財務管理功能
(1)協助財務人員進行計算機管理,對庫存情況\進貨情況\銷貨進行登錄和輸出
(2) 根據預設的庫存情況提醒進貨
(3) 對收款情況進行統計,在應收帳款達到預設值時進行提示
技術管理功能
(1)對技術資料進行登錄
(2)對維修記錄進行登錄和統計,按不同型號的機器進行故障整體分析,並作出分析報告
(3)對維修配件的需求進行管理並及時提示備貨
5. 性能需求
5.1數據精確度:因為此數據為公司內部數據,所以要求不能有誤差
5.2時間特性:當日銷售統計要求有即時性,馬上能反應出存貨的問題;同時財務管理數據計算當前存貨情況,並對進貨情況進行估算
5.3 適應性:此軟體只在公司內部管理人員的機器上使用,因此不考慮適應性
6. 運行需求
6.1用戶界面:
屏幕格式:
(1)要求有菜單及工具欄以方便操作
(2)各資料庫信息可在屏幕上直接修改
(3)各數據統計結果可在屏幕上顯示
(4)進行系統分析後的結果在另一窗口中顯示
報表格式:
(1)人事管理報表只要求有個人的普通數據
(2)銷售統計報表要求可分別列印當日統計或之前的統計
(3)財務統計報表要求列印出存貨及公司帳務詳表
(4)技術管理報表要求可以分別列印技術檔案總表和任一技術檔案文檔內容菜單格式:要求菜單項大致與WIN95標准相同,另外附加的功能做到新的單項中輸入輸出時間:年份以4位數字表示
6.2硬體介面:需要標准列印機介面進行報表列印
6.3 軟體介面:Windows標准介面
7. 其他需求
可使用性:要求容易使用,界面友好
安全保密性:因本數據屬於公司內部管理用關鍵數據,因此除公司管理人員外,其他人員不得訪問.要求設有登錄密碼檢驗功能,並且此密碼可以在以後進行修改
可維護性:要求本軟體的維護文檔齊全,便於維護
③ 軟體測試報告怎麼寫
測試分析報告
1
引言
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測試資源消耗
總結測試工作的資源消耗數據，如工作人員的水平級別數量、機時消耗等。
④ 軟體測試報告怎麼寫
摘要
測試報告是把測試的過程和結果寫成文檔，並對發現的問題和缺陷進行分析，為糾正軟體的存在的質量問題提供依據，同時為軟體驗收和交付打下基礎。本文提供測試報告模板以及如何編寫的實例指南。
關鍵字
測試報告 缺陷
正文
測試報告是測試階段最後的文檔產出物，優秀的測試經理應該具備良好的文檔編寫能力，一份詳細的測試報告包含足夠的信息，包括產品質量和測試過程的評價，測試報告基於測試中的數據採集以及對最終的測試結果分析。
下面以通用的測試報告模板為例，詳細展開對測試報告編寫的具體描述。
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測試方法(和工具)
簡要介紹測試中採用的方法(和工具)。
提示：主要是黑盒測試，測試方法可以寫上測試的重點和採用的測試模式，這樣可以一目瞭然的知道是否遺漏了重要的測試點和關鍵塊。工具為可選項，當使用到測試工具和相關工具時，要說明。注意要註明是自產還是廠商，版本號多少，在測試報告發布後要避免大多工具的版權問題。
⑤ 面向百度編程之-測試報告
官方網站在這里： http://extentreports.relevantcodes.com/
當年github上開源，如今pro版本居然收錢了
先說總結：
1. 生成的報告簡潔美觀，
2.生成的單html方便jenkins集成發郵件
3.自帶集中展示歷史報告的服務端
4.支持java，
5.可定製報告
6.數據入庫
官網提供V2.x版本和V3.x版本，只支持java8。注意
客戶端地址： https://github.com/anshooarora/extentreports-java/commits/master
服務端地址： https://github.com/anshooarora/extentx
安裝過程，官方文檔上比較消息。
官方說明在這里： http://extentreports.com/docs/versions/3/java/ ， 提供了3種和testng集成示例：
1.直接在 @ BeforeSuite 和 @ BeforeClass 進行初始化
2.自己實現testng的ITestListener介面，監聽的適合你已經有測試狂簡了，不想動原來的case
3.自己實現testng的IReporter介面，更加直觀
以上隨便選擇一種都可以，實現ITestListener介面。內容類似下面：
onTestFailure函數裡面實現了出錯自動截圖，調用的是ExtentTest的addScreenCaptureFromPath方法。
ExtentManager用來做初始化：
ExtentXReporter構造函數里填的是mongodb的地址和埠。
在res/testng.xml裡面注冊這個監聽器，測試類也寫上：
測試類調用，隨便寫2個case演示：macaca是阿里的自動化框架，也不錯的，可以直接刪除也行，內容罷了
運行命令
開始測試
生成的本地報告在test-output下面，內容類似下面：
最下面可以看到失敗的截圖：
看看服務端的報告（運行了多次）：
匯總頁面：
這里的PROJECT和BUILD是ExtentManager類裡面
這里設定的，這里實際使用時可以用jenkins集成時直接由jenkins傳進來
具體某一次的報告：
如果覺得這種報告太笨重了，可以看下這種
https://www.jianshu.com/p/ce09d3bd1c37
輕量級別的
ps：所有酷炫的測試報告，都不適合發郵件，因為內容太多了
適合發郵件的模板去掉各種渲染
⑥ C語言實驗報告怎麼寫實驗步驟高手最好給個樣板啊！
．實驗報告規范
實驗報告內容包括：
1.實驗目的：說明實驗所驗證的知識點。
2.需求分析：以無歧義的陳述說明程序設計的任務、約束條件、輸入輸出要求、對功能的規定及模型。
3.邏輯設計：說明本程序中用到的所有抽象數據類型的定義、主程序的流程以及各程序模塊之間的層次調用關系。
4.詳細設計：邏輯設計中定義的所有數據類型的實現，核心演算法的設計描述、人機界面設計、函數之間調用關系的描述，主要功能的演算法框架，測試數據設計。
5.測試分析：測試結果的分析與討論，測試過程中遇到的主要問題及採取的解決措施。
6.心得：軟體設計與實現過程中的經驗與體會，進一步改進的設想。
7.程序清單：源程序中應有足夠的注釋。如果提交源程序軟盤，列出程序文件名。