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