軟件測試實習的開展能使實習生們對軟件測試工作有一定的認識與理解。軟件測試實習報告是小編爲大家帶來的，希望對大家有所幫助。
第一篇：軟件測試實習報告
這學期學習了軟件工程實踐這門課，我覺得這是對上學期的軟件工程課程學習的檢驗，上學期學習軟件工程只是我們淺顯的認識，相比之下，這學期就更加全面的說明了開發一個項目所需要的步驟以及開發項目過程中所需要注意的諸多細節。如果說上學期的課程注重理論基礎的話，那麼這學期的軟工實踐，顧名思義，就是側重我們動手操作的能力。
原來我認爲開發一個項目最重要的就是寫代碼，似乎整個軟件都是編代碼，因爲自己動手能力不強所以就很排斥做項目。可是經過我們學習軟工課程到團隊做項目再到學習軟件工程實踐課程之後，我才真正意識到實施一個軟件工程項目並不是說簡單的會編碼就能夠解決問題的，因爲一個軟件的生命週期分爲三個時期：軟件定義時期、開發時期、維護時期，而這三個時期整體又分爲七個階段，他們分別是：問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼和單元測試、綜合測試，由此可看出，當我們開發一個項目時，更多的精力不是放在編碼上，編碼只是一個很小的模塊，而是項目的整體結構上。
在寫軟工實踐體會之前，我想在這裏總結一下上學期三人團隊做 項目的相關事宜。上學期我們三人團隊根據軟件開發的步驟開發一個名爲“西大老鄉‘薈’”的社交系統，主要是爲西大學子提供一個找老鄉的平臺。雖然只進行到詳細設計階段，沒有進一步實現，但是我還是從中學到很多東西的。首先要先確定項目主題，也就是這個項目用來做什麼，可以解決什麼問題。接着就是這個項目是否有研究的必要以及是否有解決的辦法，針對我們的項目，我們對西大的一些學生做了問卷調查，並從調查中繼續完善系統本身的做用戶。第三步根據我們確定的項目主題進行需求分析，這一步驟當時做的不是很好，比如所畫E-R圖、數據流圖等都有考慮不周的問題，導致接下來的概要設計、詳細設計進行的很困難，有些步驟甚至還需要返工。
從我們在需求分析中出現的問題，使我們明白了軟件定義階段對於一個項目的開發是至關重要的，當軟件定義階段完成時必須要用正式的文檔準確的地記錄目標系統的需求。只有前期的準備工作做得好，後面的工作才能順利進行。雖然項目最後沒有完全實現，但是起碼我們已經初步體會到軟件項目開發的步驟，以及每一步所需要完成的文檔等內容。
這學期的軟件工程實踐雖然不是親自動手開發一個系統，但是張元平老師以“物聯網物流倉儲管理系統”爲主給我們講解了一個真實系統的開發過程，從計劃到項目系統的發佈實施，以及每一步必須生成的文檔。我主要從以下五個方面談一下我的心得體會。
第一、行業背景說明方面
對於一個軟件系統的開發，第一步就是問題定義，瞭解所開發系統的行業背景，制定計劃。當我們計劃確定以後就要對項目系統本身進行可行性研究，主要從技術可行性、經濟可行性和操作可行性三個方面着手。就比如《物聯網物流倉庫管理系統》的行業背景說明文檔中非常詳細地分析了當下物聯網物流行業的整體業務說明、應用背景、未來發展趨勢以及相關應用案例等四個方面，項目團隊中系統分析員就可以根據這份文檔以及相關的調查資料對將要開發系統的進行定義等工作。
原來我們寫這類文檔的時候就是草草了事，不會做得這麼詳細，而這次看到大型項目的行業背景說明也是這麼詳細，也讓自己認識到不管是軟件開發的那個階段都要認真對待，這些瑣碎的文檔都是後期開發項目的支撐，只要它們做的透徹，後面的開發工作才能更順利的進行。
第二、項目需求說明方面
這部分項目需求說明就是軟件定義時期中需求分析階段，而該階段的主要目的就是了解用戶的需要，根據用戶的需要確定系統必須完成那些工作，並對目標系統提出完整、準確、清晰、具體的要求。在需求分析結束之前系統分析人員要寫出一份需求規格說明，即爲《物聯網物流倉儲管理系統》項目需求說明文檔。我們可以看出該文檔也是非常詳細，相比之下我們之前做項目時寫的需求規格說明書就非常不合格，不僅格式不正確內容也是少之又少。
在這方面，這篇文檔給我啓發很大。首先就是文檔的格式，要美觀整齊，讓人看着舒服方便。其次就是文檔的內容，原來它不是很重要，寫文檔的時候也不知道怎麼寫就借鑑下網上的內容，結果根本就沒有把自己項目的需求寫明白，以至於自己最後都有些糊塗，所以根據以前的經驗教訓我會對這部分更加重視。
第三、系統概要設計方面
這部分內容分說的是軟件設計時期的概要設計階段，該階段的主要目的就是實現系統的功能、設計軟件的結構、模塊組成以及模塊之間的關係。在概要設計階段，我們可以站在全局的高度上，花較少的成本，從抽象的層次上分析對比多種可能的系統實現方案和軟件結構，從中選出最佳方案和最合理的結構。在這個階段還會具體畫出E-R圖、數據流圖等方面的設計。
比如《物聯網物流倉庫管理系統》的系統概要設計從項目概述、設計約束、功能單元與功能模塊設計、數據E-R圖設計、總體設計、界面設計等六個方面介紹，通過讀這個文檔，我覺得最重要的還是總體設計，分別從邏輯架構設計、物理架構設計、技術架構設計設計系統。在這個階段中模塊要做到高內聚低耦合，這樣開發出來的系統纔會具有更高的獨立性。
在原來做項目時沒有編寫過這類文檔，在該階段只是畫了結構圖、層次圖以及相關的模塊劃分，對該類文檔尚未重視。通過張老師的講解和自己的學習，我相信在以後做項目的時候一定會注意到這類文檔的編寫。
第四、詳細設計與分析方面
詳細設計階段就是把概要設計階段的每個模塊進一步設計，確定每個模塊所需要的算法和數據結構。在這個階段還是需要我們設計出程序的詳細規格說明，而不是編寫程序。在詳細設計階段，系統設計人員可以通過使用程序流程圖、盒圖、PAD圖等過程設計的工具和Jackson圖等面向數據結構的設計工具進一步設計系統相關接口，主要包括界面設計接口、業務單設計接口、單元模塊設計接口等，這些對於以後的編碼工作都是極其重要的。
第五、編碼和測試方案方面
關於編碼，我認爲編碼要想做的完美必備條件就是前面的軟件定義和軟件設計時期要按部就班的做，文檔一定要按要求書寫，不能偷懶也不能草草書寫。對於編碼也要有相應的文檔書寫規範，要使源程序代碼的邏輯簡明清晰、易讀易懂。這樣儘管我們不是設計系統的人員，當看到源程序代碼的時候也能容易讀懂代碼的意思。
其次就是測試的內容，從測試的文檔中我們可以得出，其實測試在軟件開發中同樣佔據了重要的地位，它主要就是儘可能多的找到問題並排除其中的潛藏的錯誤，最終把一個高質量的軟件系統交給用戶使用。它要求測試人員也要有很高的技術水平。
第二篇：軟件測試實習報告
這次軟件工程實訓是從20xx.12.26號開始的，截至20xx.12.31號。實訓內容是用java相關知識(主要是jsp)做一個物流配送系統。下面談談對這次實訓的看法。
因爲自己平時對java知識儲備不足，特別是jsp這一塊基本不瞭解怎麼回事，所以一拿到這個項目，我心裏都是沒有底的，再加上我被分到的那個組，我知道就意味着是我一個人在戰鬥了。呵呵，26號，實訓開始了，我們的老師是來自中軟國際公司的程序員，一個是周褀，一個是朱映，都是一身樸素的着裝，讓我感覺做軟件的也沒什麼兩樣。老師介紹了自己之後，就直接切入正題了，分析了下我們各個組的系統，即將用到的知識，然後就總體把覺得需要補充的知識(jsp和數據庫連接等這幾塊)給我們實際操作了下，因爲當時看到用jsp，還講的那麼認真，當時我就後悔了，平時要是多聽點，現在老師這麼認真的給我們講，這是一個多麼難得的機會啊。後悔也沒用啊，開始還勉強能理解一點，後來就直接暈了。然後再給大家介紹了一些即將用到的工具，比如rationalRose，SVN，MyEclipse等等。接下來的幾天就不再細講了。下面談談通過這次實訓的心得體會吧。
通過這次實訓，讓我瞭解到工程開發的過程，可行性分析——>需求分析——>概要設計——>詳細設計——>代碼編寫——>測試——>驗收。從技術方面上，我開始jsp基礎基本上就是零的，在老師和syz2(另外一個物流小組，我一個人基本上是跟她們做的，或者說是看着她們做的)的幫助下，對jsp有了一個大概的認識。其實實訓開始前，我還以爲做個系統沒什麼大不了，可是當真正拿到一個項目，我卻真的無從下手了，而且就是在知道需求分析和詳細設計，在代碼編寫時，一樣寸步難行。通過這個實訓，也讓我瞭解到，團隊協作是多麼的重要。一個人的精力是多麼的有限。進一步理解到，企業爲什麼如此重視團隊協作。同時借用老師的話就是團隊協作固然重要，但是是建立在個人素質的基礎上，假設你個人素質不行，將會影響到整個團隊，就別提對團隊作更多貢獻了。**老師說這幾句話的時候，朝向了我，估計是有特殊意義的吧，所以，我將謹記老師的教導。
還有一個收穫是從一個同學(小胖)那裏得到的，他的那組成員跟我的這組大體一樣，我倒是覺得沒什麼了，不過他倒是很重視這個問題吧。然後他說出來，我也覺得這個問題確實其實是個大的問題。就是不管你會不會這門技術，會不會做這個東西，態度要正確纔好，就算你不會做，你也應該認真的對待，將來 出身到社會，就不是說像你現在，不會做就不做，跑去玩遊戲了。小胖說出了這段話，也在我身上有了一個印證，雖然我jsp技術知識爲0，但我也還是在認真的跟着他們一起做，不會做，就多問，畢竟現在我們是學生，可以毫不顧忌的詢問各種問題，老師也會盡力爲你回答。將來出身社會就不一樣了。雖然，我就算個打醬油的水平，但是這個醬油也要打得有涵量啊。不管怎麼樣，我能對自己有個交待，雖然我不會，但是這次實訓我確實是認真對待了，六天的實訓，除了晚上加班外，還花了2個通宵來完成不同階段的任務，完成與否也不重要了，我至少我做了，這點，是這次我應該對自己的一個肯定。
這次實訓的心得基本上就是這些了，最後特別感謝中軟國際帶我們的那兩個老師(周褀，朱映)，這兩個老師對待我們很平易近人，對我們提出的問題，總是不光解決了，還進行了擴展，晚上也跟我們一起加班加到很晚，印象尤其深刻就是朱映老師爲了給小胖解決一個問題，臉都變紅了，還在繼續努力，這點我並不會覺得老師知識儲備不夠，我想應該是這個問題的突發吧，一時沒想到怎麼處理。相反讓我感覺更多的就是老師很認真，很負責。還要感謝就是syz2小組的傾力支持，輔導。
第三篇：軟件測試實習報告
20XX年11月28日，我懷着提高並實現自我價值的心態，跨進E軟件技術有限公司的大門，開始了自己第一份實習工作。這是一家國內知名的專業軟件外包企 業，在深圳華南地區位居行業前列。易軟自開始從事軟件外包業務以來，服務合作模式從人力資源外包發展到項目外包、離岸開發和OEM產品合作等模式。業務領 域包括電信業，金融業，製造業等。特別在電信行業有多年積累,在電信業務領域涉及固網,智能網、移動通信、光網絡,電信增值服務等業務領域.易軟公司總部 設在深圳, 在上海、南京、北京，廣州，重慶，蘇州，武漢，大連等地建立了分公司或辦事處，就近爲客戶提供外包服務。
轉眼間，三個月實習 時間就過去了。回想起這段時間的工作過程，我從一名普通的大學生到一個爲社會服務的軟件測試人員，思想覺悟有了很大的提高，作爲一個剛剛步入企業的年輕人 來說，什麼都不懂，沒有任何實踐經驗，不過在各位同事的幫助下，我很快的融入到了這個新環境，還學到了很多在學校學不到的東西，也認識到了自己很多的.不 足，感覺受益匪淺。以下是我在這幾個月實習期間對工作的總結以及一些自己的心得體會。
要想成爲好的測試人員，首先得了解自己要測試的軟件 的相關知識。要了解軟件產品的架構是什麼樣的。要了解軟件的市場需求，在接觸軟件之初要可以多看看用戶的反饋信息，這些纔是用戶最關心的，也是在測試中需 要注意的問題，滿足客戶是最大的需要。但是瞭解軟件需求之後要學會要多讀些軟件系統的技術文檔，軟件設計文檔，這些文檔可以幫助瞭解產品如何工作。還有多 看看公司 Bug 庫中的問題，這些存在的問題可以幫助自己瞭解軟件產品那些地方存在缺陷，軟件系統那些地方會出現錯誤。軟件是運行在一個大環境中，如果對系統不熟悉，那麼 有些問題你不能從一個更廣闊的層面考慮，學習操作系統的知識，有助於你發現缺陷，定位問題更加準確。比如軟件運行在 Windows 或者 Linux ，如果不懂操作系統，你就無法建立測試環境，有些時候時候軟件的組件發生問題，就是自己系統配置造成的，對系統不熟悉，會把外在原因歸結爲軟件本身。所以 要學習關於和軟件系統相關的知識，比如編程，網絡，數據庫等。不一定要學習到多好的程度，只是通過這些擴展的知識面，可以在發現問題，解決問題上不會侷限 在狹小的圈子裏。
和一切相關的人員交流，不同的交流渠道，獲取消息是不同的，角度也不同。和客戶交流，會在測試中從客戶的角度發現問題;和開發人員交流，會了解開發人員怎麼實現軟件功能的;和項目管理人員交流，會知道開發進度以及遇到的困難。
在這實習期間，我就參與了一個項目，這對我在軟件測試方面有了一定的認識和需要注意的地方。
在滕邦國際的項目中，我主要負責的是wap網站、Symbian客戶端和後臺管理系統，對有關用戶界面的測試和測試執行流程有了一定的瞭解，學會了對bug管理工具Bugzilla的使用。
一.有關用戶界面的測試
1.圖形測試
圖形包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。
(1) 要確保圖形有明確的用途，應用系統的圖片尺寸要合理，並且要能清楚的說明某件事情，一般都鏈接到某個具體的頁面。如在滕邦項目中，wap網站跟客戶端的標誌圖形就不一樣，酒店模塊、機票模塊和旅遊模塊的圖片也是不同的。
(2)驗證所有頁面字體的風格是否一致。
(3)背景顏色與字體顏色和背景色相搭配。如本項目以該企業顏色爲主。
2.內容測試
內容測試用來檢驗應用系統提供信息的正確性、準確性和相關性。信息的正確性是指信息是可靠的還是誤傳的。信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口，也就是一般Web站點中的所謂"相關文章列表"。
如在滕邦項目中，在查詢機票的時候出現一個不應存在奧林匹克航空，查詢機票深圳-北京時，出現美國聯合航空 UA，屬於國際票務，也是不應該查詢到的。
3.整體界面測試
整體界面是指整個 應用系統的頁面結構設計，是給用戶的一個整體感。例如：當用戶瀏覽應用系統時是否感到舒適，是否憑直覺就知道要找的信息在什麼地方?
整個應用系統的設計風格是否一致?
在滕邦國際項目中，除了wap網站外，還有Symbian、Android、WinMobile三個客戶端，所以在事先沒有標準的情況下，各個平臺的導航不統一，各關鍵字段也不一致。
二管理
1. 在進行測試前，首先必須理解業務和需求。需求和業務理解了，才知道客戶想要系統實現什麼。然後按照需求來進行測試，不滿足需求要求的都可以認爲是BUG。
2. 和開發人員溝通。這裏說的溝通並不僅僅指通過溝通試圖讓開發人員修改每個BUG，這個當然需要溝通，但是並不是指所有的BUG都需要修改，這中間涉及到成 本、技術，還有別的問題。除此之外，通過和開發人員搞好關係，對於BUG我們可以問他發生該BUG的原因，修改的大致方法，甚至不修改的原因等等，這有助 於以後測試中多注意、多發現這樣的問題，甚至提出修改建議。
如在Symbian客戶端測試中，會出現“內存不足，請關閉一些應用程序後再試”的警告，是屬於正常現象。
3. 決定BUG嚴重性的時候，可以根據該被測對象在整個系統中充當的角色，實現的功能來判定如果該對象出現錯誤會對整個系統產生什麼樣的影響，對產生的影響打 分，從而定義BUG的嚴重程度;決定BUG優先級的時候，可以先假設不修復該BUG，出現的這些問題會產生哪些影響，然後判定這些影響的嚴重性來判定 BUG的優先性。
如在項目中，旅遊模塊頁面中，點擊查詢時自動退出系統，本是屬於High單，而我提的是Medium單。
4. 容易產生BUG的情況：雖然在開發過程中，軟件需求通常都會發生改動，所以如果某一部分的軟件需求頻繁發生變動，那麼就會導致和這部分相關的編碼和設計會相應的頻繁變動，那麼在測試中，這部分編碼設計實現的部分出現BUG的可能性就很大。
如果在開發的過程中，大量使用了第三方的組件，或者從別的軟件中移植了大量的代碼，那麼和這些第三方的組件和代碼相關部分出現BUG的可能性就很大。