第一篇：做好測試計劃和測試用例工作的關(guān)鍵

做好測試計劃和測試用例的工作的關(guān)鍵

做好測試計劃和測試用例的工作的關(guān)鍵（轉(zhuǎn)）

對于目前大部分公司存在的狀況，很多測試計劃文檔只是一種形式而已

所以我的理解是：怎樣讓測試計劃對整個測試工作真正具有指導(dǎo)作用

這里把測試計劃和測試方案分開來講（計劃對應(yīng)于管理層面的問題，方案對應(yīng)于技術(shù)方面的問題）

測試計劃中最重要的內(nèi)容包括： 進(jìn)度安排；人力、物力資源分配（包括組織結(jié)構(gòu)等）、風(fēng)險假設(shè)和規(guī)避措施。（其他像軟件版本號之類的，只要是個人都會寫，這里不列了）寫好測試計劃的關(guān)鍵在于：充分了解你的團(tuán)隊的整體實力和團(tuán)隊中每個成員的特點充分理解為當(dāng)前軟件制訂的整個研發(fā)活動過程

帶過項目的人都知道：在實際項目中，往往進(jìn)度才是第一位的，但是對進(jìn)度的把握和估算卻是極其困難的。只有做到這兩點才有可能對進(jìn)度有比較準(zhǔn)確的把握，對人員有一個合理的分配。否則所謂的進(jìn)度，所謂的資源分配，都是拍腦袋得出的結(jié)果，風(fēng)險假設(shè)更是無從談起，這樣的測試計劃文檔只能流于形式也就不足為奇了。

寫好測試方案的關(guān)鍵在于：有一個合理的測試計劃熟悉相關(guān)業(yè)務(wù)深入體會用戶的實際需求

這個不想多解釋了，不難理解。

至于測試用例，看到上面不少朋友認(rèn)為關(guān)鍵在于理解用戶需求。

其實理解用戶實際需求是一切的根本，并且對于有些測試（比如像單元測試）對應(yīng)的測試用例通常和用戶需求之間的關(guān)系可能并不直接或是十分密切。

當(dāng)然，如果有一份好的需求和設(shè)計文檔的話，什么事情都解決了。可是現(xiàn)實往往是不存在這樣的文檔的。

所以我的看法是：對業(yè)務(wù)理解的深入程度經(jīng)驗有自己的文檔

前兩條不解釋了。自己的文檔包括兩方面：一個是常用的特殊測試數(shù)據(jù)，比如一些特殊字符，極限長度的輸入等等。這個在項目時間緊迫的時候是非常有幫助的（有的時候甚至可以當(dāng)成check list）。另一個就是自己測試模塊對應(yīng)的相關(guān)需求和設(shè)計文檔。服務(wù)器上的標(biāo)準(zhǔn)文檔拖到本地來并且記得及時更新。然后在測試過程中，需要什么內(nèi)容文檔上沒有，最直接的方法是和開發(fā)人員溝通。（其實我很反對這么做。你想，按開發(fā)人員自己說的標(biāo)準(zhǔn)

去測他們自己開發(fā)的模塊能測出因為需求或者設(shè)計錯誤導(dǎo)致的問題么??應(yīng)該是和客戶和designer去溝通，可惜一般沒有這條件-_-）任何標(biāo)準(zhǔn)文檔上缺少的內(nèi)容，只要是和你有關(guān)的，一定要記得做記錄。當(dāng)然你有時間有精力把整個系統(tǒng)的需求和設(shè)計文檔都搗鼓出來最好，不過通常是沒這可能性的。

補充說明：lz最后提到的“完全憑借自己的經(jīng)驗在執(zhí)行測試活動”不如說是完全憑借自己的感覺在執(zhí)行測試活動。

項目需要的用例詳盡程度可以商量，但是必須要有。如果進(jìn)度很緊，可以用一部分用例加上check list進(jìn)行測試活動（比如很多日本外包項目的UI測試，相當(dāng)一部分可以用check list來代替具體的用例，效果并不差)

完整的大綱應(yīng)該是：

目錄

測試計劃標(biāo)識符

目錄表

參考文獻(xiàn)

詞匯表

介紹

測試項

軟件風(fēng)險問題

待測特征

不予測試的特征

方法

測試項通過/失敗準(zhǔn)則

掛起準(zhǔn)則和恢復(fù)需求

測試交付物

測試任務(wù)

環(huán)境需求

職責(zé)

人員安排與培訓(xùn)需求

進(jìn)度表

計劃風(fēng)險與應(yīng)急措施

審批

第二篇：做好測試計劃和測試用例的工作的關(guān)鍵是什么？

一、測試計劃的有效性和全面性

無論做什么工作，都是計劃先行，然后按照所制定的計劃去執(zhí)行、跟蹤和控制。軟件測試也一樣，先要制定測試計劃，是做好整個測試工作的前提。所以在進(jìn)行實際測試之前，應(yīng)制定良好的、切實可行的、有效的測試計劃。軟件測試計劃的目標(biāo)是提供一個測試框架，不斷收集產(chǎn)品特性信息，對測試的不確定性（測試范圍、測試風(fēng)險等）進(jìn)行分析，將不確定性的內(nèi)容慢慢轉(zhuǎn)化為確定性的內(nèi)容，該過程最終使得我們對測試的范圍、用例數(shù)量、工作量、資源和時間等進(jìn)行合理的估算，從而對測試策略、方法、人力、日程等做出決定或安排。

1．測試計劃的要點

測試規(guī)劃與軟件開發(fā)活動同步進(jìn)行，在需求分析時，就開始測試策劃，確定測試需求、目標(biāo)、資源等。測試計劃可以按不同的測試階段（集成測試、系統(tǒng)測試等）來組織，也可以為每個測試任務(wù)或目標(biāo)(安全性、性能、可靠性等測試)進(jìn)行考慮。

測試計劃主要集中在測試目標(biāo)、質(zhì)量標(biāo)準(zhǔn)、測試策略、測試范圍、測試用例設(shè)計方法、所需資源和日程安排等，其關(guān)鍵是制定有效的測試策略，界定清楚地測試范圍，識別出測試中所存在的各種風(fēng)險并找出風(fēng)險回避、監(jiān)控和管理的方法，針對不同的測試目標(biāo)或階段確定測試方法，對測試工作量及所需的資源、時間進(jìn)行合理的估算。所有這些，都是為了兩個根本目的：測試的質(zhì)量和效率。

2．制定測試策略

制定測試策略主要分析測試的目標(biāo)和質(zhì)量指標(biāo)、確定測試的對象和依據(jù)，測試的重點和所采用的方法，包括在規(guī)定的時間內(nèi)哪些測試內(nèi)容要完成，軟件產(chǎn)品的特性或質(zhì)量在哪些方面得到確認(rèn)。測試策略可以分為：

基于測試技術(shù)的測試策略，根據(jù)軟件系統(tǒng)的技術(shù)構(gòu)成和層次結(jié)構(gòu)，著重考慮如何分層測試、選擇哪些測試工具、如何將白盒測試和黑盒測試有機(jī)地結(jié)合起來等。

基于測試方案的綜合測試策略，根據(jù)測試的目標(biāo)和范圍，著重考慮如何更好地滿足測試需求、如何讓功能測試、適用性測試和兼容性測試等進(jìn)行有機(jī)結(jié)合、如何充分利用測試資源、如何更有效地完成回歸測試等。

為了更好地制定好測試策略，要做到：

全面細(xì)致地了解產(chǎn)品的項目信息：應(yīng)用領(lǐng)域、測試范圍、市場需求、產(chǎn)品特點、主要功能和技術(shù)架構(gòu)；

基于模塊、功能、系統(tǒng)、版本、性能、配置和安裝等各個因素對產(chǎn)品質(zhì)量的影響，客觀地、全面地展開測試計劃；

根據(jù)軟件單元在系統(tǒng)結(jié)構(gòu)的重要性差異和一旦發(fā)生故障將給客戶造成的損失大小，來確定軟件測試的等級、重點和先后次序；

