第一篇：軟件測試總結報告

引言

1.1 編寫目的

編寫該測試總結報告主要有以下幾個目的 1．通過對測試結果的分析，得到對軟件質量的評價

2．分析測試的過程，產品，資源，信息，為以后制定測試計劃提供參考 3．評估測試測試執行和測試計劃是否符合

4.分析系統存在的缺陷，為修復和預防 bug 提供建議

1.2 背景

1.3 用戶群

主要讀者：***項目管理人員 其他讀者：*** 項目相關人員。

1.4 定義

基本功能點測試：等價類劃分法、邊界值法、錯誤推測法、場景法

業務流程測試：根據業務邏輯，構建測試數據，執行業務流程，查看執行結果與預期是否一致 界面易用性測試：根據界面測試規范及日常使用習慣，提出軟件的非功能實現問題

回歸測試：對已修復的問題，根據測試出該錯誤的用例，重新執行該用例，驗證問題是否真正被修復，以及是否又引起了其它錯誤

1.5 測試對象

對綜合管理系統進行全新測試，主要進行功能測試、系統測試

1.6 測試階段

第一階段：對主業務邏輯及功能進行測試 第二階段：對所有業務邏輯及功能進行深入測試 第三階段：回歸測試

1.7 測試工具

BugFree缺陷管理工具

1.8 參考資料

《***功能描述》 《***數據字典》 《***測試計劃》 《***測試用例》 《***項目計劃》 測試概要

***系統測試從 2012年7月25日到2012年10月12日基本結束，歷時近70個工作日。后續還有一些掃尾的工作，又增加一些工作時日。是一項花費大量人力物力的項目。

***通過BugFree缺陷管理工具進行缺陷跟蹤管理，在bugfree中有詳細的測試用例以及用例執行情況記錄

2.1 進度回顧

2.2 測試執行

此次測試嚴格按照項目計劃和測試計劃執行，按時完成了測試計劃規定的測試對象的測試。針對測試計劃規定的測試策略，在測試執行中都有體現，在測試執行過程中，依據測試計劃和測試用例，對系統進行了完整的測試、2.3 測試用例

測試環境與方法

3.1 軟硬件環境

3.2 測試方法和工具 測試結果

4.1 Bug 引入階段

4.2 Bug 引入原因 測試覆蓋分析

1.此次測試的重點在在于對功能的測試，特別是V2.0新增功能的測試； 2.***完成在常見的操作環境下的測試，因此具有良好的兼容性。

3.本次此時的目的除了基本的功能測試外，重點突出對系統易用性的測試，力圖使系統更加的人性化，操作更加簡單，易懂。測試結果和建議

6.1 測試結論

1.***的測試工作已基本結束，功能測試目標也已完成，剩下部分報表的設計需要繼續完善。

2.本次測試從功能性，易用性，兼容性等多個方面進行測試，力圖在滿足客戶需求的基礎上操作更加簡捷，人性化。6.2 改進建議

1.測試過程中遇到的最大問題是需求的不確定性和需求的變更。前期由于開發人員和測試人員對一些需求的理解不一致，或是在需求文檔中需求的定義不明確，大家根據自己的理解開展工作，繼而在后期工作中產生一些不必要的bug;除此之外，由于在前期，沒有對客戶的需求進行較為準確的界定，在開發過程中，客戶提出一些新的要求，而這些要求和其他功能具有關聯性，需求做改動，開發和測試也進行改動，比較顯著地例子是在開發中后期要求在一個關聯性強的表中增加一個字段，從而引起一系列重復的測試。因此我認為在開發前期要反復確定需求，并制定需求變更標準，避免在開發過程中出現重復，返工的現象。

2.本次測試由于主要是手工測試，因此未能實現對一些功能的進行大量數據操作的測試

3.系統目前比較明顯的缺陷是報表打開速度比較慢，這個嚴重影響了系統的性能，是需要研究改進的部分。

