SDK怎麼測試？俺不會啊

測試蔡坨坨發表於2022-11-28

轉載請註明出處❤️

作者：測試蔡坨坨

原文連結：caituotuo.top/7bc8d1c8.html

你好，我是測試蔡坨坨。

眾所周知，在雲產品和SaaS蓬勃發展的當下，企業中有許多系統和環節都是依賴於第三方提供的服務或應用，而不必自己去搭建和實現，從而節省人力和物力，避免重複造輪子。

第三方應用可以透過廠商提供的API或SDK等形式整合。

對於測試同學來說，API測試，也就是所謂的介面測試，應該是再熟悉不過了，但對於SDK的瞭解以及測試可能就沒有API那麼熟悉了。

所以，今天我們就來聊一聊什麼是SDK，以及SDK如何測試。

什麼是SDK

SDK的全稱是Software Development Kit（軟體開發工具包），通常包括SDK介面、開發文件和Demo示例等。

API的全稱是Application Program Interface（應用程式介面），就是軟體系統不同組成部分銜接的約定。

API和SDK的區別

常見的API形式有http協議請求介面、websocket協議請求介面等，而SDK可能是xxx.jar、xxx.war、xxx.py、xxx.framework、xxx.a、xxx.aar、xxx.so等。

通俗地說，API可以比作房門鑰匙，在一個房子裡，每個房間有不同的用途和資源，想要獲取相應房間的資源，我們需要先用鑰匙開啟房間門，比如去書房拿書、去臥室拿枕頭，都需要先找到相應的房間鑰匙，而拿書和拿枕頭的過程，就是呼叫API的過程，也就是鑰匙開門的過程。

SDK相當於一個大的工具包，把這些鑰匙都串在一塊兒，將API集合到一起，擁有SDK，便可以在該房子裡暢通無阻，想要哪個房間的資源，就呼叫相應的方法。

兩者的區別就是，API是一個確定的功能，明確了它的作用，而SDK是很多方法的集合體，只要引入SDK工具包，無論想實現什麼，SDK裡總有能實現的方法。

簡單來說，SDK=放著你想要的軟體功能的工具包，API=SDK上唯一的介面。

API舉慄：

http介面文件：

名稱: 全國高校資訊查詢介面
描述: 用於查詢全國高校資訊
Host: www.iamwawa.cn
Request URL: /home/daxue/ajax
Request Method: POST
Content-Type: application/x-www-form-urlencoded
headers: user-agent:Chrome

呼叫：

呼叫http介面的方式有很多，比如postman、apifox、jmeter、python requests、java httpclient等。

SDK舉慄：

騰訊雲簡訊xxx.py包：

呼叫：

透過編寫程式碼呼叫SDK工具包。

# -*- coding:utf-8 -*-
# 作者：測試蔡坨坨
# 時間：2020/12/3 16:46
# 功能：傳送簡訊SDK

from django.conf import settings
from qcloudsms_py import SmsSingleSender
from qcloudsms_py.httpclient import HTTPError


def send_sms_single(phone_num, template_id, template_param_list):
    """
    單條傳送簡訊
    :param phone_num: 手機號
    :param template_id: 騰訊雲簡訊模板ID
    :param template_param_list: 簡訊模板所需引數列表，例如:【驗證碼：{1}，描述：{2}】，則傳遞引數 [888,666]按順序去格式化模板
    :return:
    """
    appid = settings.TENCENT_SMS_APP_ID  # 自己應用ID
    appkey = settings.TENCENT_SMS_APP_KEY  # 自己應用Key
    sms_sign = settings.TENCENT_SMS_SIGN  # 自己騰訊雲建立簽名時填寫的簽名內容

    sender = SmsSingleSender(appid, appkey)
    try:
        response = sender.send_with_param(86, phone_num, template_id, template_param_list, sign=sms_sign)
    except HTTPError as e:
        response = {'result': 1000, 'errmsg': "網路異常傳送失敗"}
    return response

SDK層級結構及測試

