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