軟件測試答辯項目總結

軟件測試答辯項目總結該如何擬寫呢？今天我們就一起來了解一下吧！

　　軟件測試答辯項目總結【1】

這學期的期末大作業是對ELearning Java Web應用系統進行測試，通過這次系統測試，我學到了很多知識，軟件測試個人總結。對於具體的測試部分，我主要做的是單元測試和性能測試，其中單元測試使用的是Junit工具，性能測試使用的是JMeter。就這次大作業而言，我認為它與我們平時做的實驗很不相同，我們平時的實驗只是涉及到測試的某個小部分，而這次測試卻是對一個相對完整的項目按照規範的標準進行測試。

對於好的測試來説，應該注意一下幾點：

1.測試的獨立性：一次只測試一個對象，方便定位出錯的位置。這有2層意思：一個TestCase，只測試一個對象；一個TestMethod，只測試這個對象中的一個方法。

2.給測試方法一個合適的名字。

3.在assert函數中給出失敗的原因，如：assertTrue("…should be true",…)，方便查錯。在這個例子中，如果無法通過assertTrue，那麼給出的消息將被顯示。在junit中每個assert函數都有第一個參數是出錯時顯示消息的函數原型。

4.測試所有可能引起失敗的地方，如：一個類中頻繁改動的函數。對於那些僅僅只含有getter/setter的類，如果是由IDE(如Eclipse)產生的，則可不測；如果是人工寫，那麼最好測試一下。

5.在setUp和tearDown中的代碼不應該是與測試方法相關的，而應該是全局相關的。如針對與測試方法A和B，在setUp和tearDown中的代碼應該是A和B都需要的代碼。

6.測試代碼的組織：相同的包，不同的目錄。這樣，測試代碼可以訪問被測試類的protected變量/方法，方便測試代碼的編寫。放在不同的目錄，則方便了測試代碼的管理以及代碼的打包和發佈。

對於測試用例的命名，我們最好要使其與測試類的名稱相一致，比如説，類的名稱為Testing，此類的測試用例的名稱為TestingTest。當我們把測試代碼和被測的代碼放在同一目錄下時，我們就可以在編譯被測代碼的同時編譯測試代碼，從而確保兩者是同步更新的，工作總結《軟件測試個人總結》。事實上當前的普遍做法，就是把單元測試視為build的一個環節。保持測試之間的獨立性是一個很好的習慣，使得它們在任何次序下執行的結果都是相同的。如果真得需要某些測試按照特定的次序執行，我們可以藉助addtest來實現。當我們需要增加一個測試時，我們要書寫一個自己的測試用例，但是如果喜歡在測試用例的構造函數中做有關的初始化工作，這就不是個好習慣。數據文件應該儘可能和源代碼一起都放在配置管理系統上，但這樣一來如果我們採用上面的resource機制，我們就需要做一件工作，就是把數據文件從原來的位置-就是源代碼的某個相對路徑，拷貝到編譯後的位置，也就是class文件的相應的相對路徑。

通過這次軟件測試的系統測試，我對軟件測試有了更加深刻的認識，其實軟件測試並不像想象的那麼簡單，它需要測試人員具備多方面的能力和素質。軟件測試人員應該擁有廣闊的視野、一定的編程能力、細心和耐心等等。這些對於能否測出優秀的系統來説都是必不可少的。

經過這次對java Web應用系統的測試，我的測試能力得到了鍛鍊，對軟件測試有了比較全面的認識，收穫了很多珍貴的東西，而且我也從軟件測試的角度，對編寫健壯的程序也有了新的認識。

記錄激動時刻，贏取超級大獎！點擊鏈接，和我一起參加"2010：我的世界盃Blog日誌"活動！

　　軟件測試答辯項目總結【2】

我在幾個月的軟甲測試課程中深刻體會到軟件測試的重要性和趣味性。這門課教會我們以軟件系統工程的更大視角審視軟件測試這項工作。

在做作業的過程中我感覺我做的測試項目越多，閲讀的測試書籍越多，我越感到我對軟件測試理解的越膚淺。因為我越來越感受到軟件測試的廣度和深度的無限性，它像大海寬廣，像宇宙那樣深邃。

為什麼要進行軟件測試軟件測試的前途如何軟件測試的工具和思想誰更重要軟件測試的最高境界是什麼

軟件測試是保證軟件質量的重要活動，是軟件項目實施的不可缺少的環節。軟件測試的直接目的是發現軟件中存在的缺陷。此為測試的有效性。

在軟件項目沒有結束之前的'全部軟件缺陷主要由軟件開發人員負責，因為軟件缺陷來自程序員的編程。軟件項目結束後的軟件缺陷主要由軟件測試人員負責，因為軟件測試人員沒有在軟件發佈之前的測試中沒有發現隱藏的錯誤。

軟件測試不是萬能的，因為不可能發現全部的軟件缺陷，而且軟件的功能和性能不是由測試決定的。此為測試的有限性。

軟件測試目前主要以手工測試為主，自動測試工具雖然很多，但實際應用的廣度和深度還有很大潛力，自動將有很大的發展空間!。軟件測試的缺陷管理流程非常重要，報告的軟件缺陷的質量，應該由他人驗證，做到責任明確，方法簡便可行。

