• #7 楼 @d00004_1 发帖要认真, 以后精华帖子有机会出书的. 你可以补补. 我觉得这是个不错的技术点的.

  • 感谢你们 at 2016年06月14日

    赞一下, 此贴证明楼主情商也是挺高的嘛.

  • 我是来秀表情的!🆗 at 2016年06月13日

    太花哨了. 这是要走向娱乐化吗. 😅

  • 说明下技术原理吧, 这才是大家想了解的干货.

  • 你列举的事情太多, 不够聚焦. 广而不精. 你得明确不同的阶段的不同目标. 然后才能制定合适的策略.
    一般是前期重效率, 中期重 feature, 后期重集成. 每个阶段需要定义好最值得投入的事情, 发散太多容易导致投入过大.
    前期 sonar 代码静态分析 + 单测用例 + 单测覆盖率
    中期 接口测试 +Trace 技术 + 集成测试覆盖率 +Code Review
    后期 人工测试 + 部分主流程的 UI 自动化 + 代码 diff 分析

    至于 bug 定位, 你研究下对应的 trace 技术即可. 比如 java 里面的 byteman 或者 jacoco 就足够了. 基本可以保证能快速定位问题了.

  • 趣谈我眼中测试发展 at 2016年06月13日

    负能量太多了. 其实所谓的测试大屌丝都是人生赢家.
    能够不依赖任何技术就能混到管理岗位, 拿着最早的互联网初创公司期权, 在最青春年华的时候财务自由, 并在测试行业走向衰退的时候全身而退. 这不是最励志的逆袭小说吗. 以后很难再有人能走出这样的路了. :)

    其实每一派的观点跟你一样. 只是措辞反过来说而已. 每一个派系都有自己高大上的理由.
    与文章中你提到的两个极端相比, 你也在走向另外一个极端.

    每个人的现状进步在未来都会被淘汰, 你需要假定自己也是错的, 才能看清变化.

    要很好的度量每个人的价值, 需要有一个参考标杆. 我的参考标杆主要是数据.
    每个测试手段和测试形式的本质都是为了拿到质量数据从而断言目标质量.

    业务特性测试, 可以手工测试,也可以自动化测试. 两者各有所长. 需要根据公司的业务和自己团队的技术水平去合理的使用. 这里面无关对错, 如果没条件上技术路线, 那就全手工. 如果有部分能力掌握, 就半手工. 如果团队牛逼的确做到了建模分析和智能学习, 可以放弃手工测试转向研发自测 + 监控 + 数据分析. 目前绝大多数的团队都还停留在全手工和半手工的阶段. 这里没有对错, 取决于质量和效率的平衡.

    专项测试本身也是可以手工或者自动化. 他是另外一个质量维度, 和执行形式并不冲突.
    任何质量目标和测试任务都存在手工和自动化等多种不同执行方式. 也是不冲突的. 而且执行方式上本来也是互相融合的, 技术手段的测试也需要人去维护.

    不要因为自己做菜被刀 (自动化) 切到手, 就觉得刀 (自动化) 没有用. 那一定是"姿势"的问题.

    也不要因为自己所处的公司环境和自身的经历就断言偏技术或者偏人工的胜利.

    任何公司都可以看成两个抽象属性集合 业务目标 + 执行力. 阿里巴巴, 腾讯, 小米都是这样的属性集合.
    产品部门代表业务目标, 研发部门代表执行力, 而测试部门则是两者中间的链接. 用于保证两者的契合.
    在计算机时代早期, 偏交付, 质量代表一切, 所以才会出现人海战术 +CMMI
    在互联网时代早期, 偏迭代, 速度代表一切, 所以才出现了持续集成, 持续交付和敏捷思潮.
    而移动互联网时代, 有移动端的交付, 又有互联网属性. 所以他自身会仍然要注定出现上两个时代的结合态.
    从历史的长河来看, 人类从钻木取火到用打火机, 从石壁刻字计数到用电脑, 这本身就是一个人类不断掌握科技和运用科技的过程.
    而互联网领域的业务和技术发展, 其实就是整个人类发展的缩影. 能进化过来的才是人类. 多学多用是保证未来十年内有稳定发展的有力保证.

  • 搭建 api 测试服务平台 at 2016年06月13日

    文字太少了, 可以补充下你们的测试用例的管理方式. 以及如何与持续集成结合

  • #15 楼 @suddenly 你好, 这是个技术社区, 不接受外部的商业平台推广活动. 如果你们能长期发展的话, 可以考虑联系社区管理员建立自己的商业品牌专区. 商业和技术需要明确区分. 可以参考 fir 百度 oneapm 和 testin 跟我们的合作模式.
    这一次我们先临时性的给你放开. 请你能理解.

  • #12 楼 @pacerron 加我微信吧 seveniruby

    —— 来自 TesterHome 官方 安卓客户端

  • Macaca-iOS 入门那些事 at 2016年06月09日

    你们都入坑了啊. 只剩下我这个老顽固了

  • 阿里的测试发展 是整个行业的一个缩影吧. 我也算是见证人之一. 因为八年前我在阿里的时候, 正是阿里去测试化的萌芽阶段. 作为行业为数不多经历整个历史的老骨灰. 我就给大家科普下吧

    萌芽阶段

    阿里 B2B 当初还是卫哲是 CEO 的时候, 就推崇 Facebook Groupon 和 twitter 等公司的崛起. 他们的创业公司风格为公司和产品的发展带来了很强大的动力. 就是更新快, 发布快. 产品迭代快. 然后阿里的高层就去美国学习了一番.
    回来之后带来的一些思潮, 这些阿里内网应该都有记录, 这里面也提到了一点, 就是他们一开始是没有 QA 的

    发展阶段

    原来面试阿里 QA 是不需要懂技术的, 后来随着公司发展的需要, 对技能的要求也越来越高. 并开始从百度挖懂技术的一些测试工程师. 同时自身也加强培养. 提升各种测试效率来力图保证公司的产品发展.
    这期间即是 QA 发展的黄金阶段. 又是阿里自身提升效率的一个动手阶段. 这个阶段开始. 需求分析师和项目管理岗位被裁掉. 变成产品 + 研发 + 测试三足鼎立. (这期间为了提升能力我跳槽去了百度)

    瓶颈阶段

    阿里 QA 人数继续发展, 产品质量没有明显的提升, 但是效率却下降.
    而且随着各种新技术的发展, QA 的话语权也越来越弱. 很多地方不深入产品和架构是没法很好测试的. 研发的话语权也越来越重.
    公司高层也意识到要进一步提升效率就必须从 QA 开刀了.
    这期间有几个标志性的事件.
    左耳朵耗子率先对 QA 发起质疑.


    这文章是 4 年前发的. 地址是 http://coolshell.cn/articles/6994.html
    (TesterHome 也是这个时期成立的. 力图培养新兴的技术型测试工程师群体来逆转测试行业的局面)

    衰落阶段

    以淘宝的 QA 老大郭芙离职为标志性事件.阿里 QA 最辉煌的时代过去了. 郭芙对测试行业的发展还是有目共睹的.
    接着 QA 被划入各个子业务线, 然后各个业务线就展开了对测试的改造. 基本是 3 个趋势

    • 有技术能力的转入研发团队做业务, 这也是楼主所处的历史时代.
    • 有技术能力的自己做测试服务和工具
    • 不懂技术的转岗到还是离不开 QA 的重人力型的部门
      巧合的是正好左耳朵耗子又和玉伯发生了一件轰动整个 IT 行业的微博骂战
      这是玉伯的观点.

      两个对立的研发派系的人, 在对测试的态度却是十分一致的. 那就是能不要就不要. 能自己干就自己干.

      后测试时代

      工作 7-8 年以上还是不懂技术的测试工程师会发现越来越难找工作了. 研发测试比也逐步的从 1:2 到 1:6 发展. 也就是整个 QA 行业三分之一的人工作受到了影响. 庆幸的是移动互联网的崛起和创业公司的数量增多, 吸纳了这部分人. 但是这波移动互联网创业浪潮也即将退潮了, 这三分之一的人还是会难以逃避自己的命运.
      这期间 BAT 等大公司也都逐步完成分拆并消化 QA 的过程. 大的质量部一去不复返, 测试工程师的晋升之路也终止于测试主管和高级测试工程师.

      重生阶段

      说实话测试行业发展成这个样子 ,并不是测试行业不好, 是之前测试行业带头的那些大佬们太坑了. 测试理论测试技术都很陈旧. 根本跟不上行业发展的需求. 当一家发展型的公司苛求更高的产品质量和更好的迭代效率的时候, 不能满足需求的一切力量都会被逐步淘汰. 能满足的就会崛起. 我希望这部分力量可以有很大的部分来自于我们的社区.
      一个团队或者团体生存的依据就是价值, 而价值是通过业务体现. 找到了自己业务也就找到了存在. 这是我定义的新时代的测试工程师业务

    • 业务测试. 手工和自动化都会用到, 合理搭配

    • 流程管理. 产品迭代上的业务需求管理和节奏把控. 监督研发和产品的产出和完善度. 通过持续集成和持续交付来打通流水线.

    • 质量监控. 监控用户级别的质量和体验. 有自己的平台和数据. 支撑产品和研发做改进. 包括研发自测, 内测, 灰度测试的质量保证和数据分析.

  • 因为--session-override 不能用, 我都自己把 appium 启动停止封装到了脚本里了

  • #24 楼 @lamianxiaodian 这是两年前社区的招募合伙人的制度 https://testerhome.com/topics/143

  • #19 楼 @lamianxiaodian 真正的高手都是被 BAT 养在深闺的. 是不是一个合格的高手判断很简单. 他有 github 吗. 他开源过什么吗, 他有对其他开源项目提交过代码吗. 有很多不懂代码不懂 git 的伪"高手"和理论家. 就跟那些动不动就谈大数据只知道 excel 不知道 hadoop spark 的人一样. 测试行业慢慢被行业质疑, 也是因为太多这样的人存在.

  • 之前也发生过别人问问题被 T 的情况. 他们也都是重新申请给解释原因就进了. 那是还没有像你这样"斗志昂扬"的人.

    你 @ 的人根本就不在群里, 说明你只是简单的复制粘贴群发. 你这样的风格很容易被各种群 T.

  • #17 楼 @lamianxiaodian 大多数都不是, 都知道出名捞钱. 没人去脚踏实地的研究和分享测试的经验和技术. 所以我们才成立了这个社区. 另外, 说实话我不觉得其他那些高手有多"高", 行业里面大半的 BAT 高手和那些各种招摇撞骗的人我们圈子基本都认识的.

  • 估计是发现你 @ 人太多. 骚扰别人了吧. 重新申请解释下原因即可. 乱 @ 人是要被 T 的

  • #10 楼 @lamianxiaodian 高手一般是能独自的查资料并独立解决问题. 属于修行比较高. 等到了高手的 level. 也就到了懒得发帖分享, 懒得帮助别人. 这样其实对行业也没什么价值了. 只能独善其身. 如果人人都这样, 就变成了老子所说的 "老死不相往来".

    这个社区的理念是"Coding Share" 如果不满足这两个属性, 就算是再高手也不会接纳. 一个不能为社会和行业带来价值的高手, 浪费了行业对他的期待.
    而善于和同类型的人交流的人, 会成长的更快. 无论是高手还是新手. 失去了切磋和交流, 高手也会慢慢"钝化"的

  • #7 楼 @zsx10110 他不过是故意发这贴挑起点评论的.

  • 不要那种不会分享只会捞钱的高手. 分享和进步的动力才是最大的. 一年前还在这发小白问题的人, 现在都已经开始出书了. 这样的节奏就很好.
    过几年行业里面的高手, 可能会有不少人会来自于这个社区.

  • #6 楼 @success 有人要陪你一起写了 @gaopeng1106 哈哈

  • 我记得官方是支持 0.8 和 0.2 这样的格式. 不过我为了保险都会再乘以 screenSize

  • #4 楼 @luoxi001713 那只能用 @chenhengjie123 的办法了. 目前没有太好的方式判断元素前面是否有遮挡.

  • 你还不如换个思路, 等待要操作的元素出现也行. 这样就是标准的 WebDriverWait 了. 这个东西跟 @chenhengjie123 提的思路是一样的.

  • #7 楼 @taurus 开源要等中国移动测试大会上, 我正在考虑放个预览版给所有参与大会的人