概述

軟件開發(fā)套件（SDK）是通常由硬件平臺、操作系統(tǒng)（OS）或編程語言的制造商提供的一套工具游昼。

經(jīng)常使用的場景：

為什么使用SDK？

SDK可協(xié)助軟件開發(fā)人員面向特定的平臺遗座、系統(tǒng)或編程語言創(chuàng)建應(yīng)用豆瘫。它就像是一個(gè)工具包，讓您可以自行的組裝寺董，知識對象是應(yīng)用開發(fā)而已覆糟。您所需的構(gòu)建塊和工具，根據(jù)制造商而異遮咖。SDK被開發(fā)出來是為了減少程序員工作量

一個(gè)基本的SDK通常由編譯器搪桂、調(diào)試器和應(yīng)用編程接口（API）組成，包含一下內(nèi)容：

文檔、庫踢械、編輯器酗电、運(yùn)行的開發(fā)環(huán)境、測試分析工具内列、驅(qū)動程序撵术、網(wǎng)絡(luò)協(xié)議

客戶端SDK測試的對象

SDK接口和文檔

SDK接口是測試的主要對象，也是核心的內(nèi)容

SDK日志

對開發(fā)者來說话瞧，SDK接口里面的具體實(shí)現(xiàn)是透明的嫩与，當(dāng)上層調(diào)用時(shí)遇到問題，只能依賴SDK打印的日志來定位分析交排。所以SDK日志是否完備划滋，是否有助于解決問題，對應(yīng)用開發(fā)者和SDK提供方來說都很重要

Demo或行業(yè)解決方案

Demo是SDK提供方用來示例如何調(diào)用接口實(shí)現(xiàn)具體的功能埃篓，也可以作為開發(fā)者直觀感受SDK接入效果处坪。行業(yè)解決方案類似Demo，但是架专，比Demo更加像一個(gè)產(chǎn)品同窘，具有比較完整和典型的行業(yè)應(yīng)用場景〔拷牛可以讓行業(yè)開發(fā)者比較明確知道想邦，接入這個(gè)SDK做出來的產(chǎn)品效果如何

客戶端SDK接口測試類型

客戶端SDK根據(jù)需求和開發(fā)平臺不同，可能需要選擇不同的測試類型對SDK接口進(jìn)行測試

常見的測試類型有：

1委刘、功能測試

保證SDK接口功能正確性和完備性丧没。客戶端SDK接口測試跟服務(wù)端接口測試類似锡移，包括場景覆蓋和接口參數(shù)覆蓋呕童，主要測試各種參數(shù)組合下的返回值，考慮數(shù)據(jù)是否緩存與存儲罩抗，是否有回調(diào)拉庵，對于請求成功或失敗都能按預(yù)期進(jìn)行處理

2、性能測試

保證SDK接口滿足特定的性能需求套蒂，比如資源占用钞支、移動設(shè)備耗電量等。在云信IM登錄的場景操刀，登錄時(shí)可能收到大量同步數(shù)據(jù)包和離線消息包烁挟，那么對這些數(shù)據(jù)包的解析以及本地儲存的性能就要進(jìn)行保證，否則可能出現(xiàn)登錄響應(yīng)很慢甚至卡住的問題骨坑，所以測試時(shí)就需要考慮這個(gè)場景的性能

3撼嗓、兼容性測試

保證SDK兼容特定的設(shè)備平臺柬采，并與其他軟件兼容。兼容設(shè)備平臺的工作量通常是比較大的且警，先根據(jù)產(chǎn)品需求和市場現(xiàn)狀對需要適配的設(shè)備平臺做分析粉捻，再根據(jù)需要覆蓋的機(jī)型、系統(tǒng)版本斑芜、分辨率等進(jìn)行優(yōu)先覆蓋排序肩刃，移動端SDK兼容性測試需要考慮下對模擬器的支持，因?yàn)楹芏嚅_發(fā)者可能就是先在模擬器上開發(fā)杏头∮客戶端SDK覆蓋多平臺設(shè)備的，還要考慮多端消息數(shù)據(jù)包的互通

4醇王、穩(wěn)定性測試

考察業(yè)務(wù)場景在一定壓力下呢燥，持續(xù)運(yùn)行一段時(shí)間，接口功能和設(shè)備資源占用有無異常寓娩。比如云信實(shí)時(shí)音視頻通話場景中叛氨，要保證多人長時(shí)間通話且不斷有人進(jìn)出時(shí)的接口功能和設(shè)備資源占用無異常

