很少看到有讨论测试人员薪资的文章，当然了在一些论坛里这个话题似乎是主旋律，经久不衰。但写小作文去讨论这件事的测试人员还是不多的。今天看到一篇名为Want to Increase Your Salary as a Tester? Look for a New Job的文章，说的很实在，国内国外都适用，翻译一下，供大家参考。

我们大多数人都不介意获得加薪,尤其是考虑到通货膨胀如何影响世界大部分地区。一切似乎都在变得越来越贵,我们的购买力似乎每周都在萎缩。大多数公司每年都会进行渐进式的加薪,但这仍无法跟上现实生活中的开支。这些略微的加薪也难以反映出你全年的改进。

你想要的加薪应当与你创造的价值和职业发展成正比。但是你该如何获得与你当前技能水平相称的加薪呢?你可以尝试改进现有技能以获得 QA 经理的晋升,或者从手工测试转向自动化测试。不幸的是,有些工作环境没有职位或能力来晋升任何人。有些公司根本不会从内部晋升任何人。无论你付出多少努力,这些决定都不在你的控制范围内。

无论你是在公司工作了一两年的手工测试人员,还是拥有丰富经验的软件开发测试工程师,获得加薪的最佳方式是找到一份新工作。

作为测试人员跳槽可以获得回报

证据表明,与留在原职位获得的平均加薪相比,跳槽可以带来更高的工资增长。在一份报告中,工资和人力资源巨头 ADP 在 2021 年收集了 1800 万工人的数据,并指出换工作的人工资增长了 5.8%,而保留工作的工人只增长了 3.1%。在日本,人力资源公司 Recruit 今年也得到了同样的结论:换工作的人工资增加了 3%,而留在原地的人只增加了 1.2%。

你或者你认识的人可能都有过有意跳槽获得大幅加薪的经历。我的个人经历也印证了这一点,包括我从一家公司跳槽到另一家公司时,工资增加了 50%(后来由于内部晋升又增加了 33%)。仅仅通过跳槽到一家新公司就将薪水翻倍的故事并不罕见。

基本工资的大幅增加不是跳槽带来的唯一好处。你还应该考虑到与新角色相关的额外福利,比如灵活的工作时间、远程工作的能力和更多的假期时间。根据你所在的国家和组织,这些额外福利可以有很大差异。例如,硅谷的一家创业公司可能会在加薪的基础上提供股权。这许多因素不会直接影响你获得的金钱数额,但从长远来看可以极大地提高职业满意度。

跳槽时金钱并非唯一考量

当然,这不全是关于加薪。我们都需要金钱,但有时仅仅为了短期内的加薪而损害你的长期职业发展是不明智的。你需要看得更长远,确保你正在做出正确的决定来增加你未来多年的挣钱能力。对于职业生涯还在早期的测试人员来说,这一步尤其值得注意。

密切关注你当前角色以及未来职位中的潜在停滞是很重要的。在我职业生涯早期,我离开了一份工作,却进入了另一份工作内容几乎相同的角色。说实话,这导致了停滞和懒惰。我最初跳槽时确实多赚了一点钱,但专业发展的缺乏可能使我失去的要比如果我选择能将我带出舒适区的公司所能获得的要多得多。

当寻找新工作时,你需要探索的主要领域之一是拓展技能的能力。作为一名软件测试人员,你可能已经适应了当前角色中使用的某些工具和遵循的特定流程。找到可以让你接触新方法和新技术的不同职位将大大提高你在 QA 中的价值,并直接影响你未来测试职业生涯的挣钱能力。

在充满不确定性的时期找到测试工作

如今,似乎大多数大型和小型科技公司每周都在裁员。仅 2022 年,像谷歌、Meta 和亚马逊这样的行业巨头就解雇了数万名员工。许多这些公司也暂停了招聘,因此我们现在有更少的选择来寻找新工作。由于市场上涌入大量优秀的被裁员工,任何可用职位的竞争可能也会变得更加激烈。

