第一篇：《測試管理培訓》心得

測試管理培訓心得

這次培訓主要針對測試管理方面的培訓，包含測試流程、人員等的管理方法及技巧。由于組織這次培訓的機構是第三方軟件評測機構，老師不僅從第三方角度講解了培訓管理過程，而且還針對我們第二方測試管理做了相應的引導。

一、目前我國軟件業大的背景如下：

1.測試需求不明確，測試不知在何時介入項目，即使知道在哪里介入，也沒有發揮很好的作用；

2.很多時候功能完成后，測試才開始執行測試工作，導致測試對需求的了解是通過開發人員轉述，造成測試人員按開發人員的理解去理解需求，使測試需求不明確；

3.測試人員的工作都應是從文檔中體現，但由于時間緊導致文檔缺，無法衡量測試人員的工作量和工作質量；

4.測試人員的文檔應包括:測試計劃進度計劃、測試方案、測試用例、測試報告、會議紀要或溝通記錄，但目前我們的測試人員很少有溝通記錄的東西。5.測試用例與需求存在很大差距，導致用例不能覆蓋全部功能或用例無效； 6.沒有計劃的測試造成測試隨意性很強，導致測試效果差。7.配置管理混亂，導致版本混亂。8.人員方面，合格的測試人員比較少

二、怎樣管理

1.組織管理：組織架構、人員角色、人員培訓

a)組織架構：質量監督（質量成果控制）、文檔管理、配置管理、設備管理；

-----就目前公司現狀，不需要單獨文檔管理和設備管理

b)人員培訓：是長期工作，對新進員工培訓及測試新技術培訓都是要有的，但培訓一定要有效果，因此培訓后要有總結或考試，否則培訓是浪費時間。

2.測試過程管理：測試計劃、過程審核及工作產品

3.測試管理：以正確的方式對測試過程進行管理，選擇合適的人建立有效的測試團隊。

三、測試分類

1.單元測試：一般由開發人員自己做，或開發人員之間互查，測試模塊的可用性及正確性，測試用例編寫以詳細設計為依據，使用白盒測試技術； 2.集成測試：是為了測試模塊與模塊之間的互通性，測試人員來做，測試用例編寫以概要設計為依據，結合使用白盒測試、灰盒測試；

3.系統測試：此階段測試，不僅要測試軟件，還要測試軟件與硬件系統的結合程序，因此，系統測試機的配置要與需求規格說明書硬件要求一致，是對整個軟件、硬軟件系統測試，測試用例編寫以需求規格說明書為依據；

4.驗收測試：主要是業主方測試，測試用例以用戶需求規格說明書為依據，此類型測試一般不會在第二方測試；

5.性能測試：一般都是在現場環境測試，若由于軟件性質問題，不能在現場測試，應該配置與現場1:1的測試環境測試，因為軟件的性能不是和硬件環境成線性比例的，因此在一個環境下測試結果，不能正確預估其它環境的測試結果。

關于測試類型還有阿爾法測試、貝特測試，但我們不是做市場化的產品，很少用到。

接著老師又從軟件測試的預備階段、準備階段、執行階段及收尾階段分別詳細講解了各階段的注意事項及中國軟件評測中心在這幾階段怎么做的，其它的一些大公司是怎么做的，從中見識了一些大公司在軟件測試方面的做法，從中借鑒了一些適合公司的實踐。

由于時間關系，講的不是特別細致，主要是點到為止，讓我們知道測試管理有哪些關注點。主要的核心點是如何來預防缺陷要高于如何解決缺陷，缺陷越早發現解決成本越低。

很多測試人員在手工測試都不是很好的情況下，瘋狂追逐自動化測試，其實一個軟件在測試中，最主要的還是手工功能測試中發現的問題比例比較大，自動化畢竟還是需要人來設置場景和測試腳本，并且自動化測試在前期準備要花費大量的時間，花費大量時間寫的測試腳本若沒有重復使用的話，屬得不償失。當然自動化測試有它自身優點，自動化測試最大的優點就是把重復性的勞動交給計算機去做，每個版本更新后都需要重復測試的功能，或者是大量的數據的重復操作。這些如果在項目之前都開發完成的話，對于軟件的效率會有極大的提高。但是它的局限性也比較大：

? 自動化測試前期投入很大，包括編寫自動化測試工具，開發自動化測試腳本。如果項目周期短，沒有可持續性不適合自動化測試，例如我們公司目前的項目不太適合自動化測試方式。

