測試工程師的工作總結5篇

如果想要讓自己得到成長，一定要認真進行工作總結的寫作，工作總結是很好的反思方式，出色的工作總結一定能給人以很大的幫助，本站小編今天就為您帶來了測試工程師的工作總結5篇，相信一定會對你有所幫助。

測試工程師的工作總結篇1

先介紹一下我的背景：通訊類院校20xx年畢業、本科、計算機專業，畢業後進入一家大型通訊裝置商工作，任職軟體測試工程師。

一、t專案執行

20xx年7月13日入部門，此時才知道自己被分配到了測試部。部門主管把我領走後，就把我交給了導師。

入部門的頭幾天，主要熟悉公司的工作環境，認識部門同事，瞭解產品知識。由於我們是做傳輸裝置的，所以當時學習的產品知識主要以sdh原理為主，包括sdh的幀結構、網路的保護和倒換等。

下面介紹一下我所做的專案。

專案名稱：t軟體

專案概況：該專案是在pc和sun工作站上開發的軟體，屬於cs結構。client端用java開發(開始使用jdk1.3，後來改用jdk1.4)，實現跨平臺;server端用c++開發，使用ace實現跨平臺(windows和unix)。

人力投入：開發好像是9人，測試3人。(我來的時候是產品的第2個版本，人力投入大概如此)

我入部門幾天後，t專案就進入了測試階段。我的任務就是執行分配給我的測試用例。當時我只知道根據測試用例描述的內容，去點滑鼠，如果發現程式出現錯誤或異常，就填寫問題單。我就這樣沒有任何思考的按著測試用例點了3個月的滑鼠 : )

現在想起當初的測試工作，實在有太多的不足，和待改進點。

1|||、 測試用例。對於一個軟體的測試來講，測試用例是至關重要的。測試用例要覆蓋所有測試規格，而且測試用例要易於理解、易於執行，簡單的講就是要描述的規範。而當時我們的測試用例卻是一團糟，最糟糕的是用例的質量很差，使用這些測試用例，根本無法保證產品質量。測試用例的預置條件、操作步驟、預期結果的描述也是亂糟糟的，而且用於儲存測試用例的excel表格設計的很差，介面很不友好，從一定程度上降低了測試效率。

2、 產品知識。t軟體雖然是在pc和工作站上執行的，但是開發t軟體的目的是為產品服務的，所以我們必須具備產品知識，才能更好的對t軟體進行測試。恰巧當時包括我導師在內的3個人，都不太瞭解產品，所以就造成我們無法判斷某些測試用例是否驗證通過。從而導致了與開發人員的多次爭吵。

3、 軟體測試的重點不明確。軟體測試是軟體工程中的一項重要活動，它儘可能發現程式中存在的缺陷，保證程式的質量。但軟體作為一種商業品，有它的釋出時限，老闆說這個軟體要1月份釋出，你總不能測到12月份再給他釋出吧。當時我們在一些小問題上與開發人員糾纏過多，而很多重點卻沒有得到重視，一些嚴重問題暴露的比較晚，導致測試時間延了又延，版本測了一個又一個，想起那些日子，只能如此描述：累並痛苦著。 : (

4、 測試流程的把握。7月份中旬，t專案從開發部轉到測試部，進入了測試階段，實際當時的產品質量並不能達到轉測試的標準，而我們卻讓他們通過了轉測試，結果就給我們自己帶來了巨大的痛苦。而且後續的幾個版本也如此，我們是測了一輪又一輪，測的我們都要絕望了。回頭想一想，t軟體還真的是我們測出來的，而不是開發寫出來的 : )

5、 缺少針對性測試。軟體也可以分很多種，不同的軟體有不同的特點，自然就需要針對性的測試了，

一年級語文家長會講稿%a(20xx-11-25 11:26:53)

譬如gui的軟體與嵌入式軟體的測試方法肯定有很大不同。最初我們在做t專案測試時，就缺少針對性方法。有兩個教訓讓我們刻骨銘心：1、介面測試，t軟體釋出後沒多久，其他組同事就發現某介面一個按鈕的單詞拼寫錯誤——rollback被寫成roolback;2、效率測試，軟體測試到後期才發現t軟體在實際環境中執行效率很低，根本無法滿足達實際應用的需要。從那以後我們就準備了專門針對t軟體的測試專案，包括：介面測試、效率測試、資料測試、穩定性測試等。

6、 溝通問題。自從工作開始，開發人員和測試人員的爭吵從來就沒有停止過。最初是什麼問題都吵，很多沒有意義的爭吵甚至非理性的爭吵，慶幸的是現在的爭吵大多是有針對性的、理性的。個人覺得以前無為爭吵過多的原因是：開發人員、測試人員的工作技能和職業素養都比較欠缺。吵了大半年後，人員提升了工作技能和職業素養後，吵架都吵的比較有默契了。當然最重要的是開發人員和測試人員的目標要一致：保證產品的質量，滿足客戶需求。

二、自動化測試