第二篇：WEB軟件測試總結報告

XXX管理平臺

XXX項目測試總結報告

目錄

1.項目測試結果........................................................................................................................2 1.1 BUG嚴重程度................................................................................................................2 1.2 BUG問題分布狀況........................................................................................................3 2.測試結論................................................................................................................................4 2.1界面測試.........................................................................................................................4 2.2功能測試.........................................................................................................................4 2.3兼容性測試.....................................................................................................................4 2.4易用性.............................................................................................................................4 2.5 負載/壓力測試...............................................................................................................5 3.軟件問題總結與分析............................................................................................................6 4.建議........................................................................................................................................7

XXX管理平臺

1.項目測試結果

1.1 BUG嚴重程度

測試發現的bug主要集中在次要功能和輕微，屬于一般性的缺陷，但測試的時候出現了37個主邏輯級別的bug,以及嚴重級別的2個.XXX管理平臺

1.2 BUG問題分布狀況

由上圖可以看出，主要為代碼錯誤占36%,以及標準規范的問題占35%,界面優化占17%,設計缺陷占9%,其他占2%

XXX管理平臺

2.測試結論

2.1界面測試

網站系統實現與設計稿一致。站點的導航條位置，導航的內容布局，首頁呈現的樣式與需求一致。網站的界面符合標準和規范，直觀性強。

2.2功能測試

分不同賬號 總權限賬號,以及店長賬號分別進行功能測試。1:鏈接測試無問題,不存在死鏈接,測試鏈接都存在.2:對頁面各個不同數據的測試,主要的出入庫,銷售報表,訂單查看管理等一一對應,不存在數據有誤差的問題.2.3兼容性測試(Windows下)測試總的瀏覽器包括:360極速瀏覽器,火狐瀏覽器,谷歌瀏覽器,IE瀏覽器,測試通過,主要邏輯以及次要功能都沒問題,因為瀏覽器的不同,導致界面瀏覽不一定相同,例如有的界面瀏覽頁面顯示正常,有的界面顯示不一樣。

2.4易用性

網站實現了如下易用性： 1.輸入限制的正確性

2.輸入限制提示信息的正確性，可理解性，一致性 3.界面排版美觀

4.web應用系統易于導航，直觀

5.web應用系統的頁面結構、導航、菜單、連接的風格一致

XXX管理平臺

2.5 負載/壓力測試

主要測試了壓了測試: 測試

結

果

60秒內發請求,一次1000個請求,總共請求了2230個請求,成功了2208個失敗兩個 1:每個請求用時30ms(吞吐量)2:服務器收到請求，響應頁面要花費的時間:332ms 3: 并發的每個請求平均消耗時間 :33.ms 4:請求一共花了:72s

XXX管理平臺

第一個1000個人同時發出1000個請求 總共1004個請求失敗4個,成功1000 1:每個請求用時9ms(吞吐量)2:服務器收到請求，響應頁面要花費的時間:109128ms 3: 并發的每個請求平均消耗時間 :109.ms 4:請求一共花了:109s

1:如上圖當同時在線人數達到45時候,服務器崩潰,導致成功率一直下降到達40%,直到結束總請求達到:26796.平均每個請求響應時間為281ms,系統吞吐量(tps)20.89/s.因為系統被困導致數據反映不準.3.軟件問題總結與分析

從測試過程中發現bug的嚴重程度與分布狀況來看，引起缺陷主要有以下幾方面：

1.沒有需求文檔

需求文檔只是個大綱的形式，沒有詳細的需求文檔。沒有相應的輸入輸出字段限制及統一的字段名稱，使得開發人員根據需求進行設計時，沒有考慮相關功能的關聯性。在沒有詳細需求的指引下，開發人員根據自己的經驗進行設計，負著不同模塊開發的人員沒有統一設計。在測試過程中，需求相關聯的問題表現出來，及風格統一的問題。例外沒有需求文檔導致測試,無法根據需求文檔來進行用例的設計,只有靠自己自己測試經驗來測試排除BUG.2.功能性錯誤

