手機(jī)軟件測試培訓(xùn)

1、 測試部 方 明一、概述二、測試流程三、測試用例四、實(shí)例講解手機(jī)軟件測試 軟件測試就是在軟件投入運(yùn)行前，對軟件需求分析、設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程?；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)一批測試用例（即輸入數(shù)據(jù)及其預(yù)期的輸出結(jié)果），并利用這些測試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯誤的過程。 軟件測試定義軟件測試定義軟件測試目的軟件測試目的 1.所有的軟件測試都應(yīng)追溯到用戶需求。 2.盡早和不斷的進(jìn)行軟件測試。 3.避免測試自己的程序。 4.執(zhí)行測試計(jì)劃，排除隨意性。 5.增量測試，由小到大。（增量

2、測試：自頂向下和自底向上的開發(fā)或測試過程） 6.周密的測試用例(輸入條件(合理、不合理)、預(yù)期輸出結(jié)果)。 7.充分注意群集現(xiàn)象(指在測試中發(fā)現(xiàn)缺陷越多的地方，存在的未被發(fā)現(xiàn)的缺陷也就越多 )。 8.問題的相互確認(rèn)。 9.完全測試是不可能的，測試需要終止。 10.回歸測試。 11.妥善保存測試計(jì)劃，測試用例，出錯統(tǒng)計(jì)和最終分析報(bào)告，為維護(hù)提供方便。軟件測試原則軟件測試原則 軟件未達(dá)到產(chǎn)品說明書/產(chǎn)品定義書標(biāo)明的功能。 軟件出現(xiàn)了產(chǎn)品說明書指定不會出現(xiàn)的錯誤。 軟件未達(dá)到產(chǎn)品說明書雖未指出但應(yīng)達(dá)到的目標(biāo)。 軟件測試人員認(rèn)為軟件難以理解、不易使用、運(yùn)行速度緩慢，或者最終用戶認(rèn)為不好。軟件缺陷軟件缺

3、陷一些常識和經(jīng)驗(yàn)之談一些常識和經(jīng)驗(yàn)之談 測試能提高軟件的質(zhì)量，但是提高質(zhì)量不能依賴測試。 測試只能證明缺陷存在，不能證明缺陷不存在?！皬氐椎販y試” 難以成為現(xiàn)實(shí)，要考慮時(shí)間、費(fèi)用等限制，不允許無休止地測 試。我們應(yīng)當(dāng)祈禱：軟件的缺陷在產(chǎn)品被淘汰之前一直沒有機(jī) 會發(fā)作。 測試的主要困難是不知道如何進(jìn)行有效地測試，也不知道什么 時(shí)候可以放心地結(jié)束測試。 每個開發(fā)人員應(yīng)當(dāng)測試自己的程序（份內(nèi)之事），但是不能作 為該程序已經(jīng)通過測試的依據(jù)（所以項(xiàng)目需要獨(dú)立測試人員）。 80-20原則：80的缺陷聚集在20的模塊中，經(jīng)常出錯的模塊 改錯后還會經(jīng)常出錯。 測試應(yīng)當(dāng)循序漸進(jìn)，不要企圖一次性干完，注意“欲速則

4、不達(dá)”。 軟件測試的種類軟件測試的種類名稱說明黑盒測試基于軟件需求，而不是基于軟件內(nèi)部設(shè)計(jì)和程序?qū)崿F(xiàn)的測試方式。白盒測試基于軟件內(nèi)部設(shè)計(jì)和程序?qū)崿F(xiàn)的測試方式。單元測試主要測試軟件模塊的源代碼。一般由開發(fā)人員而非獨(dú)立測試人員來執(zhí)行，因?yàn)闇y試者需要懂得該單元的設(shè)計(jì)與程序?qū)崿F(xiàn)，測試者可能需要編寫額外的測試驅(qū)動程序。集成測試將一些“構(gòu)件”集成一起時(shí)，測試它們能否正常運(yùn)行。這里“構(gòu)件”可以是程序模塊、客戶機(jī)服務(wù)器程序等等。功能測試測試軟件的功能是否符合功能性需求，通常采用黑盒測試方式。一般由獨(dú)立測試人員執(zhí)行。系統(tǒng)測試測試軟件系統(tǒng)是否符合所有需求，包括功能性需求與非功能性需求。一般由獨(dú)立測試人員執(zhí)行，通常

