自动化测试平台化[v1.0.0][自动化测试基本需求]

随着软件发展到不同的阶段对自动化会有不同的测试需求，因此也产生了多种测试类型，然而万变不离其宗，一切皆可自动化

单元测试

单元测试也可以看做是代码层的测试，而但凡成熟的语言都附有单元测试框架，例如Java的Junit和TestNG，例如Python的Unittest和Pytest，在很多场合我都曾强调，单元测试才是自动化的核心，从某种意义上讲具备单元测试框架的语言就都能进行单元测试的自动化执行，而这最小单元可以是一个函数、一个方法、一个类或是一个模块

然而很多公司的研发团队虽然要求单元测试，但很少要求交付单元测试报告的，也有很多公司的单元测试是有自动化测试团队承担的，虽然测试无法穷尽，但测试不同的输入、边界值、非法值、默认值、异常情况等等是基本要求，而这些内容让研发团队自行去做，若非严格的制度限制，又如何能保证高速迭代的环境里真的能达到单元测试目的呢，研发人员的兴趣点绝大多数都在创造力上，他们更喜欢开发新东西，而对质量兴趣不大

功能测试

通常情况下，功能测试是测试团队介入的第一个阶段，开发人员将完成的功能特性写成文档输出给测试团队，测试团队根据这些文档开发设计测试用例，最后执行测试用例，对功能进行验证，理想情况下，如果功能特性文的规范写的足够清晰，测试团队应该在功能开发完成之前就开发完测试用例，甚至可以根据这些用例来编写自动化测试用例

然而尽管大多数情况下，都希望根据质量体系的规范输出详尽的文档，但实操起来确是各种问题：

• 功能文档不规范，协作之间理解不一致，出现偏差，导致设计的用例变成了无效用例
• 需求变更，导致功能特性更新，直接影响原先的测试用例设计
• 新功能不稳定，导致测试用例无法顺利执行

以第三点新功能不稳定为例，过早的执行自动化测试会被不稳定的新功能阻碍住，一个严重的问题可能导致很多用例无法执行或执行失败，最终仍然需要人来干预执行结果的，认为进行判断甚至重复劳动，这就使得自动化不那么自动了，也就是说需要人值守，遇到问题后手动介入解决
测试开发也是软件开发的一个类型，其本身的质量不能和被测系统的质量纠缠到一起，否则会让问题的排查更为复杂

因此，如果非牛逼的研发团队，自动化测试用来辅助测试提升测试效率的角度出发更为实际，将其用于单元测试自动化，接口测试自动化，辅助自动化工具类将成为相当可行的选择，当功能相对稳定后，在全面的实现自动化测试。

再不然，对于功能测试而言非要强行引入自动化测试，那么测试用例本身的构建和修改一定要非常迅速，自动化测试框架需要提供快速构建用例的能力，以此来响应需求的变更，测试代码的健壮性和灵活性要求非常高，从而应对不稳定的功能产生的阻塞，并且还要对灾难性的错误进行测试环境上的自动恢复

回归测试

回归测试时软件开发迭代阶段的一种测试，主要是保障原有的功能没有因为新功能的引入而导致功能回退，在这个阶段自动化测试将得到大量的应用，相对于新功能的不稳定，回归测试的目标是已经发布的或者稳定的功能，相应的测试代码也相对比较稳定，自动化代码也已经经过多轮的完善，执行结果相对也会稳定的多

可用性测试及冒烟测试

可用性测试和冒烟测试都是一种快速验证的过程，测试周期很短，为保证这种快速验证，有些测试团队会针对性的快速开发一些用例，然而这些用例往往又和实际的功能测试验证点重复，因此在大量自动化测试用例中迅速抽取核心的测试用例集，然后将测试用例集集成到整个团队的CI中，将测试用例的执行放在编译的job后作为下游任务，当编译结束后自动执行下游任务，而对于一些持续CD情况中，自动化又需要集成在发布上线前的节点，来保证上线的包不存在基本功能问题

系统测试

系统测试是一个复杂的测试过程，其主要目的是使被测产品的众多功能甚至是产品本身的集合，以系统级别运行时进行行为级别的验证，其测试类型非常多样且复杂，例如：

• 相对于功能测试比较固定的测试环境，系统测试环境比较复杂，配置繁多，不固定，不稳定，在这种情况下，自动化测试需要足够灵活的应对不同的环境配置来执行相同的测试目的
• 测试用例的兼容性要足够强，稳定性足够强，且被测系统的稳定性足够强
• 压力测试和性能测试的需求，自动化测试应能够快速的集成相应的标准性能测试设备或工具
• 客户场景模拟测试，即便再聪明的测试工程师能够设计出种类繁多的测试方案，总有想象不到的场景，客户才是麻烦的最佳制造者，因此很多企业会花一些经历收集客户场景，并加入到系统测试的模拟场景中

可以看出，自动化测试要有足够的弹性来匹配不同的测试场景，而不是通过不同的测试用例来对应不同的场景，同时要具备足够的可扩展性，能够加入不同的第三方工具或者设备来满足更多的测试场景