在測試的過程中，部分功能沒有現實，導致部分模塊無法進行功能的測試。功能實現錯誤，在功能模塊的開發時，是進行先開發后調整的策略，沒有具體的需求文檔，部分模塊的功能實現有所偏差。

3.頁面設計易用性缺陷 頁面輸入字段限制不統一，系統中多個頁面存在相同的字段，但用戶輸入相

XXX管理平臺

同的數據，提示輸入的限制不相同，沒有統一輸入字段的限制。

提示信息錯誤，不同模塊相同結果的提示信息不一致，用戶操作后，相應的提示信息不明確，引起用戶誤解。

提示信息一致性，用戶在不同頁面執行相同的操作，提示信息不同。4.開發人員疏忽引起的缺陷

網站在開發的過程中，不斷的追加新需求，或調整。開發人員修復或修改問題時，有時疏忽沒對相關聯的地址進行修改驗證。導致因修改修復問題而引入更多的問題。

5.開發版本的控制

在測試一個版本(代理商版)，發現問題重復出現，還會引入新的bug,開發人員修改的問題時，提交的版本相互覆蓋。引起上一個版本已關閉的問題，在下一版本重復出現。

4.建議

在項目開始的時候，應該制定相應的標準，編碼標準，需求變更標準等，開發和測試人員嚴格按照標準進行，可以在后期減少因為開發，測試不一致而導致的問題，同時可以降低溝通成本。

發布版本的時候，正確布置測試環境，減少因為測試環境，測試數據庫數據的問題而出現的無效bug。

開發人員解決bug的時候，填寫bug原因以及解決方式，方便bug的跟蹤。開發人員在開發版本上發現bug，可以通知測試人員，因為開發人員發現的bug很有可能在測試版本上出現，而測試人員和開發人員的思路不同，有可能測試人員沒有發現該bug，而且，這樣可以保證發現的bug都能夠被跟蹤。

做好版本的控制，從開發版本，測試版本做好每個環節的版本控制。

第三篇：《軟件測試技術》課程總結報告

《軟件測試技術》課程總結報告

班級：姓名：學號：

一、課程概述

二、課程實訓項目

三、課程知識點總結

四、收獲和體會

第四篇：軟件測試（推薦）

一、簡答5*6’

1.為什么不讓時間有余的人做測試工作

表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關系。測試工作人員應該是勤奮并富有耐心，善于學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它工作同樣也會很出色，因此這里還有一個要求，就是要喜歡測試這項工作。2.軟件測試風險主要體現在哪里

我們沒有對軟件進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。因此，我們要盡可能的選擇最合適的測試量，把風險降低到最小 3.所有軟件測試缺陷都需要修復嗎

從技術上講，所有的軟件缺陷都是能夠修復的，但是沒有必要修復所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美。對于整個項目團隊，要做的是對每一個軟件缺陷進行取舍，根據風險決定那些缺陷要修復。發生這種現象的主要原因如下：-沒有足夠的時間資源。在任何一個項目中，通常情況下開發人員和測試人員都是不夠用的，而且在項目中沒有預算足夠的回歸測試時間，修改缺陷可能引入新的缺陷。

-有些缺陷只是特殊情況下出現，這種缺陷處于商業利益考慮，可以在以后升級中進行修復。-不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理。缺陷是否修改要由軟件測試人員、項目經理、程序員共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定。4.如何減少測試人員跳槽帶來的損失 建議我們從以下兩個方面做起：

-加強部門內員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化。

-管理者就應該把員工的個人成長和企業的發展聯系起來，為員工設定合理發展規劃并付諸實現。

5.驗收測試的注意點有哪些 測試要注意下面的事項：

