今年，确定了自己的职业走向：系统工程师。所以从工作和学习积累中开始放弃一些知识点和业务点，在测试行业的大知识圈中选中自己需要的几个要点进行深入研究。

　　要做好系统分析类的工程师，需要注重3个部分：数据库，操作系统，网络。此部分以操作系统为主，结合工作经验，开始把系统以自己的测试角度来描述一下自己的系统见解。（此次学习和工作中性能测试的书为：《操作系统精髓与设计原理》）

　　虽然对于评测师考核中，硬件也是测试人员的知识点之一，由于我的职业走向基本很少和纯硬件打交道，我就从cpu开始学习和总结。

　　计算机在单核的情况下，程序对其而言是一排需要执行的指令，在高速执行的过程中，单核的计算机执行的每个时刻都是只能处理一件事情.所以单核的CPU处理的速度取决与它的主频。想在每个进程之间插入一些操作，一般来说需要靠中断，中断一般来自与时钟，程序和io干预.此时就可以在cpu中执行多个进程的程序.进程一般有新建，就绪，执行，挂机，退出的状态，通过程序和cpu自动的分配可以使得进程。多核的计算机就好比有多个独立的线程，然后有1个主控制器来分配任务，比起单核，可以同一时间做多个任务。在这里我有个疑问，这些多核的系统应该也会像分布式系统一样有个控制器来主导它的执行数据，所以我觉得他也有类似一个这样的映像瓶颈的因素在（这点书上我没找到相关的资料）。

　　对于CPU，作为性能测试人员来说，即需要分析多线程的客户端代码编写，也需要分析被测服务器的线程相关指标。一半作为自动化的脚本来说，线程可能只有10个，出现到需要‘分析’线程的时机不是太多，但是作为压力测试，尤其是不依赖工具来写，是个重要的一环。一台普通pc可能在执行程序可以开到几百甚至上千个线程。但是你作为测试的客户端，就会受到了CPU主频的限制。一个CPU处理速度是有上限的，就是计算机能够开超过上千的线程，它输出的压力其实不比几百个线程高。因为此时你的CPU到了极限，多于的线程其实效果就跟列表的速度差不多。所以第一点测试的时候假如要求注重并发性，你首先要算好和测试你的每台机器最佳开启线程数（测试稳定性可以不用）。其二我一直把一个“核”当作一个测试机对待，即使在现在最流行的云，我也是坚持物理机做压力，因为你再怎么虚拟，机器的效率是有限的，你用尽了机器的’潜力‘不代表你高并发。其三，算好每个测试机网络io的最大流量，即使你用强大的服务器机来做客户端，你的io限制了，还有操作系统的限制，使得它并发的效果不是你所想的效果。所以，我们在有条件的情况下，做多线程压力就需要用到分布式，我也经常把多核服务器当作“小分布式”对待。但是分析被测系统的性能的时候，除了关注上面三点外，我们其实不是关注它的并发能力，而是它的交易成功率，还有就是排队的缓存，和负载均衡的效果。

　　说到线程，应该不会忽略掉信号量的使用，也是每年软件评测师的典型题目：PV操作。因为互斥，死锁等问题，在我学习科学计算的文章时，用C++的代码会用到信号量。但是用脚本语言python的时候，发现很多时候，它封装的threading竟然也做到了信号量的操作（我在同段代码加入信号量的控制，效果一样）这点我需要后期项目机会来研究（毕竟脚本语言使用类似ReentrantReadWriteLock的时候不多）

　　为什么我会提到互斥，还有我分析操作系统期间，会关注编写内存这块呢。因为很多时候，python和java写的脚本测试的确没用到这些做压力测试。但是你碰到操作数据库，重现产品异常测试BUG问题，还有提高压力时，无疑嵌入C++语言是个好选择（这和开发相反，不知道别人是否这么做，我现在就是这样做，喜欢把开发速度快的语言作为主语言）。因为很多测试代码“自动”的功能帮倒忙，在做性能测试的异常测试时，往往会因为语言“自动处理”导致很多问题给忽略了，这时候你也不得不用到有“手动”功能的语言来进行测试。

　　结语：我的测试之路就是一直在打系统知识基础的过程，每次分析项目问题的突破都和CPU，进程，线程有关。同时为后面的学习笔记：分布式，云打下知识基础。

版权声明：本文出自 acbennn 的51Testing软件测试博客：http://www.51testing.com/?299791

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。