軟體測試心得體會5篇 磨礪軟測技能：實戰心得分享

作為軟體測試人員，總結和分享自己的軟體測試心得體會是很有意義的。在軟體測試過程中，我們需要全面認識需求，分析需求，制定測試計劃，執行測試用例。在這個過程中，總會有一些經驗教訓，對測試人員來說，這些心得體會至關重要。

第1篇

在最初的認知裡，軟體測試這個行業需要掌握的只是簡單的點點點，但是怎麼點，從那點，為什麼點一直是我內心的疑惑，所以，為了讓自己能夠點點點，更明白的點點點，學習軟體測試並在這個行業發展成了我現階段的目標。

需求澄清階段：從二三百字的英文需求文件，像一個產品的使用說明書，簡單明瞭的交代了是什麼，怎麼用。到後來幾千字的需求澄清文件，是一次思維的轉變。從習以為常的使用各種軟體到思考怎樣去製造出來一個軟體，一個成熟的軟體具備了哪些功能才能夠讓我們去使用，要同時從人和計算機的角度去思考問題。從人的角度出發，我們要考慮我們所需要的軟體能夠幫助我們幹什麼，在哪些方面減少我們的人工成本，怎樣才是使用起來方便快捷的。從程式碼的角度出發，程式碼能夠實現的功能有哪些，其中的邏輯順序是怎樣的，怎樣才能用最少的程式碼實現最多的功能。盡最大的努力去提出儘可能多的需求。

思維導圖階段：思維導圖，像字面意思一樣，是思維的引導流程圖。相比於繁瑣的文字資訊，它能夠有邏輯有順序的用最少的文字展現一個軟體應有的功能。也能夠說明在人們對於軟體錯誤的操作後，軟體能夠明確的告知。

測試計劃階段：計劃，顧名思義，對任何一件事情都是需要有計劃的，它就像是完成目標的開始，我們在對某件事情有了初步的瞭解之後，怎樣去完成這件事情，誰去完成這件事情，在什麼環境下完成這件事情，怎樣就算達到目標，不管哪一方面，我們都需要一個簡單的計劃，這樣才能更好的掌控事情的發展形勢。

測試設計階段：軟體測試需要我們去測試什麼，我們怎樣才能測試出來我們想要的東西，根據什麼去執行測試。或許這就是測試設計的意義。根據對需求的理解，我們怎樣才算完成對需求的開發，是測試設計的重點，也是測試用例編寫的依據。我們需要全方面的考慮問題。不僅僅是它能不能正常使用，而且也包括在異常情況下的處理；在不同條件，不同環境下功能能否正常使用；一個軟體前端和後端所能顯示的資訊情況是否一致。這些都不再是概括性的描述，而是具體的例項。

需求澄清到用例開發，二三百字到上萬字的文件，對於軟體測試這個行業有了全新的認識。不止是簡單的點點點，是對一個專案上線前的最後一道防線，儘可能多的去避免缺陷產生是軟體測試的職責。

對於現階段的自己，想要更深層次的瞭解軟體測試，需要的是時間和精力的付出。只希望現在的自己，能夠快速的掌握軟體測試的基礎知識，進入這個行業。在實踐中成長，在成長中學習。

第2篇

六天的培訓結束了，感覺過得好快啊。雖然是因為參加“模擬招聘”獲得這次機會的，不像其他同學一樣是交錢的，但是我也是抱著要學東西的心態參加的。

第一天老師就給了個下馬威——教材全是全是英文版的。對於雖然大三的我來說，英語四級剛過，六級成績還沒出來的情況下，想看懂全文是不太現實的。在老師講解過程中利用線上翻譯才勉強能看懂句子。不過培訓過程中最難忘的不是來自教材，而是來自老師的那雙犀利的眼神。無論何時，只要你打開了與課堂無關的網頁，她總會第一時間或叫號碼，或叫名字，或站到你旁邊。說實話，大學上課已經很久沒有這種高中被管的感覺了。雖然不爽，但是卻有種回到高中的快感（說的是實話）。