自動化測試的技術門檻相對較高，測試團隊整體水平不高的情況下無法完成工具的發開，心有余而力不足。

對于沒有預期結果的測試，不適應自動化。? ?

? 對于用戶體驗的測試，主觀性比較強的不適應自動化。測試人員的工作是基于需求、設計階段的詳細文檔成果制定詳細測試計劃，和詳細設計（測試用例及測試方案設計）可在同一時間完成。完美的測試是90%的測試任務和開發并行完成，10%的測試任務在開發之后完成，還是剛才說的，預防缺陷要比解決缺陷效果好的多。讓開發人員邊開發就邊測試自己的代碼使之都是有效代碼。測試計劃中除了包含常見的測試內容，功能測試，性能測試，健壯性測試，安全測試，界面測試等，還應該考慮到UE用戶體驗測試，因為用戶體驗的好壞是決定商業上是否成功的標準。不僅把產品做到能用，還要把產品做到好用。所以產品開發完成之后積累用戶的反饋也很重要。需求不明確所導致的測試時間的延長，這些都要計算到測試風險之中。

? 制定測試計劃中，人員不充分，經驗不足怎么辦？從工程的角度考慮問題，不僅僅是要求測試人員之間分享經驗，還需要有效的標準。一個好的模板，是節約人力成本的好辦法。還能弱化對每個人的依賴度。還要檢查需求細不細，避免主觀語句（性能高，響應速度快等這樣的形容詞），速度響應快，快到多少秒。一定要量化需求，? 而不是主觀感受。凡事以數據說話，這樣才能有說服力。

如何提高測試用例的編寫水平？第一，積累測試素材，比如對于文本框的驗證，一般都是驗證那幾項，有效數值，無效數值。空格，空等等。這些測試用例在每個項目中都可以反復使用。第二，測試方法的復用，對于有繼承性的項目來說，用之前編寫的測試腳本或自動化測試工具以達到測試方法的復用(目前公司還用不到這? ? ?

點)。

如何判定測試是否充分？驗證到每個對象的每個屬性值，結合白盒深度測試。測試對bug的理解不一致怎么辦？有爭議的地方和開發人員商定，確認后建立checklist或者用戶指南，列出檢查清單。以后如發現此問題，對照清單解決問題。如果衡量缺陷的質量？1）檢查環境，測試環境是否正常 2）是否可重現 3）檢查

是否是重復bug 4）詳盡的操作步驟 5）問題的定位 6）要能提出修改意見就更好了

? 缺陷的分類比一般的分類多的項有：測試引起的；由其他bug引起的；功能未實現的。

執行測試的過程當中，限定解決缺陷的時間，即check-in估計完成時間。真正把每個問題都落實到微觀。這些缺陷分配理論上由項目經理來做。通過缺陷管理平臺，所有缺陷平臺管理員、領導知道某個開發人員的代碼有效率是多少，即使他們未曾謀面。目前有很多跨地域管理的問題，管理者不可能時刻都盯著手下的人在做什么。重要的得到信息的方式，做到用數據管理，以事實說話。

測試后期到準備發布階段，發布評估標準（Release Criteria）： ? ? ? 95%的測試用例通過率，且持續時間>5天。---針對目前公司發現缺陷的程度，要100%通過

代碼覆蓋率>85%---目前公司需完善的指標

ZBB（零基預算）零bug邊界，保持15天—---針對目前公司小項目，應該取更少天數比較好。

測試項目之中的管理，以數據為依據，分析bug的曲線，知道目前的項目進展狀況并估算項目的進度是否在可控范圍內，才能保證項目順利進行。對于項目的流程的制定，過于復雜的流程如果過于難以執行，則會降低紀律的可執行力，所以針對不同的項目制定流程裁剪活動。流程裁剪一旦確定，就要落實。分配任務的時候要落實到每個人頭上，不能把一個任務交給一群人做，要明確到每個人做什么模塊。合理的制定里程碑之間的工作計劃，循序漸進逐步完善：

? 短期計劃：

? 針對這次培訓，整理一個培訓課件，找時間做一次測試培訓； ? 完善測試組用到的模板；

? 規范測試流程，對JIRA的應用流程強調說明，在我們能掌控范圍內將測試流? 程向標準靠攏；

項目所有成果都要commit到SVN上，目前兩個項目組已經有計劃出來；

? ? 測試機與開發調試機分離，實現開發、測試兩條線；

? 修改月績效考核指標，制訂一個符合測試組實際工作的考核指標； 中期計劃： ? ? ? 調整缺陷管理庫，做到測試用例和bug關聯； 完善項目開發組用到的模板；

