隨著移動客戶端產品的快速發展，整體的節奏也在加速，無線事業部技術團隊要在1-2周時間內確保一個可以上線的版本而不出大的問題，作為測試人員我們希望跟團隊一起在最后能響亮的對產品質量喊出“YES”，而不是“NO”。
作為產品質量最后的一道把關者，要如何在短時間的快速迭代中高效保證質量？ 質量問題只有在測試環節才被重視和關注么？那么其他環節測試又能做些什么呢？
在最初面對效率與質量，似乎就像魚和熊掌一樣不能兼得的時候，曾不止一次問自己團隊類似的問題。在過去的1年里我們也摸索了很多，遇到過很多困難，確實發現了不少問題。最終嘗試了這種全過程質量保障的方式，在此想跟大家分享下：為什么我們要跳出單一的測試環節，從整個項目研發的全過程出發去關注效率與質量。
產品在進入開發階段后除了編碼引入的bug外，整個過程（打包-提測-發布-監控）都有可能引入質量和用戶體驗問題。而這些過程引入的問題讓我們的技術人員精力分散，效率降低，進而導致質量有所下降。
舉個例子，在打包環節我們曾遇到過這樣的問題：
1、以前要測試IOS-App，沒有mac設備的童鞋必須要找開發人員線下要測試包；
2、IOS-App想要搞內測版，每次必須整理好工程代碼打成壓縮包上傳；
3、android-App雖沒有設備限制大家可以自主打包，但由于太自由了，導致相互測試與調試的包都不夠一致，結果要驗證多次。
4、android客戶端發布前的幾百個渠道包，依靠某程序員單機打包得耗上半天；
這些問題不是引入bug的罪魁禍首，但卻直接影響了找出bug、修復bug的效率。大家希望能有辦法讓項目組能盡可能的專注。所以我們將它關注起來，出現了摩天輪上的打包系統（摩天輪即為阿里無線內部以提升質量和效率為主的一個工具化平臺）。項目打包通過界面配置和系統自動觸發的方式，不但將之前投入到這些工作中的人力解放出來，也避免了以前開發/測試獲取包信息對應不一致，排查問題對不上座的現象。目前已支持全集團40多個app產品的系統打包。
當然提測階段仍然是我們關注做多的一環節，遇到的各類問題更是層出不窮。我們都知道移動應用的測試，除了client端之外，縱向受網絡和服務端的干擾，橫向受各種廠商型號的設備兼容性影響。
再一起來看看下面我們曾遇到的問題：
1、客戶端的測試要如何去便捷覆蓋服務端邏輯？
2、如何從客戶端更直觀的去檢測隱藏在后端的邏輯？
3、不同的機型到底要覆蓋多少才會有底，具體又要如何去選擇覆蓋？
4、移動平臺的多樣性帶來的自動化維護成本，如何才能快速投入產出？
5、穩定性方面的測試投入耗時較多，測試任務繁重。
隨著移動客戶端產品的快速發展，整體的節奏也在加速，無線事業部技術團隊要在1-2周時間內確保一個可以上線的版本而不出大的問題，作為測試人員我們希望跟團隊一起在最后能響亮的對產品質量喊出“YES”，而不是“NO”。
作為產品質量最后的一道把關者，要如何在短時間的快速迭代中高效保證質量？ 質量問題只有在測試環節才被重視和關注么？那么其他環節測試又能做些什么呢？
在最初面對效率與質量，似乎就像魚和熊掌一樣不能兼得的時候，曾不止一次問自己團隊類似的問題。在過去的1年里我們也摸索了很多，遇到過很多困難，確實發現了不少問題。最終嘗試了這種全過程質量保障的方式，在此想跟大家分享下：為什么我們要跳出單一的測試環節，從整個項目研發的全過程出發去關注效率與質量。
產品在進入開發階段后除了編碼引入的bug外，整個過程（打包-提測-發布-監控）都有可能引入質量和用戶體驗問題。而這些過程引入的問題讓我們的技術人員精力分散，效率降低，進而導致質量有所下降。
舉個例子，在打包環節我們曾遇到過這樣的問題：
1、以前要測試IOS-App，沒有mac設備的童鞋必須要找開發人員線下要測試包；
2、IOS-App想要搞內測版，每次必須整理好工程代碼打成壓縮包上傳；
3、android-App雖沒有設備限制大家可以自主打包，但由于太自由了，導致相互測試與調試的包都不夠一致，結果要驗證多次。
4、android客戶端發布前的幾百個渠道包，依靠某程序員單機打包得耗上半天；
這些問題不是引入bug的罪魁禍首，但卻直接影響了找出bug、修復bug的效率。大家希望能有辦法讓項目組能盡可能的專注。所以我們將它關注起來，出現了摩天輪上的打包系統（摩天輪即為阿里無線內部以提升質量和效率為主的一個工具化平臺）。項目打包通過界面配置和系統自動觸發的方式，不但將之前投入到這些工作中的人力解放出來，也避免了以前開發/測試獲取包信息對應不一致，排查問題對不上座的現象。目前已支持全集團40多個app產品的系統打包。
當然提測階段仍然是我們關注做多的一環節，遇到的各類問題更是層出不窮。我們都知道移動應用的測試，除了client端之外，縱向受網絡和服務端的干擾，橫向受各種廠商型號的設備兼容性影響。
再一起來看看下面我們曾遇到的問題：
1、客戶端的測試要如何去便捷覆蓋服務端邏輯？
2、如何從客戶端更直觀的去檢測隱藏在后端的邏輯？
3、不同的機型到底要覆蓋多少才會有底，具體又要如何去選擇覆蓋？
4、移動平臺的多樣性帶來的自動化維護成本，如何才能快速投入產出？
5、穩定性方面的測試投入耗時較多，測試任務繁重。
版權聲明：本文出自51Testing軟件測試網電子雜志第三十期投稿文章中。51Testing軟件測試網及相關內容提供者擁有51testing.com內容的全部版權，未經明確的書面許可，任何人或單位不得對本網站內容復制、轉載或進行鏡像，否則將追究法律責任。