我们有必要把握这些东西，完善且充分的监控，才能让我们对过程以及结果能有充分的认识和判断 4：这是体现一个性能测试人员素质的时候了，就是对过程以及结果的监控数值的判断，一个具备良好素质的性能测试工程师，应该能充分的设计相关的场景，以使这些场景暴露出性能的问题，而这些场景只能直接暴露出你监控到的过程和数据。
4.1所以数据库的监控数据如何分析？如何看？这个首先得了解数据库的设计和结构了，对表的关系要明白，而在这之后，你就想象一下你的业务到底在操作哪些表，执行了几次查询，数据库有几次IO等等。哪些SQL执行得最频繁，哪些IO最多，哪些阻塞最严重等等，而这些SQL都是在哪些场景中执行？可以追溯到哪个业务操作？这个过程，需要业务很熟悉，数据库设计很了解，更关键一点，是怎么把这两者结合起来一同分析。同时知道这些还不够，因为你的数据库如果是ORACLE问题一般会在哪，如果是DB2问题又会在哪？这个过程很麻烦，假如只会使用LR，你永远就知道A业务和B业务一起跑起来很慢，然后你告诉开发人员，A和B一起跑很慢，一般他都会先问你：“为什么呢？”因为假如他知道会慢你就不会测出来了，就是因为他不知道会慢，因为他不知道会慢所以他一般也不会知道为什么会导致慢。然后一大驮的程序代码，开发员翻了半天也翻不出什么问题来，因为他要是翻得出来就不会让你发现了。因此性能测试人员这时候再傻一点的，就应该会纠出几个IO很频繁的，阻塞最严重的SQL出来，你看看这些是不是有问题。噢也，对，就是这里IO查询执行了N遍，或则是，哇，这地方阻塞等待的时间也太久了。那么问题就简单明了些了，开发人员翻翻那代码趟在的地方，对了就这了，看了半天，对，就是这里有问题了，时间节省很多了吧？再高手的人，一看到那些数据，然后转头和开发员说，你这瓜娃子，都和你说过了，数据库IO很影响性能了，这地方你看是不是把表锁死了，你想想看那条SQL语句是不是写出问题来了。然后给出了这些建议，开发员一看，89不离10的话，那么这就是高手了。还有更高手的，那就是跑都不用跑，直接拿ER图来看看，然后再把数据库的表关系给瞧瞧，或则整整程序中敏感的地方，那问题就出来了，那叫经验，这时候，转身就可以说，你个呆瓜，有你这样写的么？就知道你会这么写，下次再这么写我把你头给拧下来。呵呵，以上的某些语言纯属玩笑。。。但问题确实如此，假如做为性能测试人员，连影响性能的因素都把握不准，那么很难寻找问题，并发现问题的本质。特别是在数据库应用的软件系统中，你不了解数据库，你就不了解你在做什么。
