专注测试技术的课程订阅站点

如何在软件开发中实现速度和质量的平衡

软件开发的节奏和期望在最近的时期急剧升级。以前,团队会提前几个月规划大多数软件产品的交付周期。瀑布式开发方法是开发软件的主流方法,并且许多组织在不同行业广泛采用了这种方法。例如,Microsoft Windows 操作系统的开发在上市之前需要数年时间。即使是以服务包形式的增量更新也需要数年才能发布。

在当今快节奏的环境中,任何花费数月或数年时间向客户交付新功能的组织都将被抛在后头。构建和部署软件的方法发生了巨大变化,大多数公司采用了快速开发周期以保持竞争力。回到上面提到的例子,Microsoft 近期的 Windows 版本转向滚动更新,而不是等待多年才发布新功能。这一举措使得公司能够定期和频繁地推出变化,而不是让消费者等待数年。

这种尽快构建和频繁交付的加速周期对于消费者来说非常有利,他们可以在应用程序的主要版本之间没有长时间等待的情况下获得最新和最好的软件。然而,产品开发团队面临的压力可能导致他们采取捷径和省略步骤。在许多情况下,由于高要求导致的质量和稳定性的牺牲会导致产品存在错误,从而使客户不愿使用。

初创公司和小公司最容易受到快速交付的负担和困扰。在这种环境下,这是一种必要的恶。当你在一个小团队中努力工作,希望将新的创新产品推向世界时,你需要频繁迭代你的产品,将其塑造成能够使你的业务生存下去的东西。通常,这意味着更加强调快速发布周期,为初创公司留下更少的时间和资源进行测试。较大的公司通常有更多的时间和资金用于质量,但以延长的开发和部署周期为代价。

大多数组织认为他们可以通过速度或质量来应对,但这种策略只能在短期内起作用。对于初创公司来说,快速交付周期可以帮助他们更快地迭代和修复错误,但随着时间的推移,所有这些捷径将累积成巨大的技术债务,使开发变得更加缓慢和困难。较大的组织将建立稳定软件交付的流程,但缓慢的交付速度将使竞争对手超越他们。软件团队需要同时具备速度和质量,才能应对现代软件时代客户的高要求。

软件开发中速度的重要性

正如本文已经指出的,速度对于保持软件开发的长期业务计划至关重要。在争夺消费者有限的注意力方面,竞争异常激烈,对许多组织来说,以较慢的速度工作以确保准确性已经不再可接受。未能迅速工作和适应将不可避免地面临挑战。应用程序中过时的功能可能导致客户转投其他地方,这导致消费者和市场份额的损失,最终不可避免地以失败告终。

多年来,我们见证了无数组织因无法跟上技术进步或对其不感兴趣而失败。例如,在 90 年代和 2000 年代初,诺基亚是手机的代名词。但是当苹果推出 iPhone 并且谷歌随后推出 Android 时,诺基亚选择坚持其现有软件平台,而不是加入消费者想要的更现代和先进的移动生态系统。该公司在接下来的几年中迅速失去了超过 90%的市值,再也没有恢复其在该市场细分中的地位。

然而,快速前进也带来一些风险。过快发展的其中一个更危险的风险是花费数月或数年时间来构建人们不需要的东西。大多数初创公司无法生存,因为他们的创始人无法找到产品与市场的契合点,使他们的软件可持续发展。大型组织在新产品方面也面临这个问题,比如谷歌。该公司在 2013 年推出了 Google Glass,虽然许多人对该设备着迷,但谷歌未能弄清楚为什么大多数人愿意为该产品支付 1500 美元。该公司也没有花时间考虑隐私和安全问题,试图快速进入市场。结果,该产品成为谷歌最引人注目的失败之一。

急于上市的最明显风险是可能导致产品发布时尚未完全完成。我们经常在软件和硬件产品中看到这种情况。例如,苹果在 2012 年发布了苹果地图,试图替代其设备上的谷歌地图服务。然而,该产品显然还没有准备好,存在大量错误、不准确的导航和缺失的数据。另一个例子是微软因其发布的 Windows Vista 而受到严厉批评,该系统运行缓慢且不稳定,许多项目开发人员将这些问题归咎于匆忙的发布计划。

