我经历了自动化测试用例设计与开发、测试框架选型、测试框架自行研发、测试基础架构设计以及最新的测试服务化（Test as a Service，TaaS）等一系列技术的变革与发展。
我带领过的测试项目也几乎涵盖了所有种类，包括嵌入式系统测试、金融平台单元测试、平台 SDK 测试、轨道交通安全软件测试、Web Service 测试、大型电商网站 GUI 自动化以及性能全链路压测等。
ABC（AI + Big Data + Cloud）技术
无论是从被测对象本身的复杂性、多样性和规模性来讲，还是从测试技术以及测试基础架构从无到有的发展来讲，都需要测试工程师的知识面、测试设计能力、测试开发能力和测试平台化抽象能力有质的提升。
1、你不仅需要从业务本身出发来对软件进行手工测试验证，还需要掌握完整的自动化测试开发技术来设计自动化测试用例。
2、必须掌握设计开发测试基础架构的关键技术。需要一套完善的高并发测试执行基础架构的支持。
3、必须系统性地思考如何才能将测试数据的准备工具化，服务化，最终实现平台化。
一、测试对象，要思考的
1、一个质量过硬的软件系统，除了显式功能性需求以外，其他的非功能性需求即隐式功能性需求也是极其关键的。
- 显式功能性需求（Functional requirement）的含义从字面上就可以很好地理解，指的是软件本身需要实现的具体功能。
- 非功能性需求（Non-functional requirement）：从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。
2、测试的不可穷尽性：
“穷尽测试”是指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷。
但是，在绝大多数的软件工程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。
其实测试真正目标不是保证全面覆盖，而是追求在有限的时间资源以及人力成本资源的情况下，寻找质量风险和测试成本之间的平衡点。
3、“好的”测试用例：一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
比如：能够捕鱼的网的大小和池塘有没有鱼没关系。
- 一个“好的”测试用例，必须具备以下三个特征。 就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。
- 整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
- 等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
- 等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。**