需要在測試用例數(shù)和測試覆蓋率上進(jìn)行權(quán)衡而獲得一個平衡點，以便能使用盡可能少的有效測試用例去發(fā)現(xiàn)盡可能多的程序錯誤。測試不足意味著讓用戶承擔(dān)隱藏錯誤帶來的危險；同時反過來看，過度測試則又會浪費許多寶貴的資源或耽誤軟件產(chǎn)品的發(fā)布時間。

3．確定測試范圍

測試主要依據(jù) “產(chǎn)品設(shè)計規(guī)格說明書”、代碼所發(fā)生的變化及其影響的區(qū)域，來確定哪些功能和特性要測試，哪些功能和特性不需要測試。在確定測試范圍時，主要考慮的因素有：

優(yōu)先級最高的需求功能

新增加的功能和編碼改動較大的已有功能

容易出現(xiàn)問題的部分功能

過去測試不夠充分的地方

經(jīng)常被用戶使用的功能和配置（占20%）

4．所需資源和日程安排

為了合理、準(zhǔn)確地安排日程，對測試工作量要進(jìn)行正確的估計。除了對工作量的估計之外，還要正確評估參與該項目人員的培訓(xùn)時間、適應(yīng)過程和工作能力等。由于涉及到不同的項目、不同的測試人員、不同的前期介入方式，要對每人每天能夠完成的平均測試用例數(shù)目做出一個準(zhǔn)確的估計確實很困難，但是可以根據(jù)以前一些項目測試的經(jīng)驗或歷史積累下來的數(shù)據(jù)進(jìn)行判斷推理，并適當(dāng)增加10%-20%的余量，估算結(jié)果就比較準(zhǔn)確了。

在估算的基礎(chǔ)上，進(jìn)行有效的、合理的資源安排。在不同的測試階段人力資源的需求是不一樣的，所以人力資源的計劃要有一定的靈活性和動態(tài)性，形成有機(jī)的動態(tài)平衡，保證測試的進(jìn)度和資源的使用的效率。

5．編制測試計劃的技巧

要做好測試計劃，測試設(shè)計人員要仔細(xì)閱讀有關(guān)資料，包括用戶需求規(guī)格說明書、設(shè)計文檔等，全面熟悉系統(tǒng)，并建議注意以下方面：

讓所有合適的相關(guān)人員參與測試項目的計劃制定，特別是在測試計劃早期；

測試所需的時間、人力及其它資源的預(yù)估，盡量做到客觀、準(zhǔn)確、留有余地；

測試項目的輸入、輸出和質(zhì)量標(biāo)準(zhǔn)，應(yīng)與各方達(dá)成一致；

建立變化處理的流程規(guī)則，識別出在整個測試階段中哪些是內(nèi)在的、不可避免的變化因素，加以控制。

6．測試項目計劃的評審

測試項目的計劃不可能一氣呵成，而是要經(jīng)過計劃初期、起草、討論、審查等不同階段，才能將測試計劃制定好。測試計劃的評審是完成測試計劃關(guān)鍵的一個環(huán)節(jié)，包括測試組織內(nèi)部的自我評審、討論和修改，然后交到評審會進(jìn)行正式的評審，直至測試計劃得到審批。

測試計劃的正式評審，項目中的每個人（產(chǎn)品經(jīng)理、項目經(jīng)理、開發(fā)工程師等）都應(yīng)當(dāng)參與。計劃的審查是必不可少的，每一個參與者都可能根據(jù)其經(jīng)驗及專長提出問題或建議，彌補在測試范圍、工作量、風(fēng)險等各方面的不足，進(jìn)一步完善測試計劃。

二、測試用例在測試活動中的作用：

1.強化測試用例在測試活動中的作用

測試用例在實際中沒有起多大作用 , 在實際測試時根本沒有按測試用例執(zhí)行，測試執(zhí)行后沒有把新的測試用例補充到用例庫中等等。

為何如此？ 根本原因是對測試用例重要性的認(rèn)識不夠，測試流程不完善，針對測試用例的管理流程更不完善，其實，從三個方面具體來說：

1）測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執(zhí)行環(huán)節(jié)的基本依據(jù)，如果這個依據(jù)不能足夠發(fā)揮它應(yīng)起的作用，那是不是說這個依據(jù)不明確、依據(jù)設(shè)計的不合理呢？答案是肯定的！

2）制定了完備有效的測試用例，為什么不按測試用例執(zhí)行測試呢？首先是因為企業(yè)沒有嚴(yán)格和良好的機(jī)制促使和保證測試執(zhí)行者這樣做；其次是個別測試人員投機(jī)取巧心理作祟的表現(xiàn)。

3）測試用例設(shè)計得不可能天衣無縫，不可能完全滿足軟件需求的覆蓋要求，測試執(zhí)行過程里肯定會發(fā)現(xiàn)有些 測試路徑或數(shù)據(jù)在用例里沒有體現(xiàn)，那么事后該將其補充到用例庫里，以方便他人和后續(xù)版本的測試；如果沒有這樣做，那么測試部門負(fù)責(zé)人和每個測試員都難辭其疚，是該重新坐下來思考一下公司的測試用例管理規(guī)范和測試流程了。

2.改進(jìn)測試用例執(zhí)行過程

那么究竟如何做，才能盡量避免上述問題呢？

我們不妨從軟件開發(fā)周期的每個階段就把這些問題考慮進(jìn)去，以便從初始就力爭將問題縮到最小，將問題扼殺在萌芽階段。

1）軟件需求分析階段，測試人員從軟件生命周期的需求階段就開始介入。通常測試人員的測試工作開展在開發(fā)周期的末尾，如果前期不涉入，如何通曉整個系統(tǒng)的需求和架構(gòu)而對其充分測試呢？

項目的測試負(fù)責(zé)人和測試工程師在 需求階段 的任務(wù)有：

a.參與軟件需求調(diào)研，以測試角度分析需求的可測性，可構(gòu)思將來對其測試的方法、原則等；更重要的是，對不可測或難以測試性問題要及時與客戶或項目經(jīng)理協(xié)調(diào)解決。

b.全面了解系統(tǒng)需求，從客戶角度考慮軟件測試需要達(dá)到的驗證狀態(tài)，即何些功能點需重點測試、何些無需，以便將來制定測試計劃。

2）軟件分析設(shè)計階段：

l 測試人員除制定測試計劃書等基本工作外，還有一個相當(dāng)必要的任務(wù)，那就是將系統(tǒng)的可測性落實到書面文檔，以備將來編寫測試用例。（之所以要這么做，是因為考慮到很多企業(yè)編寫測試用例直接參考需求規(guī)格說明書或者分析流程圖，這樣跨度大，難度也大，是造成測試用例不完備、覆蓋范圍小的重要原因）。

l 測試人員更要編寫一份《軟件功能點測試描述書》，它是軟件的詳細(xì)測試分析文檔，其主旨是將系統(tǒng)分析人員的開發(fā)分析文檔加工成以測試為角度的功能點分析文檔，重要的是描述對系統(tǒng)分解后每個功能點逐一的校驗描述，包括何種方法測試、何種數(shù)據(jù)測試、期望測試結(jié)果等，這些信息都是描述性的，無須具體數(shù)據(jù)；它的作用是據(jù)此編寫測試用例，以及測試執(zhí)行時的參考依據(jù)，基于它直接來源于需求，覆蓋當(dāng)然最全，也最能貼近客戶要求。

l 當(dāng)然該文檔不是非要不可，如果有類似的替代文檔或有工具可自動實現(xiàn)此功能，則會倍加受推崇！

3）軟件開發(fā)階段： 編寫測試用例。應(yīng)該遵守的原則是：

n 首先，從覆蓋率來說，測試用例庫的用例要達(dá)到最大覆蓋軟件系統(tǒng)的功能點。編寫測試用例時，基本上就是將《軟件功能點測試描述書》中的每個功能點進(jìn)行操作上的細(xì)化：一是從步驟上描述到達(dá)校驗點的方式，二是從內(nèi)容上描述以何種數(shù)據(jù)校驗功能點；如此可實現(xiàn)趨向最大需求覆蓋率。

