每周總結下自己剛步入這個行業的心得。

希望厚積薄發。

1.意識到測試工作對于App形象的重要性

為什么總會有線上bug沒有被發現修正？

一方面，用戶的使用場景下，App哪怕卡死，自然也就是強制關閉再打開的方法來解決。有極少數客戶，會選擇問題反饋（嚴重影響使用的情況），花時間來上報問題的細節。那么為了維持App的高質量和服務可靠的形象，測試人員要承擔這部分不積極用戶遇到的問題。但是測試人員很難完全模擬用戶所有的使用場景（就像產品經理完全理解客戶也是有一定難度的）。這次測試出來的消息推送彈窗功能場景就不容易想到：需要安裝App，沒有打開通知，兩次App打開時間戳相隔一天以上才能復現的App黑屏卡死問題。我也是大量的UI自動化中遇到的這個問題，然后閱讀代碼去了解這個彈窗出現的邏輯。前提是最近對于Xcode工具又熟悉了一些，對于代碼定位總結出了經驗（可見周期性的總結學到的知識對于之后的工作大有裨益）。

★善用工具

Xcode-可以檢測代碼失誤，比如循環引用、內存泄漏。好處是門檻低：只要會用這個工具，不用懂得太多原理，就可以幫開發者發現代碼問題。即便是某些難以自動化的測試流程，有條件的情況下完全可以連接Xcode等調試工具進行必要檢查測試。安卓同理。接下來花時間學習下安卓系統的常用調試、測試工具，嘗試更專業的眼光發現問題，也幫開發者減輕負擔，更好地溝通。

★不能對不熟悉的需求附加自己的理解

要默認不是bug的心態去和開發溝通。通過產品文檔和產品溝通來確認結果。即便是看上去不太合理的情況、兩個系統客戶端實現不一致的情況，也可能有歷史原因。

★安卓版本技術更新測試的心得

bugA顯示頁面1不應該返回交易頁面，bugB顯示頁面2不應該返回交易頁面。

那么bug數量增加的時候就應該思考，為什么返回的都是交易頁面，這可能是個通病，于是嘗試復現，找出來操作路徑S使得大部分二級頁面返回都去到交易頁面的bug。或者說這些bug可能都是一個技術問題導致的（最后開發的備注也驗證了我這個猜想是正確的）。控制bug數量，提出更貼近開發視角的bug，會使得團隊協作過程效率提升。所以需要關注下同期需求別人提出的bug，然后善于思考、總結、bug歸類。接下來熟悉安卓客戶端的代碼會很有幫助。

2.在測試過程中發現有一些耗時的復制粘貼工作（比如對token進行AES加密之后再用于postman發送請求），嘗試重現產品中的AES加密方案，沒有成功，有時間繼續嘗試。在使用App的過程中，充分思考自己的經驗來發掘問題，找到了幾個問題，比如消息彈窗遮擋問題，和開發溝通后進行了修復并驗證問題的解決。還有一些不確認是否屬于bug的問題，在和同事探討的過程中也增強了對產品的認識。

3.學到的完成某一部分工作的方法，不能完全的照搬和循環，要多加思考，看看是否能夠改進過程和工具來提高效率，從而獲得業務和技能的雙豐收。遇到問題，在自行探索的過程之后，才應該有虛心請教的主動性。不能依賴別人，也不能過于被動而影響進度。

4App看似上層結構簡介明了，其實內部邏輯紛繁復雜，作為剛接觸業務不久的我應該仔細研究各種買賣公式和邏輯，了解App模塊間的跳轉關系和調用邏輯。不然看客戶端代碼都步履維艱。印證了上周例會學到的那句“業務是技術的有力支撐”。

踏下心來，一個個業務模塊總會弄懂，技術也不能落下，優化時間分配，讓兩者輔助發展。

5.關注作為測試人員的基礎、核心能力，規劃成長體系。

不可以貪求學的知識過多、過快、過雜。

目前的規劃是把熟悉業務作為首要條件，在工作中盡可能多的熟知任務的細節，然后扎實地開始學習用例的設計方法。

學一點理論就要嘗試把它實踐一下，結合工作內容進行導向學習。

6.在實施項目的過程中，如果覺得中間容易遇到一些問題，這些問題應該被記錄和總結出來，不管對于自己的積累還是團隊知識的共享，都是很有意義的。

