前言当前业界对于软件测试和质量相关的讨论非常多，各种不同的声音也层出不穷，比如去测试人员、测试人员无用论、测试技术化、测试工程化、测试与质量赋能、敏捷测试、持续测试、全程自动化测试等等。可见测试工作和专业的测试人员已经处于了一个很大的漩涡里面。但是只要一个项目追求高质量，那么它一定需要实施大量系统化的专业的测试和质量工作。而这些大量系统化的测试与质量工作一定需要拥有专业知识的人员来做。虽然一些互联网公司或者某些项目号称可以在没有专业QA的情况下成功交付了，但是他们是基于一定的前提条件的，比如项目规模不大，团队的BA和Dev也拥有专业的测试与质量能力，他们也愿意做测试与质量相关的工作，并且...

最近随着敏捷测试在中国测试届风起云涌，其中包括不少公开课以及各种文章和在线分享，越来越多的人开始关注敏捷测试和敏捷开发。不过仍然有不少人对敏捷测试和敏捷开发提出了质疑，其中最典型的就是：敏捷测试和敏捷开发只适合小型项目玩一下，不适合大项目，因为一般大型项目质量要求非常高，敏捷做不到高质量敏捷开发没有完备的文档，难以维护，质量难以维系敏捷测试没有完整的测试用例，很难进行全回归测试，无法保证质量理论上同样的团队在单位时间内获得的质量，瀑布要比敏捷高。但是这里有几个前提常常被人忽略，那就是软件需求必须一开始就能确定并且能分析和设计得十分清楚，其次开发过程中不能有大的变动，最后不需要频繁发布。如...

起因在前两篇《TDD之让我们再聊聊TDD》 和《 TDD之让我们再聊聊TDD(续)》 中我们聊了很多TDD理论和实践相关的疑惑，其中包括TDD的分类，选择以及其实施步骤。最近TDD相关的培训和讨论也越来越多，还提出了很多独特的观点，比如：软件没有做好就是因为TDD没有做好TDD没有做好所以软件也做不好学好TDD靠多多练习就可以了，不用学习其理论知识开发应该自己理解业务，并提炼测试（需求）点来实施TDD开发只要做好TDD，就不需要其他人测试了等等对于这些观点我有不同的看法，比如我在第一篇讨论中就提到，TDD不是银弹，所以软件没有做好的原因是很多的，也不是靠TDD做好了就一定能做好。其次学习...

最近十到二十年，软件业迎来了一个超高速发展期，其中软件测试相对于软件开发进展稍微缓慢一点，不过也出现了不少新的思想、技术以及趋势。基于现阶段在客户现场、业界大会、与专家的讨论以及从网上看到的相关内容，我尝试在本篇文章中总结出几个测试新趋势：AI+测试利用AI（深度学习等）系统来辅助测试工作绝对是最近几年最为热门的一个测试趋势，其中包括测试用例，测试数据和测试代码的自动生成、大规模测试结果分析、自动化探索性测试、缺陷定位等，美国已经有多个公司推出了商用的AI测试工具。在朱少民老师的公众号“软件质量报道”中就有一篇名为《未来已来，人工智能测试势不可挡：介绍9款AI测试工具》的文章，里面介绍了...

今天我们来谈谈移动测试的测试策略与测试架构。首先我们将移动应用的范围限定在智能移动操作系统（比如Android、iOS、WinPhone等）上，包括手机应用，智能设备应用等。智能手机和智能设备的普及需要大量的应用来支撑。随着应用数量的增多，业务复杂度的提高，移动应用也越来越需要各种测试来保证应用以及设备本身的正确和稳定运行。因此移动应用测试的需求也越来越大，大量关于移动应用测试的书籍应运而生，比如《Android移动性能实战》，《腾讯iOS测试实践》、《移动APP性能评测与优化》、《深入理解Android自动化测试》、《精通移动App测试实战：技术、工具和案例》等。这些书都介绍了大量的移...

自动化测试一直是敏捷开发和敏捷测试的重要基石，也是DevOps和CI/CD必不可少的组成部分。由于不同项目的测试需求不同，以及各种不同的限制，导致需要的自动化测试框架和工具也不同。比如很多金融和能源类的企业就倾向于选择收费的企业级自动化测试框架或者工具，而新型互联网企业则倾向于开源免费的自动化测试框架或者工具，或者基于它们进行二次定制开发，或者重新开发适合自己的自动化测试框架、工具或者平台。我之前写过一篇文章——《自动化测试框架Cucumber和RobotFramework的实战对比》仅仅针对两种自动化测试框架进行了讨论，却引发了大量的讨论，由此可见业界对于自动化测试框架存在很多不同的理...

去年中旬两位Google工程师在《美国计算机学会通讯》发表了一篇论文“Why Google Stores Billions of Lines of Code in a Single Repository”，它介绍了谷歌为什么采用一个定制的大型单体中心代码库，并且在多个大会上分享了这个话题。InfoQ中文网站也发表了一篇较为客观的文章”Google为什么要把数十亿行代码放到一个库中？”来评论Google这种代码管理方法 ，其中总结了Google宣称的这种唯一中心库代码管理方式的优势，包括：统一版本控制广泛地代码共享和重用简化依赖管理，避免菱形依赖原子修改大规模重构跨团队协作灵活的团队边界和...

介绍这个话题，有两个原因：从开始工作到现在，我经历过没有代码版本管理、代码集中式管理，以及现在的分布式管理，我深刻体会到它在软件开发过程中的重要性；我在工作中遇到的很多客户都存在对于代码版本管理的各种问题、困惑和不同的需求。所以我希望将我在这个方面的经验分享给更多人，希望能帮助更多的团队解决在代码版本控制方面的问题和疑惑。一，代码版本管理系统的历史代码版本管理系统大致可以分为三个时代：第一代，本地式这代主要的特点提供本地代码版本控制，比如SCCS(1972)、 PVCS(1985)等。这代主要实现了基本的代码版本管理，但缺点是无法让多人同时对一个版本库进行修改。这个也和当时软件规模不够大...

对于软件测试策略的分类，有多种类型的分类，比如根据软件系统的类型进行分类（比如基于Web软件系统，桌面软件系统，移动软件系统，嵌入式软件系统等）；或者根据测试类型进行分类（比如端到端测试，性能测试，安全测试，模糊测试等）；或者是根据软件的架构进行分类（比如基于SOA架构的传统企业系统，基于MicroService架构的互联网系统，基于Severless架构的物联网系统等）等。而我将从组织架构和交付方式的角度来对测试策略来进行分类，并一共把测试策略分为四种类型，手工作坊式低质量要求的轻量测试类型，集团式高质量要求的全测试型，特战队式内建质量要求的敏捷（精益）测试类型和流水线式持续交付的全自...

"测试自动化"与"自动化测试"通俗的理解上都是一个意思，我并不想咬文嚼字，但是为了说明两种自动化测试策略，我暂时用这两个名称来区分它们，就像敏捷开发中的”做正确的事情”和”正确的做事情”一样用于区分。第一种: 测试自动化，为了测试而让测试自动化执行这种策略主要是指团队已经拥有了自己的各种类型的手动测试，比如说手动验收测试，手动端到端测试，手动探索性测试，手动压力测试，手动安全测试等等。然后当团队已经无法承受手动测试所带来的时间和人力成本的时候，就会思考如何减少时间和人力成本，而自动化执行这些已有的测试，就能有效的减少手动测试的成本。由于时间要求快以及测试人员的能力不足等，所以这种情况下的...