20xx年過完年後，我被主管派到一個大組去學習自動化測試技術。這個測試組是個比較大的測試組，總共有幾十號人，其中有很多牛人。他們的自動化測試框架就是由幾個牛人耗時1年多開發出來的。到現在，他們的自動化用例覆蓋率約50%，應用率好像有70%，總之這個自動化測試框架還是滿牛x的，不過就是整個框架實現太複雜了，涉及的程式設計指令碼就用了三種 : (

下面簡單介紹一下該gui自動化測試框架。

測試工具：ibm rational robot

自動化測試技術：第三代自動化測試框架，叫什麼dde，具體什麼意思已經記不住了 : )

測試指令碼：robot中使用的是sqabasic指令碼(基於basic的一種指令碼)，另外還使用了tcl、com組建等，並自行開發了一個抓包工具用於自動化測試。還有我們測試的產品介面是使用java開發的，如果要讓robot能夠正常識別介面，還需涉及到java程式設計。呵呵，實現上可是夠複雜的 : (

學習自動化的頭一個星期，我只是學習該測試組的產品知識，學習如何使用自動化測試。後面的幾個星期就開始承擔自動化測試的建設任務了。想想當初自己還是滿辛苦的，白天上班學習產品知識，晚上回家就對著電腦看basic指令碼的語法，週末還去公司無償加班看程式碼。

在技術文件的選擇上，我基本只看英文的，單詞不懂就拿金山詞霸查，實在看不懂了才會去找些中文的資料看。為什麼要選擇英文的呢?因為很多中國寫書的人很浮躁，只想著快點把書出版了好賺錢，所以很多中文的資料質量很差。首先要貶低的就是那本譚教授的《c語言程式設計》。記得讀大學時，照著譚教授的書敲程式，沒多少程式能編譯通過的，真是誤人子弟。

當時帶我學習自動化的導師姓l，他是個大忙人，有時一整天都在開會。l的師傅姓w，w是該自動化創始人之一。我呢，充其量算是徒孫一輩，呵呵。由於l太忙，而且不那麼愛說話，於是乎我就只能自己對著文件看程式碼。

當時對我比較有用的文件就只有兩篇：一篇是彙集型的chm文件，是篇比較全面的介紹，其中包括自動化框架的介紹，原理的介紹，各模組介紹，自動化執行的流程等;另外一篇則是由w寫的自動化建設指導書，寫的還是滿不錯的，在我有一定基礎後，照著指導書就能完成簡單的自動化建設。

在我整個學習過程中，是按照以下的過程開展的：1、吳江裝修網初步瞭解整個自動化和產品知識，嘗試使用自動化進行測試;2、熟悉sqabasic語法;3、對著文件讀程式碼，嘗試除錯指令碼，跟蹤到程式碼的最底層。木製模擬模型

其實最好的學習方式就是實踐，去做自動化建設。當有一定基礎後，去完成導師交給的自動化建設任務，就是最好的學習方式。後來，我教別人的時候，也是安排實際任務給他做，然後再進行相應的引導。

在我的學習期間，有件事情讓我滿討厭的。就是我必須給原部門的主管和測試組人員講課，然後那些傢伙會不停的提問，以檢驗我的學習效果。雖然這招很bt，但是對個人的成長還是滿有利的。假設你學會了一項技能，此時你可能只在第一個層次上，如果你能夠把這項技能教會別人，那麼你的層次上升了一個檔次。

記得當時是20xx年2月初去參加學習的，4月初就應急被調回原測試組了。總共不到兩個月的時間，我總共完成了3個模組的自動化建設，第1個模組搞了3個多星期，第2個模組不到2個星期，第3個模組一個星期就搞完了(第3個模組算是友情支援呢，哈哈)。

4月初被調回原測試組後，就一直做救火的工作。差不多5月份的時候才正是開始做我們t專案的自動化。其實也就是把我學習的自動化框架移植過來，做t專案自動化測試。

另我比較遺憾的是，t專案的測試一直都很緊，而自動化測試並沒有被推廣和充分利用。直到我離職前，測試組為應付測試部自動化考核指標，才得到重視。

這裡我談一下自己對自動化測試的理解。

1、 自動化測試用於提高測試效率;

2、 自動化測試可以完成一些無法手工完成的測試，例如長時間不間斷的測試;

3、 自動化雖然能夠發現問題，但主要是對繼承的功能進行測試，保證以前的老功能。(這個跟專案有關， gui自動化測試比較複雜，如果是嵌入式裝置或晶片的自動化測試，對自動化測試的理解可能會不一樣)

三、開發小工具

我在自動化學習期間，表現出來的專業技能和良好的學習能力，得到了同事和主管的認可。鑑於此，在4月中旬的時候，測試組的leader給我安排一個任務，使用excel表格開發一個工具，用於收集和統計記錄的資料。要求該工具能夠代替手工計算，提升測試效率。任務完成的截至日期是五一。給我安排的時間大概為一週。

該工具的實現方式並不難，就是設計一個excel表格，然後在裡面嵌入vba指令碼，以巨集的方式代替手工計算。對我來說最大的挑戰就是：1、短時間內學會vba程式設計;2、提取需求，設計excel表格的格式，使該工具具有較好的易用性。

當我接到任務後，下班回家就開始到網上搜集關於vba資料。當時我找了一個星期，都沒有讓我滿意的文件。最終只找到一篇國人寫的pdf文件，但是那篇pdf文件只是讓我初步瞭解了vba是個什麼東東，並不能滿足我的實際需求。最終，在寫vba指令碼期間，我還是參考微軟自帶的幫助文件搞定的。(搞忘球當初是否裝了msdn)

本來計劃是在四月底的一個星期開展該項任務，但實際上直到4月的最後兩天我才有時間。記得當時，我花了一天半的時間與我的客戶——也就是我的同事，共同討論需求，並設計excel表格的格式，讓其評審。最終寫指令碼花費了4月的最後一個下午，以及五一期間的三個下午的時間，總計4個下午的時間，完成該工具的開發。而且我五一期間的工作並沒有申報加班，是無償勞動啊 : (

另外，令我欣喜的是，從此我成了我們組的牛人，哈哈哈哈。。。。。。

其實工具開發完成後，還是有些問題，如：

1、 程式崩潰(不小心除了0，呵呵，加入異常處理就ok了);

2、 有1/3的功能基本沒有被使用(鬱悶，花那麼大精力。。。我的五一啊);

3、自動生成的表格，奇醜無比(直到現在，我都沒改，哈哈)。

記得當時有個做了5年以上c++的開發人員，看到我寫的excel表格，居然說誒，這東西還滿神奇的嘛。我當時的一個感覺就是，暈，這個傢伙工作效率肯定不高。

excel還真是好用，功能強大啊!

四、負責m專案測試

20xx年10月份，我開始獨立負責m專案的測試工作。m專案是個小專案，大體情況如下：

程式碼量：大約10k行

開發語言：c#

軟體環境：windows ppc 20xx

硬體環境：hp的pda(具體型號忘了，反正是便宜貨，大概1000塊)

人力投入：開發3人，測試就我1人

m專案的測試需求分析、測試設計、測試用例編寫、測試執行到測試報告，全部由我一個人搞定

20xx年10月～12月中旬這段時間，主要是完成前期的測試分析與設計。12月中旬，就進入了實際的測試階段，20xx年1月底，軟體釋出。回顧這4個月的工作，有做的好的，也有做的差的。下面對這些進行總結。

做的比較好的：

1、 測試進度把握比較好，在規定時間內，甚至提前完成了測試任務;

2、 與開發人員的溝通較好，使問題能夠較順利的解決，基本沒有內耗，雙方合作愉快;

3、 測試的重點把握較好，把很多嚴重問題，在測試前期就給暴露出來了;

做的不好的，待改進的：

1、 前期的測試分析能力較弱，測試規格分析不全，測試用例編寫質量不是高。到後期測試時，才發現很多規格沒有覆蓋到，需要補充測試用例。而且之前寫的測試用例與實際測試情況，有些偏差，用例的可用性差，又花了很多時間去修改用例。

2、 前期的測試計劃制定比較差，實際工作較之計劃偏差過大。吳江裝飾網反正10月、11月那段時間，m專案的工作是亂七八糟的，還好關鍵時間點的把握還算到位。

3、 測試物件選擇上疏忽，導致漏測。m程式是個工具軟體，主要用於查詢和設定裝置的某些引數或配置。我當時只考慮到對所有支援的裝置進行遍歷，卻未考慮到裝置上所有單板的遍歷。結果技術支援工程師到香港試用該工具時，發現某塊叫pm1d的單板無法識別。後續，我們對大部分單板進行了遍歷，還發現了很多隱藏的問題。這是一項較大的疏忽。

4、 在做內部模擬試驗局測試時，對測試環境的選擇有較大疏忽，導致漏測。在做內部試驗局的時候，我為了偷懶只選擇了3個不同裝置的組網測試，而沒有考慮到大規模組網情況下的測試。後來，技術支援工程師拿m軟體到廣州試用時，程式的某項功能就不正常了，原因就是大規模組網時，通訊資料的傳輸是多包的，而m程式的底層函式沒有對多包的情況進行處理，導致該項功能不正常。當時，在其他實驗室是有類似環境的，而我卻為了偷懶 : (

雖然m專案的測試有很多不足，但是總體情況良好，我對產品的質量有信心 : )

五、救火

大概是20xx年7月份時，我們組組長跟我說，要派我到b組去學習3個星期。等我去了b組才發現自己是被派來救火的。來b組支援測試，主要是完成一項測試任務，說具體點，就是把一件事情幹600多次，沒任何技術含量。我當時真是鬱悶壞了 : (

雖然心底是比較鬱悶，但畢竟也就3個星期，想著忍忍就過去了。

具體的任務很簡單：大概有80種板子，每種板子大概有8套軟體，用t工具對80多塊板子把8套軟體都加一次，觀察軟體載入過程中，業務是否正常，板子加完軟體後，執行是否正常。

還有一個也是其他組借調過來的新員工，跟我一起幹這件事情。我600多次，他也差不多600次。還好這個傢伙，心態很好，做事情也很勤奮。

最初b組給的方案是這樣的：先用第1套軟體把80多個板子載入一遍，再用第2套，第3套，直到第8套。

開始工作幾天，我們就按這種方案執行，但按這種方案執行的效率很差。主要因為實驗室常用的板子差不多隻有30塊，其他的板子都藏在箱子裡，而且有些板子b組根本沒有，需要到其他專案組去借，這樣針對軟體版本，對80多塊板子進行輪循載入，效率就很低，因為每加一套軟體，就要去尋找80多塊板子。

當時，我和那個新員工都很愁，按照這種做法，這項任務3個星期根本就無法完成。b組負責帶我們的兩個員工，也表示比較無奈。

鬱悶過的第2天一早，我就直接找b組的老大談話，按照你們提供的這種方案，我們在三個星期內根本無法完成任務，而且還有諸多其他困難：1、部分板子是壞的;2、某些板子實驗室裡根本就沒有;3、對裝置不熟悉。

就這樣，b組老大把組內相關骨幹人員都叫過來開會，重新商討了一套方案，並要求他們全力支援我們的工作。

開了會後，b組的人就比較支援我們的工作了，啟用新的方案後，還提前了1天時間把工作完成 : )

這裡我體會比較深的是：在做一份工作前，一定要弄清楚這項任務到底要做些什麼、要怎麼做、要做到什麼程度，工作中還要定期彙報工作(基本上以日報、週報的形式，用郵件傳送)，如果出現瞭解決不了的困難，一定要向老大彙報，如果老大也解決不了，那他也不能責怪你無能 : )

六、工作中的陷阱

在辭職前的幾個月，有個師弟也是老鄉x君，得知我做過自動化專案後，便來向我瞭解自動化測試相關的情況。

從與x的聊天過程中瞭解到，他也正在做自動化，他們組測試的產品規模比較大，不過做自動化的只有兩個新人，而且是使用一種新的gui測試工具。他在給我講他們具體工作時，瞭解到他們的自動化測試非常原始，就是針對一個用例錄製一套指令碼，幾百個測試用例，大概錄製幾百個指令碼，根本沒有對公共進行提取，更別提有什麼自動化測試框架了。x君與另外一個人，在自動化方面都是新手，沒有相關經驗，他們不知道這樣做會給後期的維護帶來多大的麻煩。而且他們主管也不太懂gui測試的自動化，只是每天要他們彙報工作進度，期望在兩個月內完成那幾百個指令碼。

經過我細緻詢問後，我猜測他們做這項自動化工作，基本上是為了應付部門自動化考核而做的，而並非為了提高測試效率，保證產品質量。

我也可以體諒x君主管的難處：測試組人力本來就緊張，而部門又要考核自動化指標，他只有弄兩個人來應付一下部門的考核了。

這樣說來，x君和他另外一位同事就是受害者了，被安排做一件這麼沒意義的事情。對他們我只能表示同情了。

對於這類bt主管吩咐的沒啥意義的事情，我的體會就是能推掉不做就不做，如果實在推不掉，就完全按照他的意思做，他要怎麼做就怎麼做，要做成什麼樣就做成什麼樣。實在搞鬱悶了就老闆炒魷魚吧。

七、其他

記得剛進公司那一陣，對我們新員工有這樣那樣的培訓，估計轉正前至少被培訓了20門課吧。具體講的都是產品知識、測試技能、程式設計方面的東東。那些講課的老師水平也參差不齊，ppt寫的水準也有好有壞。總體感覺就是那些培訓是在浪費時間，如果自己看這些資料效果都要好很多。

在轉正前，作為新員工要給部門的老員工講課，講自己所學習過的知識，然後下面的老員工會發狂了似的問你問題。現在我感覺這種方式真的是一種非常好的檢驗方法，不但檢驗了你的學習情況還鍛鍊了你講解ppt的能力。

通過這種方式，我覺得自己在很多方面有提高：

1、 寫ppt的水平。後續工作中，寫ppt彙報工作，做的是又快，又漂亮。

2、 溝通能力。最初別人問我一個問題，我還沒完全理解他的意圖，就以自己的理解，淅瀝嘩啦的說了一堆別人不想知道的東東，搞得別人一頭霧水。此後，別人每問我一個問題，我都會先把他的意圖或意思搞搞清楚了，確認後，再以最精練的語言來回答他的問題。

3、 懂就是懂，不懂就別亂說。記得最早老員工問我一個我自己不是很懂的問題，我通常是按自己的理解方式，跟他胡吹一通。結果他再一細問，我就傻了。知道就知道，不知道就別亂說，這點很重要，尤其是在參加面試的時候，如果自己不是很動，別人一問你就會露餡。

測試工程師的工作總結篇2

伴隨著充實緊湊的工作生活，20__年的時間已經過去了。這一段時間裡有工作上的收穫，知識的豐富，經驗的增長，同時也暴露出很多問題和不足。

總結經驗，吸取教訓，我主要從幾個方面來對工作進行總結：工作的主要內容;其中的失敗和教訓以及成功和經驗;展望下一階段的工作，確定自己的目標。以此作為懲前毖後的記錄。

一、工作的主要內容

在20__年的工作中，我的總體任務是協助管理系統的後期測試，編碼，修改，文件編寫的工作，分解開來之後，我主要做了三件事：

1.編寫礦業權系統的各類文件;

2.礦業權系統的編碼及bug勘誤工作;

3.礦業權系統的測試工作。

下面依照時間來對我的工作進行介紹。

初踏入職場，進入專業的軟體製造公司，對我，一個沒有接觸過標準軟體製作過程的新人來說，起步就是一個很大的難題。若直接做開發，則業務不熟練，程式碼不規範，弊大於利;若僅做學習，則不能跟上專案的步伐，不能以最快的速度融入工作中去。

在我還在忐忑自己到底要做什麼工作的時候，任務已經下達了，首先進行礦業權系統的測試工作。這樣的好處在於能夠在測試的過程中，瞭解專案的整體佈局，瞭解專案中的業務邏輯，瞭解專案中尚未完成的工作並以此作為下個階段的工作目標。至此，入職工作順利起步。

在對礦業權系統進行測試之後，暴露了系統的諸多問題，測試過程中發現礦權系統沒有進行輸入限定，為了解決這個問題需要對整個系統的資料進行整理，我的下一個任務就是編寫礦業權系統的資料需求文件。在編寫該文件的過程中，對礦權系統進行了更深入的瞭解，為之後的bug勘誤工作奠定了一定的基礎。

完成了礦業權系統的資料需求文件的編寫之後，新的任務是對整個礦權的輸入資料進行輸入限定，在任務開始之處是極為困難的，幸而得到了同事們的幫助才得以順利完成任務。任務雖然完成，但是對輸入限定實現方法的一知半解以及任務完成過程中的不仔細，為之後發生的問題也埋下了苦果。

在對礦業權系統新增輸入限定完成之後，進入瞭解決程式小問題的階段，對礦權系統進行細微的縫補工作。這段時間是學習多於工作的，不同的問題督促我要每天和百度親密接觸數百次，又要勞煩諸位在百忙中的同事抽出時間來給我幫忙。雖然辛苦一點，但收穫卻是滿滿。

完成了系統的修補之後，我們的程式送到了四惠進行第一輪測試，在測試的一週裡，我主要是補充網路程式設計的基礎知識。

第一輪測試結果出來之後，我們專案組開始了緊張的第一輪礦業權系統bug勘誤工作。拿到bug列表之後，發現有一小半錯誤皆是因我而起，輸入限定問題很多，我也主動承擔了輸入限定部分的bug勘誤工作。

第一輪bug勘誤工作完成後，進行了第一輪了迴歸測試，測試結果已然不盡人意，仍然存在大量的問題需要修改，而且很多問題還是因我而起，輸入限定仍然存在大量問題，再一次進行修改之後，我們的程式送到了十五所進行所檢。

在進行所檢之餘，我又接到了新的任務，完成礦權系統的概要設計以及詳細設計文件的編寫。這兩份文件已於9月2號編寫完畢。

現階段我的任務是根據所檢的bug列表，對礦權系統進行迴歸測試。

二、工作中失敗的教訓以及成功的經驗

對於失敗的教訓要吸取，成功的經驗要進行總結。我對成功的定義是：在保證質量的前提下完成既定的計劃或目標就是成功。其他的所有結果都是失敗。

成功的經驗：

1) 敢於接受任務並想盡一切辦法完成

