开发者应掌握的系统性测试方法

Posted 2020-07-01 20:30 +0800 by ZhangJie ‐ 1 min read

如何做好测试，是一门系统性的方法学，而不只是一些零零散散的经验。了解并掌握各种测试的目的、方法是非常有必要的。

最近工作中也在推动测试相关的一些事项，有一点感触，这里先简单总结下常见测试方法的目的，大致包括如下几类。

1. 研发流程中构建环节

• 冒烟测试
  该术语，取自集成电路开发领域，集成电路在测试之前，先要加电检查，如果没有冒烟才能进行后续的测试。冒烟测试并不是测试过程的一个阶段，它是软件构建过程中的一个环节，它包含一些非常基础的测试，如保证编译通过、部分核心用例通过，它随每次构建触发，处于持续集成的一个环节。英文表述为BVT测试，Build Verification Testing，从中更能感受的到。将其理解为测试的一个阶段，是一个巨大的误区。

2. 功能性指标相关测试

• 功能测试
  软件需求说明中对软件需要的功能进行了描述，软件需求分析阶段会对需求说明进行详细分析，并整理出相关的规格说明，包括每个用例的输入、输出等等。功能测试，其实也就是对这里的软件需求规格说明进行测试用例的覆盖，考察的是对各个点、异常路径的把控程度。在实际研发过程中，开发人员一般会先自测通过后，再转给测试团队进行进一步的测试。

• 回归测试
  之前已经测试过的用例，可以沉淀下来，供以后进行回归，已发现软件变更、升级期间是否引入了bug。

• 其他

3. 非功能性指标相关测试

• 性能测试 (how much + how fast)
  对软件的性能指标进行测试，以验证是否达到预期设计的性能要求。在软件设计之初，需求方一般会提出明确的性能要求，如希望支撑N个用户的并发访问请求，希望响应时间能控制在2s以内等等。除了用户提出的性能指标要求，软件设计人员在系统设计的时候，也会对系统中交互的各个子系统、组件之间的性能有一定要求，如各组件通信响应时间在100ms以内等。
  性能测试，是对系统的一个检验，检验是否达到了预期的设计标准。性能测试，通常可以参考系统最大吞吐量时的请求量级、响应时间，来确定系统的最佳运行点，科学合理地部署设备资源来平衡性能和成本。
  性能测试，通常会和负载测试、压力测试等结合起来，以获得系统的最佳运行点、系统最大负载点、系统崩溃点。

• 负载测试 (how much)
  在性能测试请求量基础上进一步增大请求量，直到系统吞吐量不随请求量增加而增加（而是下降）。这个临界点就是最大负载点，表示系统当前已经满负荷运行，继续增大请求量的话，请求处理就会变得更慢。

• 压力测试 (how much)
  在压力测试的基础上，继续增大请求量，以检验系统的耐压能力，请求量的继续增大，意味着会消耗更多的系统资源，如内存、CPU、网卡等等，资源不足肯定会影响到请求处理，服务本身需要具备一定的过载保护能力，如限制入连接数、入请求数等，服务本身如果不够健壮的话，极有可能会导致拒绝响应，如内存不足频繁GC甚至影响到了正常请求处理无法响应。
  系统无法做出响应的点，即为系统崩溃点，请求量继续增加系统将无法做出响应。

• 可用性测试
  系统的可用性，表示系统在任意指定的时间点，系统是否可用，通常有N个9来表示，如系统达到5个9的可用性，表示系统全年只有365x24x3600x(1-0.99999)=315s=5min的不可用时间。
  服务级别协议（service-level agreement，缩写SLA）也称服务等级协议、服务水平协议，是服务提供商与客户之间定义的正式承诺。服务提供商与受服务用户之间具体达成了承诺的服务指标——质量、可用性、责任。SLA最常见的组成部分是以合同约定向客户提供的服务。例如，互联网服务供应商（ISP）和电信公司通常在与客户的合同条款内包含简单定义的服务级别协议。在此事例下，SLA通常定义有平均故障间隔（MTBF）、平均修复时间或平均修复时间（MTTR）；哪一方负责报告错误与支付费用；吞吐量；抖动；或类似的可衡量细节。 通常，服务提供商需要有SLA保证客户权益。

• 稳定性测试
  稳定性测试，是用来验证产品在一定的负载下，是否能够长时间的稳定性运行，其主要目的是验证能力，并在验证过程中发现系统不稳定的因素并进行分析解决。

• 安全测试
  对系统进行安全性相关的测试，如敏感权限、sql注入、csrf供给、api鉴权、有漏洞的不安全组件等等，通常这是一个系统性的工程，需要有专业团队来支撑，并提供安全相关的服务供业务团队接入使用。

软件研发流程中的各个阶段，仔细观察之后你会发现，每一环都与软件最终交付质量息息相关。了解并掌握各个阶段常见的一些系统性测试方法，是非常有必要的。