手機(jī)軟件測試基礎(chǔ)

1、BTX-ST軟件測試人員基本素質(zhì)手機(jī)軟件測試基本概念手機(jī)軟件測試內(nèi)容軟件測試的基本方法主要的參考資料良好的個人素質(zhì)責(zé)任心：責(zé)任心是做好工作必備的素質(zhì)之一，測試工程師更應(yīng)該將其發(fā)揚(yáng)光大。如果測試中沒有盡到責(zé)任，甚至敷衍了事，這將會把測試工作交給用戶來完成，很可能引起非常嚴(yán)重的后果。專心：主要指測試人員在執(zhí)行測試任務(wù)的時候要專心，不可一心二用。經(jīng)驗(yàn)表明，高度集中精神不但能夠提高效率，還能發(fā)現(xiàn)更多的軟件缺陷，業(yè)績最棒的往往是團(tuán)隊(duì)中做事精力最集中的那些成員。細(xì)心：主要指執(zhí)行測試工作時候要細(xì)心，認(rèn)真執(zhí)行測試，不可以忽略一些細(xì)節(jié)。某些缺陷如果不細(xì)心很難發(fā)現(xiàn)，例如一些界面的樣式、文字等。耐心：很多測試工作有

2、時候顯得非?？菰?，需要很大的耐心才可以做好。如果比較浮躁，就不會做到“專心”和“細(xì)心”，這將讓很多軟件缺陷從你眼前逃過。自信心：自信心是現(xiàn)在多數(shù)測試工程師都缺少的一項(xiàng)素質(zhì)，尤其在面對需要編寫測試代碼等工作的時候，往往認(rèn)為自己做不到。要想獲得更好的職業(yè)發(fā)展，測試工程師們應(yīng)該努力學(xué)習(xí)，建立能“解決一切測試問題”的信心?！拔逍摹敝皇亲龊脺y試工作的基本要求，測試人員應(yīng)該具有的素質(zhì)還很多。例如測試人員不但要具有團(tuán)隊(duì)合作精神，而且應(yīng)該學(xué)會寬容待人，學(xué)會去理解“開發(fā)人員”，同時要尊重開發(fā)人員的勞動成果開發(fā)出來的產(chǎn)品。正確的思考方式Oracle Heuristics: “HICCUPP” 原則原則Consis

3、tent with History: Present function behavior is consistent with past behavior. Consistent with our Image: Function behavior is consistent with an image that the organization wants to project. Consistent with Comparable Products: Function behavior is consistent with that of similar functions in compa

4、rable products. Consistent with Claims: Function behavior is consistent with what people say its supposed to be. Consistent with Users Expectations: Function behavior is consistent with what we think users want. Consistent within Product: Function behavior is consistent with behavior of comparable f

5、unctions or functional patterns within the product. Consistent with Purpose: Function behavior is consistent with apparent purpose. 更多更好的思考Conjecture and Refutation: reasoning without certainty. 懷疑、駁斥：大膽推理Adductive Inference: finding the best explanation among alternatives. 小心求證：在眾多解釋中選擇最合理的解釋Latera

6、l Thinking: the art of being distractible. 水平思考：發(fā)散性思維的藝術(shù)Forward-backward thinking: connecting your observations to your imagination. 正向、逆向思維：把你觀察到的和你想象的聯(lián)系起來Heuristics: applying helpful problem-solving short cuts. 啟發(fā)式的思維：問題解決的絕對有效途徑De-biasing: managing unhelpful short cuts. 去偏解：管理無效的路徑Pairing: two te

7、sters, one computer. 對比：兩個測試人員，一臺電腦Study other fields. Example: Information Theory. 學(xué)習(xí)其他領(lǐng)域，比如信息技術(shù)良好的技術(shù)背景對無線移動通信網(wǎng)絡(luò)知識,基本的網(wǎng)絡(luò)協(xié)議以及網(wǎng)絡(luò)工作原理 ,計(jì)算機(jī)知識, 甚至是攝影知識積累對于軟件測試都有很大的幫助掌握必要的軟件測試知識和軟件工程基本知識對于我們自身的提高也是大有裨益的掌握必要的軟件編程知識,對于深入測試, 編寫利用自動測試腳本，可以起到事半功倍的效果作為一名測試人員，盡管不能精通所有的知識，但要想做好測試工作，應(yīng)該盡可能地去學(xué)習(xí)更多的與測試工作相關(guān)的知識。 軟件測試的

8、目的軟件測試的目的從軟件開發(fā)者的角度出發(fā)，表明軟件產(chǎn)品中不存在錯誤的過程，驗(yàn)證該軟件達(dá)到要求，確立人們對軟件質(zhì)量的信心? 符合需求設(shè)計(jì)文檔的要求 ? 符合一些應(yīng)用標(biāo)準(zhǔn)的要求，比如不同國家的用戶不同的操作習(xí)慣和要求，項(xiàng)目工程中的可維護(hù)性、可測試性等要求 從用戶角度出發(fā)，暴露軟件中存在的錯誤和缺陷。從客戶的需求出發(fā)，從客戶的角度去看產(chǎn)品，客戶會怎么去使用這個產(chǎn)品，使用過程中會遇到什么樣的問題。只有這些問題都解決了，軟件產(chǎn)品的質(zhì)量才可以說是上去了軟件測試人員的任務(wù)和目標(biāo)軟件測試人員的任務(wù)和目標(biāo)盡量短的時間盡量多的發(fā)現(xiàn)Bug；衡量軟件的品質(zhì)；關(guān)注用戶的需求?？偟哪繕?biāo)是：確保軟件的質(zhì)量。軟件測試原則軟件

9、測試原則測試是需要設(shè)計(jì)的, 一個好的測試計(jì)劃和測試用例往往能達(dá)到事半功倍的效果。測試是一項(xiàng)具有很大創(chuàng)造性的工作，其工作量一點(diǎn)也不比軟件設(shè)計(jì)小。軟件測試的創(chuàng)造性主要表現(xiàn)在測試方案選擇、測試計(jì)劃制定、測試用例設(shè)計(jì)、測試結(jié)果的分析以及測試過程的管理等方面。應(yīng)當(dāng)把“盡早和不斷的測試”作為開發(fā)者的座右銘測試工作應(yīng)該由獨(dú)立的專業(yè)的軟件測試部門來完。一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系。對測試錯誤結(jié)果一定要有一個確認(rèn)的過程，一般有A測試出來的錯誤，一定要有一個B來確認(rèn)，嚴(yán)重的錯誤可以召開評審會進(jìn)行討論和分析。制定嚴(yán)格的測試計(jì)劃，并把測試時間安排的盡量寬松，不要希望在極短

