• 同 10 楼,面试官在面试你,同时也是你在面试面试官

  • toB 业务的测试难点 at 2021年10月11日

    我的理解是银行对资损防控上的谨慎,直觉上银行是直接管钱的,而互联网金融是间接操作钱(或许碰不到实际的钱,最终还是要去到银行?)。在用户体验上的评价是这样的,欢迎澄清一下区别

  • toB 业务的测试难点 at 2021年10月11日

    测试数据

    这就是第一个难点,测试数据的缺失。虽然我们可以通过 mock 的手段,把自己的系统测试充分,但是全链路联调测试阶段和预发阶段都没有办法保证。这一点,其实还是非常影响发布信心的。

    财经的 QA 会自己花钱在线上真实环境跑用例(转账、付款),最后再走退款流程把钱拿回来,也有在用流量回放、MockServer 等技术。

    测试环境

    对于老功能的回归,通常下游机构是没有义务配合你做回归测试的,所以他们更加不太可能有一个稳定的环境提供给你做回归测试。那测旧又该怎么办?这也是我们目前遇到的问题,没有一个稳定的测试环境,可以用来持续回归。

    关于线上压测和回归,忘记之前从哪里听说的,银行那边会给个固定的压测 QPS 要求,如果超过这个 QPS 就算发压方(也就是我们)的事故。
    吐槽一下,平时用个招行银行 app 转账还提示等待 10 秒,用支付宝和微信转账根本不存在这种等待,就是传统银行跟互联网的区别,背后就是新老技术架构、风险承担能力、成本结构的差异。

    业务中台

    当然这个时候,也给中台投入了专职测试了,要把中台的质量最厚,测试策略也调整为:中台功能测试 + 中台回归测试 + 上层业务回归测试(可评估)。目前还在试验中,其实也不清楚是不是有效果。

    以前跟教育业务线的小伙伴交流过,他们比楼主更原始一些,部分教育线的业务中台甚至跟上层业务耦合在一起(也就是业务中台给不同业务做了一堆定制需求)。导致了但凡中台一改,很多业务都要跟着回归一遍,或者业务改了,中台要跟着改,互相坑。

    他们的改进路线也比较明显,先让中台逐渐与上层业务解耦,解放测试人力,然后也是将部分 QA 挪到中台中做专项测试(其实很多业务线都是这样做,中台作为最核心的部分,不放人去做专项测试是不实际的,自己都方得都命)。

    另一个点,正因为中台是通用且稳定的,意味着老逻辑改动频率低,所以中台更加适合做各种自动化回归(接口自动化、流量回放等),这个收益应该是比较显著的。


    由于自己没怎么接触过这类 toB 业务,也就只能把一些道听途说的东西写上来。对于测试数据和测试环境,简单问了财经的 QA 同学,答复中没特别的信息,估计也是存在一样的问题。

  • 这个回答下面一共有 467 个回答,我通过这样去请求,只会获取到 181 个回答,其他的回答就获取不到,如果把 467 设置为更大的值,获取到的还是 181 个回答

    后端的防护性编程,为了防止前端传参过于离谱导致数据库压力过大,合理操作。你就自己设置一个合理 offset 分几次循环去请求就行了,也没必要非得一个请求拉下来所有回答。如果你嫌弃 for 循环串行请求耗时长,你就上多线程或者异步,网上很多资料。

  • 仅楼主可见
  • 接口的排列组合测试 at 2021年10月08日

    这种需求最好就是直接白盒测试,根据等价类划分和边界条件来区分 case,穷举遍历没有任何意义。好比我的代码逻辑是

    int a,b,c;
    c=a+b;
    

    那无论你穷举出多少个 a 和 b,你不过就是在测试 java 的加法有无 bug,根本就是在做无效测试。

    有一个问卷调查,包含 9 个小问题,每个问题有 A B C D 等多个不定项选项,每个问题的每个选项对应不同分数。

    所以我觉得关注点并不是穷举 A B C D 分数总和(这个求总和可能就是一行代码而已,如果没有额外的条件分支,那一条 case 都过了),而是不同题目的 A B C D 这几个选项它本身映射的分数是否符合预期,以及几个关键的分数总和点和答题场景(如全对、全错、对错混合、部分题目没作答、全部题目没作答)

  • 驱动我自己变化的,主要是周边工作环境和工作接触面的变化。

    工作环境的变化:人外有人天外有天,无论是牛逼的前辈,还是变态的后浪,出现在身边的案例越来越多,反正明白的一点是 自己很菜 。自知之明确立下来,人就知道了自己的定位,自然会有动力去不断学习,只是这个学习的过程它本身是否高效而已(我觉得我是比较低效的 QAQ)。
    @ 恒温 也提到,有些人 5 年的工作经验可能只是跟 1 年一样,有些人 1 年的工作经验就是实打实的 1 年甚至更多,如何衡量这个 “实打实”?自己问自己,对于这个业务或者事物,它的方方面面,无论是本职的,还是上下游,从 透彻->理解->熟悉->了解 列一下,就知道水平了。

    • 透彻:有行业视野,能判断出什么是好什么是坏,能根据场景客观评价技术,看清趋势,灵活应用实践
    • 理解:明白整个事物的逻辑,背景、解决的问题、技术细节都掌握,达到自己能把核心的东西做个简单版的地步,对不同替代方案的优缺点有一定了解
    • 熟悉:知道这个事物的落地形式,有真正参与建设过,对单点细节有一定理解
    • 了解:知道那么个概念,知道其所解决的问题,最好有使用过

    (以上分类仅供参考,临时写的……)
    避开重复劳动,在熟悉以及理解本职工作后,尽量去往上下游拓展,去 “偷师”。其实跟楼主说的【差别在于花了多少时间提升自己】意思是一样的。

    工作接触面的变化:很多时候只有实践才能出真知,这个感同身受,有些东西说得很简单(它不一定是纯粹的技术),但是做起来非常复杂琐碎难处理,最后做出来的效果也因人而异。接触过不同的技术领域,如果把它们放在一起来对比看待,有时候会有新风景,或者说自己脑袋中会出现一个更全的图。这个 “图”,可以支撑你在不同的公司,按照这个 “图” 来一步一步完成建设。说白了,你的知识体系和经验会更加完整。对于创业公司来说,你这个 “图” 可以帮助公司识别哪些建设是最高优的,然后调动人力尽快拿到收益;对于成熟公司来说,你这个 “图” 可以帮助公司识别还欠缺什么需要建设或者完善,做到百尺竿头更进一步。

  • 仅楼主可见
  • 顶一下帖子,长期有效(至少是半年内)

  • 好吧,首先楼主估计就是来打广告的……

    看到帖子里提及 Fastbot 工具,确实好用,平时跟 Fastbot 团队同学往来十分密切,有多次出差约饭的经历,在 app 稳定性测试上,Fastbot 应该是市面公开最好用的工具之一了吧。不过外部公开的是超级阉割版,内部还有各种多机遍历、用户模拟、定向测试等高级特性,很多都是跟 Fastbot 服务端有直接通信的,算法模型直接放在服务端而非客户端,估计短时间也不会公开。

    核心业务大都承载在移动 app(类游戏系列)时,如何做好回归测试,缩短测试周期,实现快速交付呢

    不过,Fastbot 只是用来做稳定性测试,换而言之它只能断言崩溃卡死问题(如果 app 本身接了 apm 那就更好),无法识别 UI 层面甚至白屏黑屏的问题。
    这种这么范的问题,妄想通过加一个工具就能解决,第一个还是先从流程上解决沟通效率问题,流程顺了各自分工明确了效率就会高起来。
    UI 自动化用来做回归测试,绝大多数就是一个谎言,现阶段大多数公司甚至大厂,UI 自动化本质上只是一个定向遍历的驱动器。除了少量的核心 case 能用 UI 自动化做最基本的检测外(往往这种检测的断言还很粗犷,起不到效果),要想拓展 UI 自动化的应用范围和效果,其实还需要非常多配套设施,除了 UI 自动化框架本身,最核心的点是:一、降低 UI 自动化编写维护员成本;二、提高 UI 自动化断言准确性。在字节跳动内部也就是还在各种探索的阶段……

  • QA 能干多久,要么转岗? at 2021年09月28日

    可现在的环境里面 QA 是越来越多能化,啥都要做。心里也想着我到底在干嘛?

    多能化是一件好事,至少代表这 QA 这个原本是从研发职能中分离出来的岗位本身具备越来越多的核心价值。老生常谈,社会要求 T 字型人才,先专后广,也就是你得现有一个苟起来的方向,然后再往上下游拓展。至于这个方向是什么,要不参考你自己的技术爱好,要不就你手头现在负责的工作方向。

    随后便开始想我到底想要什么工作,如果不是 QA 那么转岗还来得及嘛?希望大家给点意见,QA 能干多久?

    我身边有 QA 转 RD、RD 转 QA、QA 转 PMO 的各种案例,很多时候转变序列不应该是你日常工作翻天覆地式的变化,它一般是从你日常工作中顺其自然切换过去的。比如 QA 转 RD,那必须是你还是 QA 角色时就承担了很多开发工作,在开发方向有一定积累,你才有可能实现 QA 转 RD,其他转职同理。
    QA 能干多久?这个看人,如果自己没信心也没动力持续学习持续进步持续沉淀,说实话,35 岁的坎不是空穴来风。否则 35 岁只会是一个数字,只要你的价值跟得上年龄的发展,比如一个同事(某大厂多年技术专家、也在某手机厂带过上百人的部门)就已经超越 35 岁,但不妨碍别人混得风生水起。

  • 看看你公司缺什么,哪个最痛。从上面的大平台里细拆小方向,先做小的东西把坑位占住,然后从小的慢慢拓展到大的不就成了么?
    关键还是你要对现状掌握得很明白,毕竟我不了解你们内部情况,就只能给你瞎枚举一下了

  • 1、留在这公司,子公司目前是没有测开的,未来可能有机会上位(领导的饼)

    领导画的饼多数时候要自己判断,按照我的经验,领导很少会说谎,但是一般会把某种东西稍微夸大一些,所以就需要有自己的判断。

    2、在 HR 业务线继续沉淀下去(继续完善 HR 体系,解决 HR 痛点,提效)

    HR 业务线我自己没接触过,但是直觉上这个方向的业务简单且不具备足够的探索空间。之所以这样说,是因为我了解到的这类内部 ERP 系统,流程和技术似乎都很成熟了,做到天花板那就是做成 toB,由于系统业务特性问题用户体量有限访问量有限信息反馈也很慢。换而言之,单纯从技术角度看的话,天花板低。我的建议是不要留在 HR 业务线,商城业务线显然是一个更有利的业务线。

    3、喊领导说换商城业务线?(前脚刚拒绝后脚又答应,这也太什么了。。。)

    无可厚非,找领导说清楚原因,给他上下文让他明白你为什么当时要这样说,做得了领导应该还是能有正确的判断……

    4、尝试一下跳槽,自己是自信但又不自信的人,面试又会怯场,学历硬伤,工作经验也才 3 年多,怕出去后找到的比原来的还差。。。

    外面的世界很大,我建议时不时出去看看。你可以把面试当成是与面试官的技术交流,又不是非得面了就一定要去,面试和工作是不冲突的,先找一些自己确定不会去的公司练练手拿拿感觉,再去更有意愿的公司试一试(不过机会一定要珍惜,因为有些公司面过了但不去是会有冷却时间的),offer 不满意就不去,说不定分分钟涨幅 40% 呢?

  • 公司内部有几百个平台,随便举一些测试开发方向的,任何一个厚度都足够以年为单位。
    移动端:apm 平台、云真机平台、monkey 工具、ui 自动化框架、录制回放平台、性能数据追踪分析平台……
    服务端:压测平台、流量回放侧事平台、测试环境、数据构造平台、接口测试智能化技术、Fuzz、自动监控与运维……

  • 顶一个

  • 投他!

  • 收到😀 ~ 简历蛮合适的,这边联系 HR 在一周内发起一面,一般一二面加起来大概花一周多时间,比较快

  • 两年后我还在不在职都是个问题 hhhhhh

  • 瞧一瞧看一看来勾搭一下呀~

  • 反复横跳不是梦呀 😁 想看看机会的话,我们配合你的时间偷偷面试~

  • 不用害羞,想了解细节随手加微信,是我本人的微信,问题只要不是红线范围都乐意解答~ 😁
    何不多了解一个机会,说不定就真的成为同事了呢~

  • 可以接受字节内部活水嘛?😅

  • 报个到