頭幾天還蠻不錯的，食堂開門的，超市沒關。可後幾天，當校門口已無人煙，就剩我們這幾個的時候就真覺得寢室樓好靜啊，還不如在機房呆著。對於老師我想說的是，前幾天笑容總是掛在臉上，可兩天後明顯笑的少了，不知道是不是因為和大家熟了，沒有剛見面的客氣了（我喜歡看人笑，本身也喜歡笑，老師的這種變化，我很敏銳的察覺了）。

這次培訓雖然感覺學到的沒有很多，但是我瞭解了一個企業，起碼是軟體測試這一行業大致的運作模式，讓我對我將來要不要從事這個行業有了認識。貌似軟體測試女生為主，男生比較適合從開發做起，這是我這幾天得到的最大體會。還有對於課堂結束的演講，是個鍛鍊

自己的好機會，我並不否認這點，不過貌似每個人都只有一次機會，我是個表現欲很強的人，讓我講了一次有點不過癮。

開始我是因為不想浪費免費來上課的就會，來到後我覺得確實很多時候是需要多接觸下這些社會上的公司、企業等，畢竟還有一年就畢業了，到底何去何從自己是真的要好好做個打算了。期待下一期的`網新的培訓??

第3篇

在支付寶測試分析的角色和系統分析的角色是對應的，只不過一個是測試類的另外一個是開發類的。系分下面會有相應開發，測分下面會有相應的測試用例編寫和執行人員。也就是說測試分析文件是對測試執行人員的一個指導(在我原來的理解方式上，覺得測試分析人員應該是用例編寫人員;而在這裡測試分析人員是從業務上去分析的，用例是用例執行人員來寫並且執行的)。

而通過這次的這次分析覺得自己的測分還存在以下的問題：

1、太關注開發的內部實現邏輯。建議：將開發內部實現邏輯看成一個黑盒子，測試分析要從這個黑盒子的輸入和輸出上去看開發內部實現邏輯是不是有問題，而不應該先去了解開發的實現邏輯然後按照他們的思路去分析。

2、分析文件寫的過於詳細，甚至將用例的步驟都寫了出來。建議：測試分析要從全域性上去看問題，細節的東西即便是知道的，也要留給之後的用例編寫人員去了解(就像系分之後的開發需要去寫詳細設計的道理一樣)，這樣後面的人才會自己主動去想問題。

3、分析文件要考慮維護性問題，不要出現類似比如還款中狀態為“r”這種具體的資料內容。因為我的分析是對後續用例編寫人員的一個指導性的文件，所以如果側分這麼寫很有可能導致用例也照著這麼寫，其實不管側分和用例都不應該具體寫到r這麼細節，否則的話開發稍作變動我們就要相應變動我們的用例

4、沒有明確測試目的。review用例的時候，沒有提出每個用例需要明確一個測試目的，讓別人來看這個用例的時候能明白到底是怎麼回事。

1、以後寫測試分析文件，依據僅僅是prd文件，必須拋開開發實現邏輯部分(即不去看系分文件)，待測分出來之後，再去看系分文件，互相看看彼此考慮的是否存在遺漏的地方。等到在寫用例的時候再讓寫用例的人和相應的開發去互相明確更細節的東西。

2、寫用例我們目前都是僅僅做到對流程上的每個節點去單獨分析，細到看輸出的時候會關注到資料庫表的一個變化。但是除了以上部分，其實還少了對整體流程的關注，需要增加業務流程的各條路徑的一個覆蓋，在針對路徑的用例中不需要關注到資料庫表級那麼細。

3、在做流程路徑覆蓋之前應該畫一個路徑圖，這個圖的畫法考慮各個入口的不同分開畫流程圖，分別進行路徑覆蓋。

第4篇

通過這次課程設計的實訓，增加了我學習軟體技術的興趣，雖然還不明確軟體技術包含的具體內容，但從c++語言這門課程開始，已發現程式設計的樂趣，在學習c++語言的過程中也學到了許多計算機應用基礎知識，對計算機的機體也有了一個大體的瞭解。在實際操作過程中犯的一些錯誤還會有意外的收穫，感覺實訓很有意思。在具體操作中對這學期所學的c++語言的理論知識得到鞏固，達到實訓的基本目的，也發現自己的不足之出，在以後的上機中應更加註意，同時體會到c++語言具有的語句簡潔，使用靈活，執行效率高等特點。發現上機實訓的重要作用，特別是對陣列和迴圈有了深刻的理解。

通過實際操作，學會c++語言程式程式設計的基本步驟、基本方法，開發了自己的邏輯思維能力，培養了分析問題、解決問題的能力。深刻體會到“沒有做不到的，只有想不到的”，“團結就是力量”，“實踐是檢驗真理的標準”，“不恥下問”的寓意。

在此希望以後應多進行這樣的實訓，加長設間，培養學生獨立思考問題的能力，提高實際操作水平。

通過本次專案實訓我要感謝學校領導給我們提供了這次機會，讓我們自己有出去體會生活，自己做專案的深刻體會。這次實訓讓我明白我自己之前的學習還是差很多，只有不斷的努力，才能學好。還要感謝達內公司對我的指導，我自己的努力固然重要，但是達內的優秀教師給我做的培訓，講的理論都讓我受益匪淺，讓我對軟體有了一個新的概念新的理解。

第5篇

雖然一如繼往地寫讀書筆記，筆墨也浪費了不少。但真正坐下來利用大段的時間將自己的思路理清還沒有過。因為最近有了一定的時間,更因為狠狠地泡了一段時間測試論壇,下載學習了該網站的電子測試雜誌之後，自己的思路終於開始清晰起來，朦朦朧朧地開始看清了遠方的路,麻著膽子去分析一下自己,也學著展望一下未來了,畢竟摸黑走路的感覺很不好。

我覺得學習軟體測試的通用技術與針對某類軟體的測試技術外,還有一個重要的與技術無關的方面:業務知識.沒有具體的業務知識很難發現軟體中潛在的邏輯錯誤甚至是需求上的錯誤,當然需求要依據特定的軟體,但軟體測試人員對需求理解的深入程度不應低於軟體開發的人員.因為軟體測試所有的依據來自於需求,而所有的需求來自於客戶,甚至是我們的全部都來自於客戶.識別需求後還必須轉化為測試上的需求,畢竟測試人員看需求的角度和開發人員還是有區別的。

關於學習，我知道我並非計算機專業的學生,初涉軟體測試行業，沒有接受系統的培訓，對軟體測試一無所知，既不知道該測試什麼，也不知道如何開始測試。但是,總該知道如何去學習，然而我認為，學習總該有必要的方法。

這是最重要的一條了,也是公司提供的最好的一個條件.剛進來的時候,td,測試案例都有一個pm細心的和你講,案例有什麼方法來設計要注意哪些錯誤軟體測試技術相關書籍目錄、軟體測試流程相關文件目錄、產品業務相關的文件目錄，一大堆的東西馬上夠你頭暈的了.呵呵,還好,悟性不錯,都囫圇吞棗地吞下去了。

無論是神馬專業，我始終確信，萬變不離其宗，我知道，我不是這個專業的，但這個並不代表這我就不瞭解這個，再怎麼不濟，我也是從書本中走出來的，我相信，只要我努力地吧書本啃熟，我能夠靈活地融入到這個職業中去，從書本中找尋解決問題的方法。標記出自己所錯誤的。

總有一天，我們會成為一位前輩，不過不是現在，至少現在我們應該好好的向別人學習，所以，我覺得，前輩是我們前進道路上不可或缺的一部分，他會成為引領我們前進的發動機，給我們指點，跟我們道工作的經驗。然而，我們也應該多說，我知道，前輩們給我們講解，已經是很辛苦的事情，畢竟，這不是他們的義務。我們也應該多多說說我們的觀點，這樣既能夠讓人家瞭解我們的水平，也方便老師前輩們對我們進行指導。

它存在於整個專案週期，在專案開始之初需求調研的時候就開始了，在形成需求規格說明書的時候就需要針對文件進行測試。這個環節在後續整個專案中佔了很大的比重，能主導整個專案的走向，成敗與否全在於開始階段的決策。

體會二：軟體測試的真正意義在於發現錯誤，而不在於驗證軟體是正確的。

再嚴密的測試也不能完全發現軟體當中所有的錯誤，但是測試還是能發現大部分的錯誤，能確保軟體基本是可用的，所以在後續使用的過程中還需要加強快速響應的環節。結合軟體測試的理論，故障暴露在最終客戶端之前及時主動的去發現並解決。這一點就需要加強研發隊伍的建設。