• appium客户端中webdriver管理的部分实际上就是selenium,上面这个命令也是selenium中默认就有的参考

  • pythonappium客户端为例:

    webdriver初始化的地方添加reconnect参数

    如果reconnecttrue的情况下,直接获取server端的session信息,并直接将这些信息保存至客户端脚本上下文中

    调试时,脚本代码中只要将reconnect值设为true就行了

  • 有点复杂,介绍下我们之前用appium调试的简单思路:

    因为appium是C/S架构,每次测试执行的上下文信息都保存在appium server端,其中最主要的就是会话session,所以,只要重写或者添加个driver初始化的方法,先去server端获取下已存在的session信息,就能实现无需重启的单步调试了

  • 可以参考ApiMatic,能实现各种借口定义之间的转化,我们项目使用了Postman collection -> Swagger的方式,配合chrome到postman中的导流功能,接口定义生成本身的成本不高。

  • 2、接口文档标准化,很多时候真的是可遇而不可求,特别是在中途接手一个质量不是很高的项目的时候,接口文档滞后或甚至是没有。实现自动生成测试用例这块儿,不知道你们有没有成功实践经验,可否分享下?

    —— 看下swagger吧,一种标准的接口定义规范,可通过代码注解或者postman collection自动转化生成(当然也可手写),而且也是yaml格式,挺适合你这框架的

  • 从个人经验看,接口测试的最佳工程实践应该包含从开发的接口定义到测试脚本(至少是单接口的参数遍历脚本)全自动化生成,这样才能保证接口测试的准确性、覆盖率和运作效率。

  • 1、如果用xposed的话,你要知道请求最终是调用系统的什么接口接受响应内容的,然后hook对应方法就行
    2、但个人不推荐上述方式,因为你要自己构造各种响应结果,这个工作量很大,建议直接使用peach,有非常强大的fuzz测试能力

  • WebElement监听的不一定是click事件,还有tap、touch,这几个是不一样的,你可以都试试

  • 批量操作这种建议做成接口测试框架本身的功能,比如你在请求中加个占位符test%100%,表示该请求从test1、test2...test100自循环100次;同理再加个全局的随机值,如$RANDOM$,这样和上面的搭配在一起test%100%$RANDOM$,就可以基本保证你每次运行产生的数据都不会冲突了,而且脚本会很简洁

  • 我们目前在搞的精准测试方案是这样的:通过分析变更代码的调用路径,找到最上层的触发接口,然后测试对应的接口请求。

    但是有个比较扯的疑问,我们把所有测试接口跑一边也花不了多少时间,搞这么精确的意义在哪=。=