为了解决这些问题,组织通常需要暂停一下,审视他们如何处理产品质量的问题。

软件开发中质量的重要性

软件质量是软件开发生命周期中非常重要但常常被忽视的部分。每个人都希望产品具有最高的质量,但很少有人在追求速度时给予足够的重视。许多开发团队对测试和质量保证流程口头上多有讲究,但没有采取实际行动。在某些团队中,尤其是在“快速打破事物”的时代,有时会将质量视为快速开发的直接相反,但这与事实相去甚远。

本文前面提到的一些例子讨论了为什么质量至关重要。当您加快应用程序的开发并忽略质量问题以便更快地推出产品时,随之而来的问题将不可避免地导致系统故障、安全漏洞和对您品牌的信任不足。我们经常看到新闻中的许多组织由于质量差而遇到困难和危机,从初创公司到科技巨头都有。

专注于质量并不是解决这些问题的万能解决方案。事实上,过于专注于某一方面可能对开发过程产生不利影响。除了导致发布计划放慢并且远远超过截止日期之外,过于严格的质量保证政策还可能导致团队士气下降。我曾在一家初创公司工作过,他们将质量保证团队设为我们是否能够发布网页应用程序更新的门槛。他们的标准相对较高,即使是小问题也完全阻止了部署。开发和质量保证之间的来回反复随着每次进度滑坡而变得紧张。开发人员和测试人员都没有在公司呆很长时间,员工流动是该初创公司不存在的原因之一。

在某些行业中,质量是绝对必要的。您不希望使用实验室没有经过彻底测试的心脏起搏器,也不希望使用没有经过安全专家审计的互联网银行。但在软件行业中,现实情况是,大多数开发人员正在构建的是没有任何巨大影响的网络或移动应用程序,即使产品不像预期那样始终正常工作。您可能会因为偶尔的小错误或可用性问题而冒失去客户的风险,但我们很少遇到在软件中会产生不利现实影响的问题。大多数时候,它们只是小小的烦恼,不会导致客户大批离开。

作为软件开发人员和测试人员,我们不希望放慢速度或发布有错误的软件。我们需要学会如何正确平衡速度和质量。

在软件开发中平衡速度和质量

过快进行开发和测试会导致质量问题,但过于关注质量可能会拖慢整个过程。关键是根据项目当前的状态找到合适的速度和质量平衡点。当然,安全地进行快速迭代测试和部署应用程序并不容易,但通过投入时间和精力是可以实现的。

以下是您可以在组织中实施的五种策略,有助于在所有应用程序中实现速度和质量的正确平衡。

1)自动化测试 大多数软件团队都有测试流程,但通常他们将这些流程视为次要任务,与构建功能和修复错误相比,它们的重要性不大。即使在 2023 年,我与许多团队合作时,他们仍然主要进行手动测试,仅在部署前进行测试,这是一个缓慢、繁琐且容易出错的过程,导致问题被忽视。自动化这些重复性任务可以显著提高效率,通过消除它们并更快地捕捉到回归问题。自动化测试并不能取代手动测试,但它确实有助于提高应用程序的速度和质量。

尽管自动化测试可以帮助开发人员和测试人员更快地完成任务,但如果团队在整个产品生命周期中没有密切关注它,它可能成为一个障碍。我曾见过一些团队夸耀他们有成千上万个自动化测试用例,但仔细检查后发现自动化并没有像他们想象的那样帮助他们。团队可能在覆盖范围上存在巨大的空白,或者他们没有测试应用程序的高商业价值部分。测试套件运行时间也很长,并且由于不稳定性而经常失败,导致他们花费更多时间修复测试套件,从而占用了宝贵的时间。关键是确保自动化测试能够很好地平衡速度和质量,以帮助团队快速交付并尽快解决问题,以防止平衡倾斜到一侧。

