一、背景
在2019Q4的線上問題中讯榕，漏測原因均為測試用例設(shè)計(jì)覆蓋不全導(dǎo)致姆钉，雖然小程序本質(zhì)上是webview渲染佳晶，但對小程序框架宿主功能而言，是屬于natvie截型，需要和基線一起發(fā)版上線的趴荸，在小程序框架功能的測試上，應(yīng)更多的考慮移動端的測試用例設(shè)計(jì)方法宦焦。自從H5 web轉(zhuǎn)為小程序框架的測試发钝，在用例設(shè)計(jì)上大多沿用的web測試方法，很多移動端獨(dú)有的特性并未考慮波闹，測試方法落后酝豪，使得用例設(shè)計(jì)成為測試質(zhì)量提升的瓶頸，因此精堕，希望以此總結(jié)移動端常用的測試用例設(shè)計(jì)方法和關(guān)注點(diǎn)孵淘，完善測試設(shè)計(jì)，提升移動端的測試能力歹篓。
二瘫证、移動端和web端測試設(shè)計(jì)方法對比
移動端的測試，與WEB測試相比滋捶，有很多是通用的痛悯，比如基礎(chǔ)功能性測試余黎、前后端接口交互邏輯重窟、接口容錯異常、性能測試惧财、兼容性測試等巡扇，但移動端本身還有很多獨(dú)有的特性扭仁，比如應(yīng)用的安裝卸載、應(yīng)用啟動和停止厅翔、手機(jī)權(quán)限控制乖坠、系統(tǒng)配置、應(yīng)用穩(wěn)定性測試等刀闷，這在web測試上是從未考慮過的熊泵，是最容易被忽略的部分。
2.1 基礎(chǔ)功能性測試
這部分即產(chǎn)品需求文檔內(nèi)所明確要求實(shí)現(xiàn)的功能甸昏，通常我們可以采用最基本的測試方法顽分，如功能分析、因果分析施蜜、等價(jià)類邊界值劃分等基礎(chǔ)方法卒蘸，將產(chǎn)品功能逐級拆分細(xì)化，最后轉(zhuǎn)化成功能性用例翻默。這些用例過完后缸沃，通常即可保證產(chǎn)品需求功能是完備的，在用戶正常操作的情況下不會出現(xiàn)大的問題修械，之后的問題一般是出現(xiàn)在基本功能外的特殊情況中趾牧，比如特殊場景、特殊操作的影響祠肥。在這一部分的用例設(shè)計(jì)上武氓，我們應(yīng)該做到以下幾點(diǎn)：
- 合理劃分產(chǎn)品功能模塊，逐級細(xì)分仇箱，并組織用例結(jié)構(gòu)县恕，保證清晰可延展。比如針對頁面的測試剂桥，我們可以從上往下忠烛，從左至右劃分出不同的功能模塊，再詳細(xì)梳理每個(gè)模塊所需事先的功能點(diǎn)权逗。
- 精簡的用例條例美尸。用較少的測試用例，描述清楚覆蓋的功能測試點(diǎn)斟薇，全面而不冗余师坎，這往往取決于上一步針對需求的功能模塊劃分是合理的
- 穩(wěn)定的測試方法。在一定的前置條件堪滨、執(zhí)行順序下胯陋，有明確的預(yù)期結(jié)果
- 考慮用戶體驗(yàn)，如布局與UI/UE圖是否一致、過場動畫效果遏乔、文案是否有歧義义矛，站在用戶的角度上思考交互是否友好，是否有更好更簡單的方式等
2.2 異常容錯測試
常見的異常場景有：后端接口異常盟萨、人為操作輸入凉翻、網(wǎng)絡(luò)環(huán)境等，對于web測試捻激，可參考wiki異常場景測試制轰。在移動端上，可能還需要考慮以下場景胞谭，應(yīng)用中斷測試（如測試游戲艇挨，被電話/鬧鐘/短信/鎖屏/置于后臺等中斷時(shí)的表現(xiàn)），應(yīng)用資源搶占（如音頻韭赘、視頻缩滨、攝像機(jī)資源），硬件資源異常（如存儲空間泉瞻、內(nèi)存不足時(shí)的表現(xiàn)）等等
2.3 應(yīng)用安裝卸載
web頁面是運(yùn)行在瀏覽器內(nèi)的脉漏，所以沒有安裝和卸載的概念。對于移動端應(yīng)用安裝測試來說袖牙，又可以劃分為以下幾類：
卸載安裝：卸載后相關(guān)緩存數(shù)據(jù)目錄會被清理
升級覆蓋安裝：在本地緩存的文件侧巨、數(shù)據(jù)庫等得以保留，如果數(shù)據(jù)在新老版本不兼容鞭达，安裝時(shí)未得以更新司忱，則可能會產(chǎn)生問題。再往下細(xì)分又可分為連續(xù)升級或跳級安裝
2.4 應(yīng)用啟動停止
在應(yīng)用的啟動上畴蹭，很多APP在首次啟動和二次啟動是會有不一樣的邏輯的坦仍，比如首次啟動會判斷本地是否有相關(guān)數(shù)據(jù)，如果沒有則進(jìn)行下載叨襟，那么第二次啟動時(shí)就不會下載了繁扎。這需要根據(jù)具體的業(yè)務(wù)情況進(jìn)行設(shè)計(jì)。app啟動也有冷啟動和熱啟動之分糊闽，冷啟動是指應(yīng)用未運(yùn)行在后臺時(shí)啟動梳玫，熱啟動是指應(yīng)用已經(jīng)存在于后臺時(shí)的啟動。
應(yīng)用的停止右犹，也有多種方式提澎，如正常返回退出、殺進(jìn)程念链、操作中出現(xiàn)崩潰停止盼忌、被系統(tǒng)或第三方管理軟件停止等莉炉，以上的各種情況，均需保證下次能夠正常啟動碴犬。
2.5 權(quán)限管理控制
移動端權(quán)限隨著發(fā)展是越增越多，控制也越來越嚴(yán)格梆暮，如讀取聯(lián)系人服协、定位、訪問日歷啦粹、相機(jī)偿荷、錄音、存儲等等唠椭，如果APP用到了某一項(xiàng)權(quán)限跳纳，那么在測試時(shí)，就一定要覆蓋允許贪嫂、拒絕寺庄、使用時(shí)詢問這三種情況，保證APP在各種情況時(shí)均得到良好的處理力崇，不會出現(xiàn)崩潰閃退等重大問題斗塘。還有就是權(quán)限的申請可能在不同系統(tǒng)版本有一定變化，也需要在測試的時(shí)候進(jìn)行覆蓋
2.6 穩(wěn)定性測試
穩(wěn)定性測試是為了驗(yàn)證APP在長時(shí)間運(yùn)行的情況下亮靴，是否會有崩潰或明顯卡頓現(xiàn)象馍盟。一般采用的是Monkey命令行工具，通過模擬發(fā)送隨機(jī)事件（如點(diǎn)擊茧吊、滑動等）贞岭，監(jiān)測應(yīng)用在各種操作下可保持運(yùn)行的最大時(shí)間。
2.7 兼容性測試
web端兼容性一般主要是針對瀏覽器搓侄，當(dāng)然系統(tǒng)版本瞄桨、屏幕尺寸分辨率也會稍加考慮，移動端的兼容性測試主要以系統(tǒng)版本讶踪、屏幕尺寸分辨率讲婚，還有一個(gè)很重要的是版本間的兼容性，比如2.0版本新上線的功能俊柔，在1.0版本表現(xiàn)是怎樣的筹麸，會不會出現(xiàn)重大的問題。
2.8 性能測試
性能測試在web端主要是頁面的加載時(shí)間雏婶、白屏?xí)r間物赶，移動端性能則比較多，除了頁面加載和白屏留晚，還有應(yīng)用啟動時(shí)長酵紫、CPU告嘲、內(nèi)存、渲染FPS奖地、電量橄唬、流量等。
三参歹、小程序框架項(xiàng)目測試關(guān)注點(diǎn)
以上闡述了在移動端測試設(shè)計(jì)上可能需要關(guān)注的點(diǎn)仰楚，但都比較籠統(tǒng)，每個(gè)應(yīng)用犬庇、每個(gè)需求的功能點(diǎn)都是不一樣的僧界，需要具體的業(yè)務(wù)具體分析，不能一概而論臭挽。針對小程序框架這個(gè)業(yè)務(wù)而言捂襟，我們在項(xiàng)目測試上，用例應(yīng)該要覆蓋哪些方面呢欢峰。
3.1 影響業(yè)務(wù)范圍
拿到項(xiàng)目后葬荷，首先應(yīng)該確認(rèn)該需求的范圍∨μ基線小程序在業(yè)務(wù)上來分闯狱，有小程序和小游戲兩大塊，小程序又可分為標(biāo)準(zhǔn)小程序框架和虛擬小程序框架抛计，產(chǎn)品在提需求時(shí)哄孤，往往只會提到標(biāo)準(zhǔn)小程序，而忽略了虛擬小程序框架和小游戲兩塊業(yè)務(wù)吹截，這三大部分在代碼上互相獨(dú)立的瘦陈。比如需要在小程序框架更多菜單欄內(nèi)增加反饋入口，需要覆蓋虛擬小程序和小游戲波俄，特別小游戲晨逝，比較容易被忽略，需要在評審期間就確認(rèn)懦铺。
3.2 宿主API測試關(guān)注點(diǎn)
宿主功能API是小程序業(yè)務(wù)中比較重要的部分捉貌，在用例全集中也占據(jù)相當(dāng)大的比例。對于API的測試冬念，總結(jié)了以下用例設(shè)計(jì)關(guān)注點(diǎn)趁窃。
- ****業(yè)務(wù)功能點(diǎn)**** 所要實(shí)現(xiàn)的業(yè)務(wù)基本功能測試，根據(jù)需求而定急前，同時(shí)需要判斷是否影響線上已有API功能
-
調(diào)用傳參格式和返回值規(guī)范
API可大致分為兩類醒陆，同步和異步API兩種，同步是直接返回結(jié)果裆针，不需要傳回調(diào)函數(shù)刨摩，如果是異步寺晌，則必須傳3個(gè)回調(diào)函數(shù)，分別是success澡刹、fail呻征、complete，格式為：{success: res => {}, fail: res=> {}, complete: res => {}}罢浇。同時(shí)陆赋，需要確認(rèn)觸發(fā)success和fail的條件，什么情況可認(rèn)為是success己莺，什么情況算fail，compelete是必須觸發(fā)的戈轿，不管失敗還是成功凌受。對于返回值，如果是失敗思杯，必須明確code和msg字段胜蛉，給予友好提示。 -
傳參參數(shù)
參數(shù)必須考慮到各種異常情況色乾，如參數(shù)缺失誊册、類型錯誤、值錯誤暖璧，以及針對業(yè)務(wù)功能可能涉及的情況情況案怯，如獲取用戶手機(jī)號需要考慮用戶未綁定手機(jī)號或其他情況導(dǎo)致無法獲取手機(jī)號的情況 -
調(diào)用權(quán)限
考慮該API是否可以對外部小程序公開，如果不能公開澎办，需要在后臺增加相應(yīng)的權(quán)限設(shè)置嘲碱，僅對內(nèi)部開發(fā)者使用。如果可以對外公開局蚀，也需要考慮是否要增加權(quán)限配置麦锯，即小程序內(nèi)的權(quán)限管理頁面，如獲取用戶地址琅绅、用戶信息扶欣、相機(jī)等這類的權(quán)限設(shè)置 -
安全性
考慮接口安全性問題，如泄露私密信息或惡意調(diào)用導(dǎo)致公司利益或形象受損 -
隱私彈窗提醒
對于涉及到用戶隱私信息獲取相關(guān)的API千扶，需要彈窗提醒以提示用戶料祠，如獲取手機(jī)號、用戶名等信息 -
覆蓋安裝
如果是涉及到基礎(chǔ)庫澎羞，特別是私有API的基礎(chǔ)庫js文件的變更术陶，一定要測試覆蓋升級安裝的 -
性能測試
對于前端API來說，盡量使用異步線程執(zhí)行煤痕，不要阻塞用戶操作導(dǎo)致anr梧宫。如果涉及到后臺接口接谨，需評估線上調(diào)用量并考慮是否需要壓測 -
兼容性測試
按照基線小程序兼容性覆蓋
其他容易遺漏的點(diǎn)
- 動畫效果
- wifi 4g
- 置于后臺
- 與APP資源爭搶，如音頻視頻