5、采用黑盒測試方式。回歸測試指錯誤被修正后或軟件功能、環(huán)境發(fā)生變化后進(jìn)行的重新測試?；貧w測試的困難在于不好確定哪些內(nèi)容應(yīng)當(dāng)被重新測試。驗(yàn)收測試由客戶或最終用戶執(zhí)行，測試軟件系統(tǒng)是否符合需求規(guī)格說明書。名稱說明負(fù)載測試測試軟件系統(tǒng)的最大負(fù)載，超出此負(fù)載軟件可能會失常。壓力測試概念上與負(fù)載測試相似，叫法不同。性能測試測試軟件在各種狀況下的性能，如在正?；蜃畲筘?fù)載下的狀況。易用性測試測試軟件是否易用，主觀性比較強(qiáng)。一般要根據(jù)很多用戶的測試反饋信息，才能評價(jià)易用性。安裝與反安裝測試測試軟件在“全部、部分、升級”等狀況下的安裝/反安裝過程?；謴?fù)測試測試該系統(tǒng)從故障中恢復(fù)過來的能力。安全性測試測試該系統(tǒng)防止

6、非法侵入的能力。兼容性測試測試該系統(tǒng)與其它軟件硬件兼容的能力。比較測試通過與同類產(chǎn)品比較，考察該系統(tǒng)的優(yōu)點(diǎn)、缺點(diǎn)。Alpha 測試一種先期的用戶測試，此時(shí)系統(tǒng)剛剛開發(fā)完成。Beta測試一種后期的用戶測試，此時(shí)系統(tǒng)已經(jīng)通過內(nèi)部測試，大部分錯誤已經(jīng)改正，即將正式發(fā)行。1、制定測試計(jì)劃 開啟測試項(xiàng)目 在接了一個測試項(xiàng)目后，要在一定的期限內(nèi)制定好測試的詳細(xì)計(jì)劃以及日程安排表2、測試準(zhǔn)備 在計(jì)劃制定好之后，在執(zhí)行之前，必須將測試所需的人力資源，硬件資源，軟件資源，文檔資源以及環(huán)境和人文資源準(zhǔn)備充分3、測試執(zhí)行 測試組根據(jù)測試計(jì)劃和測試日程安排進(jìn)行測試，并輸出測試結(jié)果測試流程測試流程4、測試評估 評估小組

7、或評估人員對測試結(jié)果進(jìn)行評測，分析，并輸出分析結(jié)果5、文檔收集 將從測試計(jì)劃開始到評估結(jié)束的所有文檔進(jìn)行整理收集 將對整個測試過程進(jìn)行總結(jié)，并對測試結(jié)果進(jìn)行總結(jié)6、測試總結(jié)報(bào)告 提交測試結(jié)果 歸還所借相關(guān)資源 文檔入庫 關(guān)閉測試項(xiàng)目測試流程圖測試流程圖測試周期開始升級軟件已改錯誤的驗(yàn)證測試用例執(zhí)行發(fā)現(xiàn)錯誤并報(bào)告每日報(bào)告進(jìn)度自由測試測試周期結(jié)束 定級依據(jù)：國家或行業(yè)標(biāo)準(zhǔn)、法律法規(guī)的規(guī)定和要求；國際或行業(yè)標(biāo)準(zhǔn)、法律法規(guī)的規(guī)定和要求；項(xiàng)目研制規(guī)范的要求；對用戶安全的影響程度；對過程控制及可生產(chǎn)性、可維修性等的影響；市場客戶的接受程度。缺陷分類定級規(guī)范缺陷分類定級規(guī)范 判定標(biāo)準(zhǔn)：判定標(biāo)準(zhǔn)： 根據(jù)產(chǎn)品故