n 其次，從數(shù)量來講，一個多于半年開發(fā)周期（指從編碼開始直到提交客戶的時間段）的軟件系統(tǒng)，它的用例數(shù)量不要低于 4000 個，甚至更多?。↖BM 等大公司測試過程的人士會認(rèn)為 4000 還是很少的數(shù)目。我們試想，對于一個中小型軟件系統(tǒng)，如果設(shè)計出 5000 個用例，那它的測試覆蓋率還怕不高么）！

n 再次，如此眾多測試用例的管理問題。是的，最好是需要測試用例管理工具軟件。以 word 或 excel 來編寫測試用例也可以。）測試用例 格式上一般內(nèi)容以外的幾個要點：

l 制定適合本公司的測試用例模版；

l 是用例模版里要有關(guān)鍵字索引，以方便按關(guān)鍵字分類查找，如測試方法（分手工 / 自動兩種）；

l 是測試用例要有 狀態(tài)跟蹤，可根據(jù)用例執(zhí)行狀態(tài)索引用例（測試通過、測試失敗、測試中斷等）；

l 是執(zhí)行失敗的用例要 鏈接到相應(yīng)的缺陷報告，如有根據(jù)缺陷報告檢索測試用例的試圖更妙，可評估該缺陷影響范圍的大?。?/p>

l [FS:PAGE] 是測試用例的修改，以及每個測試周期的運行都有 日志記錄，以便后期追蹤

和新員工參考；）軟件測試階段，測試負(fù)責(zé)人劃分不同的測試階段（如集成測試、系統(tǒng)測試、回歸測試、性能測試等），再劃分不同的子測試周期（如前兩個星期做 冒煙測試，測試方式是手工 / 自動，測試版本是 **，測試環(huán)境是 **，包括服務(wù)器端與客戶端等；接著做第一模塊功能測試；如此順次。），再為項目組測試人員分配測試用例（通常原則是每個人負(fù)責(zé)幾塊區(qū)域的測試任務(wù)），測試人員則按照詳細(xì)的用例文檔去執(zhí)行測試，測試失敗則提交軟件缺陷報告。這里要遵循的幾個原則是：

A）有健全且嚴(yán)格的體制保證測試執(zhí)行者嚴(yán)格按照測試用例執(zhí)行測試。這并不妨礙測試者創(chuàng)造力的發(fā)揮，因為前期用例的設(shè)計和編寫就是項目全體測試人員智慧的結(jié)晶！我們一直苦苦追尋眾多測試工程師加班加點辛苦工作的原因，其實大都發(fā)生這一階段；如此實施，即便沒有解決根本問題，也會大大提高測試執(zhí)行效率。

B）如有對測試用例認(rèn)識模糊或內(nèi)容遺漏的地方，可暫做記錄待后期解決，或經(jīng)測試負(fù)責(zé)人與項目其他管理人員同意方可更新用例庫。

C）測試負(fù)責(zé)人每日負(fù)責(zé)跟蹤本測試子周期或階段的測試用例執(zhí)行情況，以及每日提交的缺陷報告，根據(jù)執(zhí)行進(jìn)展?fàn)顟B(tài)以及缺陷數(shù)量或嚴(yán)重等級與項目高層或其他人員展開交流，商議解決途徑，并確定或調(diào)整未來時間的測試任務(wù)。

D）測試執(zhí)行者負(fù)責(zé)執(zhí)行自己區(qū)域的測試用例，還要負(fù)責(zé)跟蹤該區(qū)域軟件缺陷的修改進(jìn)展，根據(jù)其狀態(tài) 不斷驗證軟件功 能點。

E）通過缺陷管理工具來 管理軟件缺陷 ；這樣的集成工具都提供了清晰的報告模版及強大的追蹤功能，測試團(tuán)隊的每一成員按照自己的角色和權(quán)限訪問缺陷管理工具，并不斷跟蹤軟件缺陷的狀態(tài)。

F）對于自動測試（包括自動化功能測試和性能、壓力測試），有一些特殊要點。是自動化測試無須編寫測試用例，只要在編寫時將用例庫里適合或需要自動測試的用例的測試方法（不同工具可能名稱不同）設(shè)為自動即可，故而到此階段才提及自動化測試。自動化測試的實施方案有所不同，每款測試工具的使用和測試流程也不同，但都可以從在這一階段編寫測試腳本，并運行自動測試。這里要提的其他幾個基本原則是：

l 是選擇恰當(dāng)?shù)臏y試工具品牌，并要求提供培訓(xùn)；

l 是項目的自動化測試工作有專人負(fù)責(zé)跟蹤，以保證工作質(zhì)量，他們可不參與日常測試；l 是確定自動化測試成員在項目中的角色，一般自動化測試成員隸屬于項目測試負(fù)責(zé)人，負(fù)責(zé)人同樣跟蹤其工作狀態(tài)；

l 是選擇最簡單、最重用的測試用例使用自動測試方法；

l 是使用工具廠商提供的測試框架編寫腳本，千萬別采用單純錄制回放的方式，要開發(fā)出健壯且重用性強的測試腳本 ；

l 是有專人更新腳本，也有專人跟蹤自動測試結(jié)果；

l 一般選擇的測試工具品牌和缺陷管理工具品牌是同一廠商，以方便不同類型缺陷的集中管理；

l 是在多人協(xié)作開發(fā)測試腳本、代碼量相對較大情況下，應(yīng)考慮使用配置管理工具來管理測試腳本。）由于不同公司開發(fā)產(chǎn)品的特殊性，也許需要特殊類型的測試，如安全測試、甚至代碼級單元測試等，這些內(nèi)容需要酌情考慮測試用例的編寫，以及測試的執(zhí)行。）軟件驗收階段 ：除了提交軟件測試評估報告（各種類型測試結(jié)果的評估都應(yīng)有報告）這些基本工作外，對于測試用例，此時要集中時間更新，更新整個測試周期中一切需要更新的內(nèi)容，以方便未來新版本的測試。即便您開發(fā)的是項目軟件--提交客戶后沒有新版本--那也需要后期維護(hù)，維護(hù)階段需要重新測試某功能點，然而用例如果不準(zhǔn)確，碰巧又是一個

新員工來做，那就死翹翹了?。┢渌f明：加強測試部門內(nèi)部人員的培訓(xùn)教育很重要，包括工作技能與個人素質(zhì)兩方面，可通過國內(nèi)主要的培訓(xùn)機(jī)構(gòu)，也可是購買工具廠商的直接培訓(xùn)。應(yīng)該說，很多測試新人對于測試用例的書寫還存在問題，更別提及測試用例的管理或執(zhí)行；以此可見，我們的測試工程師需要培訓(xùn)的空間還很大。

3.總結(jié)

綜上所述，我們得出結(jié)論--測試用例在測試中沒起到應(yīng)有的作用，是因為測試用例編寫質(zhì)量不高，覆蓋不夠，執(zhí)行不利；測試執(zhí)行時不遵循測試用例，執(zhí)行后不更新用例庫，是測試部門的整體工作流程不健全、不規(guī)范。

第三篇：編寫測試用例和測試計劃

第六章 編寫測試用例和測試計劃

主要內(nèi)容：軟件測試計劃；軟件測試方案；軟件風(fēng)險分析

1.軟件測試計劃

1.1 軟件測試計劃的簡介

1測試計劃概念：測試計劃在測試中處于中心位置，它闡述了測試準(zhǔn)備工作和執(zhí)行測試的必要條件，同時也形成了測試過程質(zhì)量保證的基礎(chǔ)。

2測試計劃的作用：組織和管理測試；使測試工作和整個開發(fā)工作整合起來；資源和變更事先最為一個可控制的風(fēng)險。

1.2 如何編寫軟件測試計劃

1認(rèn)識測試項目不僅僅只有單一測試計劃

2避免不分析直接進(jìn)行測試階段日程安排

3避免測試任務(wù)的安排超前于開發(fā)任務(wù)

4避免有些系統(tǒng)測試類型無法按期進(jìn)入測試