培訓過程中，對培訓效果要做評估，考試或培訓總結，為了證明培訓作用這一項是必要的，即使是考試，題目題量是開放式的問題，而不是簡單選擇題。

? 長期計劃：完善性能測試、系統測試環境。

3天的測試管理培訓時間并不長，簡單介紹了一些軟件測試國標規范，結合案例，老師給我們講了一些測試管理的方法及流程。我們要想提供給客戶一款滿意的產品，關鍵在于對產品質量的要求，“在質量面前什么都不重要”。我個人對項目的簡單理解就是，每個階段把握每個細節，認真落實文檔，凡是計劃要出的文檔，一定要把關文檔質量，評審的目的就是讓其他人幫你想遺漏的地方，然后嚴格遵循文檔開發，用實際的數據說話；對測試的簡單理解是，測試越早介入，BUG遺漏率越低，解決BUG的成本越低；總之，每個人都擔當起QA的職責，監督團隊的其他人，互相促進和發展，項目的質量就會大有保證。

第二篇：《測試管理培訓》心得

測試管理培訓心得

這次培訓主要針對測試管理方面的培訓，包含測試流程、人員等的管理方法及技巧。由于組織這次培訓的機構是第三方軟件評測機構，老師不僅從第三方角度講解了培訓管理過程，而且還針對我們第二方測試管理做了相應的引導。

一、目前我國軟件業大的背景如下：

1.測試需求不明確，測試不知在何時介入項目，即使知道在哪里介入，也沒有發

揮很好的作用；

2.很多時候功能完成后，測試才開始執行測試工作，導致測試對需求的了解是通

過開發人員轉述，造成測試人員按開發人員的理解去理解需求，使測試需求不

明確；

3.測試人員的工作都應是從文檔中體現，但由于時間緊導致文檔缺，無法衡量測

試人員的工作量和工作質量；

4.測試人員的文檔應包括:測試計劃進度計劃、測試方案、測試用例、測試報告、會議紀要或溝通記錄，但目前我們的測試人員很少有溝通記錄的東西。

5.測試用例與需求存在很大差距，導致用例不能覆蓋全部功能或用例無效；

6.沒有計劃的測試造成測試隨意性很強，導致測試效果差。

7.配置管理混亂，導致版本混亂。

8.人員方面，合格的測試人員比較少

二、怎樣管理

1.組織管理：組織架構、人員角色、人員培訓

a)組織架構：質量監督（質量成果控制）、文檔管理、配置管理、設備管理；

-----就目前公司現狀，不需要單獨文檔管理和設備管理

b)人員培訓：是長期工作，對新進員工培訓及測試新技術培訓都是要有的，但培訓一定要有效果，因此培訓后要有總結或考試，否則培訓是浪費時間。

2.測試過程管理：測試計劃、過程審核及工作產品

3.測試管理：以正確的方式對測試過程進行管理，選擇合適的人建立有效的測試

團隊。

三、測試分類

1.單元測試：一般由開發人員自己做，或開發人員之間互查，測試模塊的可用性

及正確性，測試用例編寫以詳細設計為依據，使用白盒測試技術；

2.集成測試：是為了測試模塊與模塊之間的互通性，測試人員來做，測試用例編

寫以概要設計為依據，結合使用白盒測試、灰盒測試；

3.系統測試：此階段測試，不僅要測試軟件，還要測試軟件與硬件系統的結合程

序，因此，系統測試機的配置要與需求規格說明書硬件要求一致，是對整個軟

件、硬軟件系統測試，測試用例編寫以需求規格說明書為依據；

4.驗收測試：主要是業主方測試，測試用例以用戶需求規格說明書為依據，此類

型測試一般不會在第二方測試；

5.性能測試：一般都是在現場環境測試，若由于軟件性質問題，不能在現場測試，應該配置與現場1:1的測試環境測試，因為軟件的性能不是和硬件環境成線性

比例的，因此在一個環境下測試結果，不能正確預估其它環境的測試結果。

關于測試類型還有阿爾法測試、貝特測試，但我們不是做市場化的產品，很少用到。

接著老師又從軟件測試的預備階段、準備階段、執行階段及收尾階段分別詳細講解了各階段的注意事項及中國軟件評測中心在這幾階段怎么做的，其它的一些大公司是怎么做的，從中見識了一些大公司在軟件測試方面的做法，從中借鑒了一些適合公司的實踐。