10、的時間內(nèi)完成一個高水平的測試?；貧w測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多的錯誤出現(xiàn)的現(xiàn)象并不少見。妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。如何理解這句話卻仁者見仁，智者見智軟件測試原則軟件測試原則Good-enough原則：這是一種權(quán)衡投入產(chǎn)出比的原則，測試既不要不充分，也不要過分。不充分和過分都是一種不負(fù)責(zé)任的表現(xiàn)。Zero-bug是一種理想，Good-enough是我們的原則。Pareto原則：一般情況下，在分析、設(shè)計(jì)、實(shí)驗(yàn)階段的復(fù)審和測試工作能夠發(fā)現(xiàn)和避免80的bug，而系統(tǒng)的軟件測試能夠找出其余bug中的80。最后約5%的bug只有在

11、用戶大范圍、長時間的使用后才會暴露出來。因此測試只能保證盡可能多地發(fā)現(xiàn)錯誤，不能保證發(fā)現(xiàn)所有的錯誤。徹底的測試是不可能的。在測試中不可能窮舉所有的路徑，但充分覆蓋程序邏輯，并確保軟件的所有條件是有可能的所有的測試都應(yīng)追溯到用戶需求。軟件測試的目的在于揭示錯誤，而最嚴(yán)重的錯誤（從用戶角度看）是那些導(dǎo)致程序無法滿足需求的錯誤軟件測試效率的幾點(diǎn)建議軟件測試效率的幾點(diǎn)建議首先測試程序的核心功能，然后測試輔助功能。 首先測試功能，然后測試性能。 首先測試常見情況，然后測試異常情況。 首先測試經(jīng)過變更的部分，然后測試沒有變更的部分。 首先測試影響大的問題，然后測試影響小的問題。 首先測試必須測試的部分，然

12、后測試可選或沒有要求測試的部分 軟件測試測略軟件測試測略1. Release Test (又名又名BVT Build Verification Test )Purpose: 測試手機(jī)的基本功能是否實(shí)現(xiàn)，是否有進(jìn)一步測試的必要性Attention: Release Test的Test Case具有一定的典型性，主要是反映手機(jī)最基本功能的Test Case本類測試只需要依據(jù)Test Case進(jìn)行測試，不需要進(jìn)一步發(fā)揮如果有發(fā)現(xiàn)與Case無關(guān)的Error, 在測試通過后才可以填報Error Report此類測試有一門檻值，即Test Case的Pass率達(dá)到一定值（如95%）才能宣布版本發(fā)布成功，進(jìn)

13、入進(jìn)一步的測試，否則此版本無效。除了門檻值外，如果重要功能模塊的Test Case沒通過，也會終止這個版本。2. System TestFull Round System TestPurpose對手機(jī)的所有功能進(jìn)行全面的測試(所有語言包) 由于Case不可能包含所有方面，所以測試時應(yīng)適度發(fā)揮，盡力完成全面測試 Common System Test (Medium or Minor)Attention: System Test一般分為兩個部分，“跑Case”和Free Test。 當(dāng)所有Test Case都測完后，就進(jìn)入Free Test期間。這里的Free Test具有明確的目的性和范圍。一般

14、來說，這段時間的Free Test只需要測自己負(fù)責(zé)的模塊。而且Free Test還負(fù)責(zé)重現(xiàn)前期“跑Case”是遺留的不可重現(xiàn)的Error。 在測試初期，一般只需要按照Test Case測，把一些不可重現(xiàn)的Error都記錄下來。同時遇到Test Case的問題或者不充分，應(yīng)該立即解決（和Team Leader或者Special List討論，補(bǔ)寫Test Case）。在這一階段結(jié)束后，一般要寫一個Summary Report。把這一階段的測試結(jié)果和遇到的問題、自己的見解都寫在里面（當(dāng)然是用English）。3. Focus TestPurpose: 集中于一個或幾個點(diǎn)進(jìn)行測試(同System T

15、est) 軟件測試策略軟件測試策略4 Stress Test Purpose:為了解決市場上發(fā)現(xiàn)的重大Error，而進(jìn)行的有針對性的強(qiáng)度測試主要是利用邊緣測試（臨界測試）手段Attention: 壓力測試，顧名思義，是給手機(jī)施加一定壓力，從而找出手機(jī)軟件上的Error。一般來說，對手機(jī)施加的壓力主要有：存儲壓力：由于手機(jī)采用的是棧式存儲，所以當(dāng)一個存儲塊滿了之后，如果程序員不做相應(yīng)處理或者處理不好的話，很容易造成其他存儲區(qū)被擦除，從而在UI上出現(xiàn)問題（其他功能無法正常使用）。邊界壓力：邊界一直是程序員最容易忽略的地方。響應(yīng)能力壓力：有時候某個操作可能處理的時間很長，在處理期間如果測試者再不斷地

16、進(jìn)行其他操作的話，很容易出現(xiàn)問題。網(wǎng)絡(luò)流量壓力（如在接電話時進(jìn)行短信服務(wù)）等等。n 在項(xiàng)目中，Stress Test有時也會用來重現(xiàn)不可重現(xiàn)的Error。由于有不少不可重現(xiàn)的Error是由于Memory Leak(內(nèi)存泄漏)引起的，所以不停的重復(fù)同一個操作是重現(xiàn)一個不可重現(xiàn)的Error的一個好方法5. Free TestPurpose:測試System Test中沒有做完的不可重現(xiàn)Error尋找平時沒有找到的忽略的ErrorAttention:在System Test階段所用的Free Test具有明顯的目的性和范圍平時的Free Test從理論上應(yīng)該對所測試的范圍窮盡所有的測試方法。但是，這

17、是不現(xiàn)實(shí)的。在實(shí)際項(xiàng)目中，主要有兩個方面是Free Test所需要重視的。從UI Spec上找靈感。應(yīng)為Test Case是依據(jù)UI Spec寫的，所以從UI Spec上突破是一個行之有效的方法。UI Spec有一定的探索深度，加大探索深度，是一種突破的途徑；另外同一個功能用其他不同的方法去實(shí)現(xiàn)，也是一種突破途徑。多關(guān)注不同F(xiàn)eature之間的Interaction。這是手機(jī)軟件相對比較容易出問題，而Test Case又很少能反映的地方。這是一個很大的Free Test空間軟件測試的基本過程軟件測試的基本過程一個規(guī)范化的軟件測試過程通常須包括以下基本的測試活動。擬定軟件測試計(jì)劃編制軟件測試大綱

18、設(shè)計(jì)和生成測試用例實(shí)施測試生成軟件問題報告 對整個測試過程進(jìn)行有效的管理實(shí)際上,軟件測試過程與整個軟件開發(fā)過程基本上是平行進(jìn)行的。測試計(jì)劃早在需求分析階段即應(yīng)開始制定,其它相關(guān)工作,包括測試大綱的制定、測試數(shù)據(jù)的生成、測試工具的選擇和開發(fā)等也應(yīng)在測試階段之前進(jìn)行。充分的準(zhǔn)備工作可以有效地克服測試的盲目性,縮短測試周期,提高測試效率,并且起到測試文檔與開發(fā)文檔互查的作用。軟件測試的基本流程軟件測試的基本流程(1)測試工程師的工作流程，與公司的整體工作流程，項(xiàng)目的測試要求等因素相關(guān)。本文主要討論測試工程師的一般工作流程。 做好測試準(zhǔn)備 1) 明確測試任務(wù)的范圍 測試文檔通常包括測試目的、測試環(huán)境、

