灌水 三年功能测试,测试工作吐槽

测试新人 · 2023年12月19日 · 最后由 质量小白 回复于 2024年06月11日 · 42327 次阅读
本帖已被设为精华帖!

概述

社区里大部分都是测试开发的分享,作为功能测试,我也分享下日常工作中功能测试值得吐槽的问题,由于工作时间不长且未进过大厂,不了解大公司的工作模式和流程,所以自己的方法和理解都是基于中小公司的工作经验总结,应该适用于跟我一样的小白,没有各种高大上的左右移动,测开大佬们轻喷。

问题一:测试时间评估

这是一个工作日常经常需要回复的问题,理论上 测试这边要做出较科学合理的回复,那就要将
【需求变更】
【开发进度延误】
【bug 修复不稳定】
【复杂业务流程】
【测试环境不稳定】
【上下游服务依赖】
【人员资源】
【是否引入新技术】
【回归范围】
等等不确定因素考虑进去,再多方沟通确定才能获得相对合理的答案。但现实里 一个功能测试会同时测试几个项目,通常是最晚得知新需求的内容,需求评审会议都是被冷不丁拉入,然后产品劈里啪啦讲完后就让你给个测试时间,方便他安排工作。

  1. 临时进入会议,需要你马上给个估计时间场景:

    1. 询问开发所用的时间,将测试时间设定为开发时间的 50%、70% 或 80%(根据现场氛围说自己的百分比)
  2. 流程较规范,测试先拿到需求文档进行评估:

    1. 编写完测试点,根据一条用例平均 5 分钟的时间,然后根据一天实际能干活的时间,例如用 6 小时去粗劣计算天数,越多越好(测试时间肯定会被压缩)

注意:如果觉得系统很复杂,自己无法正确评估,拉上你的领导/组长一起判断,千万别不好意思或者觉得这样显得自己很差,我们是功能测试,要学会哭惨!,任务太难或者太多就让组长拉多一个人来帮忙。同时测试这边投入的人力数量需要告知下产品,防止那种一旦看到时间有盈余,就疯狂后期加需求的产品。



问题二:同一时间需要完成多项测试任务

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

  1. 需要当天确定的任务:

    1. 紧急且重要、紧急但不重要、不紧急但重要、不紧急且不重要。四个级别分类任务,虽然老套,但是真的有用,事情一多时,人特别容易烦躁,这时候就需要一个指导思想
  2. 多个周期任务:

    1. 依据截止日期, 根据任务的截止日期制定计划。先处理最紧急的任务,确保不会因为延误而影响项目进度

注意: 任务多顶不住就求救,别硬撑,看过应届生一个人测试着吃力不说,搞得老同事接锅加班的


问题三:需求不明确

这应该几乎是所有功能测试都会遇到的问题,主要分为三种:
(1). 一句话需求,甚至需求文档写在 txt 里,就一句话,eg:【充值满 XX 元获得奖励】(本人真实经历)
(2).抄袭的需求,同为差不多的功能,拿了其他产品的需求文档适当做了修改就发出给研发
(3).全文字需求,无流程图 无交互稿

  1. 情况一:(老实说这种类型的产品一般都是愣头青,你要是把需求文档打回去,通常情况下只是从一句话需求变成十句话需求,解决不了问题,你还是要在时间内完成测试)

    1. 测试这边辛苦些,拿上述一句话的例子【充值满 XX 元获得奖励】,列出不清晰的点:缺乏详细活动规则说明、奖励类型不明确、具体数值、活动触发条件、用户资格验证条件、界面展示交互、奖励发放的触发时机等
    2. 与产品经理电话沟通,询问有关背景、业务目标、关键功能、用户期望等方面的问题,然后将列出的不清晰点发到大群并 @ 开发和产品,让其在文档里做补充
    3. 千万别和产品私聊然后自己一个人确认需求,全部互动都要在大群
  2. 情况二:(通常拿来主义的产品都是很懒的,同时没啥主见,甚至他会叫你去找他抄袭的那个产品聊,麻烦的点主要在于实际转测后发现功能实现与文档不一致,开发给的原因是其中的业务逻辑或用户需求不适用于当前项目)

    1. 转测后,让产品提前先体验,让产品先满意后再测试
    2. 其他参考情况 1
  3. 情况三:(通常这类产品还挺固执,认为自己描述得很清楚)

    1. 解决方式基本和情况 1 一致

注意:以上三种情况,务必都要告知自己的直属领导,同时减少和产品的私聊,多在大群里聊,多留刷锅的证据


