前兩天其實在網絡講課的時候，有很多同學也比較迷茫，不太理解我這個用白盒的手段，黑盒的思想進行測試。其實我覺得這種方法恰恰是在移動互聯網最好的一種測試手段，也會是接下來測試業內測試人員必須會的一種手段。這樣才能夠做到真正的測試，這樣才能夠獲取我之前所謂的數據。接下來的測試人員是和數據進行的一場戰鬥。第一步，已經認知到數據的重要性；第二步，知道獲取什麼數據，怎麼過濾數據。第三步，知道用什麼方法獲取你想要的數據。而現在真正做到這三步的寥寥無幾。
那麼廢話不多，我來講下昨天我在會上講的例子。是我10年碰見的項目中一個比較棘手的問題，無論是當初的我，還是現在的我都很棘手。
這裏希望大家先看問題，思考之後再看我當初很挫的解決方案。問題是這樣的，android平臺當初我測試一個第三方的軟件，該軟件內有一個手機聯繫人的快速搜索匹配功能。其功能和匹配邏輯都是由我們自己實現的。希望達到的功能有兩點，第一，一個人的姓名比如叫“小明”，那麼用戶可以通過姓名的正序匹配xiaoming，xm，ximin等等，倒序mx，mingxiao，minxi等等，這一系列的方式進行快速的搜索到聯繫人。第二，用戶搜索之後，搜索的結果儘量讓用戶覺得自己想要找的名字在手機的前幾頁顯示，以免用戶翻很多頁。大家可以先思考如果你要測試這樣一個功能，你會怎麼測試？考慮幾個方面？PS：支持中文，德語，法語等十幾個國家的姓名搜索。
思考中。。。。。。。。。。。。。。。
接下來我就介紹我當初做的很挫的方法。在會上有朋友提出，是否做這個測試之前需要和開發進行交流。我的答案是肯定的。不單單要和開發做交流，還需要好好了解這個功能的需求。當初我問開發和項目經理要了兩樣東西，第一個是該搜索功能的全部匹配模式列表。第二個就是各個匹配模式在code中的權重。
接下來就是測試，第一步進行了網絡上所有中文字的抓取，相當於準備好中文，英語，法語等各種語言組合的最基礎的字符串。接下來的例子是中文，其他語言以此類推。然後我們可以寫一個很簡單的程序將這些基礎的字符串組合，變成如下圖，這些txt文件保存在android的assets文件夾中，方便android程序讀取。
第二步，在生成上圖的這個聯繫人名稱的同時，進行簡單的case的生成。舉例比如一個聯繫人叫做“王小二”，我設置了兩個隨機數，第一個隨機數是用來取“wang xiao er”中從左往右連續的字的個數。第二個隨機數是用來取每個字變成拼音之後的字符串的從左到右的連續的字符的個數。舉例子來講第一個隨機數可能這裏取出來的是“王小”，第二隨機數取出來的是“wanx”。然後這個就是一份case了其實。如下圖：
這樣之後我們的聯繫人的原始數據，case以及期望結果都有了。那麼對於我們來講就是進行輸入，然後看輸出驗證了。那麼這裏就需要用到我們的android junit test，注意不是什麼robotium，而是僅僅使用android提供的測試框架。從assets讀取文件之後，存入數組，接下來就是告訴程序我要輸入的case，得到返回的list，然後從返回的list中遍歷查看是否有這條case對應的聯繫人的姓名。如下圖：
ok，到這裏爲止，我們驗證了通過各種匹配邏輯輸入case之後，程序是否能夠搜索的出來對應的聯繫人。大家也都看到了。這裏用的是android的代碼測試框架，但是其思維一步一步下來全部是黑盒的思維，從而也能夠看出黑盒的思維多麼的重要。那麼還有一個重要的問題，就是我們怎麼來驗證這個結果在返回的很長的list中比較靠前呢？因爲如果你有900個聯繫人，搜索的確能夠搜索出來，但是index在800,用戶體驗會非常的差。
那麼這裏我留兩個思考問題，其一，這個用戶體驗如何進行解決？其二，就是除了上述我說到的之外，大家覺得在做這個功能的測試時候還需要注意哪些問題。當初我有很多的點想當然，導致了很多bug沒有被發現。
在總結3裏面對於兩個問題我都會做進一步的分析。其實我覺得網上很多文章實例不對，還是那句話，純理論不是沒有意義，而是純理論很多人可能無法理解。就比如我看一篇很高深的文檔，我的level達不到，那麼我也看不懂。就是這樣。
再次感謝大家來參加移動測試會。我會完全的讓大家知道什麼是落地，什麼是實際，什麼纔是我們雙贏。
轉載地址：http://blog.sina.com.cn/s/blog_7022adbf01015tm2.html