如果突变覆盖率不够高，我能让质量门失败吗？ - 腾讯云开发者社区 - 腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

DevOps 实施中的10个“深坑”，你一定要警惕

如果要靠最后的人去验证车的质量是否OK，我觉得这是是不对的。另外一个就是丰田公司，他们是怎么做流水线的？...如果不这样，一开始你的质量门永远过不去。...，都会有相应的质量门。...但是我想这些真的是 DevOps 需要的吗？所以说很多 DevOps 是为了什么？是为了提效增质、安全，但是这些我是没有看到。...还有一个很重要的就是同行对比，右边的图大家可以看到，我们通过DevOps评估的方式，能让你看，比如说实施DevOps之后，我能达到一个什么水平，其实我是不光跟内部比质量提升，还有可以跟同行比，看在这个行业里的一个水平

1.5K3 0

变异测试

变异测试，英文Mutation Testing，是使用变异器（切换数学运算符，更改返回类型，删除调用等）将代码修改为不同的变异（基于变异器创建新代码），并检查单元测试是否失败。...好的单元测试应该使所有突变都失败（杀死）。所以，变异测试的有效性可以衡量杀死了多少个突变。变异测试是覆盖率的一个很好的补充。相比覆盖率，它能够使单元测试更加健壮。...注：如果是要执行指定某个包路径下所有类的单元测试变异测试，则通过targetClasses和targetTests的模糊匹配，比如这样： com.xxx.util.* testng 找到插件双击...运行完成后，会自动生成变异测试报告，报告位置一般在对应模块的target/pit-reports目录下：报告会详细列出每个包、每个类的覆盖率，变异通过率等。 ?...如果我的单元测试加上边界测试： ? 再次执行，变异测试全覆盖了！ ?

1.8K2 0

您找到你想要的搜索结果了吗？

是的

没有找到

如何控制代码的质量

质量关卡的执行时间不应超过 5 分钟，最好更短。坚固耐用。由于工具问题或基础设施不良而导致的质量门失败非常令人沮丧。工程师无法继续工作，并因没有做错的事情而受到指责。...假设质量门失败，需要一周的重构才能解决问题并获得“绿灯”。这会导致挫败感，因为交付通常是一系列变更的最后一步，而这些变更通常涉及时间压力。因此，如果出现这样的故障，应该相对容易修复它以通过质量门。...在这个位置最重要的约束是额外的检查应该有很多附加值，因为如果这个门失败了，它将在工程师交付后的一天或多天返回给他。必须有非常好的理由在游戏后期要求修复。...如果您的代码覆盖率是 65%，而 60% 是绝对目标，那么您就没有经过像样的单元测试就可以交付代码。 2 另一方面，相对目标对每个人来说都是一件好事。...换句话说：您已经修复了一个错误，但质量门控失败了。这不是我们引入质量门控的原因。 3 但它变得更加复杂。假设你决定对代码覆盖率进行质量门控。每次你交付更改的代码时，你的单元测试都必须变得更好。

1321 0

使用一条 CICD 流水线管理所有的产品

它可以帮助敏捷开发团队提高部署频率，减少变更准备时间、变更失败率和关键绩效指标（KPI）的平均恢复时间，从而提高质量并且实现更快的交付。...尽早、频繁地扫描漏洞，并且尽快失败尽早、频繁地进行测试，并且尽快失败保持已发布版本的可追踪和监控但是，如果我要打破这些，最重要的原则就是保持简单。...如果你不能说明流水线化的原因（是什么、为什么）和过程（如何），你或许是不了解自己的软件过程的。...image.png 在构建过程中进行尽可能多的验证（左移提前），这允许开发新特性的团队可以尽快失败，不断的提高整体的产品质量，并在拉取请求中为代码审核人员提供宝贵证据。你喜欢有大量提交的拉取请求吗？...还是一个带有少数提交和提供了漏洞检查、测试覆盖率、代码质量检查和 Stryker 突变残余等支持的拉取请求？就我个人而言，我投后者的票。

4471 0

代码覆盖率VS测试覆盖率

