管理實習報告模板合集八篇

　　在不斷進步的時代，大家逐漸認識到報告的重要性，報告具有成文事后性的特點。那么什么樣的報告才是有效的呢？以下是小編為大家收集的管理實習報告9篇，僅供參考，歡迎大家閱讀。

管理實習報告 篇1

　　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的可能性就很大。

　　例如在本項目中，機票模塊和酒店模塊的需求經常改動，所以這兩個模塊也是該測試的重點;Symbian客戶端有V3版本、V5版本，這兩個版本之間的代碼大致相同的，V5版本也是大量復制了V3版本的代碼，所以V3版本出現異常的時候，V5版本也就會出錯。

　　5. 描述BUG主題時，應當根據實際情況，簡要的描述出自己的操作和希望被重視的現象，不應該包含自己對異常表現出現的原因的推測和猜想。BUG的描述要簡潔易懂。

　　6. 不能假設開發人員對他們開發的程序和業務需求都十分熟悉，在提交BUG的時候，一定要說明白是哪個模塊的哪個功能，出現了哪種類型的錯誤，并且，如果需要，應該把這部分相應的需求都描述出來。

　　實習這段期間，自己的收獲是豐碩的：最起碼從意識上，發現自己的不足，并尋求到合適的解決途徑。非常感謝那些曾對我幫助的同事。因為你們的幫助，我順利的走過了我人生中第一份工作的適應期。我堅信：在你們的幫助下，我會持續努力，不斷反省，總結提高。