5不正確的變更測試計劃

6測試計劃里明確更新周期和暫停測試原則

7測試計劃不是一成不變的1.3 測試計劃包括：簡介，目的，范圍，測試策略，進(jìn)度，缺陷的嚴(yán)重程度的定義，風(fēng)

險分析。

2.軟件測試方案

2.1 軟件測試方案的概念

軟件測試方案描述測試的特征，測試的方法，測試環(huán)境的規(guī)劃，測試工具的設(shè)計和選擇，測試用例的設(shè)計方法，測試代碼的設(shè)計方案。即包括以下幾點：

? 明確測試策略（黑盒，白盒，灰盒等）

? 細(xì)化測試特征

? 測試用例的規(guī)劃

? 測試環(huán)境的規(guī)劃

? 自動化測試框架的設(shè)計

? 測試工具的設(shè)計和選擇

2.2 軟件測試計劃于軟件測試方案的區(qū)別

? 測試計劃是組織管理層面的文檔。測試方案是技術(shù)層面的文檔。

? 測試方案需要在測試計劃的指導(dǎo)下進(jìn)行，測試計劃提出“做什么”，測試方案明確“怎么做”

? 回報的對象不同，測試計劃向領(lǐng)導(dǎo)匯報，測試方案是組員共享該文檔

3.軟件測試的風(fēng)險

? 軟件需求風(fēng)險

? 人員的風(fēng)險

? 測試環(huán)境的風(fēng)險

? 測試工程師對產(chǎn)品的業(yè)務(wù)不熟悉

補充：

回歸測試：把以前檢查過的已經(jīng)修復(fù)好的缺陷，拿來另測看有無帶來新的缺陷 反側(cè)：把開發(fā)人員已經(jīng)處理的缺陷拿來測，看是否修復(fù)

第四篇：工作時長測試用例5.4

1.目的測量手機(jī)各狀態(tài)純工作時長是否符合設(shè)計規(guī)范和用戶正常使用。

2.適用范圍

適合移動產(chǎn)品試產(chǎn)及相關(guān)變更的驗證。

3.內(nèi)容

3.1 手機(jī)待機(jī)時長（測試用例編號:5.4.1）

3.1.1 測試條件和說明

1）被測機(jī)1臺裝SIM卡、TF卡，測試前手機(jī)需至少上電2小時保證后備電池充

滿電（以保證關(guān)機(jī)漏電流不是測了后備電池充電電流），測試過程中手機(jī)背光等級/時長、鍵盤鎖與音量級等均為默認(rèn)；

2）測試用移動卡2張、測試用電腦1臺、程控電源1臺（3.8V）、假電池1個、SkyworksLabteststudio電流分析軟件（設(shè)置：Sample interval：

1996.8uS,Sample points：501, Sample length：3600S），如沒特別說明，電流值均由電流分析軟件讀取；

3）手機(jī)開關(guān)機(jī)時長規(guī)定：開機(jī)時長15小時(早上7:30~晚上22:30)，關(guān)機(jī)時

長9小時(晚上22:30~早上7:30)；

4）用戶使用時長參考營銷部調(diào)查結(jié)果，在計算手機(jī)待機(jī)時長時引用。

3.1.2 測試步驟

1）關(guān)機(jī)漏電流：

手機(jī)關(guān)機(jī)狀態(tài)時的電流，在程控電源上直接電流值，關(guān)機(jī)時長為9H（上面3.1.1第3)點規(guī)定）。

2）待機(jī)省電平均搜網(wǎng)電流：

手機(jī)開機(jī)待機(jī)省電/后臺掛Q（不收到消息)，正常環(huán)境里的30秒平均搜

網(wǎng)電流；

用戶使用時長＝15*3600-T1-?T17=54000-6410=47590秒（備注：

T1...T17為以下第3到第17項各項用戶使用時長）。

3）關(guān)機(jī)響鬧鈴電流：

手機(jī)關(guān)機(jī)期間響鬧鈴(鬧鐘響0db_1Khz.mp3、響鈴方式：響鈴+振動）30

秒手動停止選擇開機(jī)后進(jìn)入省電過程中的平均電流；

用戶使用時長＝30秒。

4）開機(jī)響鬧鈴電流：

手機(jī)待機(jī)省電期間響鬧鈴(鬧鐘響0db_1Khz.mp3、響鈴方式：響鈴+振動）

30秒后手動停止后進(jìn)入省電過程中的平均電流；

用戶使用時長＝30秒

5）來電響鈴電流：

正常環(huán)境手機(jī)待機(jī)省電期間外線來電響鈴（響鈴0db_1Khz.mp3、響鈴方

式：響鈴+振動）10秒平均電流（每天來電4次）；

用戶使用時長＝10*4＝40秒。

6）手柄通話電流：

正常環(huán)境手機(jī)手柄通話5分鐘本方掛斷后進(jìn)入省電過程中的平均電流（每天3個手柄通話）；

用戶使用時長＝5*3*60＝900秒。

7）免提通話電流：

正常環(huán)境手機(jī)免提通話5分鐘本方掛斷后進(jìn)入省電過程中的平均電流（每天1個免提通話）；

用戶使用時長＝5*60＝300秒。

8）編輯/發(fā)送短信息電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕進(jìn)入信息編輯，以正常的速度

編輯60個漢字后發(fā)送信息，發(fā)送成功后返回待機(jī)自動進(jìn)入省電過程中的平均電流（信息編輯至發(fā)送成功時長為2分鐘，每天發(fā)送4條信息）；用戶使用時長＝2*4*60＝480秒。

9)接收/查看短信息電流：

正常環(huán)境手機(jī)待機(jī)省電期間收到短信后按鍵點亮屏幕查看完信息再返回

待機(jī)自動進(jìn)入省電過程中的平均電流（接收到信息至查看完信息時長為30秒鐘，每天接收4條信息）；

用戶使用時長＝4*30＝120秒。

10)FM自動搜尋電臺/聆聽廣播電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕進(jìn)入收音機(jī)/插耳機(jī)FM自動搜

尋電臺/聆聽廣播10分鐘后關(guān)閉收音機(jī)拔掉耳機(jī)返回待機(jī)進(jìn)入省電過程中的平均電流；

用戶使用時長＝10*60＝600秒。

11)MP3耳機(jī)聆聽電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕/插入耳機(jī)快捷進(jìn)入MP3播放器

/最大音量循環(huán)播放＜0db_1kHz.mp3＞音樂20分鐘后按鍵停止播放拔掉耳機(jī)返回待機(jī)進(jìn)入省電過程中的平均電流；

用戶使用時長＝10*60＝600秒。

12)MP3外放電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕快捷進(jìn)入MP3播放器/最大音量

外喇叭循環(huán)播放＜0db_1kHz.mp3＞音樂10分鐘后按鍵停止播放返回待機(jī)進(jìn)入省電過程中的平均電流；

用戶使用時長＝10*60＝600秒。

13)MP4外放電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕進(jìn)入電影播放器/最大音量外

喇叭全屏播放＜妃子笑.mp4＞電影5分鐘后按鍵停止播放返回待機(jī)進(jìn)入省電過程中的平均電流；

用戶使用時長＝5*60＝300秒。

14)WAP上網(wǎng)電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕進(jìn)入WAP瀏覽器登陸新浪網(wǎng)/流

浪5個子網(wǎng)頁如新聞、財經(jīng)、體育、軍事、房產(chǎn)等5分鐘后退出瀏覽器返回待機(jī)進(jìn)入省電過程中的平均電流；

用戶使用時長＝5*60＝300秒。

15）QQ聊天電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕進(jìn)入移動QQ聊天（聲音/振動開

啟）10分鐘后退出返回待機(jī)進(jìn)入省電過程中的平均電流；

用戶使用時長＝10*60＝600秒。

16）QQ斗地主電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕登陸QQ斗地主游戲10分鐘后退

出返回待機(jī)進(jìn)入省電過程中的平均電流；

用戶使用時長＝10*60＝600秒。

