测试工作总结

一、接口层面

1、提测前的准备工作：询问开发人员要项目相关的技术设计文档，技术设计文档包含接口设计，数据库设计和数据对应字段含义，保证测试工作的顺利进行。

2、当程序上传文件或者图片出现出现：Access to XMLHttpRequest at + URL 时说明跨域有问题如图，此时需要查看电脑是否开启了代理工具（charles、fiddler....），关闭代理工具重试如果还有问题则存在跨域不兼容

 

3、如果应用程序涉及调度服务中有静默推送机制，查看调度库如发现已完成调度并且执行静默推送任务但是在客户端无法看到对应的信息。

　　3.1、先确认客户端与服务端之间的交互时间是否重叠（比如服务端调度任务结束后30s返回一次数据，但是客户端也是30s发起一次请求，

　　　　 就会造成在客户端无法看到静默推送的信息），如果属于该问题则需要客户端调整发起请求时间，提前3~5s发起请求（也就是说服务

　　　　 端30s返回一次数据，那么客户端则需要在25~28s区间发起请求），方可解决此异常（三次握手）。

　　3.2、确认两端交互的时间（2.1中）没有问题后，再次确认是否有用到第三方库或者第三方推送（如：极光推送...等），查看从我方数据库推送到极光的时间多久，如果本地数据库

　　　　 推送给极光的创建时间 = creat_time:2021-10-08 15:45:18 极光收到的时间为：creat_time:2021-10-08 15:45:18，并且极光有记录给相应的设备id（devicesID:）发起了推送，

　　　　 说明极光收到推送的指令非常及时表示第三方推送及时，如果极光的创建时间为：creat_time:2021-10-08 15:45:20 说明极光推送有延迟，需要极光工作人员协助排查。

　　3.3、如果本地推送库和极光的收到的推送时间一致，并且极光已经给对应的设备或者用户发起了静默推送，此时则需要从客户端入手继续排查问题，用户与信息源的距离不同则收到

　　　　 的消息所消耗的时间不同（比如：10km以内的用户从消息发出时立即看到该条信息源，10km以上的用户则需要在消息发布起15s后才能看到该信息），在redis中使用命令：

　　　　 keys dispatch.str.fast.alive_status:* 可以查看用户当前定位是在哪里，然后再使用高德地图对两个地址进行测距排查问题

4、当发现数据有异常时，不要急于跑去问开发也不要立刻提bug，首先先使用抓包工具对应用程序进行抓包查看对应的字段返回的数据与客户端所显示的信息是否一致，如果接口返回的

　   数据与客户端返回的数据不相同则有可能是客户端或者前端把数据写死，也或者是后端把数据写死导致返回的数据与测试配置的数据不一致。确认是前端还是后端的问题再提bug给对

　　应的开发进行修改并及时回归。

5、在测试的过程中往往会疏漏掉的场景：比如用户在操作某项指令时，管理员在后台对该项配置进行编辑后导致用户输入的数据与实际配置不符，存在数据争议的场景，因此接口需要做

　　历史配置兼容，标记该数据是哪条配置输入保证数据干净整洁，避免产生一些脏数据，给用户留下体验不好的印象

6、当需求不确定或者不明确的情况下，先将需求文档仔细看一遍然后将所有的疑问记录下来同意发给产品解答，节省产品的答疑时间更好的提高产品工作效率也更好的提升自己

二、客户端

1、发现客户端和服务端交互出现界面无法打开或者报服务异常时要详细查看请求接口和技术设计文档是否一致（一个字一个字的比对，有时候客户端和服务端沟通不到位或者漏一个字母没有复制成功导致无法访问）

2、客户端设计拍照、图片上传的要测试 内存不足、内存溢出、内存饱满、内存回收，清理内存等场景，因为内存不足、内存溢出、内存饱满 ，内存回收这些场景会导致app闪退和崩溃等异常的发生，找死都找不到

3、客户端需要多注意兼容性测试，因为安卓机型千奇百怪各有不同，要多对市场上的小米、华为、oppo机型进行兼容性测试，而且小米和华为目前市场占有率非常高，小米的兼容性问题层出不穷。

三、排查服务日志

1、通过用户的手机号或者账号在用户表获取到相应的ID到token 表拿到对应的设备ID（deviceID），如果没有token表则通过抓包工具抓取设备ID一般在请求头里面有传递,去Discover（日志平台--一般公司都使用这个日志平台做记录）查询用户的

　  操作行为轨迹，这里的操作行为轨迹就是查看请求接口的先后顺序或者请求的接口是否有丢失，如有丢失说明客户端没有向服务端发起该请求（导致该异常一般是进行上一步操作的时候app已经闪退或者直接跳过该接口）可以通过轨迹分析得出

　  app闪退还是跳过应该请求的接口未发起请求。