軟件測試個人總結3篇

時間：2024-10-25 16:25:00 工作總結

　　下面是范文網小編整理的軟件測試個人總結3篇，供大家賞析。

軟件測試個人總結3篇

軟件測試個人總結1

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

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

　　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變量/方法，方便測試代碼的編寫。放在不同的目錄，則方便了測試代碼的管理以及代碼的打包和發(fā)布。

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

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

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

軟件測試個人總結2

　　軟件測試在整個軟件周期中的重要性，它存在于整個項目周期，在項目開始之初需求調研的時候就開始了，在形成需求規(guī)格說明書的時候就需要針對文檔進行測試。這個環(huán)節(jié)在后續(xù)整個項目中占了很大的比重，能主導整個項目的走向，成敗與否全在于開始階段的決策。

　　體會一：軟件測試的真正意義在于發(fā)現錯誤，而不在于驗證軟件是正確的。

　　再嚴密的測試也不能完全發(fā)現軟件當中所有的錯誤，但是測試還是能發(fā)現大部分的錯誤，能確保軟件基本是可用的，所以在后續(xù)使用的過程中還需要加強快速響應的環(huán)節(jié)。結合軟件測試的理論，故障暴露在最終客戶端之前及時主動的去發(fā)現并解決。這一點就需要加強研發(fā)隊伍的建設。

　　體會二：在系統(tǒng)性能測試方面需要重視。

　　經過這次培訓中多個案例的講解，讓我了解到系統(tǒng)在上線之后會有很多不能預知的性能問題，需要在上線之前實現進行模擬，以規(guī)避風險，包括大數據量訪問，高并發(fā)數等等。

　　當然也有很多應對手段，沒有哪種手段可稱為最完美，只有最合適的，需要靈活掌握，綜合運用以達到最優(yōu)程度，這是個很值得研究的領域。

　　下面是本人的幾點想法：

　　想法一：加強系統(tǒng)上線前的'性能測試。

　　目前我們在項目建設過程中對性能壓力測試的重視程度還不太高，廠家也很少有雇傭第三方的測試機構。而是在現網進行試用，遇到問題再解決，可能會產生滯后問題，影響客戶使用。希望以后能在性能測試方面提高重視程度，加大人力投入，以保證系統(tǒng)上線后能夠穩(wěn)定運行。

　　想法二：適當介入相關項目研發(fā)

　　對于快速響應這塊，我們不能一味依賴廠家，而希望自己就能快速響應，及時將問題解決。這也是一個比較長遠的問題，需要加強研發(fā)力量的投入。

　　我個人是做開發(fā)出身，有此類經驗，當時是在客戶現場，因為了解系統(tǒng)內部結構，能夠在第一時間排查解決客戶所反饋問題。

　　現在系統(tǒng)完全由廠家開發(fā)，很難了解內部結構，或許會造成后期維護困難。所以，是否應該針對某些項目介入廠家研發(fā)工作，比如請廠家提供源代碼等相關要素，以增進維護人員對系統(tǒng)的了解。

　　最后再次感謝公司提供的平臺，感謝領導的信任，讓我有機會得到更深層次的學習以及展示自己能力的機會，我也會盡我所能來完善工作的系統(tǒng)，提高整體工作效率，為南方電網的發(fā)展建設提供更堅實，優(yōu)秀的支撐服務平臺。