由于時間關系，講的不是特別細致，主要是點到為止，讓我們知道測試管理有哪些關注點。主要的核心點是如何來預防缺陷要高于如何解決缺陷，缺陷越早發現解決成本越低。

很多測試人員在手工測試都不是很好的情況下，瘋狂追逐自動化測試，其實一個軟件在測試中，最主要的還是手工功能測試中發現的問題比例比較大，自動化畢竟還是需要人來設置場景和測試腳本，并且自動化測試在前期準備要花費大量的時間，花費大量時間寫的測試腳本若沒有重復使用的話，屬得不償失。當然自動化測試有它自身優點，自動化測試最大的優點就是把重復性的勞動交給計算機去做，每個版本更新后都需要重復測試的功能，或者是大量的數據的重復操作。這些如果在項目之前都開發完成的話，對于軟件的效率會有極大的提高。但是它的局限性也比較大：

? 自動化測試前期投入很大，包括編寫自動化測試工具，開發自動化測試腳本。如果

項目周期短，沒有可持續性不適合自動化測試，例如我們公司目前的項目不太適合自動化測試方式。

自動化測試的技術門檻相對較高，測試團隊整體水平不高的情況下無法完成工具的發開，心有余而力不足。

對于沒有預期結果的測試，不適應自動化。? ?

? 對于用戶體驗的測試，主觀性比較強的不適應自動化。

測試人員的工作是基于需求、設計階段的詳細文檔成果制定詳細測試計劃，和詳細設計（測試用例及測試方案設計）可在同一時間完成。完美的測試是90%的測試任務和開發并行完成，10%的測試任務在開發之后完成，還是剛才說的，預防缺陷要比解決缺陷效果好的多。讓開發人員邊開發就邊測試自己的代碼使之都是有效代碼。測試計劃中除了包含常見的測試內容，功能測試，性能測試，健壯性測試，安全測試，界面測試等，還應該考慮到UE用戶體驗測試，因為用戶體驗的好壞是決定商業上是否成功的標準。不僅把產品做到能用，還要把產品做到好用。所以產品開發完成之后積累用戶的反饋也很重要。需求不明確所導致的測試時間的延長，這些都要計算到測試風險之中。

? 制定測試計劃中，人員不充分，經驗不足怎么辦？從工程的角度考慮問題，不僅僅

是要求測試人員之間分享經驗，還需要有效的標準。一個好的模板，是節約人力成本的好辦法。還能弱化對每個人的依賴度。還要檢查需求細不細，避免主觀語句（性

能高，響應速度快等這樣的形容詞），速度響應快，快到多少秒。一定要量化需求，? 而不是主觀感受。凡事以數據說話，這樣才能有說服力。如何提高測試用例的編寫水平？第一，積累測試素材，比如對于文本框的驗證，一

般都是驗證那幾項，有效數值，無效數值。空格，空等等。這些測試用例在每個項

目中都可以反復使用。第二，測試方法的復用，對于有繼承性的項目來說，用之前

編寫的測試腳本或自動化測試工具以達到測試方法的復用(目前公司還用不到這

?

?

?

點)。如何判定測試是否充分？驗證到每個對象的每個屬性值，結合白盒深度測試。測試對bug的理解不一致怎么辦？有爭議的地方和開發人員商定，確認后建立checklist或者用戶指南，列出檢查清單。以后如發現此問題，對照清單解決問題。如果衡量缺陷的質量？1）檢查環境，測試環境是否正常 2）是否可重現 3）檢查

是否是重復bug 4）詳盡的操作步驟 5）問題的定位 6）要能提出修改意見就更好了

? 缺陷的分類比一般的分類多的項有：測試引起的；由其他bug引起的；功能未實現的。

執行測試的過程當中，限定解決缺陷的時間，即check-in估計完成時間。真正把每個問題都落實到微觀。這些缺陷分配理論上由項目經理來做。通過缺陷管理平臺，所有缺陷平臺管理員、領導知道某個開發人員的代碼有效率是多少，即使他們未曾謀面。目前有很多跨地域管理的問題，管理者不可能時刻都盯著手下的人在做什么。重要的得到信息的方式，做到用數據管理，以事實說話。

測試后期到準備發布階段，發布評估標準（Release Criteria）：

?

?

? 95%的測試用例通過率，且持續時間>5天。---針對目前公司發現缺陷的程度，要100%通過 代碼覆蓋率>85%---目前公司需完善的指標 ZBB（零基預算）零bug邊界，保持15天—---針對目前公司小項目，應該取更少