（1）用戶現場測試不可能測試全部功能，因此要測試核心功能。這需要提前做好準備，這些核心功能一定要預先經過測試，證明沒有問題才可以和用戶共同進行測試。測試核心模塊的目的是建立用戶對軟件的信心。當然如果這些模塊如果問題較多，不應該進行演示。（2）如果某些模塊確實有問題，我們可以演示其它重要的業務功能模塊，必要時要向用戶做成合理的解釋。爭得時間后，及時修改缺陷來彌補。（3）永遠不能欺騙用戶，蒙混過關。6.完全測試程序是可能的嗎

實際上完全測試是不可能的。主要有以下原因：-完全測試比較耗時，時間上不允許；

-完全測試通常意味著較多資源投入，這在現實中往往是行不通的；-輸入量太大，不能一一進行測試；-輸出結果太多，只能分類進行驗證；-軟件實現途徑太多；

-軟件產品說明書沒有客觀標準，從不同的角度看，軟件缺陷的標準不同；因此測試的程度要根據實際情況確定 7.是不是發現的缺陷越多就說明軟件缺陷越多 其中的原因主要如下：

-代碼復用、拷貝代碼導致程序員容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反復拷貝同一代碼意味可能也復制了缺陷。-程序員比較勞累是可以導致某些連續編寫的功能缺陷較多。

“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象。如果軟件編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程序就可以了。8.軟件測試就是QA嗎

軟件測試人員的職責是盡可能早的找出軟件缺陷，確保得以修復。而質量保證人員（QA）主要職責是創建或者制定標準和方法，提高促進軟件開發能力和減少軟件缺陷。測試人員的主要工作是測試，質量保證人員日常工作重要內容是檢查與評審，測試工作也是測試保證人員的工作對象。軟件測試和質量是相輔相成的關系，都是為了提高軟件質量而工作。9.測試產品和測試項目區別

習慣上把開發完成后進行商業化、幾乎不進行代碼修改就可以售給用戶使用的軟件成為軟件產品，也就是可以買“賣拷貝”的軟件，軟件項目是一種個性化的產品，可以是按照用戶要求全部重新開發，也可以修改已有的軟件產品來滿足特定的用戶需求。項目和產品的不同特點，決定我們測試產品和測試項目仍然會有很多不同的地方：

-質量要求不同。通常產品的質量要高一些，修復發布后產品的缺陷成本較高，甚至會帶來很多負面的影響。而做項目通常面向某一用戶，雖然質量越高越好，但是一般只要滿足用戶要求就可以了。測試資源投入多少不同。做軟件產品通常是研發中心來開發，進度壓力要小些。同時由于質量要求高，因此會投入較多的人力、物力資源。項目最后要和用戶共同驗收測試，這是產品測試不具有的特點。此外，測試產品與測試項目在缺陷管理方面、測試策略制定都會有很大不同，測試管理者應該結合具體的環境，恰如其分的完成工作 10.如何編寫提交給用戶的測試報告

測試報告一般分為內部測試報告和外部測試報告。內部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況,一般外部測試報告要滿足下面幾個要求：

根據內部測試報告進行編寫，一般可以摘錄；不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的；報告上面的內容盡量要真實可靠；整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。總之，外部測試報告要小心謹慎的編寫。

二、論述2*12’

1.請論述為什么要進行軟件測試，并列舉歷史上2~3個著名軟件測試（缺陷）案例，說明測試重要性

軟件測試的目的,第一是確認軟件的質量，其一方面是確認軟件做了你所期望做的事情（，另一方面是確認軟件以正確的方式來做了這個事情。第二是提供信息，比如提供給開發人員或程序經理的回饋信息，為風險評估所準備的信息。第三軟件測試不僅是在測試軟件軟件產品本身，而且還包括軟件開發的過程。如果一個軟件產品開發完成之后發現了很多問題，這說明此軟件開發過程很可能是有缺陷的。因此，軟件測試的第三個目的是保證整個軟件開發過程是高質量的。