7.基本結論是穩定性和速度上，UITest是優于Appium的。那么支持文檔少的原因，一個是iOS開發者并沒有太多精力來用于測試開發，而測試開發人員又不一定能夠很好的運用Objective-C和Swift語言（總結為門檻稍高，但是Swift很容易看懂，UITest用到的知識也不算太深）。Appium社區多，發展快，是它的兼容性好，多平臺多語言。但是正是這個龐大和臃腫的兼容平臺帶來了環境部署難，運行速度慢，容易崩潰等弊端。借著和iOS開發團隊的溝通支持，和自己已有的對移動端UI編程的了解，希望能把這個心的測試工具引入到生產過程中去。

UI測試的過程中有一些問題是需要解決的，目前遇到的一個情況就是有些元素需要通過一個標志符來獲取焦點，但是并沒有配置Accessbility屬性和標志符，換句話說需要我在源代碼中加上幾個賦值語句來完成用例編寫。這會與業務產生耦合，但是對功能沒影響。目前的方案有兩種：

學習Hook技術，交換函數指針來在殼工程中進行設置Accessbility屬性（待探究，且穩定性未知。可能需要ios開發來支持）。

在對每個版本建立UI自動化工程的過程中，手動的去相應位置、相應元素添加兩行賦值語句。這個手動插入代碼的工作量需要再嘗試寫一些用例才能確定，目測不會太多。（目前優先考慮該方案）

8.多個任務確實容易出錯，電腦都會卡慢。但是兩個任務還是比較高效的，因為有的任務存在等待過程，比如編譯，比如等待發布，等待開發修復操作的間隙。交替執行使得時間利用率更高的同時，也能使得大腦在不同任務間減少單調疲憊感，有利于聯想和創新。

XCUITest in iOS UI自動化

能夠查看完整測試報告，失敗用例會有截圖。

由于支持文檔不是很多，通過蘋果的開發者大會視頻，認識了FirstMatch函數，網上很少提及，因為是Xcode9新增功能。也就是幾個月前發布。合理地正確地使用這個函數能夠提高將近一倍的UI元素查找性能，對整個UI自動化有著重要意義！于是下周會抽出時間把近三年的開發者大會的UITest官方發布內容都過一遍。

解決urs登錄的自動化測試問題時，輸入完整的賬戶名稱，還是會彈出下拉列表提示一些備選的登錄名。這個列表遮擋了密碼輸入框。在沒有找到操作這個列表的方法情況下，換了思路，先填寫密碼，再填寫登錄名稱。感覺有些彎道暫時繞過技術問題，先追求投入產出比再改進技術才是適合任務的思路。同樣的，測試需要了解技術原理（或者說數據流的變化），編輯測試開發代碼的時候也是找到了共鳴。URS登錄頁面的兩種登錄方式通過按鈕切換，實際上不是我理解的切換了一個視圖（從手機號登錄--到郵箱登錄），而是公用一個視圖，寬度是屏幕兩倍，隱藏了拖動條。所以我操作的登錄按鈕總是找不到。

關于各角色的思路：

開發者：修復bug，驗證沒問題即可。

???????????測試：哪里都不能有問題，A頁面調用的C功能，和B頁面調用的C功能是不是同一段代碼？

??????? 在素材自動化配置的過程中，測試出不能編輯配置的bug，修復完成后，詳情頁面可以編輯了，列表頁面還是不能編輯。最終證明這是同一個函數調用，出現在相似的兩個地方，只改了一處。這也給測試提供了一個思路，有時間就去讀一下代碼，就算沒時間也要推斷同樣業務的多個入口是否也可能存在同樣問題。

9.測試工作要往前趕（保持認真的前提下），留有一點空間給意外和新需求，因為新需求測試可能會比想象的復雜些（耗時間久）。

從中學到兩點：

????????????????????????????一個是代碼修改需要重新評估回歸測試范圍，了解bug的群集性。

? ? ? ? ? ? ? ? ? ? ? ? ? 一個是經典核心功能不能認為測試得多就穩定，要當做全新App去認真回歸

10.隨著對UI自動化操作的熟悉，能夠發現不同現象（iOS 9系統下密碼輸入框找不到，“智投獨家”按鈕找不到）在技術原理上的共同點，可能是都使用了自定義的UI組件，而不是常規原生組件。所以沒有很好地支持Accessbility輔助功能定位，需要走進源碼探究。在iOS開發的幫助下，學到了快速定位UI控件在代碼中的位置的方法。每個操作能提升下效率，那么整個工程就能得到推進。（共鳴：工欲善其事必先利其器）

