“君子慎独，不欺暗室，卑以自牧，含章可贞”，人性最危险的时候也就是一个人的时候。

背景

看到有人在TesterHome上写了一篇关于测试工作的吐槽：三年功能测试，测试工作吐槽，于是我决定也写一篇测试那些事。

问题一：测试时间评估

一般需要评估时间的都是项目型的测试，如果是走迭代的话，基本就是不需要评估时间了。

  • 突然拉你去评审，然后对于那种一评审完，就开始评估时间的情况，我通常会用开发时间的50%、70% 或 80%（更具业务的复杂程度增加减少百分比）。
  • 是有时间写完用例在评审，那就根据自己写的用例来进行量比就好了。
    通常都会遇到压榨测试时间的情况，如果自己搞不定，那就向上反馈，把问题说清楚，该加人加人，该延期延期。

问题二：同时多项测试任务

现状：测试着 A 任务，就接到 B 任务的需求评审，已上线的 C 任务现网出现了些问题反馈需要你跟进，然后测试组自动化的任务 D 也要完成进度，最后 C 任务根据用户的一些反馈做了功能整改，拉你评审和排期。

  • 明确优先级，善用项目管理工具，把任务分好优先级，先做截止日期近的任务，灵活应对变化和紧急情况。如果有紧急插入的任务，那就和产品开发沟通好顺延当前在做的任务。
  • 提前做准备，一些预备工作在不忙的时候就开始着手，不要等到要测试了还需要走流程造数据。
  • 学会向上管理，自己什么实力不仅要自己清楚，让你的上级也清楚，直接在源头就避免给自己安排过多的工作。

问题三：需求不明确

常见的三种情况：

  1. 一句话需求，甚至需求文档写在 txt 里，就一句话，eg:【充值满 XX 元获得奖励】（本人真实经历）
  2. 抄袭的需求，同为差不多的功能，拿了其他产品的需求文档适当做了修改就发出给研发
  3. 全文字需求，无流程图 无交互稿
  • 测试推动产品，实在是和产品聊不动的，你就和你的上面聊吧，总不能一直混吧。
  • 需求不要只是口头讨论，最好在群里沟通，让开发一起确认。

问题四：线上出现 bug

测试过程中难免会遇到线上BUG，有可能是有人离职了然后接了别人的项目，之前遗留的BUG，有可能是自己漏测等等很多情况。

  • 遇事冷静分析，定位好问题，然后让开发修复。一般只要不是致命的导致公司有直接利益损失的BUG，都对你没有什么影响。
  • 做一个错题本，将自己之前遗漏的，没有覆盖到的场景记录下来，没过一段时间归纳总结一下，逐步提升完善自己的测试能力。
  • 一些技术BUG可以尝试深入了解它的根本原因，思考一下自己如果是开发会怎么做，又该如何避免这类问题的发生。

问题五：测试报告风险规避

  1. 测试日报中，阻塞测试进度 bug、偶现 bug、p0 级未解决 bug 需要标红加粗放在测试报告醒目的地方
  2. 对于测试环境无法完美模拟现网环境的测试场景，需要在报告中标红加粗体现（风险多说不亏）
  3. 测试进度根据测试用例执行的百分比来写

问题六：测试时间不足

  • 开发延期：喜闻乐见的情况，鉴于经验通常都是延期 1-0.5 天，所以测试时间评估一般都要在自己评估的时间上至少 +1 天，同时保持在开发转测时间的前一天问下开发进度的习惯。如果开发给了进度不乐观，及时同步给产品和测试领导，看产品是否可以调整时间或者领导这边加测试人力。将测试压力尽量提前告知，给测试领导和产品有调整分配的时间，不要依赖开发去反馈

  • 产品上线日期提前：没有任何方法预防，一般大老板开口了，测试领导比你还紧张，会积极询问你测试进度情况和风险，你这边要是没把握，可以提出增加人力的要求。

  • 需求变更： 需求变更也是很常见的，特别是都转测了，产品那逼还在每天优化更新他的需求文档。这里需要预防一个坑：你要截图保存他转测前的最后一次需求文档并发到大群 @ 相关人，防止后面现网出现需求不一致情况时，产品拿着他未同步且更新过的文档来兴师问罪。到时你百口莫辩，特别是测试地位比较低的公司，产品修改需求是不跟测试及时同步的。 时间上也以每次变动的大小产生的影响，记录在测试报告上，规避背锅的风险。

  • 测试人力变动： 原本两个人测试的任务，因为其他原因变成一个人。这也是很常见的情况，特别是两个人当初分好了测试范围，你这边只了解和评估了自己的范围，对其他人那部分并不了解，无形之中增加了后期的测试压力和时间。这种情况通常没啥好的解决方法，记得要哭惨，要让测试领导和产品去协调。别一个人傻傻的硬撑疯狂加班

  • 测试物料阻塞：电商类型的项目通常涉及一些消费券的申请和配置，同时这些券的使用还带风控判断。测试这边要根据情况，转测前提前沟通准备好测试物料，申请需要用的白名单和权限，熟悉好对应的配置系统。防止正式转测前，被一堆权限和申请的事情严重拖延到进度。

  • 复杂的业务逻辑： 具体情况具体分析，根据经验，面对复杂的业务逻辑，最好的方法就是编写清晰、详细的测试用例。对自己要有 B 数，评审阶段感觉吃力就求救兵

问题七：提测质量不高

目前比较好的办法：转测前，出一份冒烟用例给开发，通过冒烟用例后才能转测，否则主流程测试阻塞，只要代码有大改动，基本都要重新测。测试地位比较低的公司，可以把这个流程安利给测试领导和产品，让领导去推动。

问题八： 业务自动化实现

一般有想法技术总监或者测试领导者总会去做自动化，所以尽量不要因为看到网上各种自动化做了没有的想法就被影响了，其实做好了自动化的公司多了去了，然后取得了效果的也有很多，下面简单说一下个人的理解吧。

  1. 首先调研好自动化测试工具/平台，推荐Apifox或者metersphere这种比较成熟的平台。
  2. 组织好测试用例，并不是所有的功能测试用例都需要转化成接口测试用例
  3. 规划好自动化测试的标准，不要做的一个一个样。
  4. 如果是流程型的功能，可以分模块进行，最后在将么个模块组合起来组成一个个流程型的用例。
  5. 如果是数据统计的那种功能模块，那就需要根据具体情况来定制化编写自动化检测脚本，然后集成起来。
  6. 将用例划分按优先级，然后进行自动化用例的编写
  7. 一定要定跑，定期维护，当然能持续集成起来那就最好了。