愛國者導彈防御系統把“槍口”對準了自己人 美國迪斯尼公司的獅子王游戲軟件的兼容性問題 售票系統性能問題

2.論述軟件測試科學的發展歷程 1957年之前－調試為主 20世紀50年代，計算機剛誕生不久，只有科學家級別的人才會去編程，需求和程序本身也遠遠沒有現在這么復雜多變，相當于開發人員一人承擔需求分析，設計，開發，測試等所有工作，當然也不會有人去區分調試和測試。

1957–1978－證明為主 當時計算機應用的數量，成本和復雜性都大幅度提升，隨之而來的經濟風險也大大增加，測試就顯得很有必要了，這個時期測試的主要目就是確認軟件是滿足需求的，也就是我們常說的“做了該做的事情”。

1979–1982－破壞為主 我們不僅要證明軟件做了該做的事情，也要保證它沒做不該做的事情，這會使測試更加全面，更容易發現問題。

1983–1987－評估為主 人們提出了在軟件生命周期中使用分析，評審，測試來評估產品的理論。軟件測試工程在這個時期得到了快速的發展.1988–至今－預防為主 預防為主是當下軟件測試的主流思想之一。測試不是在編碼完成后才開始介入，而是貫穿于整個軟件生命周期。3.論述軟件缺陷的由來

軟件缺陷的產生主要是由軟件產品的特點和開發過程決定的。

軟件本身：①需求不清晰，導致設計目標偏離客戶的需求，從而引起功能或產品特征上的缺陷。②系統結構非常復雜，而又無法設計成一個很好的層次結構或組件結構，結果導致意想不到的問題或系統維護、擴充上的困難；即使設計成良好的面向對象的系統，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數傳遞、方法調用、對象狀態變化等方面問題。③對程序邏輯路徑或數據范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。④對一些實時應用，要進行精心設計和技術處理，保證精確的時間同步，否則容易引起時間上不協調，不一致性帶來的問題。⑤沒有考慮系統崩潰后的自我恢復或數據的異地備份、災難性恢復等問題，從而存在系統安全性、可靠性的隱患。⑥系統運行環境的復雜，不僅用戶使用的計算機環境千變萬化，包括用戶的各種操作方式或各種不同的輸入數據，容易引起一些特定用戶環境下的問題；在系統實際應用中，數據量很大。從而會引起強度或負載問題。⑦由于通信端口多、存取和加密手段的矛盾性等，會造成系統的安全性或適用性等問題。⑧新技術的采用，可能涉及技術或系統兼容的問題，事先沒有考慮到。

團隊工作：系統需求分析時對客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。不同階段的開發人員相互理解不一致。對于設計或編程上的一些假定或依賴性，相關人員沒有充分溝通。項目組成員技術水平參差不齊技術問題。算法錯誤：在給定條件下沒能給出正確或準確的結果。語法錯誤：對于編譯性語言程序，編譯器可以發現這類問題；但對于解釋性語言程序，只能在測試運行時發現。計算和精度問題：計算的結果沒有滿足所需要的精度。系統結構不合理、算法選擇不科學，造成系統性能低下。接口參數傳遞不匹配，導致模塊集成出現問題。

項目管理的問題：缺乏質量文化，不重視質量計劃，對質量、資源、任務、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。系統分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。開發周期短，需求分析、設計、編程、測試等各項工作不能完全按照定義好的流程來進行，工作不夠充分，結果也就不完整、不準確，錯誤較多；周期短，還給各類開發人員造成太大的壓力，引起一些人為的錯誤。開發流程不夠完善，存在太多的隨機性和缺乏嚴謹的內審或評審機制，容易產生問題。文檔不完善，風險估計不足等。4.軟件測試V模型

①繪制示意圖

②闡述每個步驟是做什么 需求分析

即首先要明確客戶需要的是什么，需要軟件作成什么樣子，需要有那幾項功能

概要設計

