最后还是要鸣谢一下，当年 marvell 测试经理张昊翔，现在去哪里也不知道了
做这些还是来自他 chinatest2012 的演讲，可惜现在 TID 大会演讲的水平已经不复当年了，说明测试真的就那么点事可说，技术发展都是被动的，而非领跑 IT 行业~

只是管理效率、便利性和准确性的提升，对于一线帮助不大，你可以那这个数据透视的结果要求他们（包括开发、产品、测试）在哪里加强测试、在什么阶段要抓紧投入等等，而想要他们自己理解这些，估计就比较难了，除非是精英团队……而精英团队才不会用这个咧~

case when 写法，时间换空间，牺牲 CPU 时间用于判断和计算
left join 写法，空间换时间，两个查询结果在内存中 sort

附 SQL：

SELECT 
  a.classid,
  IFNULL(a.male_num, 0) AS male_num,
  IFNULL(b.famale_num, 0) AS famale_num
FROM
  (
    (SELECT 
      classid,
      COUNT(*) AS male_num 
    FROM
      student 
    WHERE gender = 'M' GROUP BY classid) a 
    LEFT JOIN 
      (SELECT 
        classid,
        COUNT(*) AS famale_num 
      FROM
        student 
      WHERE gender = 'F' GROUP BY classid) b ON a.classid = b.classid
  ) 
GROUP BY a.classid ;

我最多问印象最深刻的 BUG，最难这种我觉得是伪命题
BUG 找到了，难道不解决？解决了不知道什么原因、怎么解决的？都知道了还有什么难的，了解过后都不会觉得多难~
要说难这种情况，大多在测试开发自己开发自己测试，搞 1、2 天找不出问题根因，那才叫难呢……虽然最后很可能只是一个引号敲错了

可惜规则不能定制化，全都按照阿里的路子来，有点不大灵活……确切的说是很不灵活

具体信息可参考：https://segmentfault.com/a/1190000011560013

https://testerhome.com/topics/10451

realtime-report 和 reportng 是我自己改写过的

不必为了一句话之失而拼命挽尊吧，阁下是谁我猜得出七八分，或许你还可能面试过我，跟我讨论 MBT 的核心难点在于脚本如何生成并且不等回答就直接否定说你们肯定解决不了这个问题的那位？阁下网上网下语气倒是一致得很啊。不过不得不承认招行的技术还是超级厉害的~

我保险、银行、证券行业算是都混过，像招行这个技术水平的真的没有，所以，不用揪着一句玩笑话就上火，就算是真做这个鬼，肯定也不敢卖给你们的

3.3+？

干嘛明年跳，现在就来啊，本司欢迎你，我这人就不怕 XDJM 们弱，就怕不想学、不会学

用 chrome 打开调试工具（F12），进入 console，输入：

alert(window.document.getElementById("mobile_file_url").getAttribute("value"));
如果你的网页有用jquery，那就这样写：
alert($("#mobile_file_url").val());
在jquery的前提下，如果这一句没结果，那就试试：
alert($("#mobile_file_url").eq(0).val());
如果有了结果，那就说明id使用重复，js或者jsp编译就应该有报错才对，可能被IDE给忽略掉了，找开发解决

如果以上操作，第一步弹出窗口有内容（就是那个 zip 的 url），那说明文档结构是没问题的，如果最终没有结果，那么还是要找开发去看，到底用了什么控件，是 flash 啊还是 SWFUpload 之类的什么鬼~

type=“hidden” 只是一个 “貌似为了” 防跨站攻击的隐藏域，用来记录一个随机串的吧，肯定于此无关，因为这根本不是 form 的属性，而是 form 的一个 childobject 而已

不妨换 xpath 试一下，如果 OK 了，说明前端有小 bug 或者结构太过复杂导致按照 id 无法查询到

单步等待的 API 封装，一般不赞成这么用