19、測試方法、測試用例、測試工具等。測試工程師首先要通讀文檔，對整個測試要求形成整體認(rèn)識，明確測試目的，以及測試要求和測試重點(diǎn)，明確軟件測試方法和使用的測試工具。 2) 明確測試時間 明確測試周期和測試時間進(jìn)度。如果是多人合作完成一個軟件，則要首先明確屬于自己的測試內(nèi)容、根據(jù)測試內(nèi)容和測試周期，估算自己每日應(yīng)該完成的工作量。此外由于軟件測試是群體協(xié)作的測試活動，需要明確哪些測試內(nèi)容要與其他測試工程師協(xié)作才能完成。 3) 設(shè)置測試環(huán)境 根據(jù)測試文檔要求，設(shè)置測試需要的軟件和硬件環(huán)境，包括操作系統(tǒng)，要測試的軟件和其他必要的測試工具軟件等。所有這些完成后，分別運(yùn)行，查看是否能正確運(yùn)行，保證符合測試文檔要

20、求的測試環(huán)境。 4) 學(xué)習(xí)被測試軟件 對于不太熟悉的軟件，可以通過閱讀軟件自身的教程和幫助文件，學(xué)習(xí)本軟件的一般操作方法，也可以參照相關(guān)的書籍資料等。另外，向熟悉測試軟件的其他同事請教軟件使用方法，也是學(xué)習(xí)軟件的一條捷徑。對軟件使用越熟練，測試過程越順利，測試效果越理想。 5) 確認(rèn)完全理解測試任務(wù) 軟件測試最重要的要求就是確實(shí)明確了測試任務(wù)和要求，這包括正確理解了測試文檔，確認(rèn)可以按照測試進(jìn)度要求，完成測試。對于測試工具要正確安裝，熟練使用。如果有任何不明白之處，向軟件測試負(fù)責(zé)人詢問。切忌憑自己的理解和主觀推測，自行其事。當(dāng)然，真正測試中，往往會遇到各種新的小疑難問題，也需要及時向測試負(fù)責(zé)人

21、請教，以保證測試順利進(jìn)行。 軟件測試的基本流程軟件測試的基本流程(2)執(zhí)行軟件測試任務(wù) 1) 按照測試文檔要求，逐項(xiàng)認(rèn)真測試 根據(jù)測試文檔測試要求，按照測試步驟，逐項(xiàng)進(jìn)行。通過運(yùn)行軟件，觀察測試結(jié)果，與軟件需求說明書的內(nèi)容進(jìn)行比較，找出軟件錯誤。對于需要調(diào)用測試用例的測試，保證正確地調(diào)用了測試用例，注意觀察和分析測試結(jié)果。某些不容易重復(fù)的錯誤，需要反復(fù)測試，總結(jié)重復(fù)該錯誤所需要的測試步驟，直到確認(rèn)可以重復(fù)出現(xiàn)為止。 2) 記錄發(fā)現(xiàn)的錯誤，填寫軟件問題報告 為了糾正軟件中的錯誤，測試工程師要正確記錄發(fā)現(xiàn)的錯誤，將錯誤再現(xiàn)的步驟寫入測試報告中，測試報告是程序測試的重要組成部分，正確書寫測試報告是對

22、測試工程師的基本要求。采用軟件缺陷數(shù)據(jù)庫管理測試中發(fā)現(xiàn)的軟件缺陷，每一條錯誤作為數(shù)據(jù)庫的一條記錄，方便記錄、修改、查詢。 3) 填寫測試進(jìn)度表和必要的測試內(nèi)容記錄表 每天將測試內(nèi)容寫入測試進(jìn)度表文檔，可以使測試負(fù)責(zé)人了解測試進(jìn)度，控制測試周期內(nèi)測試的連續(xù)性，增強(qiáng)測試過程控制性，保證測試的正常進(jìn)行。測試記錄要準(zhǔn)確完整，實(shí)事求是，必要時插入測試注釋，解釋測試中的特殊問題。測試進(jìn)度表是評價測試質(zhì)量和工作內(nèi)容的重要憑證，對于測試后發(fā)現(xiàn)的測試錯誤和失誤，可以通過檢查測試記錄，尋找產(chǎn)生錯誤的原因。 4) 測試中發(fā)現(xiàn)疑難及時請教 測試是一個動態(tài)的過程，可能由于自己的錯誤操作或者測試文檔內(nèi)容的錯誤，使得測試過

23、程中出現(xiàn)自己不能解釋的現(xiàn)象或結(jié)果，出現(xiàn)與測試要求不符合的情形，這時可能需要與其他測試者協(xié)商或求助，如果問題仍然不能解決，應(yīng)該及時請教，聽取意見和建議，必要時反復(fù)討論直到問題全面解決。 全面檢查測試結(jié)果 1) 對照測試文檔要求，檢查測試內(nèi)容是否完整 測試完成后，要對照測試文檔檢查測試是否全部完成，保證沒有丟失測試內(nèi)容。如果某些內(nèi)容，由于測試環(huán)境的要求不滿足，或者由于測試時間短沒有進(jìn)行，則要寫入測試進(jìn)度表文檔。 2) 檢驗(yàn)書寫的軟件問題報告的記錄，使之確切、規(guī)范 正確書寫測試記錄是保證迅速定位軟件錯誤，加快改正錯誤的必要前提。專業(yè)規(guī)范的軟件記錄報告是體現(xiàn)公司測試水平和專業(yè)實(shí)力的外在體現(xiàn)。認(rèn)真檢查書

24、寫的每條記錄是否符合規(guī)范，格式、步驟、內(nèi)容一一檢查，必要時補(bǔ)充或刪減。 上述三個階段，相互聯(lián)系緊密，其中準(zhǔn)備是基礎(chǔ)，測試是重點(diǎn)，檢查是保證，應(yīng)該根據(jù)測試的軟件特點(diǎn)合理安排軟件測試配置軟件配置管理：軟件需求規(guī)格說明書，設(shè)計(jì)規(guī)格說明書，源代碼等管理。（Rational Clear Case/ Clear Quest）測試配置工具：測試計(jì)劃，測試用例，測試程序等。（VSS）測試工具：測試數(shù)據(jù)自動生成程序，靜態(tài)分析程序，動態(tài)分析程序，測試結(jié)果分析程序，以及驅(qū)動測試的測試數(shù)據(jù)庫， 自動測試工具（Winrunner）其他測試工具 ? Log工具QXDM/QPST/VPST/ETS? 電流測試工具? Now