8、障的嚴(yán)重程度，將其劃分為A、B、C、待觀察四個級別。其判定標(biāo)準(zhǔn)如下：A A類故障：類故障： 按照國家法律、標(biāo)準(zhǔn)或行業(yè)相關(guān)標(biāo)準(zhǔn)進(jìn)行鑒定或認(rèn)證不能通過的故障； 可能危及到用戶生命或財(cái)產(chǎn)安全的故障； 嚴(yán)重影響用戶正常使用的故障； 嚴(yán)重影響過程控制及可生產(chǎn)、可維修性等的故障； 客退和市場調(diào)查數(shù)據(jù)顯示用戶無法接受的故障。B B類故障：類故障： 影響過程控制及可生產(chǎn)的故障； 用戶能夠勉強(qiáng)接受的故障； 導(dǎo)致用戶在保修期內(nèi)要求返修的故障。C C類故障：類故障： 用戶可忍受的輕微的產(chǎn)品故障； 用戶一般不常用的功能、且國家規(guī)范無明確要求的故障； 用戶一般不易發(fā)現(xiàn)，且國家規(guī)范無明確要求的故障； 用戶一般不會進(jìn)行，在

9、極端操作條件下才會出現(xiàn)的故障。待觀察類故障待觀察類故障(D(D類類) )： 故障出現(xiàn)機(jī)率小于5%（操作次數(shù)大于20次）或無法找到規(guī)律有效重現(xiàn)，或在多臺手機(jī)（20臺以上）有小于5比例的手機(jī)再現(xiàn)同一功能故障。 對于軟件功能性故障，屬于下列兩種情況中的一種時(shí)，可取消觀察，關(guān)閉故障。 1）在3個正式版本內(nèi)未復(fù)現(xiàn)的故障； 2）同一版本上持續(xù)測試的時(shí)間超過一個月未復(fù)現(xiàn)。 書寫清晰、完整的缺陷報(bào)告是對保證缺陷正確處理的最佳手段。 它也減少了工程師以及其它質(zhì)量保證人員的后續(xù)工作。為了書寫更優(yōu)良的缺陷報(bào)告，需要遵守“5C”準(zhǔn)則：Correct（準(zhǔn)確）：每個組成部分的描述準(zhǔn)確，不會引起誤解； Clear（清晰）：

10、每個組成部分的描述清晰，易于理解； Concise（簡潔）：只包含必不可少的信息，不包括任何多余的內(nèi)容； Complete（完整）：包含復(fù)現(xiàn)該缺陷的完整步驟和其他本質(zhì)信息； Consistent（一致）：按照一致的格式書寫全部缺陷報(bào)告。 缺陷報(bào)告的寫作準(zhǔn)則缺陷報(bào)告的寫作準(zhǔn)則為什么做測試用例為什么做測試用例 完全測試是不可能的 輸入量太大 輸出結(jié)果太多 軟件實(shí)現(xiàn)路徑太多 軟件說明書沒有客觀標(biāo)準(zhǔn)。從不同角度看，軟件缺陷 的標(biāo)準(zhǔn)不同什么是測試用例什么是測試用例 在開始實(shí)施測試之前設(shè)計(jì)好測試用例，可以避免盲目測試并能提高測試效率。 測試用例的使用令軟件測試的實(shí)施重點(diǎn)突出、目的明確。 功能模塊的通用化和

11、復(fù)用化使軟件易于開發(fā)，而相對于功能模塊的測試用例的通用化和復(fù)用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率不斷攀升。使用測試用例的好處使用測試用例的好處 測試用例的代表性：能夠代表并覆蓋各種合理的和不合理、合法的 和非法的、邊界的和越界的、以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè) 置等。 測試結(jié)果的可判定性：即測試執(zhí)行結(jié)果的正確性是可判定的，每一 個測試用例都應(yīng)有相應(yīng)的期望結(jié)果； 測試結(jié)果的可再現(xiàn)性：即對同樣的測試用例，系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng) 是相同的。 測試用例設(shè)計(jì)生成的基本準(zhǔn)則測試用例設(shè)計(jì)生成的基本準(zhǔn)則 正確性測試：輸入用戶實(shí)際數(shù)據(jù)以驗(yàn)證系統(tǒng)是否滿足需求規(guī)格 說明書的要求；測試用例中的測試