仅仅发送一个充满时髦词汇的简历并期待接到电话已经不够了。你必须展示你的技能、经验和成为专业 QA 的渴望。在 LinkedIn 或 Ministry of Testing 论坛等地方扩大你的专业网络可以开启新的机会之门。写博客和上传视频是展示你知识并展现你对行业热情的绝佳方式。有许多不同的方式可以使你脱颖而出,许多有价值的公司看重这种主动性。

尽管我们目前似乎处于低迷期,但情况并非大多数主要出版物所描述的那么令人绝望。如果你仔细寻找,你仍会发现许多受人尊敬和有趣的组织在寻找像你这样高技能测试人员加入他们的团队。当然,找到这些职位现在比以前更具挑战性,你可能会收到无数拒绝或“鬼影”。我知道这对心理是一个大负担。但这并非不可能克服。低迷期是暂时的,在跳槽之前,你可以开始为更光明的未来做准备。

总结

在同一家公司工作几十年直到退休的日子早已一去不复返了。大多数现代公司都知道这一点,但暗自希望你尽管缺乏经济和非经济激励但还是继续留下来。作为一名软件测试人员,主导你的职业和财务未来取决于你自己。寻找一份新工作可能是实现这些目标的最佳策略。

离开当前角色去别处找到一份新工作通常伴随着比等待可能永远不会到来的潜在加薪更高的加薪。你还可能获得更灵活的工作环境等额外福利,这可能极大地改善你的工作与生活平衡。除了金钱之外,新角色还带来了新职责,为你未来带来更大的发展机会。

这篇文章并不是说每个读者都需要尽快找到一份新工作。你可能对当前的团队、薪水和职责感到满意。如果是这样,请珍惜你拥有的一切。但是许多人会从一个新环境中受益,无论是为了金钱还是职业发展。目前的求职市场有些紧张,但请开始把自己放在那里——你永远不知道能发现什么。走出舒适区是成为更好测试人员的绝佳方式。

最近 Facebook 的工程师们撰写了一份文档，解释了他们如何编写了一个可以自动修复 bug 的工具。在这篇论文中，他们介绍了 𝗦𝗔𝗣𝗙𝗜𝗫，这是一个自动检测和修复软件 bug 的工具。该工具对 Facebook App Family 中的六个重要安卓应用程序提供了修复建议，这些应用程序包括 Facebook、Messenger、Instagram、FBLite、Workplace 和 Workchat。

工作原理

步骤 1：检测崩溃 - 另一个名为 𝗦𝗮𝗽𝗶𝗲𝗻𝘇 的工具用于查找应用程序崩溃情况。当 Sapienz 识别出崩溃时，它会被记录到数据库中。

步骤 2：确定问题 - SAPFIX 可以准确定位导致问题的代码行。它首先检查崩溃是否可重现。如果不可重现，崩溃将被丢弃。它使用一种称为"基于频谱的错误定位"的技术来确定最可能导致崩溃的代码行。

步骤 3：提供修复建议 - 使用预定义的模板或代码变异，SAPFIX 提出了一个解决方案。在确定故障位置后，SAPFIX 尝试生成一个补丁。它采用了以下两种策略：

• 基于模板的修复 - SAPFIX 使用预定义的模板为常见 bug 提供修复建议。这些模板是根据标准开发者实践设计的。
• 基于变异的修复 - 如果基于模板的方法失败，SAPFIX 将采用基于变异的系统。它会对故障位置应用一系列代码变异，生成潜在的修复方案。

步骤 4：测试修复 - 提议的解决方案会经过测试以确保其有效性。它使用 𝗦𝗮𝗽𝗶𝗲𝗻𝘇 的测试用例来检查补丁的有效性。如果补丁通过所有测试，则被视为有效的修复方案。在补丁验证完成后，SAPFIX 使用 𝗜𝗻𝗳𝗲𝗿（一种静态分析工具）对提议的修复方案进行进一步分析。Infer 会检查补丁是否引入了任何新的潜在问题。

步骤 5：审查 - 开发人员拥有最终决定权，对修复方案进行审查和批准。

论文地址是: https://ieeexplore.ieee.org/document/8804442

最近因为面试的关系跟一些大厂的测试经理有过一些交流，我们不妨看看大厂的测试经理们都在做什么吧。

