第一篇：第三方軟件測試報告

第三方軟件測試報告（暫定）

1.引言 1.1.編寫目的

本文檔作為該系統(tǒng)測試的測試標準，內(nèi)容關系到本次系統(tǒng)測試可能涉及到的測試內(nèi)容和測試技術解決方案。

1.2.系統(tǒng)概述

略

2.測試描述 2.1.測試范圍與內(nèi)容

我方（北京圓規(guī)創(chuàng)新公司）對XX公司“XX”項目進行測試，保證使用方的功能正確，保證系統(tǒng)核心模塊的穩(wěn)定和安全，為項目的驗收提供參考。以此，本計劃列出了在此次功能測試過程中所要進行的內(nèi)容和實施的方案及測試資源的安排，作為測試活動的依據(jù)和參考。

本次測試的對象為XX公司“XX”項目，測試范圍為：略。本次測試的主要內(nèi)容有功能測試（含容錯測試）、易用性測試。

2.2.測試依據(jù)

本次測試所依據(jù)的文檔包含開發(fā)方提供的《需求規(guī)格說明書》、《操作手冊》、《用戶手冊》，《維護手冊》，《設計文檔》等相關開發(fā)文檔。并依據(jù)IT行業(yè)項目的通用標準，包括功能測試標準、缺陷標準、易用性標準。對于項目的易用性標準，原則上由測試方提出易用性問題修改的建議，由開發(fā)方對測試方提交的問題進行確認。

3.測試解決方案

我公司針對用戶方提出的測試要求，根據(jù)以往項目的實際經(jīng)驗，撰寫測試技術解決方案。該解決方案包含了本次系統(tǒng)測試可能涉及到的測試類型，并分別介紹不同測試類型的內(nèi)容和相關標準。

3.1.系統(tǒng)功能測試

實施系統(tǒng)功能測試，完成對被測系統(tǒng)的功能確認。

采用黑盒測試方法，根據(jù)需求規(guī)格說明書和用戶手冊，將功能點轉(zhuǎn)換為功能測試需求，根據(jù)測試需求編寫測試用例，保證所有功能點必須被測試用例覆蓋。

測試用例的編寫采用基于場景的測試用例編寫原則，便于以使用者的角度進行測試。用例設計上兼顧正常業(yè)務邏輯和異常業(yè)務邏輯。測試數(shù)據(jù)的選取可采用GUI測試，等價類劃分、邊界值分析、錯誤推測、比較測試等測試方法中的一種或者幾種數(shù)據(jù)的組合，一般以等價類劃分和邊界值法為主。

3.1.1.系統(tǒng)功能項測試

對《軟件需求規(guī)格說明書》中的所有功能項進行測試（列表）；

3.1.2.系統(tǒng)業(yè)務流程測試

對《軟件需求規(guī)格說明書》中的典型業(yè)務流程進行測試（列表）；

3.1.3.系統(tǒng)功能測試標準

? 可測試的功能點100％作為測試需求（如未作為測試需求，必須在測試計劃中標注原因并通知用戶方負責人）； ? 測試需求100％被測試用例覆蓋；

? 測試用例100％被實施（如未實施，在測試報告中標注未測試的原因并通知用戶方負責人）；

? 含有一類缺陷的系統(tǒng)不建議上線發(fā)布（缺陷嚴重等級見附錄，需確認）； ? 含有二類缺陷的系統(tǒng)不建議上線發(fā)布（缺陷嚴重等級見附錄，需確認）； ? 含有三類缺陷10個以上不建議上線發(fā)布（缺陷嚴重等級見附錄，需確認）； ? 權限矩陣測試覆蓋率100％。

3.2.易用性測試

本系統(tǒng)的易用性測試不是本次測試的重點。我方的原則是在測試過程中如果發(fā)現(xiàn)有完全不符合IT行業(yè)習慣的操作、完成一次業(yè)務過多操作步驟和彈出窗口、界面顏色嚴重影響閱讀、提示信息過于復雜或者簡單、業(yè)務邏輯完全不符合思維邏輯的情況下，我方測試人員會提出易用性類型的缺陷，此類缺陷由用戶方最終確認。

易用性測試的內(nèi)容包括: 軟件的用戶界面是否友好，是否出現(xiàn)中英文混雜的界面；

軟件中的提示信息是否清楚、易理解，是否存在原始的英文提示；

軟件中各個模塊的界面風格是否一致；

軟件中的查詢結果的輸出方式是否比較直觀、合理。

3.3.容錯測試