最大的收穫就是敢於接受任務並想盡辦法完成，每一個任務對於初入職場的我都是一個挑戰，如何保質保量完成任務是最基本的要求。這兩月最大的成功在於沒有一次任務是拖沓的，每次都盡最大努力完成了任務。

2) 勇於承擔錯誤，正視自身的問題

工作中可謂是錯誤不斷，從文件的錯別字這種小問題到礦權系統bug修改不正確導致崩潰這種大錯誤，暴露出來了很多的問題，我秉承著有錯即改，下不為例的思想，正視自己的錯誤並積極改正，因此這也算是一個成功。

失敗的教訓：

1) 重視每一個細節，不要忽視小問題

在最初進行礦業權系統資料需求文件的編寫的過程中，對某些頁面的資料在資料庫中沒有儲存的情況沒有加以重視，在後期進行資料限定的時候，還要重新修改資料需求文件，造成了不必要的時間浪費。從這個事情上得到教訓就是不要放過任何一個小問題，這個小問題可能導致之後的大問題。

2) 進行重複工作也不能大意

在對礦權系統進行輸入限定的方法熟悉之後，都是重複性的工作，給每個頁面，每個欄位進行輸入控制語句的新增，在進行了數個頁面之後，出現了有的頁面沒有新增完整，或者提示語句不正確的情況，在後續的bug勘誤中出現了大量此類問題，浪費了大量的時間和精力修改。

