標籤:隱藏 改名 amp 圖片 roi 其他 bsp 相容性 測試
什麼是SDK
本文轉自 http://www.cnblogs.com/milanmi/p/4528031.html 在其中補充了一些情境的考慮,紅標紅處
SDK就是一個程式,提供一些方法,調用這些方法,可以實現一些功能。如:調用銀行提供的SDK,可以實現線上支付的功能。
目前主要接手的SDK有js SDK 和android SDK。JS SDK就是給你一個js檔案,裡面提供一些調用的方法。Android SDK就是提供一個jar包,引用jar包後根據說明文檔,調用裡面的方法。
1、入參和出參:一般SDK說明文檔會提供介面的入參和出參,以及入參的類型、是否必填、邊界值
是否必選:如果文檔裡寫的參數是必選的,可以用null,“” 寫用例
邊界值:一般寫入操作,都會有他的邊界值,這個文檔裡應該詳細有寫。如果參數為1-99 int類型。那用例就是 0,1,99,100來寫用例。如果參數的類型為string 長度為 1-50,就是長度為0,1,50,51來寫用例
參考型別和參考型別:如果參數是參考型別,需要測試null 和“”。如果是實值型別可以對正數、負數、0以及最大值最小值。這個看需求。
特殊字元:可以測一下鍵盤能打出來的特殊字元,如[email protected]#¥%……&*()——+{}P|:"<>?還有中文的特殊字元。
特殊情況:像一些查詢類介面,可以針對*%這種萬用字元寫用例
相同參數不同入參值範圍:像解析度入參值在某個範圍切的圖大小是不一樣的
特殊類型:布爾類型(出參和入參),預設類型(入參),產品類型(出參如火車票類型或機票類型)情境考慮。
隱藏情境:根據依賴第三方資料來源(DB或外部介面),如查詢火車票用戶端只需要在售狀態,但第三方資料來源有在售、停售、預售狀態的三種類型,那需要考慮此三個情境
注意出參細節:很多時候,很多出參往往被大家忽視。以為只要有參數就對了。比如發送圖片介面,返回的width、height、和大小。這些都可能被忽視,以及返回的圖片地址是不是能開啟,大小是否正確。以及圖片被壓縮後是不是符合要求。
注意出參格式:比如有時候用戶端和服務端互動的時候是用xml,但是出參的格式是json。有時候開發忘記解析了,就變成xml,所以這也是一個bug。
注意出參的返回順序:如果出參是一個列表,還要看列表的返回順序是否正確。
2、不同的情境調用
未登入和已登入
網速不好的情況
如果設計到ip電話,可以測wifi 4G 3G 2G,電話中 wifi切換4G,wifi切換3G 等等
使用者被後台刪除的情況
不走尋常路,可能會發現意外的bug:比如之前測試加好友/同意/拒絕這三個介面。如果這三個介面分開測,一點問題都沒有。但是這個情境(A給B發出加好友申請,A再調用同意介面同意B,然後A和B就互為好友。其實應該B同意A才會互為好友)。
3、相容性測試:
android SDK的話,最好多找幾個不同的手機多做一下自由測試。
web SDK的話,最好多找幾個瀏覽器和不同瀏覽器版本多做一下自由測試。
4、反覆測試:
有些靜態變數,在退出後沒有初始化,可能會導致一些問題。比如之前測webSDK,登入退 出登入退出後,請求的地址就變成 http://xxx/Login/Login,原因就是在登入的時候,請求的地址就是url=url+/Login。退出後,沒有對url初始化,所以 多次登入後,url後面就會有很多/Login
5、注意用例的大小寫以及特殊符號的中英文:比如之前有個同事搜尋使用者暱稱介面,使用者暱稱包含英文的(,但是他的入參為中文的(,搜了半天沒搜到,還以為是開發的問題呢。還要後來自己發現了,不然找開發的話,開發會不高興了。
6、考慮全面:比如測試QQ的曆史訊息,不要覺得,發送一條訊息然後能擷取到就行了。其實 我們應該想好曆史訊息的類型,如(文本、表情(ios的表情等等)、圖片、語音、檔案 等等)訊息類型必須全面。其次,應該考慮QQ的用戶端,看一下web端、android端、ios端、windows用戶端 等等 發送的訊息是否沒個端都能擷取曆史訊息。然後再細測 曆史訊息的時間暱稱這些是否正確、以及圖片是否能開啟 儲存的檔案地址是否正確。還有一些特殊的情境,比如改QQ名稱前的曆史訊息和改名以後的曆史消 。還有其他的等等 就靠大家多想啦。
- 邊界值。比如使用者名稱的最大長度為50的情況下:不能建立會議、不能收到離線訊息、等等
- 特殊字元:使用者暱稱含特殊字元不能收到簡訊。發簡訊借口,簡訊內容為特殊字元,會收不到簡訊以及簡訊內容為空白。
- 錯誤提示不正確。
Android SDK Web SDK 介面測試總結