主要是架構的實現，指搭建架構、表述各模塊功能、模塊接口連接和數據傳遞的實現等項事務。詳細設計

對概要設計中表述的各模塊進行深入分析，對各模塊組合進行分析等。軟件編碼

按照詳細設計好的模塊功能表，編程人員編寫出實際的代碼。單元測試

按照設定好的最小測試單元進行按單元測試，主要是測試程序代碼，為的是確保各單元模塊被正確的編譯，單元的具體劃分按不同的單位與不同的軟件有不同。集成測試

經過了單元測試后，將各單元組合成完整的體系，主要測試各模塊間組合后的功能實現情況，以及模塊接口連接的成功與否，數據傳遞的正確性等，其主要目的是檢查軟件單位之間的接口是否正確。根據集成測試計劃，一邊將模塊或其他軟件單位組合成系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。系統測試

經過了單元測試和集成測試以后，我們要把軟件系統搭建起來，按照軟件規格說明書中所要求，測試軟件其性能功能等是否和用戶需求相符合，在系統中運行是否存在漏洞，等。驗收測試

主要就是用戶在拿到軟件的時候，在使用現場，會根據前邊所提到的需求，以及規格說明書來做相應測試，以確定軟件達到符合效果的。

第五篇：西南科技大學軟件測試實訓總結報告

實訓總結報告 學 院 名 稱：專 業 班 級：學 號：學 生 姓 名：實 訓 地 點：實 訓 日 期：

信息工程學院 通信工程 20124410 唐曼玲 新區圖書館

2015.1.5--1.16

一、實訓目的：

1.了解軟件測試概念，軟件測試主要內容，手動測試自動測試，初步掌握軟件測試并且能夠進行簡單運用。

2.了解軟件測試在當前計算機行業的地位和前景。3.了解為了成為軟件測試工程師所需要掌握的技能。

二、實訓內容：

1.移動警務通項目環境搭建 2.軟件測試的基本概念

3.軟件研發流程及系統測試過程 4.需求評審流程和評審要點 5.測試計劃和方案寫作要點 6.測試用例寫作要點和設計方法 7.軟件缺陷的概念和找軟件缺陷 8.TDD測試和開發設計文檔 9.溫度轉換器測試及開發設計 10.項目實戰總結

三、實訓總結(不低于2500字)

這次大三寒假實訓的主題是“軟件測試”，和同學們在圖書館機房一起學習。在軟件開放越來激烈的當今，追求軟件質量也是一個重要內容。軟件測試，即在軟件設計完成后要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題并加以糾正。整個測試過程分單元測試、組裝測試以以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試，以減少測試的隨意性。這次的實訓大致分為兩個階段。第一階段主要是文字處理工夫多一點，考驗了我們對找病句修改病句的能力；第二階段主要涉及了利用JAVA來編輯測試代碼，主要考察了我們細心程度，還有鞏固了我們編程能力。

第一階段我們主要學習了移動警務通項目環境搭建，軟件測試的基本概念，軟件研發流程及系統測試過程，需求評審流程和評審要點這四大點。具體細節包括了：需求評審、軟件測試方法與工具、用例設計、用例設計評審、測試評估報告、缺陷報告記錄、缺陷管理與統計以及測試評估報告。在學習氛圍濃重的機房內，我們認真看著大幕上的課件和老師演示的內容，并且都用手機或者筆記本記下了重要內容和步驟，當修改測試用例遇到不懂的問題時，我們組的隊員都會及時詢問老師尋求解答，保證我們小組學習的質量和速度。

