• 如果出现 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 也是变化的啊

  • 嵌入式测试前景 at 2018年02月26日

    😱

  • 嵌入式测试前景 at 2018年02月26日

    可以,我也发现群头关于嵌入式测试的基本没有

  • 嵌入式测试前景 at 2018年02月25日

    都问一些之前工作的情况,问的内容和嵌入式都没关,直到最后人事给我介绍公司,才慢慢思考过来

  • 嵌入式测试前景 at 2018年02月25日

    嗯,目前都还不知工作内容,面试太少了,开始不知道要问这些,也想着面试不上问了没意义

  • 嵌入式测试前景 at 2018年02月25日

    测了五年软件,在一个测试沙龙听过一次手机硬件测试,当时就不喜欢了,我都不知道嵌入式属于硬件测试

  • 嵌入式测试前景 at 2018年02月25日

    谢谢好意,我在成都定居的哈

  • 测试数据生成程序 at 2018年02月09日

    不要做成数据查询什么意思?

  • 前面那种方式很赞同,但是感觉在添加测试用例的时候,这种方式效率并不高,开发一般只考虑几种情况,写的用例少,但是测试犹豫覆盖率的问题,当考虑多种情况时,这种手动去添加用例饿,感觉还是比较麻烦,有没有想过根据数据类型,自动生成单个字段的测试数据,在通过正交表去组合,形成最后的测试数据(目前正在尝试写这个程序,也是用 pyth,对 python 懂的还有限,前端框架更薄弱,只能边摸索,边写)

  • 我也遇到了,你是怎么解决的呢?

  • 自动化测试解答 at 2018年01月30日

    一次参加一次沙龙,里面说的自动化也需要分成,70% 单元测试,20% 接口测试,10% 的 ui,上次面试新蛋,他们也说他们 UI 还是是手动测试,接口,单元自动化,感觉流程类冒烟测试和回归用 UI 自动化意义要大点

  • 说的我在网上了解的一些看法哈,理论上这种都是算 bug,但是实际设计用例的时候会进行一下讨论:
    1.输入中哪些在后端限制,哪些在前端限制,因为有些在后端处理反而受益不高,这些就需要加强前端输入的验证
    2.有些参数是不可能存在空值,比如登录这种,接口登录后才能调用,用户名自己就获取到了,就不会存在字符串类型,字符格式不对
    3.通过 1,2 对参数进行筛选,在通过他们说的正交表生成测试用例,在进行适当的增减,基本都可以了
    4.你说的情形如果开发说的情形确实不存在就可以忽略,否则你可以自己设计正式使用场景来推翻他,以例子为证
    5.其实我们公司也是,开发说是啥,就是啥,虽然公司说改革,改了几次,感觉变化并不大,因为项目太多,永远都是在老项目上修改,要验收了,才开始测试,受够了这种模式,加上家庭原因,辞职了

  • 直接用代码调用接口,也学要知道接口返回值得规律吧

  • 你说得这两种方式都可以,还是可以这么干,只是没有实践过

  • 恩,谢谢回答,这个以前我搜索过,但是没找到工具,后来自己手工计算四个参数的情况,但是算到后来就不明白为什么这种方式就能很好的代替全覆盖的情况