1、測試部年終總結范文在實踐中二者常常是揉合在一起，相得益彰。運用所學知識處理實際工作的能力主要通過實踐培養起來的，絕不是天生的。因此，總結是提高能力的重要手段。 本文為測試部年終總結范文， 讓我們通過以下的文章來了解。回顧這一年里的工作收獲頗多。年初一直在參與中行對公系統的測試工作，中國銀行對公代客資金管理系統已 2 月份對公系統順利投產。緊接著春節后又開始了 xx 銀行的 X-FUND2.0項目的全程介入測試。跟隨項目組一同到北京現場開發測試， 以及后期配合用戶的壓力測試，項目投產內部演練和支持等工作。目前中信 X-FUNDS2.0系統也已經投產完畢。8 月份后回到公司，主要從事公司內部集成測

2、試和系統測試工作，主要測試系統包括福建分行日積月累系統、 SGE與 K+接口管理系統、xx 銀行利率衍生品交易系統、浦發銀行離岸交易系統、中國銀行新一代做市商系統等。 目前正忙于新一代做市商系統測試工作， 該項目計劃年底投產。補丁測試方面主要有部分轄內對公系統補丁測試、部分中行對公代客管理系統補丁測試、澳門資金管理系統補丁測試、中信X-FUNDS2.0系統補丁測試等。壓力測試方面主要有中信 X-FUNDS2.0系統、中信外匯電子交易系統壓力測試、統一系統壓力、浦發離岸系統壓力、新一代做市商系統壓力測試等。從年初的中行對公項目到 xx 銀行 X-FUNDS2.0項目再到中行新一代做市商項目。一個

3、個項目完成測試任務并順利投產或進行中。從本年度內主要項目的測試及跟進客戶測試方面經驗教訓進行總結，以便更好的提高項目介入測試的質量和完善自己的能力與不足之處。一、測試組內部要有計劃。介入項目測試以后，理論上講是應該配合項目組的測試工作。 但個人認為這樣測試組方面工作會比較被動，跟隨項目組指定的測試并不能比較全面的覆蓋到系統全部功能或者絕大多數功能。如更新一塊，就讓你測一塊，這樣無形中就會疏漏其他模塊。測試組內部可以根據項目整體工作的安排情況也應該有自己的測試計劃，即完整測試輪次的計劃， 這樣能更好的把握系統整體功能情況。這部分工作在進駐客戶現場測試時應與項目組長溝通， 明確每日工作流程， 如版

4、本 _ 約定、內部更新測試安排以及配合指導用戶測試等工作。二、項目的測試進度控制。主要是按照項目計劃進行的，按照項目組計劃要求完成測試任務、提交測試類相關文檔， 包括制定內部測試計劃、測試案例的完善、執行測試、缺陷跟蹤以及 BUG回歸測試等。協調項目的內部測試工作，配合項目工作，共同保證項目質量。項目測試的問題跟蹤及處理采用每日進行修改問題回歸測試工作，每日同步更新問題跟蹤單的模式，按照規劃時間完成系統更新測試等。三、要加強學習和溝通。在進駐客戶現場測試后，測試人員的工作要配合項目組， 也要指導和協調客戶測試。 項目組內部共同探討解決問題的方法， 向各模塊負責人學習模塊功能處理方式， 向業務人

5、員了解系統中涉及的業務知識點， 兩者結合起來進行模塊功能測試。 與客戶接觸吸收新的業務知識， 積累測試方面必須的業務知識點， 這些都做公司系統測試應有的測試基礎， 或者說銀行金融行業項目測試工作的素養。也可以進步一提高與客戶、 與項目組內的溝通能力和協調能力。多參考客戶測試的測試案例及測試過程中提出的問題， 也能為自己的測試工作打下一個好的基礎。四、善于總結和吸收項目經驗教訓。總結回顧以往的項目測試經驗可以更好的指導以后的測試工作， 也會提高系統缺陷和業務處理流程方面不合理情況的發現率。 測試出來的問題與項目組溝通也會比較容易 . 。鑒于以前的項目經驗，也可以向項目組提出了一些完善性意見和功能