17)玩手機(jī)游戲電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕進(jìn)入游戲,玩俄羅斯方塊（聲音

/振動開啟）10分鐘后退出到待機(jī)進(jìn)入省電過程中的平均電流；

用戶使用時長＝10*60＝600秒。

18)藍(lán)牙傳輸文件電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏幕進(jìn)入藍(lán)牙選項，搜索并與另一

臺手機(jī)配對成功后發(fā)送文件給對方，5分鐘后停止發(fā)送返回待機(jī)進(jìn)入省電過程中的平均電流；

用戶使用時長＝5*60＝300秒。

19)關(guān)機(jī)電流：

正常環(huán)境手機(jī)待機(jī)省電期間按鍵點亮屏解鎖或開蓋后手動關(guān)機(jī)至屏滅過

程中的平均電流；

用戶使用時長＝10秒。

20)手機(jī)待機(jī)時長計算方法：

a>關(guān)于用戶每天各功能使用時長,引用營銷部調(diào)查數(shù)據(jù)：通話20分鐘+短信10分鐘+游戲20分鐘+MP3耳機(jī)播放20分鐘+外放10分鐘+鬧鐘1個+上

網(wǎng)5分鐘+藍(lán)牙5分鐘+FM10分鐘+來電4次+待機(jī)；在此基礎(chǔ)上我們合理增加了：MP4外放5分鐘+QQ聊天10分鐘、1個鬧鐘及關(guān)機(jī)時長10秒鐘，以

此計算手機(jī)待機(jī)使用時長；

b>通話20分鐘分解為手柄通話3個、免提通話1個（每個通話5分鐘）；短信10分鐘分解為接收/發(fā)送短信息各4條（接收查看1條信息30秒鐘，編輯發(fā)送1條信息2分鐘）；游戲20分鐘分解為QQ斗地主和玩俄羅斯方塊

各10分鐘；鬧鐘使用時長為30秒鐘/個；

c>最后根據(jù)公式手機(jī)待機(jī)時長T=電池容量*24H*3600S/〔I關(guān)機(jī)漏電流

*Ta+I省電平均搜網(wǎng)電流*Tb+I1*T1+?+I17*T17〕

計算出手機(jī)總待機(jī)時長T。

說明：

“I關(guān)機(jī)漏電流*Ta”為手機(jī)關(guān)機(jī)9小時里的單項耗電,Ta=9*3600=23400S；“I省電平均搜網(wǎng)電流*Tb”為手機(jī)開機(jī)15小時里除去其他功能耗電總和的省電平均搜網(wǎng)單項耗電,Tb=15*3600-T1-?-T17=54000-6410=47590S（T1...T17為以上第3到第17項各項用戶使用時長）；

“I3*T3+?+I19*T19”為手機(jī)開機(jī)期間各項功能操作的耗電總和。

3.1.3 預(yù)期結(jié)果

手機(jī)的待機(jī)時長T應(yīng)大于等于3天（72小時）。

3.2 通話時長（測試用例編號：5.4.2）

3.2.1 測試條件:

準(zhǔn)備手機(jī)2臺、程控電源、假電池、電流測試軟件、CMD55/CMU200（62CH，5級功率，BS-API:-70dbm）、測試白卡；

3.2.2 測試步驟

1）手機(jī)接白卡連接CMD55/CMU200手柄耦合通話，測試省電狀態(tài)的通話平均

電流；

2）計算方法：電池容量乘以90%除以平均通話電流，即得出通話時長（乘以

90%的原因是算電池容量的有效值）。

3.2.3 預(yù)期結(jié)果

通話時長：一般大于或等于4H，相應(yīng)型號說明書標(biāo)注的通話時長作為一

個參考。

3.3 MP3外放時長（測試用例編號：5.4.3）

3.3.1 測試條件:

準(zhǔn)備手機(jī)2臺、程控電源、假電池、電流測試軟件、CMD55/CMU200（62CH-5

級功率-BS-API:-70dbm）、測試白卡；

3.3.2 測試步驟

1）手機(jī)接白卡連接CMD55/CMU200，待網(wǎng)絡(luò)注冊成功后，最大音量播放《倩

女幽魂》，測試省電狀態(tài)的外放平均電流；

2）計算方法：電池容量乘以90%除以MP3外放的平均電流，即得出MP3外放時

長。

3.3.3 測試預(yù)期結(jié)果

MP3外放時長：一般大于或等于4H。

3.4 耳機(jī)播放MP3時長（測試用例編號：5.4.4）

3.4.1 測試條件:

準(zhǔn)備手機(jī)2臺、原配耳機(jī)、程控電源、假電池、電流測試軟件、CMD55/CMU200

（62CH-5級功率-BS-API:-70dbm）、測試白卡；

3.4.2 測試步驟

1）手機(jī)接白卡連接CMD55/CMU200，待網(wǎng)絡(luò)注冊成功后，耳機(jī)最大音量播放

《倩女幽魂》，測試省電狀態(tài)耳機(jī)播放MP3平均電流；

2）計算方法：電池容量乘以90%除以耳機(jī)播放MP3的平均電流，即得出耳機(jī)

播放MP3的時長。

3.4.3 測試預(yù)期結(jié)果

耳機(jī)播放MP3時長：一般大于或等于30H。

3.5 播放MP4時長（測試用例編號：5.4.5）

3.5.1 測試條件:

準(zhǔn)備手機(jī)2臺、程控電源、假電池、電流測試軟件、CMD55/CMU200（62CH-5

級功率-BS-API:-70dbm）、測試白卡；

3.5.2 測試步驟

1）手機(jī)接白卡連接CMD55/CMU200，待網(wǎng)絡(luò)注冊成功后，最大音量外放MP4

《步步高新廣告》，測試外放MP4的平均電流；

2）計算方法：電池容量乘以90%除以外放MP4的平均電流，即得出外放MP4的工作時長。

3.5.3 測試預(yù)期結(jié)果

播放MP4時長：一般大于或等于4H。

3.6 錄像時長（測試用例編號：5.4.6）

3.5.1 測試條件:

準(zhǔn)備手機(jī)2臺、程控電源、假電池、電流測試軟件、CMD55/CMU200（62CH-5

級功率-BS-API:-70dbm）、測試白卡；

3.5.2 測試步驟

1）手機(jī)接白卡連接CMD55/CMU200，待網(wǎng)絡(luò)注冊成功后，對著純白色背景錄

像，測試錄像時的平均電流；

2）計算方法：電池容量乘以90%除以錄像時的平均電流，即得出錄像的工作

時長。

3.5.3 測試預(yù)期結(jié)果

錄像時長：一般大于或等于4H。

第五篇：APP測試流程,測試用例,計劃,報告可參照（寫寫幫推薦）

移動APP測試流程及測試點

1.APP測試基本流程

1.1.測試周期

測試周期可按項目的開發(fā)周期來確定測試時間，一般測試時間為兩三周（即15個工作日），根據(jù)項目情況以及版本質(zhì)量可適當(dāng)縮短或延長測試時間。正式測試前先向負(fù)責(zé)人確認(rèn)項目排期。

1.2.測試資源

測試任務(wù)開始前，檢查各項測試資源。

--產(chǎn)品功能需求文檔；

--產(chǎn)品原型圖；

--產(chǎn)品效果圖；

--行為統(tǒng)計分析定義文檔；

--測試設(shè)備（ios7.1-ios9.2；Android4.0-Android6.0；）；

--其他。

1.3.日報、周報及APP上線報告

1）測試人員每天需對所測項目發(fā)送測試日報。

2）測試日報所包含的內(nèi)容為：

--對當(dāng)前測試版本質(zhì)量進(jìn)行分級（高中低）；

--對較嚴(yán)重的問題進(jìn)行例舉，提示開發(fā)人員優(yōu)先修改；

--對版本的整體情況進(jìn)行評估。

3）APP上線前，測試人員發(fā)送APP上線報告。4）上線報告所包含的內(nèi)容為：

--對當(dāng)前版本質(zhì)量進(jìn)行分級；

--附上測試報告（功能測試報告、兼容性測試報告、性能測試報告以及app可用性能標(biāo)準(zhǔn)結(jié)果）；