本系統(tǒng)的容錯測試不是本次測試的重點。我方的原則是在測試的過程中檢查對系統(tǒng)對非常規(guī)操作或業(yè)務流程的容錯性處理，是否影響系統(tǒng)的正常運行，是否給與用戶明確的提示信息等，此類缺陷由用戶方最終確認。

容錯測試的檢查內(nèi)容包括: 軟件對用戶常見的誤操作是否能進行提示；

軟件對用戶的的操作錯誤和軟件錯誤，是否有準確、清晰的提示；

軟件對重要數(shù)據(jù)的刪除是否有警告和確認提示；

軟件是否能判斷數(shù)據(jù)的有效性，屏蔽用戶的錯誤輸入，識別非法值，并有相應的錯誤提示。

3.4.安全性測試

如用戶方有明確的安全測試需求，可根據(jù)用戶實際情況，進行安全性測試。安全性測試的檢查內(nèi)容包括: 軟件中的密鑰是否以密文方式存儲；

軟件是否有留痕功能, 即是否保存有用戶的操作日志；

軟件中各種用戶的權限分配是否合理；

3.5.性能測試

對軟件需求規(guī)格說明書中明確的軟件性能進行測試。測試的準則是要滿足規(guī)格說明書中的各項性能指標（需明確說明）。

3.6.適應性測試

參照用戶的軟、硬件使用環(huán)境和需求規(guī)格說明書中的規(guī)定，列出開發(fā)的軟件需要滿足的軟、硬件環(huán)境（包括服務器環(huán)境、客戶端環(huán)境）。對部署環(huán)境進行測試（需明確說明）。

3.7.文檔測試

用戶文檔包括: 安裝手冊、操作手冊和維護手冊（需明確說明）。對用戶文檔測試的內(nèi)容包括: 操作、維護文檔是否齊全、是否包含產(chǎn)品使用所需的信息和所有的功能模塊；

用戶文檔描述的信息是否正確, 是否沒有歧義和錯誤的表達；

用戶文檔是否容易理解, 是否通過使用適當?shù)男g語、圖形表示、詳細的解釋來表達；

用戶文檔對主要功能和關鍵操作是否提供應用實例；

用戶文檔是否有詳細的目錄表和索引表；

文檔描述與程序當前版本符合

3.8.用戶有特別要求的測試

用戶對于系統(tǒng)是否有特別的要求（需明確說明）

4.預期提交文檔

本次系統(tǒng)測試可能提交的文檔包括《測試需求》、《測試計劃》、《測試用例》、《測試報告》等。其中測試計劃、報告等根據(jù)測試回歸次數(shù)而產(chǎn)生多份。

4.1.測試需求文檔

首先完成測試需求的整理，閱讀項目功能性說明的相關文檔，挑選出可以測試的功能點，完成測試需求的整理。

4.2.測試用例文檔

測試需求作為今后測試活動的指導和目標，且為測試工作量的估算提供可計算的依據(jù)。我方制定測試需求后將測試需求提交相關人員進行審查。通過之后，將根據(jù)測試需求完成功能性測試用例的編寫。

4.3.測試日志文檔

測試用例設計完成之后，我方將測試用例提交給相關各方評審。評審通過后測試人員按照測試用例實施測試。測試人員在實施測試的時候，將每日填寫測試日志。

4.4.測試報告

完成一次完整的功能測試之后，我方將匯總?cè)毕?，完成測試報告。

5.測試工作流程 5.1.測試啟動

開發(fā)方提供項目相關文檔，包括《需求規(guī)格說明書》、《設計文檔》、《用戶手冊》等相關文檔；

開發(fā)方搭建測試環(huán)境，提供必要的軟、硬件； 開發(fā)方進行系統(tǒng)講解，完成對測試方的培訓； 測試方閱讀相關文檔并學習使用被測系統(tǒng)；

測試方對依據(jù)的文檔中的不足提出意見，由開發(fā)方補充完善文檔。

5.2.測試準備

測試方制定必要的標準，提交開發(fā)方和用戶方審閱； 測試方整理測試需求，提交開發(fā)方和用戶方審閱； 測試方書寫測試計劃，提交開發(fā)方和用戶方審閱；

測試方編寫測試用例，開發(fā)測試腳本，可提交開發(fā)方和用戶方審閱； 5.3.測試實施

測試方按照測試計劃，按照設計的測試用例實施測試，記錄測試過程中的問題。測試方每日完成測試日志，并將測試日志提交開發(fā)方和用戶方。

5.4.測試總結

測試方對每次回歸測試提交缺陷列表，編寫測試報告。

6.三方職責分工

