框架

一、了解什么叫框架

所谓框架是一个指定了规则的半成品，已经对基础的代码进行了封装并提供相应的API，开发者在使用框架时直接调用封装好的API，可以省去很多代码的编写，从而提高工作效率和开发速度。

所以针对各个方向各种语言实现的框架也就应运而生，如：

• Android 网络框架：AsyncHttpClient、Volley、OKhttp、Retrofit
• 图片加载框架：Picasso、Glide、ImageLoader
• 单元测试框架： Junit、TestNG、Unittest
• 自动化测试框架：Appium/Selenium、Airtest、Mocaca
• 前端框架：Vue、Angluar
• 后端框架：Flask、Express

太多了，没必要举太多例子了，现在，我们大概认识到，整个软件界基本上都是各种框架堆起来的。一个程序从底层到业务需求，方方面面规模庞大，没哪个团队说有精力有必要去重复造轮子，当然，你自己研究的话，就另当别论了。所以多了解一些业界知名框架对测试的视野扩展还是很有利的。

那什么是网络框架? 从名字我们可以看出来，网络框架主要是网络请求，对请求构造、连接、请求、响应处理、http缓存等方面进行专项处理。

二、评估影响范围

小编所负责的项目是一个表情运营类的产品，没有网络请求，产品基本无法使用，所以我评估的影响范围很是粗暴：所有功能模块的所有场景的所有类型的请求，均有影响。

三、如何进行测试

注意：这里切换的是客户端的网络框架，所以那些接口自动化等测试方法还留到服务端网络框架切换时再用吧。

以下是我规划的具体测试任务：

1. 梳理当前APP内所有类型的请求。 这一步主要是为了后续执行的效率和不遗漏，如果项目组已经有很完善的接口文档更好，没有的话就自己整理一份吧。因为，我们要求的是覆盖率要达到100%，不要太相信开发会一个不漏的把所有接口都改好了。
2. 梳理所有接口的参数组成、请求类型、必需要的响应字段，并严格的检查它。小编就遇到过开发会把POST接口写成GET，结果灯下黑的排查了小半天。
3. 保证接口的请求时机和顺序，与之前版本是一致的。网络请求有异步和同步之分，有的接口可能会依赖其它接口的返回，所以要保证这类接口的请求顺序，把业务场景找出来，并回归它。
4. 保证请求的异常处理逻辑正常。比如有些网络框架是以回调的形式来处理接口的响应结果，所以请使用接口MOCK工具验证接口在不同状态下返回时，客户端的处理是否正常。如状态码502、301，或自定义的错误信息时，客户端是否容错。
5. 测试环境要求，最好直接用线上的接口。这样你可以同时拿两部设备同时操作，对比效果更容易发现问题，至少不用再去排查是否是服务端的问题。
6. 如果接口有加密封装的话，请在加密环境下测试。小编公司为保证用户数据安全，所有请求都有二次加密的，所以在加密环境下测试，更符合实际情况。最接近用户的测试，才是最完整的测试。
7. 网络请求要稳定。由于这次框架是开发自己定制的，小编还加了一个稳定性的任务，当然这个是要在测试环境下对服务端的请求log进行监控了，主要是针对404这种客户端的问题，当然这需要服务端同学配合了

如此测试完成后，就有一份相对全面且有保证的测试结果了。

以上就是小编针对此次网络框架切换所做的工作了。

当你们启用或更换了框架时，也可以以此步骤梳理你的测试任务。

如果是非定制的第三方框架，可能你还要了解一些框架本身的特点，比如Volley框架对短而小的请求支持比较好，但对于数据较大的请求支持就不太好，类似上传文件这样的接口就要重点关注了。