第一篇：測試工程師 6年工作經驗總結

[測試工程師 6年工作經驗總結 觀后感]

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

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等等優秀的開源產品或者框架，抽空看看大師們是如何抽象、分析、設計和實現那些類似問題的通用解決方案的，觀后感《測試工程師 6年工作經驗總結 觀后感》。試著這樣做做，你以后的工作將會少遇到一些讓你不明就里、一頭霧水的問題，因為，很多東西你“知其然且知其所以然”！

7、在一種語言上編程，但別為其束縛了思想。“代碼大全”中說：“深入一門語言編程，不要浮于表面”。深入一門語言開發還遠遠不足，任何編程語言的存在都有其自身的理由，所以也沒有哪門語言是“包治百病”的“靈丹妙藥”。編程語言對開發人員解決具體問題的思路和方式的影響與束縛的例子俯拾皆是。我的經驗是：用面對對象工具開發某些關鍵模塊時，為什么不可以借鑒C、C51、匯編的模塊化封裝方式？用傳統的桌面開發工具(目前主要有VC++、Delphi)進行系統體統結構設計時，為什么不可以參考來自Java社區的IoC、AOP設計思想，甚至借鑒像Spring、Hibernate、JBoss等等優秀的開源框架？在進行類似于實時通信、數據采集等功能的設計、實現時，為什么不可以引用來自實時系統、嵌入式系統的優秀的體系框架與模式？為什么一切都必須以個人、團隊在當然開發語言上的傳統或者經驗來解決問題？？？“他山之石、可以攻玉”。

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

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

10、心態有多開放，視野就有多開闊。不要抱著自己的技術和成果，等到它們都已經過時變成垃圾了，才拿出來丟人現眼。請及時發布自己的研究成果：開發的產品、有創意的設計或代碼，公布出來讓大家交流或者使用，你的成果才有進化和升華的機會。想想自己2000年間開發的那些Windows系統工具，5、6年之后的今天，還是那個樣子，今天流行的好多Windows系統工具都比自己的晚，但進化得很好，且有那么多用戶在使用。并且，不要保守自己的技術和思想，盡可能地與人交流與分享，或者傳授給開發團隊的成員。“與人交換蘋果之后，每個人還是只有一個蘋果；但交換思想之后，每個人都擁有兩種思想”，道理大家都懂，但有多少人真正能做到呢？

11、盡量參加開源項目的開發、或者與朋友共同研制一些自己的產品，千萬不要因為沒有錢賺而不做。網絡早已不再只是“虛擬世界”，網上有很多的開源項目、合作開發項目、外包項目，這都是涉獵工作以外的知識的絕好機會，并且能夠結識更廣的人緣。不要因為工作是做ERP，就不去學習和了解嵌入式、實時、通信、網絡等方面的技術，反過來也是一樣。如果當他別人拿著合同找你合作，你卻這也不會，那也不熟時，你將后悔莫及。

12、書到用時方恨少，不要將自己的知識面僅僅局限于技術方面。諾貝爾經濟學獎得主西蒙教授的研究結果表明：

“對于一個有一定基礎的人來說，他只要真正肯下功夫，在6個月內就可以掌握任何一門學問。”教育心理學界為感謝西蒙教授的研究成果，故命名為西蒙學習法。可見，掌握一門陌生的學問遠遠沒有想想的那么高難、深奧。多方吸取、廣泛涉獵。極力夯實自己的影響圈、盡量擴大自己的關注圈。財務、經濟、稅務、管理等等知識，有空花時間看看，韜光養晦、未雨綢繆。

13、本文的總結與反思： A：不要去做技術上的高手，除非你的目標如此。雖然本文是關于提高軟件開發知識的建議，做技術的高手是我一向都不贊同的。你可以提高自己的專業知識，但能勝任工作即止。

B：提高軟件知識和技術只是問題的表面，本質是要提高自己認識問題、分析問題、解決問題的思想高度。軟件專業知識的很多方法和原理，可以很容易地延伸、應用到生活的其它方面。

C：在能勝任工作的基礎上，立即去涉獵其它領域的專業知識，豐富自己的知識體系、提高自己的綜合素質，尤其是那些目標不在技術方面的朋友。