測試過程中需要開發(fā)方精悍有素的人員的大力支持與配合，并且為測試方提供現(xiàn)場技術支持。開發(fā)方有義務配合測試方完成本次的系統(tǒng)測試，并提供必要的支持工作。

由于測試階段的根本目標是盡可能多發(fā)現(xiàn)并排除軟件中潛藏的錯誤，最終把一個高質(zhì)量的軟件系統(tǒng)交給用戶使用，因此用戶方在測試階段的直接參與、指正和確認起著十分重要的作用。開發(fā)方需要有專人負責本次系統(tǒng)測試工作，組織測試現(xiàn)場和相關硬件設備，溝通和協(xié)調(diào)各方關系。

測試方嚴格按照軟件工程理論進行測試，提供專業(yè)測試人員和必要的測試工具，并以用戶方的根本利益為工作原則指導。

7.附錄

7.1.軟件錯誤的嚴重性等級

7.1.1.Critical：1級錯誤

這一級別的錯誤一般包括以下內(nèi)容: ? 沒有實現(xiàn)或錯誤地實現(xiàn)重要的功能； ? 業(yè)務流程存在重大隱患；

? 軟件在操作過程中由于軟件自身的原因自動退出系統(tǒng)或出現(xiàn)死機的情況；

? 軟件在操作過程中由于軟件自身的原因?qū)ο到y(tǒng)或數(shù)據(jù)造成破壞； ? 在現(xiàn)有的軟、硬建設環(huán)境下不能實現(xiàn)應有的功能； ? 特殊軟件在操作過程中可能危及系統(tǒng)和人身安全等。

7.1.2.Major：2級錯誤

這一級別的錯誤一般包括以下內(nèi)容: ? 沒有實現(xiàn)基本功能，并且不存在替代辦法；

? 沒有實現(xiàn)重要功能中的部分功能，并且不存在替代辦法； ? 業(yè)務流程銜接錯誤； ? 用戶的權限分配不合理； ? 不可繼續(xù)使用的異常錯誤；

? 系統(tǒng)不明原因資源占用增大,導致性能不斷下降； ? 界面與需求不符；

7.1.3.Averagte：3級錯誤

這一級別的錯誤一般包括以下內(nèi)容: ? 沒有實現(xiàn)基本功能，但存在替代辦法；

? 沒有實現(xiàn)重要功能中的部分功能，但存在替代辦法； ? 可繼續(xù)使用的異常錯誤； ? 提示信息存在錯誤

7.1.4.Minor：4級錯誤

這一級別的錯誤通常為易用性方面的錯誤： ? 界面不友好、前后風格不一； ? 中英文混雜；

? 查詢結果輸出不直觀；

? 錯別字，提示信息輕微錯誤； ? 界面控件缺陷； ? 快捷鍵錯誤；

7.1.5.Enhancement：5級錯誤

通常為不影響正常使用下的用戶方提出的改進性建議，或者文檔方面的錯誤。

? 界面調(diào)整

? 功能改進調(diào)整建議

? 顏色,字體,圖像等不合適 ? 基本操作過于復雜

? 使用手冊與功能不符（功能使用正常）

第二篇：軟件測試報告格式

軟件測試報告模板

XXX公司

XXX（產(chǎn)品或軟件）/XXX（模塊）測試報告

1.概述

測試目的 簡述本次測試的目的，如：驗證某模塊是否符合設計

項目背景 簡述測試所在項目的背景，如：XXX（項目）目前進入什么階段，以及其他信息

2.測試環(huán)境

硬件環(huán)境 僅針對測試對象的硬件環(huán)境及其版本信息加以說明軟件環(huán)境 僅針對測試對象的軟件環(huán)境及其版本信息加以說明

3.測試人員

人員

角色

4.實際進度

占用時間 描述整個測試過程的時間跨度，如：xxxx-xx-xx至xxxx-xx-xx進度情況 原因 如果測試提前或延后完成，請說明具體原因

5.測試參考文檔

《XXX測試計劃》

《XXX測試用例》

《文檔三》

《文檔四》

版本信息 V1.0

6.測試數(shù)據(jù)

測試數(shù)據(jù)

測試項總數(shù) 0

PASS 0 PASS率 #DIV/0!

FAIL 0 FAIL率 #DIV/0!

嚴重度——高 0 其中：高--#DIV/0!

嚴重度——中 0 中--#DIV/0!

嚴重度——低 0 低--#DIV/0!

測試項編號 測試項 通過與否 問題描述 問題嚴重度

注： 問題嚴重度的界定：

高——導致系統(tǒng)死機或后續(xù)部分測試項功能不能實現(xiàn)；中——影響該部分的測試功能的完整性且急需解決；

