測試工作總結
測試工作總結
時光飛逝，如梭之日，辛苦的工作已經告一段落了，經過過去這段時間的積累和沉澱，我們已然有了很大的提升和改變，是時候仔細的寫一份工作總結了。那麼如何把工作總結寫出新花樣呢？以下是小編幫大家整理的測試工作總結，希望能夠幫助到大家。
測試工作總結1
這個學期我學習了軟體測試這門專業課程，在學期即將結束的時候，我也對這門課程建立基本的瞭解和理解。軟體測試這門課程作為軟體工程專業中一門很重要的課程，已經在軟體領域佔據了不可替代的角色，當一個軟體從雛形到真正的在一臺計算機上執行的時候，誰也不能保證計算機軟體能一步到位的滿足人們的需求。所以就有了軟體測試，其目的是：第一是確認軟體的質量，其一方面是確認軟體做了你所期望的事情，另一方面是確認軟體以正確的方式來做了這個事件。下面我簡單的寫一下這個學期對課程的總結和收穫。
我認為，在整個龐大的軟體工程中，不管是需求分析、架構設計甚至是最後的debug，都會產生引入不管的機會，這就要求作為一個軟體測試師要掌握豐富的軟體工程原理和知識。測試的工作將會存在於整個專案週期，即在專案開始時需要各種分析調研時就開始了。尤其是在形成需求規格說明書時就有對文件的測試需求，甚至主導整個專案的走向。
軟體測試對邏輯思維、學習能力、反應要求很高，是否有嚴密的思維和逆向思維也非常重要。做測試還要考慮到所有出錯的可能性，有時候還要用一些非常規的的測試方法。軟體測試還很注重軟體效能問題，也就是要保證軟體執行得很好；不同的使用環境下，考慮軟體的相容性同樣重要。對於測試員來講，會比開發人員更加重視軟體產品的質量問題。在測試過程中，測試者可能會為客戶的需求角度考慮到更多，由此我們可以認為測試人員有權利決定產品是否可以釋出。然而，透過一個學期的學期，我們又不得不懂得，軟體測試人員不是萬能的，測試人員在面對一個設計爛編碼爛的軟體時，也是無法不低頭的，再怎麼測試它也變不成優秀的軟體。
透過課上的理論因為課下的實踐和後半學期又因為身體力行於。
1、最基本的測試的分類：從是否需要執行被測軟體的角度，可分為靜態測試和動態測試；從測試是否針對系統的內部結構和具體實現演算法的角度來看，可分為白盒測試和黑盒測試。
2、然後就是，白盒測試中的邏輯驅動測試的覆蓋率測試。
3、還有就是對於劃分等價類和邊界值法這一塊，讓我從模糊到明朗。
4、在初次寫測試用例的時候，感覺真是糾結，用例寫的很死板，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且還很慢。在後來負責了對論壇新鮮事版塊的測試之後，明白了測試用例其實就是指導怎麼去執行測試，而且書寫設計測試用例也要以熟悉軟體的業務為前提，才能更好的去測試。
另外就是一個學期的學習讓我糾正了幾點誤區：
1、有位大師曾說過：“軟體測試的目的在於發現錯誤，一個好的測試用例在於發現從來未發現的錯誤，一個成功的測試是發現了從未發現的錯誤的測試。”由此我自認為測試就是為了找到bug，然而一個學期的測試學習經驗告訴我這是錯誤的，如果只是為了找到BUG，那麼BUG會成天纏著你。
2、在大家協力測試論壇的時期內，我曾認為這種大量的重複性的工作真的很乏味，可是在這乏味中真心發生挺多有意思的bug，意想不到的bug，所以我認為只要掌握了方法，在重複中尋到到創新的小驚喜，任何東西都有它的特點。
作為測試新手，透過一學期的學習，我認為能獨立寫測試計劃，設計測試用例，精通一種測試工具，理解一種bug管理軟體是新手晉級老手的必備素質。任重而道遠？
在最後，我不得不提的就是細心和耐心了。這是我認為這個學期測試課上收穫的了，課程要求測試時必須細心和耐心，我在想，如果以後真的工作在測試一系列的崗位上，要學會坐得住，用大量的時間和精力和bug鬥爭，分離、識別還有歸類bug，是不是也能真的改變我粗心大意和三分鐘熱度的毛病。
最後感謝劉老師這學期的課程講授，和實踐中的指導和幫助。測試路程，路漫漫其修遠兮，吾將上下而求索。
測試工作總結2
我最初參加測試工作的時候，不知道什麼是軟體測試，整合測試和系統測試的概念經常混淆，cmm是什麼就更加不知道了。那時候最簡單的開關機也是透過直接拔插電源完成，安裝系統對我來說簡直是有史以來人類的最高技能，對於那些拿著螺絲刀安裝機器的人就認為是宇內超級高手，身具殺人於無形之絕世秘技。拿破崙說不想當將軍計程車兵不是好士兵，我最初的夢想就是想成為軟體測試的高手，傲視天下。所以不斷偷師，總結經驗，自認為掌握了成為高手的幾個秘技，這幾年混跡“江湖”還算無往而不利。不敢獨享，望與吾輩測試人員切磋，早日總結成功密技之大成，助新進人員早日入門，也算不愧對東北活雷鋒的稱號。
第一招學會利用網路
剛參加工作面對浩瀚的網路世界，當時如劉姥姥進大觀園，什麼都新奇，什麼都想要，從網上下載很多源程式的程式碼，軟體技術文件之類，恨不得把所有的好東西收集到手中，其實有些在他人看起來就是垃圾一堆。當時覺得有了這些“武林秘籍”，成為高手指日可待。最初參加工作由於自己工作努力有幸轉為開發，加入專案組後我的習慣還是沒有改，反而變本加厲，手中的資源更加多，上網的時間更加頻繁。
一次專案經理分配任務，覺得依靠手中的秘籍加上自己的“聰明才智”很快會完成，不料短短的時間，所有的一切變成了馬奇諾防線。解決問題很慢，思路不清晰，專案經理在對我施壓的過程中教會了我終身難忘的一招，學會利用網路尋找要解決問題的答案，從此google成了我的最愛，關鍵字成了我變化的招數。在軟體測試工作中，他幫我解決了很多疑難問題，解答了很多令我迷惑的地方。也是我幫助測試同行解決問題手段之一，很多軟體測試新手，甚至老手都沒有意識到自己手上就握有“無敵秘籍”，所以只要你耐心找，答案就在身邊。
這裡總結一下利用網路搜尋引擎的技巧：
組合搜尋：每次搜尋某個檔案，如果只給出一個單詞進行搜尋，經常會出現成千上百萬計的匹配網頁。然而如果再加上一個單詞，那麼搜尋結果會更加切題。
選擇表述內容的片語：一般我在網頁搜尋引擎的時候，選擇一些可以表達我要查詢內容的關鍵片語，用來縮小搜尋範圍，從而找到搜尋結果是最好的辦法。運用片語搜尋涉可以先先簡單地輸入一個問題作為片語搜尋，如果仍然找不到合適的，那就用多個可以表達要查詢內容的關鍵字進行查詢。
定位資訊來源：有的時候用片語搜尋不到或者無法準確表達所需資訊。可以用另一種方法直接到資訊源，就是直接到到提供某種資訊的`站點去。可以用公式“公司名”去猜測某一組織的特點。從而得到所要搜尋的資訊的主要片語。
其實網路上還有很多關於搜尋技巧的文章，大家可以自行學習。千萬要記住搜尋引擎是幫助你成功的有力武器。
第二招學會動手
參加軟體測試工作後，隨著工作經驗的增長自我感覺越來越好。在公司裡也逐漸受到同事領導的重視，一次針對公司的新的軟體功能進行測試的時候，像往常一樣“隨手”測試出了幾個bug，然後“仔細”的填寫了bug單（這個bug的現象已經出現了很多次了）。這時候測試經理走過來，重新複查了一下填寫的bug。他在重現我的bug的過程中，簡化了我的輸入變化，bug神奇的又出現了，同樣的現象，他關閉軟體重新變化輸入，擴展出10幾個變化後，軟體不動了，記憶體不斷上升。終於他找到了產生軟體的bug的原因，然後對我說“尋找bug要準確定位，我們開發團隊是一個整體，時間是等量的，時間不在你身上浪費，就是在他身上浪費。如果測試人員每次發現的bug描述不清楚，並且多個問題潛在的錯誤原因是一個，雖然操作可能稍微有些變化。這樣開發人員在重現bug的時候他要除錯跟蹤判斷，很花費時間，而且效率低。如果測試人員發現bug的時候多動手可以更加準確的定位bug步驟和原因，給開發人員最精確的步驟和準確的描述，這樣整個團隊才能高效，所以需要大家協作。
在以後的日子裡，每次解決問題的時候我都記得多試驗幾次，多嘗試。網上很多朋友還有同事問我問題的時候，其實他們只是萬里長征就差一步，只要再多動手實驗一次就可以達到目的了。所以多動手，多嘗試。
第三招思考自己所作的
剛開始入行的時候，總是思考如何做好軟體測試。認為公司的測試流程混亂總是很鬱悶，認為自己學不到東西，如何才能測試好產品，常說心動不如行動，以前看到古龍小說中經常出現的場景無名小子不斷挑戰高手，總結積累。我總結了有些經驗是實戰中得到的，所以不斷嘗試引入新的測試流程然後評估，這個過程雖然很痛苦，但是從中積累了不少經驗。這段時間讓我學習到了很多東西，接觸了iso，cmm，測試管理工具，自動化工具（因為公司不正規給了我很多學習的機會，後來到了比較大的軟體公司後，以前的經歷給了我更多的發展機會，因為大公司非常正規了，公司內部人員分工明確，所以能力的鍛鍊反倒少了）。由於工作中經常寫報告反倒養成了總結教訓的習慣，因為紙面上的東西是永遠也忘不掉的。在寫的過程中可以不斷補充擴充套件，整個過程是思想昇華的過程，當年達摩面壁九年就是融會貫通的典型例子，如果他不是有個思考的過程，他也不能成為一代大家。如果後來不時有人把他的絕技記錄下來，也就不能有後來的少林寺七十二絕技。
所以善於思考，總結經驗，也是成為高手之路的不二法決。
測試工作總結3
一直在對公司幾個固定的軟體做測試工作，在接到進行KJ385系統的測試任務之前對我們的線上系統一直沒有一個很深刻的認識，甚至於對主站、分站、介面這樣的術語也是一無所知，只知道一點我們的線上系統在公司是一個很重要的專案，大家對其也抱有很大的信心，一定要讓其順利的透過煤安認證。
11月26日開始本系統的測試工作，其實也算不上是隻針對於軟體，需要排查軟體本身的錯誤，然後從軟體中發現硬體上傳的問題，與開發人員一同分析確定bug是由軟體還是硬體程式產生的。從學習到測試到排查，整套系統測試完畢真的收穫很多，無論是知識上還是以後工作中需要注意的地方。想在此把我的整個測試過程記錄一下，也算是對這段時間工作的一個總結，不過這些收穫還得要歸功於我的領導，如果不是他這次把這個任務分給我，我真的學不到這麼多東西呢。
（1）與工作組人員的合作
說團隊合作可能意義太廣，我要表達的一個意思就是一旦一份工作需要其它人的協助配合，一定要讓別人瞭解到你確實是想得到問題的答案，你在虛心請教他們每一個人，這樣整個小組才能有一個好的工作氛圍，才能讓工作順暢的進行下去，對其它成員的工作不理會，也勢必會對自己的工作造成困擾，因為你永遠都不可能保證自己工作中不會遇到問題。
（2）效率的提升
這個效率的提升不是從我本人身上得到的一個體會，而是整個工作過程中我對其它人工作效率的一個總結（不過這可不是批判其它人的工作，也算是對自己以後工作中尤其要注意的一方面的一個提醒吧。接到一個大的任務可能你要做的工作很多很多，（比如說我們的線上系統，硬體上你既要熟練掌握各個硬體裝置的掛接，又要學會修整其中出現的小問題，保證硬體正常的情況下還要確保軟體無誤）這時候時間上的把握一定要清晰，今天做什麼，明天做什麼，工作與工作的銜接是否得當，第二天做的工作前一天是否已經對其做了初步的準備。應該要列一個詳細的時間安排計劃，沒有計劃的工作只能讓你手忙腳亂，看上去你一直忙忙碌碌，但其實每個工作都沒有結果，這樣勢必會導致你的工作質量下降，甚至於任務的延期。如果在工作進行時確實因為一些其它原因導致不能按照原計劃執行，或者說因為執行某一項耽誤了後面的程序那自己利用業餘時間將計劃進行修整以保證後面的工作不會受到很大的影響。工作務必要保證在合理的時間段內高效率的完成。
（3）任務的輕重緩急
確定當前你的重點測試方向，是硬體還是軟體，如果是當前重點測試軟體問題，一定要保證其硬體的掛接正確，硬體本身能正常工作。將軟體的簡單獨立功能測試完畢，再去重點測試實時線上傳輸，實時線上傳輸講求的是效能穩定，一定要制定合理的測試方案保證能順利的讓軟體透過效能測試。初次測試個人感覺對軟體的測試極不成功，因為沒有制定一個合理的測試計劃，以至於因為硬體程式的問題讓軟體的測試很被動，重點測試方向給轉移了。但事後仔細想想，反覆驗證硬體程式的時間之餘足以讓自己把實時上傳的測試方案寫出來，這樣也會加速後面的測試程序，讓工作仍然保持有序狀態。
（4）錯誤的跟蹤分析
前面說的實時線上傳輸系統看的是系統的穩定效能，長時間載入之後如果發現有問題，作為測試人員也要在第一時間對其排查，要首先排除人為因素造成的故障或是機器本身是否有問題，然後要對資料進行分析檢視故障日誌的發生時間、檢視資料的完整性，以便開發人員在詢問有關故障適宜時能夠應答自如，這樣就能更有利於開發人員確定錯誤，以便及時對其修改，對於已經確定的問題修改完畢之後列為重點測試物件繼續對其監測。開發人員也找不出問題的所在，這時作為工作組成員要做的工作就是提出幾個測試方案以便依次進行排查。（如我們本套系統我確定裝置沒問題，但就是不清楚到底是分站問題還是主站問題，這時候為了找到問題根源就必須想幾個測試方案，如我們先單獨掛接一種型別裝置載入固定時間確定單個裝置沒有問題再依次往上掛接其它型別裝置，多一種裝置一旦出現問題那產生錯誤的根源也就找到一定是某種裝置的傳輸對另一種裝置型別造成了影響…）本次測試對自己提供測試方案這方面比較滿意，其中也排查出了問題所在。
（5）與開發人員的配合
曾經看過一句有關測試的話語，一個好的測試人員不是發現更多bug使得開發人員不自在的人，而是能夠說服開發人員修正更多bug的人。對這句話自己當然是持中立態度。但是這句話卻現實的反映出開發人員與測試人員在工作中的對立問題。任何一個開發人員都不希望自己的程式或產品出問題，甚至於我們發現的錯誤有時開發人員並不認同，認為是我們搭建的環境問題，這時候就要看測試人員如何去溝通表達。工作中一旦發現問題不要去數落開發人員的不是，而是向開發人員報告錯誤之後與開發人員一同去確定bug。或者更進一步幫助開發人員一塊去思考可能產生問題的原因，這樣開發人員才樂於接受。（自己對此深有體會，從開始對開發人員改程式的不耐煩到與開發人員一塊排查問題所在，自己感覺很有收穫，一點小小的成功軟體上一塊跟開發人員解決問題）與開發人員的溝通配合靠的是換位思考，換做自己的話也未必不會出現這樣的錯誤，甚至有可能出現的問題更多呢。
測試工作總結4
自2月份開始，我一直在跟進xx銀行w—xxnd1s2.0專案的測試工作，至此為止已近6個月時間，從公司內部系統測試、驗收測試，再到uat測試，以及投產前的系統壓力測試等等。從開始到專案即將結束，一步步走過來。本次專案中，我作為測試環節的主力人員之一，僅對此專案中測試工作進行總結。
一、專案測試進度控制。
專案的測試進度主要是按照專案計劃進行的，完全按照專案組計劃要求完成測試任務、提交測試類相關文件，包括測試案例的完善、制定測試計劃、執行測試、缺陷跟蹤以及bug迴歸測試等。協調專案的內部測試工作，本此專案中測試小組一共組織了四輪次系統全面測試工作，認真配合專案工作，共同保證專案質量。專案測試的問題跟蹤及處理採用每日進行修改問題迴歸測試工作，每日同步更新問題跟蹤單的模式，按照規劃時間完成系統更新測試。
二、專案組內部成員關係處理。
在專案工作的這幾個月裡大家相處融洽，專案組內部共同探討解決問題的方法，向各模組負責人學習模組功能處理方式，向業務人員瞭解系統中涉及的業務知識點，兩者結合起來進行模組功能測試。鑑於之前轄內對公交易系統和中行對公專案的經驗，也向專案組提出了一些完善性意見。
三、協呼叫戶測試方面。
使用者驗收測試是專案測試工作的重要組成部分之一，是專案驗收階段的最終把關階段，業務人員結合日常業務處理情況對系統進行的嘗試性使用過程。本次專案客戶測試方面也是我個人覺得不夠安全感一個主要方面，客戶測試介入力度太小，儘管我們已經很多次電話催促業務人員測試，每次聯絡相關業務人員進行測試，他們來到專案組開發現場測試，也僅僅一兩個小時時間，簡單的進行驗證操作即可。xx銀行利用兩批系統培訓的時間安排了兩次分行集中測試，也算給專案進行了一次全面的測試，從中也暴露出不少系統存在的問題，目前專案組均已解決。
四、測試成效方面。
中信x—funds2.0系統測試中，共記錄問題及客戶新增需求825個，其中bug數量512個、系統完善類問題225個，新增需求類問題88個。組織了四輪次內部系統全面測試工作，兼顧日常系統更新測試工作，最大限度的進行了內部質量把關。配合外包公司一同進行系統壓力測試及穩定性測試，測試結果符合客戶要求。現中信x—funds2.0系統臨近投產實施工作，測試組還將繼續配合配合專案投產工作及投產後的補丁更新測試工作。
五、個人得失方面。
作為此次專案測試的負責人，對於日常的測試流程、測試任務分配、測試執行、缺陷跟蹤、協調內部測試及協調客戶測試方面能力均得到了進一步提高，理清了專案整個過程中測試小組的工作過程以及後期的專案移交工作。同時也對各子系統相應的業務知識有了更進一步認知。相關業務知識方面還需要進一步加強，測試技能及測試管理方面還需要進一步完善學習。更好的吸收專案經驗，做好以後的補丁測試工作及其他專案的測試工作。