软件测试主要是做什么事的?
软件测试主要是做什么事的? 原文专栏地址：陈甫鸼：杂谈：软件测试在做什么?最近一直被邀请回答各种和软件测试有关的问题。之前我一直觉得不好回答，因为我已经做了技术管理很多年。最近我开始做个人的游戏开发项目，也有了些时间回顾之前的一些文字，想了想，不如干脆整合在这里，作为一个系统的梳理。
软件测试工作的想象与真实
如果我们问开发每天在做什么，很多人可能会条件反射地给出答案：「在写代码啊」。行内的朋友们可能会给出一个有些黑色幽默但恰如其分的回答，「在开会啊」。类似地，当问起测试每天在干什么，大多数人可能会认可的答案很可能会是：「在抓 bug 啊」。如果刨去无穷无尽的对齐会（互联网大厂的朋友们可能开始扶额），和每个敏捷发布周期将近时巨细靡遗的报表输出（数字化转型项目的同行们应有苦笑），这么说好像也没什么错。
但这两个回答有一个微妙的不同。开发的代码都是自己的产出，测试要抓的 bug 却不是测试引入的。那么，是不是意味着测试其实是一个极富艺术家气质的工作，每天就是想出各种创意，用旁人想都想不到的组合来崩坏系统呢？想想都让人羡慕呢。
说到这里，我估计所有头衔上有测试的同行们，都会想抄起键盘到我门口排队准备砸我了吧。
作为同样测试出身的我来说，我也不可能同意这样的想象。事实上恰恰相反，无论是我曾经的同事或下属，还是我知乎上认识的朋友，交流最多的一个话题就是：「测试的职业发展究竟是怎样的」。实际工作里，我从未见过多少测试同学们能带着一种「艺术气质」在工作；相反地，很多测试从业的朋友都在抱怨自己机械劳动、压力巨大等等。那么，为什么会有这样的认知差异？
从 Bug 看软件测试的工作范围
说到软件开发的 bug 时，大多数人可能会条件反射地认为是开发角色写错了代码导致的。这种印象虽然很符合直觉，但却不符合事实。在软件开发过程中，bug 的引入至少有三个来源：设计、实现、外部依赖，产品经理、开发、甚至架构，都可能引入 bug。这么说可能会有些空洞，我们不妨以我自己正在开发的平台跳跃类游戏项目其其格大冒险（Tsetseg's Adventure on Steam）作为例子。
场景一：需求修改引入的 bug
在三月份开发第二关时，我曾考虑过想把游戏中的跳跃高度增加一倍，从两个身位增加到四个。理由是在我女儿试玩时，我注意到孩子在一些窄平台上连续跳跃时出错概率特别高，而一个较高的跳跃高度能给她更多的反应时间。本身这个修改就是改个初始跳跃速度的配置而已，连代码都不用改。所以我简单地提交了代码。
然而打脸的现实紧随其后。第二天我发现女儿已经开开心心地把我精心设置的一堆隐藏区域的金币全吃光了。理由也很简单，改了跳跃高度后，从起跳到落地的时间变长，连带着前跳的距离也从原来的两个身位拉长到接近四个身位。我本来设置了一批漂浮在远处的平台，连通着隐藏区域的。这本来是为了后续获得滑翔技能后再玩二周目才能到达，现在只需要普通的跳跃也能到达。
此时我进退两难。我可以选择把隐藏空间入口的平台距离拉得更远，保证增强的跳跃也无法到达，直到女儿拿到滑翔技能为止。但要修改的不只是作为入口的平台，也包括隐藏空间里多处同样需要滑翔到达的区域——原本的设计里，我假设玩家到达入口的前提是得到滑翔能力，因此进入入口后，多处区域也是按照具备滑翔能力的标准设置的。现在这些位置都需要相应修改，这完全打乱了原本的关卡设计。虽说个人项目没有时间压力，慢慢改也行；但不巧的是，四月我已经预约了一些工作。所以最后的选择是：我取消了增强的跳跃距离，只在现有关卡中女儿觉得困难的几处做了微调，降低跳跃难度。
这个 bug 是很典型的，因为需求变更导致前后不一致产生的问题。作为设计角色的我，在对「跳跃高度」这个基本功能进行修改的时候，没有充分考虑它的连带效应——修改高度同时滞空距离增加，进而导致原本的关卡设计桥段无效化；一开始以为微不足道的小修改，却导致最终的修改范围远超最初的估计。这类 bug，如果非要硬着头皮改掉，其实也是可以的；其风险在于难以估算后续工作量，导致时间和资源不可控。
读到这里，产品背景的朋友是不是觉得很熟悉？场景二：实现逻辑时错误逻辑引入的 bug
今年四月初我在 Steam 上发布第一个 demo 版本前几天曾发现过一个 bug，为了赶上预订的发布时间加了一天班。这个 bug 会在很低的频率下，让游戏中的敌人刚被踩死就立即原地复活，而不是按设计，被踩死后等待一段时间后复活。玩家遇到敌人突然复活时来不及避开，100% 会被反杀。研究后发现，根源是因为代码中存在两个独立工作却同时修改内部状态的逻辑没有正确协作，一个是响应玩家踩踏操作的逻辑，一个是敌兵检测玩家方向的逻辑。这导致踩踏操作将敌兵状态刚刚设置为「击倒」，却立即在方向检测逻辑中将其设置为「转向」，导致代码将敌兵立即激活，而不是等待击倒时设置的等待时间。
熟悉多线程开发的程序员应该能立即反应过来，这个 bug 是临界区保护逻辑没有做好导致的多线程同步问题。而对这篇文章的读者们而言，临界区、多线程这些技术细节并不重要，重要的是：这是一种典型的，开发过程中由于开发人员考虑不周而引入的 bug。这类 bug 的特征是，只要能考虑清楚根源，一般都有被正确修复的方法，且修复可能带来的连带影响也较低，不容易出现类似场景一中无法控制范围的连带问题。实际项目管理中，这种 bug 也都会倾向于优先修复。
场景三：第三方依赖存在 bug
五一假期我修复了一个神奇的卡关 bug。当玩家被击倒时，游戏会停留在当前关而不会重新开始。说它神奇，是因为想稳定触发这个 bug，需要三个看似和游戏流程完全无关的条件：1. 必须使用一部蓝牙耳机，2. 蓝牙耳机必须同时连接我的 Linux 测试机和一部手机，3. 蓝牙必须首先连接手机，然后再连接我的测试机。为什么一个平台跳跃游戏需要蓝牙耳机？
经过调查，我初步确定了问题的直接原因：我的游戏中，角色被击败时会播放一小段音效。为了保证效果，我的代码逻辑监听了音效播放，只有在音效播放完毕后才会调用重新开始当前关卡的逻辑。但当测试机和一部手机同时连接蓝牙耳机时，Linux 声音子系统不能正常播放来自游戏引擎的音效；相应地，游戏引擎中用来监听音效播放完毕信号的代码逻辑不会被触发，游戏当然不会重新开始。
进一步检查发现，这实际上是操作系统的声音子系统的问题。测试中我就注意到，受影响的不只是我的游戏，甚至同一台机器上浏览器的视频播放都陷入卡顿。值得庆幸的是，绕过这个问题还是容易的：既然声音无法被正常播放，那么重新开始关卡的代码逻辑就应当避免依赖声音播放完毕，而应该使用一个延迟计时器。计时器需要等待的时间长度，就是音效素材的播放时间。
和前两类 bug 不同，这个 bug 我只能选择绕开，不能真正修复。我并不是蓝牙设备或者操作系统音频播放功能的专家，无法直接进入操作系统代码或者联系耳机供应商来解决问题。即使我有这个技术能力修复，我也没有能力要求操作系统或者耳机供应商作出保证，在我的游戏七月份上线之前将修复推送到所有的玩家系统上。
有朋友也许会数落我，「谁让你非要让游戏在 Linux 上跑的，这不是你做为产品该背锅的么？」这话没有错，对于一个游戏项目，也许确实没有支持 Linux 平台的理由。但不支持 Linux 仍是绕开问题，不改变问题的性质。如果这个 bug 是和特定耳机有关呢？这个论断谁也没法证实或者证伪，毕竟我自己没钱买下市场上全部的耳机设备来做测试。甚至某些实际场景中，这样的 bug 不一定能找到绕开的方法，只能以「我们不支持这种操作」为由禁止用户使用。
从研发分工模式看软件测试的挑战
在我工作的很多项目中，测试负责人被产品甚至业务方施加的压力常常是团队中最大的。一个经常抛给测试负责人的责难：「我花了这么多钱，养了这么多人，这么多 bug 测不出来，我养你有什么用？」甚至这样的责难会直接来自团队内部。然而这种说法仅仅是情绪的发泄，并不能帮助解决问题。而作为软件研发团队负责人，则应该有更清醒的思路。
前面举的例子表明，产品和开发阶段都可能引入软件 bug，即使外部依赖问题，本质上也是在技术选型阶段引入的。至于测试，则是唯一工作性质不引入 bug 的角色，某种角度上，测试这个角色多少带了一点背锅属性。但这也不能全怪产品和开发，而是和分工模式有关。
很多如今的软件项目中，设计、开发、测试被设置为独立的阶段，彼此少有交集。这种分工方式保证了测试团队的中立性，但也使得问题发生时，测试角色很难独立分析清楚问题的来源，这本身就给问题的产生和定位增加了一重沟通的压力。在并不罕见的场景中，许多稍有规模的软件开发项目，往往为了提升产出效率将三个阶段重叠，比如测试当前版本时，产品和开发已经着手开发下一个版本的功能。这使得问题被检查出来时，产品和开发还需要从当前任务中脱离出来，回忆上一个版本做了什么。理解问题的时机越晚，修复成本就越高。
这就是测试工作的第一个挑战：测试团队被要求在自身不熟悉技术细节的前提下给引入 bug 的人提供足够的信息。项目初期功能少，这种开销往往不明显；但随着项目深入，实现的功能越多，大家都处在并行工作时，沟通的成本就会飞速提高。
与此同时，测试的第二个挑战也随之浮现。因为谁也无法保证自己能记住之前的影响，为了保证当前的修改不会导致上一个版本已经交付的功能损坏，测试自然的倾向就是保证全覆盖，也就是测试经常会说的回归测试，regression test。回归测试的核心挑战，在于保证覆盖率，而不是很多朋友以为的所谓「创意」。每一个功能和对应的组合可能产生的交叉效应，都必须反映在测试计划里，并且在每一个交付周期内执行到位。这里和开发角色的工作模式存在一个巨大的区别：对开发而言，一旦开发工作完成，只要不动代码，大部分情况下可以安全地忽略上一个交付周期里开发的功能，只关心本次交付的代码；如果代码质量实在有限，开发甚至可以拷贝一份代码重起炉灶。但测试则从来没有这种路径可走，恰恰相反，每一次交付，测试都必须关注前面已经交付的功能，确保其在新版本中仍然工作正常，或者将改变登记在案，确认这些改变确实符合产品的需求。
因此，测试的工作特征从来都不是「艺术家式的创意」，而是步步为营地构造测试覆盖体系。测试覆盖体系总是以目前已经开发的所有功能为整体，保证应该覆盖的环节不缺失为目标。测试的工作性质，很少有只关注当前功能这样的奢侈。这个过程中大部分的工作，实际上是非常辛苦的重复性劳动。
观点：敏捷开发流程不能帮助软件测试
我有一个自己的观点，即时下流行的敏捷软件开发理论，虽然有效地帮助了开发和产品经理控制节奏，但对质量验证环节却没有什么帮助。敏捷开发实践讲究的是定期迭代和发布，留给每一个开发周期的时间是大体固定的。时间固定的前提有效限制了来自利益相关方（或者直白点：业务方）不断增加功能的冲动，产品经理可以只关注本次迭代排入的功能清单，开发可以根据产品经理的功能清单，只关注本次迭代中需要的实现的功能，单个排期内的工作量可以做到大体恒定。很多时候敏捷布道者会说：定期迭代保护了团队，就是这个道理。
然而，这种保护对测试工作非常有限。质量检查阶段的回归测试工作量，在每一个迭代中实际上是「本次迭代产出+前面所有迭代产出」的总和。它带来的工作量由已经实现的功能总数确定，而单次迭代承诺的功能数，随着项目进行，占比只会越来越低。这种差异使得测试的单次迭代工作量随着进度越发接近最终发布而越来越大。这和产品+开发的工作模式存在显著不同。
当然有朋友一定会争辩，有经验的产品经理可以在设计时就能注意到哪些变动未经仔细思考；有经验的开发也可以注意到自己的改动可能对同事的其他功能模块造成影响。然而这些「提前发现」严重依赖于个人能力，无法通过敏捷开发流程中提供的各种诸如 planning meeting 等机制来提供保护。一旦团队经验不足，这些早期的问题就可能被静悄悄地传递到迭代末期，全部变成测试阶段的压力。
最糟糕的是，现实的软件开发任务中，测试角色的工作时间偏偏是最容易被压缩的。因为作为工序的测试阶段通常排列在迭代周期的末尾。在此之前的许多问题都可能导致额外的开销，诸如业务要求变更需求、开发遇到难以解决的技术问题导致延迟，等等。而考虑到很多商业因素，软件的发布时间往往又很难有商量的余地，因此，测试承受的压力往往也是最大的。
从资源分配看软件测试工作的实质
上述说的情况并不新鲜。实际上行业多年来有诸多的探索。比如微软多年前一度倡导的 SDET 角色（Software Developer in Test），即近年来国内在喊的「测试开发」角色。这个角色的职责是将测试任务尽量自动化，来降低回归测试的开销。我自己以 SDET 角色入行，但后来看其他公司的项目多了，我开始意识到，SDET 方式实际上只在资源充足的前提下才有实际意义：当我们从测试团队去开发测试自动化时，测试执行的任务并没有减少，事实上，实际的工作量因为包含了开发任务是增加的。当年微软对这个问题的解决方法是全职的 SDET 带队，带一组外包的 STE（Software Test Engineer，也就是手工测试执行），整个团队需要的人数更多。而且 SDET 需要技术和管理能力，这种角色并不好找。微软在 2010 年后，就逐步让这种 SDET + STE 的组织模式从开发序列中消失，也侧面佐证了这个模式难以为继。
当然可能有同行们会试图争辩，说这是因为当时微软正处增长乏力的阶段，没有足够的钱维持大的团队。这种说法有道理，但无法解释为什么 2023 年的微软也没有重新引入 SDET 角色。在我看来，上述方案无法持续的根源，不在于公司是不是有钱，或者能不能招募到合适的 SDET。它的核心缺陷在于资源错配：即在软件开发工作中，有一组工作量，它们无法通过迭代周期隔离；然而这些工作被要求限制在一组固定的人力资源上，并且要求这批固定人力资源自行消化。平心而论，这组工作量确实有优化的余地，比如提升测试用例自动化。但这种优化并不改变工作量积累的趋势，而是以充足的资源为代价回避了矛盾。一旦资源不足，就很快被打回原型。
项目管理者如何管理软件测试
首先，整个团队必须有共识，即承认累积性质的回归测试是软件开发过程中必须完成的一部分，而非测试团队「虚报的工作」。我相信前面的例子已经足够具体地说明了这个问题。当我们承认回归测试具备上述特点，那么站在项目负责人的角度来说，解决问题的方向就很清楚：既然 bug 的引入方是产品和开发，而检查 bug 的工作量随着功能总数不断积累，那么最合理的手段应该是用整个团队的资源均摊。这才能让整个团队共同承担交付目标的压力，而不是「质量是你测试的责任，和我有什么关系」。只有当团队开始意识到这一点并且愿意共同承担任务，这个问题才具备解决的基础。
接下来，假定我们的团队已经接受了上述共识，我们应该怎么做才能落地？我的建议是两步走：第一，团队不同角色可能引入的问题，应要求对应的团队角色去验证，确保潜在问题能被最懂的人第一时间发现，从而分流回归测试的压力；第二，在回归测试被均摊的前提下，保留专门的全员参与时间进行大规模随机测试。
这样说可能过于抽象，仍以我的游戏项目为例。我将每个迭代分为三个部分：
[*]设计阶段。即设计新关卡时，所有对现有角色或技能进行修改的想法，都需要被标出，并查看之前关卡中对应的桥段是否还能正常工作。比如前面的例子，当我考虑在游戏中修改跳跃距离时，即使我作为关卡设计者不能意识到它可能过早暴露的隐藏关可能会打乱后续的许多流程，我自己应该在动手开发前就知道之前哪些关卡可能会被这个变化影响而需要先试试效果。我可以简单地通过直接修改跳跃高度产生一个新的临时版本，在这个新的版本上到前面的关卡对应处做调研，进而决定应该是放弃修改跳跃本身，还是修改隐藏关卡的进入方式。
[*]开发阶段。即实现本关卡的功能时，比如角色增加新技能后和原本敌兵的互动逻辑，应该有单元测试覆盖代码 bug。对此业内早有单元测试的实践。有些游戏引擎如 UE 和 Unity，因为采用成熟的程序设计语言，可以方便地编写单元测试；但部分引擎如 Godot，则因为脚本和开发工具绑定紧密，不借助外部插件不能直接引入单元测试。但即使不用插件，方法总是有的，比如我自己最初在不知道 Godot 有单元测试插件时，会长期保持一个不存在于正常流程的关卡用于测试。我把测试代码都放进了这个关卡中的启动初始化步骤里，保证每次这一关启动时都能执行；同时这一关中也包含了所有的玩家技能和敌兵。每次代码变动时，我会先在这个测试关卡先玩一遍，确保动作、声音、判定都没有问题，才会提交代码，认为开发阶段完毕。随着时间持续，整个测试关卡本身就成为自动化回归测试的一部分。
[*]验证阶段。在前面两个步骤都覆盖了对应的验证之后，这个阶段应该假设显而易见的 bug 不会随便出现。其目标就能被设置为：只关注前两个阶段尚未覆盖到的内容。就游戏项目而言，这个阶段最主要的落地手段就是不受限制地用各种随机手段去玩。前面我提到的蓝牙耳机触发的卡关问题，就是在我在玩新买的耳机时偶然发现的。某些需要微调的设计，也能在这个阶段发现。
我举的例子都来自我的个人开发项目。就规模而言，当然无法和企业中的很多软件开发项目相比，但问题的性质是相似的：随着做出来的功能越来越多，越到项目后期需要重新验证确保前后一致的部分就越多，花在测试和验证上所需的时间一定会越来越长。企业中的许多软件开发项目规模更大，而且常有发布时间的要求，资源的压力和我相比，只大不小。
遗憾的是，我见过的一些项目中，产品经理拍脑袋修改之前的设计是常态，开发不写单元测试是常态；但修改后会对别的功能是否造成影响，「我也不清楚啊」；没有单元测试的代码，改了之后是否对别的模块有影响，「我只测了自己这一块儿，没问题啊」。当我们把所有的「不清楚」都堆积在项目发布前一周的回归测试，等测试团队抓出来一堆问题，「哎呀这么久谁还记得住那么多细节啊」。最后压力到了极限压垮了团队，变成了内部的互相指责：「你们测试为什么不早点测出来？！」
当然，如果某团队秉承的信条是：「项目崩了不要紧，只要证明我没责任，我就是安全的」。那其实不如选择尽快换一个团队，落个清静。
题外话：软件测试的职业特点如何影响岗位选择
知乎上 @IT技术之美 邀请我回答这个问题：「为什么大厂不招功能测试全是测试开发或者测试专家岗？ 」。我没有办法直接回答，是因为这个问题试图描述的现象和我的观察正好相反。老实说，在我供职过或者打过交道的企业中，我没有看到这个趋势。恰恰相反，测试团队的主要战斗力仍然来自功能测试团队。当然，我的工作领域包括数字化转型和工业互联网，并没有在所谓互联网大厂中工作过，也许以偏概全。但有一点我可以证明，那就是很多常年的测试开发岗位和测试专家岗位一直是处在招不到的状态。在我的观察中，基本上是因为三个原因：
[*]满足测试开发技能要求的人难找。和前后端开发岗位不同，测试开发岗位不存在类似前几年铺天盖地的培训机构加持。测试开发需要的很多技术工具开发用不到，即使是不系统的教学体系，也不容易找到。
[*]过去十年形成的传统观念，使得很多行内人已经形成了一些思维定势，觉得开发和测试是不同的职业。我甚至在知乎上看到一些问答中会用「我们测试行业」这样的表述自称。这使得很多科班出身的开发者并不愿意去顶着测试的头衔，觉得自己掉价。
[*]测试的绩效比开发更难衡量。在很多我看到的团队实践中，开发的绩效往往被定义为准时交付了多少功能。功能数目这种 KPI 相对容易衡量，因为这个指标和利益相关方的 KPI 高度一致，所以很容易得到认可；但测试的工作性质不直接产生功能，而更偏向技术+管理的混合角色，导致很多团队中非技术角色对测试意义认知不清，绩效考核指标难以取得一致。
需要注意的是，上面三个理由实际上基于一个隐含的前提，那就是团队设置中，开发和测试被认为是两个不同的角色。实际上，过去十年中，一些软件开发的细分领域已经不再认可这样的分类，特别是一些不涉及用户交互的产品，会更倾向于提升自动化测试覆盖率，作为开发提交代码前必须完成的一部分工作。我见过的这种场景，广泛存在于各种云上 API 服务、编译器、操作系统、量化交易、算法研发领域等。我曾经见过这些领域的团队，无一例外地，都不设置单独的测试角色。
与此同时，区别开发和测试的开发领域仍然数量众多。我自己的观察，凡是存在频繁用户交互的领域，很多还是需要单独的功能测试角色。那么，这类行业未来会大量寻求测试开发（SDET）么？
我认为需要大量交互的软件开发领域仍倾向于长期保留测试角色，但原因可能和同行的解释不同。我的理论是：这类行业中存在一个和我前面提到的细分领域存在一个区别，即引入 bug 的角色（产品、业务）常常缺乏自行验证 bug 的能力，又因为 KPI 的要求，存在打破研发流程纪律引入新 bug 的天然倾向。我这么说并不是贬低产品和业务。他们的压力实际上来自公司的商业目标，我们作为技术团队应该尊重这样的现实，并且给予支持。但为了保证这种冲动不会对交付软件的质量造成破坏，作为团队整体需要额外的角色补充产品和业务在技术上的短板。反映在团队上，最适合承接这个职责的，仍然是测试角色。
至于这类领域是不是更倾向于招聘测试开发或者测试专家，我自问经历有限，如果妄下结论，实在不妥。但如果团队负责人增加测试开发的目的是提升测试自动化以降低测试开销，那么我可能需要提前给一个警告：也许您走的路，并不能通向您期望的结果。
总结
很多年前，有关于质量管理/Quality Management 和测试/Test 两个概念的区别和联系，就是个热门话题。也听到过各种观点，比如我听过有朋友坚决宣称「开发就不能碰测试，因为两种人思维方式不一样」，也有人要求「测试应该全给开发做，因为只有开发最懂代码」。考虑到说这些话的人的背景各不相同，我不能简单地断言这些说法正确或者错误。但在我看来，所谓思维方式或者技能差异，都还浮于问题的表面。问题的实质在于如何理解项目中测试工作的特征，并根据它们的特点决定应该如何分配工作量。
质量管理工作的特点，决定了所有测试工作从一开始就必须以软件最终阶段的整体为单位进行考虑，而时下流行的敏捷开发模型中的分拆需求+固定发布方法，不能有效地隔离其复杂性。这是测试团队或者测试角色的难处所在，也是整个开发团队应该共同面对的问题。说到底，软件开发过程中，几乎所有的 bug 都不可能是测试团队引入的。
问题解决的关键在于，如何将质量管理分拆到不同的角色身上。产品、开发、测试，都需要对自己的工作承担验证的责任。最终在测试角色处归总，形成整个质量管理的体系。换言之，「质量管理」，应被视为是整个开发团队（产品+开发+测试+其他角色如运维）的共同任务。 笼统来说，你可以理解为软件测试就是找bug的，但是实际上测试又没那么简单。
下边我来给你说下，测试工程师每天都在做什么，希望能帮助你更准确的理解这个岗位。
软件测试工程师主要的工作分为4大部分：
业务测试、专项测试、效能提升和质量监控
第一，业务测试
有的同学可能还不清楚什么是业务，业务说白了，就是你们公司或项目组为了达成商业目标而所做的事。
业务是由销售、运营、产品、设计、开发和测试共同完成的。
比方说你们的项目组主要负责搜索功能，那么，你在里面的角色就是这个搜索功能的迭代测试。
那么，如何进行业务测试呢？
首先，需要参加需求评审和技术评审，熟悉和明确产品需求。
其次，针对需求文档和技术文档进行测试用例的编写，编写完测试用例之后，还需要进行测试用例评审。
接下来，研发工程师会进行产品的开发，等开发完毕并开发自测通过后，会把代码提测到你这边。
此时，你要做的就是把代码部署到测试环境中，并开始进行冒烟测试。
冒烟测试就是把产品功能的主流程走一遍，看是不是能满足提测标准。
假如没有满足提测标准，有权把提测打回，让开发自测充分后再提交测试。
假如已经满足提测标准，就可以开始按照你编写的测试用例，逐项进行测试。
这个阶段就是测试的重头戏，主旋律一般就是发现bug，提交bug，开发解决bug之后，测试再验证bug是否修复。
测试完毕之后，需要让产品进行产品验收和体验。
验收通过后，方可进行上线。
上线完毕之后，还需要在生产环境下，进行回归测试，等回归测试没问题之后，才宣告功能正式交付。
接下来，又是进行下一个功能迭代的测试。
第二、专项测试
专项测试，顾名思义，主要是诸如：数据测试、性能测试、自动化测试等特殊的测试。
主要是对业务测试的一个补充。
没有绝对完美无缺的系统，单靠业务测试，是无法保证产品或代码质量得到更多提升的。
比方说，自动化测试可以模拟重复1000次点击操作，但是这个要是让手工去做，不得把测试工程师逼疯喽。
专项测试可以发现一些手工业务测试发现不到的bug。
但是专项测试不可能完全替代业务测试。
业务测试具有主观能动性，可以站在用户的角度去体验一个功能的好坏以及产品是否美观。
但是专项测试并不能做到这点。
第三、效能提升
现在的互联网公司，产品迭代周期很短，一个功能可能1-2天之内就得上线。
假如说企业不追求效率的提升的话，就无法快速占据市场。
我们测试工作也一样，更应该注重效能提升。
效能提升主要可以从CI/CD、Bug管理、测试环境维护、流程管理与优化去考虑。
有能力的测试团队，可以考虑开发出适合自己团队的测试平台，集结所有优秀的测试工具，方便测试工程师提升测试效率。
近几年，DevOps也是火了一阵，DevOps就是开发运维一体化，可以把整个产品的生产过程，形成一套流水线的规范，这样也可以很大程度上提升产品的交付效率。
第四、质量监控
不论如何，质量都是测试的脸面，为了保证质量，我们不能只局限于在测试阶段去发现bug，我们应该也要对产品交付之后的进行质量监控。
比方说：
移动端app，正式发版之前，都会有灰度测试阶段，在这个阶段，已经有部分用户可以率先体验到我们的新功能，我们需要进行app的crash监控。
所谓crash就是app的崩溃，crash会对用户体验造成相当大影响，
监控crash可以有效的把crash扼杀在正式发版之前。
其他的监控还有服务器状态监控、用户反馈监控、埋点数据监控等等。
下图是我对测试工程师所做的事项进行了一个大概的总结。
http://pic1.zhimg.com/v2-b0f63ff688e7c74da7fdf327a2d65229_r.jpg?source=1940ef5c
以上，希望能帮到你。
<hr/>我是专注分享测试干货的臻叔，喜欢的可以关注哦~
其他精华文章——
软件测试高薪的真相：
转行软件测试，报培训班3个月出来就是高薪工作，靠谱吗？臻叔自己转行到测试开发的经验总结（精华）
考研失利后，我是如何零基础转行测试开发 ，成功拿下独角兽公司offer？软件测试必看书单：
软件测试最全书单：学测试必须要知道这6本书！（附48本测试经典书单）❤既然都看到这里啦，请你帮个忙：
1、点赞，让更多小伙伴看到；
2、关注我，持续更新测试干货。
关注我，免费咨询测试问题→→
最后，感谢您的阅读。
你的盛赞就是对创作者最大的支持！ 就是一个找bug的。说那么大段，简单点不好吗？
什么是bug？比如微信，有的时候微信频频闪退，或者逛PDD，商品价格是1元，实际确扣了你99，本身是99最后扣了1块钱，再或者你玩一款游戏，这个游戏上线之后再下线，装备丢了，你可以看到，这就是bug。软件测试是要避免这些bug出现，对用户造成损害，对用户造成影响，这是软件测试要做的事情。
工作流程有：
一、测试需求分析阶段；
二、测试计划阶段；
三、测试设计阶段；
四、测试执行阶段：1、搭建环境；2、对每个case记录测试的结果；3、测试日报；
五、测试评估阶段：和研发人员的撕逼过程。
检查程序的业务逻辑和代码逻辑。每个人对一件事的理解不同，同理不同人员对需求的理解可能会存在差异，所以适当的时候要检查下代码是否有业务逻辑错误和代码逻辑错误，当然达不到检测程序的，可以通过手工测试来做。
提高产品的易用性。若是一个软件产品不好用，用户的学习成本太高，那么产品的接受满意度就会下降，更别提产品的市场占有率了。 &#34;测试行业&#34;是从属于&#34;IT行业&#34;的，而随着信息产业的迅猛发展，到目前为止IT行业已经赶超金融业，排名行业第一，成为中国最大的产业，并且还以每年20%的速度递增，而&#34;测试行业&#34;作为IT公司内部必不可少的重要组成部分，它是推动软件质量提升的关键环节，就好比：施工监理、药监、保监、反贪司法、质检等等部门，虽然做的是不同的事儿，但有异曲同工之目的，软件测试是保障软件质量的重要手段，甚至它被誉为是软件质量把关的最后的一道生命防线。
试问：一辆没有经过测试的汽车，大家敢买敢坐吗？
试问：一枚没有经过测试的导弹，敢运用于实战吗？
试问：一款没有经过测试的软件，没有客户敢收的？
今天和大家来聊一聊测试工程师日常的工作是做什么的。
http://picx.zhimg.com/v2-c1d8b1a4f172fc86df7212e0859f5b92_r.jpg?source=1940ef5c
首先，一个互联网产品或者说一个新功能上线，需要经过需求评审，功能开发，测试，上线发布这四个流程。
测试就可以理解为，产品生产的最后一道关卡。负责产品的质量，我们需要尽可能的去发现开发的缺陷 ，及时发现及时解决，保证产品交付给用户是合格的产品。
如果你喜欢这个内容，记得点赞。系统还会检测你的点赞行为，给你推荐更优质的回答。
如果不忙的话，可以双击一下屏幕。有一样的效果~那么测试工程师，每天都在做什么呢？
主要的工作分为四大部分：
业务测试
专项测试
效能提升和质量监控。
第一、业务测试
有的同学可能还不是很清楚，什么是业务。业务说白了，就是你们公司或者项目组为了达成商业目标而 所做的事，业务是由销售，运营，产品，设计，开发和测试共同完成的。比方说你们的项目组主要负责 搜索功能。那么你在里面的角色，就是这个搜索功能的迭代测试，那么如何进行业务测试呢？首先：需要参加需求评审和技术评审，熟悉和明确产品的需求。其次：针对需求文档和技术文档，进行测试用例的编写。编写完测试用例之后，还需要对测试用例进行评审。接下来：研发工程师会进行产品的开发，等开发完毕，开发自测通过后，会把代码提测到你这边。此时你要做的就是把代码部署到测试环境，并开始进行冒烟测试，冒烟测试就是把产品功能的主流程走一遍。看是不是能符合提测标准。如果已经满足提测标准，就可以开始按照你编写的测试用例逐渐进行测试，这个阶段就是测试的重头戏，主旋律就是发现bug、提交bug，开发解决完bug，再验证bug是否修复。测试完毕之后，需要让产品进行产品验收和体验。验证通过后方可进行上线。上线完毕之后，还需要在生产环境下进行回归测试，等回归测试没问题之后才能宣告功能正式交付。接下来就开始进行下一个功能迭代测试。
第二、专项测试
顾名思义，就是诸如数据测试，性能测试，自动化测试等特殊的测试，主要是对业务测试的进行补充，没有绝对完美无缺的系统，单靠业务测试是无法保证产品或代码质量得到更多提升的，比方说，自动化测试可以模拟1000次点击操作，但是这个要让手工测试去做的话，不得把测试工程师逼疯囖~专项测试可以发现一些手工测试发现不到的bug，但是专项测试不可能完全替代业务测试，业务测试具有主观能动性，可以站在用户的角度，去体验一个功能的好坏以及产品是否美观，但是专项测试不能做到这一点。
第三、效能提升
现在的互联网公司产品迭代周期很短，一个功能可能一到两天之类就得上线，加入说企业不追求效率提升的话，就无法快速占领市场，我们的测试工作也是一样，更应该注重效能提升，效能提升主要可以从CI/CD,bug管理，测试环境维护、流程管理和优化去考虑，有能力的测试团队可以考虑开发出适合自己团队的测试平台，集结所有优秀的测试工具，方便测试工程师提升测试效率。近几年来，DevOps也是火了一阵，DevOps就是开发运维一体化，可以把整个产品的生产过程，形成一套流水线规范，这样也可以很大程度提升产品的交付效率。
第四、质量监控
无论如何质量都是测试的脸面，为了保证质量，我们不能只局限于测试阶段去发现bug，我们应该也要在产品交付之后进行质量的监控。比方说移动app正式发布之前，都会有灰度测试的阶段，在这个阶段，已经有部分用户可以率先体验到我们的新功能，我们需要进行app的Crash监控，所谓的Crash就是app的崩溃，Crash给用户体验造成相当大的影响，监控Crash可以有效的把Crash扼杀在正式发版之前，其他的监控还有服务器的状态监控，用户的反馈监控，埋点数据监控等等。下图是我对测试工程师所做的事进行一个大概的总结。
http://pic1.zhimg.com/v2-e24f5521976552a0d5b636d8e883a4d3_r.jpg?source=1940ef5c
大家如果对软件测试感兴趣，欢迎关注我！ 软件测试我从三部分给你说一下：
第一，说下什么是软件，软件的专业定义很抽象，为了让大家更容易理解，简单来说软件可以理解为安装在电脑或者手机中的一个程序，比如大家熟知的手机上的微信，抖音，淘宝，电脑上的Word，Excel，Wps等编辑工具很多很多，可以说我们的日常生活中软件无处不在。
第二，什么是软件测试，大家在使用的过程中是不是很少会遇到软件出故障的情况，其实这就是软件测试的功劳。一个软件从开始设计到推广给大家使用是一个漫长到过程，只有经过专业的软件测试人员进行测试，保证这个软件功能没有问题才会正式对外使用。
第三，就是软件测试工程师的工作，软件测试工程师的工作就是在软件对外发布之前，通过各种方法去使用这个软件，发现它的各种影响使用的问题，然后配合开发人员去改正，直到最终没有问题为止。
页:
[1]