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

我的同事肖然在 《ThoughtWorks的敏捷开发》一文中介绍了ThoughtWorks敏捷开发的全貌，并在其中简单介绍了ThoughtWorks是怎么做质量内建和敏捷测试的。我作为一名加入ThoughtWorks已经7年的QA，想更为详细的介绍一下这些内容，希望能帮助业界中仍对于敏捷测试有疑虑和困惑的团队建立起自己的敏捷测试体系和实践，从而帮助团队更好的实施敏捷软件开发。在目前的软件开发领域，敏捷依然没有被广为采用，很多人诟病其：开发速度其实并不比传统的开发方式快软件质量得不到保证无法应用于大规模软件开发文档少导致开发出来的软件难以维护……其实大多都是在不了解敏捷开发中质量内建与敏捷...

前言软件安全一直被视为一项神秘而又高级的领域，其中的软件安全开发和安全测试更是很多普通的开发者和测试人员难以企及的工作。但是对于常规的安全开发和安全测试，普通的开发人员和测试人员是可以担任的。而且通过这些常规的安全开发和安全测试，可以预防绝大部分中低级安全漏洞。为什么要做威胁建模软件的安全漏洞主要来自业务需求，业务流程，软件架构，代码开发和第三方依赖包等，并不是仅仅来自某一个单一方面。并且由于某一类角色基本上很难对于业务需求，软件架构，代码细节以及各种基础设施等都很熟悉，因此对于软件系统的全方位的安全漏洞，如果仅仅希望由某几个安全测试人员通过安全测试去发现是非常困难的。所以需要有一种体系...

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