天數比較好。

測試項目之中的管理，以數據為依據，分析bug的曲線，知道目前的項目進展狀況并估算項目的進度是否在可控范圍內，才能保證項目順利進行。對于項目的流程的制定，過于復雜的流程如果過于難以執行，則會降低紀律的可執行力，所以針對不同的項目制定流程裁剪活動。流程裁剪一旦確定，就要落實。分配任務的時候要落實到每個人頭上，不能把一個任務交給一群人做，要明確到每個人做什么模塊。合理的制定里程碑之間的工作計劃，循序漸進逐步完善：

? 短期計劃：

? 針對這次培訓，整理一個培訓課件，找時間做一次測試培訓；

? 完善測試組用到的模板；

? 規范測試流程，對JIRA的應用流程強調說明，在我們能掌控范圍內將測試流? 程向標準靠攏； 項目所有成果都要commit到SVN上，目前兩個項目組已經有計劃出來；

? ? 測試機與開發調試機分離，實現開發、測試兩條線； ? 修改月績效考核指標，制訂一個符合測試組實際工作的考核指標； 中期計劃：

?

?

? 調整缺陷管理庫，做到測試用例和bug關聯； 完善項目開發組用到的模板； 培訓過程中，對培訓效果要做評估，考試或培訓總結，為了證明培訓作用這一

項是必要的，即使是考試，題目題量是開放式的問題，而不是簡單選擇題。

? 長期計劃：完善性能測試、系統測試環境。3天的測試管理培訓時間并不長，簡單介紹了一些軟件測試國標規范，結合案例，老師給我們講了一些測試管理的方法及流程。我們要想提供給客戶一款滿意的產品，關鍵在于對產品質量的要求，“在質量面前什么都不重要”。我個人對項目的簡單理解就是，每個階段把握每個細節，認真落實文檔，凡是計劃要出的文檔，一定要把關文檔質量，評審的目的就是讓其他人幫你想遺漏的地方，然后嚴格遵循文檔開發，用實際的數據說話；對測試的簡單理解是，測試越早介入，BUG遺漏率越低，解決BUG的成本越低；總之，每個人都擔當起QA的職責，監督團隊的其他人，互相促進和發展，項目的質量就會大有保證。

第三篇：測試培訓心得

軟件測試培訓心得體會

1.1概述

2013年12月27日下午14：00-17：30，研究院邀請了測試支持部的XXX召開軟件測試培訓，本人非常榮幸的參加此次培訓，通過這次培訓讓我系統的梳理了軟件測試理論技術，對軟件測試有了一個更深入更全面的認識。更為重要顏經理通過他的測試經驗分享，可以讓我在日后的工作中會少走一些彎路，以免犯一些不必要的錯誤。

1.2軟件測試培訓內容及自我體會

此次培訓的內容主要包括VMS項目總結，SPMS系統測試流程及華為驗收流程介紹，測試工程師需要的技能和軟件，軟件測評師的簡述等 以下是自我體會

體會一: 軟件測試在整個軟件生命周期中的重要性

現狀：國內大部分公司都存在對測試工作不太重視的現狀,諸如軟件測試就是為軟件開發打下手，測試與開發的配比也存在嚴重的不足，一般公司都是1比3，更有甚的就是沒有測試人員，放眼國外的大公司微軟，測試與開發比例為1：1，軟件測試它存在于整個項目周期，在項目開始之初需求調研的時候就開始了，在形成需求規格說明書的時候就需要針對文檔進行測試。這個環節在后續整個項目中占了很大的比重，能主導整個軟件項目的走向，成敗與否全在于開始階段的決策。

體會二: 系統測試流程的嚴格執行很重要

學習了公司的SPMS系統測試流程和華為的驗收流程，通過VMS項目的經驗有１.需求及設計文檔不夠詳細，導致了開發，測試，資料活動受阻，導致后期的溝通成本大幅增加，并出現了架構調整的重大風險2．需求及設計評審不足導致后期變更比較多3.沒有全面地測試需求分析，未能從整個系統把握住所要測試的需求。以上經驗都告訴我們系統測試流程的嚴格執行很重要，從項目前期的需求分析，總體設計到測試需求的分析及用例，再到后期的系統測試等，只有嚴格執行標準的系統測試流程才能把風險降低。

1.3個人想法和總結