12、點(diǎn)應(yīng)首先保證要至少覆蓋需求規(guī)格說明書中的各項(xiàng)功能，并且正常。 容錯性測試：程序能夠接收正確數(shù)據(jù)輸入并且產(chǎn)生正確（預(yù)期）的輸出， 輸入非法數(shù)據(jù)（非法類型、不符合要求的數(shù)據(jù)、溢出數(shù)據(jù)等），程序應(yīng)能給出提示 并進(jìn)行相應(yīng)處理。把自己想象成一名對產(chǎn)品操作一點(diǎn)也不懂的客戶，在進(jìn)行任意操作。 安全性測試：對未經(jīng)授權(quán)的人使用軟件系統(tǒng)或數(shù)據(jù)的企圖，系統(tǒng)能夠控制的程度，程序的數(shù)據(jù)處理能夠保持外部信息（數(shù)據(jù)庫或文件）的完整。 接口間測試：測試各個模塊相互間的協(xié)調(diào)和通信情況，數(shù)據(jù)輸入輸出的一致性和正確性工具程序。 數(shù)據(jù)庫測試：依據(jù)數(shù)據(jù)庫設(shè)計(jì)規(guī)范對軟件系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)、數(shù)據(jù)表及其之間的數(shù)據(jù)調(diào)用關(guān)系進(jìn)行測試。 測試用例設(shè)

13、計(jì)方法測試用例設(shè)計(jì)方法測試用例設(shè)計(jì)方法測試用例設(shè)計(jì)方法 手機(jī)開發(fā)的三個關(guān)鍵要素是：質(zhì)量（Quality）、成本（Cost） 和上市時(shí)間（Time to Market），這三個要素相互制約和影響，一 款成功的手機(jī)開發(fā)，往往是這三個要素的完美結(jié)合。 測試只能證明軟件存在缺陷（Defect），卻不能證明不存在缺陷（Defect），“徹底地測試”是不現(xiàn)實(shí)的，要考慮上市時(shí)間和測試成本等因素的限制，不允許無休止的測試。 并非所有測試出來的問題都會被修復(fù)。 手機(jī)軟件是屬于嵌入式的，軟件的運(yùn)行跟硬件結(jié)合得非常緊密，因此在手機(jī)軟件測試的過程中，硬件是不能忽略的一個因素。 測試是為了證明手機(jī)軟件存在錯誤，而不是為

14、了證明軟件沒有錯誤，所以成功的測試在于發(fā)現(xiàn)了迄今為止沒有發(fā)現(xiàn)的問題。手機(jī)軟件測試?yán)砟钍謾C(jī)軟件測試?yán)砟钍謾C(jī)軟件測試主要用黑盒測試法手機(jī)軟件測試主要用黑盒測試法 黑盒測試把測試對象看成一個黑盒子，測試人員完全不考慮程序內(nèi)部的 邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是 否符合它的功能說明。 黑盒測試方法是在程序接口上進(jìn)行測試，主要是為了發(fā)現(xiàn)以下錯誤: 是否有不正確或遺漏了的功能? 在接口上，輸入能否正確地接受? 能否輸出正確的結(jié)果? 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤? 性能上是否能夠滿足要求? 是否有初始化或終止性錯誤? 黑盒測試又叫做功能測試或數(shù)據(jù)驅(qū)動測

