本文提供了一个结构化的方法来创建和更新回归测试套件。回归测试套件应包含哪些类型的测试？应该运行哪些回归测试？如何应对回归测试失败？回归测试套件如何演变？这些问题以及其他考虑因素都会逐步探讨。
回归测试 是一种用于测试产品的增量验证技术。它旨在验证在正在进行的开发过程中，产品的新变化没有破坏现有功能。为每个新功能添加新的测试用例可确保回归测试成功。
软件开发的过程中，充满了各种各样的测试方式。今天，我们将讨论的是回归测试（Regression Testing），这是一种关键的测试策略，用于确保软件的质量和稳定性。让我们一起来深入了解这个概念。
测试在每个 Web 应用程序中都非常重要，即使在 React 中也是如此，特别是在其组件方面。
本文要点 回归测试不同于其他类型的测试。 回归测试分为多种类型，因为不同的原因，采取不同的方法。 建立回归测试的策略，重点是要考虑上下文和其他一些因素。 回归测试有很多方式和方法。 不同的方法论需要采用不同的回归测试方法。 成本高、耗时长的回归测试对整个交付团队来说是一个令人烦恼的难题。幸运的是，我们有机会让回归测试变得更轻松、更有效。要做到这一点，应该设计一个有效的回归测试策略，充分满足产品的需求，以最佳的成本保证产品质量。这需要了解回归测试的本质，采用它的原因以及执行它的方法。 为什么要进行回归测试 软
测试是软件开发生命周期 (SDLC) 的重要组成部分。SDLC 的每个阶段都应包含测试，以获得更快的反馈并提高产品质量。
上周写了一篇关于测试过程效率演变的文章，其中聊了很多过程改进的方法。比如：需求阶段应该做好评审和风险预案；研发阶段应该做好质量卡点，持续集成流水线以及为研发自测做好辅助工作；测试阶段的重点是测试计划和质量门禁，同时关注线上的发布质量，通过线上巡检和监控，持续提升测试过程效率和最终的交付质量。
什么是回归测试？ http://mpvideo.qpic.cn/0bf22iaaaaaanmahnjv2ajpfbuwdadjaaaaa.f10002.mp4?dis_k=e95607d0474ac0
我们知道，每个项目都有三个重要方面，例如质量，成本和时间。任何项目的目标都是在控制完成项目所需的成本和时间的同时获得预期的输出。
进行功能测试以确保应用程序的功能符合需求规范。这是黑盒测试，不涉及应用程序源代码的详细信息。在执行功能测试时，重点应放在应用程序主要功能的用户友好性上。要首先执行功能测试，我们需要识别测试输入并使用选定的测试输入值计算预期结果。然后执行测试用例，并将实际数据与预期结果进行比较。
由于最近的疫情影响，小部分小伙伴又要居家办公了。想起之前的文章疫情期间，如何提高远程办公效率，现在想想可能还会或多或少的采取在家办公的形式去拿工资养家糊口。
当今世界敏捷大行其道，软件迭代越来越快和发版隔间越来越小，很多公司团队都提倡小步快跑的软件开发模式。其中软件测试时间窗口不断减少，测试团队面临着比以往任何时候都面临的更多挑战，为建立可靠的连续测试策略，以适应需求变化，响应生产环境的反馈等。一些团队利用测试数据分析，而另一些团队则使用机器学习和其他先进技术来优化其DevOps管道。
回归测试对于每个版本都至关重要，因为它会检查整体应用程序的质量。众所周知，在敏捷模型中，新版本的发布很快，而回归可能成为质量保障的瓶颈。
AI 科技评论按：如何减轻软件开发的回测压力，从而提高工程师的生产效率？MATEUSZ MACHALICA、ALEX SAMYLKIN 等人组成的 Facebook 研究团队提出使用一个利用机器学习的新系统来创建一个为特定代码更改选择回归测试的概率模型，从而更好地执行这种回归测试。
人们常说“懒惰是程序员的美德”，因为程序员通常无法忍受重复低效的工作，所以他们通过编写软件程序，帮助人们解决问题，从而达到一劳永逸的效果。与程序员有所不同，测试工程师身上的美德有细心、耐心、可以胜任重复的工作等等。那么，作为测试工程师，我们是否也应该拥有“懒惰”的美德呢？我们是否需要在重复工作的过程中去思考和探索让工作“一劳永逸”的方法？
精准测试从某个层面来讲，是赋予了测试用例真正的生命力，传统的测试用例仅仅是一些只能够依赖人去理解和分析的文本文件而已，在计算机和算法层面则没有存在意义和价值。下图是精准测试的整体架构图：
码农的产品和服务大都是以软件形式存在的，我们存在的价值之一就是快速提供高质量的软件产品或服务。如何保障软件的高质量呢？这与软件测试分不开的，测试是保证软件质量的关键环节之一。
敏捷提供了众多优势，例如更快的上市速度，更快的ROI，更快的客户支持，降低的风险，持续的改进等，随之而来的还有一些非常困难的挑战。在这些主要问题之一中，令人头痛的是在sprint开发和迭代测试之间保持适当的平衡，进行精确的敏捷开发和回归测试。
软件测试阶段是软件开发生命周期中至关重要的一环，其主要目的是确保软件产品满足用户需求，并且在交付使用前尽可能地发现和修复缺陷。软件测试可以分为多个不同的阶段，每个阶段都有其特定的目标和测试活动。
软件测试是软件开发过程中的基本活动。黑盒测试和白盒测试是两种不同类型的软件测试策略，它们具有同样强大的功能，并且结合使用时甚至更好。
其实测试的过程并不是固定的，它只是一种规范，也可以把它当作一种指导。但是真实的产品测试和项目测试中，一定是要灵活运用的，甚至是在不断的根据实际情况变化。我在其他平台、app上讨论软件测试时，经常提到：项目测试和 产品测试一定是不一样的。
埋点是在应用中特定的流程收集一些信息，用来跟踪应用使用的状况，后续用来进一步优化产品或是运营的数据支撑，包括访问数，点击量等等。
冒烟和健全性测试是软件测试中最容易被误解的主题。关于该主题的文献很多，但其中大多数令人困惑。下面的文章试图解决这种疑惑。
手动测试人员应该权衡测试自动化相对于手动测试的好处，并且即可开始行动。下面我介绍一下从手动测试到自动化测试转换的5步指南。
你不是唯一一个为区分回归测试和重新测试绞尽脑汁的人。它俩都是用于开发之后，很多人因为这两种软件测试类型之间有很多的相同点而陷入疑惑。然而在一些大的方面他们是不一样的。
手动测试是其由QA分析师手动执行对软件的测试。执行此操作是为了发现正在开发的软件中的错误。
页面级测试是Web测试中的重要组成部分，它主要关注用户界面的展示、交互以及用户体验，在有赞以及整个业界，页面级测试往往涉及复杂的用户交互，这使得自动化测试面临很大挑战，部分工具如Selenium虽然可以模拟用户行为，但是维护成本高，随着页面功能和布局的频繁变化，维护测试脚本的成本也越来越高，且容易受前端页面变更的影响导致执行失败。
为了应对多客户端（Web, iOS, Android）的挑战，2016 年我们在团队层面和技术栈上做了很大胆的尝试：我们把前端团队和移动端合并了，组成了客户端团队。这个团队采用同一套基于 React
上期讲到回归BUG，本文将讨论一些回归测试的最佳实践和方法，它们将有助于处理回归BUG。
在产品需求迭代过程中，功能测试与回归测试是必不可少的两个环节。对于改动较大的项目，首先，确保功能的实现符合产品逻辑并做到100%没有问题离不开有效的功能测试；其次，项目中很多逻辑的改动都是在原有功能的基础上进行的，这时候就需要一定的回归测试。通常，在功能测试时，人工case不能模拟线上用户的所有行为，且具有一定的主观性；回归测试时，采用全面回归的方式往往也伴随着测试成本的增加。一个好的方式就是利用线上流量来验证。
因为某些测试生来就会产生依赖环境的结果，我们提供了方法来指定替代的“预期”结果文件。每一个回归测试可以有多个比较文件来展示在不同平台上的可能结果。有两种独立的机制来决定为每一个测试使用哪个比较文件。
前一阵子，笔者在某个高端测试群里面丢了一个小石头，引出了诸多测试大佬的讨论。不少人首先就不认同这个问题，认为自动化测试的目标就不是发现缺陷，而是其它。
对于测试人员来说，不管进行功能测试还是自动化测试，还是性能测试，都是需要编写测试用例，所以我们必须先要了解清楚手工测试用例与自动化测试用例的一些特点，才能更好的开展自动化测试工作。
为了解自动化测试的当前和未来状态，我们采访了14位非常熟悉自动化测试的IT专业人员。我们问他们：“通过自动化测试解决了哪些现实问题？”
顾翔老师开发的bugreport2script开源了，希望大家多提建议。文件在https://github.com/xianggu625/bug2testscript，
A是软件测试部负责此日历行程的测试工程师，在做日程提醒事件测试时，他发现如果手机电力不足（不足于开机），而这段时间正好有提醒事件发生，则在下次开机后不会再提醒，即发生在没电池时段内的提醒事件会丢失。
它测试了被测软件的行为。根据客户的需求，称为软件规范或需求规范的文档将用作测试应用程序的指南。
haibing，携程研发能效经理和SRE，关注自动化测试，能效提升方向的工具技术。
「回归」这个词会让很多软件测试人员想起痛苦不堪的经历。对于发布窗口而言，回归测试是多么的重要以至于不可或缺也来不得半点虚假。有时候，我们甚至想知道是否真的需要回归测试？当软件一直处于发现BUG和解决BUG的循环中时，为什么我们需要执行回归用例？我们需要定期执行回归测试。我们这样做的原因是发现回归缺陷。
在软件测试领域，有两种测试技术：手动测试和自动化测试。两者都旨在执行测试用例，然后将实际结果与预期结果进行比较。手动测试是一种基础的测试技术，需要大量的人工来确保软件解决方案能够完成它应该做的所有事情。
在软件测试行业中，争议最大的话题是“更好的是手动测试还是自动化测试”。尽管自动化测试最常谈论流行语，并且正在慢慢主导测试领域，手动测试的重要性不可忽视。
我们每个人在测试过程中都会遇到几种类型的测试。我们可能听过一些，也许已经做了一些工作，但是并不是每个人都了解所有测试类型。
软件开发和交付正在从复杂、独体式应用程序朝更加分布式、以服务为中心的架构转变，前缀的许多依赖关系在编译时解析，而后者的依赖关系在运行时解析。大部分企业应用程序都是最初为比云更早的环境设计的现有应用程序（也称为记录系统）与在云中开发的新 “互动参与系统” 应用程序的组合。由于它们具有众多依赖关系，它们的架构可能很复杂，而且它们使用 API 来衔接现有记录系统和新的互动参与系统。它们利用 API 管理和云集成技术来实现集成，同时满足企业的安全需求。它们的工作负载可能跨多个环境运行：内部部署、私有云、公共云，这些环境组合在一起形成了一种也称为混合云的架构。
http://mpvideo.qpic.cn/0bf2jeaaiaaa3eaeb6fj3vpfasodareqabaa.f10002.mp4?dis_k=cc04b07c621debb660c5902
为了解决SRS WebRTC推流， 转RTMP后音视频时间戳不同步， 导致的后续HLS切片，FLV/RTMP播放音画不同步等问题，我提交了一个PR：https://github.com/ossrs/srs/pull/2470 其实就是依赖SenderReport来同步RTP时间戳和绝对时间戳。做完了以后，简单的跑了下， 发现输出符合预期， 就满心欢喜的提交了PR， 等待合并。 最先review代码的是SRS技术委员会的进学， 他提出了一个问题：“如果Sender Report乱序了，计算出来的时间戳是
翻看之前学习自动化测试时记录的技术笔记，发现写了很多的落地方案文档，正好后台有同学私信问我，该如何设计一个自动化测试的落地方案。这篇文章，分享一下我对于自动化测试落地方案的想法和实践。
业界有一些强大的工具可以替代Selenium，今天就来大概介绍一下。以下清单是精挑细选的Selenium替代框架：
概述：标识并描述发现的缺陷，具有清晰、完整和可重现问题所需的信息的文档。 理解：测试人员发现缺陷，将缺陷记录在《缺陷报告》中，通过缺陷报告将缺陷告知给开发人员，并对缺陷进行跟踪和管理。缺陷报告是测试人员与开发人员之间重要的沟通方式。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
