第一篇：測試培訓(xùn)心得

軟件測試培訓(xùn)心得體會

1.1概述

2013年12月27日下午14：00-17：30，研究院邀請了測試支持部的XXX召開軟件測試培訓(xùn)，本人非常榮幸的參加此次培訓(xùn)，通過這次培訓(xùn)讓我系統(tǒng)的梳理了軟件測試?yán)碚摷夹g(shù)，對軟件測試有了一個更深入更全面的認(rèn)識。更為重要顏經(jīng)理通過他的測試經(jīng)驗(yàn)分享，可以讓我在日后的工作中會少走一些彎路，以免犯一些不必要的錯誤。

1.2軟件測試培訓(xùn)內(nèi)容及自我體會

此次培訓(xùn)的內(nèi)容主要包括VMS項(xiàng)目總結(jié)，SPMS系統(tǒng)測試流程及華為驗(yàn)收流程介紹，測試工程師需要的技能和軟件，軟件測評師的簡述等 以下是自我體會

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

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

體會二: 系統(tǒng)測試流程的嚴(yán)格執(zhí)行很重要

學(xué)習(xí)了公司的SPMS系統(tǒng)測試流程和華為的驗(yàn)收流程，通過VMS項(xiàng)目的經(jīng)驗(yàn)有１.需求及設(shè)計(jì)文檔不夠詳細(xì)，導(dǎo)致了開發(fā)，測試，資料活動受阻，導(dǎo)致后期的溝通成本大幅增加，并出現(xiàn)了架構(gòu)調(diào)整的重大風(fēng)險(xiǎn)2．需求及設(shè)計(jì)評審不足導(dǎo)致后期變更比較多3.沒有全面地測試需求分析，未能從整個系統(tǒng)把握住所要測試的需求。以上經(jīng)驗(yàn)都告訴我們系統(tǒng)測試流程的嚴(yán)格執(zhí)行很重要，從項(xiàng)目前期的需求分析，總體設(shè)計(jì)到測試需求的分析及用例，再到后期的系統(tǒng)測試等，只有嚴(yán)格執(zhí)行標(biāo)準(zhǔn)的系統(tǒng)測試流程才能把風(fēng)險(xiǎn)降低。

1.3個人想法和總結(jié)

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

２.規(guī)范開發(fā)轉(zhuǎn)測試的流程：制定開發(fā)提交給測試軟件的流程，使得測試工作會更順利的開展，提高工作效率

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

第二篇：軟件測試-培訓(xùn)心得

個人淺談培訓(xùn)之心得

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

參見培訓(xùn)以前，沒有測試環(huán)境重要性的認(rèn)知，通常是測試需要什么環(huán)境就配置什么環(huán)境，開發(fā)不能重現(xiàn)的bug在測試機(jī)器上修改的情況大有存在。這次培訓(xùn)讓我了解到，測試的進(jìn)步、高效率首先有在測試環(huán)境建立和管理的基礎(chǔ)。在保證開發(fā)環(huán)境與測試環(huán)境的唯

一、純凈性的同時，必須建立一個科學(xué)的標(biāo)準(zhǔn)庫。

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

并不是所有的測試寫的越細(xì)越好，根據(jù)產(chǎn)品形態(tài)、形式、周期的不同，測試用例的細(xì)化程度是為了實(shí)現(xiàn)高效率的可執(zhí)行、低成本的易維護(hù)。

以前一直以為，自動化測試，會用工具，會寫執(zhí)行腳本就可以了。聽完老師的培訓(xùn)之后，我認(rèn)識到，測試用例的設(shè)計(jì)、維護(hù)在自動化測試中統(tǒng)一重要，自動話測試并不是為了發(fā)現(xiàn)bug而去測試的，自動化測試是為了檢查沒有bug，程序沒有錯誤。

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

第三篇：軟件測試培訓(xùn)心得

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

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

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

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

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

第四篇：軟件測試培訓(xùn)心得

手機(jī)客戶端測試實(shí)踐的培訓(xùn)心得