A 来自某一线互联网大厂，担任测试经理应该十多年了，有着丰富的质量管理经验。在聊的过程中我发现 A 近两年的工作重心都放在效能提升方面。因为机会难得，我就问了一些我比较关注的问题。

问：如何提升测试开发比，比如从 1 比 3 提升到 1 比 4？

答：我们之前的测试开发比其实也很高，不过现在已经降到 1 比 7 或者 1 比 8 了。这里面有一些事情是可以做的。首先质量管理方面产品的出厂质量不能降低，质量保障是一个端到端的事情，不能只靠测试同学去保障，研发人员也是质量控制中很重要的一环，所以研发人员在质量上游也要做好测试，这样后面的质量压力就会轻一点。另外我们还会定义标准的出厂测试以及 uat 测试的流程和指标，哪些东西要测以及怎么测，哪些指标要达到多少，什么环境进行什么样的测试，我们都会定义的很精细，这样才能花比较确定的力气去做一些相对确定的事情。另外需要尽可能的去自动化，或者开发相关的工具平台，给测试提效；最后还要管理好老板的预期，因为尽管有提升的空间，但整个过程还是需要花时间的。

问：自动化测试的维护成本很高，比如系统的频繁改动会导致用例的更新速度跟不上，针对这一点有什么好的办法呢？

答：接口测试没有界面相对来说维护成本还好，但是带 ui 的自动化测试维护成本确实很高，但一些项目又不能没有 ui 的自动化测试用例，对于这种情况，我们只能说用外包来尽量补，技术债总是有的，测试也有技术债，需要花成本去还。

在跟 A 的聊天过程中，我发现大厂的质量管理现在做的越来越精细化和标准化，一些质量度量指标也更加立体和实际，聊完之后非常有收获。

相对于 A 一直在一线大厂，B 的经历要丰富一些。两年多之前在某一线厂负责核心系统的整体测试，目前在二线大厂负责整体的测试工作，下属规模还是比较大的。

问：可以简单了解一下在公司的主要工作职能吗？

答：做的事情可以分为两大块。第一块是规范质量流程，定义质量度量的指标，比如怎么样才算是质量好，这里可以做的事情非常多，比如规范测试流程方面，我们定义了具体的质量保障流程以及流程中的交付物和产出物，质量的管理变得更加的高效和精益。第二块就是测试效率的提升和整体研发效能提升，里面也有很多细节。

问：可以方便了解一下在度量质量方面，我们定义了哪些指标呢？

答：主要的指标就是线上故障数。线上故障数来自几个方面。首先是用户的反馈。用户反馈分三个方面。第一个是吐槽；第二个是产品建议；第三个就是线上故障了。我们通过一些渠道收集这些用户反馈并进行记录；然后是发布时出现的故障，看回滚数就可以了；第三是我们一些钉钉群里的反馈，比如老板的反馈和内部反馈等；最后就是测试和开发在日常使用过程中发现的线上故障数和用户 app 端上报时发现的故障数。

问：所以线上故障数就是线上 bug 对吧？

答：不太一样，线上 bug 是汇总过的，比如一个线上 bug 可能会引发几百个故障，如果只记录 1 个线上问题的话，那么就没办法比较好的比较 bug 的严重程度的。所以记录故障，对故障的影响范围的评估就相对容易一些，就不会出现线上问题的影响范围变小的问题了，因此对线上的质量就有比较客观的评估了。

问：那在效能提升方面，我们做了哪些实践呢？

答：主要几个方面吧。首先定义了标准的开发过程，比如之前我们抽查过一些项目，从需求提出到上线可能要 30 多天(这里记得不是很清楚了)，后来我们通过定义好开发的标准过程，主要是消除状态扭转时的耗时，我们发现需求上线周期可能只要 7 天了。其实研发的效率并没有得到提升，开发一个需求还是需要 3-4 天，但是由于过程定义清楚了，大家的职责范围更明确了，就不能甩锅了，因此研发整体效率提升了不少；另一个实践就是专项测试。我记得当时我来的时候某个功能开发要 3 天，测试却要 21 天，这实在是吓到我了，后来我们进行了测试专项的优化，这个时间只需要 2 天了，而且发现的 bug 数还有了较大的提升，这是一个很典型的例子 。最后就是工具的研发，提升开发的 debug 效率以及测试的效率。