--總結(jié)上線版本的基本情況。若有遺留問題必須列出并記錄解決方案。5）周報作為匯總本周所有的情況，以及開發(fā)人員修改情況與回歸測試。

2.APP測試點

2.1.安全測試

2.1.1.軟件權(quán)限

1）扣費風(fēng)險：包括發(fā)送短信、撥打電話、連接網(wǎng)絡(luò)等；

2）隱私泄露風(fēng)險：包括訪問手機(jī)信息、訪問聯(lián)系人信息等；

3）對App的輸入有效性校驗、認(rèn)證、授權(quán)、敏感數(shù)據(jù)存儲、數(shù)據(jù)加密等方面進(jìn)行檢測；

4）限制/允許使用手機(jī)功能接人互聯(lián)網(wǎng)；

5）限制/允許使用手機(jī)發(fā)送接受信息功能；

6）限制/允許應(yīng)用程序來注冊自動啟動應(yīng)用程序；

7）限制或使用本地連接；

8）限制/允許使用手機(jī)拍照或錄音；

9）限制/允許使用手機(jī)讀取用戶數(shù)據(jù)；

10)限制/允許使用手機(jī)寫人用戶數(shù)據(jù)；

11)檢測App的用戶授權(quán)級別、數(shù)據(jù)泄漏、非法授權(quán)訪問等。2.1.2.安裝與卸載的安全性

1）應(yīng)用程序應(yīng)能正確安裝到設(shè)備驅(qū)動程序上；

2）能夠在安裝設(shè)備驅(qū)動程序上找到應(yīng)用程序的相應(yīng)圖標(biāo)；

3）是否包含數(shù)字簽名信息；

4）JAD文件和JAR包中包含的所有托管屬性及其值必需是正確的；

5）JAD文件顯示的資料內(nèi)容與應(yīng)用程序顯示的資料內(nèi)容應(yīng)一致；

6）安裝路徑應(yīng)能指定；

7）沒有用戶的允許, 應(yīng)用程序不能預(yù)先設(shè)定自動啟動；

8）卸載是否安全, 其安裝進(jìn)去的文件是否全部卸載；

9）卸載用戶使用過程中產(chǎn)生的文件是否有提示；

10）其修改的配置信息是否復(fù)原；

11）卸載是否影響其他軟件的功能；

12）卸載應(yīng)該移除所有的文件。

2.1.3.數(shù)據(jù)安全性

1）當(dāng)將密碼或其他的敏感數(shù)據(jù)輸人到應(yīng)用程序時, 其不會被儲存在設(shè)備中, 同時密碼也不會被解碼；

2）輸人的密碼將不以明文形式進(jìn)行顯示；

3）密碼, 信用卡明細(xì), 或其他的敏感數(shù)據(jù)將不被儲存在它們預(yù)輸人的位置上；

4）防止應(yīng)用程序異常終止而又沒有刪除它的臨時文件, 文件可能遭受人侵者的襲擊, 然后讀取這些數(shù)據(jù)信息；

5）當(dāng)將敏感數(shù)據(jù)輸人到應(yīng)用程序時, 其不會被儲存在設(shè)備中；

6）在數(shù)據(jù)刪除之前，應(yīng)用程序應(yīng)當(dāng)通知用戶或者應(yīng)用程序提供一個“取消”命令的操作；

7）“取消”命令操作能夠按照設(shè)計要求實現(xiàn)其功能；

8）應(yīng)用程序應(yīng)當(dāng)能夠處理當(dāng)不允許應(yīng)用軟件連接到個人信息管理的情況；

9）當(dāng)進(jìn)行讀或?qū)懹脩粜畔⒉僮鲿r, 應(yīng)用程序?qū)蛴脩舭l(fā)送一個操作錯誤 的提示信息；

10）在沒有用戶明確許可的前提下不損壞刪除個人信息管理應(yīng)用程序中的任 何內(nèi)容；

11）應(yīng)用程序讀和寫數(shù)據(jù)正確；

12）應(yīng)用程序應(yīng)當(dāng)有異常保護(hù)；

13）如果數(shù)據(jù)庫中重要的數(shù)據(jù)正要被重寫, 應(yīng)及時告知用戶；

14）能合理地處理出現(xiàn)的錯誤；

25）意外情況下應(yīng)提示用戶。

2.1.4.通訊安全性

1）在運行其軟件過程中, 如果有來電、SMS、EMS、MMS、藍(lán)牙、紅外等通訊或充電時, 是否能暫停程序，優(yōu)先處理通信, 并在處理完畢后能正?；謴?fù)軟件, 繼續(xù)其原來的功能；

2）當(dāng)創(chuàng)立連接時, 應(yīng)用程序能夠處理因為網(wǎng)絡(luò)連接中斷, 進(jìn)而告訴用戶連接中斷的情況；

3）應(yīng)能處理通訊延時或中斷；

4）應(yīng)用程序?qū)⒈３止ぷ鞯酵ㄓ嵆瑫r, 進(jìn)而發(fā)送給用戶一個錯誤信息指示有連接錯誤；

5）應(yīng)能處理網(wǎng)絡(luò)異常和及時將異常情況通報用戶；

6）應(yīng)用程序關(guān)閉或網(wǎng)絡(luò)連接不再使用時應(yīng)及時關(guān)閉)斷開；

7)HTTP、HTTPS覆蓋測試

--App和后臺服務(wù)一般都是通過HTTP來交互的，驗證HTTP環(huán)境下是否正常；

--公共免費網(wǎng)絡(luò)環(huán)境中（如：麥當(dāng)勞、星巴克等）都要輸入用戶名和密碼，通過SSL認(rèn)證來訪問網(wǎng)絡(luò)，需要對使用HTTP Client的library異常作捕獲處理。

2.1.5.人機(jī)接口安全性

1）返回菜單總保持可用；

2）命令有優(yōu)先權(quán)順序；

3）聲音的設(shè)置不影響應(yīng)用程序的功能；

4）應(yīng)用程序必需利用目標(biāo)設(shè)備適用的全屏尺寸來顯示上述內(nèi)容；

5）應(yīng)用程序必需能夠處理不可預(yù)知的用戶操作, 例如錯誤的操作和同時按下多個鍵。

2.2.安裝卸載測試

驗證App是否能正確安裝、運行、卸載及操作過程和操作前后對系統(tǒng)資源的使用情況。

2.2.1.安裝

1）軟件在不同操作系統(tǒng)（Android、iOS）下安裝是否正常；

2）軟件安裝后的是否能夠正常運行，安裝后的文件夾及文件是否寫到了指定的目錄里；

3）軟件安裝各個選項的組合是否符合概要設(shè)計說明；

4)）軟件安裝向?qū)У腢I測試；

5）軟件安裝過程是否可以取消，點擊取消后，寫入的文件是否如概要設(shè)計說明處理；

6）軟件安裝過程中意外情況的處理是否符合需求（如死機(jī)，重啟，斷電）； 7）安裝空間不足時是否有相應(yīng)提示；

8）安裝后沒有生成多余的目錄結(jié)構(gòu)和文件；

9）對于需要通過網(wǎng)絡(luò)驗證之類的安裝，在斷網(wǎng)情況下嘗試一下；

10）還需要對安裝手冊進(jìn)行測試，依照安裝手冊是否能順利安裝。

2.2.2.卸載

1）直接刪除安裝文件夾卸載是否有提示信息；

2）測試系統(tǒng)直接卸載程序是否有提示信息；

3）測試卸載后文件是否全部刪除所有的安裝文件夾；

4）卸載過程中出現(xiàn)的意外情況的測試（如死機(jī)、斷電、重啟）；

5）卸載是否支持取消功能，單擊取消后軟件卸載的情況；

6）系統(tǒng)直接卸載UI測試，是否有卸載狀態(tài)進(jìn)度條提示。

2.3.UI測試

測試用戶界面(如菜單、對話框、窗口和其它可規(guī)控件)布局、風(fēng)格是否滿足客戶要求、文字是否正確、頁面是否美觀、文字、圖片組合是否完美、操作是否友好等。

