乙個畢業才三四年的測試同行，居然已經出書並做出一定的成就，讓我這個測試很受打擊。不過也好，知道人外有人，天外有天，未必是件壞事。
這篇博文也是受他的文章所啟發，想到的。
在移動應用的測試中，往往屬於輕量化的開發。在模組功能完成之後，會提供版本給質量控制部門進行測試工作，但是問題在於怎麼樣叫模組的完成。
從我的角度來看，需要注意以下幾點：
1. 開發自測
因為開發每出品乙個版本，第一責任人是開發，簡單的說，對於該模組，開發是否有資訊進行交付？
所以自測的過程是必不可少的，不期望在自測過程中發現更多的潛在問題，因為那時測試團隊的職責所在。但是作為團隊的成員之一，開發要首先對功能模組中最重要的功能有個把控，達到了自己的要求，才能發包。
討厭的是盲目的發包或者畢竟過自測的發包，對於團隊，產品都會形成不良的影響。
其實這裡是有個誤區的，因為太多的開發覺得，我為什麼要做測試的工作？其實在阮建工程，特別是敏捷開發的理念中，開發測試的工作時可以互換的，開發有時間可以去做測試，測試有時間可以去做開發的工作，乙個團隊，講究的是快狠準，而不是其他。但是國內目前。。。
2. tdd 先行
在敏捷的團隊中，tdd的模式如果用起來可能會好點，測試用例中需要實現的10個功能點，如果有6個是重要級別的功能點，4個是輕量級的功能點，如果開發在完成6個重量級功能點之後，其實已經滿足了測試要求，可以發布版本進行測試。
但是必須強調的是，如果6個功能點完成之後，整個模組的系統沒有串聯起來，發包測試將是一種災難。所以找到主幹，並完成主幹才是測試開始的關鍵。
3. 介面的穩定
在工作中，我也想達到一種的境界：在開始測試的時候，後台介面其實已經完成了測試，並穩定下來。這樣測試的準確性和問題追蹤的準確性才大大增加。
但是很可惜的是，目前還不能達到這樣的境界。我在努力，團隊也在努力。
總的來說，並沒有乙個完整的需求或者說可以測試的標準的界限，每個團隊都不同，開發的經驗不同，測試的流程不同，所以經驗不可以套用。最重要的是自己分析。
第七周，移動模組的測試
關於人物移動模組，在測試bug時首先使用的黑盒測試，在人物移動中發現了許多的bug例如人物移動時候與物體發生碰撞，有時候並不能完美的碰撞，有時候提前就發生了碰撞，有的時候可能根本不發生碰撞。觀察到這一現象就使用了白盒測試，在移動模組中加入了一些小的程式。例如下面這個執行緒。這個執行緒的功能是每隔一秒...
測試開發中的蟲劑悖論
1 初識蟲劑悖論 提到 蟲劑悖論 pesticide paradox 我相信很多人都沒聽說的，除非是生物學專業的同學或者磚家。蟲劑悖論描述的是重複使用某種農藥殺滅害蟲，時間越久，殺蟲的效果就越差。之所以這樣，是因為出現抗藥性，也就是說害蟲發生了進化，對這種殺蟲藥免疫了。為了保證農藥的殺蟲效果，我們必...
移動app測試的多樣性 測試移動應用程式的十大技巧
51cto.com快譯 移動應用程式行業是個競爭異常激烈的領域。除了許多公司將業務應用程式改用移動平台外，蘋果的應用程式商店裡面有200多萬個應用程式，谷歌的play store提供了220多萬個應用程式。據pocketgamer聲稱，今年到目前為止，每天向應用程式商店提交的應用程式數量平均在200...