大家好，我是陈哥，今天聊聊禅道的代码提交规范~背景在《还不知道这个原则的程序员，要小心了》的文章中，我提到了禅道的代码提交规范。简单来说，我们将工具融入到禅道团队的日常代码提交过程中，利用工具对流程、行为进行规范和约束。接下来，我将从编码规范、测试规范等方面，和大家简单分享一下禅道团队的代码提交规范。为了方便大家了解和学习，大家可以发送【代码提交规范】，免费领取禅道团队的代码提交规范。
一位读者在看过我的《理解这八大优势，才算精通单元测试》后，问我：知道单元测试有好处，但实在没空写。看完文章后又想重新落实一下，有没有啥写好单元测试的技巧？这位读者绝对不是第一个和我抱怨单元测试的人。这很好理解，中国互联网公司太多太卷，想要抢夺市场就要推出不同功能，而这些压力一部分落在了程序员身上，拼命赶需求。单元测试这种费力不讨好的事情，自然而然就没有人做。就我多年的经验来看，写单元测试其实不
在准备将软件上线到生产环境之前需要进行测试。随着软件测试方式日趋成熟，软件开发团队的测试也在取代大量手动测试，逐渐实现自动化测试。通过自动化测试，开发团队可以在短短几分钟内就了解到软件是否存在问题，而不需要等待几天的时间。自动化测试大大地缩短了反馈周期，与敏捷开发、持续集成和DevOps文化密切相关。本文将分为上、下篇来探讨如何构建一个高响应、可靠并且可维护的测试组合，无论是针对微服务架构、移动
作为开发人员，我们应该遵守这样一句话：“质量不是来自检查，而是来自生产过程的改进。”——爱德华·戴明 “测试即代码。”太多的组织将任何未编码的东西视为一次性的。很明显，测试是必不可少的，但我们一次又一次地发现，团队将测试自动化和相关材料视为二等公民。测试是用户行为的文档，与产品组织产生的需求密不可分，并在虚拟层面与用于创建功能的代码相连。 如果它提供了价值，就应该对它进行版本化、维护、照顾和尊重，
技术性债务在DevOps到底意味着什么？从本质上讲，这是小的开发缺陷的积累，需要不断地返工。它可能由多种原因引起，例如快速交付新功能的压力，这可能会导致团队不得不牺牲代码的整洁和完善。但这些不完整的小代码，如经济上的债务一样，随着时间的推移会产生“利息”，在软件工程里就表现为修改的挑战或添加新功能的困难。 一、技术债务的原因技术债务的主要原因之一是组织的开发方和业务方之间的脱节。开发团队经常会感到
在《TDD、BDD、ATDD都是什么、有什么区别？（上）》一文中，探讨了探讨TDD、BDD和ATDD的概念。虽然TDD、BDD和ATDD都是软件开发中使用的测试方法，但它们在方法和重点上有所不同。TDD、BDD和ATDD之间的主要区别在于关注点、抽象层级和协作。1、关注点TDD侧重于测试代码并确保它满足需求。BDD关注软件的行为，并确保它满足业务需求。ATDD关注于验收标准，并确保软件满足业务
tynam —-倔强的测试人 几年前，当我第一次看到《海盗派测试分析:MFQ&PPDCS》这本书的时候，便带给我一种非常亲切的感觉，书中的部分思想和我当时的认知非常切合。那几年，我一直从事软件测试工作，按照自己的想法完成着测试任务，与接受的测试理论存在非常大的差异，一度怀疑自己是否走偏，但感觉又应该是自己走的那样，直至了解到海盗派Tester，心中顿有方向，有理论支持。至今，还在一如既往的
作者：王凌云｜QE_LAB 背景：最早接触和了解无障碍测试是在去年参加公司的一项“无障碍测试公益培训” 的助教工作，这个活动是计划为“有人”基金会的视障人群展开一期“无障碍测试公益培训”活动。后来通过公司的Accessibility Community上的文章对无障碍测试有了更进一步的了解。目前所在的项目中正在做有关Mobile端的Accessibility的测试和相关的开发改进工作，借此做一个总
作者：赵泽鑫｜QE-LAB浅谈DataDrivenTestingWhatisDataDrivenTesting数据驱动测试（Data-driventest）是一种软件测试方法，其中测试数据以表格或电子表格格式存储。数据驱动测试允许测试人员输入一个单一的测试脚本，可以对表格中的所有测试数据执行测试，并期望在同一表格中的测试输出。它也被称为表驱动测试或参数化测试。尤其是针对于自动化
作者：赵泽鑫，张海云，冯曌 ｜ QE-LAB 写在前面：该项目是某企业CRM+ERP系统 0 - 1 的数字化转型中最重要的一个产品之一，需要拉通上下游30+系统，有上百名的同事与我们共同在一线战斗。我们将项目上的实践，遇到的问题，以及我们的辛酸苦辣落笔为大家眼前这些朴实的文字，希望能够给大家带来在大规模项目中做敏捷测试的不一样体验，感受大规模0到1数字化转型中的QA的机遇与挑战。由于篇幅很长，
+求关注