UI測試的目標(biāo)是確保用戶界面會通過測試對象的功能來為用戶提供相應(yīng)的訪問或瀏覓功能。確保用戶界面符合公司或行業(yè)的標(biāo)準(zhǔn)。包括用戶友好性、人性化、易操作性測試。

2.3.1.導(dǎo)航測試

1）按鈕、對話框、列表和窗口等；或在不同的連接頁面之間需要導(dǎo)航；

2）是否易于導(dǎo)航，導(dǎo)航是否直觀； 3）是否需要搜索引擎；

4）導(dǎo)航幫助是否準(zhǔn)確直觀；

5）導(dǎo)航與頁面結(jié)構(gòu)、菜單、連接頁面的風(fēng)格是否一致。

2.3.2.圖形測試

1）橫向比較。各控件操作方式統(tǒng)一；

2）自適應(yīng)界面設(shè)計，內(nèi)容根據(jù)窗口大小自適應(yīng)；

3）頁面標(biāo)簽風(fēng)格是否統(tǒng)一；

4）頁面是否美觀；

5）頁面的圖片應(yīng)有其實際意義而要求整體有序美觀；

6）圖片質(zhì)量要高且圖片尺寸在設(shè)計符合要求的情況下應(yīng)盡量?。?/p>

7）界面整體使用的顏色不宜過多。

2.3.3.內(nèi)容測試

1）輸入框說明文字的內(nèi)容與系統(tǒng)功能是否一致；

2）文字長度是否加以限制；

3）文字內(nèi)容是否表意不明；

4）是否有錯別字；

5）信息是否為中文顯示；

6）是否有敏感性詞匯、關(guān)鍵詞；

7）是否有敏感性圖片，如：涉及版權(quán)、專利、隱私等圖片。

2.4.功能測試

根據(jù)軟件說明或用戶需求驗證App的各個功能實現(xiàn)，采用如下方法實現(xiàn)并評估功能測試過程： 1)采用時間、地點、對象、行為和背景五元素或業(yè)務(wù)分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內(nèi)在、外在及非功能直接相關(guān)的需求，構(gòu)建測試點，并明確測試標(biāo)準(zhǔn)，若用戶需求中無明確標(biāo)準(zhǔn)遵循，則需要參考行業(yè)或相關(guān)國際標(biāo)準(zhǔn)或準(zhǔn)則。

2)根據(jù)被測功能點的特性列丼出相應(yīng)類型的測試用例對其進(jìn)行覆蓋，如；涉及輸入的地方需要考慮等價、邊界、負(fù)面、異?；蚍欠ā鼍盎貪L、關(guān)聯(lián)測試等測試類型對其進(jìn)行覆蓋。

3)在測試實現(xiàn)的各個階段跟蹤測試實現(xiàn)與需求輸入的覆蓋情況，及時修正業(yè)務(wù)或需求理解錯誤。

2.4.1.運行

1）App安裝完成后的試運行，可正常打開軟件；

2）App打開測試，是否有加載狀態(tài)進(jìn)度提示；

3）App打開速度測試，速度是否可觀；

4）App頁面間的切換是否流暢，邏輯是否正確；

5）注冊

--同表單編輯頁面--用戶名密碼長度；

--注冊后的提示頁面；

--前臺注冊頁面和后臺的管理頁面數(shù)據(jù)是否一致；

--注冊后，在后臺管理中頁面提示；

6）登錄

--使用合法的用戶登錄系統(tǒng)；

--系統(tǒng)是否允許多次非法的登陸，是否有次數(shù)限制；--使用已經(jīng)登陸的賬號登陸系統(tǒng)是否正確處理；

--使用禁用的賬號登陸系統(tǒng)是否正確處理；

--用戶名、口令（密碼）錯誤或漏填時能否登陸；

--刪除或修改后的用戶，原用戶登陸；

--不輸入用戶口令和用戶、重復(fù)點（確定或取消按鈕）是否允許登陸；

--登陸后，頁面中登陸信息；--頁面中有注銷按鈕；--登陸超時的處理；

7）注銷

--注銷原模塊，新的模塊系統(tǒng)能否正確處理；

--終止注銷能否返回原模塊，原用戶；

--注銷原用戶，新用戶系統(tǒng)能否正確處理；

--使用錯誤的賬號、口令、無權(quán)限的被禁用的賬號進(jìn)行注銷。

2.4.2.APP前后臺切換

1)APP切換到后臺，再回到app，檢查是否停留在上一次操作界面；

2)APP切換到后臺，再回到app，檢查功能及應(yīng)用狀態(tài)是否正常，安卓和IOS的版本的處理機(jī)制有的不一樣；

3)app切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候；

4)手機(jī)鎖屏解屏后進(jìn)入app注意是否會崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候；

5)當(dāng)App使用過程中有電話進(jìn)來中斷后再切換到app，功能狀態(tài)是否正常； 6)當(dāng)殺掉app進(jìn)程后，再開啟app，app能否正常啟動；

7)出現(xiàn)必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在，有時候會出現(xiàn)應(yīng)用自動跳過提示框的缺陷；

8)對于有數(shù)據(jù)交換的頁面，每個頁面都必需要進(jìn)行前后臺切換、鎖屏的測試，這種頁面最容易出現(xiàn)崩潰。

2.4.3.自動登陸

很多應(yīng)用提供自動登錄功能，當(dāng)應(yīng)用開啟時自動以上一次登錄的用戶身份來使用app.1)app有免登錄功能時，需要考慮IOS與安卓版本差異；

2)考慮無網(wǎng)絡(luò)情況時能否正常進(jìn)入免登錄狀態(tài)；

3)切換用戶登錄后，要校驗用戶登錄信息及數(shù)據(jù)內(nèi)容是否相應(yīng)更新，確保原用戶退出；

4)根據(jù)MTOP的現(xiàn)有規(guī)則，一個帳戶只允許登錄一臺機(jī)器。所以，需要檢查一個帳戶登錄多臺手機(jī)的情況。原手機(jī)里的用戶需要被踢出，給出友好提示；

5)app切換到后臺，再切回前臺的校驗；

6)切換到后臺，再切換回前臺的測試

7)密碼更換后，檢查有數(shù)據(jù)交換時是否進(jìn)行了有效身份的校驗；

8)支持自動登錄的應(yīng)用在進(jìn)行數(shù)據(jù)交換時，檢查系統(tǒng)是否能自動登錄成功并且數(shù)據(jù)操作無誤；

9)檢查用戶主動退出登錄后，下次啟動app，應(yīng)停留在登錄界面

2.4.4.數(shù)據(jù)更新

根據(jù)應(yīng)用的業(yè)務(wù)規(guī)則，以及數(shù)據(jù)更新量的情況，來確定最優(yōu)的數(shù)據(jù)更新方案。

1)需要確定哪些地方需要提供手動刷新，哪些地方需要自動刷新，哪些地方需要手動+自動刷新；

2)確定哪些地方從后臺切換回前臺時需要進(jìn)行數(shù)據(jù)更新；

3)根據(jù)業(yè)務(wù)、速度及流量的合理分配，確定哪些內(nèi)容需要實時更新，哪些需要 定時更新；

4)確定數(shù)據(jù)展示部分的處理邏輯，是每次從服務(wù)端請求，還是有緩存到本地，這樣才能有針對性的進(jìn)行相應(yīng)測試；

5)檢查有數(shù)據(jù)交換的地方，均有相應(yīng)的異常處理。

2.4.5.離線瀏覽

很多應(yīng)用會支持離線瀏覽，即在本地客戶端會緩存一部分?jǐn)?shù)據(jù)供用戶查看。

1)在無網(wǎng)絡(luò)情況可以瀏覽本地數(shù)據(jù)；

2)退出app再開啟app時能正常瀏覽；

3)切換到后臺再切回前臺可以正常瀏覽；

4)鎖屏后再解屏回到應(yīng)用前臺可以正常瀏覽；