例如，如果源代码具有一个简单的if...else循环，则如果测试代码可以覆盖这两种情况（即if＆else），则代码覆盖率将为100％。...单元测试有助于提高软件的整体质量，但是关于构成单元测试的测试数量始终存在疑问。测试套件中是否有足够数量的测试方案？我们应该添加更多测试吗？代码覆盖率是所有这些问题的重要衡量标准。...代码覆盖率可用于确保测试过程符合这些标准，并且质量最好的代码进入生产阶段。代码覆盖率越高，发生未检测到的错误的概率越低。在某些组织中，质量团队设置在将软件推向生产阶段之前需要实现的最小代码覆盖量。...尽管还有其他选项，例如Cobertura和EMMA，但由于长时间没有更新，因此不推荐使用这些工具。...PITest：这是一个突变测试框架。它有快、可扩展，并与当前测试和构建工具集成好的优点。传统的测试覆盖率（即行，语句，分支等）仅衡量测试执行的代码。它不会检查测试是否真正能够检测到所执行代码中的错误。

2.4K2 0

谈谈践行 TDD 后的感受

大家好，我是码农小余，今天我们来讨论 TDD。本文纯属个人实践后的感受，若有不确之处，欢迎大佬指导和交流！细心的童鞋可能看出在小余前几篇文章中都有在实践 TDD。...有一个误区：测试覆盖率越高越好，每个接口的覆盖率都达到 100% 岂不完美。...要深入了解需求，必须多方交流；如果不采用 TDD ，那这个情况就会发生在你实现业务中间，此时再去改业务逻辑，自然就晚了。只能在业务逻辑上补充各种判断，几百行的函数自然就炼成了。...TDD 的目标是能让你更有组织地完成需求和让代码不染上坏味道的方法论。最后回到文章开头的问题“TDD 属于编程技术还是规范（意味着 TDD 是一种重要的敏捷需求和敏捷设计技术）？”...小余作为一个前端开发人员，我的看法 TDD 是一种编程技术，它能让我更聚焦代码质量，需要花费更多的精力使用 SOLID 和设计模式去打磨写过的代码，这是当前 TDD 带给我的收益。

4972 0

茹炳晟：你可能对研发效能的度量有误解

如果原来覆盖率只有 60%，增加新的代码之后，改动代码改动之后，覆盖率指标不能往下降，必须大于等于 60%。这似乎是一个好指标，但是在实际操作过程中也会存在问题。...有些工程师会采取一种投机取巧的方法，当新增的代码业务逻辑比较复杂，如果不做单测覆盖率上不去，他会选一些之前没有做单测的，非常简单的 get 和 set 方法写一些单测，让覆盖率不至于降低从而骗过系统。...比如正在读这篇文章的人，我想度量一下你们的能力，给屏幕前的各位排个序，你认为能排出来吗？可能你是搞数据库的，他是搞前端的，另一个人是搞测试的，还有人是搞运维的，怎么度量大家的能力？...在做代码静态质量分析时往往会用 Sonar 对代码的静态质量进行度量，我认为接入 Sonar 的项目数量就是一种虚荣性的指标，因为这个指标能引导出的行为是让更多的项目接入 Sonar。...以搬砖为例，一百块砖是工作量，我去搬一天只能搬一百块，要十天才能搬完，我来干是十个人天。如果我找一个工人来干，他一天可以搬五百块砖，两天搬完，两天是他的人天。那么这个工作量到底是两个人天还是十个人天？

6822 1

Bozz Nuster_Collectivum XXVIII

大家好，又见面了，我是你们的朋友全栈君前言这篇文章主要讲的是在Libprotobuf-mutator与LibFuzzer联合使用的基础上，加上custom mutator功能。...LibFuzzer随机突变生成的。...那么假设b字段只有为”FUZZ”或”PWN”两个字符的时候才能进入下一个程序分支的情况，当然LibFuzzer也可以在代码覆盖率的加持下进入下一个程序分支，但如果你通过逆向的方式已经知道了这个关键点，难道还需要等...LibFuzzer跑出这两个字符串吗？...本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至举报，一经查实，本站将立刻删除。

2841 0

代码审查完整指南来了！

