軟體系統測試工作總結 篇1
1、為什麼要在一個團隊中開展軟體測試工作？
因為沒有經過測試的軟體很難在發布之前知道該軟體的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟體測試的工作。在測試的過程發現軟體中存在的問題，及時讓開發人員得知並修改問題，在即將發布時，從測試報告中得出軟體的質量情況。
2、測試能給你帶來什麼樣的快樂？
測試可以給我帶來很多快樂，如果測試出一個項目缺少東西，我會很高興，因為我對自己的工作有了新的認識，也為公司做了效益;如果測試出一個項目沒有問題，我也很高興，因為同事們都在努力，大家都希望為公司做貢獻，這就是一個很強大的團隊，這是一件多么另人振奮的事情啊!
3、軟體測試的目的？
測試的目的是以最少人力、物力和時間找出軟體中潛在各種錯誤和缺陷，通過修正種錯誤和缺陷提高軟體質量，迴避軟體發布後由於潛在的軟體缺陷和錯誤造成的隱患帶來的商業風險。
4、Alpha測試與beta測試的區別
Alpha測試在系統開發接近完成時對套用系統的測試；測試後仍然會有少量的設計變更。這種測試一般由程式或測試員完成，不能由最終用戶或其它人員完成。
Beta測試當開發和測試根本完成時所做的測試，最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其它人員完成，不能由程式設計師或測試員完成。
5、簡述集成測試的過程
(1)構建的確認過程。
(2)補丁的確認過程。
(3) Z34 。
(4)測試用例設計過程。
(5)測試代碼編寫過程。
(6) Bug的報告過程。
(7)每周/每兩周的構建過程。
(8)點對點的測試過程。
(9)組內培訓過程。
集成測試過程:集成測試計畫->集成測試設計->集成測試實現->集成測試執行。
6、質量的八大特性是什麼？各種特性的定義？
(1）功能性：軟體所實現的'功能達到它的設計規範和滿足用戶需求的程度
(2）性能：在規定條件下，實現軟體功能所需的回響時間和計算機資源(CPU、記憶體、磁碟空間和數據吞吐量)的使用程度
(3）可靠性：在滿足一定條件的套用環境中，軟體能夠正常維持其工作的能力，在出現一些錯誤操作時，軟體可以具有容錯性，如果軟體意外退出，重新啟動後可以恢復最近的軟體數據
(4）安全性：為了防止意外或人為的破壞，軟體應具備的自身保護能力
(5）使用性：用戶在理解、學習和操作軟體的過程中的付出的努力的難易程度
(6）維護性：軟體在運行維護過程中，如果出現了運行故障或者擴展新功能和性能，軟體系統是否具有可分析性和良好的擴展性，重新設計後的軟體的穩定性和可測試性
(7）移植性：軟體從現有運行平台向另一個運行平台過度的適應程度和平台可替換性
(8）重用性：整個軟體或其中一部分能作為軟體包而被再利用的程度
7、系統測試計畫是否需要同行審批，為什麼
需要，系統測試計畫屬於項目階段性關鍵文檔，因此需要評審。
8、軟體質量應該從哪些方面來評價？
可靠性、安全性、性能、易用性、外觀、穩定性
9、系統測試包含哪些方面？
1.恢複測試、2.安全測試、3.強度測試、4.性能測試
10、區別階段評審的與同行評審
同行評審目的:發現小規模工作產品的錯誤，只要是找錯誤;
階段評審目的:評審模組階段作品的正確性可行性及完整性
同行評審人數:3-7人人員必須經過同行評審會議的培訓，由SQA指導
階段評審人數:5人左右評審人必須是專家具有系統評審資格
同行評審內容:內容小一般文檔< 40頁，代碼< 500行
階段評審內容:內容多，主要看重點
同行評審時間:一小部分工作產品完成
階段評審時間:通常是設定在關鍵路徑的時間點上!
11、測試結束的標準是什麼？
1.用例全部執行。2.覆蓋率達到標準。3.缺陷率達到標準。4.其他指標達到質量標準
12、制定測試計畫之前需要了解什麼問題？
(1)軟體測試計畫的目的是什麼？是否所有人都知道？他們同意這個測試計畫過程嗎？
(2)測試的是什麼產品？是新程式還是維護升級的？是獨立程式還是由多個小程式組成的？
(3)產品的質量目標是什麼？產品的功能需求和性能指標必須得到所有人的一致認可。
13、請詳述設計測試用例的方法？（只是列出一個測試用例思考的方向，具體設計靠經驗）
①黑盒測試用例根據業務需求說明書來設計，分為：
等價劃分法邊界值分析法錯誤推測法因果圖法邏輯覆蓋法
②白盒測試用例通過研究代碼與程式結構可以分為以下兩種方式：
靜態測試：通過靜態的檢查程式代碼、界面、文檔中可能存在的錯誤的過程。
|-測試代碼編寫的規範性|-測試界面|-測試相關需求說明和用戶手冊是否符合實際要求
動態測試：通過路徑和分支測試。測試用例主要根據以下六種覆蓋測試方法設計
|-語句覆蓋|-判定覆蓋|-條件覆蓋|-判定/條件覆蓋|-組合覆蓋|-路徑覆蓋
14、比較負載測試，壓力測試，容量測試和強度測試的區別
負載測試：在一定的工作負荷下，系統的負荷及回響時間。通過逐步增加系統負載，最終確定在滿足性能指標的情況下，系統能承受的最大負載量的測試。
強度測試：又稱疲勞強度測試，在系統穩定運行的情況下能夠支持的最大並發用戶數，持續執行一段時間業務，通過綜合分析，確定系統處理最大工作量強度性能的過程。一定負荷條件下，在較長時間跨度內的系統連續運行給系統性能所造成的影響。
容量測試：容量測試目的是通過測試預先分析出反映軟體系統套用特徵的某項指標的極限值（如最大並發用戶數、資料庫記錄數等），系統在其極限值狀態下沒有出現任何軟體故障或還能保持主要功能正常運行。容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。容量測試的目的是使系統承受超額的數據容量來發現它是否能夠正確處理。容量測試是面向數據的，並且目的是顯示系統可以處理目標內確定的數據容量。
壓力測試：通過逐步增加系統負載，最終確定在什麼負載條件下系統性能將處於崩潰狀態，以此獲得系統能提供的最大服務級別的測試。
15、測試人員需要何時參加需求分析？
如果條件允許，原則上來說是越早介入需求分析越好。因為測試人員對需求理解越深刻，對測試工作的開展越有利，可以儘早的確定測試思路，減少與開發人員的互動，減少對需求理解上的偏差。
16、軟體的缺陷等級應如何劃分？
嚴重：1.由於程式所引起的當機，非法退出2.死循環3.資料庫發生死鎖4.因錯誤操作導致的程式中斷5.功能錯誤6.與資料庫連線錯誤7.數據通訊錯誤。
較嚴重：1.程式錯誤2.程式接口錯誤3.資料庫的表、業務規則、預設值未加完整性等約束條件。
一般性：1.操作界面錯誤（包括數據視窗內列名定義、含義是否一致）2.列印內容、格式錯誤3.簡單的輸入限制未放在前台進行控制4.刪除操作未給出提示5.資料庫表中有過多的空欄位。
建議：1.界面不規範2.輔助說明描述不清楚3.輸入輸出不規範4.長操作未給用戶提示5.提示視窗文字未採用行業術語6.可輸入區域和唯讀區域沒有明顯的區分標誌。
17、你自認為測試的優勢在哪裡？
優勢在於我對測試堅定不移的信心和熱情，雖然經驗還不夠，但測試需要的基本技能我有信心在工作中得以發揮。
18、你在測試中發現了一個bug，但是開發經理認為這不是一個bug，你應該怎樣解決。
(1)如果不是錯誤則應該主動承認不是缺陷。
(2)如果是需求不明確的則應和開發加強溝通補充需求。
(3)如果和開發爭論不休應該邀請上級判斷。
19、您認為做好測試計畫工作的關鍵是什麼？
(1)明確測試的目標，增強測試計畫的實用性
(2)堅持“5W”規則，明確內容與過程
(3)採用評審和更新機制，保證測試計畫滿足實際需求
(4)分別創建測試計畫與測試詳細規格、測試用例
20、風險和問題
◆市場的壓力
◆測試時間不夠
◆測試資源的及時到位
◆測試人員的技能需求
◆開發進度的變化，需求的變更
◆開發部門的版本控制
◆短時間上線。這個是已經定好的，沒有參考測試人員的意見。時間短往往不能得到充分的測試，測試策略必須根據可用的時間進行調整。儘快指出這樣的問題非常重要，只有這樣才能調整時間表，確定快速開發的風險並制定降低風險的策略。
◆新的設計過程。引入新的設計過程會增加風險，新的設計過程包括新的工具和設計技術。如果採用新的技術，能否像我們預期的那樣運轉，都存在很大的風險
◆複雜性。我們應該進行一些分析工作來確定哪個功能最複雜，哪個功能最容易出錯，錯誤會對系統的哪些地方造成重大的影響。
◆使用頻率。軟體最常用功能中隱藏的問題可能給用戶造成嚴重的損失。
◆不可測試的需求。不可測試的需求會對系統的成功造成巨大的威脅。如果測試組在需求階段就驗證了需求的可測試性，對需求進行了評審，那么此類問題會減少多。
軟體系統測試工作總結 篇2
隨著科技的進步，手機款型可謂日新月異，功能也越來越豐富。相應的，越來越多的手機套用軟體也伴隨著手機功能的多樣化應運而生。面對種類眾多的手機套用軟體，該如何進行測試，測試時又需要重點關注什麼呢？本文檔結合本人在產品手機項目測試過程中的經驗，淺談下手機套用軟體測試相關知識。
對於產品的手機項目（套用軟體），主要是進行系統測試。而針對手機套用軟體的系統測試，我們通常從如下幾個角度開展：功能模組測試，交叉事件測試，壓力測試，容量測試，兼容性測試，易用性/用戶體驗測試等。
1、功能模組測試：首先應分析功能模組的功能項，測試每個功能項是否能夠實現對應的功能。一般根據測試用例（Test Case）或軟體本身的流程就可以完成基本功能測試（相對簡單，故障也較容易發現、解決）。
2、交叉事件測試：又叫事件或衝突測試，是指一個功能正在執行過程中，同時另外一個事件或操作對該過程進行干擾的測試。例如通話過程中接收到簡訊或鬧鈴觸發，套用軟體運行過程中插拔充電器等。執行干擾的衝突事件不能導致套用軟體異常、手機當機或花屏等嚴重問題。另外，還需要注意各交叉事件的優先權別，檢驗系統是否能依據各事件的優先權別依次進行處理。不能因執行優先權別高的事件而導致優先權較低的事件吊死。
交叉事件測試非常重要，一般能發現套用軟體中一些潛在的問題。另外有中英文模式切換的手機要注意中英文模式切換後的功能實現存在的問題（這個主要針對手機套用軟體支持語言自適應功能），這一點通常會被測試人員忽略。
3、壓力測試：又叫邊界值容錯測試或極限負載測試。即測試過程中，已經達到某一軟體功能的最大容量、邊界值或最大的承載極限，仍然對其進行相關操作。例如連續進行簡訊的接收和傳送，超過收件箱和SIM卡所能存儲的最大條數，仍然進行短訊息的接收或傳送，以此來檢測軟體在超常態條件下的表現，進而評估用戶能否接受。
對手機可以施加的壓力測試類型主要有：
●存儲壓力：由於手機採用的是棧式存儲，所以當一個存儲塊滿了之後，如果程式設計師不做相應處理或者處理不好的話，很容易造成其他存儲區被擦除，從而在UI上出現問題（比如其他功能無法正常使用，出現異常）。
●邊界壓力：邊界處理一直是程式設計師最容易忽略的地方。
●回響能力壓力：有時候某個操作可能處理的時間很長，在處理期間如果測試者再不斷地進行其他操作的話，很容易出現問題。
● 網路流量壓力：執行較大數據流量的功能的同時，再進行其他功能操作，使得網路流量始終處於很高的狀態（如視頻通話時再進行簡訊等其他功能操作），驗證各功能是否依然能正常工作，是否存在因網路流量瓶頸而引起某功能異常。
壓力測試用手工測試可能很繁鎖，可以考慮自動化測試。遺憾的是，目前還沒有較為大量使用的工具，一般都是由開發人員配合開發出的工具，或者高級的測試人員編寫出的腳本。
4、容量測試：即存儲空間已滿時的測試，包括手機用戶可用記憶體和SIM卡的所有空間被完全使用的測試。此時再對可編輯的模組進行和存儲空間有關的任何操作測試，如果軟體在極限容量狀態下處理不好，有可能導致當機或嚴重的花屏等問題的出現。
5、兼容性測試：也就是不同品牌、款型的手機（針對目前我們產品來說，主要是針對不同品牌、款型的手機上的測試），不同網路，不同品牌和不同容量大小的SIM卡之間的互相兼容的測試。以短訊息為例：中國電信的小靈通接收到從中國移動或中國聯通GSM發來的短訊息，需要驗證顯示和回復功能是否正常等。再比如，套用軟體分別在Nokia N80、N93手機上運行，各功能是否均能正常使用，界面是否均顯示正常等。
6、易用性/用戶體驗測試：易用性（Useability）/用戶體驗是指在指定條件下使用時，軟體產品被理解、學習、使用和吸引用戶的能力，是互動的適應性、功能性和有效性的集中體現。
易用是對終端軟體（推而廣之是互動類軟體）最基本、最重要的要求。不好用的軟體很難吸引用戶，更別提提升用戶對軟體的忠誠度了。易用性體現在：所見即所得、一用便知、一學就會，方便快捷的完成預期功能。易用的軟體能讓一個新用戶快速學習、使用我們的軟體，並在使用軟體過程中體現我們的貼心服務，超出用戶預期的體現是我們追求的目標。
軟體系統測試工作總結 篇3
項目名稱開發工具全面測試次數測試時間測試人員測試過程簡述010203後勤管理系統後台登錄模組MyEclipse10.02次20xx年10月09日至20xx年10月19日陸全全龍玉蓮左登吳德武編號任務名稱任務描述開始時間結束時間制定測試計畫規劃開發和測試的具體步驟搭建測試環境編寫測試用例分析程式的具體功能模組，編寫每個功能模組的測試用例測試系統修改再測試按照測試用例測試系統修改bug，重新測試，直到達到測不出bug040506編寫測試報告總結測試過程，編寫測試報告功能缺發現2個；解決2個；陷缺陷設計缺發現0個；解決0個；統計陷模組缺發現0個；解決0個；陷測試用例覆蓋情況：測試用例涵蓋了所設計程式的一下功能（登錄模組）：
1、用戶名為空時的提示功能
2、密碼為空時的提示功能
3、用戶名和密碼錯誤時的提示功能
4、用戶明和密碼空時的提示功能
5、驗證碼為空或者錯誤時的提示功能……..遺留問題及解決方案：無測試結論：通過設定詳細的測試計畫，在開發過程中不斷的進行測試，編寫了詳細的功能模組的測試用例，找出bug後改進，再測試，先後進行了2次全面的測試，終於按照測試計畫比較完善的完成了測試工作。
個人總結：在軟體測試實踐的這段時間中，我領導我們的小組，在測試初期，通過全體組員之間的討論，做好各項測試工作的分析以及分工，為後期測試工作的順利進行做好了鋪墊，在本次測試任務中，主要分工如下：作為組長的'我，先做好軟體測試計畫說明文檔的編寫，為測試流程做好一個規範，並做好後期測試總結文檔的編寫；左登主要負責測試軟體的研究和使用以及軟體測試缺陷文檔的編寫；吳德武主要負責測試用例的編寫；龍玉蓮主要負責後期記錄測試日誌。雖然每個組員分工不同，但是大家在一起做好一個系統功能的測試，相互之間討論、協作，保證這個測試工作的順利進行完成。