【正文】 （ 5）業(yè)務(wù)管理系統(tǒng)安全訪問測試 使用若干臺測試機模擬上述不同的情況，嘗試向業(yè)務(wù)管理系統(tǒng)的組件發(fā)起訪期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 29 問請求，檢查系統(tǒng)安全策略能否對這些訪問請求進(jìn)行識別和阻斷。服務(wù)器和業(yè)務(wù)組件由用戶方提供。 其次，通過操作系統(tǒng)的安全機制，可以對整個系統(tǒng)進(jìn)行統(tǒng)一的管理，特別是對安全策略的統(tǒng)一制定和部署 ，能夠極大提供系統(tǒng)的安全性。 根據(jù)前面的網(wǎng)絡(luò)消息洪流攻擊的分析，限制同一 IP 地址對服務(wù)器的過多連接還可以有效抵御 SYN Flood 和 TCP 連接攻擊。 d) Teardrop 攻擊。 安全性測試需求分析 （ 1）網(wǎng)絡(luò)消息洪流測試 網(wǎng)絡(luò)消息洪流的攻擊方式屬于拒絕服務(wù)攻擊 (DoS， Deny of Service)和分布式拒絕服務(wù)攻擊 DDoS（ Distribute Deny of Services） ， 而目前最為流行也是最難防范的攻擊方式是拒絕服務(wù)攻擊和分布式拒絕服務(wù)攻擊。 （ 2） 選擇具有典型性的測試案例，使業(yè)務(wù)系統(tǒng)從交易所新開業(yè)開始，跨2 年的業(yè)務(wù)周期，完成報單、撮合、集合競價、結(jié)算、熔斷、平倉、交割、數(shù)據(jù)傳輸、查詢打印等完整的業(yè)務(wù)功能。 （ 9） 性能測試統(tǒng)計參數(shù)及統(tǒng)計方法 a) 響應(yīng)時間： 在 TestManager 中執(zhí)行測試腳本 ， 模擬并發(fā)用戶執(zhí)行 ，產(chǎn)生 “ Performance Report Output”， 可以清晰的顯示每一筆交易的平均響應(yīng)時間、 90％ 用戶最大響應(yīng)時間、最大響應(yīng)時間等 ； b) 系統(tǒng)處理能力：在 TestManager 中執(zhí)行測試腳本，模擬并發(fā)用戶執(zhí)行，產(chǎn)生“ Command Usage Report”，其中的統(tǒng)計 stop_time Command Throughput for All Virtual Testers： cmds，表示系統(tǒng)每秒鐘處理的交易數(shù)，從中可得出系統(tǒng)處理能力：每分鐘處期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 24 理的交易筆數(shù)。同時驗證隨著客戶數(shù)的增長，交易系統(tǒng)在具有一定客戶量的前提下各種處理能力，從而驗證系統(tǒng)能支持的最大客戶數(shù)。 （ 3）模擬報單成交業(yè)務(wù)，驗證某一報單成交時，由交易所端主動向特定會員發(fā)出信息時，系統(tǒng)處理正常，驗證所發(fā)目標(biāo)會員與報單所屬會員相一致，驗證成交信息完整、正確。 （ 4）在執(zhí)行進(jìn)結(jié)算操作前，對結(jié)算價等相關(guān)參數(shù)進(jìn)行驗證，確認(rèn)結(jié)算價取值正確。 a） 在集合競價報單狀態(tài)時，驗證是否能夠?qū)ο嚓P(guān)限價報單和止損單進(jìn)行插入、修改、撤銷、掛起及激活操作；進(jìn)行相應(yīng)操作時，是否對產(chǎn)生的理論集合價產(chǎn)生影響；當(dāng)產(chǎn)生影響時，驗證新的理論集合價期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 21 是否正確。 d） 驗證部分成交時，剩余交易數(shù)量是否正確，未能成交的剩余申報是否進(jìn)入申報庫 . e） 驗證完全不成交時，剩余交易數(shù)量是否與申報單交易數(shù)量相符，該申報單是否進(jìn)入申報庫。 b) 系統(tǒng)成交價確定原則為中間價原則，即取買入價（ bp）、賣出價（ sp）、前一成交價（ cp）三者之中間的價格，設(shè)計用例時，涉及的報單中合約價格應(yīng)覆蓋 bp≥sp≥cp 、 bp≥cp≥sp 、 cp≥bp≥sp 三種情況。 （ 3）報單修改：按測試用例，對報單可修改屬性進(jìn)行修改，驗證修改后數(shù)據(jù)正確性；驗證對報單非可修改屬性進(jìn)行修改時，是否是取消現(xiàn)有報單并輸入新報單，而非直接修改原報單。 （ 5）刪除某一權(quán)限角色組，驗證與其相關(guān)的操作角色對應(yīng)權(quán)限是否正確處理。 關(guān)鍵點測試設(shè)計 登陸、權(quán)限控制 根據(jù)系統(tǒng)需求，會員、交易員、操作員等多種角色均可登錄訪問系統(tǒng)。 期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 16 性能測試方案 （ 1） 明確性能測試需求 在進(jìn)行性能測試之前，需要根據(jù)系統(tǒng)的性能需求明確描述性能測試的目標(biāo)。 （ 3）利用 Robot 錄制測試腳本 基于測試計劃和測試用例，利用 Robot 錄制測試腳本。客戶端可以為 Java,VC、 VB、 PB、 Delphi 等編制的軟件、各種字符終端軟件或者運行瀏覽器 Microsoft Explorer 和 Netscape，期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 15 通過自動錄制形成測試腳本實現(xiàn)自動化的功能 /回歸測試。 測試用例管理 運用測試用例還需配備測試用例管理軟件。 （ 6） 測試用例的評審 測試用例是軟件測試的準(zhǔn)則，但它并不是一經(jīng)編制完成就成為準(zhǔn)則。 期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 13 （ 4） 評估測試結(jié)果的度量基準(zhǔn) 完成測試實施后需要對測試結(jié)果進(jìn)行評估，并且編制測試報告。 根據(jù)測試用例的測試等級， 每一輪迭代 測試 哪 些用例在設(shè)計用例時都已作明確規(guī)定， 測試執(zhí)行 時測試人員不能隨意作變動。主要是通過一個二維表格一目了然的將負(fù)責(zé)的邏輯結(jié)構(gòu)和多種條件組合的情況表達(dá)出來。測試需要在給定的資源、時間條件下盡可能達(dá)成目標(biāo)，我們必須在測試計劃階段明確測試的目標(biāo)，一切圍繞測試的目標(biāo)進(jìn)行，測試用例的詳細(xì)程度根據(jù)需要確定： 對核心的復(fù)雜流程和算法，測試用例必須明細(xì)到每一步可能的分支；對系統(tǒng)中各個功能模塊都需要的通用測試用例，可以提煉通用的測試要素，制定詳細(xì)的測試用例，而不需在每個用例中重復(fù)，以節(jié)省編寫時間和執(zhí)行時間，提高用例的復(fù)用性。 期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 11 測試用例技術(shù) 用例技術(shù)說明 測試用例指對一項特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略。 系統(tǒng)操作指南 3 安裝、設(shè)置指南 手工依次執(zhí)行驗證是否可以根據(jù)指導(dǎo)步驟完成安裝和設(shè)置后，系統(tǒng)能夠正常運行。這種方法即可以單項驗證各業(yè)務(wù)功能的正確性，又可以加快整體 測試進(jìn)度。 連續(xù)交易撮合 2 核心業(yè)務(wù)處理 先采用模塊測試測試策略，然后采用聯(lián)合測試策略；其中，場景數(shù)據(jù)通過編寫腳本自動生成或通過進(jìn)行數(shù)據(jù)移植來獲取。 增加產(chǎn)品 18 上傳下載文件檢查 手工測試驗證上傳下載文件的功能是否實現(xiàn)，上傳文件是否能打開。添加規(guī)定為整型的項，修改也必須為整型。 報單錄入 6 字符類型檢查 手工測試或使用 Robot錄制 GUI腳本驗證在應(yīng)該輸入指定類型的內(nèi)容的地方輸入其他類型的內(nèi)容，看系統(tǒng)是否檢查字符類型，是否報錯。 測試標(biāo)準(zhǔn) 測試進(jìn)入準(zhǔn)則 用戶提交被測系統(tǒng)的業(yè)務(wù)需求、業(yè)務(wù)功能說明書； 用戶提交可運行的被測系統(tǒng)，且被測系統(tǒng)已通過開發(fā)商的系統(tǒng)測試； 驗收測試所需的業(yè)務(wù)規(guī)則配置已確定。 測試策略 依據(jù)對交易所系統(tǒng)業(yè)務(wù)特征、架構(gòu)特征的分析，確定了交易所系統(tǒng)的測試策期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 5 略，在正式開始測試前，將進(jìn)一步細(xì)化整體策略，以便指導(dǎo)整體測試過程。 測試內(nèi)容 本項目范圍為期貨交易所“交易所系統(tǒng)”的“交易系統(tǒng)”、“交易控制員終端”、“交易所管理”、“結(jié)算系統(tǒng)”、“會員客戶管理”、“會員服務(wù)”、“風(fēng)險監(jiān)控系統(tǒng)”等子系統(tǒng)的驗收測試，目的是 為了確保該系統(tǒng)的各項功能和性能指標(biāo)能夠達(dá)到預(yù)期目的 。 為了提供對交易所系統(tǒng)進(jìn)行的驗收測試服務(wù)，我們有必要對整個系統(tǒng)的特征進(jìn)行概要分析，主要包括業(yè)務(wù)特征和系統(tǒng)特征兩方面內(nèi)容。在軟件過程能力方面， XX 軟件 形成了符合 ISO9000、 CMM、 CMMI要求的質(zhì)量控制體系，并于 2020 年 8 月通過 QAI 組織的 CMM 咨詢和 3 級評估。同時， XX 軟件 公司 也 希望以此次 “期貨交易所系統(tǒng)”驗收測試項目 為起點，與 期貨交易所 建立一種長期的戰(zhàn)略合作伙伴關(guān)系，共同發(fā)展、共同成長。 （ 3） 安全性 業(yè)務(wù)系統(tǒng)的安全運行是保證期貨交易正常進(jìn)行的要素之一，系統(tǒng)的漏洞、外部的攻擊、病毒的侵襲等都會對整個系統(tǒng)帶來考驗。 交易所系統(tǒng)測試涉及期貨交易所系統(tǒng)和會員系統(tǒng)之間通過標(biāo)準(zhǔn)報文進(jìn)行交易所需的數(shù)據(jù)交換和通訊。這種方法既可以單項驗證各業(yè)務(wù)功能的正確性，又可以加快整體測試進(jìn)度。 行情發(fā)布 3 相關(guān)性檢查 手工測試或使用 Robot錄制 GUI腳本驗證刪除 /增加一項會不會對其他項產(chǎn)生影響，如果產(chǎn)生影響，這些影響是否都正確。 會員注冊 11 檢查刪除功能 手工測試或使用 Robot錄制 GUI腳本驗證在一些可以一次刪除多個信息的地方，不選擇任何 信息，按“ delete”，看系統(tǒng)如何處理，會否出錯 。 會員合約查詢 期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 8 功能類型 測試方法 /工具 舉例 16 search檢查 手工測試或使用 Robot錄制 GUI腳本驗證在有search功能的地方輸入系統(tǒng)存在和不存在的內(nèi)容，看 search結(jié)果是否正確。 頁面輸入或按鈕輸入 22 提示信息檢查 手工測試或使用 Robot錄制 GUI腳本驗證提示信息位置、格式、內(nèi)容與需求的一致性。 持倉 6 大數(shù)據(jù)量業(yè)務(wù)限時處理 編寫程序自動生成大批量場景數(shù)據(jù)，使用Robot錄制腳本定制交易發(fā)生計劃，并對交易發(fā)生狀態(tài)進(jìn)行實時統(tǒng)計和分析。 會員遠(yuǎn)程指令 文檔測試 檢查文檔的正確性、完備性、可理解性。 非功能類型 測試類型 測試方法 /工具 安全性 網(wǎng)絡(luò)消息洪流測試 （ 1）手工或編寫應(yīng)用程序發(fā)起敵意會話，驗證系統(tǒng)對敵意攻擊的處理能力； （ 2）手工、編寫應(yīng)用程序、使用 Robot工具 使用同一 IP進(jìn)行重復(fù)請求，驗證系統(tǒng)對多連接請求的處理機制； （ 3）編寫模擬程序或使用 Robot工具測試操作系統(tǒng)、組件、配置文件或外部端口訪問操作系統(tǒng)、組件的控制和安全審計機制。 針對交易所系統(tǒng)這樣的交易 的測試 ，較好的 做法是把測試數(shù)據(jù)和測試腳本從測試用例中劃分出來。 4 因果圖法 首先，根據(jù)業(yè)務(wù)功能說明書中的輸入輸出條件分析出等價類，將每個輸入輸出賦予一個標(biāo)志符；其次，將對應(yīng)的輸入輸出之間，輸入與 輸出之間的關(guān)系聯(lián)系起來，并將其中不可能的組合情況標(biāo)注成約束條件或者限制條件，形成因果圖；然后，將因果圖轉(zhuǎn)化成判定圖；最后，將判定表中的第一行作為場景劃分要素，每一列可以作為依據(jù)進(jìn)期貨交易所系統(tǒng)招標(biāo)項目投標(biāo)書 股份有限公司 12 行測試用例設(shè)計。然后進(jìn)行失敗測試：純粹為了破壞軟件而設(shè)計和執(zhí)行的測試案例，也稱為迫使出錯測試。 （ 3） 編寫測試腳本的 設(shè)計規(guī)格說明書 為提高測試效率，軟件測試 應(yīng) 大力發(fā)展自動測試。 （ 5） 分析缺陷的標(biāo)準(zhǔn) 通 過收集缺陷，對比測試用例和缺陷數(shù)據(jù)庫，分析確 認(rèn) 是漏測還是缺陷復(fù)現(xiàn)。主要來自三方面的緣故：第一、在測試過程中發(fā)現(xiàn)設(shè)計測試用例時考慮不周，需要完善；第二、在軟件交付使用后反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟件自身的新增功能以及軟件版本的更新，測試用例也必須配套修改更新。 （ 2） 壓 力測試需求：能夠進(jìn)行各種負(fù)載環(huán)境下的壓力測試，包括： ? 測試不同負(fù)載時的系統(tǒng)響應(yīng)時間； ? 測試不同負(fù)載時的系統(tǒng)吞吐量； ? 測試工具要具備提供大數(shù)據(jù)量交易事務(wù)的能力。 （ 2）利用 TestManager 制定功能測試計劃和測試用例 基于系統(tǒng)的需求，利用 TestManager 可以幫助制定測試計劃和測試用例。之后，執(zhí)行各種測試套件或相關(guān)測試用例。 （ 5） 利用 TestManager創(chuàng)建測試執(zhí)行計劃 測試執(zhí)行計劃是基于錄制形成的測試腳本，模擬各種業(yè)務(wù)，實現(xiàn)負(fù)載模型的過程。驗證登錄者退出系統(tǒng)時是否能夠正常執(zhí)行，且退出后不再具有任何訪問權(quán)限。 a) 根據(jù)期貨交易規(guī)則，確定委托條件所有可能的組合，用例設(shè)計時要求覆蓋所有的組合； b) 對每一合約要求多張對應(yīng)的報單，并包含凈持倉會員／綜合持倉會員、開倉／平倉／平今倉、投機／保值等各類屬性的組合； c) 對每一報單對應(yīng)的合約價格，要求包含正常價、達(dá)到漲停板價格、超過漲停板價格、低于最小變動價位等多種情況，并考慮金額邊界值情況（零值、負(fù)值、最大值等）； d) 對于每一報單對應(yīng)的成 交量，要求包含正常數(shù)量、超過會員倉位限制、超過合約倉位限制等多種情況 ，并考慮數(shù)量邊界值情況（零值、負(fù)值、帶小數(shù)位數(shù)值等）； e) 考慮報單的增加、修改、撤銷、掛起、激活等操作。 連續(xù)交易撮合 根據(jù)系統(tǒng)需求，在連續(xù)交易階段，每輸入一筆報單，交易系統(tǒng)根據(jù)價格優(yōu)先／時間優(yōu)先的原則，立即判斷它是否成交 ； 存在全部成交、分成幾筆成交、部分成交、完全不成交多種情況；未成交的剩余申報在申報庫以價格優(yōu)先／／時間優(yōu)先的原則排隊等候。 a） 驗證第一筆交易成交時，是否取上日結(jié)算價作為前一成交價，取值是否正確。 b) 考慮在集合競價報單狀態(tài)中，插入、修改、撤銷、掛起、激活限價報單和止損單時，對產(chǎn)生理論集 合價的影響。 （ 2）根據(jù)實際情況需要及各相關(guān)功能模塊用例組織要求，重新整理相關(guān)測試用例，注重相關(guān)功能之間的業(yè)務(wù)關(guān)聯(lián)性。針對某一會員，考慮三種通訊模式同時存在的情況。 性能測試 （ 1） 制定性能測試計劃，要求至少迭代測試 4 次，至少 1 次不間斷運行24 小時。 （ 7） 選擇復(fù)雜度和 TPCC 基準(zhǔn)應(yīng)用相當(dāng)?shù)臉I(yè)務(wù)管理系統(tǒng)功能，設(shè)置一定時間內(nèi)要求完成的交易數(shù)量，并發(fā)多用戶測試，統(tǒng)計此時服務(wù)器內(nèi)存、 CPU、 I/O