〔測試工程師 6年工作經驗總結 觀后感〕隨文贈言：【人生舞臺的大幕隨時都可能拉開，關鍵是你愿意表演，還是選擇躲避。】

第二篇：測試工作經驗總結

測試工作經驗總結

功能測試最重要的是理解業務和需求。知道系統要實現什么功能，業務流程是怎樣的，然后就可以根據需求編寫測試計劃和測試用例了。測試書籍上介紹常用的編寫測試用例的方法有：等價類、邊界值、因果圖、判定表等，在實際工作中，我使用較多的有等價類、邊界值、場景法和錯誤猜測法。在這里需要提一點，將測試用例按測試目的進行分類，比如用戶界面、功能點、業務場景等，會讓測試用例的結構看起來更清晰，執行測試用例的效率也更高。

要做好功能測試，還需要對整個系統的數據庫結構比較清楚，每個功能點涉及哪些數據表，對數據的操作方式是怎樣的。這樣就不單從前臺頁面來進行測試，通過對數據庫中數據的驗證，可以發現隱藏的一些bug。比如庫表沒有進行關聯刪除，從前臺頁面是看不出來的，但實際可能導致程序出現問題。對一些比較復雜的組合查詢或數據排序，也可以自己編寫sql語句對結果進行驗證。

了解程序的框架結構和一些開發知識也有助于更好地測試程序和定位錯誤。

測試用例的編寫經驗步驟和數據的分離

將輸入的各種數據已參數的形式表達在操作步驟中，而不需要為每一種輸入數據創建一個測試用例。

例如：atm存款

好的測試用例，在執行的步驟(Step)的表達上應該是盡可能和數據相分離。舉例來講，有一個ATM機取款的功能，可能有以下幾個場景：

1.密碼正確的登錄

2.密碼錯誤的登錄

3.密碼輸入三次錯誤，卡被鎖定

4.取少于余額的款項

5.嘗試取大于余額的款項

6.嘗試取等于余額的款項(考慮手續費)

6.取款額度大于當次的限制

7.取款額度大于當天的限制

7.取款次數大于限制次數

等等

不管你用什么用例設計的方法論來做指導，作為這個簡單的例子，有經驗的人都應該能看出，此處的很多步驟是可以重用的，總結下來如下(此處只列出了操作的步驟，略去了系統的交互中的反饋結果)：

1.插入卡->A:輸入密碼->B:按“確定”鍵->重復A-B

2.A:選擇取款功能->B:填寫取款金額->C:點擊“確定取款”的按鈕->D:取現金->重復A-D

因此，我們只需要寫出兩套比較完整的步驟，將密碼和取款金額多數字用參數來表達即可。這樣是不是簡單了很多呢?單獨的測試基礎數據準備工作

將測試基礎數據提前準備好，寫到你單獨的測試數據準備文檔中，而不是分散到 所有使用到它的case中才去描述。測試用例的前后置條件

除了第二點中談到的數據需要準備外，在測試用例這個Level，必須有一些條件滿足，您才能開始執行它。集中的把這些步驟整理成一個相對獨立的操作單元，具體用例中只要引用就可以了，這樣會便于對用例的理解和在多處復用。

順便說一下，對于一些類似軟件運行環境的條件，比如安裝和配置測試中，需要3種操作系統和3種瀏覽器的組合等，我們可以把他放在Test Set這個Level上來，不用寫多個用例，只是在測試計劃和執行的管理系統中作為測試集的一個環境參數，恰當地表達出來就可以。

第三篇：軟件測試工程師面試經驗總結

首先說明我算上找實習的時候的面試總共就經歷了不到5次，沒有多少經驗，就在網上和書上摘錄了些我認為比較重要的，分享給大家，希望各位都能找到一份適合自己的好工作。1.筆試題

對于筆試，有的公司筆試題是不區分開發和測試崗位的，測試人員除了要掌握好測試的基本知識外最好也是有編程基礎，具有盡量多的計算機的知識，像操作系統的基本知識（線程等），數據庫的基本操作（增刪改查，關聯查詢，授予權限等），數據結構的知識（像二叉樹的前序、中序、后序查詢）。2.面試