在移動警務通項目中，老師要求我們修改需求報告，填寫需求評審。移動警務通客戶端設備，它包括了信息收集，信息查詢查詢，定位等功能，我在小組主要負責的是信息查詢這個工作。信息查詢需求報告的修改涉及到很多內容：需求填寫不完整，有歧義，用例填寫錯誤等。需求語句中有“或”，“和”字眼出現的句子我們都格外小心，因為這是病句可能出現的信號。我和小組成員們認真聽取了卿老師的課堂講解，并且認真記錄課堂筆記。我們還學會了利用虛擬手機平臺，模擬安卓手機，在手機上面進行測試和使用，這個讓我大開眼界。在老師講完之后我們小組立馬投入到需求評審等練習，組長給我們每個人都合理分配了適宜的任務，每個人都認真工作著，通過借鑒和及時詢問其他小組同學和老師，我們小組每次都很快地很好地完成了課堂練習任務。移動警務通這個項目讓我學到了看任何東西都要認真細心，特別是找病句的過程中是收貨很多的。

這一階段主要涉及了“需求分析”。通過老師的講解，我了解到，在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟件開發項目的成功打下良好的基礎。“唯一不變的是變化本身”，同樣需求也是在整個軟件開發過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。

第一階段中老師教我們使用了JUnit。它是一個開源的java測試框架，它是Xuint測試體系架構的一種實現。在JUnit單元測試框架的設計時，設定了三個總體目標，第一個是簡化測試的編寫，這種簡化包括測試框架的學習和實際測試單元的編寫；第二個是使測試單元保持持久性；第三個則是可以利用既有的測試來編寫相關的測試。JUnit可以把測試組織成測試系列；這個測試系列可以包含其它的測試或測試系列。JUnit測試的合成行為允許你組合多個測試并自動的回歸從頭到尾測試整個測試系列。你也可以執行測試系列層級架構中任何一層的測試。使用Junit測試框架，你可以很便宜的撰寫測試并享受由測試框架所提供的信心。撰寫一個測試就像寫一個方法一樣簡單；測試是檢驗要測試的程序代碼并定義期望的結果。這個測試框架提供自動執行測試的背景；這個背景并成為其它測試集合的一部份。

利用這個，我們就可以在電腦上實現安卓手機的模擬，在電腦上面就可以對安卓手機上的應用進行測試和使用。我們就是用這個實現了移動警務通的的第二階段任務測試代碼的編寫和測試的。

在實訓的第二周，第二階段主要是溫度轉換器測試代碼的編寫和學習，在安卓手機模擬平臺下訓練了我們JAVA編程能力。通過在Eclipse上編寫JAVA語言用于移動警務通的Android平臺，我第一次體會到了編寫安卓應用的樂趣。老師首先給我們普及了一下JAVA語言的一般用法和注意事項，然后開始編寫溫度轉換應用程序。在老師的耐心講解下，我們開始自己操作。可能剛開始有點不適應不習慣，但是到了后來，就慢慢熟練起來。中途遇到問題及時向老師提問，老師親自過來幫我檢查錯誤并且教我改正錯誤，這其中的方法和體會我覺得是很寶貴的經驗財富。由于老師講的內容我們都不是很熟悉，為了能夠更好地跟上上課節奏，我們就拿出手機，拍下老師每一次的內容，在老師講完過后就看照片復習和操作，這樣的效果很好。

這次需求評審中最大的感悟就是要學好語文，尤其是查找病句的能力。因為需求里面可能有很多的病句，這些病句有二義性或者錯誤，我們就應該立馬找出來及時修正，并且寫上批注，寫得很詳細很具體。最初找病句的時候由于沒有經驗，找的地方都不是很正確而且修改也沒修改好。接著聽了老師對每一個例子的詳細講解和經驗總結，我們小組成員都找到了修改的方法和途徑，大大增加了需求評審的效率。后來找老師來幫我們看看這些批注，老師都說我們寫的具體，寫地很好，這讓我們大受鼓舞。