只需进行设置，并为指标设定一个可接受的阈值，例如，在 PR（拉取请求）中的新代码覆盖率不应低于 90%，这种简单的设置能让很多人的工作更轻松。不要自我重复（DRY）。...我可以保证的是，如果能将上述任何事件至少基本自动化，代码审查的平均质量就会大幅提高。这能为审查人员节省时间。如果出现以下情况，就需要检查代码？...并非所有测试都通过测试覆盖率不足/低于公认的百分比代码重复率高于可接受水平代码有异味意外的安全热点通用规则尊重。礼貌待人，尊重作者。请记住，代码审查的参与者是来互相帮助的，他们有着共同的目标。...应用程序会崩溃或向错误跟踪软件发送报告吗？它会向最终用户显示所有堆栈跟踪吗？它是可恢复的失败操作吗?数据会被损坏或碰撞吗？性能。新更改后性能是否受到影响?该代码可能导致内存泄漏？优化有多好?...代码应当激励以某种方式与它现在或未来产生交集的任何人，努力做到同样出色和高质量，甚至更好。值得关注的问题：在合并之后，代码库是否变得更好？其他工程师会对使用这段代码感到兴奋吗？

1921 0

一枚程序员眼中的单元测试

无辜派我并不清楚代码的行为，你叫我怎么测试呢？这些代码命名都能够通过编译啊！个性派测试代码不是我的工作，这不应该由专门的人去做吗？公司请我来是为了写代码，而不是写测试的。...同理派如果我让QA人员没有工作，那么我会觉得很内疚的！仔细推敲这三大派系，甩出几个问题就能让这些借口不攻自破：如果连代码的行为都不清楚，写出来的代码意义何在？通过编译就代表能正常工作吗？...你可以不写测试，但你写的代码不断被QA找出Defect，作为DEV名声信誉何在，难道写出可靠的代码也不是你的职责吗？公司的确不是雇你来写测试的，那公司是顾你来调试bug的吗？...我们编写单元测试也无非是一种价值的取舍，当它给我们带来的价值低于我们付出的成本时，我们就要保持警惕了，比如思考以下两个问题：在追求漂亮的测试覆盖率数字100%的时候，思考一下它真有那么高的价值吗？...在做快速的技术Spike（技术调研），思考一下不写测试是不是能让我更快的试错？我们要理解的是单元测试背后的核心价值，从而做出正确的取舍。我们要做的是编写出有效的单元测试，让它真正地为我们创造价值。

1.2K3 0

如何编写可靠的代码

编写测试失败是浪费时间。为什么失败时您可以编写代码,编写代码不失败或几乎是对吗?重要的是,你写单元测试几乎在同一时间你写代码测试。更重要的是,你写的代码覆盖率,为每一行代码或测试和大部分的排列。...与小谎而不是丑陋的代码,编写高质量的重构代码与整个单词,好名字。例如,如果你有一个像是命名合理的方法,只有一个责任和良好的指标,评论是多余的。规则11:评论撒谎和浪费时间。...如果你发现自己写的评论,你需要一个更好的名字,更好的度量标准,您将获得更好的度量重构和运行单元测试,直到你的指标是符合你的标准。而不是写评论。 4 cs质量代码已经坚持4 cs质量。...抽查还有其他元素我想当我想到干净代码。如果我看代码和皱纹我的鼻子,因为它的气味,和我有一个好鼻子。你可以问一系列的问题在评估代码。这是童子军所写的代码吗?童子军的人把事情比他们发现他们。...总结我当然没有发明所有的这些想法。我不聪明,但我是一个收藏家的知识。业内一些最好的想法自40年代以来写这些东西。如果你想快速的捷径和伟大的读,涵盖了很多材料,阅读由Bob大叔干净代码。

1.4K8 0

一文了解CICD的常见问题

持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。二为什么要做持续集成？...如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。 ⑤部署通过了第二轮测试，当前代码就是一个可以直接部署的版本(artifact)。...构建完成后，需要运行全部测试（单元测试，功能测试，端到端测试）以确保产品质量。如果有一个测试没有通过，那么这次提交的代码不能进入主干；或者这次构建的产物是一个失败的构建品，不能用于发布。...另外，由于持续集成依赖于这些测试去保证产品质量，所以测试的覆盖率要尽可能高。测试覆盖率不够高（包含代码覆盖率和功能覆盖率），就无法充分反映代码的变动是否对系统带来影响。...⑤交付当新提交代码构建出来的产品包，通过了各种各样残酷的测试后，就说明这个包是稳定的，能达到基本交付条件的（前提是自动化测试的覆盖率足够高，当然，有一些极端的情况需要人工测试的另说）。

1.5K3 0

你每天跑这么多自动化用例，能发现BUG吗？

