一、簡介?
? ? 移動應用App已經滲透到每個人的生活性置、娛樂拾并、學習、工作當中鹏浅,令人激動嗅义、興奮且具有創(chuàng)造性的各種App猶如雨后春筍般交付到用戶手中。各類智能終端也在快速發(fā)布隐砸,而開發(fā)者對于全球移動設備的質量和性能卻掌握甚少之碗,App與設備的兼容性問題常常導致用戶投訴,令開發(fā)者十分沮喪季希,App測試與服務質量保證矛盾十分突出继控。
? ? 移動開發(fā)的一個重要難題械馆,就是應用在開發(fā)過程中,必須使用手機真實環(huán)境進行系統(tǒng)測試武通,才有可能進入商用霹崎。由于手機操作系統(tǒng)的不同,以及操作系統(tǒng)版本之間的差異冶忱,使得真機系統(tǒng)測試這個過程尤其復雜尾菇,涉及終端、人員囚枪、工具派诬、時間、管理等方面的問題链沼。
? ? 首先必須購買足夠多的手機默赂,包括不同操作系統(tǒng),不同版本括勺,不同分辨率缆八,甚至不同廠商,目前市場上的手機平臺有iOS疾捍、Android奈辰、Symbian、WP乱豆、Blackberry奖恰、Linux等(集中度較高的是iOS、Android和WP系統(tǒng))宛裕,平臺之間存在較大差異瑟啃,語言和標準完全不同。以Android為例揩尸,就需要面對Android?1.5翰守、2.0、2.1疲酌、2.2蜡峰、2.3、3.0朗恳、4.0七個以上的版本湿颅,約十幾種不同的分辨率,HTC粥诫、摩托油航、三星、LG怀浆、索愛谊囚、聯想怕享、中興、華為…等數十個廠商镰踏。一個商業(yè)化運作的開發(fā)團隊函筋,一般至少需要幾十部手機、終端奠伪,才能完成必要的適配工作跌帐。如果缺失這個真機系統(tǒng)測試環(huán)節(jié),極大可能會給應用的推廣和使用埋下了一個隱患绊率,一旦出問題將直接招致用戶的投訴或拋棄谨敛。??
? ? 其次在拿到不同手機進行測試的時候,還將面臨不同手機廠商的系統(tǒng)版本差異問題滤否,即便是標準統(tǒng)一的Android系統(tǒng)脸狸,手機廠商的版本也并非完全相同,MIUI藐俺、LePhone炊甲、MEIZU,這些Android系統(tǒng)已經加入了很多個性化的東西紊搪,導致Android應用必須進行單獨適配。這過程中出現的很多問題全景,往往沒有資料可查耀石,使開發(fā)者雪上加霜。?
? ? 終端問題之后爸黄,就是人員工資的高漲使得很多開發(fā)團隊在緊張的預算下優(yōu)先向產品滞伟、運營、技術傾斜炕贵,很多成規(guī)模的互聯網企業(yè)通常只有幾個人的小測試團隊梆奈。
? ? 另外,App的真機系統(tǒng)測試在全球范圍內還停留在刀耕火種的純人工狀態(tài)称开,沒有有效的工具可以利用亩钟,測試人員發(fā)現的Bug很難復現,開發(fā)人員因此也很難定位鳖轰、快速修改Bug清酥。
? ? 接下來的問題是,為了滿足用戶旺盛的需求蕴侣、適應激烈的市場競爭焰轻,所有的移動互聯網企業(yè)都在拼命地趕工期,開發(fā)人員下班前完成的版本昆雀、至少希望第二天上班的時候能夠被測試完成辱志,這就要求測試人員連夜工作蝠筑,于是我們可以看到很多歐美的軟件公司會把測試工作交給中國的外包企業(yè)進行。
? ? 最后揩懒,終端什乙、人員、流程等管理問題也非常突出旭从,終端稳强、Bug、人員要在測試和悦、開發(fā)退疫、產品、客服鸽素、運營等不同的部門之前交錯褒繁。
? ? 如何進行卓有成效的App系統(tǒng)測試,以及協調好與之相關的計劃馍忽、管理棒坏、人員、資源遭笋、終端等各個環(huán)節(jié)坝冕,一直是困擾各個App開發(fā)企業(yè)的問題。
? ? 1.1什么是App測試?
? ? IEEE定義:使用人工或自動化來測試某個程序瓦呼,來驗證它是否滿足規(guī)定的需求或者實際結果和預期結果之間的差別喂窟。?
? ? App是基于移動互聯網軟件、及軟硬件環(huán)境的應用軟件央串。App測試就是要找出App中的BUG磨澡,通過各種手段和測試工具,判斷App系統(tǒng)是否能夠滿足預期標準质和。移動App稳摄,由于增加了終端、外設和網絡等多項元素饲宿,因而測試內容和項目也相應增加了厦酬。?
在App開發(fā)過程中容易出現缺乏有效溝通,功能復雜瘫想、編程錯誤弃锐、需求不斷變更、時間壓力殿托、缺乏文檔的代碼霹菊、App開發(fā)工具、SDK和人員的疏忽等原因引發(fā)的錯誤,通過測試能夠發(fā)現旋廷、找出其中的錯誤鸠按,解決錯誤,從而提高App的質量
1.2??測試方法?
1.2.1? 白盒測試?
依據被測App分析程序內部構造饶碘,并根據內部構造設計用例目尖,來對內部控制流程進行測試。
?1.2.2? 黑盒測試?
黑盒測試(Black-Box?Testing)是基于系統(tǒng)需求規(guī)格扎运,在不知道系統(tǒng)或組件的內部結構的情況下進行的測試瑟曲,把測試對象看作一個黑盒,只考慮整體特性豪治,不考慮內部具體實現洞拨。? 通常又將黑盒測試叫做:基于規(guī)格的測試(Specification-Based?Testing)、輸入輸出測試(Input/Output?Testing)负拟、功能測試(Functional?Testing)烦衣。?
1.2.3? 人工測試?
測試活動由人來完成,狹義上指測試執(zhí)行由人工完成掩浙。
?1.2.4? 自動化測試?
通過計算機模擬人的測試行為花吟,替代人的測試活動,狹義上指測試執(zhí)行由計算機來完成厨姚。
?1.3?? UT衅澈、IT、ST測試?
1.3.1? Unit?Testing單元測試?
定義:對App的基本組成單元來進行正確性檢驗谬墙。集中對用源代碼實現的每一個程序單元 進行測試今布,檢查各個程序模塊是否正確地實現了規(guī)定的功能。? 目的:檢測App模塊對App產品設計說明書的符合程度芭梯。? 類型:白盒測試险耀,測試范圍為單元內部的數據結構弄喘,邏輯控制玖喘,異常處理。?評估標準:邏輯覆蓋率蘑志。?
1.3.2? Integrate?Testing集成測試?
定義:測試模塊或子系統(tǒng)組裝后功能以及模塊間接口是否正確累奈,把已測試過的模塊組裝起來,主要對與設計相關的App體系結構的構造進行測試急但。? 目的:在于檢測App模塊對App產品概要設計說明書的符合程度澎媒。? 類型:灰盒測試,測試范圍為模塊之間接口與接口數據傳遞的關系波桩,以及模塊組合后的功能戒努。? 評估標準:接口覆蓋率。
?1.3.3? System?Testing系統(tǒng)測試?
定義:App系統(tǒng)測試(App?System?Testing)镐躲,是將已經確認的App程序储玫、移動終端侍筛、外設、網絡等其他元素結合在一起撒穷,進行信息系統(tǒng)的各種組裝測試和確認測試匣椰,系統(tǒng)測試是針對整個產品系統(tǒng)進行的測試,目的是驗證系統(tǒng)是否滿足了需求規(guī)格的定義端礼,找出與需求規(guī)格不符或與之矛盾的地方禽笑,從而提出更加完善的方案。App系統(tǒng)測試發(fā)現問題之后要經過調試找出錯誤原因和位置蛤奥,然后進行改正佳镜。?
App系統(tǒng)測試是基于系統(tǒng)整體需求說明書的黑盒類測試,應覆蓋系統(tǒng)所有聯合的部件喻括。對象不僅僅包括需測試的App軟件邀杏,還要包含App軟件所依賴的硬件、外設甚至包括某些數據唬血、某些支持軟件及其接口等望蜡,基于本地及不同地區(qū)、網絡等真實終端拷恨,測試脖律、檢查已實現的App是否滿足了需求規(guī)格說明中確定了的各種需求,以及App配置是否完全腕侄、正確小泉。?
目的:驗證最終App系統(tǒng)是否滿足用戶規(guī)定的需求。?
類型:黑盒測試冕杠,測試范圍為整個系統(tǒng)微姊。
評估標準:測試用例對需求規(guī)格的覆蓋率。
二分预、移動App的系統(tǒng)測試? ??
目前主流的iOS兢交、Android和WP等OS系統(tǒng)以及各平臺,都相應地提供了不同程度的單元笼痹、集成測試工具配喳,可以在模擬器、沙箱環(huán)境下進行白盒凳干、灰盒測試晴裹、調試。?
但App存在著大量的軟硬件交互救赐,而這些都需要通過真實的終端通過黑盒測試方法進行系統(tǒng)測試涧团,需要將經過集成測試的軟件,作為移動終端的一個部分,與系統(tǒng)中其他部分結合起來泌绣,在實際運行環(huán)境下對移動終端系統(tǒng)進行一系列嚴格有效地測試喳瓣,以發(fā)現軟件潛在的問題,保證系統(tǒng)的正常運行赞别,驗證最終軟件系統(tǒng)是否滿足用戶規(guī)定的需求畏陕。?
然而,由于OS版本仿滔、硬件異常迅猛的發(fā)展速度惠毁,平臺始終沒有有效地提供符合App黑盒系統(tǒng)測試的工具與方法,大量的移動App測試還停留在純人工狀態(tài)崎页,效率十分低下鞠绰。終端、版本的碎片化飒焦,更加劇了這一問題的嚴重性蜈膨。?
自己開發(fā)、或借助第三方工具牺荠、平臺翁巍,進行自動化的移動互聯網App系統(tǒng)黑盒測試,是提升效率和測試質量的有效方法休雌。?
移動互聯網是極快速發(fā)展的新興產業(yè)灶壶,沒有成功經驗可循,只有市場和用戶才是檢驗你產品是否好壞的終極標準杈曲。借助傳統(tǒng)軟件測試方法和規(guī)律驰凛,可以有效地提升App的程序質量和用戶體驗。?
? 2.1? 冒煙測試(Smoke Testing)
冒煙測試(Smoke Testing)的對象是每一個新編譯的需要正式測試的App版本担扑,目的是確認軟件基本功能正常恰响,可進行后續(xù)的正式測試工作。冒煙測試的執(zhí)行者是版本編譯人員涌献。
App程序在編寫開發(fā)過程中胚宦,內部需要多個版本(Builds),但是只有有限的幾個版本需要執(zhí)行正式測試(根據項目開發(fā)計劃)洁奈,這些需要執(zhí)行的中間測試版本间唉。在剛剛編譯出來后绞灼,開發(fā)人員需要進行基本性能確認測試利术,驗證App是否能正確安裝、卸載低矮,以及操作過程和操作前后對系統(tǒng)資源的使用情況印叁,針對終端硬件及ROM版本的各維度,與App安裝、卸載不適配情況轮蜕、隱患原因分析報告昨悼,最終確認是否可以正確安裝/卸載,主要功能是否實現跃洛,是否存在嚴重死機率触、意外崩潰等Bug。
如果通過了該測試汇竭,則可以根據正式測試文檔進行正式測試葱蝗。否則,就需要重新編譯版本细燎,再次執(zhí)行版本可接收確認測試两曼,直到成功。
如果發(fā)現問題玻驻,就要有效地發(fā)現導致問題出現的原因悼凑,例如在Android App測試中,某些終端璧瞬、有時會出現應用程序錯誤需要強行關閉的提示户辫,但又找不到重現這個問題的步驟,這個是App的問題還是系統(tǒng)的問題呢嗤锉,應該怎么判斷呢寸莫?這通常需要有Log日志才可以判斷,Andriod App出現Crash的情況档冬,一般有兩方面的原因膘茎,如果Log日志中出現System_server,則為系統(tǒng)問題酷誓;如果Log中出現Shutdown VM披坏,代表應用程序的問題;還有一種情況是出現Died盐数,這個是進程死掉導致棒拂,包含系統(tǒng)主動殺死的情況。
【Testin Tips】? 當一個單元玫氢、或程序整體開發(fā)編譯完成帚屉,開發(fā)人員、或測試人員可以在PC上選取被測的App漾峡,通過iTestin連接的原型測試終端攻旦,自動進行快速的冒煙測試属百,以驗證App安裝梨州、啟動吼肥、基本操作運行、卸載等是否正常耕驰,測試報告包括各測試項是否成功芹关、特征截圖滓玖、Log日志详拙、CPU/內存等參數等。
2.2? ? 功能測試(Functional Testing)
功能測試是移動App測試最關鍵的環(huán)節(jié)截酷,根據產品的需求規(guī)格說明書和測試需求列表涮拗,驗證產品的功能實現是否符合產品需求規(guī)格;
功能測試的目標主要包括:? ?
是否有遺漏需求迂苛;? ?
是否正確的實現所有功能多搀; ?
隱示需求在系統(tǒng)是否實現; ?
輸入灾部、輸出是否正確康铭。
移動App的功能測試應側重于所有可直接追蹤到用例、或業(yè)務功能和業(yè)務規(guī)則的測試需求赌髓。這種測試的目標是核實數據的接受从藤、處理和檢索是否正確,以及業(yè)務規(guī)則的實施是否恰當锁蠕。
功能測試基于黑盒技術夷野,通過圖形用戶界面 (GUI) 與應用程序進行交互,并對交互的輸出或結果進行分析荣倾,以此來核實應用程序及其內部進程悯搔。
【Testin Tips】? 通過iTestin Suite連接的本地終端,測試人員可以非常方便地按照測試用例舌仍、在終端上進行操作妒貌,所有的操作過程、軌跡都會被自動記錄為腳本铸豁,所有操作目標灌曙、特征點的屏幕截圖、Log日志节芥、CPU/內存/網絡和其他系統(tǒng)資源參數也都會被詳細的記錄下來在刺,最后形成測試報告。? 當功能測試要求涉及到不同地區(qū)头镊、不同網絡的時候蚣驼,可以發(fā)布任務到mTestin社區(qū),要求特定地區(qū)相艇、特定網絡的測試者按照功能測試用例要求進行測試颖杏,然后通過報告匯總測試結果
2.3? ? 用戶界面測試(GUI Testing)
用戶界面 (GUI) 測試用于核實用戶與App之間的交互,包括用戶友好性厂捞,人性化測試输玷。? 一個好的App要有一個極佳的分辨率,而在其他分辨率下也都能可以運行靡馁。GUI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能欲鹏。另外,GUI 測試還可確保 GUI 中的對象按照預期的方式運行臭墨,并符合公司或行業(yè)的標準赔嚎。
GUI測試主要測試在不同分辨率下,測試用戶界面(如菜單胧弛、對話框尤误、窗口和其它可視控件)布局、風格是否滿足客戶要求结缚,文字是否正確损晤,頁面是否美觀,文字红竭,圖片組合是否完美尤勋,操作是否友好等。
GUI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能茵宪。確保用戶界面符合公司或行業(yè)的標準最冰,包括用戶友好性、人性化稀火、易操作性測試暖哨。
【Testin Tips】? 通過iTestin Suite完成冒煙測試和功能測試,所有特征點的截圖都可以快速反饋UI是否正常凰狞。 同時篇裁,為了更好地測試普通用戶對UI的反饋,可以進行用戶UI測試赡若,找一組人(1組12人茴恰,軍隊一個班的建制),試用你的原型UI斩熊,記錄他們的操作軌跡往枣,當然包括嚴重的Bug:? 1) 邀請外部用戶在現場通過iTestin Suite連接的終端進行操作。? 2) 發(fā)布測試任務到mTestin社區(qū)粉渠,要求n組用戶按照UI測試要求分冈,通過用戶自己的終端 連接到iTestin進行操作,將完成的任務提交到mTestin社區(qū)霸株。? 通過此類測試雕沉,可以有效地發(fā)現不同用戶操作UI上的行為軌跡差異,以判斷UI是否存在設計不恰當去件、或許要改進的地方坡椒。
2.4? ? 用戶體驗可用性測試(UE Testing)
用戶體驗可用性測試主要是檢測用戶在理解和使用系統(tǒng)方面到底有多好扰路,是否存在障礙或難以理解的部分。
用戶體驗可用性的測試方法倔叼,一般是通過用戶訪談汗唱,或邀請內測、小范圍公測等方式進行丈攒,通過不同實驗組的運營結果來判斷是否存在可用性缺陷哩罪。但由于缺乏有效的測試工具,必須要大量的測試樣本才能獲得比較真實的測試數據巡验,投入資源較多际插,測試周期較長。
【Testin Tips】? 參考GUI測試方法显设,為了更好地測試普通用戶對App UE的反饋框弛,可以進行用戶可用性測試,找n組測試者(1組12人——軍隊一個班的建制捕捂,UE測試建議選取最大12組測試者功咒、144人),試用App的原型UE可用性绞蹦,記錄測試者的操作軌跡力奋,當然包括嚴重的Bug。? 1) 邀請外部用戶在現場通過iTestin Suite連接的終端進行操作幽七。? 2) 發(fā)布測試任務到mTestin社區(qū)景殷,要求n組用戶按照可用性測試要求,通過用戶自己的終 端連接到iTestin進行操作澡屡,將完成的任務提交到mTestin社區(qū)猿挚。? 通過此類測試,可以有效地發(fā)現不同用戶操作App UE行為軌跡差異驶鹉,以判斷App的UE是否存在設計不恰當绩蜻、或許要改進的地方。
2.5? ? 安全性室埋、訪問控制測試(Security Testing)
安全性和訪問控制測試側重于安全性的兩個關鍵方面:
1)應用程序級別的安全性办绝,包括對數據或業(yè)務功能的訪問。
應用程序級別的安全性可確保:在預期的安全性情況下姚淆,主角只能訪問特定的功能或用例孕蝉,或者只能訪問有限的數據。例如腌逢,可能會允許所有人輸入數據降淮,創(chuàng)建新賬戶,但只有管理員才能刪除這些數據或賬戶搏讶。如果具有數據級別的安全性佳鳖,測試就可確被襞梗“用戶類型一” 能夠看到所有客戶消息(包括財務數據),而“用戶二”只能看見同一客戶的統(tǒng)計數據系吩。
2)系統(tǒng)級別的安全性来庭,包括對系統(tǒng)的登錄或遠程訪問。? 系統(tǒng)級別的安全性可確保只有具備系統(tǒng)訪問權限的用戶才能訪問應用程序淑玫,而且只能通過相應的網關來訪問巾腕。
2.6? ? 性能測試(Performance Testing)
性能測試用來測試App在真實環(huán)境中的運行性能面睛,以及與硬件絮蒿、網絡資源的匹配度,最終度量系統(tǒng)相對于預定義目標的差距叁鉴,通過極限測試方法土涝,發(fā)現系統(tǒng)在極限或惡劣的環(huán)境中自我保護能力,主要驗證系統(tǒng)的可靠性幌墓。? 性能測試測試主要通過以下幾項測試完成但壮。
2.6.1? 負載測試(Load Testing)
負載測試是在一定的軟硬件及網絡環(huán)境下,通過模擬不同的用戶常侣,執(zhí)行一種或多種業(yè)務蜡饵,觀察系統(tǒng)在不同負載下的性能表現。在這種測試中胳施,將使測試對象承擔不同的工作量溯祸,以評測和評估測試對象在不同工作量條件下的性能行為,以及持續(xù)正常運行的能力舞肆。? 負載測試的目標是確定并確保系統(tǒng)在超出最大預期工作量的情況下仍能正常運行焦辅。 此外,負載測試還要評估性能特征椿胯,例如筷登,響應時間、事務處理速率和其他與時間相關的方面哩盲。
【Testin Tips】? 性能測試可以通過iTestin錄制腳本前方,在本地的原型終端上單機進行,也可以在iTestin組成的企業(yè)私有云廉油、或Testin終端云上發(fā)起任務镣丑。
2.6.2? 強度測試(Stress Testing)
強度測試是一種性能測試,實施和執(zhí)行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤娱两。如果內存或磁盤空間不足莺匠,測試對象就可能會表現出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源(如數據庫鎖或網絡帶寬)而造成的十兢。強度測試還可用于確定測試對象能夠處理的最大工作量趣竣。
【Testin Tips】? 強度測試可以根據測試要求摇庙,通過iTestin錄制腳本,本地遥缕、或通過企業(yè)私有云卫袒、甚至Testin公有云的終端,非常方便单匣、有效地設定多次執(zhí)行的次數夕凝,自動進行測試,例如選99件商品户秤、加999個好友码秉、上傳9999張照片、支付99999次等等鸡号。
2.6.3? 穩(wěn)定性測試(Stability Testing)
穩(wěn)定性測試評價系統(tǒng)在一定負荷情況下转砖,長時間的運行情況。在一定的軟硬件及網絡環(huán)境中鲸伴,通過模擬大量的用戶執(zhí)行多種業(yè)務處理大量數據府蔗,使系統(tǒng)在極限環(huán)境下長時間運行,目的在于尋找系統(tǒng)的失效點汞窗。
【Testin Tips】? 穩(wěn)定性測試可以根據App的產品特征姓赤,非常方便地錄制腳本,通過本地仲吏、私有云不铆、公有云和mTestin群測,快速蜘矢、有效地完成測試狂男。
2.6.4?基準測試?
基準測試的目的主要是進行與已知系統(tǒng)的比較,包括App之前的版本品腹、參照版本岖食、競品等。?
【Testin?Tips】? 根據基準測試要求舞吭,可以通過iTestin在本地通過同類腳本的執(zhí)行泡垃,可以有效地判斷不同App基準測試的結果。??
2.6.5? 競爭測試?
競爭測試是判斷App競爭使用各種資源(數據紀錄羡鸥,內存等)的情況蔑穴。?
【Testin?Tips】? 通過iTestin?Suite進行App測試時,所有相關的CPU惧浴、內存存和、網絡等資源數據都會被記錄下來,用于競爭測試分析。??
2.7?故障轉移和恢復測試(Recovery?Testing)?
通過人工干預手段使系統(tǒng)發(fā)生軟捐腿、硬件異常纵朋,通過驗證系統(tǒng)異常前后的功能和運行狀態(tài),達到檢驗系統(tǒng)容錯茄袖,排錯和恢復的能力操软。可確保測試對象能成功完成故障轉移宪祥,并能從導致意外數據損失或數據完整性破壞的各種硬件聂薪、App或網絡故障中恢復。??
故障轉移測試可確保:對于必須持續(xù)運行的系統(tǒng)蝗羊,一旦發(fā)生故障藏澳,備用系統(tǒng)就將不失時機地“頂替”發(fā)生故障的系統(tǒng),以避免丟失任何數據或事務肘交。? 恢復測試是一種對抗性的測試過程笆载。在這種測試中扑馁,將把應用程序或系統(tǒng)置于極端的條件下(或者是模擬的極端條件下)涯呻,以產生故障(例如設備輸入/輸出?(I/O)?故障或無效的數據庫指針和關健字)。然后調用恢復進程并監(jiān)測和檢查應用程序和系統(tǒng)腻要,核實應用程序或系統(tǒng)和數據已得到了正確的恢復复罐。?
【Testin?Tips】? 在不涉及電源終端或開關機等狀態(tài)下的故障轉移和恢復測試,可以通過iTestin對測試App及終端在測試過程中的各項參數進行記錄雄家,幫助分析效诅、判斷測試結果。? ?
2.8?兼容適配性測試(配置測試Configuration?Testing)?
兼容適配性測試(配置測試)趟济,是核實測試對象在不同的App乱投、硬件配置中的運行情況,測試系統(tǒng)在各種軟硬件配置顷编,不同的參數配置下系統(tǒng)具有的功能和性能戚炫。?
在大多數環(huán)境中,不同終端媳纬、屏幕双肤、OS版本、網絡連接的規(guī)格都會有所不同钮惠,而這些因素都可能運行許多不同的配置環(huán)境組合茅糜,從而占用不同的資源(如CPU、內存素挽、瀏覽器版本蔑赘、OS版本等)。?
目標:驗證全部配置的可操作性、有效性缩赛,特別需要對最大配置锌历,最小配置和特殊配置進行測試。? ??
?操作系統(tǒng)版本的兼容性:測試App在不同操作系統(tǒng)版本下是否能夠正確顯示與運行峦筒;????
?硬件兼容性:測試與硬件密切相關的App產品與其他硬件產品的兼容性究西,是否可以正 確使用;? ??
?瀏覽器兼容性:測試App在不同產商的瀏覽器下是否能夠正確顯示與運行物喷。?
2.9 分辨率測試
測試在不同分辨率下卤材,界面是否匹配。
【Testin Tips】? 分辨率測試可以上傳App到Testin平臺峦失,選取不同分辨率的終端扇丛,自動進行。
2.10? 網絡測試
在網絡環(huán)境下和其他設備對接尉辑,進行系統(tǒng)功能帆精,性能與指標方面的測試,保證設備對接正常隧魄。
【Testin Tips】? 可以按照網絡要求卓练,將測試任務發(fā)布到mTestin社區(qū),測試者通過符合要求網絡的測試終端完成測試任務购啄,并上報測試結果到mTestin
2.11? 本地化測試
是指為各個地方開發(fā)產品的測試襟企,如英文版、中文版等等狮含,包括程序是否能夠正常運行顽悼,界面是否符合當地習俗,快捷鍵是否正常起作用等等几迄,特別測試在A語言環(huán)境下運行B語言App(比如在英文環(huán)境下運行中文版App)是否正常蔚龙。
【Testin Tips】? 可以按照本地化語言要求,將測試任務發(fā)布到mTestin社區(qū)映胁,測試者通過符合要求語言要求的測試終端完成測試任務木羹,并上報測試結果到mTestin。
2.12? 文字測試
測試文字是否拼寫正確屿愚,是否易懂汇跨,不存在二義性,沒有語法錯誤妆距;文字與內容是否由出入等等穷遂,包括圖片文字。
【Testin Tips】? 可以按照文字測試的要求娱据,將測試任務發(fā)布到mTestin社區(qū)蚪黑,選取合格的測試者分A/B組進行測試盅惜,測試者通過符合要求素質要求的測試終端完成測試任務,并上報測試結果到mTestin忌穿。
此類發(fā)布到mTestin的App測試抒寂,存在明顯的“殺蟲劑現象”,即由于測試人員的思路不盡相同掠剑,每個人測試的側重點不同屈芜,由于都按照測試用例進行測試,但是測試用例一般僅描述系統(tǒng)的一些基本測試項朴译,不會將所有的測試用例方方面面都寫到井佑,有時還需要測試人員的經驗和素質。所以A測試某個產品用了七個工作日眠寿,第一天到第四天報出許多bug躬翁,但從第五天開始幾乎報不出啥 bug了。七天后換了B盯拱,B一下子又測試出一堆bug盒发,不能說A的水平差,只能說該App已經對A產生了抗藥性狡逢,這就是測試學中的殺蟲劑現象宁舰。所以在測試中每次輪流測試最好安排不同的測試人員進行不同模塊測試工作,以避免殺蟲劑現象產生甚侣。
2.13? 發(fā)布測試
主要在App發(fā)布前對說明書明吩、廣告稿等進行測試间学。
【Testin Tips】? 發(fā)布測試可以由App產品殷费、客服團隊內部測試,或發(fā)布測試任務到mTestin進行測試低葫。
2.13.1?說明書測試?
主要為語言檢查详羡、功能檢查、圖片檢查嘿悬。? ??
語言檢查:檢查說明書語言是否正確实柠,用詞是否易于理解;???
功能檢查:功能是否描述完全善涨,或者描述了并沒有的功能等窒盐;???圖片檢查:檢查圖片是否正確。
?2.13.2? 宣傳材料測試?
主要測試產品中的附帶的宣傳材料中的語言钢拧,描述功能蟹漓、圖片等。
?2.13.3? 幫助文件測試?
幫助文件是否正確源内,易懂葡粒,是否人性化?
2.15回歸測試?
回歸測試是以上所有測試完成后的一個最為重要的環(huán)節(jié),是App發(fā)布、維護階段嗽交,對缺陷進行修復后的測試卿嘲。?
目的是驗證缺陷已經得到修復,檢測是否引入新的缺陷夫壁;?流程:?
1)在測試策略制定階段拾枣,制定回歸測試策略;?
2)確定需要回歸測試的版本盒让;?
3)測試版本發(fā)布后放前,按照回歸測試策略來執(zhí)行回歸測試;?
4)回歸測試通過糯彬,關閉缺陷跟蹤單凭语;?
5)回歸測試不通過,缺陷跟蹤單返回給開發(fā)人員撩扒,開發(fā)人員重新修改BUG似扔。再次提交給測試人員回歸測試?
測試策略:?
1)完全重復測試:重新執(zhí)行前期設計的用例,來確認問題修改的真確性和修改的擴散局部影響性搓谆;?
2)選擇性重復測試:?
a)?覆蓋修改法:針對被修改的部分炒辉,選取或重新構造測試用例驗證沒有錯誤再次發(fā) 生的選擇方法;?
b)?周邊影響法:該方法包括覆蓋修改法泉手,還要分析修改后對擴散的影響黔寇;?
c)?指標達成法:先確定一個達成的指標,基于這種要求選擇一個最小的測試用例集 合斩萌。?
【Testin?Tips】? 由于回歸測試是各項系統(tǒng)測試的重復缝裤,所以通過Testin所提供的各種測試工具與方法仍然是適合的,之前測試錄制的腳本可以繼續(xù)使用颊郎。根據回歸測試的終端憋飞、可以分解任務執(zhí)行。?