測試分享

前言

        從某種程度來說,每一個測試人員就像偵探小說裏面的“福爾摩斯”,不過工作的領域不同罷了。那麼,要當一名測試領域的合格偵探,就要保持着對問題的敏銳觸覺,這種觸覺,就是從平日的工作中不斷思考得來的,在這個方面,我並沒有什麼發言權。所以在此我也就不再贅述了。那麼,本篇文章分享的重點是什麼呢?下面就要揭開謎底,本文分享的主題就是將一些研發常用的排查定位問題的方法分享出來,促進測試同研發之間的協同效率;當然,同時也會帶給大家一些研發部門提升工作效率黑科技的分享,提升大家的工作效率。
        當然,需要大家提前做好準備,比如安裝我們的工具軟件等等,首當其衝必須要的就是谷歌的chrome瀏覽器,其次是fiddler抓包工具等。

1 問題的引入

        思考了很久,到底應該如何引入本文要討論的話題,最終得出的結論是以一個小故事的形式來引入這個問題。
        既然是小故事,下面就來看看劇本吧!

故事背景(故事背景純屬虛構)
        某日,一位測試攻城獅A找到程序猿同學B,正當程序猿心猿意馬的時候,暗想着這次一定要撩到妹。A開口了,你這裏有bug,瞬間B被從天堂拉到了地獄。


臺詞
B:我這裏是好的,你看?
A:我剛纔明明不行啊?
B:可能是數據問題?
A:我覺得這是個bug,你們改一下吧
B:無法復現啊,怎麼改
A:你改不改,不改讓我們老大和你們老大協調下這個問題?
B:。。。。


故事結果
        最終的結果很好想象,那就是B同學默默的尋找bug,然後修改之。

2 實際的問題是什麼?

        事實上,到了這裏,我們需要思考實際的問題是什麼?我們常常會遇到這樣的問題,當我們的福爾摩斯將錯誤發現以後,會記錄下來,繼而去發掘下一個問題,但是,對於一些難以復現的case而言,這裏就出現了問題。因爲當我們把問題拿過去交付給研發的時候,常常又是好的。
        這個時候,我們該怎麼做呢?保存第一手資料實在是過於重要,這往往可以解決大量時間。所以,對於bug出現地方的保存,真的可以相比犯罪現場的保存,所以,首先保存好犯罪現場。
        好了,現在就可以拿着犯罪現場的第一手樣本去找程序猿同學了。這不僅方便了自己,也方便了程序猿同學們。


        那麼,哪些東西是需要保存的?下面告訴你需要保存的東西。

需要保存的東西:
1:出現問題接口的track_id
2:出現問題的商品url


3 從程序猿的角度看世界

3.1 前言

        研發與測試之間其實往往是水火不容的,他們之間的相互理解其實是不夠的,這是因爲什麼呢?是因爲兩者的工作屬性本身就是對立的。
        當然,每一個職業都有着每一個職業的迷人之處,那麼,現在一起來感受下研發看問題的角度,想象一下,當你把問題交給程序猿同學的時候,已經定位到問題的大致所在了,這時看着程序猿同學的眼珠子,都快瞪出來了。

3.2 需要的技術積累
3.2.1 接口請求的一般流程

         之所以要從接口請求的流程說起,是爲了讓大家對於程序員同學目前涉及的技術體系有一個比較全面且直觀的認識。對於接口的一般請求的流程開始分析之前,我們先來分析這其中都要涉及到哪些功能模塊。圖3.1即爲涉及到的模塊。



這裏寫圖片描述