如果在筆試中沒有考測試的基本知識，那在面試中是肯定要被問到的。面試前一定要做好準備，可以在網上搜一下關于這個公司的筆試題和面試題，以供參考。如果時間充裕可以找一本自己能看的進去的講軟件測試的書，認真的有側重點的看看。軟件測試的幾個主要的階段，不一定死記硬背能用自己的話說出來也可以或者能舉例說明，那幾個主要的白盒和黑盒的測試方法能熟練的應用到實際的例子中，等價類劃分和邊界值分析經常被問到。

每個公司做的項目都不一樣，最好先了解下要應聘的那家公司主要是做哪方面的，比如對美外包的公司就要求英語水平，能看懂英文文檔甚至能同外國人交流，最好能提前先看些英語的文章，準備下英文的自我介紹，臨時提高下英語水平。

我被問到的面試題（答案僅供參考）

1.為什么不考研？

2.想要一份什么樣的工作

3.做軟件測試人員需要具備什么樣的職業素質

（1）專業技能，包括測試的技能和開發的技能（2）積極的態度

（3）良好的溝通能力（4）細心（5）耐心

（6）團隊意識 4.對他們公司的了解

5.再就是些工作地點能否接受，有沒有男朋友之類的基本問題 以下是針對實習項目問的問題（答案僅供參考）

6.缺陷報告有幾個狀態，都包括哪些內容

狀態：新建，打開，修復，關閉，重復的bug，無效的bug，被拒絕的bug，其他 內容：：標題、模塊名稱、項目名稱、測試環境、重現步驟、期望結果、實際結果、嚴重級、優先級、發現人、接收人和附件（截圖，說明等）。7.有一個文本框，只能輸入0-5個字母的組合，如何進行測試 從字符串的長度考慮，按照邊界值方法設計測試用例

從字符串的組成內容考慮，按照等價類劃分方法設計測試用例 8.簡單的說一下性能測試和壓力測試 9.寫過自動化測試的腳本嗎

10.我實習的項目是一個金融的網站，技術的面試官問我，商品的價格是左對齊還是右對齊（對于這個問題我也不知道為啥會被問到，有什么具體的含義，猜想可能是判斷我的項目經驗是否真實）

下面是我網上摘錄的一些可能被問到的面試題

1.您認為做好測試用例設計工作的關鍵是什么？

答：白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果

黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題

2.在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

3.談一些自己在以往的學習和工作中獲得的工作經驗和心得體會？（可以包括軟件測試、過程改進、軟件開發或者與此無關的其他方面

4.什么是軟件測試。

5.Alpha 測試與beta 測試的區別。

6.測試結束的標準是什么？

7.測試項目：杯子

需求測試:查看杯子使用說明書 界面測試:查看杯子外觀

功能度：用水杯裝水看漏不漏；水能不能被喝到 安全性：杯子有沒有毒或細菌

可靠性：杯子從不同高度落下的損壞程度

可移植性：杯子再不同的地方、溫度等環境下是否都可以正常使用 兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等 易用性：杯子是否燙手、是否有防滑措施、是否方便飲用

國際化：杯子上的圖案有沒有觸犯到某個國家或宗教的禁忌

用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述 疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等

壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透 跌落測試: 杯子加包裝(有填充物),在多高的情況摔下不破損

震動測試: 杯子加包裝(有填充物),六面震動,檢查產品是否能應對惡劣的鐵路公路航空運輸

測試數據：測試數據具體編寫此處略（最討厭寫測試數據了）。其中應用到：場景法、等價類劃分法、因果圖法、錯誤推測法、邊界值法等方法

期望輸出：該期望輸出需查閱國標、行標以及使用用戶的需求 說明書測試: 檢查說明書書寫準確性

給大家提三個產品:1.手機 2.電飯鍋 3.電梯

8.圖書（圖書號，圖書名，作者編號，出版社，出版日期）

作者（作者姓名，作者編號，年齡，性別）

用SQL語句查詢年齡小于平均年齡的作者姓名、圖書名，出版社。

9.軟件測試分為幾個階段 各階段的測試策略和要求是什么

10.您認為在測試人員同開發人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其他成員良好的人際關系的關鍵是什么？

11.請以您以往的實際工作為例，詳細的描述一次測試用例設計的完整的過程

12.您認為做好測試計劃工作的關鍵是什么？

13.您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。