在視頻懸浮窗的關閉按鈕上，iOS 9系統能找到關閉按鈕，但是tap（）點擊操作無效（點擊操作無效問題在iOS 9的別處UI也很常見）。最終的解決方案是找到的按鈕的位置信息，計算出一個坐標在它內部，利用坐標的tap來完成button的tap（）。問題是暫時解決了，但是最好搞清楚無效的原因，因為繞過的小問題太多終會導致出現棘手的、無從下手的大問題。暫時能用為主，初期需要效率。

11.最近了解了下做好測試工作的技能樹。結合談下自己的感悟：

我抽空大概閱讀了主站的接口測試工程代碼，case邏輯是很相似，參考編寫應該不會太難。但是讓我寫可能會漏掉業務重點，總之需要結合手工測試來確認接口在整個工程中的地位，才容易寫出覆蓋更全面的用例。包括在組里的有道云協作分享的知識中，也看到說：通過閱讀后臺源碼、了解業務，才能發現沒有覆蓋到卻有必要驗證的函數部分。

測試掌握多種語言、了解并嘗試拓寬廣度到性能、電量、穩定性等專項測試，是有必要的。當然是把技術應用到業務中產生效益才有意義。自己會初步探究使用穩定性測試工具、性能測試工具來幫助提高和保證App產品質量的方法。不斷積累知識，在各個方面，希望產生量變和融會貫通的效果。

通過不斷地總結業務性強的需求，增進對業務的了解。

12.在測試過程中如果發現重復或者過于復雜的操作，要時刻嘗試去縮短操作流程，提高效率。前提是保證本次測試任務按時完成（第一原則）。

另外就是要多熟悉已有的測試平臺、工具和項目，思考它們之間的關系，才能改進工作流程而從中受益。

13.★提高效率的途徑中，我思考過“工具”和“方法”：

上周的ipa文件安裝屬于“工具”，那這次復現在線bug路徑就屬于“方法”了。

①這次復現一個【編輯交易品】閃退的線上bug，感受就是首先相信bug的產生大多不是代碼偶然，代碼是靜態的，接口也相對穩定的情況下：就是探尋一個必現路徑的過程。開始只是知道“操作復雜”導致閃退

-->交易Tab下的操作

-->和開發探討編輯交易品的情景，結合bugly的堆棧信息推測數組是否越界、刪除點擊操作和長按移動操作是否沖突等等原因

-->嘗試減少商品數量驗證越界（采用手機屏幕錄制來統計規律：比如商品個數變化，種類的排列規律、是否移動了首末元素等）

-->最后得到較小的復現路徑范圍：只需要來回交換商品順序，不需要增刪就能發生閃退。

?開發最終定位的原因：動畫未完成的時候點擊了“完成”按鈕，說明之前總結商品排列規律的思路是走偏了，所以提供了新的bug定位經驗-快速操作。

以后還可以通過快速操作來檢查代碼的問題，這部分UI自動化的操作速度會明顯優于人工。

②還有一個返回箭頭部分頁面顯示不完整的問題，開發備注的原因是“部分頁面使用了自定義的返回實現”。這就印證了我寫UI自動化代碼的時候為什么統一實現的返回函數在一些地方不起作用。隨著對產品、代碼的深入理解，對編寫自動化項目和發現更多使用問題起到促進作用，相輔相成。

必現&偶現

理論上所有偶現的crash，找到出現條件都能必現。但是沒找到就不是必現的。

★測試的一部分工作需要開發視角

測試微信助手的過程中，學習到了看開發者日志的方式，有助于增進定位問題的能力，更方便地和開發溝通。

盡管不看源碼，也要理清楚代碼操作數據的邏輯，就像開發者在設計新增需求鎖改動和增加的數據。

業務的改動有很多是基于某塊功能的完善，所以隨著接觸不同功能模塊，測試越來越得心應手，效率提升，對內容的掌握也增進。尤其是微信助手這樣的App，體量不算大，是個訓練測試思想、技巧的好項目。

14.探究iOS的Monkey測試工具，閱讀源碼

對之前的Appium的測試環境原理加深了理解，在一個領域之內的各個項目之間研究和應用會明顯感覺到有些觸類旁通。學習不能操之過急，有目的性和耐性才能逐個攻破。