这么多的CASE，花了大量时间和资源去运行，真能发现bug吗？CI做到90%的行覆盖率了，能发现问题吗？测试用例越来越多，删一些，会不会就发现不了问题了？...我们认为：一组Success的测试用例，在其被测对象发生变化后（注入变异后），应该至少有一个失败。如果这组测试用例仍然全部Success，则这组测试用例的有效性不足。...测试覆盖率：只会注入被测试代码覆盖的业务代码，测试覆盖率越高，评估越准确。...“我学习了他们的规则，写了个程序来查错，拿到了第一个满分” “厉害了...” “第二个月就不行了，他们不搞错别字了，搞了一堆语法、语义、中心思想的错误... 我就专心干活儿了” “...”...文章转载自公众号阿里巴巴技术质量，作者义理

2K3 0

实施有效有价值的CI CD流水线实践分享

例如，当构建失败或测试失败时会发生什么？解决此类问题应放在首位，否则将减少CI / CD流程的收益。容器化 -不是强制性的，但是如果部署基于容器，则将降低复杂性。...单元测试覆盖率 —这是CI的关键部分，如果您的测试覆盖率很低，那么在实施CI / CD管道之前就应该先进行处理。自动化程度 –这将决定您是否仅依赖自动化测试，还是要在流程中引入一些手动测试。...Jenkins管道用于驱动构建过程，并且存在与构建过程相关的质量关卡检查。质量门检查应基于对共同开发部门的最低要求。...在我们的上下文中，质量门检查可以验证，构建是否成功单元测试已通过没有违反代码风格的行为新代码的代码覆盖率超过80％ Sonar扫描未报告任何漏洞或代码气味。...持续交付如果质量门已经通过，则开发人员可以提交其拉取请求。集成管理器会将代码合并到通用开发分支。这将启动通用开发分支上的构建过程，如果成功，将继续构建docker映像。

1.3K3 0

前端单元测试那些事

很长一段时间以来，单元测试并不是前端工程师应具备的一项技能，但随着前端工程化的发展，项目日渐复杂化及代码追求高复用性等，促使单元测试愈发重要，决定整个项目质量的关键因素之一 1.单元测试的意义？...大规模代码重构时，能保证重构的正确性保证代码的质量，验证功能完整性 2.主流的前端测试框架了解 2.1 框架对比（主流前三） Karma - 基于Node.js的JavaScript测试执行过程管理工具...- (行为驱动开发) 由外到内的开发方式，从外部定义业务成果，再深入到能实现这些成果，每个成果会转化成为相应的包含验收标准简单来说就是TDD先写测试模块，再写主功能代码，然后能让测试模块通过测试，...我在项目开发使用jest作为单元测试框架，结合vue官方的测试工具vue-util-test 3.1 Jest 安装 npm install --save-dev jest npm install -g...当我们完成单元测试覆盖率达不到100%，不用慌，不用过度追求100%的覆盖率，把核心的功能模块测通即可，当然如果你要设置最低的覆盖率检测，可以在配置中加入如下，如果覆盖率低于你所设置的阈值(80%)，则测试结果失败不通过

1.6K4 1

微服务合并前测试的挑战

涉及所有服务的测试是集成测试吗？还是端到端测试？满足 API 规范的测试是契约测试吗？还是单元测试？...如果集成测试的目的是查看我们更新的服务如何与我们堆栈的其余部分交互，那么我们希望在将代码与生产或预生产环境合并之前运行此测试。适当的集成测试可以帮助尽早发现问题，从而减少缺陷进入生产环境的可能性。...笔记本电脑上的集成测试：模拟的缺点我在科技行业的第一份工作是为在线课堂工具提供支持。在与工程团队的交谈中，我询问了测试覆盖率。团队告诉我，他们有自动测试来模拟虚拟课堂的正常更新操作。...我们不能让开发人员等待数天才能获得测试反馈，因为这些测试很可能失败。在合并之前在真实环境中进行测试我们真正想要的是一个现实的环境，任何开发人员都可以使用，即使是在处理 PR 的早期阶段。...在合并之前共享单个环境 Signadot 是一款工具，可以让任何规模的团队在共享的预发布集群中实现高质量的合并前测试。Signadot 使团队能够共享和维护单个环境，同时在选定的服务上运行测试。

961 0