问题四:线上出现 bug

线上出现 bug 时,大多第一时间会很慌,生怕是自己的锅,所以步骤很重要,一方面防止非自己的锅被人甩在身上,一方面要显得自己是个负责的成熟测试

  • 通常都是群里忽然炸锅,截图出 bug 点,然后产品们叽叽喳喳
    • 1. 冷静点,群里先发一句:“我定位下,看能不能复现”
    • 2.现网尝试复现 bug,如果 bug 能百分百复现,@ 相关开发排查,并发出便于定位的相关的日志和信息
    • 3.测试环境尝试复现,若能复现,查询下测试用例有无覆盖当前的场景【确保不是测试用例执行遗漏,执行遗漏和覆盖遗漏是两个不同的锅,执行遗漏是态度问题,很严重的】
    • 4.如果是自己的锅,记得表现出积极解决问题的态度,配合开发检查修复状态,并同步到大群,要将 bug 出现的原因和修复方法了解清楚,方便后续做复盘和回答领导的询问。
    • 5.如果是他人/环境的锅,要表现出超级积极解决问题的态度,将 bug 原因和修复情况实时同步到大群

注意: 遇到线上 bug,一定不要急着疯狂甩锅和叠 buff(这个在测试阶段时就要上的护甲,测试报告提示风险和大群聊天记录),要表现出先解决问题的态度,同时搜索对自己有利的条件。

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

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


问题六:测试时间不足