/**
   * Description: set element locate timeout.</BR> 
   * 内容描述：设置对象查找超时时间.
   *
   * @param seconds
   *            timeout in timeunit of seconds.
   */
  protected void setElementLocateTimeout(int seconds) {
      driver.manage().timeouts().implicitlyWait(seconds, TimeUnit.SECONDS);
  }

  /**
   * wait for the element visiable in timeout setting</BR> 
   * 在指定时间内等待，直到对象可见。
   *
   * @param by
   *            the element locator By
   * @param seconds
   *            timeout in seconds
   */
  protected boolean waitForElementVisible(By by, int seconds) {
      try {
          setElementLocateTimeout(seconds);
          WebDriverWait wait = new WebDriverWait(driver, seconds, stepTimeUnit);
          return wait.until(ExpectedConditions.visibilityOfElementLocated(by)) != null;
      } finally {
          setElementLocateTimeout(maxWaitfor);
      }
  }

  /**
   * wait for the element visiable in timeout setting</BR> 
   * 在指定时间内等待，直到对象可见。
   *
   * @param element
   *            the element to be found.
   * @param seconds
   *            timeout in seconds.
   */
  protected boolean waitForElementVisible(WebElement element, int seconds) {
      try {
          setElementLocateTimeout(seconds);
          WebDriverWait wait = new WebDriverWait(driver, seconds, stepTimeUnit);
          return wait.until(ExpectedConditions.visibilityOf(element)) != null;
      } finally {
          setElementLocateTimeout(maxWaitfor);
      }
  }

  /**
   * wait for the element not visiable in timeout setting</BR>
   * 在指定时间内等待，直到对象不可见。
   *
   * @param by
   *            the element locator.
   * @param seconds
   *            timeout in seconds.
   */
  protected boolean waitForElementNotVisible(By by, int seconds) {
      try {
          setElementLocateTimeout(seconds);
          WebDriverWait wait = new WebDriverWait(driver, seconds, stepTimeUnit);
          return wait.until(ExpectedConditions.invisibilityOfElementLocated(by)) != null;
      } finally {
          setElementLocateTimeout(maxWaitfor);
      }
  }

  /**
   * wait for the element present in timeout setting</BR> 
   * 在指定时间内等待，直到对象出现在页面上。
   *
   * @param by
   *            the element locator.
   * @param seconds
   *            timeout in seconds.
   */
  protected boolean waitForElementPresent(By by, int seconds) {
      try {
          setElementLocateTimeout(seconds);
          WebDriverWait wait = new WebDriverWait(driver, seconds, stepTimeUnit);
          return wait.until(ExpectedConditions.presenceOfElementLocated(by)) != null;
      } finally {
          setElementLocateTimeout(maxWaitfor);
      }
  }

  /**
   * wait for the element clickable in timeout setting</BR>
   * 在指定时间内等待，直到对象能够被点击。
   *
   * @param by
   *            the element locator By
   * @param seconds
   *            timeout in seconds
   */
  protected boolean waitForElementClickable(By by, int seconds) {
      try {
          setElementLocateTimeout(seconds);
          WebDriverWait wait = new WebDriverWait(driver, seconds, stepTimeUnit);
          return wait.until(ExpectedConditions.elementToBeClickable(by)) != null;
      } finally {
          setElementLocateTimeout(maxWaitfor);
      }
  }

  /**
   * wait for text appears on element in timeout setting</BR>
   * 在指定时间内等待，直到指定对象上出现指定文本。
   *
   * @param by
   *            the element locator By
   * @param text
   *            the text to be found of element
   * @param seconds
   *            timeout in seconds
   */
  protected boolean waitForTextOnElement(By by, String text, int seconds) {
      try {
          setElementLocateTimeout(seconds);
          WebDriverWait wait = new WebDriverWait(driver, seconds, stepTimeUnit);
          return wait.until(ExpectedConditions.textToBePresentInElementLocated(by, text)) != null;
      } finally {
          setElementLocateTimeout(maxWaitfor);
      }
  }

  /**
   * wait for text appears in element attributes in timeout setting</BR>
   * 在指定时间内等待，直到指定对象的某个属性值等于指定文本。
   *
   * @param by
   *            the element locator By
   * @param text
   *            the text to be found in element attributes
   * @param seconds
   *            timeout in seconds
   */
  protected boolean waitForTextOfElementAttr(By by, String text, int seconds) {
      try {
          setElementLocateTimeout(seconds);
          WebDriverWait wait = new WebDriverWait(driver, seconds, stepTimeUnit);
          return wait.until(ExpectedConditions.textToBePresentInElementValue(by, text)) != null;
      } finally {
          setElementLocateTimeout(maxWaitfor);
      }
  }

应该是，依赖的 JUnit、TestNG，把<scope>test</scope>都删掉就行了

参考一下：http://www.it1352.com/313066.html
实际操作起来，我发现其实这种操作在【效果上】还是阻塞的，并非异步
为什么呢？换个角度思考，有了这个 timeout，你在下一个 page 加载完成之前的任何操作（包括断言），也会有同样的超时设置作用于对你的 element 的加载等待，除非你故意在下一步操作之前把超时时间设置为 1s 或者更短~
所以我在脚本中基本不动这个设置，只有在初始化的时候通过全局设置一下，结合自己系统、环境的性能表现即可。