作为现代开发的基础，为什么 TDD 没有被广泛采用？

TDD 不会失败。如果它引起问题，那是因为你做错了。 TDD 和生产力之间的权衡关系到学习曲线。一旦你到达山顶，那就没有什么权衡的事了。如果你还在谈论权衡，那就表明你可能在山上的什么位置。...我认为，真正的极致主义者并不多，尽管我至少遇到过一个。大多数倡导者在某些方面是温和的，但在另一些方面却是偏激的——我当然也不例外！...我对此深信不疑。测试覆盖率越高，意味着 bug 越少。问题在于，TDD 测试非常受限制。为了使 TDD 周期保持快速，你的测试需要快速编写和运行，而且要能在“一秒之内完成数百次的测试”。...这导致了我对极繁主义的 TDD 最大的不满：它强调局部组织而不是全局组织。如果它能让你不对一个函数进行整体思考，那么它也能让你不对整个组件或组件之间的交互进行整体思考。它能带来更好的设计。...如果人们没有时间去同时学习，他们会选择哪个呢？如果使用合适的 TDD 所花的时间太长了，那么你能在 Shell 脚本和调试实践中学到一些东西吗？人们什么时候才能停下来？

5273 0

开源大咖说07期｜倪辉——ncnn项目导师

非常感谢社区的支持和贡献，我也会继续努力，为大家提供更好的开源产品。您最初接触开源是基于怎样的机缘，有值得分享的趣闻轶事吗？...ncnn通过精简架构设计，减少封装，并建设完备的全平台CI和代码覆盖率测试，提前找到了大量潜在bug，节省了大量时间，在重构或新增功能时都能更加自信。...在LLM-ncnn的困难任务上，因为目前属于行业空白，缺乏技术资料，学生在模型转换的过程中失败率较高，学生定期与导师交流和同步结果后，导师再同步改进转换工具，以便解决转换中的各种问题。...不仅能让学生提高项目实践成功率，还能发现、测试到ncnn本身的问题，帮助项目提升质量。腾讯犀牛鸟开源人才培养计划已举办至第三届，越来越多的学生参与到其中，您对热爱开源的学生们有什么建议呢？...如果有问题，多进技术群交流，学会提问。如果害羞，群里潜水看着群友聊技术，也会有所收获。 #关于开源近年来，国内涌现出来了不少开源软件，您是怎么看待当下的开源现状呢？

7.2K3 0

聊聊测试覆盖率的六大门派

网上有相关教程，这里不细说了，感兴趣的小伙伴可以去搜索「Jacoco测试覆盖率」关键字。...如果我们统计的覆盖率是「有价值」的，那么我们得到的数值才「有价值」。最后，你的自动化脚本执行完成后，从0%变成了多少，那么我认为目前的自动化测试脚本覆盖率就是多少。...如果一个被测函数里面只有一行代码，只要这个函数被调用过了，那么衡量这一行代码质量的所有覆盖率指标都会是 100%，但是这个函数是否真正实现了应该需要实现的功能呢？答案肯定是否定的。...如下图所展示的代码，这是一个解析配置文件的方法，try-catch前面的代码行都是「绿色」的（被测试覆盖的），我们能认为这一片绿色的代码质量是100%没问题吗？当然不能！！！...有了覆盖率数据，并持续监测，利用和改进这个数据，才能让我们的测试工作越做越好。

1.4K1 1

ARTS-20-敏捷开发之LinkedIn的高效代码评审技巧

我真的明白代码变更的目的是什么吗？...整洁的代码和高度测试覆盖率被视为理所当然的，然而有些code review过于关注代码问题，侧重点变成代码怎么修改才能变得更好，这非常不好，大部分人需要积极的反馈才能得到鼓舞和提高积极性，工程师也不例外...当审查员发现代码中好的设计时，应该提出来并给予肯定，这种积极的反馈往往具有传染性，它能让整个团队变得更加有活力我的代码评审评论表达清楚了吗？...当然，注释也可以非常简洁，比如"消除了重复代码"、“增加了测试覆盖率”，这种类型的解释有助于让团队的价值观得以明确我是否需要感谢提交者的努力？...提交者最好列出所有测试过的案例，这样可以让审查者做出更多的测试建议，从而提高质量在review反馈中，我是否太迂腐了？

4082 0

点击加载更多

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