14.測試計劃工作的目的是什么？測試計劃工作的內容都包括什么？其中哪些是最重要的？ 答：軟件測試計劃是指導測試過程的綱領性文件，包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。

測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）

15.為什么要在一個團隊中開展軟件測試工作？ 答：因為沒有經過測試的軟件很難在發布之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測試報告中得出軟件的質量情況。

第四篇：電氣工程師工作經驗總結

電氣工程師工作經驗總結

------------------

本人系2005年畢業的，專業是機電一體化，在一家輪胎知名企業工作。剛畢業的前三個月在該公司的各車間進行輪流實習，也讓我第一次接觸到了輪胎設備，看著眼花繚亂的設備動作和工人緊張的操作，心里默默的想著，自己到底分到哪，做什么工作，慢慢的熟悉了車間，熟悉了車間的技術人員，熟悉了他們所負責的工作，知道自己如果分到車間將會成為一名電氣技術員。

可是面對斜交胎車間老掉牙的設備，半鋼車間一流進口的設備，工程胎國產剛開始安裝的設備，自己何去何從，雖然無法左右自己以后的命運，但我始終都在學習，在深入的了解設備，也許是因為自己那股虛心學習的勁頭被領導發現，在各車間實習時就被各車間的領導看好，一度想把我留到他們車間，但偏偏被裝備處室的領導看好，成為裝備選拔的六人中的一人，當時看來形勢一片大好。后半個月繼續去模具車間實習，這個車間沒有什么大型設備，只有幾臺洗模機和幾臺行吊，其他五人在這期間陸續的被調到裝備，唯獨我還在車間實習，找裝備的領導詢問情況，原來車間不放，沒有辦法，只得先暫時干下去，因為我是學機電的，并且該車間是新成立的，所以要負責設備機械電氣各項工作，做備件計劃，畫圖加工件，潤滑，維修，檢查線路所有的都由我來做，因為設備的自動化程度不高，動作也不復雜，所以真正在技術上學到的并不多，只有AB SLC的PLC，和歐姆龍200的PLC，而且我一直都在偏向于電氣.但我學會了適應環境，學會了溝通，學會了自己單獨思考解決問題，學會了用CAD畫加工件，學會了指揮別人干活，學會了看電路圖，學會了基本的PLC理論，學會了給別人安裝電腦系統。一轉眼半年過去了，到了2006年的3月份，也是我事業轉機的時候.因為我們車間設備少，所以我喜歡在沒有事的時候去半鋼，全鋼車間溜達，看看那里設備出現了問題，看他們如何維修，交談之余才知道自己的工資太低了，還是700多。于是想到了辭職，想到了換工作，經我從前的車間實習師傅介紹，有機會到該輪胎公司的第二半鋼生產基地去，拿是該集團的重點，據說全是進口設備，在辭職和該生產基地領導的大力推薦下，總于被跳到該半鋼基地。

去報到時，設備還沒有到貨，面對巨型的車間，我又一次看到了希望，設備陸續到貨安裝，韓國，日本的壓出生長線，荷蘭，捷克成型機，德國的裁斷機，韓國的硫化機，真的都是進口一流的設備，我當時就是專門負責電氣，在設備的安裝調試中，我有一次迅速的成長起來，AB 1756,西門子400，三菱的PLC，DEVICENET總線，PROFIBUS總線，ASI，伺服，變頻，BST糾偏系統，LOGIC5000編程軟件，STEP7,GX Developer，RSRSView Studio,PRTOOL觸摸屏,各分布式模塊，讓我總感覺自己知道的太少太少，要學的太多太多。

2006.8月份設備陸續的交付使用，在操作工不熟練的過程中，也出現了各種各樣的問題，開始分析解決問題的時間很長，慢慢的，慢慢的，自己的能力提高了，解決問題也不那樣撓頭了，各種設備編程軟件也開始熟練掌握，把原來英文的觸目屏界面紛紛改成中文版的，英語水平也開始在和老外的對活中慢慢提高，2006年年底被該集團評為設備管理標兵，一晃到了現在。水平提高了，工資卻漲的太慢，現在才拿1600，所以感到了不滿，付出和匯報不成正比。

第五篇：測試經驗總結

1.測試人員和用戶的聯系與區別