低——僅屬于系統(tǒng)中的小bug，或根據(jù)測試過程發(fā)現(xiàn)的需要調(diào)整的部分，但并非急需解決。

7.項目的總結 對整個測試項目進行總結性闡述，如：測試是否通過，導致FAIL的主要原因。

8.意見和建議 針對本次測試工作，提出自己的意見或建議。沒有可填“無”。

第三篇：軟件測試報告1.0

測試報告模板1.0

目錄 測試報告模板............................................................................................................1 簡介..........................................................................................................................2 1.1 編寫目的........................................................................................................2 1.2 1.3 1.4 1.5 2 2.1 2.2 3 項目背景........................................................................................................2 系統(tǒng)簡介........................................................................................................2 術語和縮寫詞.................................................................................................2 參考資料........................................................................................................2 測試用例設計.................................................................................................3 測試環(huán)境與配置..............................................................................................3 測試概要...................................................................................................................2 2.3 測試方法(和工具)...........................................................................................3 測試結果及缺陷分析.................................................................................................3 3.1 3.2 測試執(zhí)行情況與記錄.......................................................................................4 覆蓋分析........................................................................................................5 4 5 3.3 缺陷的統(tǒng)計與分析..........................................................................................5 測試結論...................................................................................................................6 建議..........................................................................................................................6

簡介

1.1 編寫目的

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

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

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

1.2 項目背景

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

1.3 系統(tǒng)簡介

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

1.4 術語和縮寫詞

列出設計本系統(tǒng)/項目的專用術語和縮寫語約定。對于技術相關的名詞和與多義詞一定要注明清楚，以便閱讀時不會產(chǎn)生歧義。

1.5 參考資料

1．需求、設計、測試用例、手冊以及其他項目文檔都是范圍內(nèi)可參考的東東。2．測試使用的國家標準、行業(yè)指標、公司規(guī)范和質(zhì)量手冊等等 測試概要

測試的概要介紹，包括測試的一些聲明、測試范圍、測試目的等等，主要是測試情況簡介。（其他測試經(jīng)理和質(zhì)量人員關注部分）2.1 測試用例設計

簡要介紹測試用例的設計方法。例如：等價類劃分、邊界值、因果圖，以及用這類方法(3-4句)。提示：如果能夠具體對設計進行說明，在其他開發(fā)人員、測試經(jīng)理閱讀的時候就容易對你的用例設計有個整體的概念，順便說一句，在這里寫上一些非常規(guī)的設計方法也是有利的，至少在沒有看到測試結論之前就可以了解到測試經(jīng)理的設計技術，重點測試部分一定要保證有兩種以上不同的用例設計方法。

2.2 測試環(huán)境與配置

簡要介紹測試環(huán)境及其配置。

提示：清單如下，如果系統(tǒng)/項目比較大，則用表格方式列出 數(shù)據(jù)庫服務器配置 CPU： 內(nèi)存：

硬盤：可用空間大小 操作系統(tǒng)： 應用軟件： 機器網(wǎng)絡名： 局域網(wǎng)地址： 應用服務器配置 …….客戶端配置 …….對于網(wǎng)絡設備和要求也可以使用相應的表格，對于三層架構的，可以根據(jù)網(wǎng)絡拓撲圖列出相關配置。

2.3 測試方法(和工具)

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

提示：主要是黑盒測試，測試方法可以寫上測試的重點和采用的測試模式，這樣可以一目了然的知道是否遺漏了重要的測試點和關鍵塊。工具為可選項，當使用到測試工具和相關工具時，要說明。注意要注明是自產(chǎn)還是廠商，版本號多少，在測試報告發(fā)布后要避免大多工具的版權問題。測試結果及缺陷分析

整個測試報告中這是最激動人心的部分，這部分主要匯總各種數(shù)據(jù)并進行度量，度量包括對測試過程的度量和能力評估、對軟件產(chǎn)品的質(zhì)量度量和產(chǎn)品評估。對于不需要過程度量或者相對較小的項目，例如用于驗收時提交用戶的測試報告、小型項目的測試報告，可省略過程方面的度量部分；而采用了CMM/ISO或者其他工程標準過程的，需要提供過程改進建議和參考的測試報告－主要用于公司內(nèi)部測試改進和缺陷預防機制－則過程度量需要列出。3.1 測試執(zhí)行情況與記錄

描述測試資源消耗情況，記錄實際數(shù)據(jù)。（測試、項目經(jīng)理關注部分）

3.1.1 測試組織

可列出簡單的測試組架構圖，包括：

測試組架構（如存在分組、用戶參與等情況）測試經(jīng)理（領導人員）主要測試人員 參與測試人員