從這個事情上得到的教訓就是工作不能大意，重複性的工作更要完成好。一般重複性的工作第一次做不好，後續檢查修改是非常浪費時間的。

3) 考慮問題要嚴謹

在對礦權系統bug勘誤的過程中，對輸入限定條件的判斷出了問題，我想當然的按照我的主觀思路對資料進行了限定，而在迴歸測試的時候出了問題，這些都是考慮不嚴謹的後果。這個事情的教訓就是考慮不嚴謹直接導致問題推倒重來，影響了工作效率，而且很容易埋下隱患。

4) 注重使用者體驗

在礦權系統bug勘誤的過程中，修改最多的在於座標系統的提示語句，因為座標系統不僅要求資料必須填入，而且每一個數據都有嚴格的格式限定，因此每一個錯誤提示的彈出都要本著如何讓使用者知道哪裡錯了為原則進行設定。

在最初的限定裡面，語句粗糙，彈出語句不明確，造成了使用者使用的不方便，還得重新進行改造。這個問題的教訓是一定要從使用者的角度出發考慮問題，注重使用者體驗從簡單的提示語句做起。

三、展望下一階段的工作

下一階段短期內我們的工作主要針對礦權系統的使用的資料庫變更來對我們的系統進行修改。我的工作任務主要是學習oracle資料庫和sql資料庫的使用上的區別，做好從sql資料庫向oracel資料庫的遷移工作。

