• 关于测试开发的思考 at 2019年06月28日

    有人抱怨测试开发没有产出 推进事情我觉得两方面都有原因 需要带动的是代码能力弱一点的测试 但是这个事情有多难 只有做过的人知道 事情大部分不是一方面的问题 但是需要一方面的人负责任 世界就这么运转

  • 关于测试开发的思考 at 2019年06月28日

    我觉得测试开发不纯粹是开发框架的 测试开发测业务 应该是用代码的地方用代码 需要业务的时候用业务知识 需要自动化的时候自动化 代码应该是随手就能写出来 这应该是大部分测试需要达到的水平 可惜现实中没有这么多 测试用例的代码难度没有那么大也没有那么简单 但是往往工作量大 这也就是为什么好多开发不愿意写单测代码也好集成也好的一个很重要原因 解决工作量大的问题同时还要解决欠债太多问题 这个真不是一般测试开发搞得定的 无解 混日子 工资到手就可以

  • 讨论价值没意义 有意义的是讨论价值多少

  • 个人觉得这个做法是可行的.
    https://www.cypress.io/ 这个 UI 测试的,其实用在本机测试使用 Mock 会有比较好的效果.

    我自己个人的感受,看了 angular 或者 vue 这种 model 和 view 自动绑定的前端,其实在运行层上面完全可以进行 model 和 view 绑定。
    上面有点玄乎,举个例子来说:

    1. 页面的某个输入框 model 的名字是 name, 那么你的测试数据里面如果有一个属性也是 name, 那么默认应该就是这个属性 name 的值就应该输入到这个 model 名字是 name 的框中
    2. 大部分控件的默认操作就一种,输入框就是 input
    3. 结合以上两点,在运行 UI 测试的时候也可以做到 model 和 view 绑定,已 java 为例子,给一个对象实例,他有变量名,有变量的值, 通过这个变量名可以找到这个变量名在 page 中定义的定位元素,就可以直接操作了, 最后的测试用例其实就是变成类似:
    login(String processNameList<Pages> pages, TestData data)
    

    这个样子了. data 中包含所有需要测试的数据,变量名自动到 Page 里面去寻找这个流程需要的页面元素,selenium 里面的常用操作都可以在写测试用例的时候都需要知道,只要知道数据是什么就可以了。

    可以参考老帖子: https://testerhome.com/topics/2788
    这个就是当时看了 angular 想到的, 甚至通过解析页面元素 model 这样的东西,可以把生成一部分 PageObject 类。然后在反射关联页面的 model 和测试的数据,页面,定位,数据都可以分开,model 对业务系统来说是稳定的,页面元素变来变去,只要改 pageobject 就可以,页面操作什么都可以不用改,因为大部分都使用默认操作,默认操作封装在框架就好。

    最后只能说没有什么用,因为其实大部分的测试越封装,效果就越不好,太多的概念分层都不如直接写 selenium 原生的 api 好用,什么稳定不稳定,自己没试过怎么有感受内,类似于在 json 对象里面找一个元素,如果在学习了一段时间后,还是要花很长时间才会用,什么框架都不管用。

    具体的是可以参考: https://github.com/ideasfortester/mixed-first

    还有一点其实个人觉得如果有类似于的埋点系统的话,完全可以把页面操作的所有动作都记录下来,直接通过埋点系统来完成录制回放。不过不好的地方就是这些都变成开发的事情了, 要测试做什么。 所以我也被 fire 了。 嗨找工作真难!

  • 分批提测理论上是可以提高交付速度分批提测 分批验证 分批 UAT 提高并行度 但是需要需求分解好 同时沟通频率也加大 测试工作量是提高了的 环境问题吗 能做的还是需要基础设施能力 挑战肯定是加大了 能不能快只能说看能力 都说不准 如果马上试肯定会有点混乱的

  • 首先明确一下开户接口调用的时间分布 最高一段时间会有多少人 然后转换到一秒会有多少 tps 给这个值 *2 就当你的目标 然后看看用户行为 会有同时注册这种情况吗如果有就要增加一个抢注册这样场景 并发需要设置集合点 其他可以再看看会有持续比较长时间一值有人注册的场景 可以模拟这个场景看系统较长时间运行情况

    以上纯属拍脑袋

  • 又精通分布式又精通 android 感觉还是个人吗

  • 使用吞吐量控制器也可以做到:

  • 一个方便的办法就是:用 postman,里面 postman echo 基本例子都有

    然后查看 postman 的 code 生成:

  • 申请开通专栏

  • 简单的想法

    这个问题太难了,感觉出题的人也不会知道这个水深水浅.
    下面是自己的一些想法.

    1. 单个 Server Cache 场景 - 最基本 cache 的功能

    • cache 的读取
    • cache 如果不在内容里面从数据库取,然后再放入 cache
    • cache 过期,过期策略验证
    • cache 的不同类型验证
    • cache 超过内容容量 cache 策略

    2. 分布式看 - 太难了,感觉问问题的人也不一定很懂

    首先不知道这个地方的实现,总体可能有两种情况:

    1. 都是直接访问 server 的 cache,remote cache 做同步分发,协调用
    2. 先过 remote cache,server 的 cache 做类似二级缓存

    但是不管怎么样如果是数据一致性,高可用的话有些事情一样都很难实现和验证,比如:

    1. 数据一致性,这个缓存数据的要和实际最新数据一致,而且一个 server 端的 cache 更新了需要广播更新所有的 cache,还要保证时序性保证,先到 remote cache 的不代表他真的是先发生,网络,处理能力都可能有问题的,系统最后更新的表示最新的值,这个难呀
    2. 可用性,如果一个 server 重启了,那么如果复制 cache 到这个 server,性能问题 如果 remote cache 挂了,怎么让 remote cache 的数据恢复正确,和实际情况一样
    3. 如果不同 server 的时间都不一致,怎么保证数据一致性
    4. 如果对 key 加锁的化,性能如何?如果没有 key 的话,怎么加锁? 没有 key 是完全可能的,就是不在缓存里面,但是是去拿同一个东西,没法控制了?
    5. 如果 server cache 的内存大小都不一致,怎么保证 cache 内容是一样的?

    最后说这种功能,测试还是不要碰了,谁想的方案谁验证吧

  • 聊一聊职业发展 at 2018年10月12日

    问题是给多少钱?这个要求可不是不高,而是相当高

  • 我这个效果怎么样 at 2018年08月22日

    貌似 winzard.pinan.com.cn 这个链接报错了:@jacksonchina

  • 我这个效果怎么样 at 2018年08月21日

    antd pro 的味道

  • 主要没找到 python 长期维护的 jsonpath 的包

  • 赞一个,全能呀

  • 坦白讲我觉得还是 else 里面要处理什么响应的验证也是在 doothertask 这个方法里面做 本质应该我觉得是 doothertask 这个业务校验不严格 以后如果其他地方调用可能会出现一样的问题

  • 那也是 doothertask 的问题吧 和 if 没什么关系吧

  • 直接在本机运行的,没有打包。maven 的项目的话,直接 mvn test 就可以了,或者在打包的时候不忽律 test,就会在打包时运行.

  • 确实非常没意思,不知道为什么 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 2018年07月22日

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

  • 初步估计需要在 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>