3.1.2 測試時間

列出測試的跨度和工作量，最好區(qū)分測試文檔和活動的時間。數(shù)據(jù)可供過程度量使用。例如 XXX子系統(tǒng)/子功能 實際開始時間－實際結束時間 總工時/總工作日

任務 開始時間 結束時間 總計

合計

對于大系統(tǒng)/項目來說最終要統(tǒng)計資源的總投入，必要時要增加成本一欄，以便管理者清楚的知道究竟花費了多少人力去完成測試。

測試類型 人員成本 工具設備 其他費用

總計

在數(shù)據(jù)匯總時可以統(tǒng)計個人的平均投入時間和總體時間、整體投入平均時間和總體時間，還可以算出每一個功能點所花費的時/人。用時人員 編寫用例 執(zhí)行測試 總計

合計

這部分用于過程度量的數(shù)據(jù)包括文檔生產(chǎn)率和測試執(zhí)行率。生產(chǎn)率人員 用例/編寫時間 用例/執(zhí)行時間平均

合計

3.1.3 測試版本

給出測試的版本，如果是最終報告，可能要報告測試次數(shù)回歸測試多少次。列出表格清單則便于知道那個子系統(tǒng)/子模塊的測試頻度，對于多次回歸的子系統(tǒng)/子模塊將引起開發(fā)者關注。3.2 覆蓋分析

3.2.1 需求覆蓋

需求覆蓋率是指經(jīng)過測試的需求/功能和需求規(guī)格說明書中所有需求/功能的比值，通常情況下要達到100％的目標。

需求/功能（或編號）測試類型 是否通過 備注 [Y][P][N][N/A]

根據(jù)測試結果，按編號給出每一測試需求的通過與否結論。P表示部分通過，N/A表示不可測試或者用例不適用。實際上，需求跟蹤矩陣列出了一一對應的用例情況以避免遺漏，此表作用為傳達需求的測試信息以供檢查和審核。

需求覆蓋率計算 Y項/需求總數(shù) ×100％

3.2.2 測試覆蓋

需求/功能（或編號）用例個數(shù) 執(zhí)行總數(shù) 未執(zhí)行 未/漏測分析和原因

實際上，測試用例已經(jīng)記載了預期結果數(shù)據(jù)，測試缺陷上說明了實測結果數(shù)據(jù)和與預期結果數(shù)據(jù)的偏差；因此沒有必要對每個編號在此包含更詳細的說明的缺陷記錄與偏差，列表的目的僅在于更好的查看測試結果。

測試覆蓋率計算 執(zhí)行數(shù)/用例總數(shù) ×100％

3.3 缺陷的統(tǒng)計與分析

缺陷統(tǒng)計主要涉及到被測系統(tǒng)的質(zhì)量，因此，這部分成為開發(fā)人員、質(zhì)量人員重點關注的部分。

3.3.1 缺陷匯總

被測系統(tǒng) 系統(tǒng)測試 回歸測試 總計

合計

按嚴重程度 嚴重 一般 微小 按缺陷類型

用戶界面 一致性 功能 算法 接口 文檔 用戶界面 其他 按功能分布

功能一 功能二 功能三 功能四 功能五 功能六 功能七

最好給出缺陷的餅狀圖和柱狀圖以便直觀查看。俗話說一圖勝千言，圖標能夠使閱讀者迅速獲得信息，尤其是各層面管理人員沒有時間去逐項閱讀文章。圖例 3.3.2 缺陷分析

本部分對上述缺陷和其他收集數(shù)據(jù)進行綜合分析 缺陷綜合分析

缺陷發(fā)現(xiàn)效率 ＝ 缺陷總數(shù)/執(zhí)行測試用時 可到具體人員得出平均指標

用例質(zhì)量 ＝ 缺陷總數(shù)/測試用例總數(shù) ×100％ 缺陷密度 ＝ 缺陷總數(shù)/功能點總數(shù)

缺陷密度可以得出系統(tǒng)各功能或各需求的缺陷分布情況，開發(fā)人員可以在此分析基礎上得出那部分功能/需求缺陷最多，從而在今后開發(fā)注意避免并注意在實施時予與關注，測試經(jīng)驗表明，測試缺陷越多的部分，其隱藏的缺陷也越多。測試曲線圖

描繪被測系統(tǒng)每工作日/周缺陷數(shù)情況，得出缺陷走勢和趨向 重要缺陷摘要

缺陷編號 簡要描述 分析結果 備注

3.3.3 殘留缺陷與未解決問題

殘留缺陷 編號：BUG號