圖3.1 模塊組成圖

         圖3.1已經列出了涉及的重要模塊,那麼每一個模塊都是幹嘛的?有什麼作用呢?下面就結合接口請求的一般流程來對每個模塊的在這個流程中所擔當的角色做一個說明。
        當我們拿到APP或者打開一個網頁的時候,我們知道,我們可以看到一個比較友好的畫面,這也就是俗稱的用戶界面,洋玩意叫“USER INTERFACE”;這個界面一般來說是經過我們的設計師和前端工程師精心打磨的。
        接下來,我們要開始我們的行動了,舉個例子來說,我看到了一個特價促銷的商品,我已經按捺不住自己體內的洪荒之力了,我要買買買,於是你急切的按下了購買按鈕,此時,系統就開始請求接口了,一般而言,我們現在前端與後臺之間的耦合都是依賴於HTTP協議的。接口的請求在網絡下的支持下到了後端,此時,後端拿到接口帶來的信息,進行分析,迅速的取出其中有用的東西。進行進一步的分析,然後在數據存儲的倉庫中取出所需要的信息,交給業務邏輯模塊在此組裝,返回出去,此時,前端在接收到信息之後,友好的給你展示一個確認訂單的界面,那優雅的切換簡直讓你心情都愉悅了不少。這就是一個請求的完整流程,此時,剛纔那個還活蹦裸跳的接口也就走到了生命的盡頭,從他開始將貨物卸下的那一刻,它的使命也就終結了。下面,我們就以一幅圖的形式來展示,如下所示:
接口請求流程圖

圖3.2 接口請求流程圖


        圖3.2明確的展示了一個接口從前端到後臺的完整流程,當然,這是經過簡化的流程,實際的流程可能比這個要複雜,但是這並不影響我們的理解。而這裏面涉及到的技術細節我們並不care,我們care的是,你說一次接口調用的成功與否到底應該如何來界定呢?那就進入下一節,HTTP協議的狀態碼。


3.2.2 HTTTP協議狀態碼

        大家應該都知道莫爾斯電碼,說到這裏,可能有的小夥伴會問:這和HTTP協議有啥關係?我們可以想一下,莫爾斯電碼是爲了幹嘛,是爲了傳遞信息,那麼在信息的接收方和信息的傳輸方之間一定有着一種統一的約定,這種統一的約定其實就是一種協議。我們的HTTP協議對於接口是否成功的調用,也就是說是否有正確的返回也是有着一定的一定的標示的,這就是狀態碼。
        那狀態碼到底怎樣纔是正確的呢?一般而言看,返回200是我們最希望的。但是,HTTP協議本身是比較複雜的,比較常用的有200、302、404、503等等。最常見的就是200和404了,那麼,我們去追蹤接口的狀態,其實不需要了解的那麼清楚。遇到一個不懂的狀態碼當然就可以查嘍。
        當然,在附錄中1中我給大家準備了查詢的網址,方便大家的查詢,那裏有最全的http狀態碼。

3.2.3 常用調試工具-chromeDevtools的使用

1:控制檯的使用
        谷歌真的是一個非常棒的公司,其產品也往往讓我們感到驚豔,比如說chrome瀏覽器,真的是谷歌的良心之作。
        下面,我們來看看谷歌瀏覽器的調試模式-也就是其devTools的使用。首先,如何從一個正常的頁面進入到調試模式呢?只需要同時按住ctrl+shift+i即可。進入的界面一般而言是這樣的。


進入dev


        我們可以看到,畫面變形了,那是因爲我們對移動端做了適配,而pc的話,就顯得有點比例不協調了。但是大家不要慌,調試模式爲我們提供了移動端的模式,具體如何打開呢?如下圖所示:



打開適配器


        打開後的效果如下圖所示:


打開


        當然,你以爲這就是所有,其實不然,還可以選機型呢,哈哈,是不是感覺不能在貼心了。這是因爲前端同學必須適配不同的設備,蘋果倒還好說,android由於各種廠家的存在,手機的尺寸是千變萬化,所以,前端同學要想設計出兼容各種設備的網頁,也會比較複雜的。設計出來後,往往還得找各種各樣的主流機器來測,谷歌的這個功能真的是很不錯。現在看來,我們可以同時有多個手機進行測試了,這個功能不就解放了你手裏的手機嗎,一個測試機加上chrome,從此不再爲機器不夠而憂愁。
        下面,我們要說的是什麼呢?其實通過調試模式我們可以看到頁面上呈現的各種數據,我們前面也提到過,請求接口的時候返回的數據會在界面上以合適的格式展示出來。比如說商品的上下架狀態等等。當然,這需要藉助調試工具的控制檯來實現。在進行之前,我們先來看看調試工具都有哪些的功能?


調試


        如上圖所示,我們可以看到其有很多的功能,我們這一節主要強調的就是控制檯-console。
在控制檯裏面,我們可以使用相關的命令來查找一些數據節點的信息。如下圖所示:


查詢


        上圖展示了在APP.goodsInfo裏面有一個shelves字段,這個字段就表示的是商品目前處於上架狀態,當然1就是上架狀態。在這裏把這個地方提出來一方面是要給大家說明數據和展示之間的對應關係,另一方面,希望大家對自己所瞭解的業務的常用字段有一些瞭解,這也是有益於大家對整個系統的理解的。
        控制檯能幹的事情還很多,當然,這就要求大家去自己探索了,在此不做贅述。
2:network查看ajax請求的相關內容
        上一節,我們談到了devTools的控制檯的使用,下面,我們要來看接口的請求了,我們利用的是network這個小工具項。
當我們選擇到這個工具上的時候,我們就可以看到接口的請求了,如下所示:


這裏寫圖片描述


        大家可以看到,這裏調用了最主要的接口是goodscommon,這個接口幾乎封裝了關於商品的所有信息。我們來分析裏面的幾個關鍵屬性,來一張清晰的圖進行分析。


分析


        我們可以看到,狀態碼爲200,這就是我們需要的結果,當然,出現別的狀態碼就要警惕了。其次,xhr代表的是一種異步的請求技術,這裏不做過多說明。剩下的參數就是耗時之類的玩意。其實,這裏還可以點進去,在進行更加細緻的分析。


具體分析


        這裏的headers之類的不重要,我們主要的關注response,這是接口的返回參數,我們要看其是否正常返回。這裏,對network這個點的介紹基本就結束了。當然,谷歌瀏覽器不止這些功能,其調試器也沒有分析完,有興趣的同學可以自行研究,在後面的附錄2將會給大家帶來chrome瀏覽器的一些使用技巧。幫助大家提高工作的效率。

3.2.4 fiddler抓包工具的使用

        最後要講解的一個工具就是fiddler,前面我們講解的devtools主要針對的是H5,下面的重點自然就落在了APP之上。
        fiddler也是一款優秀的用於網絡調試的工具。在日常的開發及測試中其使用的頻率也是非常高的,下面,我們就來學習如何使用此工具進行抓包。首先來看下fiddler軟件的主界面。


fiddler


具體的配置可以參考如下的博客:
fiddler配置博客


        如果大家還不懂,不要着急,到時候我會帶着大家一起去做的。前面我們還提到過,要保留案發現場,這裏的話主要就是track_id了。如果遇到異常,一定保留當時異常報錯接口的track_id.

4 常見的問題點

4.1 接口無法返回

        這個錯誤就屬於比較實在的錯誤了,不帶任何的拐彎抹角,最常見的排查方法就是看HTTP接口的返回碼了。

4.2 返回的數據異常

        數據返回異常就屬於邏輯上的問題,此問題是不好排查的,基本上都要深入到代碼層面。

5 總結

        本文從接口的請求、涉及到的模塊、以及常用的調試工具作爲主題,細緻的介紹了排查問題所需要涉及到的種種工具。希望能帶給大家收穫!

附錄
1. http協議狀態碼一覽表
2:使用ps實現桌面搜索
3:chrome瀏覽器使用技巧
4:searcheverything文件搜索的使用

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章