2013年7月4日至2013年7月6日，部門組織了一次手機(jī)客戶端測試實(shí)踐的培訓(xùn)，讓我對軟件測試有了一次更深的認(rèn)識.軟件測試就是利用測試工具按照測試方案和流程對產(chǎn)品進(jìn)行功能和性能測試，甚至根據(jù)需要編寫不同的測試工具，設(shè)計(jì)和維護(hù)測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進(jìn)行分析和評估。執(zhí)行測試用例后，需要跟蹤故障，以確保開發(fā)的產(chǎn)品適合需求。

測試存在于整個項(xiàng)目周期，在項(xiàng)目開始之初需求調(diào)研的時候就開始了，在形成需求規(guī)格說明書的時候就需要針對文檔進(jìn)行測試。這個環(huán)節(jié)在后續(xù)整個項(xiàng)目中占了很大的比重，能主導(dǎo)整個軟件項(xiàng)目的走向，成敗與否全在于開始階段的決策。

在嚴(yán)格的測試也不能完全的發(fā)現(xiàn)軟件當(dāng)中所有的錯誤，但是測試還是能發(fā)現(xiàn)大部分錯誤的，能確保軟件基本可用和軟件的適用性，所以在后使用的過程中還需要加強(qiáng)快速響應(yīng)的環(huán)節(jié)。結(jié)合軟件測試?yán)碚摚收媳┞对谧罱K客戶端之前及時主動的去發(fā)現(xiàn)并解決。這點(diǎn)需要加強(qiáng)研發(fā)隊(duì)伍的建設(shè)。

經(jīng)過這次培訓(xùn)中多個案例的講解，讓我了解到系統(tǒng)在上線之后會有很多不能預(yù)知的性能問題，需要在上線之前實(shí)現(xiàn)進(jìn)行模擬，以避免風(fēng)險(xiǎn)，包括大數(shù)據(jù)量訪問，高并發(fā)數(shù)等等。

培訓(xùn)中個人關(guān)于敏捷的建議

1.在需求文檔成型的初期，用戶體驗(yàn)人員，開發(fā)人員，測試人員應(yīng)該在一起分析該需求，開發(fā)人員提出可能的難度，測試人員根據(jù)需求提出可能存在的風(fēng)險(xiǎn)，把隱藏的風(fēng)險(xiǎn)盡量暴露在需求階段，避免后期需求開發(fā)了一半，發(fā)現(xiàn)某個不可能實(shí)現(xiàn)的步驟，導(dǎo)致整個需求作廢，前期的工作全部白費(fèi)

2.在前期需求分析階段，開發(fā)人員需要根據(jù)用戶體驗(yàn)人員的需求以及測試人員對該需求提出的風(fēng)險(xiǎn)做出需求實(shí)現(xiàn)的具體迭代計(jì)劃，測試人員負(fù)責(zé)需求以及這些風(fēng)險(xiǎn)的驗(yàn)收

3.在開發(fā)人員實(shí)現(xiàn)需求的迭代計(jì)劃中，開發(fā)人員和測試人員每天都要開站會，開發(fā)人員負(fù)責(zé)介紹需求實(shí)現(xiàn)進(jìn)度，測試人員匯報(bào)當(dāng)前風(fēng)險(xiǎn)并根據(jù)項(xiàng)目的整體進(jìn)度對開發(fā)人員提出警報(bào)，測試人員驗(yàn)收需求的標(biāo)準(zhǔn)一定要高，避免后期bug太多，維護(hù)成本高

4.每周的迭代計(jì)劃會議上，測試人員需要根據(jù)提供當(dāng)前項(xiàng)目的軟件bug分布和開發(fā)人員一起判斷進(jìn)度是否有延遲，迭代計(jì)劃任務(wù)是否有更改，并根據(jù)當(dāng)前迭代的進(jìn)度制定以下各迭代的計(jì)劃

5.敏捷的最終目的是在最短時間內(nèi)提供軟件質(zhì)量高的版本，越到后期軟件維護(hù)成本越高，所以敏捷的源頭應(yīng)該是把風(fēng)險(xiǎn)控制需求階段，把一個需求拆分為若干個小需求，一步一步實(shí)現(xiàn)，測試人員在需求前期提出風(fēng)險(xiǎn)，開發(fā)設(shè)計(jì)代碼的時候考慮的就會比較全面，這樣代碼質(zhì)量比較高，需求完成后要實(shí)現(xiàn)0嚴(yán)重bug