軟件測試技術不斷進步，但總體來看，國內的測試重視程度還不夠，但已經發展很快。差不多兩年之前，國內計算機書店中關於軟件測試的書籍非常稀少，如今卻琳琅滿目，異彩紛呈。

軟件測試是個可以很快入門的職業，門檻不高，但是，不要認為什麼人都可以做好軟件測試。因為會做和做好是兩個概念。軟件測試人員最好具有軟件開發經驗，理解軟件工程的知識。這是提高軟件測試能力的基礎。對於剛剛畢業的學生，如果希望今後從事軟件開發，那麼，先從事一段時間的測試可能更有利於今後的編程。而對於具有多年編程經驗的程序員，如果改行做測試，更容易提高技術。

軟件測試不是孤立的活動或過程，需要開發和市場人員的參與和交流，需要軟件質量保證人員SQA的積極配合和溝通。

軟件測試的技術不斷進步，與具體測試技術相比，掌握測試的核心思想比具體技術更重要!測試的最高境界在於運用最簡單有效的測試技術，最大限度的發現軟件缺陷!

　　軟件測試答辯項目總結【3】

這個學期我學習了軟件測試這門專業課程，在學期即將結束的時候，我也對這門課程建立基本的瞭解和理解。軟件測試這門課程作為軟件工程專業中一門很重要的課程，已經在軟件領域佔據了不可替代的角色，當一個軟件從雛形到真正的在一台計算機上運行的時候，誰也不能保證計算機軟件能一步到位的滿足人們的需求。所以就有了軟件測試，其目的是：第一是確認軟件的質量，其一方面是確認軟件做了你所期望的事情，另一方面是確認軟件以正確的方式來做了這個事件。下面我簡單的寫一下這個學期對課程的總結和收穫。

我認為，在整個龐大的軟件工程中，不管是需求分析、架構設計甚至是最後的debug，都會產生引入不管的機會，這就要求作為一個軟件測試師要掌握豐富的軟件工程原理和知識。測試的工作將會存在於整個項目週期，即在項目開始時需要各種分析調研時就開始了。尤其是在形成需求規格説明書時就有對文檔的測試需求，甚至主導整個項目的走向。

軟件測試對邏輯思維、學習能力、反應要求很高，是否有嚴密的思維和逆向思維也非常重要。做測試還要考慮到所有出錯的可能性，有時候還要用一些非常規的的測試方法。軟件測試還很注重軟件性能問題，也就是要保證軟件運行得很好；不同的使用環境下，考慮軟件

的兼容性同樣重要。對於測試員來講，會比開發人員更加重視軟件產品的質量問題。在測試過程中，測試者可能會為客户的需求角度考慮到更多，由此我們可以認為測試人員有權利決定產品是否可以發佈。然而，通過一個學期的學期，我們又不得不懂得，軟件測試人員不是萬能的，測試人員在面對一個設計爛編碼爛的軟件時，也是無法不低頭的，再怎麼測試它也變不成優秀的軟件。

通過課上的理論因為課下的實踐和後半學期又因為身體力行於QQ羣論壇裏使我對測試方法和設計分析有了大致的接觸和深入瞭解。收印象深刻的有一下幾點。

1、最基本的測試的分類：從是否需要執行被測軟件的角度，可分為靜態測試和動態測試；從測試是否針對系統的內部結構和具體實現算法的角度來看，可分為白盒測試和黑盒測試。

2、然後就是，白盒測試中的邏輯驅動測試的覆蓋率測試。

3、還有就是對於劃分等價類和邊界值法這一塊，讓我從模糊到明朗。

4、在初次寫測試用例的時候，感覺真是糾結，用例寫的很死板，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且還很慢。在後來負責了對論壇新鮮事版塊的測試之後，明白了測試用例其實就是指導怎麼去執行測試，而且書寫設計測試用例也要以熟悉軟件的業務為前提，才能更好的去測試。

另外就是一個學期的學習讓我糾正了幾點誤區：

1. 有位大師曾説過：“軟件測試的目的在於發現錯誤，一個好的測試用例在於發現從來未發現的錯誤，一個成功的測試是發現了從未發現的錯誤的測試。” 由此我自認為測試就是為了找到bug，然而一個學期的測試學習經驗告訴我這是錯誤的，如果只是為了找到BUG，那麼BUG會成天纏着你。

2.在大家協力測試論壇的時期內，我曾認為這種大量的重複性的工作真的很乏味，可是在這乏味中真心發生挺多有意思的bug，意想不到的bug，所以我認為只要掌握了方法，在重複中尋到到創新的小驚喜，任何東西都有它的特點。

作為測試新手，通過一學期的學習，我認為能獨立寫測試計劃，設計測試用例，精通一種測試工具，理解一種bug管理軟件是新手晉級老手的必備素質。任重而道遠？！

在最後，我不得不提的就是細心和耐心了。這是我認為這個學期測試課上收穫最大的了，課程要求測試時必須細心和耐心，我在想，如果以後真的工作在測試一系列的崗位上，要學會坐得住，用大量的時間和精力和bug鬥爭，分離、識別還有歸類bug，是不是也能真的改變我粗心大意和三分鐘熱度的毛病。

最後感謝劉老師這學期的課程講授，和實踐中的指導和幫助。測試路程，路漫漫其修遠兮，吾將上下而求索。