軟件系統測試工作總結

時間：2022-12-01 15:35:12 總結我要投稿

相關推薦

軟件系統測試工作總結

　　總結就是對一個時期的學習、工作或其完成情況進行一次全面系統的回顧和分析的書面材料，它可以促使我們思考，讓我們抽出時間寫寫總結吧。那么你知道總結如何寫嗎？以下是小編精心整理的軟件系統測試工作總結，歡迎大家借鑒與參考，希望對大家有所幫助。

軟件系統測試工作總結

軟件系統測試工作總結1

　　隨著科技的進步，手機款型可謂日新月異，功能也越來越豐富。相應的，越來越多的手機應用軟件也伴隨著手機功能的多樣化應運而生。面對種類眾多的手機應用軟件，該如何進行測試，測試時又需要重點關注什么呢？本文檔結合本人在產品手機項目測試過程中的經驗，淺談下手機應用軟件測試相關知識。

　　對于產品的手機項目（應用軟件），主要是進行系統測試。而針對手機應用軟件的系統測試，我們通常從如下幾個角度開展：功能模塊測試，交叉事件測試，壓力測試，容量測試，兼容性測試，易用性/用戶體驗測試等。

　　1、功能模塊測試：首先應分析功能模塊的功能項，測試每個功能項是否能夠實現對應的功能。一般根據測試用例（Test Case）或軟件本身的流程就可以完成基本功能測試（相對簡單，故障也較容易發現、解決）。

　　2、交叉事件測試：又叫事件或沖突測試，是指一個功能正在執行過程中，同時另外一個事件或操作對該過程進行干擾的測試。例如通話過程中接收到短信或鬧鈴觸發，應用軟件運行過程中插拔充電器等。執行干擾的沖突事件不能導致應用軟件異常、手機死機或花屏等嚴重問題。另外，還需要注意各交叉事件的優先級別，檢驗系統是否能依據各事件的優先級別依次進行處理。不能因執行優先級別高的事件而導致優先級較低的事件吊死。

　　交叉事件測試非常重要，一般能發現應用軟件中一些潛在的問題。另外有中英文模式切換的手機要注意中英文模式切換后的功能實現存在的問題（這個主要針對手機應用軟件支持語言自適應功能），這一點通常會被測試人員忽略。

　　3、壓力測試：又叫邊界值容錯測試或極限負載測試。即測試過程中，已經達到某一軟件功能的最大容量、邊界值或最大的承載極限，仍然對其進行相關操作。例如連續進行短信的接收和發送，超過收件箱和SIM卡所能存儲的最大條數，仍然進行短消息的接收或發送，以此來檢測軟件在超常態條件下的表現，進而評估用戶能否接受。

　　對手機可以施加的壓力測試類型主要有：

　　●存儲壓力：由于手機采用的是棧式存儲，所以當一個存儲塊滿了之后，如果程序員不做相應處理或者處理不好的話，很容易造成其他存儲區被擦除，從而在UI上出現問題（比如其他功能無法正常使用，出現異常）。

　　●邊界壓力：邊界處理一直是程序員最容易忽略的地方。

　　●響應能力壓力：有時候某個操作可能處理的時間很長，在處理期間如果測試者再不斷地進行其他操作的話，很容易出現問題。

　　● 網絡流量壓力：執行較大數據流量的功能的同時，再進行其他功能操作，使得網絡流量始終處于很高的狀態（如視頻通話時再進行短信等其他功能操作），驗證各功能是否依然能正常工作，是否存在因網絡流量瓶頸而引起某功能異常。

　　壓力測試用手工測試可能很繁鎖，可以考慮自動化測試。遺憾的是，目前還沒有較為大量使用的工具，一般都是由開發人員配合開發出的工具，或者高級的測試人員編寫出的腳本。

　　4、容量測試：即存儲空間已滿時的測試，包括手機用戶可用內存和SIM卡的'所有空間被完全使用的測試。此時再對可編輯的模塊進行和存儲空間有關的任何操作測試，如果軟件在極限容量狀態下處理不好，有可能導致死機或嚴重的花屏等問題的出現。

　　5、兼容性測試：也就是不同品牌、款型的手機（針對目前我們產品來說，主要是針對不同品牌、款型的手機上的測試），不同網絡，不同品牌和不同容量大小的SIM卡之間的互相兼容的測試。以短消息為例：中國電信的小靈通接收到從中國移動或中國聯通GSM發來的短消息，需要驗證顯示和回復功能是否正常等。再比如，應用軟件分別在Nokia N80、N93手機上運行，各功能是否均能正常使用，界面是否均顯示正常等。

　　6、易用性/用戶體驗測試：易用性（Useability）/用戶體驗是指在指定條件下使用時，軟件產品被理解、學習、使用和吸引用戶的能力，是交互的適應性、功能性和有效性的集中體現。

　　易用是對終端軟件（推而廣之是交互類軟件）最基本、最重要的要求。不好用的軟件很難吸引用戶，更別提提升用戶對軟件的忠誠度了。易用性體現在：所見即所得、一用便知、一學就會，方便快捷的完成預期功能。易用的軟件能讓一個新用戶快速學習、使用我們的軟件，并在使用軟件過程中體現我們的貼心服務，超出用戶預期的體現是我們追求的目標。

軟件系統測試工作總結2

　　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)如果不是錯誤則應該主動承認不是缺陷。