5、網(wǎng)絡(luò)相關(guān)測試

保證在不同網(wǎng)絡(luò)類型根暑，不同網(wǎng)絡(luò)環(huán)境下力试，SDK接口都能較好的處理徙邻。在涉及到多媒體資源或音視頻通信排嫌，弱網(wǎng)下測試的需求較多，并且弱網(wǎng)下的處理通常需要反復(fù)優(yōu)化和對比缰犁，不僅是新老版本效果對比淳地，還包括競品的效果對比測試

6、安全性測試

對隱私數(shù)據(jù)保護(hù)帅容，訪問權(quán)限的控制颇象，用戶服務(wù)鑒權(quán)等，SDK接口的安全性問題也是比較突出并徘。安全性很多是在架構(gòu)設(shè)計(jì)和開發(fā)設(shè)計(jì)中就考慮進(jìn)去遣钳，但是最好還是有專門的安全性測試

上述諸多測試類型中，功能測試先行麦乞。在進(jìn)行客戶端SDK測試前蕴茴，需要全面的了解測試對象的細(xì)節(jié)：

了解業(yè)務(wù)流程，結(jié)合API接口文檔和開發(fā)指南姐直，理順接口的使用場景和調(diào)用關(guān)系倦淀；

了解SDK協(xié)議，理解協(xié)議中字段的意義以及服務(wù)器端的處理邏輯声畏；

了解各接口或協(xié)議返回碼撞叽，分析對應(yīng)的場景；

了解開發(fā)實(shí)現(xiàn)細(xì)節(jié)，可以繪制成圖愿棋，便于測試分析和分層驗(yàn)證科展。

對客戶端SDK進(jìn)行測試，可以采用的分層測試方式由上至下依次有：基于Demo和解決方案->基于接口調(diào)用->基于代碼糠雨。

1辛润、基于Demo和解決方案的測試

大多客戶端SDK在提測時(shí)，都會有對應(yīng)的Demo或者解決方案提交給測試见秤，因此可以覆蓋到該Demo或解決方案對應(yīng)的接口或業(yè)務(wù)場景砂竖。而且測試人員可以比較直觀的看到界面表現(xiàn)，上手快鹃答，所以在客戶端SDK測試中比較常用乎澄，也是比較有效的。

但這種測試方式的缺點(diǎn)也很多测摔，Demo對接口和業(yè)務(wù)場景覆蓋比較有限置济，對接口的輸入輸出參數(shù)不能全覆蓋，發(fā)現(xiàn)問題時(shí)定位復(fù)雜度增加锋八。精心設(shè)計(jì)的Demo以及多解決方案的形式或許可以最大程度滿足測試需要浙于，但是需要較大的Demo開發(fā)測試投入，也使得問題暴露的時(shí)間大大滯后挟纱⌒咝铮基于Demo和解決方案的測試，可以是手工的也可以是UI層自動化測試紊服。

2檀轨、基于接口調(diào)用的自動化測試

基于接口調(diào)用的測試，包括對單個(gè)接口的測試欺嗤，也包括業(yè)務(wù)場景的覆蓋参萄。這種測試方式直接有效，需要一定開發(fā)基礎(chǔ)

目前煎饼，我所在項(xiàng)目組的同事也有一些實(shí)踐讹挎，以云信iOS SDK測試為例，最小回歸測試對應(yīng)接口也已經(jīng)自動化吆玖，測試工程基本結(jié)構(gòu)如下：

基于接口調(diào)用的自動化測試筒溃，需要有產(chǎn)品的思路、開發(fā)的知識和測試的思維衰伯，做起來有難度铡羡。但是因?yàn)镾DK接口通常比較穩(wěn)定，所以一旦實(shí)現(xiàn)并投入使用意鲸，測試效率和質(zhì)量的收益都很大烦周，值得擁有尽爆。

3、基于代碼的單元測試

單元測試是為開發(fā)代碼質(zhì)量保駕護(hù)航的一個(gè)重要環(huán)節(jié)读慎，在測試左移推進(jìn)的道路上漱贱，大家越來越意識到單元測試的重要價(jià)值。特別是在一些核心業(yè)務(wù)上夭委，值得開發(fā)同學(xué)投入精力去做幅狮。

其他測試類型的展開，跟應(yīng)用層測試類似株灸，就不再重復(fù)了崇摄。

本文來源：公眾號“測試開發(fā)技術(shù)”、“Red Hat”