2)持续集成/持续部署 应用程序的自动化测试很好,但如果您或您的团队不经常运行这些测试,那么构建它们就是浪费时间。我在职业生涯中与数百名开发人员和测试人员合作的经验表明,很少有人在本地运行其应用程序的自动化测试套件。持续集成环境对于任何希望在快速交付产品时感到自信的组织来说都至关重要。一个良好构建的持续集成系统将尽早尽可能频繁地运行自动化测试,以便在问题变得更容易修复和更便宜时捕捉到潜在问题。

在设置持续集成环境以自动化测试之后,下一步是研究持续部署以自动化软件发布。“持续部署"通常指的是当代码库中有任何新更改时自动部署应用程序。这种策略并不适用于所有人,因为它需要大量的时间、精力和信任来安全地实现。但采用这种方法的团队在其流程中构建了所需的高质量,从而在竞争中获得巨大的优势。如果一个团队出于任何原因不愿意自动化其部署,他们至少应该有改进部署流程的流程,因为这将迫使速度和质量保持良好的平衡。

3)功能开关 功能开关是一种软件开发策略,允许团队在不更改底层代码的情况下设置可以打开或关闭的行为。通常,开发人员使用这种技术来构建和发布他们不希望在各个环境中广泛提供的功能,直到他们可以进一步开发和测试。这样,团队可以逐步以小规模发布功能,并在生产环境中进行测试,而不会造成系统中断。

功能开关是在应用程序中平衡速度和质量的一种绝佳方式,因为它们允许团队在发布给大众之前在内部或与部分客户测试和实施新功能。测试人员可以拥有一个界面,可以在没有开发人员介入的情况下安全地切换代码库的不同部分。缺点是太多的开关可能会导致代码库混乱,并对开关背后的功能产生潜在的混淆。然而,合理使用这种方法可以使团队收集反馈,降低风险,并快速解决问题,同时增加部署高质量解决方案的信心。

  1. 金丝雀部署 许多组织通常会同时向所有用户发布新功能和功能。虽然这样可以使团队更快地部署,但可能会牺牲质量,特别是对于没有许多自动化测试或将持续集成纳入其工作流程的团队。即使有这些系统存在,由于开发、测试和部署阶段之间的差异,仍然存在出现问题的风险。开发人员可能会发现他们的应用程序在他们的计算机上运行得非常好,或者测试人员在测试环境中找不到问题,但由于微小的差异,应用程序在生产环境中出现问题。

金丝雀部署通过逐步将应用程序的部署提供给一部分用户,然后再向所有人提供,有助于减少这种风险。这个过程允许团队监控新功能的真实使用情况,并收集数据来确定变更的安全性。这些部署与特性标志略有相似之处,但工作在应用程序级别,因为流量在应用程序的旧版本和新版本之间进行划分。一切看起来都很好之后,团队可以将所有人重定向到最新版本的应用程序,并删除以前的版本。金丝雀部署需要一些前期工作,包括监控和可观察性系统,以跟踪部署后的系统行为。这些部署可能会使团队的速度变慢,因为他们必须等待完全部署任何变更。然而,确保质量所需的努力和时间最终会在未来提高速度。

  1. 团队之间的合作 在开发过程中,要在质量和速度之间取得平衡,并不是所有事情都需要技术解决方案。对于希望快速而安全地发布产品的任何组织来说,跨所有参与软件开发生命周期的团队(开发人员、质量保证和运维)建立协作文化至关重要。这些团队之间的相互联系将通过消除障碍和潜在的沟通问题,从头到尾创建一个流畅高效的工作流程,从而提高速度和质量。自动化测试、持续集成/持续交付、特性标志或金丝雀部署在产品的所有团队没有达成一致的情况下并不重要。 当团队紧密合作时,他们可以确保每个人都在做正确的事情,并提出比独立工作更好的解决方案。例如,测试人员通过识别开发人员在开发过程中没有考虑到的潜在弱点和边界情况来帮助开发人员,运维团队可以更轻松地为测试人员设置测试环境。这种合作努力必然会带来改进的产品,因为它们将不同的观点和专业知识融入到讨论中。当每个人共同努力时,他们可以完成比每个人单独所能做的更多的事情。

