軟體質量越來越受到人們的關注，軟體測試作為新興行業有很多不完善的地方。下面小編整理了軟體測試工程師工作總結，希望對你有幫助。
軟體測試工程師工作總結篇一
現在軟體測試工作越來越收到企業的重視，許多人員也投入到軟體測試的行列中來，軟體測試工程師的隊伍越來越壯大。但是如何成為一名優秀的軟體測試工程師呢?這是大家比較關注的一個問題，尤其是初入這個行當的萊鳥更想了解這個問題的答案。本文根據自己多年來在IT公司從事軟體測試的經驗總結了一些東西給大家共享，同時也希望大家提出寶貴的意見和建議。
步驟/方法
起碼有三年以上的軟體開發經驗
現在許多軟體企業招收一些剛剛畢業的大學生或者非計算機專業的人員作為自己公司軟體測試工程師，這是非常錯誤的，也是對軟體測試不負責任的表現。雖然他們可以發現軟體中的一些錯誤，但是對於軟體中的一些關鍵，致命，危險的錯誤他們是很難發現的。大家都知道，軟體工程中有個模型叫瀑布模型，這是最基本的軟體模型，這個模型又叫碗狀模型，因為開發位於碗的最底部，左上方依次為建模，需求分析，設計;右上方依次為測試，部署，維護。這就是說明軟體開發是一切軟體活動的基礎，同時也是軟體測試的基礎。一個人只有經歷過一定年限的軟體開發工作，才可以積累豐富的經驗，知道在軟體中哪些地方容易出錯而那些地方不容易，這給以後的軟體測試工作帶來非常寶貴的經驗。
有逆向思維的能力
我曾經接觸過一些軟體測試工程師，他們幹了一段時間軟體測試工作後返回去又開始去做開發工作了，問他們為啥?答案是軟體測試工作太難了，開發是順向思維，而測試是逆向思維，老要找一些稀奇古怪的思路去操作軟體。軟體的使用者千差萬別，軟體在使用過程中遇到的各種現象也是千差萬別的，所以要求軟體測試工程師需要具有一些逆向思維的能力，想別人所不想，測別人所不測，這樣才可以找到更多的軟體中的錯誤。這是作為一名優秀的軟體測試工程師最基本的素質。
善於同軟體開發人員溝通
溝通是當今軟體項目中需要掌握的最關鍵技術之一。軟體測試人員要善於同軟體開發人員溝通，軟體測試人員與開發人員搞好關係，使測試人員不成為開發人員的眼中釘，這對於提高整個軟體項目質量是十分重要的。溝通主要包括：
討論軟體的需求，設計：通過這樣的溝通，你可以更好的了解所測試的軟體系統，以至於儘可能少的測試出軟體中不是錯誤的“錯誤”，從而降低給軟體開發人員帶來的壓力。
報告好的測試結果：作為一個測試人員，發現錯誤往往是測試人員最願意而且引以自豪的結果，但是一味地給開發人員報告軟體錯誤，會給他們造成厭惡感，降低整個軟體的質量和開發進度。所以作為一名軟體測試工程師，當你測試的模組沒有嚴重的錯誤或者錯誤很少的時候，你不妨跑到開發人員那裡告訴他們這個好訊息，這會給你帶來意想不到的結果。
討論一些與工作無關的事情：作為一個測試人員經常和開發人員討論一些與工作無關的事情，比如大家可以談談新聞，趣事，家庭…這樣可以加強相互間的默契程度，許多統計表明，這樣可以更好的提高軟體工作質量。
善於同領導溝通
測試人員往往是領導的眼和耳，領導根據測試人員的測試結果可以了解公司的產品質量，從而調整其他的工作。領導工作一般比較繁忙，所以作為一名優秀的測試人員要學會把測試結果進行總結，最好以圖表的形勢給領導看。
掌握一些自動化測試工具
測試工作往往是比較繁瑣，枯燥無味的工作，測試人員長期處於重複的手工工作，會降低測試效率，並且對於測試質量也往往是不利的;況且許多測試不使用測試工具是不可以進行的，比如性能測試，壓力測試等等。目前市場上有許多測試工具供你使用，你可以根據自己的需要選擇一些測試工具來輔助你的測試。但是要記住一點，不是說有了測試工具就不要人工測試了，測試工具不是萬能的。
善於學習的能力
軟體測試技術隨著時間的變化也在做一些提高和改進，作為一名優秀的測試人員要善於利用書籍，網站，論壇，交流等各種途徑不斷提高自己的軟體測試水平。
7
提高自己的表達能力
軟體測試人員當發現軟體中存在缺陷的時候，往往要書寫缺陷報告，缺陷報告要寫得詳盡清楚，使開發人員能夠儘快定位錯誤，修改錯誤，所以作為一名優秀的測試人員提高自己的寫作能力是非常必要的。
8
了解業務知識
更好的了解你說測試軟體的業務知識是非常重要的，對業務知識了解得越深入，越能夠找出更深入，更關鍵，更隱蔽的軟體錯誤。所以作為一名優秀的軟體測試工程師，要多向該領域專家，同行學習，提高自己的業務知識水平。
以上僅為個人的一些經驗所談，希望大家都能夠成為一名優秀的軟體測試工程師。
軟體測試工程師工作總結篇二
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、理論與實踐並重，內外雙修。工程師的內涵是：以工程師的眼光觀察、分析事物和世界。一個合格的軟體工程師，是真正理解了軟體產品的本質及軟體產品研發的思想精髓的人(個人觀點、歡迎探討)。掌握軟體開發語言、套用語言工具解決工作中的具體問題、完成目標任務是軟體工程師的主要工作，但從軟體工程師這個角度來看，這只是外在的東西，並非重要的、本質的工作。學習、掌握軟體產品開發理論知識、軟體開發方法論，並在實踐中理解、套用軟體產品的分析、設計、實現思想來解決具體的軟體產品研發問題，才是真正的軟體工程師的工作。站在成熟理論與可靠方法論的高度思考、分析、解決問題，並在具體實踐中驗證和修正這些思想與方式，最終形成自己的理論體系和實用方法論。
軟體測試工程師工作總結篇三
先介紹一下我的背景：通信類院校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軟體還真的是我們測出來的，而不是開發寫出來的 : )