缺陷概要：該缺陷描述的事實

原因分析：如何引起缺陷，缺陷的后果，描述造成軟件局限性和其他限制性的原因 預防和改進措施：彌補手段和長期策略 未解決問題 功能/測試類型：

測試結果：與預期結果的偏差 缺陷：具體描述

評價：對這些問題的看法，也就是這些問題如果發(fā)出去了會造成什么樣的影響 4 測試結論與建議

報告到了這個部分就是一個總結了，對上述過程、缺陷分析之后該下個結論，此部分為項目經(jīng)理、部門經(jīng)理以及高層經(jīng)理關注，請清晰扼要的下定論。測試結論

1．測試執(zhí)行是否充分（可以增加對安全性、可靠性、可維護性和功能性描述）2． 對測試風險的控制措施和成效 3． 測試目標是否完成 4． 測試是否通過

5． 是否可以進入下一階段項目目標 建議 1．對系統(tǒng)存在問題的說明，描述測試所揭露的軟件缺陷和不足，以及可能給軟件實施和運行帶來的影響 2．可能存在的潛在缺陷和后續(xù)工作 3．對缺陷修改和產(chǎn)品設計的建議 4．對過程改進方面的建議

測試報告的內(nèi)容大同小異，對于一些測試報告而言，可能將第四和第五部分合并，逐項列出測試項、缺陷、分析和建議，這種方法也比較多見，尤其在第三方評測報告中，此份報告模板僅供參考。

第四篇：“第三方委托軟件”用戶協(xié)議書

中證期貨有限公司

“第三方委托軟件”用戶協(xié)議書

甲方（投資者）：資金帳號：

聯(lián)系電話：身份證號碼：乙方：中證期貨有限公司

甲乙雙方根據(jù)國家有關法律、法規(guī)、規(guī)章、期貨交易規(guī)則，經(jīng)友好協(xié)商，就“第三方委托軟件”進行網(wǎng)上委托交易的有關事項達成如下協(xié)議：

第一條甲方已詳細閱讀本協(xié)議，認識到“第三方委托軟件”除具有普通網(wǎng)上自助委托所有的風險外，還應充分了解和認識到其具有以下風險：

1、由于客戶計算機故障以及互聯(lián)網(wǎng)數(shù)據(jù)傳輸?shù)仍颍灰字噶羁赡軙霈F(xiàn)中斷、停頓、延遲、數(shù)據(jù)錯誤等情況；

2、因為“第三方委托軟件”程序在客戶的電腦上執(zhí)行，電腦的故障或互聯(lián)網(wǎng)故障引起的行情中斷和錯誤，都可能會造成無法下達委托、委托失敗或下達錯誤的交易指令；

3、投資者的電腦設備以及網(wǎng)絡與“第三方委托軟件”不相匹配，會造成無法下達委托或委托失??；

4、如投資者不具備一定的網(wǎng)上委托下單經(jīng)驗或者對于軟件的使用不熟悉，可能因操作不當造成委托失敗或委托錯誤；

5、由于軟件本身存在的問題而導致甲方在下單過程中出現(xiàn)的其它問題；

第二條上述風險可能會導致投資者（甲方）發(fā)生的損失，由甲方自身承擔，乙方不予以負責。

第三條本協(xié)議所表述的“第三方委托軟件”是指在乙方提供的現(xiàn)有金仕達網(wǎng)上委托程序服務的基礎上，由非金仕達公司的第三方軟件公司或個人開發(fā)的委托軟件。

第四條甲方使用的“第三方委托軟件”必須是在“第三方委托軟件”公司的官方網(wǎng)站或者乙方官方網(wǎng)站上下載，甲方使用其他途徑獲得的軟件，由此產(chǎn)生的后果由甲方自行承擔。

第五條 使用“第三方委托軟件”進行委托過程中，甲方的網(wǎng)上交易資金帳號、交易 密碼以及發(fā)送的交易指令均視為甲方親自委托，由此所產(chǎn)生的一切后果由甲方負責。

第六條 本協(xié)議作為甲乙雙方《期貨經(jīng)紀合同》的附屬部分,爭議解決方式參照《期貨 經(jīng)紀合同》的約定，同時乙方有權根據(jù)市場情況對該協(xié)議作出調(diào)整或乙方單方面終止甲方對于軟件的使用。

第七條 本協(xié)議自雙方簽字蓋章后生效。

甲方授權簽字：簽署日期：年月日

乙方經(jīng)辦人簽字：開通時間：年月日

第五篇：第三方支付軟件大致支付流程

Webpay支付

一、接受商戶訂單請求信息