20__年的工作生活是充實且富有樂趣的，結識了很多同事和朋友，公司的氛圍是非常輕鬆愉快的。感謝兩個月來李鵬經理的關心，感謝部門同事的悉心指導，感謝公司各位同事的熱心幫助，希望能在接下來的工作中能懲前毖後，總結經驗，吸取教訓，做到個人與公司共榮辱同進退，共同實現中地的輝煌。

測試工程師的工作總結篇3

這個學期我學習了軟體測試這門專業課程，在學期即將結束的時候，我也對這門課程建立基本的瞭解和理解。軟體測試這門課程作為軟體工程專業中一門很重要的課程，已經在軟體領域佔據了不可替代的角色，當一個軟體從雛形到真正的在一臺計算機上執行的時候，誰也不能保證計算機軟體能一步到位的滿足人們的需求。所以就有了軟體測試，其目的是：第一是確認軟體的質量，其一方面是確認軟體做了你所期望的事情，另一方面是確認軟體以正確的方式來做了這個事件。下面我簡單的寫一下這個學期對課程的總結和收穫。

我認為，在整個龐大的軟體工程中，不管是需求分析、架構設計甚至是最後的debug，都會產生引入不管的機會，這就要求作為一個軟體測試師要掌握豐富的軟體工程原理和知識。測試的工作將會存在於整個專案週期，即在專案開始時需要各種分析調研時就開始了。尤其是在形成需求規格說明書時就有對文件的測試需求，甚至主導整個專案的走向。

