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