【正文】 合康科技 52 / 52。 合康公司產(chǎn)品線8 繼續(xù)努力“用心測試，鑄就品質(zhì)”是合康“測試人”的口號。遠期價值體現(xiàn)在測試的工程中，合康測試團隊建設(shè)了獨立的測試案例庫、搭建了案例和功能關(guān)系模型及對測試缺陷的歸類整理，我們可以很方便地將測試過程中所涉及到的相關(guān)知識固化下來，也可以將原本只保存在大腦中的測試知識和經(jīng)驗通過這種方式直觀地體現(xiàn)出來，從而建立了一套合康測試團隊特有的高效測試體系，豐富的測試經(jīng)驗也為將來的測試工作提供了便利，為將來的項目測試提供了堅持的理論及技術(shù)基礎(chǔ)。僅在T24系統(tǒng)測試過程中，就提交近萬個缺陷，為T24的成功上線做出了應(yīng)有的貢獻。 合康優(yōu)勢l 十年金融領(lǐng)域發(fā)展經(jīng)驗，公司已經(jīng)成為以軟件研發(fā)中心、系統(tǒng)運維中心、系統(tǒng)測試中心為主的全方位金融行業(yè)解決方案提供商及服務(wù)商 l 與國內(nèi)外知名軟硬件公司達成了合作伙伴關(guān)系，能向客戶提供強大的技術(shù)支持，包括咨詢、規(guī)劃、產(chǎn)品及實施部署等，并且得到了金融行業(yè)客戶的一致好評l 專業(yè)的軟件測試服務(wù)提供商，擁有專業(yè)的軟件測試團隊和科學(xué)的管理機制，可根據(jù)客戶的需求，定制解決方案，提供客戶多種服務(wù)模式l 已經(jīng)培養(yǎng)了自己的專業(yè)測試隊伍（T24測試小組），熟悉上海銀行相關(guān)業(yè)務(wù)，能夠快遞高質(zhì)量的提供測試服務(wù)l 可以搭建測試平臺，為客戶提供測試服務(wù)，為客戶降低投入成本、降低管理成本，降低項目風(fēng)險，提升效率和質(zhì)量 合康測試的價值體現(xiàn) 合康測試團隊組建以來，已經(jīng)為上海銀行多個項目提供了專業(yè)的測試服務(wù)，除了自身得到了經(jīng)驗的積累和測試技能的提高之外，也通過提供優(yōu)質(zhì)測試服務(wù)為客戶帶來了一定的價值。u 功能測試外包：公司派出測試工程師駐客戶處，由客戶管理，進行軟件測試外包工作。網(wǎng)銀系統(tǒng)是一個功能豐富，性能要求嚴格的系統(tǒng)，這個特點決定了測試投入的力度，各方面的測試如果不采用自動化測試工具，將會耗費大量的人力物力，而合康測試團隊介入后，大量采用自動化測試工具，測試人員從原來一個上海銀行七、八人的小組減少到合康的三名專業(yè)測試人員，降低了測試的人力成本，而通過自動化測試工具，大量的數(shù)據(jù)交互、校驗等都依靠自動化測試工具在夜間完成，第二天測試人員在工作時間通過自動化測試工具提供的測試報告對系統(tǒng)進行評估和分析，并提交開發(fā)人員進行修正，大大提高了測試效率。在上海銀行call center項目及網(wǎng)銀系統(tǒng)方面，也進行了大量詳細的測試工作，獲得上海銀行的高度評價。通過自動化測試工具的運用，我們也幫助項目組對大數(shù)據(jù)量錄入類交易測試（開戶類交易的錄入）、綜合報表驗證測試（同城交換綜合報表測試需要兩天內(nèi)向新系統(tǒng)錄入10萬筆交易）。 降低變更和配置中的風(fēng)險和對業(yè)務(wù)的影響當發(fā)生變更請求，需要對上線系統(tǒng)進行版本升級或者缺陷修復(fù)，在變更委員會評估了變更的風(fēng)險和沖突以后，測試中心應(yīng)該重用已有的測試案例和測試腳本，對系統(tǒng)已有模塊進行必要的回歸測試，對系統(tǒng)新加的模塊進行新的測試，確保變更是安全的。 6 測試中心在質(zhì)量管理中的應(yīng)用 確保應(yīng)用的性能和可用性 通過測試中心，在系統(tǒng)上線之前，進行有效地功能和性能測試，確保系統(tǒng)在功能和性能上能夠滿足設(shè)計需求和業(yè)務(wù)需求。 對廠商的考核主要包括該產(chǎn)品的質(zhì)量、適用性、易用性、界面是否人性化、以后的維護等方面。因此在項目的進行過程中對相應(yīng)的人員、廠商等進行考核也是非常有必要的。另外，建立良好的反饋機制，文檔管理系統(tǒng)、知識庫和論壇等，都將有助于知識的共享和傳遞。對團隊適時、定時的培訓(xùn)是保證知識傳遞的及時性和正確性的最佳手段。 人員培訓(xùn)管理隨著銀行業(yè)務(wù)及科技的不斷發(fā)展，定期對測試人員進行培訓(xùn)是非常必要的。維護測試用例的過程是一項長期的任務(wù)，而且保證其及時性。在一個階段的測試過程結(jié)束后，或多或少會發(fā)現(xiàn)一寫測試用例編寫的不夠合理或缺少測試用例覆蓋一些應(yīng)用場景。測試用例的結(jié)構(gòu)，可以按照產(chǎn)品線、測試目標和功能模塊來進行分類、組織和存儲，以有利于測試用例的執(zhí)行和維護。l 集體審查測試用例，邀請業(yè)務(wù)人員、設(shè)計人員、開發(fā)人員等參加。最后，要在設(shè)計方法和流程上加強管理，包括：l 采用測試用例的模版，參考已有的范例。任何一個測試模塊都有專人負責(zé)，從需求分析開始到測試用例的維護，確保測試用例的質(zhì)量。l 讓測試人員講解對產(chǎn)品特性和功能的理解。l 加強培訓(xùn)和知識共享，讓產(chǎn)品設(shè)計和開發(fā)人員作專項的介紹。 測試用例創(chuàng)建的管理 設(shè)計新的測試用例，是建立在對軟件產(chǎn)品的需求、設(shè)計和代碼實現(xiàn)等理解的基礎(chǔ)上的。 測試用例管理 測試用例是測試的基礎(chǔ)，測試用例的質(zhì)量決定了測試的覆蓋率，對產(chǎn)品最終的質(zhì)量有很大的影響，所以加強測試用例的管理顯得非常重要。具體步驟就是在測試完成后，由測試人員提交換版通知書給監(jiān)督員和運維人員，并由監(jiān)督員通知開發(fā)人員何時換版。若不一致則停止換版。對于換版方式，根據(jù)不同需要也分為兩種：自動換版和手工換版。 換版管理一個版本在測試完成后，就需要將該版本從測試環(huán)境替換到生產(chǎn)環(huán)境中去，為了保證在更換版本的時候，不發(fā)生錯換、漏換的情況，保證一次換版成功，就需要測試團隊提供幫助。系統(tǒng)需求變更測試經(jīng)理測試需求變更變更通知測試用例測試腳本評審及確認變更內(nèi)容發(fā)布測試人員修改測試用例及腳本執(zhí)行一旦需求發(fā)生了變更，則需要重新進行需求分析，調(diào)整測試計劃，如果只是改動某個參數(shù)或者是應(yīng)用，對整體測試沒有影響，則只需要對這個改動項目進行測試分析，否則的話需要對整個項目重新分析、安排測試計劃。測試資產(chǎn)版本l 針對每個軟件的版本有保存向?qū)?yīng)的測試資產(chǎn)版本，保證測試的準確性l 使用專業(yè)配置管理軟件保證測試資產(chǎn)版本的管理版本的管理可以通過SVN或者VSS來進行管理。軟件版本l 設(shè)立最初版本l 每輪測試結(jié)束后設(shè)立版本l 每個新模塊加入之前設(shè)立版本除了最初版本，每個版本都有一個前驅(qū)版本，確保版本的歷史和可追溯性。通過上圖，我們了解缺陷的流轉(zhuǎn)需要有一個完善的管理機制，由測試人員發(fā)現(xiàn)缺陷，由測試經(jīng)理進行確認，通過BUG報告書發(fā)布給開發(fā)人員，開發(fā)人員進行修正后，測試人員對所修復(fù)的缺陷進行回歸測試，如通過則由測試人員將該缺陷關(guān)閉，如仍存在，則再交由測試人員修復(fù)，直至缺陷修復(fù)、關(guān)閉。 測試報告每個提交給業(yè)務(wù)部門進行測試的版本都應(yīng)有測試報告，該報告可以比開發(fā)類項目的測試報告簡單些，但必須客觀地反映該變更需求的最終測試結(jié)果。當然在實際提交bug時可以根據(jù)實際情況進行補充，如附上圖片、log文件等。一般而言，缺陷都是誰測試誰提交，當然也可以為了保證所提交缺陷的質(zhì)量，在提交前進行缺陷評估，以確保所提交的缺陷的準確性。也就是測試范圍和測試程度的問題。 測試執(zhí)行測試執(zhí)行過程又可以分為以下階段：單元測試→集成測試→系統(tǒng)測試→用戶測試，其中每個階段還有回歸測試等。如果在實際測試過程中，得到的實際測試結(jié)果與預(yù)期結(jié)果不符，那么測試不通過；反之則測試通過。對于復(fù)雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內(nèi)容在操作步驟中詳細列出。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測試用例設(shè)計中會遇到很大的障礙。測試輸入： 提供測試執(zhí)行中的各種輸入條件。重要級別： 定義測試用例的優(yōu)先級別。 測試用例編寫維護類需求的測試用例編寫，我們主要考慮以下幾個方面：用例編號：測試用例的編號有一定的規(guī)則。測試計劃一般包括以下一些方面：1．測試背景2．測試依據(jù)3．測試資源4．測試策略5．測試日程6．其他。 測試計劃測試計劃一般由測試項目經(jīng)理來編寫?？丛撔枨笫欠裥枰膭訑?shù)據(jù)庫結(jié)構(gòu)，接口文檔，操作界面等，以及該需求對其他模塊是否產(chǎn)生影響或者是其他模塊也需要做相應(yīng)的修改等。驗收測試通過，提交業(yè)務(wù)部門測試報告，由測試人員填寫換版通知書進行換版工作。修改完成后繼續(xù)交由測試人員測試，這樣周而復(fù)始，一直到測試人員沒有缺陷提出，測試完成，測試人員將提交維護需求測試報告和驗收測試報告。在開發(fā)組提交測試版本后就由測試組根據(jù)制定的測試案例進行測試工作。一旦計劃制定，那么測試組和開發(fā)組必須都按照該計劃來執(zhí)行工作?？墒侵饕菍π枰_發(fā)的內(nèi)容進行分析，而測試組同時需要對顯式的以及隱含的功能點進行需求分析，分析完成后提交測試計劃和測試案例給信息技術(shù)部進行測試方案評審。一旦復(fù)審沒有被通過，信息技術(shù)部會提交評審意見書給業(yè)務(wù)部門，該需求終止。 維護類項目測試流程 測試流程圖 對于維護類的需求，在業(yè)務(wù)部門提交，經(jīng)信息中心評審?fù)ㄟ^以后，就遞交開發(fā)任務(wù)單給相關(guān)科室。功能測試報告的目的在于總結(jié)測試階段的測試以及分析測試結(jié)果，描述系統(tǒng)是否符合需求。根據(jù)需求的要求不同以及測試的具體實施方法，我們將提供功能測試報告或者性能測試報告。7 2M2 5 31 3W3 13 2W3 1 27 1 56 1 10 102 九月06 ~ 九月1235 1 83 1 10 130 九月13 ~ 九月1935 1 84 1 10 131 九月20 ~ 九月2635 1 88 1 10 135 4. 缺陷趨勢圖5. 缺陷響應(yīng)表16 1 10 61 八月23 ~ 八月2934 1 13 八月09 ~ 八月1526 1 5 八月02 ~ 八月0811 1 七月19 ~ 七月251 1 七月12 ~ 七月181 ClosedFixedOpenProduct_fixedReopentotal七月08 ~ 七月141 6 65 3High4 37 配置測試能保證測試的完整性。6) 配置測試。重點對一些特殊點情況點、特殊的使用環(huán)境、并發(fā)性、進行檢查。隨機測試主要是對被測軟件的一些重要功能進行復(fù)測，也包括測試那些當前的測試案例沒有覆蓋到的部分。往往在測試執(zhí)行過程中，才發(fā)現(xiàn)遺漏了一些測試用例，這時候應(yīng)該及時的補充；往往也會發(fā)現(xiàn)有些測試用例在具體的執(zhí)行過程中根本無法操作，這時候應(yīng)該刪除這部分用例；也會發(fā)現(xiàn)若干個冗余的測試用例完全可以由某一個測試用例替代，那么刪除冗余的測試用例。4) 及時更新測試用例。如果發(fā)現(xiàn)了可疑問題，又無法定位是否為軟件缺陷，那么一定要保留現(xiàn)場，然后知會相關(guān)開發(fā)人員到現(xiàn)場定位問題。3) 及時確認發(fā)現(xiàn)的問題。如果測試執(zhí)行步驟與測試用例中描述的有差異，一定要記錄下來，作為日后更新測試用例的依據(jù)；如果軟件產(chǎn)品提供了日志功能，比如有軟件運行日志、用戶操作日志，一定在每個測試用例執(zhí)行后記錄相關(guān)的日志文件，作為測試過程記錄，一旦日后發(fā)現(xiàn)問題，開發(fā)人員可以通過這些測試記錄方便的定位問題。2) 加強測試過程記錄。在測試過程我們需要注意的就是：1) 全方位的觀察測試用例執(zhí)行結(jié)果。如何靈活運用各種基本方法來設(shè)計完整的測試用例，并最終實現(xiàn)暴露隱藏的缺陷，全憑測試設(shè)計人員的豐富經(jīng)驗和精心設(shè)計?？梢圆捎密浖y試常用的基本方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設(shè)計測試用例。 設(shè)計備選事件和異常事件的用例，則要復(fù)雜和困難得多。而對孤立的功能則直接按功能設(shè)計測試用例。測試用例可以分為基本事件、備選事件和異常事件。測試用例的設(shè)計和編制是軟件測試活動中最重要的。 測試用例編寫測試用例（Test Case）是指對一項特定的軟件產(chǎn)品進行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略。針對系統(tǒng)支持的協(xié)議、指標的測試。子系統(tǒng)的工作狀態(tài)變化對其他子系統(tǒng)的影響。 子系統(tǒng)間的接口瓶頸。單個子系統(tǒng)的性能。針對產(chǎn)品內(nèi)部結(jié)構(gòu)性能的測試。比如：共享資源訪問等。業(yè)務(wù)功能的沖突。業(yè)務(wù)功能的組合。業(yè)務(wù)功能的分解。業(yè)務(wù)功能的覆蓋。功能層。還有一個目的是核實軟件在安裝后可立即正常運行。例如，正常情況下，第一次安裝或升級、完整的或自定義的安裝都能進行安裝。系統(tǒng)安裝升級測試。系統(tǒng)兼容性測試。系統(tǒng)可靠性、穩(wěn)定性測試。強度測試是在資源情況低的情況下，找出因資源不足或資源爭用而導(dǎo)致的錯誤。針對整個系統(tǒng)的測試，包含并發(fā)性能測試、負載測試、壓力測試、強度測試、破壞性測試。重點站在系統(tǒng)應(yīng)用的角度，模擬實際應(yīng)用環(huán)境，對系統(tǒng)的兼容性、可靠性、性能等進行的測試。核實只有規(guī)格規(guī)定的操作權(quán)限才可以訪問系統(tǒng)，其他不符合規(guī)格的操作權(quán)限不能夠訪問系統(tǒng)。這里的安全性主要包括了兩部分：數(shù)據(jù)的安全性和操作的安全性。例如：對支持遠程維護系統(tǒng)的功能或工具的測試?？删S護性是系統(tǒng)軟、硬件實施和維護功能的方便性。在確保用戶界面能夠通過測試對象控件或入口得到相應(yīng)訪問的情況下，測試用戶界面的風(fēng)格是否滿足用戶要求，例如：界面是否美觀、界面是否直觀、操作是否友好、是否人性化、易操作性是否較好。主要包括：用戶支持測試，用戶手冊、使用幫助、支持客戶的其他