5)在對服務(wù)端的數(shù)據(jù)有更新時會給予離線的相應(yīng)提示

2.4.6.APP更新

1)當(dāng)客戶端有新版本時，有更新提示；

2)當(dāng)版本為非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現(xiàn)更新提示；

3)當(dāng)版本為強制升級版時，當(dāng)給出強制更新后用戶沒有做更新時，退出客戶端。下次啟動app時，仍出現(xiàn)強制升級提示。

4)當(dāng)客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新；

5)當(dāng)客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新后的客戶端功能是否是新版本；

6)當(dāng)客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬于缺陷。

2.4.7.定位、照相機(jī)服務(wù)

1)App有用到相機(jī)，定位服務(wù)時，需要注意系統(tǒng)版本差異；

2)有用到定位服務(wù)、照相機(jī)服務(wù)的地方，需要進(jìn)行前后臺的切換測試，檢查應(yīng)用是否正常；

3)當(dāng)定位服務(wù)沒有開啟時，使用定位服務(wù)，會友好性彈出是否允許設(shè)置定位提示。當(dāng)確定允許開啟定位時，能自動跳轉(zhuǎn)到定位設(shè)置中開啟定位服務(wù)；

4)測試定位、照相機(jī)服務(wù)時，需要采用真機(jī)進(jìn)行測試。

2.4.8.時間測試

客戶端可以自行設(shè)置手機(jī)的時區(qū)、時間，因此需要校驗該設(shè)置對app的影響。

--中國為東8區(qū)，所以當(dāng)手機(jī)設(shè)置的時間非東8區(qū)時，查看需要顯示時間的地方，時間是否展示正確，應(yīng)用功能是否正常。時間一般需要根據(jù)服務(wù)器時間再轉(zhuǎn)換成客戶端對應(yīng)的時區(qū)來展示，這樣的用戶體驗比較好。比如發(fā)表一篇微博在服務(wù)端記錄的是10：00，此時，華盛頓時間為22：00，客戶端去瀏覽時，如果設(shè)置的是華盛頓時間,則顯示的發(fā)表時間即為22:00,當(dāng)時間設(shè)回東8區(qū)時間時，再查看則顯示為10：00。（另：如果時間不統(tǒng)一，由于semp服務(wù)器的緣故，會導(dǎo)致APP無法正常使用，遇到這種情況，請及時更新手機(jī)時間，或者通知開發(fā)人員修改服務(wù)器時間，謝謝大家配合）。2.4.9.PUSH消息推送測試

1)檢查push消息是否按照指定的業(yè)務(wù)規(guī)則發(fā)送；

2)檢查不接受推送消息時，檢查用戶不會再接收到push；

3)如果用戶設(shè)置了免打擾的時間段，檢查在免打擾時間段內(nèi)，用戶接收不到PUSH。在非免打擾時間段，用戶能正常收到push；

4)當(dāng)push消息是針對登錄用戶的時候，需要檢查收到的push與用戶身份是否相符，沒有錯誤地將其它人的消息推送過來。一般情況下，只對手機(jī)上最后一個登錄用戶進(jìn)行消息推送；

5)測試push時，需要采用真機(jī)進(jìn)行測試。

2.5.性能測試

評估App的時間和空間特性：

1)極限測試：在各種邊界壓力情況下，如電池、存儲、網(wǎng)速等，驗證App是否能正確響應(yīng)。

--內(nèi)存滿時安裝App；

--運行App時手機(jī)斷電；

--運行App時斷掉網(wǎng)絡(luò)；

2)響應(yīng)能力測試：測試App中的各類操作是否滿足用戶響應(yīng)時間要求。

--App安裝、卸載的響應(yīng)時間；

--App各類功能性操作的影響時間；

3)壓力測試：反復(fù)/長期操作下、系統(tǒng)資源是否占用異常。

--App反復(fù)進(jìn)行安裝卸載，查看系統(tǒng)資源是否正常；

--其他功能反復(fù)進(jìn)行操作，查看系統(tǒng)資源是否正常；

4)性能評估：評估典型用戶應(yīng)用場景下，系統(tǒng)資源的使用情況。

2.6.兼容測試

主要測試內(nèi)部和外部兼容性：

1）與本地及主流App是否兼容；

2）基于開發(fā)環(huán)境和生產(chǎn)環(huán)境的不同，檢驗在各種網(wǎng)絡(luò)連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數(shù)據(jù)和運用是否正確；

3）與各種設(shè)備是否兼容，若有跨系統(tǒng)支持則需要檢驗是否在各系統(tǒng)下，各種行為是否一致；

--不同操作系統(tǒng)的兼容性，是否適配；

--不同手機(jī)屏幕分辨率的兼容性；

--不同手機(jī)品牌的兼容性。

2.7.回歸測試

1）Bug修復(fù)后且在新版本發(fā)布后需要進(jìn)行回歸測試。

2）Bug修復(fù)后的回歸測試在交付前、要進(jìn)行全量用例的回歸測試。

2.8.用戶體驗測試

以主觀的普通消費者的角度去感知產(chǎn)品或服務(wù)的舒適、有用、易用、友好親切程度。通過不同個體、獨立空間和非經(jīng)驗的統(tǒng)計復(fù)用方式去有效評價產(chǎn)品的體驗特性修改意見提升產(chǎn)品的潛在客戶滿意度。

1）是否有空數(shù)據(jù)界面設(shè)計，引導(dǎo)用戶去執(zhí)行操作；

2）是否濫用用戶引導(dǎo)；

3）是否有不可點擊的效果，如：你的按鈕此時處于不可用狀態(tài)，那么一定要灰掉，或者拿掉按鈕，否則會給用戶誤導(dǎo)；

4）菜單層次是否太深；

5）交互流程分支是否太多；

6）相關(guān)的選項是否離得很遠(yuǎn)；

7）一次是否載入太多的數(shù)據(jù)；

8）界面中按鈕可點擊范圍是否適中；

9）標(biāo)簽頁是否跟內(nèi)容沒有從屬關(guān)系，當(dāng)切換標(biāo)簽的時候，內(nèi)容跟著切換；

10）操作應(yīng)該有主次從屬關(guān)系；

11）是否定義Back的邏輯。涉及軟硬件交互時，Back鍵應(yīng)具體定義；

12）是否有橫屏模式的設(shè)計，應(yīng)用一般需要支持橫屏模式，即自適應(yīng)設(shè)計

2.9.硬件環(huán)境測試

2.9.1.網(wǎng)絡(luò)環(huán)境測試

手機(jī)的網(wǎng)絡(luò)目前主要分為2G、3G、4G、wifi。目前2G的網(wǎng)絡(luò)相對于比較慢，測試時尤其要注意此塊的測試。

1)無網(wǎng)絡(luò)時，執(zhí)行需要網(wǎng)絡(luò)的操作，給予友好提示，確保程序不出現(xiàn)crash； 2)內(nèi)網(wǎng)測試時，要注意選擇到外網(wǎng)操作時的異常情況處理；

3)在網(wǎng)絡(luò)信號不好時，檢查功能狀態(tài)是否正常，確保不因提交數(shù)據(jù)失敗而造成crash；

4)在網(wǎng)絡(luò)信號不好時，檢查數(shù)據(jù)是否會一直處于提交中的狀態(tài)，有無超時限制。如遇數(shù)據(jù)交換失敗時要給予提示；

5)在網(wǎng)絡(luò)信號不好時，執(zhí)行操作后，在回調(diào)沒有完成的情況下，退出本頁面或者執(zhí)行其他操作的情況，有無異常情況。此問題也會經(jīng)常出現(xiàn)程序crash。2.9.2.服務(wù)器壘機(jī)或者出現(xiàn)404、500的情況下測試

后臺服務(wù)牽涉到DNS、空間服務(wù)商的情況下會影響其穩(wěn)定性，如：當(dāng)出現(xiàn)域名解析故障時，你對后臺API的請求很可能就會出現(xiàn)404錯誤，拋出異常。這時需要對異常進(jìn)行正確的處理，否則可能會導(dǎo)致程序不能正常工作。是否有友好的提示。