如何豐富測(cè)試手段，實(shí)現(xiàn)QA自身效率的提升
作者|李京京
項(xiàng)目中QA同學(xué)需要針對(duì)不同項(xiàng)目特點(diǎn)，采用不同的測(cè)試手段，大家常用的測(cè)試手段包括：功能測(cè)試，接口測(cè)試，接口Mock測(cè)試等，那如何將這些測(cè)試手段應(yīng)用到自己的項(xiàng)目中，形成特定的測(cè)試方案呢。下面會(huì)結(jié)合具體項(xiàng)目來(lái)作詳細(xì)闡述。
項(xiàng)目名稱：盤古類目體系改造
1、背景介紹
通過(guò)新老類目體系的相互映射，保證新老類目體系并行一段時(shí)間，待各個(gè)業(yè)務(wù)方完成由舊類目體系到新類目體系遷移完成，下線舊類目體系，全部切到使用新類目體系。APP會(huì)作為盤古的第一個(gè)接入方。
2、難點(diǎn)分析
本項(xiàng)目的核心是偏下游的基礎(chǔ)服務(wù)，調(diào)用場(chǎng)景較多，且7000多個(gè)分類的新老數(shù)據(jù)映射，需要測(cè)試的case量巨大，完全基于功能層面去測(cè)試成本高，耗時(shí)長(zhǎng)，且無(wú)法保證全量覆蓋，可行性低
不同業(yè)務(wù)線業(yè)務(wù)場(chǎng)景不同，且有一些特殊場(chǎng)景存在，單純的接口測(cè)試是不能覆蓋業(yè)務(wù)線的實(shí)際應(yīng)用場(chǎng)景的，且交互邏輯是否正確，最終還是要通過(guò)功能層面去驗(yàn)收
3、測(cè)試方案
全量自動(dòng)化接口測(cè)試+業(yè)務(wù)場(chǎng)景功能測(cè)試
4、效果
全量接口自動(dòng)化測(cè)試，大大提升了測(cè)試效率（詳見(jiàn)表格），實(shí)現(xiàn)了case的全量覆蓋，保證了測(cè)試質(zhì)量；且沉淀下來(lái)的測(cè)試代碼，項(xiàng)目后期維護(hù)階段，可以復(fù)用進(jìn)行回歸測(cè)試
從用戶功能角度做驗(yàn)收是必要的，發(fā)現(xiàn)業(yè)務(wù)特定場(chǎng)景下的細(xì)節(jié)問(wèn)題，保障用戶體驗(yàn)
二、提前產(chǎn)出測(cè)試工具
項(xiàng)目名稱：我發(fā)布的列表頁(yè)改版
1、任務(wù)展示邏輯及曝光策略測(cè)試
（1）難點(diǎn)分析
任務(wù)及曝光策略涉及到的條件都是結(jié)合Redis緩存的特定字段的時(shí)間戳或字段狀態(tài)值來(lái)判斷的，構(gòu)造Redis里有代表性的時(shí)間戳和可能的狀態(tài)值是可行的，但是構(gòu)造的數(shù)據(jù)只有在隔天才會(huì)影響到Redis中特定值的變動(dòng)，頻繁的構(gòu)造真實(shí)數(shù)據(jù)，進(jìn)行客戶端展現(xiàn)的測(cè)試，幾乎是不可行的。
可不可以讓server從代碼里把時(shí)間間隔改小呢？溝通結(jié)論是不可行的，因?yàn)槿绻薷牧耍M測(cè)試，測(cè)試的不是真實(shí)邏輯，意義不大。
（2）測(cè)試方案?采用分層測(cè)試
真實(shí)構(gòu)造可能的測(cè)試場(chǎng)景，生成Redis中具有代表性的時(shí)間戳和可能的狀態(tài)值，并校驗(yàn)這些字段值是正確的
?編寫操作Redis的工具類，針對(duì)性的對(duì)Redis中的時(shí)間戳和狀態(tài)字段進(jìn)行增刪改查，對(duì)客戶端展示進(jìn)行測(cè)試?
2、不同量級(jí)的曝光數(shù)在客戶端的展示樣式
通過(guò)Mock接口字段的不同返回值，查看客戶端的展示樣式是否正常
綜上，
通過(guò)提升QA自身的技術(shù)能力和代碼能力，有助于豐富自身的測(cè)試手段，深入理解技術(shù)實(shí)現(xiàn)方案，從而制定合理的測(cè)試方案。
一個(gè)優(yōu)秀的測(cè)試方案，除了它的有效性外，還需要做到可以對(duì)提測(cè)部分盡早介入測(cè)試，將問(wèn)題盡早暴露出來(lái)，減少項(xiàng)目后期壓力。
結(jié)合QA內(nèi)部推行的冒煙流程等有利條件，可以提前準(zhǔn)備好RD自測(cè)所需的數(shù)據(jù)構(gòu)造，測(cè)試工具，接口case等，是實(shí)現(xiàn)QA從保姆型到輔助型的有效途徑。