介绍在黑客攻击软件系统出现之前，软件行业没有安全测试这个概念。但是在兴趣和金钱等利益的驱使下，一部分人开始通过各种技术手段对软件进行攻击，从而获得非法信息，并从中获利，然后这部分人被称之为黑帽（注：黑帽用来比喻进行网络入侵、使用计算机病毒等阴谋诡计的恶意攻击者，他可能是拥有黑客水平的一些专业人士，也可以是只会用一些攻击工具和脚本的一些孩子。而黑客这个词本身是指十分热心钻研计算机技术，水平高超，在一般的程序员眼里差不多是无所不能的资深专家，所以这里不用黑客来描述坏人）。为了阻止黑帽者对软件系统的攻击，反制措施一般有两种。第一种就是在软件系统前面加设一层护盾，对于WEB服务器可以是WAF（W...

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

性能测试对于大部分测试人员都是一个神秘地带，因为在很多公司，性能测试都是由一个性能测试团队来做，所以普通测试人员没有机会接触到真实的性能测试，因而很难学习到很多新的测试实践知识。市面上现在有非常多关于性能测试的书籍，其中不少书籍都能够系统地介绍性能测试。今天我想通过另一种方式来介绍性能测试，那就是通过提出一些关于性能测试的问题，然后针对问题进行思考。希望通过不一样的方式让读者以另外一种视角来思考和学习性能测试实践。1、如何在敏捷开发中做性能测试？敏捷开发，由于其持续集成、快速反馈等特点，需要性能测试工具支持轻量化、集成CI服务器、全代码化等特性，所以传统的性能测试工具比如JMeter和L...

今天我们来谈谈移动测试的测试策略与测试架构。首先我们将移动应用的范围限定在智能移动操作系统（比如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架构的物联网系统等）等。而我将从组织架构和交付方式的角度来对测试策略来进行分类，并一共把测试策略分为四种类型，手工作坊式低质量要求的轻量测试类型，集团式高质量要求的全测试型，特战队式内建质量要求的敏捷（精益）测试类型和流水线式持续交付的全自...

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

在上一篇文章里面，通过对DHH的文章以及DHH和Kent Beck等讨论的分析，我阐述了对TDD的理解和分类，现在来继续聊聊TDD的实施和分层。现在还有非常多的软件工程师在质疑TDD的可行性，比如太难不会、成本太高无法推动、意义不是很大等，但是他们却一直都在做着TDD，只不过没有意识到而已，这便是“不识庐山真面目，只缘身在此山中”。TDD的实施一般分为思维层面和技术层面。一般来说，思维层面上的实施成本较低、容易接受，但是缺点很多，比如难以传递、难以持续获得快速反馈等；而技术层面上的实施一般成本较高、不容易被人接受，但是优点更多，比如可以获得快速反馈、更容易传递和协作等。而现实世界中TDD...