技术文章

您对您团队的软件测试策略有何看法？你认为它防弹吗？计划在下一卷生产后开始一个愉快轻松的假期吗？

如果您和大多数组织一样，我敢打赌，最后几个问题的答案介于“不”和愤世嫉俗的大笑之间。没关系。我的意思是，这并不理想，但完全可以理解。即使您拥有世界上最复杂的测试实践，您也可能不会感到完全舒服。

这主要是因为测试就像大学期中考试一样。无论你已经做了多少，你总是可以做得更多。你永远不可能为可能发生的事情做好充分、彻底、彻底的准备。

尽管如此，通过将测试准备与良好的测试策略相结合，战略方法可以让您处于更好的位置。让我们看看您当前的测试策略中可能存在的漏洞，以便您可以改进准备工作。

1.负载测试

首先是负载测试。

这属于性能测试的一般标题。

这个想法非常简单。您给软件施加负担（即“负载”）并测量它的响应方式。
为什么要这样做？嗯，较低环境中的许多测试都是关于功能的。该软件是否满足其验收标准并提供预期的行为？为了找出答案，您可以部署您的 Web 应用程序，然后以唯一用户的身份对其执行测试。但这与现实世界相差甚远，现实世界中可能有数千名用户同时使用该应用程序。

输入负载测试。您希望尽力重建生产条件并观察系统的行为方式。这可以让您决定可接受的性能，还可以让您确定性能基准，以便您稍后可以知道系统是否变得缓慢。

2. 探索性测试

接下来，进行不同类型的测试。探索性测试是一种更加开放的测试风格，依赖于测试人员的专业知识。测试人员探索软件，依赖于软件如何工作以及如何与用户交互的知识，以查找在任何其他形式的测试中可能不会出现的问题。

例如，想象一个软件，其中许多用户是从严重依赖键盘快捷键的旧绿屏系统移植而来的。了解这一点后，优秀的探索性测试人员可能会考虑尝试在此应用程序的客户维护屏幕上键入旧应用程序中的“保存”快捷方式。这确实不太可能成为标准测试脚本或自动化套件，但它是一件值得了解和探索的有价值的事情。

测试小组常常过于关注脚本化测试，以至于没有给测试人员进行探索性测试的自由和时间。

3. 压力测试

压力测试是负载测试的近亲。但是，负载测试旨在检查系统在正常情况下的行为方式，而压力测试则在达到极限时对其进行检查。

你为什么想做这个？毕竟，良好的规划理念难道不是应该防止软件被推至极限吗？

嗯，当然，理想情况下。但实际上，没有人能够真正控制这一点，也没有人能够预测无人能预见的停电或流量高峰何时会破坏最周密的计划。因此，重要的是要了解系统的实际限制是什么，当您开始达到限制时会是什么样子，以及它是否以合理的方式处理超额问题。

压力测试提前为您提供了所有这些知识，然后您才必须艰难地学习。

4. 回归测试

回归测试与压力测试是一个非常不同的概念。它属于验证应用程序行为的更“传统”领域。但是，与您正在构建的东西的标准功能测试不同，回归测试是在测试不应该改变的东西时进行的。

例如，假设您添加了一项功能，新用户可以从竞争对手的服务之一自动导入数据。显然，您将在推出此功能之前对其进行测试。但是您是否也测试了用户注册的正常、老式方式？

如果你不这样做，你应该这样做。当你这样做时，你将执行回归测试。

软件很复杂，而且即使在最好的情况下，它也是紧密相关的。这意味着触摸它总是至少会产生一些破坏以前有效的东西的危险。请务必防范这一点。

5. 威胁建模

再次切换话题，我们来谈谈安全性。从最广泛的意义上讲，威胁建模是一种让您推理和测试系统防御能力的练习。

威胁建模首先涉及识别与系统交互的人员、系统边界、访问级别和信息流。然后，您可以据此开始识别潜在的风险源。当管理员离开公司时会发生什么？拥有拇指驱动器的人可以保存敏感数据吗？你问自己各种各样的问题。

一旦您识别出威胁并决定如何缓解它们，就开始执行测试。参考我刚才提到的问题，您可以分别设计用于取消配置用户和禁用拇指驱动器的测试。这种风险缓解成为您测试的一部分。

6. 可用性测试

安全性并不是检查系统的唯一角度。您的用户及其对系统的体验如何？这称为可用性测试。

可用性测试包括将实际用户置于您的软件面前，并观察他们完成任务的容易程度和直观程度。不要将此与软件的功能测试混淆。该软件完全有可能完成技术上预期的任务，但使用起来仍然是一场噩梦。

作为一个令人难忘的示例，想象一下白色页面上有一个带有白色文本和白色背景的白色保存按钮。单击时，该按钮会正确执行保存。但祝你好运找到它。可用性测试将显示用户始终（并且可以理解）无法找到该按钮。

您的测试策略应包括可用性测试，以确保人们确实想要使用它。

7. 单元测试

我将以开发人员为中心的问题结束，即单元测试。单元测试是编写小型自动化测试的实践，这些测试可以在非常精细的粒度级别上测试您的代码。考虑将两个变量传递给 Add() 函数并验证该函数是否返回正确的结果。

开发人员在其开发环境中编写、维护和执行单元测试。假设您有 CI 设置，它们也将在构建机器上执行。在这两种情况下，它们都可以帮助开发人员尽早发现回归缺陷并确保他们理解系统的行为。

单元测试是测试和质量控制实际上是每个人的责任的另一个例子。不进行单元测试的开发团队会给其他人带来过度的压力来填补空缺。因此，通过可靠的单元测试实践，确保在构建软件时发现尽可能多的问题。