25、 SMS （可以測試GSM SMS, WAP PUSH,MMS notification 等）? Helix server流媒體測試? Apache WAP server? WSFTP_Pro2006B20050511.exe 流量監(jiān)控? 聲音格式轉(zhuǎn)換工具? 第三方定位工具軟件測試內(nèi)容軟件測試不等于程序測試，軟件測試應(yīng)貫串于軟件定義和開發(fā)地整個期間。需求分析，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明，概要設(shè)計(jì)規(guī)格說明，詳細(xì)設(shè)計(jì)規(guī)格說明以及源程序，都可以成為軟件測試的對象。? 為把握軟件開發(fā)各個環(huán)節(jié)地正確性，需要進(jìn)行各種確認(rèn)和驗(yàn)證。? 確認(rèn)：是一系列的活動和過程，目的

26、是想證實(shí)在一個給定的外部環(huán)境中軟件的邏輯正確性。? 驗(yàn)證：試圖證明在軟件生存期各個階段，以及階段間的邏輯協(xié)調(diào)性，完備性和正確性。對于我們的軟件測試， 不僅僅包括手機(jī)軟件，配套光盤軟件，還應(yīng)該包括：說明書等的測試，需求評審等手機(jī)界面測試技巧手機(jī)界面測試技巧界面風(fēng)格是否一致，美觀（比如左右軟鍵/菜單風(fēng)格）名稱是否統(tǒng)一(比如說UIM/SIM,電話本/聯(lián)系人)字體大小、風(fēng)格是否統(tǒng)一是否有錯別字鍵盤操作是否正常（功能鍵、快捷鍵,長按、短按、連續(xù)按）屏幕顯示是否正常，是否有重疊、切字、亂碼（在不同的語言下，快速切換）手機(jī)交互測試技巧手機(jī)交互測試技巧是各功能不同事件下的處理以矩陣交互表格方式描述用例多重事件

27、可以選擇一些資源消耗大的場景選擇性展開兼容性測試驗(yàn)證手機(jī)對部分外部設(shè)備的兼容情況,包括SIM卡，T卡，藍(lán)牙設(shè)備也可以是其他手機(jī)傳送過來的內(nèi)容,比如說SMS, MMS, vCard, vcalendar否定測試（負(fù)面測試）在開發(fā)過程中，正常業(yè)務(wù)處理的代碼量只占有效代碼量的 10% ，而例外處理的代碼量要占有效代碼量的 90% 人們也可以通過經(jīng)驗(yàn)或直覺推測系統(tǒng)中可能存在的各種錯誤，從而有真對性地編寫檢查這些錯誤的例子，這就是錯誤推測法。錯誤推測法沒有確定的步驟，很大程度上是憑經(jīng)驗(yàn)進(jìn)行的。手機(jī)性能測試技巧手機(jī)性能測試技巧1 時間相關(guān)。時間相關(guān)。?時間相關(guān)的性能測試可分為長時間保持測試和限定時間反應(yīng)測

28、試。?長時間保持測試主要是測試終端長時間穩(wěn)定進(jìn)行某項(xiàng)功能的能力。主要包括長時間待機(jī)能力、長時間CS域業(yè)務(wù)保持能力、長時間PS域業(yè)務(wù)保持能力、長時間組合業(yè)務(wù)保持能力等。?長時間待機(jī)測試，就是根據(jù)手機(jī)電池的能力連續(xù)不間斷待機(jī)一定時間（例如4天），之后驗(yàn)證手機(jī)是否還能夠發(fā)起主叫和被叫業(yè)務(wù)，能夠發(fā)起主叫，表示終端在長時間待機(jī)后自身還處于正常狀態(tài)，能夠發(fā)起被叫，說明終端在睡眠模式下可以正常接收尋呼。?長時間CS域業(yè)務(wù)保持測試，就是根據(jù)手機(jī)電池的能力連續(xù)不間斷進(jìn)行語音通話或者視頻通話一定時間（例如2小時），測試通話期間圖象聲音是否連續(xù)、清晰，是否有單通現(xiàn)象出現(xiàn)，是否會有手機(jī)板子過熱現(xiàn)象。?長時間PS域業(yè)務(wù)

29、保持測試，主要是通過持續(xù)進(jìn)行WWW業(yè)務(wù)、ftp業(yè)務(wù)或者流媒體業(yè)務(wù)一定時間（例如2小時），測試進(jìn)行數(shù)據(jù)業(yè)務(wù)期間上下行數(shù)據(jù)傳輸率是否穩(wěn)定，網(wǎng)頁顯示是否流暢，流媒體播放是否連續(xù)等。長時間組合業(yè)務(wù)保持測試，就是同時保持CS和PS域業(yè)務(wù)一段時間，以驗(yàn)證終端長時間進(jìn)行組合業(yè)務(wù)的能力。?限定時間反應(yīng)測試主要是測試終端在規(guī)定時間內(nèi)對用戶的操作作出反應(yīng)，給出操作結(jié)果的能力。主要包括開機(jī)駐留時延、關(guān)機(jī)時延、CS域業(yè)務(wù)接入時延、PS域業(yè)務(wù)接入時延、本地應(yīng)用的操作時延等。?開機(jī)駐留時延，是指從用戶按下開機(jī)鍵（終端上電、系統(tǒng)引導(dǎo)、啟動任務(wù)、搜索網(wǎng)絡(luò)、完成位置更新）到終端進(jìn)入待機(jī)界面，提示用戶可以進(jìn)行正常服務(wù)的總時間。?

30、關(guān)機(jī)時延，是指從用戶按下關(guān)機(jī)鍵（終端完成網(wǎng)絡(luò)detach、將RAM中修改過的數(shù)據(jù)寫回flash）到終端完全下電所需的總時間。?CS域業(yè)務(wù)接入時延，是指在進(jìn)行語音或視頻電話時從按下?lián)芴栨I到聽到對方回鈴聲所需總時間，由于該過程需要在網(wǎng)絡(luò)側(cè)分配資源，所以測試結(jié)果可能會受到當(dāng)前網(wǎng)絡(luò)資源可用程度的影響，例如在網(wǎng)絡(luò)負(fù)荷高的時候申請CS 64k業(yè)務(wù)時，網(wǎng)絡(luò)側(cè)需要重新組織或合并無線資源來滿足業(yè)務(wù)要求，所需時間相對會長一些。?PS域業(yè)務(wù)接入時延，是指在進(jìn)行數(shù)據(jù)業(yè)務(wù)時從開始連接到能正常進(jìn)行數(shù)據(jù)業(yè)務(wù)所需總時間。本地應(yīng)用的操作時延，是指完成某些本地操作維護(hù)功能所需的時間，例如打開電話薄，在電話薄里查找聯(lián)系人，存儲新建

