原文地址:http://tech2ipo.com/66893
TestFlight / via iMore
作者: Nick Arnott 譯者:翛淩 原文:iMore
iOS 應用程式的測試對於 iOS 開發人員來說一直讓人非常頭疼。所以蘋果公司大張旗鼓地在 WWDC 2014 上宣布 TestFlight 將會作為 iOS 8 的一部分,一點都不讓人奇怪。自從蘋果公司收購了 TestFlight 的製造商 Burstly 公司後,許多人都期待蘋果能夠最終發布一個對開發人員友好的解決方案。將 TestFlight 加入 iOS 8 變為了該領域一個非常重要的改進,這個聲明自然也受到了開發人員們的歡迎。
TestFlight vs. Ad Hoc 發布
大部分人只在他們的終端上通過 App Store 下載安裝應用程式。然而對於主要做應用開發的人來說,他們也經常使用另一種方式:Ad Hoc 發布。每一個 iOS 裝置都有一個專屬的裝置識別碼( UDID )。這個裝置識別碼可以協助開發人員在他們的帳號下添加該裝置,使該裝置能夠接受 Ad Hoc 發布。通過這個步驟,開發人員無需公開發布程式也能將程式放到裝置上進行實驗。管理運行 Ad Hoc 發布也很簡單。開發人員只需開發人員建立並維護一個發布日誌,指明什麼特定的裝置可以運行什麼特定的應用程式,即可讓該裝置得到 beta 版應用程式的運行許可權。然而對於大部分的開發人員來說,一個帳號被限制只能對 100 個裝置進行此種設定。並且這個過程非常容易被搞砸,也很容易造成讓人迷惑的錯誤,因此對於開發人員來說 Ad Hoc 發布並不是一個非常好的工具。而 TestFlight 看起來會改變這一切。
第一個非常重要的改變就是 TestFlight 不再需要開發人員或者測試者提供你裝置識別碼或者相應的身份資訊了。目前,如果你想添加一個新裝置,你需要完成以下步驟:
開發人員需要讓測試者提供他們的裝置識別碼(如果測試者不知道如何看到他們的裝置識別碼,開發人員還需要告訴測試者如何去找到他們的裝置識別碼)。
測試者用一個軟體取出他們的裝置識別碼。
測試者把裝置識別碼發給開發人員。
開發人員登陸蘋果開發人員入口。
開發人員把測試者的裝置加入他們的帳號中。
開發人員將裝置放入合適的應用程式帳號中。
開發人員添加測試者的資訊,並更新應用程式。
開發人員將應用程式發布給測試者。
以上的步驟依據開發人員所用的工具會有少許差異,但是這個步驟至少大致描述了整個過程。而 TestFlight 的步驟則基本如下:
測試者告訴開發人員他們的蘋果帳號。
開發人員登陸 iTunes Connect。
開發人員給測試者發送郵件邀請。
測試者接受邀請。
測試者通過 TestFlight 軟體下載安裝程式。
如果 TestFlight 能達到它所承諾的所有效果的話,那麼處理裝置識別碼和帳號的繁雜步驟將會成為過去。
1000 個蘋果帳號 vs. 100 個裝置識別碼
第二點讓開發人員長期以來一直抱怨個不停的就是 100 個裝置的限制。然而現在開發人員可以在他們的 beta 版應用程式下添加 1000 個蘋果帳號。然而添加蘋果帳號會導致 TestFlight 給開發人員發一個警報,並要求應用程式給蘋果公司發送一個審查。不過我們現在不知道具體的通過審查的標準。同樣我們也不知道在審核通過之後,如果對應用進行一些小幅度的更新會不會要求開發人員再度發送審核。然而這也是開發人員必須跨過的新的坎。
除了 1000 個測試者之外,開發人員還可以加上 25 個國際測試者。不過國際測試者不能僅僅通過郵件邀請,他們必須有一個由開發人員在 iTunes Connect 裡建立的帳號。這個新加入的規則的好處就是國際測試者不再需要等待應用程式發布就能參與到測試過程中。
當應用程式的新版本被上傳並通過審核後,它將有 30 天的有效期間。如果 30 天之後開發人員沒有發布新的版本,測試者將無法運行裝置上的測試版應用程式。直到開發人員發布新版本之後,測試者才可以再度運行程式。除了要上傳應用程式之外,開發人員還必須提交程式的中繼資料。應用程式的描述以及測試者需要測試的資訊也應該被上傳。
測試者將可以通過 TestFlight 管理並安裝邀請他們進行測試的測試版程式。TestFlight 將隨 iOS 8 一起發布,因此開發人員沒法在舊的 iOS 版本或者安卓上使用 TestFlight。TestFlight 將可以讓使用者瀏覽程式描述以及測試備忘。測試備忘將會讓開發人員知道哪裡需要提高、哪裡需要改進。同時測試者也可以通過 TestFlight 軟體向開發人員發郵件提供他們的反饋。
只能下載最新版本
另一個對所有開發人員來說值得一提的事情是:不論是國內測試者還是國際測試者,他們都只能下載安裝最新版的測試軟體。依據蘋果公司的新 iTunes Connect 發布會的視頻,只有最新版本才可以提供下載,而之前的版本全部顯示為「 inactive 」。提交了新版本之後,之前在旁邊備忘一個對勾的可供下載版也會顯示為「 inactive 」。當日也許開發人員有能力通過一些方式讓測試者接觸到之前的老版本。然而只有等到秋季蘋果公布新的 iTunes Connect 的官方檔案我們才可以確信這一點。然而僅能下載最新版本這一個特性也許會成為許多開發人員無法接受的條件。
崩潰報告……明年下半年再說
最後一個值得 TestFlight 一提的特性自然是崩潰報告。當你裝置上的軟體崩潰時,會產生一條錯誤記錄檔。iTunes Connect 一直以來都提供瀏覽崩潰日誌的能力,但是很少有人成功。另一個總被遺忘的部分就是缺少符號化。而這意味著開發人員看到的崩潰日誌將不是哪一部分的代碼導致應用崩潰,而是彷彿永無止境的用十六進位表示的導致應用崩潰的代碼所在地址。也就是說,如果應用程式崩潰了,開發人員們並不會看到類似於「[OMGASIHTTPRequest reportFinished]」的具體的錯誤資訊,而是類似於「0x9b000 + 23698」的內容。諸如 HockeyApp 之類的第三方服務曾經提供過一段時間的錯誤記錄檔符號化服務,不過現在 iTunes Connect 終於將擁有這個功能。然而不幸的是這個特性將會在「明年下半年」發布,因此希望看到有用的崩潰日誌的開發人員們現在還得利用一些其他的工具。
iOS 8 的 TestFlight:底線
iOS 8 裡的 TestFlight 意味著對於開發人員和測試者來說,測試 beta 版程式將會有更多的選擇。開發人員將會有能力將 beta 版應用發布給更多的使用者,測試者將會得到一個被官方認可的安裝通過蘋果軟體市集以外的方法獲得第三方程式的途徑。我們希望這個改進會讓未來登陸蘋果軟體市集的程式的錯誤更少,讓最終下載該軟體的使用者們得到一個經過更多人測試和加工的好應用。