通過這次培訓，結合目前我的測試工作，接下來為了提高我們的軟件能在質量上得到保障減輕項目后期維護驗收的風險，在此做以下后期測試的想法； １.加強測試需求分析：第一：通過分析需求測試點，“盡早的了解被測系統”，第二，如果在需求分析階段發現系統存在嚴重的Bug（此階段的bug最多），或者發現不可測的地方，可以及時的進行修改，避免了后期修改bug的巨大的成本浪費。

２.規范開發轉測試的流程：制定開發提交給測試軟件的流程，使得測試工作會更順利的開展，提高工作效率

３.測試管理工具的利用：去探索一些適用的測試管理工具，提高整體項目組的工作效率 通過這次培訓，讓我們學到了豐富的測試知識和經驗，也讓我們看到自身存在的不足，我和我們的同事必將吸取這次測試培訓經驗，把我們的整個軟件測試流程做的更規范，更專業，更優秀，將項目的風險降到最低。最后感謝公司能夠安排這樣的培訓，讓我們能在公司得成長中學習，在學習中成長。

第四篇：軟件測試-培訓心得

個人淺談培訓之心得

2013年3月8日，黃老師在百勝軟件進行了為期一天的測試管理培訓，本人非常榮幸的參加了此次培訓，通過這次培訓讓我充實了更多的理論方面的知識，拓寬了思路，有許多不能用語言來表達的收獲，讓我更進一步的了解了軟件測試理論技術，對軟件測試有了一個更深入更全面的認識，對于以后如何更好的工作有了更全面的認識。

參見培訓以前，沒有測試環境重要性的認知，通常是測試需要什么環境就配置什么環境，開發不能重現的bug在測試機器上修改的情況大有存在。這次培訓讓我了解到，測試的進步、高效率首先有在測試環境建立和管理的基礎。在保證開發環境與測試環境的唯

一、純凈性的同時，必須建立一個科學的標準庫。

磨刀不誤砍柴工，同樣測試設計并不會耽擱測試的進度和效率。我們大部分人是看到測試任務，讀懂就開始啪啪啪的進行測試，并沒有測試之前的思考和設計。

并不是所有的測試寫的越細越好，根據產品形態、形式、周期的不同，測試用例的細化程度是為了實現高效率的可執行、低成本的易維護。

以前一直以為，自動化測試，會用工具，會寫執行腳本就可以了。聽完老師的培訓之后，我認識到，測試用例的設計、維護在自動化測試中統一重要，自動話測試并不是為了發現bug而去測試的，自動化測試是為了檢查沒有bug，程序沒有錯誤。

聽黃老師的一席話，讓我在軟件測試的路上，少了些彎路、少了些挫折。公司這樣的培訓，雖然不能起到立竿見影的效果，但潛移默化之中，把我們的測試之路修的較為平整些，吸取的經驗減少著我們的痛苦。

第五篇：軟件測試培訓心得

從事軟件測試工作已經有三年了，在經歷了小公司、大公司的功能測試之后，業務需求已經不是本職測試工作的阻礙了，這時的我們該想想接下來的路了……

通過qq群知道了有這么一個測試培訓機構有這么一群不斷努力的人。思來想去，周末在家無聊的荒廢時間，不如試試加入他們，重拾剛畢業那會的昂揚斗志。

加入這個培訓之后才從之中的同學那里知道，原來這個培訓班已經辦了快兩年了，里面有很多學員都是從最初一直堅持到現在。培訓課程設計范圍也很廣，包括系統的數據庫、java編程、linux系統包括時下比較fashion的手機自動化測試等等知識，在講述這些知識的同時老師會在課程中間穿插測試涉及的內容。課程完畢后，對應的老師也會一直在群里與同學互動，及時解決同學在實際測試應該過程中發現的問題，這個對于我們在職的軟件測試人員還是很有吸引力的。

目前為止，我也只參加了兩次培訓，一次單元測試，老師是微軟的開發人員。雖然測試人員一般不會做單元測試，但對于目前很多公司不重視測試的行業現狀，多了解開發人員的工作流程或操作無可厚非，在必要的時候能夠明白開發是用什么工具如何進行的也可以讓開發對你的測試工作給予更多的肯定。之后的培訓是手機自動化的，我因有事無法參加，不過看到群里大家在熱烈的討論時，還是有點遺憾

啊。最近的一次培訓是selenium自動化測試，這次的培訓不是用的selenium IDE而是通過結合瀏覽器自帶組件自編代碼進行各個瀏覽器的自動化測試，雖然這次講的東西比較少，但對于我們實際的測試工作還是很有幫助，至少給我們的測試工作提供的思路，不是一提自動化測試就茫然無措了。