31、的聯(lián)系人，存儲短信，存儲多媒體文件，打開瀏覽器，播放多媒體文件等所需時延，這些時延如果過長，也會極大地降低用戶體驗(yàn)的滿意度。手機(jī)性能測試技巧手機(jī)性能測試技巧 2 次數(shù)相關(guān)次數(shù)相關(guān)? 次數(shù)相關(guān)的性能測試是測試終端重復(fù)穩(wěn)定地進(jìn)行某項(xiàng)功能的能力。?包括開關(guān)機(jī)成功率、小區(qū)初搜成功率、小區(qū)重選成功率、CS域業(yè)務(wù)成功率、PS域業(yè)務(wù)成功率、組合業(yè)務(wù)成功率、切換成功率、本地應(yīng)用的成功率等。這種重復(fù)操作包括很多對象被多次創(chuàng)建和釋放，因此可能會發(fā)現(xiàn)潛在的內(nèi)存泄漏等問題。?開關(guān)機(jī)成功率測試，主要是檢驗(yàn)多次開機(jī)是否會有物理層不能正確收到初搜命令的情況，關(guān)機(jī)不完全也可能會導(dǎo)致下一次開機(jī)失敗，以及在某些情況下系統(tǒng)死機(jī)后只

32、能通過插拔電池板來重新開機(jī)。?CS域業(yè)務(wù)成功率的測試，是指通過進(jìn)行一定次數(shù)的主叫或者被叫，統(tǒng)計(jì)失敗的次數(shù)，對失敗原因進(jìn)行歸類，分析是否能夠找到和終端相關(guān)的失敗原因。PS域業(yè)務(wù)成功率、組合業(yè)務(wù)成功率、切換成功率的測試方法也類似。?本地應(yīng)用的成功率包括多次存儲再刪除文件、聯(lián)系人、短信等操作，以及多次打開某個應(yīng)用或執(zhí)行某類操作來對該應(yīng)用的穩(wěn)定性進(jìn)行測試，找出瓶頸。3 并發(fā)業(yè)務(wù)并發(fā)業(yè)務(wù)?并發(fā)測試主要是測試終端同時進(jìn)行多項(xiàng)業(yè)務(wù)時表現(xiàn)出的處理能力。?例如同時進(jìn)行CS域語音業(yè)務(wù)和PS域下載業(yè)務(wù)，或者在MP3播放的同時進(jìn)行WWW上網(wǎng)業(yè)務(wù)，以測試協(xié)議棧、操作系統(tǒng)和處理器對并發(fā)業(yè)務(wù)的支持能力。 4 負(fù)載測試負(fù)載測

33、試?負(fù)載測試主要是驗(yàn)證系統(tǒng)的負(fù)載工作能力。?系統(tǒng)配置不變的條件下，在一定時間內(nèi)，終端在高負(fù)載情況下的性能行為表現(xiàn)。?例如同時進(jìn)行多個ftp下載，使下行傳輸率接近極限值，觀察終端是否可以正常工作。需求及文檔評審技巧需求及文檔評審技巧(1)IEEE認(rèn)為好的需求規(guī)格說明應(yīng)該達(dá)到以下標(biāo)準(zhǔn)：正確：每項(xiàng)需求都反映了一種需要。完整：包含了所有必要的需求。無歧義：各方在需求的含義上意見一致。一致：所有部分都相符，如E/R模型與事件清單相符。確定重要性、穩(wěn)定性的等級：每項(xiàng)需求的優(yōu)先級以及預(yù)期的修改。可更改：易于修改且保持一致性?？沈?yàn)證：能夠檢查是否滿足了需求。可追蹤：由需求至目標(biāo)/目的，至設(shè)計(jì)/代碼。其它：可由

34、目標(biāo)追蹤至需求；能為客戶、開發(fā)人員所理解。需求及文檔評審技巧需求及文檔評審技巧(2)1、兼容性 界面需求是否使軟硬件系統(tǒng)具有兼容性？2、完備性 需求定義是否包含了有關(guān)文件（指質(zhì)量手冊、質(zhì)量計(jì)劃以及其他有關(guān)文件）中所規(guī)定的需求定義所應(yīng)該包含的所有內(nèi)容？ 需求定義是否包含了有關(guān)功能、性能、限制、目標(biāo)、質(zhì)量等方面的所有需求？ 功能性需求是否覆蓋了所有非正常情況的處理？ 是否已對各種操作模式（如正常、非正常、有干擾等）下的環(huán)境條件都作規(guī)定？ 是否識別出了所有與時間因素有關(guān)的功能？它們的時間準(zhǔn)則是否都明了？時間準(zhǔn)則的最大、最小執(zhí)行時間是否都定義了？ 是否識別定義了在將來可能會變化的需求？ 是否定義了系統(tǒng)

35、的所有輸入？ 是否標(biāo)識清楚了系統(tǒng)輸入的來源？ 是否識別了系統(tǒng)的輸出？ 是否說明了系統(tǒng)輸入、輸出的類型？ 是否說明了系統(tǒng)輸入、輸出的值域、單位、格式等？ 是否說明了如何進(jìn)行系統(tǒng)輸入的合法性檢查？ 是否定義了系統(tǒng)輸入、輸出的精度？ 在不同負(fù)載情況下，系統(tǒng)的生產(chǎn)率如何？ 在不同的情況下，系統(tǒng)的響應(yīng)時間如何？ 系統(tǒng)對軟件、硬件或電源故障必須作什么樣的反應(yīng)？ 是否充分定義了關(guān)于人機(jī)界面的需求？需求及文檔評審技巧需求及文檔評審技巧(2)3、一致性 各個需求之間是否一致？是否有沖突和矛盾？ 所規(guī)定的模型、算法和數(shù)值方法是否相容？ 是否使用了標(biāo)準(zhǔn)術(shù)語和定義形式？ 需求是否與其軟硬件操作環(huán)境相容？ 是否說明了軟

36、件對其系統(tǒng)和環(huán)境的影響？ 是否說明了環(huán)境對軟件的影響？4、正確性 需求定義是否滿足標(biāo)準(zhǔn)的要求？ 算法和規(guī)則是否有科技文獻(xiàn)或其它文獻(xiàn)作為基礎(chǔ)？ 有哪些證據(jù)說明用戶提供的規(guī)則或規(guī)定是正確的？ 是否定義了對在錯誤、危險分析中所識別出的各種故障模式和錯誤類型所需的反應(yīng)？ 是否參照了有關(guān)標(biāo)準(zhǔn)？ 是否對每個需求都給出了理由？理由是否充分？ 對設(shè)計(jì)和實(shí)現(xiàn)的限制是否都有論證？5、可行性 需求定義是否使軟件的設(shè)計(jì)、實(shí)現(xiàn)、操作和維護(hù)都可行？ 所規(guī)定的模式、數(shù)值方法和算法是否對待解問題合適？是否能夠在相應(yīng)的限制條件下實(shí)現(xiàn)？ 是否能夠達(dá)到關(guān)于質(zhì)量的要求？需求及文檔評審技巧需求及文檔評審技巧(3)6、易修改性 對需求定

