1、分布式文件系统测试方法
（1）功能性测试（手动＋自动化）
文件系统功能主要涉及系统实现的POSIX API，包括文件读取与访问控制、元数据操作、锁操作等功能与API
（2）非功能性测试
（2.1）数据一致性测试（手动＋自动化）
文件系统中的数据与从外部写入前的数据保持一致，即写入数据与读出数据始终是一致的。数据一致性，能够表明文件系统可以保证数据的完整性，不会导致数据丢失或数据错误，这是文件系统最基本的功能。
（2.2）POSIX语义兼容性测试（自动化）
POSIX (Portable Operating System Interface)，表示可移植操作系统接口；
（2.4）可用性测试（手动）
高可用性已经是分布文件系统不可或缺的特性之一，从而保证数据应用业务的连续性。
（2.5）扩展性测试（手动）
文件系统扩展性测试，主要包括测试系统的弹性扩展能力（扩展与回缩两方面），以及扩展系统带来的性能影响，验证是否具有线性扩展能力。这部分测试也是以手动方式进行。
（2.7）压力测试（自动化）
分布式文件系统的负载能力总是存在上限的，当系统过载时，系统就有可能出现性能下降、功能异常、拒绝访问等问题。
（2.8）性能测试（自动化）
性能是评估一个分布式文件系统的最为关键的维度，根据文件系统在不同场景下的性能表现，可以判断文件系统是否适合特定的应用场景，并为系统性能调优提供依据。
三：测试用例类型
分布式存储产品的特点：
1 存储海量的数据，不同类型
2 集群中机器的损坏是常态
3 海量的用户访问
所以在设计测试用的时候根据分布式存储产品的特点设计了如下的测试用例：
数据兼容性测试：
代码一直在变，会有不同的数据类型出现，如何保证数据兼容性？
一般来说都需要考虑新旧版本写入数据的兼容性。
实践中可以每天模拟用户写入不同大小，不同类型的文件，在每次升级之前预发布，来校验这些数据。以做到数据兼容测试。
开发也会在UT中包含这部分内容。只不过是在不同的级别来测试这一点。
数据完整性测试：
作为分布式存储产品，用户的数据是不能丢的。这点是做存储的底裤。
在实践中会每天扫描新增的数据以检查数据的完整性。
定期还会做全量数据扫描。
性能测试：
每次版本发布的时候，我们需要知道这个版本和上一个版本相比，性能是否有提升。这个也是用户比较能直观感受到的。
性能测试和测试的客户端，使用的代码，请求的类型，集群数据的多少都有关系。实践中是选定差不多的测试环境，进行对比，以减少多个测试变量对性能结果带来的影响。
压力测试：
模拟网络，磁盘，CPU等资源消耗完，测试系统的表现能力。对系统设定报警阈值。一旦超过这个能力，系统开始报警。也可以供运维同学参考集群的负载能力。
稳定性测试
测试系统在长期运行下，观察内存，网络，CPU资源消耗的情况。常见的问题就是内存泄露，如果每次泄露一点，短时间测试是无法发现问题的。所以一般要求系统能连续运行7天以上。
安全测试
慢连接攻击测试
大并发模拟攻击测试
其他攻击模拟
系统健壮性测试
也指Failover测试，实践中也是分层的思想
先分模块：
模拟系统各个模块失效的情况。例如进程重启，进程不再启动等。
再分机器:
对于分布式系统来说，机器资源出现状况简直是一定的，例如CPU不够用，内存超了，网卡无法使用，磁盘损坏，机器断电等情况。自动化测试可以通过软件来模拟这些情况。
在实际上线的时候，还是需要做一些模拟故障演练。例如：一台或者多台机器出现断电。
再分集群:
整个集群掉电后重启，数据是否丢失。
不可服务的时间，重启后多久恢复服务。
集群中交换机不可用。这些测试还得依赖于运维工程师的合作。
七：产品质量的保障
如何保障产品发布的质量是一个很大的话题。总结自己在产品中的方法有：
1 静态代码扫描
2 测试覆盖率
3 代码及测试评审
4 执行好测试
5 灰度发布
6 发布总结，增加测试覆盖，形成良好的闭环。
在具体的测试实践中，还是碰到了很多问题。
1 测试用例不稳定
由于测试不稳定，导致测试经常失败。大家都失败有时候都熟视无睹了。典型的破窗原理。
2 测试环境的问题
单一的环境无法满足几个层级的测试需求，但测试资源有时候是有限的。需要做好规划。
3 测试效率的问题
由于产品功能的不断叠加，回归的集合原来越庞大，越来越复杂。回归一次的时间变得越来越长。需要重构测试用例。
4 多个版本同时发布的问题
由于产品在发布的时候可能会有多个分支在回归，比如正在开发的代码分支，线上需要修复的代码分支。但回归效率不高，只能排队等待。还是需要提高测试效率。减少回归的时间
5 测试调查问题困难
测试用例的要求没有开发代码要求高，测试框架中对日志支持不够友好，都造成了调查问题困难。需要改进日志。
我们还是需要做很多工作，让测试更快，更有效地发生。
网友评论