軟體測試對邏輯思維、學習能力、反應要求很高，是否有嚴密的思維和逆向思維也非常重要。做測試還要考慮到所有出錯的可能性，有時候還要用一些非常規的的測試方法。軟體測試還很注重軟體效能問題，也就是要保證軟體執行得很好;不同的使用環境下，考慮軟體的相容性同樣重要。對於測試員來講，會比開發人員更加重視軟體產品的質量問題。在測試過程中，測試者可能會為客戶的需求角度考慮到更多，由此我們可以認為測試人員有權利決定產品是否可以釋出。然而，通過一個學期的學期，我們又不得不懂得，軟體測試人員不是萬能的，測試人員在面對一個設計爛編碼爛的軟體時，也是無法不低頭的，再怎麼測試它也變不成優秀的軟體。

通過課上的理論因為課下的實踐和後半學期又因為身體力行於

1、最基本的測試的分類：從是否需要執行被測軟體的角度，可分為靜態測試和動態測試;從測試是否針對系統的內部結構和具體實現演算法的角度來看，可分為白盒測試和黑盒測試。

2、然後就是，白盒測試中的邏輯驅動測試的覆蓋率測試。

3、還有就是對於劃分等價類和邊界值法這一塊，讓我從模糊到明朗。

4、在初次寫測試用例的時候，感覺真是糾結，用例寫的很死板，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且還很慢。在後來負責了對論壇新鮮事版塊的測試之後，明白了測試用例其實就是指導怎麼去執行測試，而且書寫設計測試用例也要以熟悉軟體的業務為前提，才能更好的去測試。

另外就是一個學期的學習讓我糾正了幾點誤區：

1、有位大師曾說過：“軟體測試的目的在於發現錯誤，一個好的測試用例在於發現從來未發現的錯誤，一個成功的測試是發現了從未發現的錯誤的測試。”由此我自認為測試就是為了找到bug，然而一個學期的測試學習經驗告訴我這是錯誤的，如果只是為了找到bug，那麼bug會成天纏著你。

2、在大家協力測試論壇的時期內，我曾認為這種大量的重複性的工作真的很乏味，可是在這乏味中真心發生挺多有意思的bug，意想不到的bug，所以我認為只要掌握了方法，在重複中尋到到創新的小驚喜，任何東西都有它的特點。

作為測試新手，通過一學期的學習，我認為能獨立寫測試計劃，設計測試用例，精通一種測試工具，理解一種bug管理軟體是新手晉級老手的必備素質。任重而道遠?!

在最後，我不得不提的就是細心和耐心了。這是我認為這個學期測試課上收穫的了，課程要求測試時必須細心和耐心，我在想，如果以後真的工作在測試一系列的崗位上，要學會坐得住，用大量的時間和精力和bug鬥爭，分離、識別還有歸類bug，是不是也能真的改變我粗心大意和三分鐘熱度的毛病。

最後感謝劉老師這學期的課程講授，和實踐中的指導和幫助。測試路程，路漫漫其修遠兮，吾將上下而求索。

測試工程師的工作總結篇4

1、分享第一條經驗：“學歷代表過去、能力代表現在、學習力代表未來。”其實這是一個來自國外教育領域的一個研究結果。相信工作過幾年、十幾年的朋友對這個道理有些體會吧。但我相信這一點也很重要：“重要的道理明白太晚將抱憾終生!”所以放在每一條，讓剛剛畢業的朋友們早點看到哈!-