37、義的描述是否易于修改？例如是否采用良好的結(jié)構(gòu)和交叉引用表等等？ 是否有冗余的信息？是否一個需求被定義多次？7、健壯性 是否有容錯的需求？8、易追溯性 是否可以從上一階段的文檔查找到需求定義中的相應(yīng)內(nèi)容？需求定義是否明確地表明前階段中提出的有關(guān)需求的設(shè)計(jì)限制都已被覆蓋？ 例如，使用覆蓋矩陣或交叉引用表？ 需求定義是否便于向后繼開發(fā)階段查找信息？9、易理解性 是否每一個需求都只有一種解釋？ 功能性需求是不是以模塊方式描述的，是否明確地標(biāo)識出其功能？ 是否使用了形式化或半形式化的語言？ 語言是否有歧義性？ 需求定義是否只包含了必要的實(shí)現(xiàn)細(xì)節(jié)而不包含不必要的實(shí)現(xiàn)細(xì)節(jié)？是否過分細(xì)致了？ 需求定義是否足夠

38、清楚和明確使其已能夠作為開發(fā)設(shè)計(jì)規(guī)約和功能性測試數(shù)據(jù)基礎(chǔ)？ 需求定義的描述是否將對程序的需求和所提供的其它信息分離開來?10、易測試性和可驗(yàn)證性 需求是否可以驗(yàn)證？ 是否對每一個需求都指定了驗(yàn)證過程？ 數(shù)學(xué)函數(shù)的定義是否使用了精確定義的語法和語法符號？本地化測試技巧本地化測試技巧(1)本地化軟件的錯誤類別，可以歸結(jié)為四種類型：翻譯錯誤，功能錯誤，界面錯誤，雙字節(jié)錯誤 翻譯錯誤：產(chǎn)生原因： ?1) 翻譯人員不熟悉翻譯要求。 ?2) 翻譯人員工作疏漏。 ?3) 用戶界面的翻譯與標(biāo)準(zhǔn)詞匯表不一致。表現(xiàn)特征：?1) 應(yīng)該翻譯而沒有翻譯的英文字符。?2) 不應(yīng)該翻譯而翻譯的中文字詞。 ?3) 錯誤翻譯的

39、字詞。 ?4) 只在本地化版本中存在該類型錯誤。 ?5) 較多隱含在對話框各控件以及幫助文檔中。 測試要求： ?1) 明確需要翻譯和不需要翻譯的內(nèi)容。 ?2) 明確正確的翻譯方式。 ?3) 根據(jù)術(shù)語表，確認(rèn)術(shù)語翻譯的正確性與一致性。 測試方法：?1) 主要同時打開中英文版本，執(zhí)行相同的操作。?2) 結(jié)合標(biāo)準(zhǔn)界面詞匯翻譯表，參照對比。說明： ?1) 對于對話框，如果含有下拉列表框，要打開列表框查看全部項(xiàng)。 ?2) 特別要注意選項(xiàng)中開關(guān)類翻譯錯誤。本地化測試技巧本地化測試技巧(2)功能錯誤：功能錯誤：產(chǎn)生原因： 1) 軟件編碼錯誤。 2) 錯誤本地化，如將程序中的變量進(jìn)行了翻譯等。 表現(xiàn)特征： 1

40、) 不能實(shí)現(xiàn)設(shè)計(jì)要求的功能 2) 產(chǎn)生與設(shè)計(jì)要求不符合的結(jié)果。 3) 英文和中文都存在同樣的錯誤。 4) 可能隱含在軟件的任何位置或任何操作步驟中。 測試要求： 1) 保證輸入數(shù)據(jù)正確，或者打開了正確的測試用例。 2) 明確正確的輸出結(jié)果和中間數(shù)據(jù)數(shù)值及格式。 測試方法： 1) 對于菜單項(xiàng)或工具欄按鈕，通過全面測試各個選項(xiàng)，認(rèn)真觀察每一步是否正確執(zhí)行，輸出結(jié)果（包括格式和數(shù)值）是否正確。 2) 對于一個命令中的多個并列選項(xiàng)，采用路徑跟蹤法，按分支順序測試嵌套的全部子項(xiàng)。 3) 對于對話框，可以逐個執(zhí)行各按鈕，各個列表選項(xiàng)等觀察執(zhí)行結(jié)果。 說明： 1) 特別注意不同選項(xiàng)、不同按鈕相互操作的影響。

41、 2) 注意檢查快捷鍵是否遺漏，是否多余，是否不同，是否起作用。本地化測試技巧本地化測試技巧(3)布局錯誤：布局錯誤：產(chǎn)生原因： 1) 軟件本地化后，由于源語言和本地化語言的表達(dá)方式不同，本地化后的字符數(shù)與源語言不同，每個字符所占空間尺寸不同，使得在英文版本正確顯示的控件字符，可能在本地化版本顯示不正確。 2) 本地化人員調(diào)整程序資源不當(dāng)引起，例如，對話框及其控件高度或?qū)挾鹊牟徽_調(diào)整。 表現(xiàn)特征： 1) 控件相互重疊或排列不均勻。 2) 控件中字符顯示不完整。 3) 主要出現(xiàn)在本地化版本的對話框中。 測試要求： 1) 對話框中控件布局均勻，字符顯示完整正確 2) 對話框中控件數(shù)量相等，沒有多

42、余或丟失的控件 測試方法： 1) 執(zhí)行將要打開對話框的菜單或工具欄按鈕，觀察打開對話框中的控件布局。 2) 對比檢查源語言軟件和本地化軟件對應(yīng)的對話框中控件的數(shù)量 說明： 1) 可能在執(zhí)行不同的操作后，如選擇了不同菜單或選按鈕后，編輯框顯示重疊等。 2) 執(zhí)行后帶省略號的菜單或命令按鈕，將會顯示對話框。 本地化測試技巧本地化測試技巧(4)雙字節(jié)錯誤雙字節(jié)錯誤：產(chǎn)生原因： 1) 源程序在設(shè)計(jì)時沒有考慮雙字節(jié)語言的支持。 2) 軟件本地化后，單字節(jié)字符向雙字節(jié)字符轉(zhuǎn)化過程中，由于單字節(jié)和雙字節(jié)之間的差別，可能使得某些本地化后的雙字節(jié)字符的顯示亂碼。 3) 軟件本地化后，對程序中控制符號如換行鍵“n

43、”的處理錯誤而引起亂碼。 表現(xiàn)特征： 1) 控件或?qū)υ捒蛑酗@示不可辯識的字符。 2) 控件或?qū)υ捒蛑酗@示無意義的明顯錯誤的字符。 3) 不支持雙字節(jié)字符的輸入，包括雙字節(jié)的文件名和路徑名。 4) 僅出現(xiàn)在本地化后的版本中。測試要求： 1) 本地化后的軟件字符顯示正確完整，無亂碼或明顯錯別字。 測試方法： 1) 執(zhí)行菜單或按鈕，檢查對話框中的字符。 2) 打開幫助文檔，檢查所有需要翻譯的字符。 說明： 1) 注意檢查對話框下拉列表中需要拖動滾動條才能顯示的內(nèi)容。 手機(jī)場地測試基本技巧手機(jī)場地測試基本技巧1. Field Test（又稱路測、場測）主要是為了了解手機(jī)在現(xiàn)網(wǎng)環(huán)境下的真正使用情況而展開

