非常感谢,用你的方法解决的,但是最好不用 ###,因为 python 中 # 会注释代码
不知道是不是 httprunner 字符解析方法的问题,replace 函数中 $ 用 $$ 可以转义为 $ 进行替换,但是密码中使用 $$ 进行转移就会失败,
${{{var}}} => $var 这个 我试了 ${{{var}}} =>${{{var}}}
开始时,但是我每个用例都需要执行不同的 sql,所以将 debugtalk.py 里面执行 sql 的方法改为根据用例传的 sql 执行
这样密码里面 $ 都变成了%24
不好意思,没有找到解决办法,只能说不忙的时候全覆盖,忙的时候先设计优先级高的场景,空闲了在补充优先级不高的用例
以前都是自己写 sql,用 sql 的结果去对比,忽略了接口测试是做回归的
如果出现 bug,在自动创建 bug 的时候,怎样判断 bug 是否已存在呢?
1.关于自动化创建 bug 这个,确实遗漏了非程序方面导致的 bug,所以改为先保存在在 excel 文档
2.保存在 excel 文档后,也想通过代码去删选是否 bug 已存在
3.summary:如果 message 太长,summary 可能超长,关于为什么要加时间的目的不清楚,
为了一眼看出是哪一个测试用例没用通过
测试方法名称:
修改前:
修改后:
为什么,会存在什么问题吗?因为接口测试这种,就算你手动创建,能够填写的内容还是那些,人工唯一就是可以判断这个 pr 出现没
对,那天也看到这样的方法,觉得比较可靠,目前还没有尝试
因为前置添加涉及多个 sql 操作,而且不同的接口,可能前置条件的 sql 语句数量不一样,就需要每次指定我要的是第几个 sql 的返回值,这样写出的代码通用性不强,
想过这个问题,但是那样就感觉用例和数据库的值绑定死了,需要单独为所有的这种情况准备测试数据,而且对于修改 roleid 不存在的数据,还是需要对初始数据进行查询获得 id 后再删除,只是少了一个插入数据的过程而已
楼主你是怎么解决的呢?
这个只能让开发加吗?我看了,都没得 content desc
那个是 lable,真正要的是他后面 input 的 值
不是每个空间都有 text ,input 的 text 也是变化的啊
可以,我也发现群头关于嵌入式测试的基本没有
都问一些之前工作的情况,问的内容和嵌入式都没关,直到最后人事给我介绍公司,才慢慢思考过来
嗯,目前都还不知工作内容,面试太少了,开始不知道要问这些,也想着面试不上问了没意义
测了五年软件,在一个测试沙龙听过一次手机硬件测试,当时就不喜欢了,我都不知道嵌入式属于硬件测试
谢谢好意,我在成都定居的哈
不要做成数据查询什么意思?
前面那种方式很赞同,但是感觉在添加测试用例的时候,这种方式效率并不高,开发一般只考虑几种情况,写的用例少,但是测试犹豫覆盖率的问题,当考虑多种情况时,这种手动去添加用例饿,感觉还是比较麻烦,有没有想过根据数据类型,自动生成单个字段的测试数据,在通过正交表去组合,形成最后的测试数据(目前正在尝试写这个程序,也是用 pyth,对 python 懂的还有限,前端框架更薄弱,只能边摸索,边写)