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