• 不知道该做些什么了 at 2018年04月25日

    😂

  • 不知道该做些什么了 at 2018年04月25日

    学习开发,学习运维;
    然后顺便把开发、运维的事情都做了。

  • 不知道该做些什么了 at 2018年04月25日

    你可以当程序员鼓励师,让他们开发更有动力

  • 不知道该做些什么了 at 2018年04月25日

    可以捞点不是测试的活来干。比如运维或者产品的活

  • 不知道该做些什么了 at 2018年04月25日

    我们测试环境比较简单 linux tomcat+mysql+redis 测试流程的话我写好一份给研发老大看过了 基本上我这周不会有什么事情了 但是每天晚上都要开会汇报当天工作情况 轮到我说的时候就很尴尬了😳

  • 不知道该做些什么了 at 2018年04月25日

    测试环境管理
    测试流程梳理
    这些东西能比开发时间还长

  • 平安壹钱包前景怎么样? at 2018年04月24日

    有些公司就是那种大到 “不能倒闭”,平安就是其中之一,不管财报上的年利润水分多大,要相信抗壹钱包这种小公司烧钱还是不在话下的

    壹钱包刚开始产品做得非常之烂,不过现在已经过去好几年了,基础也算不错了,中间在上面买过大约 1 年的理财,后面转向小赢了~

  • 平安壹钱包前景怎么样? at 2018年04月24日

    其他的呢,加班多吗?

  • 平安壹钱包前景怎么样? at 2018年04月24日

    从产品角度讲,我在平安科技的时候从来没用过。

  • 平安壹钱包前景怎么样? at 2018年04月24日

    效率慢就是说没有很多产出,功能多数能用就可以。反正给内部用的。

  • 平安壹钱包前景怎么样? at 2018年04月24日

    效率慢指的是什么,是整个公司流程慢吗,楼主在平安工作过吗,可否加个 qq 私聊一下

  • 如何怼开发? at 2018年04月24日

    你这个回复比较牛

  • 举个例子一目了然:
    StringBuider 是可变的,修改了 sb2,sb1 并没有修改,因为 StringBuider 可变,俩对象用的一个地址值,修改一个另一个也跟着改变了

    StringBuilder sb1 = new StringBuilder("aaa");
    StringBuilder sb2 = sb1;
    sb2.append("bbb");
    System.out.println("sb1: "+sb1);
    System.out.println("sb2: "+sb2);
    
    
  • string 类没有提供可以修改内部信息的方法,为什么不提供?因为静态字符串池的存在,如果可以修改,会导致静态字符串池内出现重复字符串

  • appium 执行 case 的问题 at 2018年04月23日

    问题已解决,getDriver 的时候是从当前线程里取得 driver 所以是同一个 driver

  • appium 执行 case 的问题 at 2018年04月23日

    因为匿名有股神秘感

  • appium 执行 case 的问题 at 2018年04月23日

    为啥需要匿名呢?

  • appium 执行 case 的问题 at 2018年04月23日

    虽然没用过这个框架,但是既然你对 driver.get 方法有疑问,为什么不把 driver 的 session 打印出来看看是不是同一个呢?

  • 因为看到社区里面很多人都在谈工资啊。。。虽然不知道为啥·

  • 上海。。。

  • 如何怼开发? at 2018年04月23日
    • 做好记录交给党
    • 说明公司整体不成,包括开发水平和管理水平,反应出来就是自己水平也高不了哪去,加紧锻炼去好的公司,别指望个人能救一个国
  • 离职以后把卡销了

  • 如何怼开发? at 2018年04月23日

    一些看法供参考,欢迎讨论:
    1.提前说明各方职责这是基本原则:PM 需要对项目发布时间点,以及顺利发布负责;QA 需要对项目质量负责。
    1.1 如果 QA 也要对项目发布时间点负责的话,项目 KO 时间不变,发布时间不变,只会出现一种情况,那就是压缩测试时间,测试怎么办呢,加班支持,或者加班也完不成,就草草上线。但如果这样上线后出现问题,那背锅的肯定是测试了。
    1.2 基本原则的情况下,在评估好测试自身工作量和可承受风险的情况下,发布延期未尝不可。
    2.及时说明测试过程的各种风险:邮件、或者当面向上汇报都可以,因为测试除了保障质量外,另一个重要任务就是及时暴露风险,目的就是让大家不 suprise。
    2.1 比如冒烟测试不通过,比如日报中说明 bug 太多,比如风险知会,这些关键的项目测试节点,建议都正式邮件知会项目相关方。别把压力暴露在最后,也别把压力抗在测试身上
    3.打铁还需自身硬,让开发和其他项目组同学明白测试的质量保障到底在做什么,测试时间到底能不能被压缩,压缩后会有什么结果?
    3.1 要有详细的测试计划,做什么事情,花多少时间,比如手工多少,自动化多少,其他。。。其实有些时候这也是测试心虚的事情,因为工作量不可量化,引来合作方质疑。所以一定要量化,一是自己明白时间花哪里了,二是其他人也能明白测试工作到底在做些什么。

    最后,回到怼开发的问题上,我基于以上总结下。
    项目过程用数据说话,No data No BB,对谁都适用。

  • 之前用的不多当然还能用自己的,但是业务复杂了需要用的不少呢

  • 我就一直用自己的卡,公司都还不报销呢