軟體測試實習報告三篇
第一篇：軟體測試實習報告
這學期學習了軟體工程實踐這門課，我覺得這是對上學期的軟體工程課程學習的檢驗，上學期學習軟體工程只是我們淺顯的認識，相比之下，這學期就更加全面的說明了開發一個專案所需要的步驟以及開發專案過程中所需要注意的諸多細節。如果說上學期的課程注重理論基礎的話，那麼這學期的軟工實踐，顧名思義，就是側重我們動手操作的能力。
原來我認為開發一個專案最重要的就是寫程式碼，似乎整個軟體都是編程式碼，因為自己動手能力不強所以就很排斥做專案。可是經過我們學習軟工課程到團隊做專案再到學習軟體工程實踐課程之後，我才真正意識到實施一個軟體工程專案並不是說簡單的會編碼就能夠解決問題的，因為一個軟體的生命週期分為三個時期：軟體定義時期、開發時期、維護時期，而這三個時期整體又分為七個階段，他們分別是：問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼和單元測試、綜合測試，由此可看出，當我們開發一個專案時，更多的精力不是放在編碼上，編碼只是一個很小的模組，而是專案的整體結構上。
在寫軟工實踐體會之前，我想在這裡總結一下上學期三人團隊做 專案的相關事宜。上學期我們三人團隊根據軟體開發的步驟開發一個名為“西大老鄉‘薈’”的社交系統，主要是為西大學子提供一個找老鄉的平臺。雖然只進行到詳細設計階段，沒有進一步實現，但是我還是從中學到很多東西的。首先要先確定專案主題，也就是這個專案用來做什麼，可以解決什麼問題。接著就是這個專案是否有研究的必要以及是否有解決的辦法，針對我們的專案，我們對西大的一些學生做了問卷調查，並從調查中繼續完善系統本身的做使用者。第三步根據我們確定的專案主題進行需求分析，這一步驟當時做的不是很好，比如所畫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三個客戶端，所以在事先沒有標準的情況下，各個平臺的導航不統一，各關鍵欄位也不一致。
二、bug管理
1、在進行測試前，首先必須理解業務和需求。需求和業務理解了，才知道客戶想要系統實現什麼。然後按照需求來進行測試，不滿足需求要求的都可以認為是BUG。
2、和開發人員溝通。這裡說的溝通並不僅僅指透過溝通試圖讓開發人員修改每個BUG，這個當然需要溝通，但是並不是指所有的BUG都需要修改，這中間涉及到成 本、技術，還有別的問題。除此之外，透過和開發人員搞好關係，對於BUG我們可以問他發生該BUG的原因，修改的大致方法，甚至不修改的原因等等，這有助 於以後測試中多注意、多發現這樣的問題，甚至提出修改建議。
如在Symbian客戶端測試中，會出現“記憶體不足，請關閉一些應用程式後再試”的警告，是屬於正常現象。
3、決定BUG嚴重性的時候，可以根據該被測物件在整個系統中充當的角色，實現的功能來判定如果該物件出現錯誤會對整個系統產生什麼樣的影響，對產生的影響打 分，從而定義BUG的嚴重程度；決定BUG優先順序的時候，可以先假設不修復該BUG，出現的這些問題會產生哪些影響，然後判定這些影響的嚴重性來判定 BUG的優先性。
如在專案中，旅遊模組頁面中，時自動退出系統，本是屬於High單，而我提的是Medium單。
4、容易產生BUG的情況：雖然在開發過程中，軟體需求通常都會發生改動，所以如果某一部分的軟體需求頻繁發生變動，那麼就會導致和這部分相關的編碼和設計會相應的頻繁變動，那麼在測試中，這部分編碼設計實現的部分出現BUG的可能性就很大。
如果在開發的過程中，大量使用了第三方的元件，或者從別的軟體中移植了大量的程式碼，那麼和這些第三方的元件和程式碼相關部分出現BUG的可能性就很大。
【軟體測試實習報告】相關文章：