舊的技術UIAutomation被逐步取代，新的XCTest也被開發者們開始利用，基于XCTest的C/S模式測試也興起，FastMonkey基于此進行改進。

感覺有時候并不知道解決問題的本質，但是找了一些帖子照做就繞過去了，希望隨著Xcode使用越來越多能夠漸漸明白。

15.★Xcode Instruments心得

工具使用方便，功能全面。在接下來對App質量掌控上能夠給與很大的幫助。之前對于UITest過程中上一步還能找到按鈕，點了一下其它按鈕就找不到原來的這個按鈕的情況一致覺得莫名（甚至想歸結為UITest的技術不成熟）。最終發現是CPU占用超標，導致的隨機性失敗。CPU超標的原因可能有很多種。

★不積累疑問，盡量研究透徹

對于代碼質量的提升是沒有上限的，包括可讀性、穩定性、可擴展性和實現原理的方方面面。UITest這一輪CPU指標糾錯，讓我認識到Xcode10必須清理并重新編譯才能實現代碼效果的bug對開發團隊影響之大。也發現自己實現用例過程中基于單一機型實現的能用即可的代碼對穩定性帶來的不利影響。不斷地去定位代碼和增加Accessbility屬性的過程，已經帶著我越來越清晰地認識了各個模塊的實現方式，對于之后bug的定位理解都會有幫助。

★要找準解決問題的方向

有問題是需要一些經驗來推測的，但是如果推測方向失誤，那么可能會走很多彎路。比如tab找不到去推測多window導致的，其實是CPU超負荷之后客戶端無法承擔UITest的查詢。最終鎖定CPU超負荷是快訊頁面引起的。首次啟動App的廣告頁測試失敗可能也與此有關，因為此時App已經開始在渲染planA的快訊頁面了。實踐出真知，把快訊頁面臨時替換成空白頁面，來觀察CPU的表現，從而得出進一步的定論。

16.★意識到測試工作對于App形象的重要性

為什么總會有線上bug沒有被發現修正？

一方面，用戶的使用場景下，App哪怕卡死，自然也就是強制關閉再打開的方法來解決。有極少數客戶，會選擇問題反饋（嚴重影響使用的情況），花時間來上報問題的細節。那么為了維持App的高質量和服務可靠的形象，測試人員要承擔這部分不積極用戶遇到的問題。但是測試人員很難完全模擬用戶所有的使用場景（就像產品經理完全理解客戶也是有一定難度的）。這次測試出來的消息推送彈窗功能場景就不容易想到：需要安裝App，沒有打開通知，兩次App打開時間戳相隔一天以上才能復現的App黑屏卡死問題。我也是大量的UI自動化中遇到的這個問題，然后閱讀代碼去了解這個彈窗出現的邏輯。前提是最近對于Xcode工具又熟悉了一些，對于代碼定位總結出了經驗（可見周期性的總結學到的知識對于之后的工作大有裨益）。

★善用工具

Xcode-可以檢測代碼失誤，比如循環引用、內存泄漏。好處是門檻低：只要會用這個工具，不用懂得太多原理，就可以幫開發者發現代碼問題。即便是某些難以自動化的測試流程，有條件的情況下完全可以連接Xcode等調試工具進行必要檢查測試。安卓同理。接下來花時間學習下安卓系統的常用調試、測試工具，嘗試更專業的眼光發現問題，也幫開發者減輕負擔，更好地溝通。

★不能對不熟悉的需求附加自己的理解

要默認不是bug的心態去和開發溝通。通過產品文檔和產品溝通來確認結果。即便是看上去不太合理的情況、兩個系統客戶端實現不一致的情況，也可能有歷史原因。

★安卓版本技術更新測試的心得

bugA顯示頁面1不應該返回交易頁面，bugB顯示頁面2不應該返回交易頁面。

那么bug數量增加的時候就應該思考，為什么返回的都是交易頁面，這可能是個通病，于是嘗試復現，找出來操作路徑S使得大部分二級頁面返回都去到交易頁面的bug。或者說這些bug可能都是一個技術問題導致的（最后開發的備注也驗證了我這個猜想是正確的）。控制bug數量，提出更貼近開發視角的bug，會使得團隊協作過程效率提升。所以需要關注下同期需求別人提出的bug，然后善于思考、總結、bug歸類。接下來熟悉安卓客戶端的代碼會很有幫助。