对于软件测试的一点思考

*****************************

日常工作原因，闲了，过来补充下自己的认识和思路

*****************************

最近针对当前业务的软件测试策略、测试方案、测试架构重新在审视和思考，发现我们很多测试都是无效投入；在说我们自己测试之前，我们先来看看linux操作系统作为软件工程界最大的一个系统软件工程，业界针对这个巨无霸的主流测试方式和测试技术，之后我们再返回来看看我们自己单点模块级的软件测试，会不会有些启示p>

1 、code review；

2、编译阶段的make check（代码级的LLT）；

***************************************LLT测试技术简介**************************************************

未开始，待续……

之后各个发行版操作系统厂家自己做软件集成后，也会再做集成验证，这里我理解各厂家也至少有两层质量看护：

1、编译阶段的make check（依赖源码中的test中的UT测试case）

2、版本滚动发布前的SIT集成验证（偏黑盒性质的功能、可靠性验证）

这里如果某家公司要自己做独立的发行版操作系统，我理解基于CentOS模式是最快的捷径；

因为按照上面的质量看护逻辑，Fedora自己会做一轮 –> Redhat也会再继续至少做一轮SIT测试 –> CentOS 二次编译时还会再次做一轮make check；

所以第三方发行版完全可以基于CentOS fork出来一个分支，起码基础质量是由保证的，之后基于自己的具体业务场景做深度测试；

***************************************Fuzz测试技术简介**************************************************

1、模块级的fuzz测试（灰盒测试技术）（这个是目前安全界和google、redhat等大厂主力公关的方向）

1.1 OSS-Fuzz是google构建并主推的，免费开源

1.2 Springfield是Microsoft构建并主推的，不开源

1.3 syzkaller 是google开发的内核fuzz测试工具，免费开源

1.4 trinity

1.5 IoFuzzer

1.6 KAFL

https://www.jianshu.com/p/fa232a6e2950

https://github.com/RUB-SysSec/kAFL

1.7 AFL

1.8 AFLGO

https://github.com/aflgo/aflgo/issues

1.9 API Sanity

https://blog.csdn.net/wcventure/article/details/82085251 （关于Fuzz相关技术介绍，这里也贴上大神们的总结贴）

***************************************SAN测试技术简介**************************************************

2、模块级的地址消毒技术AddressSanitizer（灰盒测试技术）【KASAN-ASAN-TSAN-KTSAN-UBSAN-MSAN】

【地址消毒简介】：简单讲就是可以检测到内存错误的检测技术（内存越界访问、内存溢出），而且是可以比较精确的找到越界错误以及释放后使用错误，ASAN对于C/C++这类语言写的用户态程序来说，是一个比较好的内存错误检测工具；内核态KASAN，用户态ASAN技术；

内核态KASAN技术简介：

动态检测内存错误的工具，他为use-after-free和out-of-bounds问题提供了一个快速和全面的检测及解决方案，KASAN使用编译是检测每个内存访问（linux 4.4以上版本，GCC 4.92以上版本）

编译配置：

KASAN技术高版本的内核默认是已经集成进来了，只需要在内核编译时打开相应的编译选项

CONFIG_SLUB_DEBUG=y

CONFIG_KASAN=y

KASAN的版本的boot.img是要比正常的img大一倍左右的，运行效率也是要低50%左右的。

KASAN检测原理：

在代码运行时，每一次memory access都会检测对应的showdow_ memory的是是否valid，1 Byte shawdow memory对应8 Bytes的application memory，用一个shadow字节就可以判断那对应的8个内存字节是否是全部可访问的，部分可访问，已经被释放或者他们是一个redzone区域；

使用指导：简单讲就是看内核日志中是否包含KASAN检查出来的bugs信息，下面就简单写下日志中的关键信息

BUG:KASAN: slab-out-of-bounds in memcpy +xxx at addr fffxxxx

 BUG:kmoalloc-64(Tainted: G B W):kasan: bad access detected

Call trace: #打印出来问题现场的调用栈

xxx

Memory state around the buggy address:  #可以直观的看出被非法访问区域的访问权限

https://www.cnblogs.com/alantu2018/p/8457420.html

用户态ASAN技术简介：

和内核态的KASAN是一样的技术原理，用来动态检测用户态内存地址相关的bug

原理介绍：

运行时库：（libasan.so.x）会接管。malloc执行完后，已分配内存的前后（称为“红区”）会被标记为“中毒”状态，而释放的内存则会被隔离起来（暂时不会分配出去）且也会被标记为“中毒”状态。

编译方式：

ASAN内存泄漏屏蔽功能： 

https://blog.csdn.net/ffmpeg4976/article/details/48766359m_source=blogxgwz3

TSAN:

有时间了补充…….

KTSAN

有时间了补充…….

UBSAN

有时间了补充…….

MSAN

有时间了补充…….

***************************************黑盒测试技术简介**************************************************

2、模块级的故障注入可靠性测试（黑盒测试技术）

3、模块级的大压力稳定性测试（黑盒测试技术）

4、模块级的安全渗透/攻击测试（黑盒测试技术）

5、模块间的交叉混合压力稳定性测试（黑盒测试技术）

6、系统级背景压力场景下的模块级功能/性能验证（黑盒测试技术）

7、系统级故障注入场景下的模块级功能/性能验证（黑盒测试技术）