6、實現的處理方式。五、個人得失及不足。作為幾次項目測試的負責人，對于日常的測試流程、測試任務分配、測試執行、缺陷跟蹤、協調內部測試及協調客戶測試方面能力均得到了進一步提高， 理清了項目整個過程中測試小組的工作過程以及后期的項目移交工作。 同時也對系統相應的業務知識有了更進一步認知。 相關業務知識方面還需要進一步加強， 測試技能及測試管理方面還需要進一步完善學習。 更好的吸收項目經驗，做好以后的補丁測試工作及其他項目的測試工作。項目測試中，維護部門配合介入的測試工作比較難分配及管理。維護人員并不是很積極從事項目的測試工作，且分配的任務也不情愿去完成。在中信X-FUNDS2.0項目和新一代做市商項目

7、組中都能明顯體現出來。他們多是認為項目組的測試過程中的工作不屬于自己的職責范圍，認為自己只是一個簡單的配合過程， 要求加班時間要么不來，要么就做其他無關工作的事情。 項目組也認為維護人員只是做自己的維護工作，抱怨時只會對測試人員。項目測試工作量也比較繁重，頻繁的超負荷工作，給測試人員也造成比較大的壓力。公司是否可以通過下放部分考核比例，由測試負責人給組內測試人員和維護人員的工作進行考核打分， 來約束和督促內部測試工作的合理進行。公司是否應該考慮制定比較合理項目開發和測試周期計劃及人員分配比例，切實減少超負荷工作帶來的壓力。公司的業務逐年擴展，測試部門人員缺口較大，主要測試工作基本都落在了部門幾

8、個人身上，望明年公司能合理補充人員， 并能在薪資待遇方面能有比較合理的增長。測試部內部是否應該經常在和合適的時間組織測試技能、業務知識以及項目經驗方面交流的討論會等， 以便更好的分享各自的經驗教訓，為今后的工作提供更多的基礎支持， 同時也應加強新人的培訓力度。在支付寶測試分析的角色和系統分析的角色是對應的，只不過一個是測試類的另外一個是開發類的。 系分下面會有相應開發， 測分下面會有相應的測試用例編寫和執行人員。 也就是說測試分析文檔是對測試執行人員的一個指導 ( 在我原來的理解方式上，覺得測試分析人員應該是用例編寫人員 ; 而在這里測試分析人員是從業務上去分析的，用例是用例執行人員來寫并且執

9、行的 ) 。而通過這次的這次分析覺得自己的測分還存在以下的問題：1 、太關注開發的內部實現邏輯。建議：將開發內部實現邏輯看成一個黑盒子，測試分析要從這個黑盒子的輸入和輸出上去看開發內部實現邏輯是不是有問題， 而不應該先去了解開發的實現邏輯然后按照他們的思路去分析。2 、分析文檔寫的過于詳細， 甚至將用例的步驟都寫了出來。 建議：測試分析要從全局上去看問題， 細節的東西即便是知道的， 也要留給之后的用例編寫人員去了解 ( 就像系分之后的開發需要去寫詳細設計的道理一樣 ) ，這樣后面的人才會自己主動去想問題。3 、分析文檔要考慮維護性問題， 不要出現類似比如還款中狀態為“R”這種具體的數據內容。因

10、為我的分析是對后續用例編寫人員的一個指導性的文檔， 所以如果側分這么寫很有可能導致用例也照著這么寫，其實不管側分和用例都不應該具體寫到 R這么細節，否則的話開發稍作變動我們就要相應變動我們的用例4 、沒有明確測試目的。 review 用例的時候，沒有提出每個用例需要明確一個測試目的， 讓別人來看這個用例的時候能明白到底是怎么回事。總結：1 、以后寫測試分析文檔，依據僅僅是 prd 文檔，必須拋開開發實現邏輯部分 ( 即不去看系分文檔 ) ，待測分出來之后，再去看系分文檔，互相看看彼此考慮的是否存在遺漏的地方。 等到在寫用例的時候再讓寫用例的人和相應的開發去互相明確更細節的東西。2 、寫用例我們目前都是僅僅做到對流程上的每個節點去單獨