如果把SDK想象成一個洋蔥，你認為它是一個什麼樣的層級結構？

  • 程式碼層

    最裡面的一層就是程式碼層，程式碼層是SDK的基石，決定了後面的走向。

    那麼基於程式碼層，我們可以去做哪些測試呢？

    • 首先是單元測試，這個主要是針對開發同學需要關注的場景，需要對一些具體的業務邏輯進行單元測試，這部分可能測試同學會使用的比較少，單元測試一般會用到Junit單元測試框架、Mockito Mock框架、Jacoco程式碼覆蓋率統計工具等，對於程式語言的瞭解程度還是有比較高的要求，如果測試同學對於語言比較瞭解的話，也可以考慮自己寫單元測試。

    • 其次，基於程式碼的話，我們還可以寫一些介面測試，介面測試的語言能力要求相對於單元測試來說會稍微低一點。業務程式碼最終使用的是SDK提供的介面，內部實現的黑盒就可以讓開發去保證質量，從測試的角度，我們只需要測試它的公開介面，保證這些公開介面沒問題，而且這種也是價效比比較高的方式。

      針對於程式碼層級的介面測試，通常我們會選用原生的語言去實現，比如這個SDK是用Java寫的，那麼我們就用Java去寫用例，這一點與下面要說的二進位制產物層級的介面測試會有一些區別。

    • 除了單元測試和介面測試以外，還有一些可以做的程式碼層測試，比如靜態程式碼掃描，現在還是有挺多靜態程式碼掃描工具的，例如：SonarQube、Scanmycode、Checkstyle、FindBugs、PMD、Jtest Pyflakes、Pylint、pep8、FxCop、StyleCop等，其原理就是在寫完程式碼以後，不需要編譯或者構建，直接用掃描工具對程式碼進行掃描，找出來裡面存在的語義缺陷或者安全漏洞，這種掃描一般掃的是程式碼的問題。

    • 另外我們還可以用一些指令碼去檢測程式碼中的敏感資訊，比如：硬編碼域名資訊、使用了一些不可商用的開源庫的License、海外版本的App中有中文（有可能影響上線海外App應用商店），像這些都有安全審計的風險，都可以用程式碼掃描的方式進行檢測。

      並且這些掃描可以做成增加掃描的形式，就不用每次都全量掃描，從而加快執行速度。

  • 二進位制產物

    程式碼層再向外一層就是二進位制產物層。

    基於二進位制產物，可能是xxx.jar、xxx.war、xxx.py等工具包，對於這樣的二進位制產物，我們可以測試什麼呢？

    • 因為從程式碼到二進位制產物，其實已經完成了構建的過程，也就是說它可以直接被執行和呼叫。因此我們可以做一些介面測試，與程式碼層的介面測試有點不一樣的是，程式碼層的介面測試一般推薦使用原生語言進行測試，但是在二進位制產物層的介面測試，我們還可以使用其他的語言，比如：要在Python中呼叫xxx.jar包，就可以藉助Jpype來實現，從而在Python專案中也可以呼叫Java類和方法。
    • 如果在SDK中呼叫了一些高敏感的API，我們在這個層級也可以用一些工具進行掃描和攔截。
    • 包大小的檢測，SDK包的大小會直接影響使用者的下載和使用率，也是一個非常重要的指標，有資料表明，apk的包體積每上升6M，下載轉化率就會降低1%，接近20%的使用者都會因為儲存空間有限而解除安裝應用。

  • Demo

    再向外我們來到了Demo層。

    一般是進行功能測試和效能穩定性等專項測試。與其他需求測試一樣，需要進行測試排期，分配人員和時間，走提測流程的。

  • 整合應用

    最外層就是SDK測試完成後，還需要基於整合包進行的測試，SDK本身沒有問題，不代表它接入到其他業務系統就沒有問題，很多SDK的問題其實都是出現在業務的配合上，比如SDK的某一個功能設計者設計它的時候希望它是一個呼叫頻率很低頻的操作，但業務在實際呼叫的時候做成了比較高頻的呼叫，那這種情況就會產生一些效能問題，像這種可能就是在整合的階段才會發現。

    除此之外，還有對鑑權的測試，SDK通常會有一套鑑權和呼叫系統，在結合業務的時候，業務系統也會有一套鑑權機制，那麼兩者之間建立的對應關係有沒有問題。

    再有就是UI規則，比如說業務系統本身有一套UI規則，與SDK不一致，還有就是SDK與業務系統之間的資訊傳遞，這些都是比較常見的問題。

    整合應用的測試一般會跟著版本走，SDK測試得差不多了，才會進行整合應用的測試，太早的話可能SDK都還沒測完，太晚的話出現問題可能來不及改，根據業務發版週期選擇合適的測試時間。

從SDK的層級體系來看，其實是一個從內到外、從白盒到黑盒過渡的一個測試體系。

Demo階段的SDK如何測試

Demo階段的SDK測試，簡單來說就是對提供給其他開發者的工具包裡面的內容進行測試。

而SDK通常包含SDK介面、開發文件和Demo示例等。

因此，測試的主要內容就有SDK介面文件、日誌、Demo。

測試型別有功能測試、效能測試、相容性測試、穩定性測試、網路相關測試、安全性測試等。

並且最終還可以實現SDK的自動化測試。

SDK介面文件測試

主要檢查文件是否完整、正確、清晰，比如：接入指南是否包含了環境依賴說明、整合方法說明、呼叫方法說明，介面文件的方法、引數名稱、引數型別、引數描述、是否必填、示例、返回值等。

日誌測試

對開發者來說，SDK介面裡面的具體實現都是透明的，當上層呼叫遇到問題時，只能依賴SDK列印的日誌來定位分析，所以日誌是否完備，是否有助於解決問題，對應用開發者和SDK提供方來說都很重要。

Demo測試

Demo是SDK提供方用來演示如何呼叫介面實現具體的功能，可以讓其他開發者直觀地感受SDK的接入效果，可以較明確的知道接入這個SDK做出來的產品效果如何，因此也是我們測試的重點，應該儘可能多的覆蓋各種業務場景。

功能測試

保證SDK介面功能的正確性和完備性，客戶端SDK介面測試跟服務端介面測試類似，包括場景覆蓋和介面引數覆蓋，主要測試各種引數組合下的返回值，資料是否快取與儲存，是否有回撥，對於請求成功或失敗都能按預期進行處理。

效能測試

保證SDK介面滿足特定的效能需求，比如：資源佔用、響應時間等。

相容性測試

保證SDK相容特定的裝置平臺，並與其他軟體相容。

穩定性測試

測試業務場景在一定壓力下，持續執行一段時間，介面功能和裝置資源佔用有無異常。

網路相關測試

不同網路型別，不同網路環境下，SDK介面都能較好的處理，比如弱網測試。

安全性測試

對隱私資料的保護，訪問許可權的控制，使用者服務的鑑權等。

自動化測試

與介面自動化測試類似，我們可以將Demo測試寫成自動化指令碼的形式，比如使用TetsNG框架並持續整合到Jenkins，方便快速回歸。

相關文章