今天想跟大家分享一个案例，关于一个测试场景引发的测试要点思考。

废话不多说，上菜！

情况介绍

某天，开发同事提交了一个功能优化单，大概情况就是：为了节省内存使用，开启了一个配置，配置项有自动切换、不切换和固定切换三种模式。当达到一定阈值阀门时，会将在内存临时存储的变量写入MySQL，使用完后即删。

我们假设配置模式是auto、no、yes。

这个功能优化的原因在于：存储的变量在大数据的情况下会占用很大的临时内存，造成内存浪费。而存入mysql后，内存使用会大大下降

那么，针对这样的一个优化功能，我们可以怎么设计测试要点呢？或者说需要测试哪些呢？

一起看看

暂不说性能测试，我们单纯讨论下功能测试要点。

我想大家肯定会说：三个不同配置一定要测！这是必然的，我们得至少证明配置生效了不是。

那么我们先来看一看。

不同配置项测试

存在三个配置项auto、no、yes，那么我们依次测试。

首先测试no，不切换

该模式下，临时变量（假设为monitor）会存入内存。

因为无法检测区分monitor变量占用的内存变化（除非从代码层加入临时打印），所以对于no配置的测试我们重点在于监控日志打印（有该变量的输出），以及已有功能回归（确保不会因为新配置的引入导致故障的产生）。

总结：本次测试要点为已有功能的回归测试。

测试yes，切换

该模式下，临时变量monitor会存入mysql的某个表，且在使用完成后，该变量会清除。

对于此，我们能够很方便的从mysql观测到。因此我们的重点除了已有功能的回归测试外，还有变量存数据库，存入变量值的正确性，以及及时清除。

那么如何确定变量值的正确性？可以通过构造特定数据，产生期望的monitor值，然后观察是否存入了mysql。

那么如何确保及时清楚？这里可以分为正常情况下的清除（比如调用程序使用完成后清除）和非正常情况下的清除（比如调用程序瘫痪，无法消费该monitor变量，那么是否能在一定时间内清除）。

除此之外，我们还容易遗漏的一个测试要点：在并发的情况下，写入mysql的变量值有没有可能错乱？由此导致调用程序消费出错以及不能及时清除。

总结：本次测试要点为已有功能的回归测试，存入变量值的正确性，变量存数据库和及时清除，以及在并发情况下的测试。

测试auto，自动切换

在上两个配置项测试的基础上，我们主要需要测试阈值阀门有效性。也就是当某个变量（比如本例中的num）到达一定值时，是否能打开自动切换功能。

但在此，值得主意的一点是：我们的阈值往往会设置的比较大，而测试环境可能达不到这样的阈值，那么怎么测试？

可以采取调下阈值。比如原有配置num>1000开启自动切换，我们可以配置阈值num>100时开启自动切换，以此验证该功能正确性。

除此之外呢，我们还需要把no和yes的测试要点回归一下。

总结：本次测试要点为已有功能的回归测试，存入变量值的正确性，变量存数据库和及时清除，以及在并发情况下的测试，还有阈值上下边界测试。

除此之外呢？还有没有？

当然有！默认配置以及无配置测试呢？

默认配置测试

在本例中，默认配置是auto，那么在测auto的时候也就把默认配置测了。那对于有的配置，假如默认配置为空呢？

要知道对于空的处理很容易产生空指针之类的故障。所以，我们一定不要忘记测试默认配置。

上面所说的还都算是中规中矩比较正常的测试，那么，我们来当个“反叛者”，做做破坏性测试。

探索性破坏测试

回忆一下，这个案例中涉及了哪些程序或组件？mysql，产生monitor的程序A，以及调用写入mysql的monitor变量的程序B。

发出邪恶的笑声吧~

停止或重启mysql

在A程序正常产生monitor的过程中，使用auto或yes配置，将mysql停止或重启，试试能不能正常写入，或者看看A程序是否检测到了异常，并正确处理了异常。

停止或重启调用写入mysql的monitor变量的程序B

monitor变量写入mysql后，将B程序停止或重启，看看变量能否正常消费或及时清除。

产生monitor的程序A

有人可能会问：我听它干嘛？你不想看看要是monitor值有很多个时，写入mysql写了一半，A程序停止或重启了是个什么样的情况？就比如A的上游程序是否会有异常打印或者重试策略？

那么还有吗？别忘了我们为什么优化。

优化指标对比

因为程序运行过程中，很难区分具体变量的内存占用，但如果我们想要测试，可以试试求助开发人员，帮助我们打印或监控下内存的消耗。

因为要是有人声称：我的改动可以节省10倍内存，你会不会怀疑？

总结

我们把上面分析出的测试要点先总结下吧。

说了这些，你觉得还有什么吗？别害羞，一起过来讨论讨论。

 

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取