前几天看到一篇文章讨论从测试人员的角度去理解 AI 的，稍微翻译了一下。原文地址https://stevethedoc.wordpress.com/2023/06/18/how-should-we-view-ai-as-testers

上周三和周四，我有幸与我的两位同事 Sushmitha Sivan 和 Bhavana Akula 一起参加了伦敦的 AI 峰会。在那里，我们不仅听到了一些非常有趣的关于人工智能的演讲，还有机会为黑客马拉松的参与者们进行了大约一个小时的测试和质量工程的培训，教他们如何将这些知识应用到他们所面临的挑战中。

人工智能对我来说还是比较新的（我猜很多人也是如此），所以我们都处于学习的不同阶段，但这个学习过程非常有趣，因为它的范围和对社会的影响都是令人着迷的。

我不会告诉你如何测试人工智能，或者如何优化数据模型等等，这方面有其他地方可以去了解。这篇文章主要是关于我从参加的不同讲座中得到的一些更普遍的学习和想法，我脑海中浮现出了一些流行词和短语（以下是随机排列的）：

• 道德
• 法规
• 抵抗
• 未知的恐惧
• 失业
• 激发人类创造力
• 减轻繁琐工作
• 数据模型偏见
• 训练数据模型
• 负责任地使用人工智能
• 深度伪造

这让我思考起作为测试专业人员，我们应该如何应对人工智能。我故意使用这个词汇，因为它涵盖了测试中的每个角色。

我们大多数人在职业生涯中都测试过用户界面、后端数据库、API 等等，这些都可以生成特定的已知结果。我们有用户故事告诉我们预期的行为，以便我们可以相应地进行测试。那么对于这个新世界，我们该怎么看待呢？

我认为人工智能的目的是增强我们人类的工具，帮助我们做出决策。计算机的思维速度比我们快得多，因此它们可以帮助我们摆脱一些乏味的工作，我们可以利用我们的大脑去做更有创造力的事情。

当然，依赖人工智能可能会导致忽视固有的偏见，我们所做的决策可能基于有缺陷的数据。因此，我们需要谨慎对待我们对结果所放置的信任程度

• 我们能相信 AI 工具使用的数据集吗？
• 可能包含假数据吗？
• 它是否包含偏见或者是偏差？
• 我们是否相信输出涵盖了我们需要考虑的一切？
• 结果是否受到了可能会影响的缺失参考文献的影响？

如果机器能够替我们进行批判性思考，并且我们毫无疑问地依赖它们，我们也可能失去自己的批判性思维能力。这种情况已经发生了，一个现实世界的例子是这样的——有多少 30 岁以下的人能够从书上读地图？如果他们的手机或汽车导航系统出故障了，有多少年轻一代能够应对并使用地图作为备用计划？他们在科技依赖下长大，而我们这些年纪稍大一点的人则能够两者兼顾。

作为测试人员，我们很容易陷入打开像 ChatGPT 这样的东西，并要求它根据我们提供的信息帮助生成测试计划或测试用例的陷阱中，然后将其用作完美答案。我们必须谨慎行事。是的，我们可能会得到一些可以开始的东西，而不是一张空白纸，但如果一直这样做，我们就会失去从头开始自己启动这个过程的能力。有时候，将事物进行思维导图有助于我们自己建立联系-我们必须训练自己从 AI 给我们的任何想法中开始中途进行，这可能行得通也可能不行。我并不是说这一定是件坏事，但我们需要小心，不要失去自己思考的能力。

有一些很棒的现实场景可以利用人工智能：

• 寻找最佳的抵押贷款利率并将其整理在一张表格中
• 为一个不熟悉的情况起草一封信件
• 准备主持一场测验的研究工作
• 准备一档广播节目（我可能会这样做）

随着我们在日常生活中开始使用人工智能，我们会越来越依赖它，它不会消失，而是需要受到监管（人类有一种令人羡慕的能力，可以将任何发明变成可以用于有害目的的东西！！），并且需要人们对其使用进行质疑。