2、一定要確定自己的發展方向，併為此目的制定可行的計劃。不要說什麼，“我剛畢業，還不知道將來可能做什麼?”，“跟著感覺走，先做做看”。因為，這樣的觀點會通過你的潛意識去暗示你的行為無所事事、碌碌無為。一直做技術，將來成為專家級人物?向管理方向走，成為職業經理人?先熟悉行業和領域，將來自立門戶?還是先在行業裡面混混，過幾年轉行做點別的?這很重要，它將決定你近幾年、十年內“做什麼事情才是在做正確的事情!”。-

3、軟體開發團隊中，技術不是萬能的，但沒有技術是萬萬不能的!在技術型團隊中，技術與人品同等重要，當然長相也比較重要哈，尤其在mm比較多的團隊中。在軟體專案團隊中，技術水平是受人重視和尊重的重要砝碼。無論你是做管理、系統分析、設計、編碼，還是產品管理、測試、文件、實施、維護，多少你都要有技術基礎。算我孤陋寡聞，我還真沒有親眼看到過一個外行帶領一個軟體開發團隊成功地完成過軟體開發專案，哪怕就一個，也沒有看到。倒是曾經看到過一個“高學歷的牛人”(非技術型)帶一堆人做完過一個專案，專案交付的第二天，專案組成員扔下一句“再也受不了啦!”四分五裂、各奔東西。那個專案的“成功度”大家可想而知了。-

4、詳細制定自己軟體開發專業知識學習計劃，並注意及時修正和調整(軟體開發技術變化實在太快)。請牢記：“如果一個軟體開發人員在1、2年內都沒有更新過自己的知識，那麼，其實他已經不再屬於這個行業了。”不要告訴自己沒有時間。來自時間管理領域的著名的“三八原則”告誡我們：另外的那8小時如何使用將決定你的人生成敗!本人自畢業以來，平均每天實際學習時間超過2小時。-

5、書籍是人類進步的階梯，對軟體開發人員尤其如此。書籍是學習知識的最有效途徑，不要過多地指望在工作中能遇到“世外高人”，並不厭其煩地教你。對於花錢買書，我個人經驗是：千萬別買國內那幫人出的書!我買的那些傢伙出的書，!00%全部後悔了，無一本例外。更氣憤的是，這些書在二手市場的地攤上都很難賣掉。“擁有書籍並不表示擁有知識;擁有知識並不表示擁有技能;擁有技能並不表示擁有文化;擁有文化並不表示擁有智慧。”只有將書本變成的自己智慧，才算是真正擁有了它。-

6、不要僅侷限於對某項技術的表面使用上，哪怕你只是偶爾用一、二次。“對任何事物不究就裡”是任何行業的工程師所不應該具備的素質。開發windows應用程式，看看windows程式的設計、載入、執行原理，分析一下 pe檔案格式，試試用sdk開發從頭開發一個windows應用程式;用vc++、 delphi、java、。net開發應用程式，花時間去研究一下mfc、vcl、j2ee、。net它們框架設計或者原始碼;除了會用j2ee、 jboss、spring、hibernate等等優秀的開源產品或者框架，抽空看看大師們是如何抽象、分析、設計和實現那些類似問題的通用解決方案的。試著這樣做做，你以後的工作將會少遇到一些讓你不明就裡、一頭霧水的問題，因為，很多東西你“知其然且知其所以然”!-

7、在一種語言上程式設計，但別為其束縛了思想。“程式碼大全”中說：“深入一門語言程式設計，不要浮於表面”。深入一門語言開發還遠遠不足，任何程式語言的存在都有其自身的理由，所以也沒有哪門語言是“包治百病”的“靈丹妙藥”。程式語言對開發人員解決具體問題的思路和方式的影響與束縛的例子俯拾皆是。我的經驗是：用面對物件工具開發某些關鍵模組時，為什麼不可以借鑑c、c51、彙編的模組化封裝方式?用傳統的桌面開發工具(目前主要有vc++、delphi)進行系統體統結構設計時，為什麼不可以參考來自 java社群的ioc、aop設計思想，甚至借鑑像spring、hibernate、jboss等等優秀的開源框架?在進行類似於實時通訊、資料採集等功能的設計、實現時，為什麼不可以引用來自實時系統、嵌入式系統的優秀的體系框架與模式?為什麼一切都必須以個人、團隊在當然開發語言上的傳統或者經驗來解決問題“他山之石、可以攻玉”。-

8、養成總結與反思的習慣，並有意識地提煉日常工作成果，形成自己的個人原始碼庫、解決某類問題的通用系統體系結構、甚至進化為框架。眾所周知，對軟體開發人員而言，有、無經驗的一個顯著區別是：無經驗者完成任何任務時都從頭開始，而有經驗者往往通通過重組自己的可複用模組、類庫來解決問題 (其實這個結論不應該被侷限在軟體開發領域、可以延伸到很多方面)。這並不是說，所有可複用的東西都必須自己實現，別人成熟的通過測試的成果也可以收集、整理、整合到自己的知識庫中。但是，最好還是自己實現，這樣沒有智慧財產權、版權等問題，關鍵是自己實現後能真正掌握這個知識點，擁有這個技能。-

