-
有从事信贷测试的同学吗？线上测试是如何进行的？ at 2020年10月15日
没做过这个行业，要不你到三和市场雇个做日结的大神？一天才一百块好像
-
测试开发与自动化测试的本质区别是哪些？ at 2020年10月15日
自动化测试分两种
一种是也做业务也做自己做的业务的自动化，一条龙跟下来的具有自动化能力的业务测试。这个模式。本质上是业务测试。
另一种是专职做自动化，其他业务测试做用例，他只负责用例自动化的（这种模式比较少用了，因为用例的沟通理解成本高，误解风险大）这个不深入讨论，很罕见。
专职的测开本质是开发跟测试没啥关系（当然很多顶着测开头衔的测试是另外一回事）。 -
请问大家，各个公司的开发和测试比例能做到 5:1 是怎么做到的 at 2020年10月15日
很简单，让开发自测 + 容忍漏测。
腾讯经常搞出十几个开发配一个测试的情况，就是让开发自测 + 容忍漏测。 -
论测试工程师的职责 at 2020年10月15日
左移，右移要搞；但是左移势必和开发的工作产生重叠，很多测试左移工作实际上是 “帮助开发完成自测”，所以哪些要左移哪些要让开发做好自测，就要定义清楚。 糟糕的是目前这个没有业界统一标准，甚至同一个公司不同部门也相互差别巨大。
于是会出现一个人，适应 A 部门的分工，但到了 B 部门就适应不了的现象，因为两个部门测试 和 开发 两个角色分工差异较大。
同时也给招聘工作带来巨大麻烦，需要去验证候选人能够适应当前团队的分工，而如果当前团队的分工不合理，往往也会加剧人员流失，造成招聘工作频繁发生，更加剧了招聘工作量。。。。 再加上 测试工作频繁交接带来的风险和低效率。。。
左移，怎样左移，移到什么程度，真是个大问题。右移反而清晰一些，大多数情况是，测试想找运维要线上数据，运维不给，不配合，基本以运维配合的程度为界限，界限分明一些，比较好做，能做到哪做到哪，大佬想推就往运维那边甩，有大佬压力，运维配合给拷贝数据，导流量就做，而且右移对质量保障和提升效率的效果比左移明显。 如果遇到线上风险大，测试不用说话，运维直接把方案拍死，大佬一般也不会强推毕竟大佬也不想出事故。
-
面试系统测试职位 二面被开发人员面试 at 2020年10月15日
这就是一个分工混沌的地方，我觉得纯粹的测开应该就是开发，测试是他开发的系统的使用方而已，开发会计系统的人一定要懂会计吗？ 为啥开发测试工具平台的人一定要懂测试？
-
面试系统测试职位 二面被开发人员面试 at 2020年10月15日
我一般喜欢用独立进程，让操作系统来管理多线程多好，非要自己管理多线程多此一举，测试脚本没必要考虑执行效率优化到线上服务级别啊。
至于数据共享，为啥有 redis，mysql 不用？嫌厚重？还有 sqlite 呢。 测试脚本应该多用简单的积木少自己实现功能。 -
如果你面试 “测试工程师”(非测开) 岗位的候选人说他曾经开发了个测试服务放在网上卖，你会怎么做？ at 2020年10月15日
实际遇到我可能就选 C 了
-
# 每日一道面试题 # 谈谈你职业生涯中遇到最难的 BUG at 2020年10月15日
我遇到过一个 bug，必须一直跑 7 天不重起才能发现它，而给我的测试周期没有 7 天（简单的说就是连着跑 7 天以后一大半请求会直接报错），而且还是开发代码夹带，提测需求单里没提这茬，而测试周期的评估是按需求单的。。。。。。。。。。。。。。。。。。就这样我把这个 bug 给漏了，然后 7 天后被运维发现，我就这样稀里糊涂的有了一个现网 bug，还是特别严重的那种。。。。。
开发这样害我，我该怎么办？？？？
-
固定 QPS 压测模式探索 at 2020年10月15日
Apache Bench（对发压机性能要求低但是不支持复杂测试，只能测试单一接口的单步操作，可以多开几个进程同时测多个接口但不能用前一个接口的响应作为下一个接口请求的一部分）不就是固定 QPS 吗，另外 jmeter 用 Synchronizing Timer 也可以实现，可以做复杂测试（需要发压机性能较好）
-
测试人员有 80%的都是从培训机构出来的，认同吗 at 2020年10月15日
测试人员的新姿从 5000 到 50000 分布着，也有低于 5000 和高于 50000 的少数
-
关于测试线上缺陷率，大家有没有什么好的建议。 at 2020年10月15日
这里面有几个问题
第一 线上缺陷分为本版本引入和历史遗留爆发两种
我见到过一个项目，线上发现的缺陷 90%+ 是历史是当前测试人员接收以前的版本引入的历史遗留 bug，就是那么多历史遗留 bug 不容易被发现，也不一定就是当前测试人员牛逼，也不一定之前测试人员不行，可能是当前测试人员漏的 bug 可能在两三年后在线上被发现呢。 这种情况下 该怎么统计才合理，如果严格按照这个线上故障率统计，结果只能是负责这个项目的人永远绩效很差，没多久就跑路。第二 线上缺陷的界定往往由运维团队界定，比如一个服务有三百多个监控项，运维看不过来，只挑二十几个主要的看，然后某一次在这二十几个之外，三百多个之内的一个监控项有异常之后不久服务挂了，经过讨论大家认可这种情况属于使用方使用不当给与短时间负载过高，挂了是合理的，但没告警不合理，运维坚持二十几个主要告警里看不出来，所以这是缺陷，开发说我三百多个告警呢谁让你只看那二十几个的，这不是缺陷？ 这种扯皮怎么算，究竟算线上缺陷数 +1 还是不算？
第三 测试阶段发现的 bug 也分为测试中发现历史遗留 bug 和发现当前版本 bug 啊，要区分开吗？
-
关于测试线上缺陷率，大家有没有什么好的建议。 at 2020年10月15日
这里面有几个问题
第一 线上缺陷分为本版本引入和历史遗留爆发两种
我见到过一个项目，线上发现的缺陷 90%+ 是历史是当前测试人员接收以前的版本引入的历史遗留 bug，就是那么多历史遗留 bug 不容易被发现，也不一定就是当前测试人员牛逼，也不一定之前测试人员不行，可能是当前测试人员漏的 bug 可能在两三年后在线上被发现呢。 这种情况下 该怎么统计才合理，如果严格按照这个线上故障率统计，结果只能是负责这个项目的人永远绩效很差，没多久就跑路。第二 线上缺陷的界定往往由运维团队界定，比如一个服务有三百多个监控项，运维看不过来，只挑二十几个主要的看，然后某一次在这二十几个之外，三百多个之内的一个监控项有异常之后不久服务挂了，经过讨论大家认可这种情况属于使用方使用不当给与短时间负载过高，挂了是合理的，但没告警不合理，运维坚持二十几个主要告警里看不出来，所以这是缺陷，开发说我三百多个告警呢谁让你只看那二十几个的，这不是缺陷？ 这种扯皮怎么算，究竟算线上缺陷数 +1 还是不算？
第三 测试阶段发现的 bug 也分为测试中发现历史遗留 bug 和发现当前版本 bug 啊，要区分开吗？
-
外包公司赚了多少差价？ at 2020年10月15日
朋友手下的一个外包，公司成本 25000，外包妹税前工资一万多。这个外包妹能力很强，以至于这个朋友因为这个外包妹离职了，一度怀疑自己能不能继续做下去有打退堂鼓的打算。
外包公司吃人不吐骨头的