十年了，测试变了，我也变了，但总有一些东西未变

最新推荐文章于 2024-03-27 17:52:13 发布

置顶 KerryZhu

最新推荐文章于 2024-03-27 17:52:13 发布

阅读量2.4k

点赞数

分类专栏： 8. IT人生测试 1. 测试的艺术 4. 测试的管理 2. 测试的技术 3. 测试自动化

本文链接：https://blog.csdn.net/KerryZhu/article/details/87976960

版权

8. IT人生同时被 3 个专栏收录

96 篇文章 0 订阅

订阅专栏

4. 测试的管理

58 篇文章 9 订阅

订阅专栏

2. 测试的技术

52 篇文章 12 订阅

订阅专栏

全程软件测试

（十三年前我设计的）

十年前，《全程软件测试》第一版和大家见面了。那是在WebEx七年测试工作之结晶，得到读者的喜欢，曾了解到，有好几家公司把这本书作为测试工程师入职培训教材。十年过去了，软件测试领域发生了很大变化，我自己也发生了很大变化。我虽然离开了WebEx、Cisco，离开了在企业一线的测试工作，来到了同济大学，但我一直没有失去和工业界的联系，而且不再局限一家公司的实践，而是视野更开阔了，和近百家公司的测试工程师有交流，为他们提供测试培训、咨询等服务，包括为中国南车、华为技术有限公司2012实验室研发能力中心等提供较长期的测试技术咨询服务。今天对测试的理解和认识，已经和自己在写本书第一版、第二版时不可同日而语，无论在广度和深度都有较大提升，这也可以从我的公众号《软件质量报道》的几篇文章中窥豹一斑。

从另一面看，软件测试自身也发生了很大变化，不仅仅是提倡测试左移、测试右移（这倒是和我十年前写此书的主要思想——“测试贯穿软件全生命周期”依旧是一致的）以及DevOps的兴起，而且今天大量的专职测试人员消失了，更多的开发人员开始做测试，人们更关注自动化测试和探索式测试，招聘更多的测试开发，手工测试人员越来越没有市场。但是，软件测试存在被引入“歧途”的风险。例如，有些公司号称“赋予了软件测试团队新的价值和使命”，将软件测试部门改名为“工程生产力 (Engineering Productivity，EP)”部门。作为EP，其职责是提高专业服务，给产品部门提供一些专业的建议，这些建议涵盖可靠性、安全、国际化、测试、发布、部署等，EP更重要的职责是负责所有能够提高软件研发效率的工具的开发与维护，这些工具包括业务建模工具、源代码管理系统、代码分析工具、版本构建工具、自动化测试工具、质量管理工具、缺陷管理系统等等。甚至强调，在策略上多开发有助于缺陷预防的工具，而不是仅仅开发传统的测试工具（发现缺陷的工具）。虽然这种做法——“成立EP部门”是一件好事，将工作重点放在“提升工程生产力、降低软件缺陷”之上，强调缺陷预防，这是上策，但EP部门做的事情已不是软件测试的主要工作，和测试工作已相差甚远，这时不能把EP看做是软件测试，EP就是EP，不能将EP和软件测试混为一谈。就像我们有时候容易把测试称为QA（Quality Assurance、质量保证）、把QA当测试，但实际上两者也是有明显的区别，QA强调有好的研发过程产生好的产品，侧重过程定义、过程评审和过程改进，工作重心是预防缺陷，而测试属于质量控制，强调对软件阶段性产品和最终产品的质量检验，工作重心是发现缺陷。虽然测试是QA的重要手段之一，但不等同于QA。

即使测试左移、测试右移，敏捷开发模式、DevOps已经流行，我们讨论软件测试需要在这样背景展开，要将软件测试更好地融入整个软件开发和运维的大环境中，但我们依旧需要清楚软件测试本身要做的工作，区分质量管理、运维管理、研发能力提升等工作。当我们谈到“软件测试”时，是指软件测试的相关工作，如单元测试、集成测试、系统测试等，也不局限于动态测试，也可以包括静态测试——需求评审、设计评审、代码评审和借助工具进行代码静态分析。今天谈软件测试，也不再指专职的测试人员所干的工作，可以由开发人员完成的测试工作，开发人员做测试，也不再局限于单元测试，他们可以做集成测试、系统测试等。

虽然不能说：“一千个测试人员就有一千种说法”，但可以列出很多种：

软件测试是验证软件产品是否满足用户的需求；
软件测试不仅要验证设计和需求、实现和设计的一致性，而且要确认所实现的功能是否真正满足用户的实际需求。
软件测试是为了发现软件缺陷而开展的活动；
软件测试就是不断揭示软件产品的质量风险；
软件测试就是对软件产品质量进行全面评估，提供产品质量信息；

所以，本书一开始就全面阐述对软件测试的不同理解和全程测试思想的解析，揭示软件测试的内涵，帮助读者更好地理解不同的测试目标、测试价值，有利于做好软件测试的策划和执行。这是本书的第一部分，由第1、2章构成：

第1章 360度看测试：一览无余
第2章全程测试：闪光的思想

作为本书的第二部分，讨论完整的一个软件测试生命周期。这部分从测试项目的“准备”开始，侧重讨论测试础设施与TA框架、团队能力等建设，这是后续测试计划、设计和执行的基础，在今天复杂的环境和技术、快速交付的背景下，基础设施必须首先被关注。然后，逐步深入到测试计划、设计、执行。这部分兼顾传统的测试和敏捷模式下的测试，的确不容易，但核心的东西一般都具有很好的生命力，是不容易遭到抛弃，而且不一定要把它们当作不同的测试阶段，而是当作研发过程中要经历的、基本的测试活动。这部分基本的方法就不详细介绍，可以参考我之前写的测试教材，这里重点讨论方法的灵活运用和实践。这部分由第3章至第9章构成。

第3章准备：基础设施与TA框架
第4章准备：组织与团队
第5章项目启动：知己知彼、百战不殆
第6章测试计划：分析与策略
第7章测试设计：架构与用例
第8章测试执行：自动与探索
第9章永不收尾：持续反思、反馈与改进

全程测试思想，不仅局限于功能测试，而且扩展到非功能性测试，包括持续的性能测试与优化、持续的安全性测试与加固，并聚焦到彻底的自动化测试——全程测试建模、全程可视化管理。

第10章全程静态测试：以不变应万变
第11章全程性能测试：持续优化
第12章全程安全性：持续加固
第13章全程建模：彻底自动化
第14章全程可视化：管理无死角

最后，展望未来测试，涉及微服务、云技术、AI技术及其应用等，更具挑战。由于篇幅所限，最后一章只能做到画龙点睛，但也能让你大受启发，知道如何应对挑战，如何设计出云测试、AI测试的解决方案，而且让云计算技术、AI技术更好地为测试服务。即使写了15章、几百页、几十万字，但感觉许多东西还没写出来，慢慢写，可以写1000页、100-200万字没问题。如果很具体的操作步骤都描述出来，再多给几个实例分析，每一章都可以写一本书。毕竟精力有限，把精髓掏出来，至于细枝末节，留给大家自学、自我拓展。IT人，最主要的能力就是学习能力——自学能力，所以像工具如何使用，自己实践是最有效的。专业工程师使用工具不是一件难事，但改变自己的思想、思维方式，倒是挺难的。总之，从思想、流程、方法到最佳实践、自己的思考都呈现出来，剩下的事，就是读者的思考、实践、再思考、再实践。（入群方式：扫码加异步小助手微信号，回复关键词“全程软件测试”入群）

全程软件测试-第3版