9、理論與實踐並重，內外雙修。工程師的內涵是：以工程師的眼光觀察、分析事物和世界。一個合格的軟體工程師，是真正理解了軟體產品的本質及軟體產品研發的思想精髓的人(個人觀點、歡迎探討)。掌握軟體開發語言、應用語言工具解決工作中的具體問題、完成目標任務是軟體工程師的主要工作，但從軟體工程師這個角度來看，這只是外在的東西，並非重要的、本質的工作。學習、掌握軟體產品開發理論知識、軟體開發方法論，並在實踐中理解、應用軟體產品的分析、設計、實現思想來解決具體的軟體產品研發問題，才是真正的軟體工程師的工作。站在成熟理論與可靠方法論的高度思考、分析、解決問題，並在具體實踐中驗證和修正這些思想與方式，最終形成自己的理論體系和實用方法論。

測試工程師的工作總結篇5

時光荏苒，如今20xx年的帷幕已經謝下，20xx年的鐘聲已經敲響，在公司高層的正確領導下，我們佰騰科技又走過了一年。而我也在自己的努力以及同事的幫助下完成了20xx年我所負責的工作，以下就是我對過去這一年的工作總結：

一、測試工作及經驗

作為軟體部測試組的一員，首先要做好的就是自己的本職工作，我在20xx年中所做的工作主要有：

測試用例的編寫，對系統的測試、跟蹤;

需求、高保圖、介面和功能的測試;

功能測試用例的編寫，高保圖、系統的測試;

的靜態頁面測試和功能測試;

的功能測試;

第一、二、三迭代高保圖測試，測試用例編寫，靜態頁面和功能測試，並主持參與測試用例評審;

平臺高保圖的測試和系統靜態頁面、功能的測試;

的高保圖測試和測試用例的編寫;

的靜態頁面和功能測試，參與測試用例的評審;

的高保圖測試、靜態頁面和功能測試;

使用者使用手冊的編寫;

一年的工作，讓我獲得很多方面的經驗：

1.編寫邏輯覆蓋率全的測試用例甚為重要。

在理解需求的前提下編寫測試用例，使得我掌握了多種測試用例編寫方法，更讓我對產品的需求有更加深入的理解，須知對需求是否理解透徹決定了能否有效、全面地對產品進行測試;

2. 要站在使用者角度對系統進行測試。從一些專案中出現的未能及時發現的bug中，我認識到使用者體驗的重要性，現在能夠越來越多的從這方面來執行測試;

3.對拿到手的專案有較清晰的思路，能夠更加快速、準確地發現問題;

4.越來越規範的工作流程的讓我們的工作有條不紊的進行，讓我深刻認識到工作的規範性是多麼的重要，並且從中學習如何從文件和流程上規範工作。

5.同事間的溝通很重要。現在不管遇到什麼不確定或疑惑，都與開發人員、產品經理等及時溝通，大大提高了工作的效率。

二、加強自我能力的提高

只有不斷的提高自己各種的能力，才能勝任越來越艱鉅的任務，因此在工作相對不飽和的時候，我自己進行了一些學習。

為提高對使用者體驗的理解，我學習了《下一站使用者體驗》，書中一些經驗確實讓我獲益匪淺。不能總拿別人的使用者體驗去改進自己的產品，但是有一些卻是通用的，比如：太多彈出框、按鈕會給使用者帶來憤怒感，要適當的給頁面減肥等等。

深知單純的介面測試和功能測試已經漸漸不能滿足今後平臺的開發，所以我學習了效能測試的一些相關知識，並在師父的指導下運用lr工具進行簡單效能測試，以後必須堅持學習。

三、存在的不足及明年計劃

一年的工作讓我有所進步，但是很多地方還是存在不足，比如：有時候看問題比較主觀，不是很細緻，沒能深入地去測試，會有遺漏的bug;自身專業技術能力還不足，不能從系統穩定性這一點上對系統進行測試。在以後的工作中，我會努力改善。

在20xx年的工作中，我計劃：

1、本著實事求是的態度，更加認真、負責的完成工作;

2、要儘可能深刻的理解需求，堅持編寫覆蓋率強的測試用例;

3、按照系統穩定性測試方案，要逐漸對系統的穩定性、安全性進行測試;

4、繼續研究效能測試，並要將lr工具運用在實際工作中;

5、多多的學習，參加一些有益的培訓，在實際工作中活學活用。

四、個人建議

這一年來我們部門有著的顯著進步，越發規範的工作流程，越來越明確的責任制度、管理體系等，都讓我們更加有凝聚力。在此，個人提出以下幾個小建議：

1、希望可以加強對專案的把控，儘量能將延期風險降到最低;

2、從各個組對需求理解的不一致，以及資訊更新不及時等問題上看，溝通問題還是有待完善;

3、希望能夠在需求這一關卡上能更詳細、準確的確定產品的功能要求;

4、雖然工作任務繁重，還是希望部門能夠多組織活動，完善獎勵制度，可以讓大家更加激情的為部門、為公司奉獻自己的全部力量。

以上是我個人的一些淺見，相信在大家共同的努力下，向著同一個目標進發，軟體部甚至整個公司必定會大展全新的巨集圖偉業。