非常感谢，用你的方法解决的，但是最好不用 ###，因为 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 懂的还有限，前端框架更薄弱，只能边摸索，边写）