结论

团队可以尝试本文中讨论的一些或全部想法,努力实现速度和质量的良好平衡。您的组织可以从改进自动化测试和实施持续集成开始采取小步骤。一旦您开始注意到开发和质量保证的工作速度更快且问题更少,团队可以引入功能开关和金丝鸟部署,以帮助更顺畅、更高效地发布。即使您不实施这些策略中的大部分,紧密的跨团队合作将成为整个过程中最重要的组成部分。如果没有坚实的合作,您将无法取得很大进展。

在追求工作速度和确保产品高质量之间找到适当的平衡并不容易。这需要组织内各个部门之间的大量努力和协调,包括开发、测试等等。当您努力实现这种平衡时,不要期望变化会立即发生。团队必须明白这是一个缓慢的过程,如果需要时间才能看到结果也是可以接受的。知道进展不会一夜之间发生是改善事物的第一步。通过努力采用本文提到的策略,您将更接近找到速度和质量的完美平衡点。

逃离微服务?为什么现在大家又在讨论微服务

最近比较热门的圈内话题,出了下云就是对微服务的讨论。

微服务今年又一次的引起了广泛讨论可能是源自今年年初亚马逊内部的一次架构迁移。

起因

在这个案例中,Prime Video 团队将一个监控系统从微服务架构迁移到单体架构,并避免使用昂贵的服务(如 AWS Step Functions 和 Lambda 无服务器函数),并对此举所带来的降本效果进行了评估。简单来说就是该团队通过将服务从微服务变成单体应用取得了明显的降本增效的效果。

这个例子引发了广泛的关注和讨论,一时间人们似乎不知道该如何去评价这件事情。反倒是一直鼓吹下云和反对微服务化的 dhh(可以理解为著名网络喷子)一针见血,他指出:即使是亚马逊也无法理解无服务器或微服务

讨论

事件逐渐发酵,目前关于逃离微服务的讨论可以频繁的见诸报端,比如前几天有人就这样的评价微服务

“microservices conflate logical boundaries (how code is written) with physical boundaries (how code is deployed).” “we propose a different programming methodology” “Our implementation reduces application latency by up to 15x and cost by up to 9x”

  • “微服务将逻辑边界(代码编写方式)与物理边界(代码部署方式)混为一谈。”
  • “我们提出了一种不同的编程方法论。”
  • “我们的实现可以将应用程序的延迟降低多达 15 倍,成本降低多达 9 倍。”

这里有一个非常有意思的点,那就是有没有一种可能单体服务比微服务其实要节省资源?

还有人认为微服务其实是一种权衡,并给出了下列的忠告。

  1. 谨慎地拥抱复杂性 投身于微服务不仅仅是一个技术决策,而是对复杂性的一种承诺。有时候,为了追随潮流,我们似乎在破坏一个系统。并非每个应用程序都需要一个相互连接的服务网络。正如 Sam Newman 在《构建微服务》一书中提到的那样,架构需要满足一定的前提条件,否则就可能过度设计。

  2. 灵活性是有代价的 是的,微服务承诺了灵活性,但也伴随着沉重的代价,不仅仅是基础设施方面的代价,还包括认知负荷。每个服务都变成了自己的领域,需要专门的关注。

  3. 没有一种大小适合所有 如果我从中获得了什么,那就是架构决策不能孤立地脱离业务需求而做出。一个灵活的初创公司的需求与传统的企业应用程序截然不同。虽然像 Netflix 那样的案例研究对我们启发很大,但我们必须认识到,适用于某个公司的解决方案未必适用于所有公司。

推荐:Docker备忘录

项目源地址:https://github.com/wsargent/docker-cheat-sheet

docker 的安装