嗯，连测试工程师这个岗位都撤消了还说啥呢

链接: https://pan.baidu.com/s/1i5qwsVN
密码: ddf8

我再说一次我去蚂蚁面试的事情，第二次去蚂蚁面试的时候面试题就有一张累积缺陷趋势图，让我来说一下这个项目有什么问题，当时我惊叹于这帮互联网屌丝居然也懂我传统业务的管理办法……那时候开始我以为阿里在这块有一整套的评估和监控体系在实行，现在看你的描述，应该也只是某些团队才会有吧。

按照我的经验三五个 release 是要的，然后开始预测，然后分析、优化参数，拍拍脑袋瞎估算一下，稳定下来至少要：

• 团队人数、任务量稳定
• 扣腚的团队人数 8 人以上为佳，SRS 至少每个 release 要达到 5 个以上吧
• 但是新项目、产品研发，我一般第一个迭代上线之后就会立刻开始下一个迭代的计算，拿整个测试团队的平均参数水平来拟合，所以偏差难免会大点，但是越早开始，后面越早贴近真实情况

每个团队的业务类型、复杂度不一样，即便是同样的开发量，缺陷密度也不一样，所以，参数要具体到每个产品或者业务系统，分析的维度也可以多元化：按产品、按产品的 release、按开发团队、按测试团队……最后在一维分析的基础上再做二维、三维的分析，比如加上时间周期来看整体的趋势，这样在全年工作衡量乃至考核打分的时候都有点参考价值（这是大 M 的事）。

看样子你还是没好好琢磨透 webdriver 怎么工作的啊，给你个样例你看下：
每一步操作，工具都会自动等到你设置的超时时间（pageLoadTimeout、implicitlyWait）过了才会继续判定为失败，在此时间内会自动轮询检查的
对 ajax 局部刷新，一样有效

@Override
public void startWebDriver() {
    cleanBrowserProcess();
    try {
        initWebDriver();
        driver.manage().timeouts().pageLoadTimeout(maxLoadTime, TimeUnit.SECONDS);
        driver.manage().timeouts().setScriptTimeout(maxWaitfor, TimeUnit.SECONDS);
        driver.manage().timeouts().implicitlyWait(maxWaitfor, TimeUnit.SECONDS);
        driver.manage().window().maximize();
    } catch (Exception e) {
        LoggerUtils.error(e);
        throw new RuntimeException(e);
    }
}

丑便丑了，我再晒一图，我一直引以为傲的：

一个比较初级的版本供参考，说明：

• 基础配置数据需要自己灌（劝你别费劲了）
• 存储过程居然都在 mysql 里面（这个锅我不抗）
• 前后端分离没做干净，所以有些页面无法访问
• 地址：https://github.com/fudax/sqcs

• 肯定可用，而且具备参考价值
• 这个公式的每个参数，是需要拿既往数据来调整之后才能去拟合的，并非每个团队都能通用

我之前在平安科技做这个工作比较久，不过计算用存储过程搞的，推算出预期之后再来观察每天工作是否到位，我们的版本周期只有 15~30 天，所以周期上不会有太大差别
除了这个 Gompertz 之外，还有个 Rayleigh 模型，更精细，用于分阶段预测甚至推算线上 bug 数，至于效果么，我说两条：

• 不见得每次都那么好，因为维护性、补丁性的变更版本和大项目不一样，大项目从头来过，没有历史数据好参考
• 最好把这个计算用规则引擎实现一下，各个参数可以动态调整才是王道，这伴随团队成熟度和管理水平而动态改变，并非一成不变

图例：

再看下，到年底了，发生了什么

凡是带分支的测试都是不合格的测试，因为你想用一段代码囊括几个场景，包括有效的、无效的等价类，这是违背测试设计原则的：

• 用尽可能少的 case 覆盖尽可能多的有效等价类；
• 每一个无效等价类至少需要一个 case 来覆盖！

所以，你的 test 不能太过纠结于 PO 还是 BOT，要把操作组件拆分清楚，比如

• 打开 url 做跳转这是一组，跳转的不是你的预期就直接通过 assert 去终止这个测试；
• 输入用户名、密码、验证码，点击登录，然后 assert 成功还是失败，这是一组；
• ……

总之自动化测试也是测试，不要想着偷懒用 if else，select case 去覆盖，应该把每个分支做成一个@Test，换位思考，如果开发的代码里一大堆 if else 让你测试，你恼火不恼火~

节后 renew~
有意的可先私聊，聊完再决定投不投简历