??由于去年項目中并沒有進行單元測試，加上團隊成員較多，測試人員有限。后期測試，雖然經過了開發人員的自測，測試人員的測試，但仍然無法保證代碼測試的覆蓋率，會導致在線bug的產生，對于緊急發布，經常會存在被拒絕的情況。

一，什么時候選擇緊急發布最合適？

??不知道大家有沒有這樣的經歷，每天被郵件轟炸，被電話轟炸。往往發生線上的bug時候，公司越大，我們被轟炸的越慘，而且不過不能快速通過審核的話，又會經常影響我的KPI。根據前幾次緊急發布的經歷，一般情況下選擇在晚上緊急發布，順利通過審核的情況下，第二天早上就可以看到app新版本了。

二，選擇什么理由最合適？

?? 首先我們優先選擇崩潰，影響用戶正常使用的理由，或者選擇某些功能模塊跟政府有合作關系，政府要推廣某些事情，比如和政府合作繳納養老保險，醫療保險。學生上學的學費等?；径际荗K的。另外言語要盡量的客氣，禮貌。審核人員有千萬個理由可以拒絕掉你的app，畢竟解釋權歸蘋果所有。

三，盡量減少緊急發布的次數

?? 雖然我們這邊進行了幾次緊急發布，都順利的通過了審核，但是我們并不能把所有的希望都放在緊急發布上，我們仍然要采取必要的措施來減少緊急發布的次數，首先要采取白盒測試—單元測試，來保證我們的代碼質量， 保證我們的代碼覆蓋率。其次即使出了問題我們仍然可以用jspatch來熱修復。后續我這邊會分別推出單元測試系列的博客，和熱修復系列的博客。