15、試。 這是手機(jī)軟件測試工作中最核心和最基本的一項(xiàng)測試，該測試的主要內(nèi)容是檢查軟件是否符合需求定義，并通過構(gòu)造正常的操作來檢查手機(jī)的動作是否正確；在這個測試?yán)铮_性是最最重要的手機(jī)軟件質(zhì)量要素。 手機(jī)的功能（若無特別指明，均指軟件功能）按照可見性可以分為兩類：顯性功能和隱性功能。 顯性功能：指在菜單里可以看得到的功能 隱性功能：指在菜單里看不到的功能 舉個例子，電話本的顯性功能有增加、編輯、刪除、撥打等，這些功能可以在電話本的菜單里面看得到，姓名列表排序則屬于一個隱性功能，因?yàn)樵陔娫挶镜牟藛卫餂]有這樣一個子菜單，但它卻是一個實(shí)實(shí)在在的功能 在實(shí)際的測試過程中，顯性功能通過菜單遍歷可以很容易地進(jìn)

16、行無遺漏的測試，但是隱性功能卻很容易為我們所忽略！一個有效的解決辦法是去檢查軟件的功能定義列表（Feature List），從這個列表里面找出那些隱性的功能。4.1功能測試功能測試 功能測試的基本方法是構(gòu)造一些合理輸入（在需求范圍之內(nèi)），檢查輸出是否與期望的相同。如果兩者不一致，即表明功能有誤。也有例外的情況，如需求規(guī)格說明書中的某個功能寫錯了，而實(shí)際上軟件的功能卻是正確的，這時(shí)要更改的是需求規(guī)格說明書。 功能測試看起來比較簡單，只要看得懂需求規(guī)格說明書，誰都會做。難點(diǎn)在于如何構(gòu)造有效的輸入。由于輸入空間通常是無限的，窮舉測試顯然行不通。那么隨便輸入一些東西，碰運(yùn)氣行不行？ 功能測試有兩種比較

17、好的測試方法：等價(jià)劃分法和邊界值分析法。 等價(jià)劃分是指把輸入空間劃分為幾個“等價(jià)區(qū)間”，在每個“等價(jià)區(qū)間”中只需要測試一個典型值就可以了。等價(jià)劃分法來源于人們的直覺與經(jīng)驗(yàn)，可令測試事半功倍。 “缺陷遺漏在角落里，聚集在邊界上”。邊界值測試法是對等價(jià)劃分法的補(bǔ)充。如果A和B是輸入空間的邊界值，那么除了典型值外還要用A和B作為測試用例。 健壯性是指在異常情況下，軟件還能正常運(yùn)行的能力。健壯性有兩層含義： 一是容錯能力，二是恢復(fù)能力。 容錯性測試通常構(gòu)造一些不合理的輸入來引誘軟件出錯，例如： （1）輸入錯誤的數(shù)據(jù)類型。如定義不存在的日期、時(shí)間。 （2）輸入定義域之外的數(shù)值。如解鎖界面輸入非定義的字符

18、，查找手機(jī)內(nèi)不存在的電話本等。粗暴一些方式俗稱“大猩猩”測試法。例如在測試直接拔電池關(guān)機(jī)。 恢復(fù)測試重點(diǎn)考察一下幾項(xiàng)： （1）系統(tǒng)能否重新運(yùn)行； （2）有無重要的數(shù)據(jù)丟失； （3）是否毀壞了其它相關(guān)的軟件硬件。 另外，手機(jī)軟件的很多功能的實(shí)現(xiàn)是有很多隱含的條件的，在健壯性測試中，要檢查當(dāng)這些條件不滿足的時(shí)候手機(jī)的反應(yīng)。 4.2健壯性測試健壯性測試 矩陣測試是使手機(jī)處于一個特定的狀態(tài)，然后構(gòu)造一個異步事件，檢查當(dāng)這個異步事件發(fā)生時(shí)手機(jī)軟件的性能。如：玩游戲過程中來電，進(jìn)行接通、掛斷、拒接、未接等操作短信編寫過程中來電或來短信，是否能正常處理并同時(shí)保留原先編寫的內(nèi)容等。 根據(jù)事件的來源，異步事件可