本次實訓另一個體會就是對軟件測試這個工作很感興趣。因為考慮到自己作為一個女生對開發應用程序編寫不是很在行，如果能有基礎的情況下從事軟件測試這份工作想必是很好的。我從網上了解了一下軟件測試的行業現狀，如今軟件開發過程中出現錯誤或者缺陷的幾率越來越來多，市場對軟件的質量越來越重視，所以軟件測試在軟件項目中顯得尤為重要。專業優勢就業競爭小，人才供不應求讓軟件測試人員的就業競爭壓力明顯小于同類其它職業，有利于從業者的身心健康。另外，由于軟件測試在我國起步較晚，獨立設置測試部門、對測試人員有強烈需求的多為獨具慧眼的大中型IT企業。軟件測試人才不需要在小企業積累經驗就能獲得知名企業的入門通行證，工作起點高于同類其它職業。高薪，剛入行的軟件測試人員，起步的月薪就在3000-5000元左右，遠高于同齡人2000元的薪資水平，隨著工作經驗的豐富以及能力的提升，這份薪水將一路看漲。就業質量高，與其他IT職位相比，軟件測試人員最大的優勢就是發展方向太多了。由于工作的特殊性，測試人員不但需要對軟件的質量進行檢測，而且對于軟件項目的立項、管理、售前、售后等領域都要涉及。在此過程中，測試人員不僅提升了專業的軟件測試技能，還能接觸到各行各業，從而為自己的多元化發展奠定了基礎。而且從專業性質分析，軟件測試人員更要具有認真、耐心、細致、敏感等個性元素，我覺得而這在一定程度上與女性的個性氣質相吻合。所以我覺得我對軟件測試這種工作很感興趣。

通過老師的講解和課后詢問，我知道了如果要想成為好的測試人員，首先得了解自己要測試的軟件的相關知識。要了解軟件產品的架構是什么樣的。要了解軟件的市場需求，在接觸軟件之初要可以多看看用戶的反饋信息，這些才是用戶最關心的，也是在測試中需要注意的問題，滿足客戶是最大的需要。我們更應該學習的是，了解軟件需求之后要學會要多讀些軟件系統的技術文檔，軟件設計文檔，這些文檔可以幫助了解產品如何工作。還有多看看公司 Bug 庫中的問題，這些存在的問題可以幫助自己了解軟件產品哪些地方存在缺陷，軟件系統哪些地方會出現錯誤。軟件是運行在一個大環境中，如果對系統不熟悉，那么有些問題你不能從一個更廣闊的層面考慮，學習操作系統的知識，有助于你發現缺陷，定位問題更加準確。比如軟件運行在 Windows 或者 Linux，如果不懂操作系統，你就無法建立測試環境，有些時候時候軟件的組件發生問題，就是自己系統配置造成的，對系統不熟悉，會把外在原因歸結為軟件本身。所以要學習關于和軟件系統相關的知識，比如編程，網絡，數據庫等。

其實，我覺得不一定要學習到多好的程度，只是通過這些擴展的知識面，可以在發現問題，解決問題上不會局限在狹小的圈子里。并且，和一切相關的人員交流，不同的交流渠道，獲取消息是不同的，角度也不同。和客戶交流，會在測試中從客戶的角度發現問題；和開發人員交流，會了解開發人員怎么實現軟件功能的；和項目管理人員交流，會知道開發進度以及遇到的困難。這些是從這次實訓中獲得的寶貴收獲。

在培訓的最后老師給我們講了計算機行業的就業工種和對應的薪水情況、軟件測試行業分布、任職要求、必備技能、面試常用問題等。我受到的觸動很大，我們現在學到的東西遠遠沒有達到就業的水平和能力，每天就學習書本上的知識和實驗室的項目，感覺自己的能力遠遠不行，感覺很大的壓力。

實習這段期間，自己的收獲是豐碩的：最起碼從意識上，發現自己的不足，并尋求到合適的解決途徑。非常感謝對我幫助的同學和老師，我堅信：在你們的幫助下，我會持續努力，不斷反省，總結提高！我今年的計劃是考川大電子信息類的研究生，我希望在接下來的一年半可以充充實實，每天都過得有意義，為了變成一個優秀的自己而努力。2015，加油！