44、一項(xiàng)測試，側(cè)重于網(wǎng)絡(luò)相關(guān)功能，可以說也是一種模擬最終用戶使用的測試。2. 場測任務(wù)展開的時間，主要是放在系統(tǒng)測試階段后期。在場測的前提條件滿足后（RF測試和無線靈敏度測試通過后，項(xiàng)目部可以向測試部經(jīng)理提交場測試申請，在獲得通過后，安排場測試。 3. 對于新平臺，正常情況下必須要安排場地測試，場測試結(jié)果將作為出場判定依據(jù)。4. 目前，場測分兩部分：PART A 與 PART B 這兩部分分別有所側(cè)重，A部分偏重?zé)o線與通訊方面的綜合測試。B部分，偏重與實(shí)網(wǎng)環(huán)境中各項(xiàng)網(wǎng)絡(luò)功能的測試。5. 產(chǎn)品上市后，如果平臺有通信相關(guān)的重大升級，測試負(fù)責(zé)人，必須安排重新安排場測。小概率問題處理小概率問題處理盡量發(fā)現(xiàn)

45、出現(xiàn)小概率問題的前提條件合理使用輔助測試工具,包括Trace, QXDM等盡量給出概率問題的概率討論討論手機(jī)測試?yán)帉懺瓌t手機(jī)測試?yán)帉懺瓌t熟悉需求,設(shè)計(jì),了解業(yè)務(wù)測試?yán)?guī)則清晰,明了.模塊劃分,測試?yán)帉懢哂休^強(qiáng)的通用性測試?yán)忻鞔_的測試目的,測試前提條件，優(yōu)先級別,預(yù)期結(jié)果測試?yán)帉懙脑敿?xì)程度應(yīng)該有限詳細(xì).? 有限詳細(xì)的定義：測試?yán)闹饕x者是測試人員，而不是所有人在測試中盡量避免使用操作某個按鍵出來什么結(jié)果的如果確實(shí)需要，盡量強(qiáng)調(diào)其測試的目的比如說，檢查對話框狀態(tài)下，左右軟鍵的顯示是否正常(居中顯示/字符串無切字/無拼寫錯誤）? 好的測試?yán)钠渌麕c(diǎn)要求能夠盡量的覆蓋典型的，常用的，

46、異常的場景盡量避免重復(fù)測試測試?yán)⒎窃蕉嘣胶?，測試?yán)臄?shù)量應(yīng)該是，盡可能的發(fā)現(xiàn)問題與盡可能的覆蓋功能的最小公倍數(shù)? 測試?yán)木帉懪c測試本身一樣，沒有最好，只有更好，是一個可以不斷完善的過程。手機(jī)測試?yán)帉懸笫謾C(jī)測試?yán)帉懸?. 準(zhǔn)確: 按所設(shè)計(jì)的去測試.對需求及設(shè)計(jì)理解準(zhǔn)確,理解軟件及功能特點(diǎn),積極設(shè)想軟件如何才能失敗,做到盡可能發(fā)現(xiàn)錯誤2.不冗余: 好的測試?yán)記]有不必要的步驟,每一個測試都應(yīng)該有不同的用途, 不會太簡單，也不會太復(fù)雜。通常每個測試?yán)龖?yīng)獨(dú)立執(zhí)行。多個測試?yán)M合，有可能屏蔽錯誤。最大操作步驟最好控制在10-15步之間,每個測試步驟應(yīng)該有一個清晰的輸入或者測試任務(wù),不排除單個

47、測試?yán)佑卸鄠€邏輯輸入,需要逐一列舉輸出結(jié)果.3.清晰: 描述清晰,步驟條理清晰,測試層次清晰(由簡而繁,從基本功能測試到破壞性測試).4.可復(fù)用: 無論何時何人測試都能得到同樣的結(jié)論,方便移植.5.可追溯性: 針對特定的需求測試.6.適 當(dāng): 測試?yán)龖?yīng)該適合特定的測試環(huán)境 以及符合整個團(tuán)隊(duì)的測試水平7.可維護(hù)性: 好的測試用例應(yīng)該是可維護(hù)的,維護(hù)包括添加,刪除,更改,特別是對應(yīng)需求及功能等變更的維護(hù).象代碼一樣,不需要維護(hù)的測試?yán)遣淮嬖诘?在變更過程中未做維護(hù)的測試?yán)龑⑹ニ鼞?yīng)有價值,甚至帶來危害.備注: 以上內(nèi)容來自毛宏才怎樣編寫高質(zhì)量測試用例設(shè)計(jì)測試用例應(yīng)注意的事項(xiàng)設(shè)計(jì)測試用例應(yīng)注意的

48、事項(xiàng) 不僅要選用合理的輸入數(shù)據(jù)作為測試用例（即肯定測試用例），還應(yīng)選用不合理的輸入數(shù)據(jù)作為測試用例（即否定測試用例）。許多人往往只注意前者而忽略了后者。為了提高系統(tǒng)的健壯性，輸入數(shù)據(jù)不合理的各種情況是應(yīng)該認(rèn)真檢查的（在開發(fā)過程中，正常業(yè)務(wù)處理的代碼量只占有效代碼量的 10% ，而例外處理的代碼量要占有效代碼量的 90% ），所以測試工作量也是如此，即肯定測試用例占總用例的 10% ，否定測試用例占總用例的 90% ）。除了檢查系統(tǒng)是否做了它應(yīng)該做的工作之外，還應(yīng)檢查系統(tǒng)是否做了它不應(yīng)該做的事情。應(yīng)該長期保留所有的測試用例，直至這個系統(tǒng)被廢棄不用為止。這是因?yàn)椋涸O(shè)計(jì)測試用例是很費(fèi)人工的，如果將用

49、過的測試用例丟棄了，以后一旦需要再測試這個系統(tǒng)（例如因?yàn)橄到y(tǒng)內(nèi)部作了某些修改）就需要再花很多人工，人們往往懶得再次認(rèn)真地設(shè)計(jì)測試用例，因而“再測試”很少像初次測試那樣“徹底”。如果系統(tǒng)的修改使得前面已測試過的部分產(chǎn)生了錯誤，“再測試”往往就不能發(fā)現(xiàn)這些錯誤。設(shè)計(jì)測試用例方法設(shè)計(jì)測試用例方法 白盒法白盒法 白盒法是以系統(tǒng)內(nèi)部的邏輯為基礎(chǔ)設(shè)計(jì)測試用例，所以又稱為邏輯覆蓋法。白盒法考慮的是測試用例對系統(tǒng)內(nèi)部的覆蓋程度，最徹底的白盒法是覆蓋系統(tǒng)中的每條路徑，但是由于系統(tǒng)中一般含有循環(huán)，所以路徑的數(shù)目極大，要執(zhí)行每條路徑是不可能的，所以只能希望覆蓋的程度盡可能高些。我們可以從以下幾點(diǎn)考慮：（ 1 ）語句

