驱动测试指导（上）

      先讲一个故事，年轻的我在写代码时突然灯泡一亮，会觉得某段算法好像不太好，就向当时的老大申请时间去创造一个新的算法。老大当时也没责怪和限制我，就说：的确存在，但是创造新的算法并不是件简单的事，有机会可以去试试，毕竟前人的算法是经过多次验证，成熟的。如果花时间创造出来的，可能会引发连带的问题。

     我当时年轻，觉得自己数学功底十分扎实，虽然尊重老大，但内心认为算法肯定是自己创造的1个更牛b。原则上服从了工作安排，但业余时间还是花了很大精力搞了一个算法出来，随后算法做验证后，还是发现其实和原来的是差不多的，只是把检查的范围变小了，自然效率高了。一旦检查范围变大，效果反而不如原来的。郁闷，但一时间执作的脾气又起来了，结果在回忆看来，完全是消耗了大量的时间做了很多毫无意义的事。

      用这段时间我拿来去不同餐厅吃东西和切磋厨艺，将是多么有意义的事。但是浪费了。这里不是反对尝试，尝试是对的，关键字：有用功和无用功。

     自我检讨包含几个问题：

     v旧时的我缺乏理论的驱动；

     v过于依赖单一的只是工作需要的知识；

     v技能运用的熟练度不高，无法举一反三。

     现在的我虽然知道问题在哪里了，应该是优化核心，周围8个点传入GetF做处理，同时关注子节点的数量和尽量有效，区分设置点的类型和拐角的特殊处理，一些想法在纸上推算，可以减少直接上机的时间。

     下面在转换到一个测试上的问题上去，关于性能的。

    假定是客户端cpu的问题，测试应该如何去采集查看。是查看整个机器n个进度下的cpu使用率还是目标进程的cpu使用率？如果目标进程的cpu35%，那么35%算高吗？多少才符合标准。是哪些因素导致的？测试人员可以排出一个问题列表和解决问题的优先时间，如果可以评估开启~至于解决结束时间做为给上面参考是最好了。毕竟测试的很多知识点是和很多职业有一定重合的，可以用温和的方式去帮助他们，和项目组一起达成项目进度。

    我下面套用1个简单的用户场景（带宽和同配置情况下只看cpu）：

    固定行为：无缓存情况下，进入游戏，加载完全主场景，进入一场战斗。背包内物品入包和删除等。根据业务来设计。测试是门严谨的学科，关乎性能部分还是要深入去做的。

    执行后的一段时间内可以用vbs分段截屏快照，保存在本地路径下，也可以盯着电脑手动采集。

    场景1：系统只开必要的进程，记录cpu的使用率和截图。严格执行这套固定行为，查看一定时间段的cpu使用记录。    

    场景2：新增一个快播和一个迅雷，开启迅雷不下载的，快播和游戏同时在加载。采集上面的一样结果，那么谁告诉我，结果应该是怎么算对，怎么算错呢？？

    理论和扎实的基础可以指导你的实践。结果应该是你需要记录的cpu不会受到什么影响。使用记录的波段都是一致的才是对的。原理可以慢慢了解。

    新的场景：如果环境执行是非ie类的产品嵌套的cpu使用率的查看方式和上面的一样吗，需要关注什么？取多个进程的平均进程？取哪2个呢。可以根据GDI对象来识别，到底是哪个呢？

    我自己因为东西多而不严谨，在遇到过记录了一段时间后，一看觉得不对啊，和预估相差太多，果然一看。采样的地方错了。  

小结：

    关于性能总结出一句话：尽可能提升单位时间的处理事物的能力，同时降低延迟，前句和后句都是对的，但放一起无疑是实践上矛盾的。

    当你一个游戏的玩起来比较卡。我们首先是不是应该先判断是客户端问题，还是服务上的延迟。可以一项项单线程去排除，列张黑板图来看这些问题。