• 确实非常没意思,不知道为什么 35 岁的年龄限制,谁没年轻过,谁不会老;一直觉得应该有个中年人相关的互联网公司,互联网只关注 90 后,00 后要么就是老年人,但是 35 岁以上的其实也就是 80 后,70 后为什么就没有人关注这些群体?做这种互联网公司的应该更多需要 35 岁以后的, 突然发了点奇想。

  • 不太清楚问得是什么问题 jmeter 录制的时候 js csshtml 都是单独的 http 请求 可以区分出来的

  • 首先要有深度 没有深度连机会都没有 个人想法

  • 首先我觉得是接口测试是有意义的,可以覆盖 App 前端可能不能覆盖的内容,几点理由:

    1. 有代码的地方就有可能出错,APP 前端验证之后,接口部分的代码实际上可能并没有全部验证到, 原因为,App 前端的代码已经对接口的请求参数做了一部分验证,所以有些接口的用例可能没有办法覆盖 如果从覆盖率的角度看,就是纯粹通过 App 前端,有些代码永远的走不到 (不是只是异常处理的逻辑)
    2. 接口并不只有 App 端访问,直接调用,或者其他客户端调用都有可能,甚至说可能被拦截后 直接修改参数再访问也有可能,从这点来说接口测试需要更加严格的校验,所以测试用例需要更多, 或者说需要去仿造通过 App 端无法测试的情况。 举个例子来说,如果用于用户名必须要要少于 5 个字符,这个限制只有在 App 端做了,没有在接口层做, 那么 App 端测试时候超过 5 个字符的用户名是不能注册,但是如果通过接口注册了超过 5 个字符的用户, 这个时候我想 App 端登录超过 5 个字符的用户名说不定永远不能成功了,这个其实就是接口测试的一些意义

    确实 App 的前端校验和接口测试从业务的角度,用例确实有部分重合,不过从测试的意义来说,App 端的测试
    有一部分的意义实际上验证和后端的交互是不是符合产品定义,这部分代码不是接口,
    而是如何前端校验,如何交互,如何转换数据;举个极端点例子来说,如果登录的时候,App 同时发了两个请求,一个给了登录接口,
    一个给了开发小哥自己的网站 (纯粹举例子),从功能的角度看,整个登录流程是没有问题的,但是它是一个 bug,
    而且很严重,而这些是接口测试无法覆盖的;

    楼主其实问的是个好问题,其中确实有重复的部分,而且很多团队确实就是用 App 测试代替了接口测试,
    在人员短缺,这个也是一个办法,合起来一起测试也不是一个完全没有道理,质疑重复测试也有道理,
    把两者合起来看,看两者的差异点,相同的是什么,不同的是什么,可能就会更高效率了.

    我有点啰嗦 .......

  • 测试那些儿事 at July 22, 2018

    外企的测试工资比开发高多了? 这个我觉得有点说的过头了,不觉得是个整体现象,个别可能有,但是如果整体不太现实。

  • 初步估计需要在 pom.xml 文件里面加入 maven compile 插件,jdk 版本设置到 1.8

    <build>
    
       <plugins>
         <plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-compiler-plugin</artifactId>
           <version>3.7.0</version>
           <configuration>
             <source>1.8</source>
             <target>1.8</target>
           </configuration>
         </plugin>
       </plugins>
    
     </build>
    
    
  • 持续交付实战 at July 03, 2018

    厉害厉害,想问一下楼主做这个大概花了多少人力呀?

  • 单实例 jmeter 不能造成大于服务器处理能力的压力,这就是他的局限性, 这句貌似不太准确吧。 我觉得方法可以是:

    • 可以不限制固定 QPS
    • 增加线程数,甚至可以设定集合时间点,假设服务器极限 TPS 到 100,你 JMETER 线程数 200 个,同时设置集合点 200 个线程同时发

    这样同时发,不就是超过你服务器极限 TPS 了吗,但是服务器 TPS 就这么多呀,TPS 就是这么多了,但是客户端的响应时间肯定很难看。 服务器不一定会挂(说明服务器的保护不错呀),有很多等待的队列,客户端反应就是超时越来越多,错误比例越来越高。

    同样如果有监控系统看的,可以从服务端的角度看系统处理时间,在这种情况下,客户端响应时间和服务端的监控的响应时间数据我觉得会有不一样

  • Virtualenv 简介及使用 at May 23, 2018

    其实 python3 自带虚拟环境的,python -m venv 就可以创建虚拟环境了,其他操作和 virtualenv 一样用,virtualenv 和性能测试关系也不大。

  • from collections import Counter
    
    source = [1, 3, 8, 9, 15, 12, 15, 3, 3, 9]
    
    
    # 不使用 python 标准库
    def get_2dup(candidates):
        if candidates is None:
            return []
        if len(candidates) <= 1:
            return []
        count_result = {}
        for candidate in candidates:
            count_result[candidate] = count_result.get(candidate, 0) + 1
        return [k for k, v in count_result.items() if v == 2]
    
    
    # 使用Counter
    def get_2dup_counter(candidates):
        if candidates is None:
            return []
        if len(candidates) <= 1:
            return []
        count_result = Counter(candidates)
        return [k for k, v in count_result.items() if v == 2]
    
    
    if __name__ == '__main__':
        print(get_2dup(source))
        print(get_2dup([1]))
        print(get_2dup([]))
        print(get_2dup(None))
        print(get_2dup_counter(source))
        print(get_2dup_counter(None))
        print(get_2dup_counter([]))
        print(get_2dup_counter([9]))
    
    
  • 有需要测试兼职的吗? at April 12, 2018

    全职估计没人要

  • 首先明确的是线程是压力生成器,实际上是客户端,TPS 是指服务器每秒处理能力。
    分情况来看:

    1. 如果压力生成是 2000 个线程,那么客户端每秒产生的请求应该会超过 2000 个,而服务器 TPS 只有 300,那么多出来的请求只能等待,这个时候客户端请求越积越多,从客户端的角度看响应时间就越来越长,因为排队等待处理的时间也计算在响应时间内;这个情况可能说明不了什么问题,可能系统就是这个设计的,可能就是个限流的设计,等待请求如果超过一定时间直接多超时返回,甚至说到了一定响应时间,如果这个响应时间大于客户端请求的超时时间,响应时间可能就不增加了
    2. 如果并发线程数和 TPS300 比较接近甚至更少时,那么响应时间的增加应该不会很陡峭,如果增加很厉害或者波动很大时,那么需要仔细查看其他的指标了,比如 SQL,内存使用的情况,GC 频率是不是很高,是不是有报异常等等了
  • 感觉没有什么好办法,最好让开发设置一个可以直接登陆的方式,要不然是自己给自己找麻烦。

  • 如果一个公司本来就没有什么流程,你问人家流程是怎么样的?为什么流程是这样的,你让人家怎么回答你?如果回答没有流程,就显得公司 low,如果回答有流程,那就说谎了。在假设,如果回答没有流程,说不定楼主会问,那你问什么不会去推动呀云云,可是推动一个流程没那么容易吧,然后如果胡乱说了一下,或者网上的流程出一下,后者牛逼公司的流程说一下,似乎也可以有个交代,但是我想说的是,这和没说或者说不出有多大的区别;关于选型为什么 JAVA,或者 python,总体上生态圈的问题,他要是说基本没有区别(语法当然有区别,当也不至于要人分析语法吧)你要如何回答他呢?

    我倒是想听听楼主如果对于自己提出的两个问题,你自己的答案是什么呢?

    心态是双方的,谁都会老,不是吗?谁没有年轻过,太阳底下没有新鲜事,或许讨论一个人是否适合岗位的要求更合适,所谓讨论岗位就是讨论性格,能力和要求的薪资是否和岗位匹配。

    关于匠人例子的一说,我很有怀疑,或许那个工厂一直都是用一种发动机,或许他们很多东西从来都没有变过;但是很明显互联网,或者 IT 这个行业不是这样的;

  • 可以参考这个:https://testerhome.com/topics/3483
    PageFactory 的 initElements 是生成的是 WebElement Proxy 的实例,这个你可以调试的时候看看,只有在真正去进行元素操作的时候,locationElementHandler 里面的 invoke 方法会先调用 findElement() 方法后,再执行你的如 click. 也就是 PageFactory 生成的元素实际是通过 locationElementHandler 里面的 invoke 方法去调用的,这也是 proxy 的原理.

  • @justcby SOAPUI 我也用过一段时间,他还是不错的。我也用过他做自动化的接口测试,我一个人负责功能和自动化,基本上也有 300+ 多个 case 的,20-30 多个接口,每个迭代两周,测试环境,集成环境都要测一遍,回归,新功能都要覆盖,基本上一个人也能搞定了,所以说效果还是不错的。我说说他的好处:

    • SOAPUI 如果用来做自动化测试的话,基本功能基本都可以完成,包括文件上传,上下文参数传递,环境配置,数据库验证,json 返回结果认证等等,甚至可以去出数据库的值来作为参数,而这些甚至不需要编程,不过你需要学习 SOAPUI 自己的一系列表达式的规则
    • SOAPUI 可以和 MAVEN 这些结合,但是我没有去研究如何做

    不好的地方:

    • SOAPUI 的表达式学习你是要花点时间的
    • 复杂的数据初始化和验证的时候有点力不从心了

    以上只是我个人的体会,其实用 SOAPUI 还是比较方便的,不过你至少要把他的官方文档中和你需要测试的东西的说明看一遍.

    我自己觉得我为什么自己写代码的目的 (个人想法,如果有不同意见请跳过我说的) 是:

    • 做自动化测试目标不是让人不写代码,而是写代码,了解代码,去更深入的理解一些基础性的,原理性的东西
    • 自己工具更灵活一点,可以更方便的实现一些自己想要的东西,同时又比 SOAPUI 更轻量,SOAPUI 可以测一堆东西,不过我只要测 RESTFUL 类型的 API
  • 分层测试重构之接口层 at March 04, 2016

    excel 的读取可以使用 easypoi 来做,直接加注解就好了,可以直接返回一个 List, excel 一行数据太长了,其实还是一列看的清楚一点。
    easypoi 地址

  • 打赏功能 at December 16, 2015

    点击右上角的用户名 -> 个人资料设置 -> 打赏二维码, 为什么我的找不到这个选项。。。。。。。

  • 貌似你要看 tps 的吧, 如果一秒钟处理 71 个请求,一分钟就是 4200 多个,如果 50000 中有个 5000 个分布就是在某个一分钟,你们系统可能也是扛不住的.估计你还是需要看请求的分布情况的.

  • #7 楼 @chenhengjie123 另外这块我觉得和开发的规范有关系,如果一些返回字段实际是表示相同内容的 (业务上的意义),而这些字段名又都不同,传这个上下文感觉是会啰嗦的。

  • #5 楼 @chenhengjie123 目前这块做的不太好,后续需要放不少精力做这个。目前已经做的一些是这样的:

    • 数据创建的时候根据上下问去再造点数据,比如说有些测试可能是这样的测试用例说一个已经有过订单的人,这个时候其实用例里面应该说不是具体的一个人,而是满足条件的这个人,所以在 Excel 里面其实是放有过订单的这个类型,然后在用一段 sql 去获取满足条件这样的人,那么如果一般情况时这样的话,自己写代码的话可能就是先创建个类在去执行一段 sql 去取值,然后再赋值给这个人,我现在做的是,创建数据类是通过一个工厂方式去创建的,然后这些根据一些初始化的内容获得的东西,都会放在 beanPostConstruction 中去实现,这样 Excel 里面填写一些关键数据,然后通过这个 DataFactory 去创建 JAVA Bean 的时候会自动运行 beanPostConstruction 里面的东西,这样可以少写一些代码

    -还有一种就是几个 API 调用之后,有些内容需要从前一个 API 获取,再给第二个或者第三个 API,这个还没有实现的很好
    我自己大体的思路就是把 API 的返回都放到一个结果集里面,一个 MAP 里面,然后在根据一些传入的表达式来获取这些值,再来传递,不过还没有完全实现出来,一直没有想的太清楚这块,需要自己在写些代码试试

  • #2 楼 @seveniruby 代码生成其实已经做好了.如果有 HAR 就不用去写那个描述文件了,会根据 HAR 自己生成,如果接口还没有开发完成还没有实际使用过,这种情况下就只好自己去写描述文件了. 然后填写测试数据来做测试用例设计了。理想情况下 (按照需求说明文档的规范做的),开发好了,接口自动化测试也可以跑起来了。不过代码确实需要再精简,要更少代码更少代码。