造成测试时间压力的通常有以下几种:开发时间延期、产品上线日期提前【大 boss 给的压力】、需求变更、测试人力资源变动、测试物料阻塞、复杂的业务逻辑。通常遇到时间不足,最好的解决方式还是加人,其他的只能前期进行预防```

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

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

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

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

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

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



问题七:用例执行困难

* 用例执行困难,通常是开发质量差导致

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


问题八:测试数据陷阱

常出现于前端开发,转测时给你的 mock 数据与实际现网数据结构不匹配,如果你是比较擅长 mock 数据和做代码 review 的,通常还挺容易踩这种坑,拿着这个错误的数据模板做了多个边界值和数据类型变化测试,代码对每个数据的处理逻辑也是正确的。然后发布到现网就报错无法交互

  • 对开发要保持怀疑的态度: 验证环节需要接入现网数据去看测试页面的响应是否正确


问题九: 业务自动化实现

很多公司的业务通常都是未经探讨直接强行自动化的,UI 自动化能阻止就阻止,阻止不了就加入。对于接口/ui 自动化,老实说我一直觉得最好的提效方式就是找个市面上商业化的自动化平台工具,直接买来就用(面过一个国企,他们就是这样干的),都不用投入什么人力,付费工具那点钱对公司来说也不多,测试这边还能把精力放在业务上,有需求就给技术方提,这才是最好的提效方式。可惜现在都要抽出一部分人力去搞这种做完很少人用且不好用的平台,搞笑的是这些平台的技术难点都集中在前后端框架业务实现,反而能在业务中起到多大作用的考虑倒是最低的,基本还是走的请求返回再断言那套,或者更魔幻点的 UI 自动化都给你加上 AI 赋能寻找控件。。。。。其实大部分都是把实现过程复杂化,然后起作用的还是你用最原始的 pytest+request 组合去断言那套

  • 公司最好的方法就是跟随大众,自动化技术能力基本都是测试标配了,但是能把自动化设计好的估计没几个

待续

共收到 42 条回复 时间 点赞

一个功能测试同时测试好几个项目,除非业务相关相同,不然也太惨了😂 ,借调支援也得花 1,2 天熟悉呀。用例执行困难,也有可能用例不是自己写的,前人埋坑后人遭殃,每个人用例习惯不一样,版本紧急过来支援只能拿别人以前的版本用例跑好 ex 啊。测试时间不足,还是得向上反馈,能加班搞的加加班,不给加人就只能拉产品确定下测试范围优先级了。自动化赞成,如果没有拿得出手的产出收益,领导强推,不过只是为了年底他们自己卷 ppt 汇报的几行数据罢了😅

写得很实际,对新人确实有很大的参考作用,本人也有相关血泪经验教训深有同感。 @Lihuazhang 要不考虑加个精。

王稀饭 回复

不需要吧,一个吐槽帖,没啥技术含量😂

看来题主是个很懂得总结的人,确实都是一些高频问题

这就是现实与实际的区别,无解有时候

王稀饭 回复

虽然标题说是吐槽,实际上很多场景都给出了解决方案。

这是一个很好的方式,不是一味去抱怨。我也觉得应该给精华。

测试新人,很用心的一位后生,前途无量。

UI 自动化能阻止就阻止,阻止不了就加入.

真实践行了打不过就加入的原则,哈哈

脚手架这个词看到过好多次了,请问是什么意思呢

挺好的解决思路,不过有时候有些东西还是无解。

王稀饭 将本帖设为了精华贴 12月20日 10:41
wangwangtest 回复

类似一个最基础的项目结构和配置。类似 “npx create-react-app react-basic” 的指令,就会生成一个基础的 react 项目结构文件,你可以直接去上面写和改

C_Two 回复

肯定的😂 毕竟你永远也想不到会遇到什么性格的开发/产品/领导/老板,有个过了磨合期的开发/产品,才可以少踩坑。否则真的防不胜防

点都很真实,解决方案也给的很靠谱,但有些问题还是无解。比如现在公司效益不好,研发都是以产品为导向。项目立项的时候就已经确定了上线的 deadline,过程中需求延期、开发延期、需求变更。。。,后期测试堆人能解决上线时间问题,但质量就堪忧了

为啥问题八不见了😂

总结得不错,但是太多斜体,看得费劲😂

非常好,环境的问题没法改变,只能提升自己,有些产品就是懒狗,你催也没有用,尤其拿来主义

开发质量差,且不自测是最让我难受的😡

ChampionH 回复

有个和自己磨合至少一年的开发很重要

Ikaros灬 回复

第八点: 场景通常发生在 H5 页,需求只有前端页面(大部分是旧页面改皮活动),后台数据拿的旧接口或者其他项目组的。转测只有前端页面,开发转测时会附带 mock 数据模板 eg:

{
  "user": {
    "id": 1,
    "name": "test",
     "years": 25
  }
}

实际上旧的接口可能已经发生了变化,新的返回数据是

{
  "person": {
    "userId": 1,
    "fullName": "test",
     "age": 25
  }
}

前端这边按照旧的数据进行调试,告诉你也是旧接口,如果没有踩坑经验的就会用他给的这个旧数据模板去测试。那上了体验服或者现网就会因为结构不同,产生代码错误、页面显示问题、逻辑错误

Ikaros灬 回复

我没那么深的觉悟😂 ,我就是个打工的,公司墙头草,无限趋利避害

其实这就是很多小公司的现状,但话又说回来,能处理好这些现状问题就已经是你在公司的能力、价值的体现了,而不是说只有你搞了个什么平台,写了个什么框架 balabala 的,当前的公司需要的就是这些。

disciple 回复

😂 现在是吃鸡模式了,得趁早逃出裁员圈,按这趋势后面的卷翻天

三年经验的同学能做出这样一份总结,真的前途无量,继续加油! 经常复盘、反思、总结是一个非常好的习惯。

碰到测试 产品,前端组长都害怕的人写的代码测试 才是最头疼的

哎 作为一个测试尽然没看懂这篇文章在写啥 悲哀啊 看来要被行业抛弃了

凡尔赛?

测试 6 年,半天打不出一个屁的我..😂

活着丶 回复

试下,边写边想,感觉跟巩固知识一样,难怪公众号们都喜欢写,可以加深理解

三年测试总结成这样只能说明两点,一个是你善于观察和总结,二是你的测试环境真的够锻炼人的

ola嘿嘿 回复

emmmmmmmmmmmmm, 我想知道哪家公司的测试环境不是这样的?

有幸经历过,话语权这事儿要看主管的高层是否看重技术以及测试管理者的能力。
有的公司 QA 岗很牛逼,比如以前 360 的某些事业部。

3 年能有这样的见解,不简单,给楼主打 call

ola嘿嘿 回复

再怎么看重技术能力,也是要有人测试业务功能的呀😹

还有一些情况,开发提测后你才知道有需求,而且需求也不明确,也很紧急,没有什么时间来编写管理测试用例

很不幸关于文中提到的三种需求情况都遇到过。更离谱的产品直接复制邮件需求后让开发自行设计,最后和开发商量了一下怎么改动,测完后产品过来找我了解需求😁

我六年看你这个觉得不错哈哈哈哈哈

A11 功能测试吐槽 中提及了此贴 06月11日 13:55
小黑子 功能测试吐槽 中提及了此贴 06月11日 13:58
王稀饭 功能测试吐槽 中提及了此贴 06月11日 15:03
王稀饭 功能测试吐槽 中提及了此贴 06月11日 15:03
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册