在昨天接近凌晨的時(shí)候，看到一條圍脖是闡述了一個(gè)現(xiàn)象?，F(xiàn)在移動(dòng)互聯(lián)網(wǎng)很多團(tuán)隊(duì)中會(huì)出現(xiàn)項(xiàng)目分類很多，項(xiàng)目發(fā)布周期短，測試和開發(fā)人員少這樣屢見不鮮的情況。時(shí)間一長，身在這樣團(tuán)隊(duì)的員工真的有苦說不出，因?yàn)樗麄冋旌苊β担瑓s斷斷續(xù)續(xù)，最終發(fā)布的產(chǎn)品還極其不穩(wěn)定。相信昨天我看到這條圍脖的作者也是這樣的感受。
這里我簡單介紹以下在這樣特定的迭代周期中的測試能夠采取的幾種解決方案。
1、測試用例分類和優(yōu)先級
一般情況，公司會(huì)要求寫很多的測試用例。當(dāng)然這些用例的數(shù)量肯定是遠(yuǎn)遠(yuǎn)超越在段時(shí)間內(nèi)測試人員能夠執(zhí)行完的。（這里也就不去提這些測試用例是不是一直維護(hù)，以及更新的問題了，大家懂得）那么此時(shí)按照一般的情況，我們將測試用例分成“基本功能”，“定制功能”，“場景測試”，“回歸測試”這樣幾類，當(dāng)然根據(jù)每個(gè)公司的產(chǎn)品業(yè)務(wù)不同可以再進(jìn)行分類。優(yōu)先級的話一般分成P1，P2，P3三類。曾經(jīng)其實(shí)嘗試過按照標(biāo)準(zhǔn)的4類劃分，后來發(fā)現(xiàn)其實(shí)P4的用例真的用到的概率非常小，所以去除了。
那么在快速迭代中，我們先要清楚要發(fā)布的產(chǎn)品的核心功能，業(yè)務(wù)是什么。比如你發(fā)布一個(gè)pptv的電視盒子，那么毫無疑問，核心價(jià)值就是看視頻。發(fā)布一個(gè)輸入法，核心價(jià)值就是輸入。這些核心價(jià)值絕對是在基本功能中，并且是P1的。作為測試人員你需要定制一套規(guī)則。因?yàn)樵诙嗌贂r(shí)間內(nèi)能夠執(zhí)行完多少用例你應(yīng)該是最清楚的，而在有限時(shí)間內(nèi)我們需要去執(zhí)行的就是那些最最有效，對于降低產(chǎn)品風(fēng)險(xiǎn)最高的用例。你分別在一天，半天，5小時(shí)，1小時(shí)這些時(shí)間內(nèi)去執(zhí)行哪些用例組合。打比方說，你有2個(gè)小時(shí)進(jìn)行一個(gè)產(chǎn)品的發(fā)布，那么此時(shí)你一定是這樣一個(gè)策略：“基本功能”（核心功能）P1＋回歸測試（核心功能）P1＋“定制功能”（核心功能）P1＋其他。而這些不是靠拍腦袋，也不是靠每個(gè)人的定義，而是需要有一個(gè)文檔進(jìn)行歸類，約束，引導(dǎo)的。比如2年前我寫的一分用例概括表。
每個(gè)功能點(diǎn)的用例都有號碼分類，可以看到都有兩個(gè)白色沒有寫的區(qū)域，第一個(gè)是這個(gè)功能用例的數(shù)量，第二個(gè)就是是否實(shí)現(xiàn)自動(dòng)化。這個(gè)表也起到了能夠讓leader或者團(tuán)隊(duì)的成員一目了然的作用。
2、邏輯分層測試
這里的邏輯分層可能需要對測試人員的要求相對會(huì)高點(diǎn)。需要進(jìn)行分析，從而減去不必要的工作量。舉兩個(gè)例子。曾經(jīng)測試過一個(gè)機(jī)頂盒升級的功能，這里我們分析一下。測試目標(biāo)兩個(gè)1.系統(tǒng)目錄中的文件是否被更新 2.版本號是否更新。 用戶升級有幾種方法
那么是不是我們測試這個(gè)功能就必須將這些點(diǎn)進(jìn)行排列組合呢？答案是大部分測試人員不會(huì)這樣做，但是他們并不知道該怎么做。但是我們進(jìn)行邏輯上的分析發(fā)現(xiàn)最關(guān)鍵的一個(gè)功能點(diǎn)——升級這個(gè)功能的邏輯，我們其實(shí)只需要寫個(gè)很簡單的工具查看這個(gè)功能是不是正確，驗(yàn)證之后，無論升級文件的來源，至少升級這個(gè)功能是正常的。接下來U盤和網(wǎng)絡(luò)的升級其實(shí)都是將升級文件先放在本地的一個(gè)儲存器中，讀取之后升級。那么我們的測試點(diǎn)就變成了系統(tǒng)是否可以正常讀取各種渠道的文件了。我們知道，android或linux這樣一個(gè)升級的工作必然夾雜著網(wǎng)絡(luò)的切換，開機(jī)，關(guān)機(jī)等等測試人員看著很頭疼的事項(xiàng)。那么我們分析拆分之后也就變的沒有那么繁瑣了。
發(fā)現(xiàn)很多測試人員知道各種寫用例的方法，但是卻沒有就自己測試產(chǎn)品功能的分析能力。這樣其實(shí)最后發(fā)現(xiàn)測試用例的數(shù)量很臃腫，質(zhì)量也不盡人意。其實(shí)主要問題就是出在這里。
另外還有探索性測試的方法，這里就不詳細(xì)說了，需要用到探索性測試方式中，旅游法，通宵法等進(jìn)行產(chǎn)品功能的分析，總結(jié)，然后實(shí)踐。同樣也是能夠起到很好的效果。
這里也順帶說下開發(fā)面臨這種情況下，就算不搭建CI，也需要通過ant＋xml配置的方法進(jìn)行快速自動(dòng)的編譯版本，否則真的是啞巴吃黃連。另外平時(shí)勤快的使用find bugs，lint，MAT等工具進(jìn)行代碼的檢查，ios的話同樣多使用一些自帶的分析工具和instruments里面的工具。相信會(huì)好很多。