对于软件测试策略的分类，有多种类型的分类，比如根据软件系统的类型进行分类（比如基于Web软件系统，桌面软件系统，移动软件系统，嵌入式软件系统等）；或者根据测试类型进行分类（比如端到端测试，性能测试，安全测试，模糊测试等）；或者是根据软件的架构进行分类（比如基于SOA架构的传统企业系统，基于MicroService架构的互联网系统，基于Severless架构的物联网系统等）等。而我将从组织架构和交付方式的角度来对测试策略来进行分类，并一共把测试策略分为四种类型，手工作坊式低质量要求的轻量测试类型，集团式高质量要求的全测试型，特战队式内建质量要求的敏捷（精益）测试类型和流水线式持续交付的全自动化测试类型。

第一种：手工作坊式低质量要求的轻量测试类型-现在

对于很多创业团队或者小型软件公司，他们的第一目标就是快速交付产品给客户或者用户，所以其核心就是快速开发。但他们在测试方面的投入往往都很少，比如一个10人的团队或许只有1个测试人员进行测试，或许没有，所以测试工作会由开发或者管理人员分担一部分。对于这样的团队，测试资源少或者缺乏专业测试人员，其测试策略主要包括：

  • 无或者少自动化测试
  • 开发人员一定要简单测试自己开发出来的功能的主要流程
  • 测试人员或者管理人员一定要对主要的端到端功能进行测试
  • 测试人员或者开发人员应该进行少量非功能性测试，比如稳定性，易用性或者探索性测试等

在这样资源有限的团队中，这样的测试策略能最大可能的在持续开发和交付流程中保证其主要功能不会有大的问题。

第二种：集团式高质量要求的全测试型-现在

大部分的成功的传统软件公司都在使用这样测试类型，比如以前的微软（大家是不是已经发现了Win10的问题比Win7多了不少？因为微软在2015年进行转型而裁掉了大量的测试人员），Intel，国内几个通信软件厂商，各大银行以及NASA等。由于这些大型软件厂商所开发的软件是需要部署到客户方进行使用或者是服务于核心金融类以及航天类等特种行业，其对于质量的要求十分苛刻。一旦出现问题，对于客户方部署的系统进行问题调查或者进行升级都需要大量的成本，甚至有些产品不能升级。而如果金融或者航天等这些特种行业的软件系统出了问题，那么直接带来的就是金钱的损失或者是不可扭转的错误。所以它们追求的是无缺陷的全测试，其测试策略主要包括：

  • 尽可能的对所有功能进行测试，无论是使用自动化或者手动
  • 尽可能的分支条件全覆盖，功能组合全覆盖等各种全覆盖测试
  • 尽可能的做各种极端的非功能测试，比如压力测试，异常测试，模糊测试，安全测试等
  • 尽可能全部满足各种标准，比如ISO/IEC 25010 Software Quality Model（2011）等。

由于这样的测试策略带来的测试成本十分巨大，所以一般只有资源十分丰富的公司才能实施。

第三种：特战队式内建质量要求的敏捷（精益）测试类型-现在

当前其实大部分中型软件企业既不满足于轻量测试，也无法投入足够的资源来进行全测试，所以一般都会自己定义介于这两者之间的测试。由于敏捷(精益)开发方式的出现和普及，敏捷（精益）测试也自然的出现了。它只是介于第一种和第二种之间的众多定制化测试策略的一种，但是它充分使用到敏捷（精益）的价值观和方法论，使得其得到很多互联网公司的青睐，比如Google，Atlassian以及AWS等，都是敏捷（精益）测试实施非常好的公司。因为他们的测试开发比都很低，产品规模大了以后依然保持这较高的发布速度和较好的产品质量。虽然上线之后产品会出现一定的问题，但是也能在短时间修复之后并重新部署（这个是因为他们的主要产品都是基于服务器，能自己完全控制升级的时机和方法），所以对于风险是可控的，并且对于测试的投资回报比是相对最高的。其中《Google软件测试之道》以及Atlassina的宣传视频 How to deliver quality assurance at speed 都对其敏捷（精益）测试做了不少介绍。

理解敏捷（精益）测试的前提是需要有足够的敏捷（精益）的知识，这里就不再赘述了，其测试策略主要包括：

  • 使用TDD的思想将测试分析前移到业务分析阶段，通过对于业务验收条件的分析得到实例化的可测试和可验收的验收条件或者验收场景，包括威胁建模等安全相关的测试分析等
  • 根据自己项目定制化的自动化测试策略和架构尽可能多的实现自动化测试，包括单元测试和功能测试等
  • 功能开发完之后尽快的给相关干系人或用户演示并进行功能和需求确认，快速验收测试
  • 在确认功能和需求以后进行一定量的探索性测试
  • 最终由Stakeholder或者用户进行验收测试

虽然敏捷（精益）测试无法达到全测试的质量高度，但是它可以在成本，进度，质量等各种条件之间找到了一个平衡点，从而尽可能的满足团队对于进度，质量以及成本的要求。

第四种：流水线式持续交付的全自动化测试类型-未来

梦想中的持续交付和全自动化测试是当软件工程师提交一个代码修改之后，在不需要人工介入或者很少介入的情况下完成自动编译，自动测试并自动部署到产品环境。这个是当前许多软件开发者和管理层的梦想。但是由于各种限制，自动化测试系统不够稳定，测试数据无法自动获得和产生（我在多个项目上都遇到过这个问题，而且由于各种原因导致最终都没有解决），自动化测试开发成本高等，导致全自动持续交付成为绝大部分企业几乎是一个无法企及的目标（只有少量的国外企业号称自己做到了全自动化持续交付），最终导致当前所谓的持续交付也需要大量的人工介入。所以为了向梦想中未来的持续交付和全自动化测试迈进，必须对于当前的测试策略进行调整，其主要包括：

  • 充分并完全实施测试前移策略，保证业务流程的正确性
  • 和Stakeholder一起全面的分析并确认功能需求和非功能需求的优先级
  • 提高整个团队软件的意识和技术，尽可能使用开源测试软件（包括收费和免费的开源软件）来定制开发符合自己的稳定的测试系统
  • 对于优先级高和风险大的功能和非功能需求不仅有明确的测试用例，并且需要引入AI来进行测试
  • 对于部署到产品环境之后的系统有精确的功能监控和精准的A/B测试发布系统，用于快速发现线上系统问题。

这种测试类型需要的不仅仅某团队的努力，而是需要整个软件行业的技术和思想的进步，比如测试工具，技术设施，软件开发的管理方式与理念等等，不然只是空中楼阁，可望而不可求。

img

对于这四种类型的测试策略，对于某个团队来讲并不是谁一定比谁更好，因为每个团队开发软件的目标不一样，所以只有谁更适合。如果团队的目的是快速交付一个产品，那么第一种和第三种更适合，或者自定义一种介于第一种和第二种之间的测试策略；而如果产品已经十分成功，而且软件的质量对于团队重于泰山，那么第二种类型更适合；或者产品不仅已经十分成功，而且团队对于软件交付速度和质量都有着更高的追求，那么团队就需要向着持续交付式的全自动化测试类型不断前进。其路漫漫兮，吾将上下而求索。

标签: none