19、以分為外部事件和內(nèi)部事件 外部事件舉例：SMS到達(dá)、來電呼入、非關(guān)機(jī)狀態(tài)拔電池、插入耳機(jī)等 內(nèi)部事件舉例：鬧鐘響鬧、日程表事件提示、低電告警、自動關(guān)機(jī)等4.3矩陣測試矩陣測試 這里主要測試手機(jī)軟件的易用性、用戶界面的友好性及美學(xué)性。 UI測試遵循的原則： 求美原則，檢查在UI的布局里，各種要素是否能傳達(dá)一種美感，布局是否合理，色彩是否合諧，”科技美學(xué)化“不是一句掛在墻上印在紙上的口號，而應(yīng)該成為實(shí)實(shí)在在的行動 一致性原則，同樣的一個功能的UI在不同的情景所呈現(xiàn)的方式應(yīng)該保持一致 普遍性原則(各功能操作、界面顯示及提示符合用戶的操作習(xí)慣) 正確性原則 注意：在評價(jià)易用性和視覺效果時(shí)，主觀性非常強(qiáng)

20、，應(yīng)當(dāng)考慮多個人的觀點(diǎn)。例如，照相、播放功能(界面、音量、音質(zhì)等)是否達(dá)到用戶的理想效果4.4UI測試測試 兼容性測試：也就是不同品牌手機(jī)，不同網(wǎng)絡(luò)，不同品牌和不同容量大小的SIM卡、存儲卡之間的互相兼容的測試，以短消息為例：中國電信的小靈通接收到從中國移動或中國聯(lián)通GSM發(fā)來的短消息，接收，顯示和回復(fù)功能是否正常等 。 例如：分別采用移動、聯(lián)通的GSM卡進(jìn)行通話、SMS、EMS等的互通互發(fā)測試，同一張卡在A機(jī)型保存的信息在B機(jī)型是否可以查看/刪除等，不同容量、品牌的存儲卡手機(jī)能否識別。4.5兼容性測試兼容性測試 性能測試即測試軟件處理事務(wù)的速度，一是為了檢驗(yàn)性能是否符合需求，二是為了得到某些

21、性能數(shù)據(jù)供人們參考（例如用于宣傳）。 性能測試從負(fù)荷及容量兩個方面考慮： 考察手機(jī)在高負(fù)荷狀態(tài)下的運(yùn)行情況。所謂高負(fù)荷，就是多個功能模塊同時(shí)在運(yùn)行，使手機(jī)CPU資源高負(fù)荷地運(yùn)轉(zhuǎn)。 考察手機(jī)在滿容量狀態(tài)下的運(yùn)行情況。在測試前，應(yīng)設(shè)法使手機(jī)所有的用戶內(nèi)存全部存滿，然后在進(jìn)行一些相應(yīng)的操作，觀察手機(jī)的性能情況。4.6性能測試性能測試 壓力測試也叫負(fù)荷測試，即獲取系統(tǒng)能正常運(yùn)行的極限狀態(tài)。 壓力測試的主要任務(wù)是：構(gòu)造正確的輸入，使勁折騰系統(tǒng)卻讓它剛好不癱瘓。 壓力測試的一個變種是敏感測試。在某種情況下，微小的輸入變動會導(dǎo)致系統(tǒng)的表現(xiàn)（如性能）發(fā)生急劇的變化。敏感測試目的是發(fā)現(xiàn)什么樣的輸入可能會引發(fā)不穩(wěn)定現(xiàn)象。 例如，在編輯短信的過程中不斷地接收短信，連續(xù)進(jìn)行多次呼叫、多次對文件系統(tǒng)進(jìn)行添加刪除操作， MP3播放的同時(shí)進(jìn)行WWW上網(wǎng)業(yè)務(wù) 4.6.1壓力測試 極限測試是指在極限負(fù)載或容量情況下進(jìn)行功能的操作和測試。負(fù)載或容量可包括文件系統(tǒng)內(nèi)存容量、內(nèi)存調(diào)用、電源電壓、下載數(shù)據(jù)流等多種因素，很多系統(tǒng)會在極限測試中崩潰。 例如，在SIM卡和手