test.jsp界面跳轉(zhuǎn)到test2.jsp界面，此跳轉(zhuǎn)主要是進行MD5加密，加密字符串=“MERCHANTID=”+商戶ID（comm_code）+“&ORDERSEQ=”+訂單號+“&ORDERDATE=”+訂單日期+“&ORDERAMOUNT=”+訂單金額;

如果clientIP不為空加密字符串+“&CLIENTIP”=ip+“&KEY=”+key Key 根據(jù)商戶的商戶ID 獲取商戶key（comm_key）

調(diào)用CryptTool.md5Digest(加密字符串);

得到test2.jsp頁面上mac的值

訂單號：日期字符串，調(diào)用StringTools.getCurrentDate訂單日期：日期字符串，調(diào)用StringTools.getTodayDate2()訂單金額：測試頁面默認

1二、根據(jù)請求得到界面數(shù)據(jù)

三、對界面數(shù)據(jù)非空判斷

四、校驗商戶域名

request.getHeader(“Referer”)得到商戶請求域名

根據(jù)得到的商戶請求域名和商戶Id檢驗商戶域名：請求的域名正則處理跟商戶表中domain_name域名是否相同（equalsIgnoreCase：不區(qū)分大小比較）。

檢驗為true為正常，否則檢驗不通過在UP_ANTIFISH_NOTICE表中插入異常信息。

五、分賬校驗

取商戶關系，根據(jù)界面?zhèn)魅氲纳虘舸a作為分賬父商戶代碼（parent_comm_code）查詢商戶表得到所有符合條件的商戶代碼集。（divDetailes）商戶代碼：金額 | 商戶代碼：金額...中間以“|”分開的格式。

取出每個商戶的交易金額疊加跟結算金額比對，商戶集若包含商戶代碼，如有一個不符合則分賬明細參數(shù)不正確。

六、商戶IP校驗

首先獲取clientIp（客戶端Ip）不為空則校驗，再得到商戶的商戶IP是否校驗（IS_IP_VAL），該字段為空則表明商戶配置IP不校驗，不為空則判斷商戶真正請求ip不為空且跟clientIp相等否則IP地址異常，交易存在風險，記錄異常信息。

七、對MAC碼校驗

字符：check = “MERCHANTID=” + merchantID + “&ORDERSEQ=” + orderId+ “&ORDERDATE=” + orderDate + “&ORDERAMOUNT=” + transAmount+= “&CLIENTIP=”+clientIp+“&KEY=”+key;

對check MD5處理。

由界面test2.jsp得到的mac校驗域跟check對比

八、檢查商戶業(yè)務類型和支付類型開通情況

調(diào)用UP_COMM_ORDER_CHECK_CORE.best_comm_check過程查詢業(yè)務類型和支付方式開通情。

根據(jù)商戶ID(comm_code)和支付方式ID(pay_type_id)且狀態(tài)（status=0：開通的情況下）查詢up_comm_open_paytype（商戶開通支付方式表），得到支付方式代碼（pay_type_id）

根據(jù)商戶ID(comm_code)和業(yè)務類型(comm_busi_code)且狀態(tài)（status=0：開通的情況下）查詢up_comm_open_busi（商戶開通業(yè)務類別表），得到商戶開通的業(yè)務類型（comm_busi_code）

返回值：

0000:成功

1010：商戶未開通相應支付方式

1020：商戶未開通相應業(yè)務類型

1030：沒有配置商戶業(yè)務類型或者商戶支付方式

九、封裝界面數(shù)據(jù)位payModel實體

十、數(shù)據(jù)校正

十一、接收商戶訂單請求

1)對支付請求驗證

調(diào)用UP_COMM_ORDER_CHECK_CORE.UP_COMM_ORDER_CHECK_CORE_main對支付請求驗證

a)對商戶注冊情況和狀態(tài)檢查

查詢商戶表（up_comm）status字段，A、商戶已注冊但未審批；

B、商戶已注冊，已審批，但未開通；

C、商戶已開通；

D、商戶已注銷。

b)商戶業(yè)務開通情況檢查

根據(jù)業(yè)務代碼查詢商戶開通業(yè)務表（up_comm_open_busi），如查詢到記錄則商戶已開通此業(yè)務，可以正常交易，否則商戶未開通此業(yè)務或商戶為注冊等其他異常。

c)商戶訂單檢查

查詢商戶交易信息表（up_comm_tran_detail）表,根據(jù)商戶代碼、訂單流水、訂單日期來檢查,檢查 TRAN_STATUS 的狀態(tài)。

i.ii.iii.首先判斷交易金額是否小于等于0 部分商戶限制金額 判斷訂單請求流水當天是否唯一