作为测试人员，我的建议是以适度的怀疑态度接受人工智能。质疑所得到的结果，并进行独立验证。你无法获得结果所基于的数据，因此要谨慎行事，做好测试人员最擅长的事情——深入探究、调查和提问。

最后，保持你的批判性思维能力——在一个人们越来越依赖所听到的话作为真相的世界中，这一点将比以往任何时候都更加重要。那些能够退后一步，采取客观的方法的人将在未来脱颖而出。

欢迎来到崭新的世界。

谨慎的在测试过程中使用人工智能

作者的观点我是大部分赞同的，最近一直在关注 AI 领域，生成式 AI 爆发性的增长以及快速的落地应用让很多人都印象深刻。我甚至听到过一种观点：凡是现在可以被外包的工作将来都可能被 ai 所取代。

但事实果真如此吗？

首先我必须说明，我是非常看好 AI 在测试领域的应用的，从三体里借用一个词语，那我可能是降临派，历史的车轮滚滚向前，螳臂当车可能是不太明智的。尽管我看好未来，不过从现在这个阶段来说，把 AI 应用到测试工作中我们还有很多问题需要解决。

• 首先值得借鉴的应用场景目前并不多。这篇推文写作的时间是 2023 年的年中，从目前的情况看将 AI 应用到测试中的案例并不多见.有一个非常有启发的例子是用 AI 自动进行网页上操作，不过离真正的测试活动还是有些差距的，预期结果和断言的缺失让这个想法目前还只是属于自动化的范畴。

看到一篇梳理微软的 QA 变迁史的文章，之前只听说过微软曾经直接干掉了所以的 qa 角色，不过也只是道听途说而已，这篇文章见微知著的以内部 qa 的视角描述了整个演进的过程，并对最终的结果进行了描述，还是非常有参考价值的。原文在这里：https://blog.pragmaticengineer.com/how-microsoft-does-qa。 下面是中文翻译。

SDET 角色

SDET（软件开发测试工程师）角色是微软在技术行业中首创的。他们是专注于编写自动化测试、构建和维护测试系统的软件工程师。SDET 与软件开发工程师（SDE）唯一的区别在于，SDET 通常不编写生产代码，而是编写测试代码，并与 SDE 在同一个团队中工作。

我无法追溯该角色的确切引入时间，但很可能是在 1990 年代。例如，这是微软 Exchange 团队的一位成员在 2004 年发表的一篇帖子，解释了在他们组织中成为 SDET 的含义：

“SDET 是一位在测试团队而非开发团队工作的开发人员。SDET 具备测试员的敏锐感，同时喜欢编写大量代码。

SDET 通过提供必要的工具和流程，使测试人员能够充分发挥他们的优势…在产品上市之前，尽可能多地测试产品并发现尽可能多的错误。

SDET 具备分析产品功能和架构的能力，从而设计和实现有助于测试的工具。

SDET 喜欢短期项目生命周期，在一年内设计和实现许多工具和测试框架，使用最新技术，并有充分的创新空间。

尽管产品质量是首要关注的问题，但 SDET 在产品生命周期末期不会像开发人员那样感到压力。通俗地说… SDET 很少会面临风险:)”

微软为 SDET 角色设定了正式的职业发展路径。同一篇帖子中写道：

“[SDET 职位]有很大的发展空间。如果你喜欢作为 SDET 所做的工作，你可以发展成为测试架构师。如果你想参与管理工作，那么你可以逐步晋升为 SDET 主管，然后成为测试经理。

如果你只想编码而不参与测试工作，你可以选择成为开发人员的道路。许多人选择了这条道路。如果你意识到你的心属于测试，那么你可以成为一名测试员。”

直到 2014 年左右，SDE 和 SDET 之间的比例在微软内部普遍为 2:1。在 2012 年我所在的 Skype for Xbox One 团队也是如此。以下是我们团队的人员构成，根据员工人数计算：

12 名 SDE（软件开发工程师） 6 名 SDET（软件开发测试工程师） 2 名 PM（产品经理） 1 名 EM（工程经理） 1 名 SDET 主管