略,windows 上可以用 docker desktop,具体可以参考官方文档。https://hub.docker.com/editions/community/docker-ce-desktop-windows

安装之后用 admin 身份打开 powershell,输入

#Display the version of docker installed:
docker version

##Pull, create, and run 'hello-world' all in one command:
docker run hello-world

容器相关

容器的生命周期

  • [docker create](https://docs.docker.com/engine/reference/commandline/create)  创建但未启动
  • [docker rename](https://docs.docker.com/engine/reference/commandline/rename/)  重命名容器
  • [docker run](https://docs.docker.com/engine/reference/commandline/run)  一个命令创建并启动容器
  • [docker rm](https://docs.docker.com/engine/reference/commandline/rm)  删除容器
  • [docker update](https://docs.docker.com/engine/reference/commandline/update/)  更新容器的资源限制

几个有用的点

  • 一般启动容器我们用 docker run -td container_id, -t 表示分配 TTY session,-d 表示后台运行并打印容器 id
  • docker run –rm 用来运行容器后自动删除
  • docker run -v $HOSTDIR:$DOCKERDIR 用来做 volume 的映射

容器的启动和停止

  • [docker start](https://docs.docker.com/engine/reference/commandline/start)  运行容器
  • [docker stop](https://docs.docker.com/engine/reference/commandline/stop)  停止一个运行中的容器
  • [docker restart](https://docs.docker.com/engine/reference/commandline/restart)  重启容器
  • [docker pause](https://docs.docker.com/engine/reference/commandline/pause/)  暂停容器
  • [docker unpause](https://docs.docker.com/engine/reference/commandline/unpause/)  继续运行一个暂停了的容器
  • [docker wait](https://docs.docker.com/engine/reference/commandline/wait)  等待直到容器停止
  • [docker kill](https://docs.docker.com/engine/reference/commandline/kill)  发送 SIGKILL 信号给容器
  • [docker attach](https://docs.docker.com/engine/reference/commandline/attach)  连接运行中的容器

限制 cpu 和内存

docker run -it -c 512 agileek/cpuset-test

上面的命令限制了 cpu 使用率为 50%,看起来很奇怪对不对?因为 100%使用率用的参数是-c 1024,所以 50%就是 512

给测试开发工程师的5条建议

近些年可以看出测试开发工程师是热度比较高的测试职位,除了涵盖了之前自动化测试工程师的职能外,测开同学的开发能力进一步提升,可以做到开发一些测试平台和测试框架的工作,并在推广自动化测试方面也有一定的 kpi 要求,能力越大责任越大,正好看到了国外有同行写的给自动化测试工程师的几条建议,觉得还是有一定道理的,所以在这里简单的分享一下,希望对大家所有裨益。

质量心态

作为测试开发工程师,我们可能专注于学习测试工具和测试框架,提升代码能力,日复一日,循环往复。学习是没问题的,不管你是测试开发还是功能测试同学,持续学习应该是整个职业生涯里必不可少的一部分。话虽如此,不过对于测试同学来说,全方位的质量心态还是很有必要的。

那么质量心态是什么呢?作为测试开发同学,我们应该关注项目/产品质量的方方面面,而不是仅仅满足于将验收标准或者是手工用例转化成自动化脚本。

相反,我们应该站在质量控制的层面去从用户的角度带入思考,如果我们的脚本不能为用户带来价值,那么这些脚本其实就没有价值。

举一个例子,我们在提交一个表单的时候,比如注册用户以后,我们的 ui 自动化用例是不是需要去查数据库,看看新的用户记录已经被持久化到了用户表里?我的答案是:在开发时间有限的前提下不需要去连数据库查询,因为用户是不会连数据库直接看数据的,我们应该从用户可以感知到的方面进行断言。连数据库查询的事情可以交给其他类型的自动化用例,比如单元测试用例去实现。

获取其他测试领域的知识

相比于成为某种工具或者编程语言的专家,测试开发工程师可能更有必要成为一名通才,我们最核心的观念应该是帮助团队满足用户的需求和期望。

因此除了功能测试和自动化测试之外,我们是需要学习其他领域的知识,比如性能测试,可用性测试,可测试性,安全测试,移动端测试,可视化测试和数据测试。

技术已经发展了很多年,我们几乎每天都有许多领域和新技能需要学习。让我们探索一些可以帮助你提升自动化工程师职业生涯的领域:

探索性测试

老生常谈的话题了,探索性测试可以叫做老司机测试,但探索性测试并不是随心所以,而是需要精心计划和设计一些测试用例。我们可以通过探索性测试来开阔用例设计的思路,从而改进我们的 e2e(也就是 ui)测试用例。《Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing》阅读这本书可能是一个不错的开始,不过我好像并没找到中文版本,有点可惜了。

数据测试

机器学习和人工智能每天都在使用数据,但数据的有效性还是要验证的。我的建议是开始学习数据模型的性能,这有助于我们弄清楚一些 ML 预测错误的具体场景。

可视化测试

其实就是 ui 测试了,ui 是产品和用户打交道的最终途径,很多情况下也是唯一途径,生产环境中的视觉错误会危及我们的声誉并影响我们的品牌,所以 ui 的测试是非常必要的,也是需要我们去花精力学习的。

可访问性测试

正如您可能知道的那样,许多国家/地区的法律法规要求让每个人都可以访问应用程序,并且创建一种必须适合所有人的软件应用程序文化。比如产品对盲人用户的可访问性就是一个很好的例子。我们可以从https://www.w3.org/WAI/WCAG21/quickref/开始进行学习。

安全测试

就法律处罚和品牌声誉而言,安全漏洞往往代价高昂。我们应该在 CI 的 pipeline 中增加安全扫描的环境。我的建议是开始阅读OWASP和学习一些安全测试工具。

混沌测试

混沌测试/混沌工程测试是在影响客户之前发现漏洞和进行中断。简而言之,我们希望系统是可以在受控的环境中进行错误恢复的。如果你想学习混沌测试,那么《Chaos Engineering: System Resiliency in Practice》这本书将是一个不错的开始。

获得正确的帮助

获得他人的支持可以加速学习周期并显着改善您的职业生涯。但是,首先得找一个你信任的导师,他已经掌握了你想学习的技能,这些技能可以是技术技能或软技能。

我的建议是你问问自己:“我公司或我的人脉网中谁会注意到我的变化并为我提供诚实的反馈?”  有时候找导师可能很困难,我们希望有最好的老师来指导我们。如果你在你的社交网络中找不到导师,你可以要求你的上级提供高质量的指导。

“如果你想快点走,就一个人走。想走远一点,就一起走”

自动化不仅仅是执行测试脚本

这个很好理解,自动化的目的是什么?大家可能有自己的答案,但答案一定不会是执行用例并使其通过。

其实我总结自动化的目标是帮助团队从质量和效率的维度满足用户的预期。

质量很好理解,我们不希望用户用到全是 bug 的产品;效率也不难想象,我们希望用户可以尽快的用到产品。

分享也是学习的一种途径

正如你可能知道的那样,教导他人可以提高你自己的学习能力。记得之前看到过一个学习的方法就是先自己学一遍,然后把自己学到的东西讲给别人去听,如果别人能弄明白,那么你自己就学会了。

基于k8s的测试执行工具:TestKube

之前我们自己开发过一些基于 k8s 的执行用例执行工具,原理大致是在用例执行的时候动态去 k8s 上创建容器,执行任务,上报指标,最后销毁容器,不过这些过程基本上与测试过程耦合在一起,难以平移扩展。最近发现了一款在开发早期的通用型的基于 k8s 的用例执行工具: TestKub。

有用的链接

特性

  • 支持执行 postman collection
  • 支持执行 cypress 的 ui 测试用例
  • 支持执行基于 curl 的简单探活,比如站点,接口有没有挂的检测之类

工具希望解决的实际问题

  • 避免 vender 锁定 CI/CD 管道中的测试编排和执行
  • 在集群中轻松编排和运行任何类型的测试 - 功能、负载/性能、安全性、合规性等 - 无需将它们打包成在 docker-images 或提供网络访问
  • 使测试执行与构建过程分离成为可能; 工程师应该能够在需要时运行特定的测试
  • 以一致的格式集中所有测试结果,以实现“可操作的 QA 分析”
  • 提供模块化架构以添加新类型的测试脚本和执行器

简单来说就是提供了与 ci/cd 解耦的纯测试容器编排和执行能力,并提供了统一的报告输出。

主要模块

  • kubectl 插件
  • API Server - 调度器,执行器,收集执行结果
  • CRDs Operator - 观看 TestKube CR,处理与 API Server 通信的更改
  • Executors - 运行为特定运行程序定义的测试,目前可用于 Postman、Cypress 和 Curl
  • 结果数据库 - 用于集中测试结果管理
  • 一个简单的基于浏览器的看板,用于监控测试结果

总结

这里就不列举如何安装以及简单使用该工具进行用例执行了,目前 TestKube 的版本是 0.6,还处在早起的开发阶段,不过项目的文档较为全面,而且模块化良好,有一定的扩展性,所以后面可能吸引一些使用者,有强烈需求的同学可以直接拿来就用,拿不定主意的同学建议再观察一定时间,等到 1.0 版本再入坑。

测试同学找工作要不要刷题

最近有公司裁员火到上了热搜,今年就业形式不容乐观,相信有不少同学正在努力找工作中,另外可能有一些同学被裁员的阴影所笼罩,也许在默默的为下一份工作而努力。看到一些开发同学正在刷题刷的飞起,而与之对应的是工作机会的减少,简历字面要求的提高,以及面试周期的增加,据说现在面试题难出了天际,其实也是一种变相提高门槛的表现,那么这个时间点测试同学在面试之前是否需要刷题呢?

答应是不一定,具体情况可以具体对待。

初级测试同学

一些公司对初级测试的同学的要求不是特别高,人聪明能干活就行,所以可能不需要频繁刷题,但一些简单的编程能力还是要有,防止被一些不太复杂的代码题被动过滤,如果时间不是很充裕的话,优先级是了解测试流程,测试方法,测试工具,各种测试种类(功能性能接口等),最后才是简单的算法和数据结构题。

中高级测试同学

其实中高级在技术上的要求差不多,所以放到一起讲,技术的广度上中高级的区别不大,不过深度上高级同学可能需要有一个强点可以侧重,能讲出东西来,让人信服。这两个职级都强烈建议刷题,不过优先刷简单的题先,中等难度的适当刷一点点,有些实在是看不明白的放弃也不可惜,高难度的题的就不用刷了,如果在面试中遇到的话,那这个职位可能是为某些人高度定制化的,或者根本就没有诚心招人,做不出来也不要紧。至于算法,可以了解比较简单的排序递归等,高级一点的贪心算法和动态规划可以适当的看看,大概知道概念,做不出来也问题不大。数据结构的话推荐优先了解二叉树及各种变种,更复杂的数据结构不看也可以。

管理岗位

管理岗位的话一般来说不用刷题,因为管理者可能很多年都没写过代码了,实在是霸王硬上弓的话可能会让场面一度显得比较尴尬。不过不写不意味着就可以不知道,数据结构和算法应该有所了解,比如 merge sort 写不出来具体的实现,但是其过程和原理应该是可以表述清楚的。算法的话可以了解一些简单的,数据结构也是从二叉树开始,结束在你没有时间去了解的地方。

测试开发

岗位相对较少,所以可能会更卷一些。建议初中级难度的全部刷完,高级难度如果能熟练掌握的话就转开发吧,大部分的开发没有花时间准备的话中高级题都很难写出来,简单题翻车也不是没有可能。

其他测试相关岗位

比如 pmo,qa 等质量度量和流程管理类的角色,其核心竞争力与刷题无关,不刷是完全没问题的。