黑盒測試人員和用戶，都是站在實際應用層進行操作，因此他們對應用層的可用性、實用性非常關注。用戶不懂的是軟件的使用，而相對用戶來說，測試人員對軟件比較了解，但不熟悉業務本身。

八個字歸納：用戶是用，測試是測。

用戶不懂使用就需要技術支持人員去培訓，而測試人員在測試初期經過開發人員和項目負責人的簡單培訓后，就應該通過所學的理論知識和相關的業務知識獨立去了解、深入到軟件的功能點中。

應該做到：由測試人員培訓技術支持人員，由技術支持人員實施時給用戶培訓。

2.帶著問題去測試

阿豬工作守則第一條：帶著問題去測試

測試中會遇到很多問題，沒關系，沒有腦子里面的一個個問號，是不能很好的發現問題的。往往發現一些藏的很深的bug都是在測試人員一步步解決這些問號的過程中，切忌遇到問題就問，不僅因為增加不必要的與開發人員、負責人等的交流時間可能延誤項目進度，而且自己對問題的印象也不會很深刻，畢竟在相對較短的測試時間內，聽不如記，記不如自己去發現規律。

3.測試期間提問題和交流的時機

什么時候應該提問題？

我們都知道，作為測試人員，并不是測試期間什么時候遇到問題就要馬上問，那什么時候是提問的時間？

培訓

培訓時，一般在講解內容的間歇允許打斷，由培訓人員解答測試人員的疑惑。培訓的過程其實就是一個傳輸新知識并答疑的時間，這個期間的提問是歡迎的，也可以增加參與性和調動積極性。所以希望大部分的問題能在這個階段提出來。受時間、環境等條件制約，有時培訓的人講的也不一定細致和全面，這時就需要自己多想，想想這個功能是干什么的，為什么這么做，對應的業務是什么。

阿豬工作守則第二條：培訓時腦子靈活轉動，多想多問

以前大家可能有過參加辯論會的經歷，就算沒有其實和人聊天也是一個交互的過程。參加辯論會要求快速思考，然后放慢語速說出自己的觀點，因為不能說錯。我們在參加培訓時前者相同，后者相反。腦子嘴巴都要快，說錯了也沒有關系，自己的想法被糾正的過程中也是加深印象和理解的過程。

計劃評審

提出對于軟件不理解、安排的任務不明白的地方。

測試期間

這個時期最主要的問題應該集中在影響測試流程和進度的問題，而不是說明書或其它文檔上已有的內容，或者與自己負責模塊無關的內容。開發人員和其他測試人員都有自己的進度安排，因此，影響測試流程和進度的問題,馬上問！

不影響流程的問題，記下來統一問！

不必要的問題（說明書或其它文檔上已有的內容、講過三遍以上的問題、今晚去哪里吃飯的問題），不問！

好處：避免不必要的時間支出，不打亂自己的測試思路，一氣呵成，并且使項目成本得到控制

壞處（？）：腦子里、筆記本上留下一堆待解決的問號吧，浪費腦細胞和公司的筆和紙

張等資源

阿豬工作守則第三條：先做事，后學習

在有限的時間內先完成該做的事，有空閑的時間再去補充自己的知識。

要很好的把握上述內容，也要求提高培訓期間培訓人員培訓內容的完善性，要求前期培訓人員強調出軟件的重點、難點和注意事項。這個期間適合于上面提到的“帶著問題去測試”的方法。

但有一點需要注意：不要為了一個地方的卡殼在那耗上一天半天的，這就不值得了。測試中期評審測試問題

答疑解惑的時間。

測試報告評審

對一些結論有疑惑和不解的地方，提！

4.記筆記

一個老生常談的話題。

阿豬工作守則第四條：好記性不如爛筆頭

測試培訓的時候對于一些重點應該記下來，即使當時聽懂了；沒聽明白的更應該記下來，到測試軟件的時候去驗證自己的疑問。如果培訓時特別強調的地方，測試時再去問，這就不好了。

養成一個良好的習慣，會使以后的工作更加順利。

5.在公司和學校的學習的區別

學校是專門學習的地方，公司就是工作的地方，因此，它們的性質決定了其學習內容和方法的不同。

學校 公司 備注

