对于测试环境配置覆盖的探讨

对于测试环境配置覆盖的探讨...



测试覆盖率一直是测试中的一个焦点问题，本篇文章就是通过我在 Hackathon 的一个 idea 来探讨一下我们对于测试环境配置的覆盖率。

大家对 Automatos 针对 VNXe 的 configuration capture and restore 脚本应该很熟悉，这个脚本会抓取 array 上所有的配置信息并存在一个文件里，一般我们是用这个文件对 array 做 configuration restore 以用来节约 array 配置时间，其实这个文件本身也给出了很多信息。我抓取了40个自动化 case 执行完以后的 array 的配置文件，并且解析了文件内容分类存储在数据库中，然后通过各个维度显示了一下这40个 array 配置文件能告诉我们什么。

首先，总览：



这是对于40个 case，也就是40个 array 的配置文件通过内容解析得出的总体分类图，从这张图上我们可以看到，LunGroup 和 Standalone Lun 的数量远远大过 File System 的数量，少数的 case 配置了 NTP server，下面我们来看看一些具体的数据。

Storage Pool:



通过图表我们可以看到，大部分 Storage Pool 都使用了 FAST VP，并且以RAID 5 作为主要的 RAID Group。

NAS Server:



只有10%不到的 NAS Server enable 了 Multiprotocal，没有一个 NAS Server 开启了 FTP，IPv6 的配置只有6%，所有67个 NAS Server 里面只有17个配置了 LDAP，10个配置了 NIS 作为naming server。

File System:



几乎一半的 File System 是 NFS，30%的 CIFS，Multiprotocal 和 VMFS 数量很少。

Host：



Windows, Linux, ESX 是我们最主要使用的3种 OS，iSCSI 是主要使用的 connection，没有 host 以 FCoE 的方式被连接。

从上面的40个 case 的 array 配置文件数据我们可以看出，有一些配置在我们测试中较少的被覆盖，甚至没有被覆盖，如果能有更大的数据量（array 配置文件），以及更具体的维度，通过这些数据的分析可能会发现更多的在测试环境配置上的遗漏点。更远一些，通过分析大量 Failed case 的 array 配置文件，我们可能会发现一些我们系统的薄弱点，我们可以通过这些数据做更针对性的测试用例的设计。

    关注 MRQE