50、覆蓋 “語句覆蓋”是一個很弱的測試覆蓋，它的含義是：選擇足夠的測試用例，使代碼中每個有效語句（即注釋語句除外）至少都能被執(zhí)行一次。順序語句覆蓋率是 100% 。（ 2 ）分支覆蓋 比“語句覆蓋”稍強(qiáng)的測試覆蓋是“分支覆蓋”。這個標(biāo)準(zhǔn)是執(zhí)行足夠的測試用例，使代碼中每個分支至少都獲得一次“真”值和“假”值，或者說使得代碼中的每個分支至少都通過一次。分支覆蓋率是 80% 。（ 3 ）循環(huán)覆蓋 “循環(huán)覆蓋”的含義是：執(zhí)行足夠的測試用例，使得循環(huán)中的每個條件都得到驗(yàn)證。循環(huán)語句覆蓋率是 80% 。設(shè)計(jì)測試用例方法設(shè)計(jì)測試用例方法 黑盒法黑盒法 設(shè)計(jì)測試用例的另一種方法是黑盒法。與白盒法不同，黑盒法不關(guān)心

51、系統(tǒng)內(nèi)部的邏輯，而只是根據(jù)系統(tǒng)的功能說明、預(yù)期結(jié)果、數(shù)據(jù)流程或業(yè)務(wù)流程等來設(shè)計(jì)測試用例。黑盒法測試的依據(jù)是需求說明書或功能說明書。我們常常采用的方法是A 、劃分等價類 B 、 邊界值分析法 C 、因果圖法 D 、錯誤推測法 劃分等價類劃分等價類等價列劃分設(shè)計(jì)方法是把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分（子集），然后從每一個子集中選取少量具有代表性的數(shù)據(jù)作為測試用例。等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。并合理地假定：測試某等價類的代表值就等于對這一類其他值的測試。等價類劃分有兩種不同的情況：有效等價類和無效等價類。設(shè)計(jì)時要同時考慮這

52、兩種等價類。下面給出6條確定等價類的原則：在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，則可以確立一個有效等價類和兩個無效等價類。 在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下，則可以確立一個有效等價類和一個無效等價類。 在輸入條件是一個布爾量的情況下，可以確立一個有效等價類和一個無效等價類。 在規(guī)定了輸入數(shù)據(jù)的一組值（假定n個），并且程序要對每一個輸入值分別處理的情況下，可以確立n個有效等價類和一個無效等價類。 在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。 在確知已劃分的等價類中各元素在程序處理中的方式

53、不同的情況下，則應(yīng)再將該等價類進(jìn)一步的劃分為更小的等價類。 在確立了等價類后，可建立等價類表，列出所有劃分出的等價類。然后從劃分出的等價類中按以下的3個原則設(shè)計(jì)測試用例：為每一個等價類規(guī)定一個唯一的編號 設(shè)計(jì)一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復(fù)這一步，直到所有的有效等價類都被覆蓋為止。 設(shè)計(jì)一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復(fù)這一步，直到所有的無效等價類都被覆蓋為止。 例：程序規(guī)定；輸入三個整數(shù)作為三邊的邊長構(gòu)成三角形。當(dāng)此三角形為一般三角形、等腰三角形、等邊三角形時，分別作計(jì)算。用等價類劃分方法為該程序進(jìn)行測試用例設(shè)計(jì)。解：設(shè)a、b、c代表

54、三角形的三條邊。1）分析題目中給出的和隱含的對輸入條件的要求：a) 整數(shù)b) 3個數(shù)c) 非零數(shù)d) 正數(shù)e) 兩邊之和大于第三邊f(xié)) 等腰g) 等邊 2）列出等價類表并編號3）列出覆蓋上述等價類的測試用例，如下表： B 、 邊界值分析法邊界值分析法使用邊界值分析方法設(shè)計(jì)測試用例的步驟，首先：應(yīng)確定邊界情況。通常輸入和輸出等價類的邊界，就是應(yīng)著重測試的邊界情況。其次，應(yīng)但選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù)?；谶吔缰捣治龇椒ㄟx擇測試用例的原則：如果輸入條件規(guī)定了值的范圍，應(yīng)取剛達(dá)到這個范圍的邊界值，以及剛剛超過這個范圍邊界的值作

55、為測試輸入的數(shù)據(jù)。 如果輸入條件規(guī)定了值的個數(shù)，應(yīng)用最大個數(shù)、最小個數(shù)、比最小個數(shù)少一、比最大個數(shù)多一的數(shù)作為測試輸入的數(shù)據(jù)。 根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則1。 根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則2。 如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合，則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例數(shù)據(jù)。 如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，應(yīng)當(dāng)選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)邊界上的值作為測試用例。 分析規(guī)格說明，找出其他可能的邊界條件。 D 、錯誤推測法 人們也可以通過經(jīng)驗(yàn)或直覺推測系統(tǒng)中可能存在的各種錯誤，從而有真對性地編寫檢查這些錯誤的例子，這就是錯誤推測法。錯誤推測法沒有確

56、定的步驟，很大程度上是憑經(jīng)驗(yàn)進(jìn)行的。 手機(jī)測試?yán)齼?yōu)先級別的定義手機(jī)測試?yán)齼?yōu)先級別的定義(1)測試用例的優(yōu)先級別測試用例的優(yōu)先級別首先，你必須確定什么是你優(yōu)先級別的類型和其暗示著什么。就我們的目的來說， 我們將用一個假設(shè)開始，那就是我們可能發(fā)現(xiàn)的缺陷的嚴(yán)重程度和那些相應(yīng)測試用例的優(yōu)先級別之間是平行的。 1 小版本確認(rèn)測試（Build Verification Tests (BVTs)：也叫做“冒煙測試”，一組你想先運(yùn)行的以確定這個給出的小版本是否可以測試的測試用例。如果你不能訪問每一個功能區(qū)域或執(zhí)行其他測試用例依賴的基本操作，那么在執(zhí)行這個優(yōu)先的測試用例之前，試圖做其他任何的測試 都是沒有意義的，因?yàn)樗麄兇蠖鄶?shù)肯定要失敗。 2 高（Highs）：最常執(zhí)行以保證功能性是穩(wěn)定的，目標(biāo)的行為和能力可以正常的工作，和重要的錯誤和邊界被測試的測試用例的集合 3 中（Mediums）：這是使給出的功能區(qū)域或功能變得更詳細(xì)，檢查功能的多數(shù)方面包括邊界，錯誤和配置測試的測試用例 4 低（Lows）：這是通