查商戶訂單請求信息表（up_comm_order_detail）order_req_tran_seq=商戶請求交易流水號或者（order_seq =商戶定單號且order_status=A）

如果有記錄，訂單正在交易中，不允許再次交易。

iv.判斷是否有訂單交易成功的記錄

首先查詢出當天該訂單號是否支付過，并且狀態(tài)是B

from up_comm_tran_detail uc,up_bank_tran_detail ub

where uc.up_tran_seq = ub.up_tran_seq

and uc.comm_code = in_comm_code

and(ub.tran_status = 'B' or ub.tran_status = 'D')

如有記錄：訂單交易成功，不允許再次交易。

v.商戶訂單查詢

首先查詢出當天該訂單號支付過，但狀態(tài)是A或C的調(diào)用過程check_bank_tran_status銀行交易是否成功檢查

from 銀行交易日志信息表（up_bank_tran_detail）

and(tran_status = 'B' or tran_status = 'D')

如果無記錄：訂單交易失敗，允許再次交易

如商戶訂單不存在或訂單支付失敗，可以正常交易。

d)商戶訂單插入訂單信息表

插入商戶訂單信息表UP_COMM_ORDER_DETAIL。

2)支付請求驗證成功

調(diào)用UP_COMM_ORDER_ATTACH_INSERT.insert_order_attach_web過程 插入商戶訂單請求附加表up_comm_order_attach，成功后

調(diào)用UP_COMM_TRAN_ATTACH_INSERT.insert_comm_attach 插入商戶交易附加表up_comm_tran_attach。

十二、新增某些支付機構需要借記卡和信用卡通道 select

t.*,ubs.description,ubs.logo_img_path,ubs.pay_info_html_path,ubs.TAB_SIGN

from up_bank_comm_relation t,up_bank_sub ubs

wheret.comm_code = '0018888888'

andt.bank_code = ubs.bank_code and t.sub_bank_id = ubs.sub_bank_id andt.status = '0' and t.sub_bank_type = '1002'

order by sort_numasc

十三、查詢商戶是否已開通的雙通道銀行

0210000008_BOC;0210000008_CIB;0210000008_GDB;

select * from up_bank_comm_relationt,up_bank_sububs where

t.comm_code = '“+commCode+”' and t.sub_bank_id like

'“+subBankCode+”_%' escape ''and t.bank_code='“+bankCode+”' and t.bank_code = ubs.bank_code and t.sub_bank_id = ubs.sub_bank_id and t.status = '0' and t.sub_bank_type = '1002' order by

t.sub_bank_id";

十四、查詢商戶信息

十五、跳轉(zhuǎn)選擇銀行界面

（up_payment.jsp）

頁面顯示對商戶所見的所以銀行

select

t.*,ubs.description,ubs.logo_img_path,ubs.pay_info_html_path,ubs.TAB_SIGN

fromup_bank_comm_relationt,up_bank_sububs

wheret.comm_code = '0018888888'

andt.bank_code = ubs.bank_code and t.sub_bank_id = ubs.sub_bank_id andt.status = '0' and t.sub_bank_type = '1002'

order by sort_numasc

根據(jù)TAB_SIGN的值：

List subBank_1 = newArrayList();//存放個人網(wǎng)銀用戶列表 List subBank_2 = newArrayList();//存放企業(yè)網(wǎng)銀用戶列表 List subBank_3 = newArrayList();//存放翼支付賬戶列表 List subBank_4 = newArrayList();//存放信用卡無密支付 List subBank_5 = newArrayList();//存放積點卡列表 List subBank_6 = newArrayList();//存放快捷支付列表 List subBank_7 = newArrayList();//存放號碼百事通賬戶列表 List subBank_8 = newArrayList();//存放號碼百事通充值卡列表

十六、點擊去支付

點擊去支付進入PayWebTwoAction

有填寫的訂單信息分裝payModel實體

插入交易表：

將payModel信息傳入

UP_COMM_ORDER_TRAN_CORE.up_comm_order_tran_core_main存儲過程插入訂單交易表插入up_comm_tran_detail表中

先檢查商戶訂單交易狀態(tài)A 訂單支付請求中

B 訂單支付成功

C 訂單支付失敗

D 訂單支付結果未知

0000--商戶訂單不存在或訂單支付失敗，可以正常交易

1101--訂單正在交易中，不允許再次交易對應 A

1102--訂單交易成功，不允許再次交易對應 B

1103--訂單交易結果未知，不允許再次交易對應 D

若返回0000，則插入商戶交易信息表up_comm_tran_detail