目前Android測(cè)試還是以黑盒測(cè)試為主的译仗，白盒測(cè)試固然是好觉壶，但白盒測(cè)試的實(shí)現(xiàn)成本對(duì)于App的快速迭代和敏捷開發(fā)來說難度過高髓需。
造成Android白盒測(cè)試的困難有：
Android系統(tǒng)本身的測(cè)試支持不夠
對(duì)測(cè)試人員的專業(yè)技術(shù)要求過高（而且我們團(tuán)隊(duì)測(cè)試同時(shí)支持iOS）
需求開發(fā)和更改時(shí)玻褪，也會(huì)依賴測(cè)試排期
那移動(dòng)開發(fā)團(tuán)隊(duì)如何保證應(yīng)用的質(zhì)量呢肉渴？
拿我工作過的騰訊和阿里的兩個(gè)Android團(tuán)隊(duì)舉例，產(chǎn)品用戶量級(jí)都在百萬(wàn)級(jí)別以上带射，機(jī)器crash率在0.5%左右同规，算是國(guó)內(nèi)的主流應(yīng)用團(tuán)隊(duì)了。我們的團(tuán)隊(duì)里面依靠以下幾個(gè)關(guān)鍵點(diǎn)來保證應(yīng)用的質(zhì)量：
1.完整的需求評(píng)審流程
需求評(píng)審
方案評(píng)審
設(shè)計(jì)評(píng)審
測(cè)試用例評(píng)審
2.完善的bug反饋系統(tǒng)
3.crash日志收集上傳
4.oa系統(tǒng)：bug和需求流轉(zhuǎn)（阿里的宙斯盾窟社，騰訊的tapd）
5.多樣性的測(cè)試方式
Monkey（阿里券勺，騰訊都有）
冒煙測(cè)試
系統(tǒng)測(cè)試（黑盒，白盒）
6.規(guī)范的發(fā)布流程
產(chǎn)品體驗(yàn)
內(nèi)部體驗(yàn)
分級(jí)灰度
全量發(fā)布
熱修復(fù)發(fā)布
前面提到的這么多策略灿里，只有系統(tǒng)測(cè)試的時(shí)候可能用到白盒測(cè)試关炼，所以白盒測(cè)試并不是Android質(zhì)量保證的全部，知識(shí)其中一個(gè)部分钠四。對(duì)于較大的團(tuán)隊(duì)白盒測(cè)試的重要性還是很高盗扒，因?yàn)榱己玫腁ndroid Unit測(cè)試用例可以解放部分測(cè)試人力，規(guī)范測(cè)試流程缀去。同時(shí)也是測(cè)試人員技術(shù)含量的提現(xiàn)侣灶。
其實(shí)，Android Unit測(cè)試對(duì)于更偏重于開發(fā)人員缕碎，很多的Android Unit測(cè)試都需要開發(fā)人員的參與褥影，如果你要做Android白盒測(cè)試如下的建議可以酌情參考：
1.使用良好的程序框架設(shè)計(jì)（MVP，MVVC）
2.關(guān)鍵協(xié)議數(shù)據(jù)的JUnit測(cè)試用例（在阿里的時(shí)候是開發(fā)人員自己寫）
3.關(guān)鍵流程的單元測(cè)試（登錄咏雌、支付凡怎、首頁(yè)等）
最后，應(yīng)用的質(zhì)量不能依賴于測(cè)試人員（facebook據(jù)說是沒有測(cè)試的）赊抖，開發(fā)人員要養(yǎng)成良好的自測(cè)習(xí)慣统倒，隨時(shí)記錄代碼中可能出現(xiàn)的問題，因?yàn)橹挥虚_發(fā)人員最清楚哪里可能出問題氛雪。應(yīng)用的質(zhì)量要靠整個(gè)團(tuán)隊(duì)的協(xié)作而不是互相依賴來保證房匆。