第五篇：《測試管理培訓(xùn)》心得

測試管理培訓(xùn)心得

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

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

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

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

3.測試人員的工作都應(yīng)是從文檔中體現(xiàn)，但由于時間緊導(dǎo)致文檔缺，無法衡量測試人員的工作量和工作質(zhì)量；

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

二、怎樣管理

1.組織管理：組織架構(gòu)、人員角色、人員培訓(xùn)

a)組織架構(gòu)：質(zhì)量監(jiān)督（質(zhì)量成果控制）、文檔管理、配置管理、設(shè)備管理；

-----就目前公司現(xiàn)狀，不需要單獨(dú)文檔管理和設(shè)備管理

b)人員培訓(xùn)：是長期工作，對新進(jìn)員工培訓(xùn)及測試新技術(shù)培訓(xùn)都是要有的，但培訓(xùn)一定要有效果，因此培訓(xùn)后要有總結(jié)或考試，否則培訓(xùn)是浪費(fèi)時間。

2.測試過程管理：測試計(jì)劃、過程審核及工作產(chǎn)品

3.測試管理：以正確的方式對測試過程進(jìn)行管理，選擇合適的人建立有效的測試團(tuán)隊(duì)。

三、測試分類

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

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

4.驗(yàn)收測試：主要是業(yè)主方測試，測試用例以用戶需求規(guī)格說明書為依據(jù)，此類型測試一般不會在第二方測試；

5.性能測試：一般都是在現(xiàn)場環(huán)境測試，若由于軟件性質(zhì)問題，不能在現(xiàn)場測試，應(yīng)該配置與現(xiàn)場1:1的測試環(huán)境測試，因?yàn)檐浖男阅懿皇呛陀布h(huán)境成線性比例的，因此在一個環(huán)境下測試結(jié)果，不能正確預(yù)估其它環(huán)境的測試結(jié)果。

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

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

由于時間關(guān)系，講的不是特別細(xì)致，主要是點(diǎn)到為止，讓我們知道測試管理有哪些關(guān)注點(diǎn)。主要的核心點(diǎn)是如何來預(yù)防缺陷要高于如何解決缺陷，缺陷越早發(fā)現(xiàn)解決成本越低。

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

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

自動化測試的技術(shù)門檻相對較高，測試團(tuán)隊(duì)整體水平不高的情況下無法完成工具的發(fā)開，心有余而力不足。

對于沒有預(yù)期結(jié)果的測試，不適應(yīng)自動化。? ?

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

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

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

點(diǎn))。

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

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

? 缺陷的分類比一般的分類多的項(xiàng)有：測試引起的；由其他bug引起的；功能未實(shí)現(xiàn)的。

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

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

代碼覆蓋率>85%---目前公司需完善的指標(biāo)

ZBB（零基預(yù)算）零bug邊界，保持15天—---針對目前公司小項(xiàng)目，應(yīng)該取更少天數(shù)比較好。

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

? 短期計(jì)劃：

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

? 規(guī)范測試流程，對JIRA的應(yīng)用流程強(qiáng)調(diào)說明，在我們能掌控范圍內(nèi)將測試流? 程向標(biāo)準(zhǔn)靠攏；

項(xiàng)目所有成果都要commit到SVN上，目前兩個項(xiàng)目組已經(jīng)有計(jì)劃出來；

? ? 測試機(jī)與開發(fā)調(diào)試機(jī)分離，實(shí)現(xiàn)開發(fā)、測試兩條線；

? 修改月績效考核指標(biāo)，制訂一個符合測試組實(shí)際工作的考核指標(biāo)； 中期計(jì)劃： ? ? ? 調(diào)整缺陷管理庫，做到測試用例和bug關(guān)聯(lián)； 完善項(xiàng)目開發(fā)組用到的模板；

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

? 長期計(jì)劃：完善性能測試、系統(tǒng)測試環(huán)境。

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