关于 ai 与测试的讨论现在逐渐流行起来，目前看来观点基本是积极和激进的，大多数人认为 ai 会重新塑造测试行业，不过基于 ai 的测试探索目前看来还是有限的，我稍微总结了一下，大概分为两类。

• 利用大语言模型的推理能力进行驱动的自动化工具；这个之前的文章已经介绍过一些了，有兴趣的同学可以翻一下之前的存档；
• 对融合了 ai 功能的软件产品进行测试。推荐大家研究一下这篇文章，里面的一些标准步骤还是让人备受启发的。https://blog.scottlogic.com/2023/11/14/testing-LLM-based-applications-strategy-and-challenges.html。这些测试大多是对prompt的安全，边界条件以及输出的稳定性进行测试。

就这个时间节点看来，ai 在测试领域上的应用其实不算太多。另外目前对于大模型本身的测试工作也基本是众测模式，模型提供商经过基本的 fine tuning 和测试之后发布模型或者提供 api 接口，通过使用者的反馈来持续的改进模型，基本上走的是强化学习的路子，对模型的测试不依赖于测试行为，而依赖于更多样性的标记数据，所以哪家大模型能跑出来其实就是看哪家的显卡多和数据多。

最近看到一篇非常积极拥抱 ai 的测试文章，里面的观点基本没有数据佐证，先不去讨论正确与否，不过文章确实传递出了一种很强烈的乐观信号，因为这篇文章认为 ai 会带来更多的测试岗位和更高的报酬。下面是对这篇文章的翻译，https://jarbon.medium.com/ai-more-testers-more-money-045e1a34741d。先提前说明，对这种观点我持谨慎的乐观态度，尽管我一直认为从事ai其实跟我们当年做黑盒测试差不多，不过下文的描述在短期看来还是比较难达成的，未来是什么样确实比较难以预测，所以不如积极投身其中去创造未来吧。

下面是原文的翻译：

AI 裂变正在迅速到来。AI 将在软件测试领域创造新的有和无。将 AI 引入软件测试将改变测试人员、供应商和工具的工作方式。但是，这种变化不会如大多数人所担心或梦想的那样。声称 AI 很快就会简单地取代人工测试人员的工作是错误的。希望 AI 无法足够聪明地完成大部分测试工作也是错误的。将会有更多的测试工作，并且它们很快将得到更高的报酬。在这个过渡中，有些人会失去工作，但这取决于他们自己。只有思想开放、乐观的测试人员才能在这个过渡中生存下来，并且他们将得到丰厚的工作保障和报酬。

AI 对测试工作的影响

在短期内，AI 不会减少测试工作的数量 - 对测试人员的需求将会增加。许多测试人员担心 AI 会消灭他们的工作 - 这对大多数人来说是不真实的。应用 AI 于工作的“AI 辅助”测试人员将更加高效。那些能够迅速做到这一点的人将获得最多的工作保障、进步和回报。

在 10 亿美元以上的测试领域中，最大的问题可能是如何衡量价值。工程团队知道他们需要测试，但很难量化，而事实是，大多数测试工作在今天没有 AI 的情况下几乎没有什么用处。当测试人员得到 AI 的辅助时，测试人员的速度、范围和价值将增长到明显的价值点。目前，大多数软件测试仅仅涵盖基本功能和一些边缘情况，成本高昂，并拖慢了工程团队的进展。

然而，AI 辅助测试将赋予这些人类测试人员“超能力”，他们的贡献将是压倒性的明显。正如测试领域的一位朋友上周所描述的那样 - 不久之后，测试人员将穿戴 AI-“钢铁侠”装备。企业将希望增加更多的 AI 测试人员，因为他们终于看到了明显的积极回报。这些 AI 辅助测试人员将足够快，以便在当前的开发周期内发挥作用，给人足够的信心进行发布，发现对业务有影响的问题，并揭示仍待测试的内容。对于 AI 辅助测试人员的需求将增加，因为他们将为企业增加明显的价值 - 就像开发人员增加功能和修复错误一样。

AI 还意味着开发人员正在创建更多的软件。AI 辅助工程师的加速是非常真实的，而且 AI 也意味着更多的人可以创建软件。所有这些新软件都需要由更多经过 AI 增强的测试人员进行测试。