內容上 主要是系統的理論知識 主要是和項目相關的業務知識 如果在測試中感到自己部分理論知識欠缺時，就應該回家多補充了

時間上 大塊時間的連續學習相對鄰散 在公司一般不會拿出大塊時間來學習和講解 形式上 老師授課＋自學 培訓＋交流＋測試過程中自學

個人覺得，一個高效的測試流程應該如下：

a.花幾個小時至多半天時間快速閱讀瀏覽軟件說明書、設計文檔；

這個階段要讓腦子里面形成對軟件的整體印象感，能夠讓自己把握全局，因此，測試負責人安排時間看文檔時，決不能忽視它的重要性，否則就會出現后續階段磕磕碰碰的情況。注重速讀，把握軟件說明，忽略具體的數據庫設計、功能點設計、計算、規則和輔助工具（相關軟件）說明文檔，囫圇吞棗的方法在這里就顯得很有效。

如果項目時間緊或沒有文檔，這個步驟所做的事可以在下面完成。

b.利用培訓時間消化吸收的知識

c.軟件上手

幾個小時至多半天時間，熟悉軟件框架和基本功能，不要求所有功能都會操作，自己負責的模塊可以多側重一些。

d.細測

主要癥對計劃中安排給自己做的模塊，這時就要相對放慢節奏，每一步操作、每個對話框（操作界面）都要深究，別放過任何情況。這時會遇到一些錯誤或不理解的地方，明顯的如報錯就提到開發過程論壇，不明顯的就先記下來，等這個功能點測完再回頭去看，你會發現：

50％的問題可以自己分析出來和解決，有的問題不是問題，只是開始還沒有完全理解。阿豬工作守則第五條：軟件不是一次能測透的Rome is not built in one day.工期、人力、環境資料等，都制約著測試的深度和廣度，因為不要期望一次能完全把握某個軟件。

綜合測試的優勢在于，我們負責公司產品的把關，而項目由產品延伸而來；測試產品會不斷出新的版本，一次沒有理解，可以在下一次中彌補，溫故而知新。

一口吃不成一個胖子，看我這么瘦又這么能吃就知道了^^

要結合自己的實際情況決定本次測試的深度，不要看著別人進度快了就打亂自己的節奏，只要安排合理，應該按照計劃來。特別忌諱認為自己這塊沒問題了就馬上去看看別人負責的功能，期望全能。這樣一般來說除了ljl這種全能性人物外都會造成最后自己的問題留了一堆，別人的也沒搞懂。

新人特別注意，踏踏實實的搞懂每個自己負責的模塊，打陣地站，這種方法很有效。評價自己是否可以轉入下個模塊的幾個因素：自我提問與別人提問、測試進度

如果大多數相關人員（主要是測試負責人、其他部分相關測試人員特別是開發組集成測試人員和技術支持人員）對于自己負責模塊的問題都能解答，搞定！NEXT-->轉入下個模塊。

否則，還是再回頭想想思路和遺漏的地方。當然，要綜合考慮測試進度。請組長對自己提幾個軟件的問題，他會很樂意的。

e.小結

一個階段就進行一次小結，這個小結可以是書面的，比如測試問題記錄、測試用例補充、測試模塊設計等，但大多是自己分析，為了方便接下來模塊的測試.f.性能測試

性能測試不僅是測試性能，同時也加深自己對軟件應用的理解，因為性能測試往往和實際應用或用戶需求結合的很緊密，避免造成軟件功能都會用，但不知用來干麻的尷尬情況。g.安裝盤測試

安裝盤程序測試，簡單過一下軟件功能有無錯誤。

安裝盤程序文件、庫文件、組件等的完整性、正確性，這個非常重要，要不返工就浪費時間了。這個階段要積極與開發負責人和GJ溝通，確保最后的勝利。

h.測試總結

測試接近尾聲，總結自己對軟件的掌握情況，得出測試結論、歸納測試方法、提出修改建議，為軟件以后版本的修改提供依據，也為以后再測類似軟件提供捷徑。

5.小結

? 用戶用軟件，測試測軟件

培訓時多想多問?

好記性不如爛筆頭?

帶著問題去測試，在測試中解決問題?

? 先做事，后學習，爭取雙贏

軟件不是一次能測透的?