缺陷描述的质量实际很体现一个测试人员的能力，一个能写出高质量缺陷描述的人让开发人员看的时候像是一种享受，一份差的缺陷描述会让开发人员犯错，对测试人员的缺陷不信任，也会让测试人员前面做得很多事。其实写起来也很简单，就在什么地方，操作了啥，出现了什么错误，可能原因是会什么！我们来看看一个关于资产财务月报折旧数据不对的缺陷，各个测试人员提交的内容。

       从上面的例子可以看出，一个缺陷尽然出现5种说法，如果你是开发人员你想看哪位测试人员的缺陷，肯定是第5位。我们来分析一下这5个缺陷的结果。

缺陷杂谈之一：如何理解深层次缺陷

记得有一次，测试刚开始，有一个同事很兴奋跑过来跟我说，对话如下：

他：“傻哥我发现一个很严重的缺陷”

我：“我说什么缺陷”

他：“当一张门诊处方输入200项的时候保存就报错”

我：“需求中门诊处方要求最大项目数是多少，你测试这个错误花了多少时间”

他：“60项，2个小时”

我：“你这个模块用例优先级是’高’都执行完了”

他：“只执行了五分之一”

我：“你见一张处方有200项的吗，还有五分四的测试用例这周能完成吗”（补充说明，当时已经周四下午）

……

         我给大家举这个例子的意思是，我们不要为了找深层次的缺陷而去找深层次，我们找缺陷要根做事一事一样要有步骤，要有优先次序地进行。我们必须根据当时项目的情况或根测试用例的优先级高低来执行。

从单个缺陷来看这个缺陷严重非常高，但时从他现在项目和测试情况，这个缺陷优先级非常低 。如果如一个产品的基本功能不能确保的时候，像这样用户可能永远不会发生错误我们却花了大量的成本去发现，我觉得不值。

如果他告诉我“当一张门诊处方输入61项的时候保存，就报错”，那么我会觉得很有价值。

我为什么要说这个，因为我发现很多测试人员觉找一些“简单”缺陷，比如点击某按钮就报错，觉得很没有成就感，项目一开始就花很多时间去找所谓“深层次”的缺陷，而把一些简单缺陷给遗漏了。

我们必须扫清我们所谓简单缺陷以后再去找“深层次”的缺陷。碰到很多简单缺陷时候，我们要分析，要这些大家觉得“很简单”的缺陷以后不再发生，才是我们要做的事。如有些界面问题，可以把一些经常出现的界面问题做成界面规范，让设计人员在界面设计的时候就遵守，那么我测试的时候这些问题就少了。

       我在前几次性能测试杂谈已经简单描述了性能测试需求获取和各操作系统的一些监控指标，那现在一起来看看如何进行性能测试用例设计吧。

       前面我们做了很多工作主要是为测试用例设计做准备，如果需求都不明确，咱们如何设计呢。测试用例设计的时候要把握这几个关键环节。

1.     确定目标

这里的目标指的当前测试系统的目标值，或者说是客户的期望值，也有可能业内的标准值。这里设定的时候一定考虑测试执行环境的影响，因为一般情况测试时不可能是在真实或上线的环境中测试。这个时候我们一定根据测试执行环境和真实、上线的环境进行比较，将我们原有目标值换算成我们测试参考值。一般受影响的环境，有服务器的配置、网络环境、数据量等。

2.     场景设计

我个人认为场景设计是性能测试用例设计最关键环节，很多人会想“大傻”你又来忽悠我们了，这还不好设计，就是模拟用户的场景就行了。我们还是拿【性能测试杂谈一】中的例子来说明一下。【某系统在做个人日报和汇总日报时，收费业务点击结账时要等很久】，我会设计以这种场景。

       为什么这样设计，主要为执行考虑，如果我测试场景2的时候，我就发现问题了，我还有必要再去执行场景3和场景4。但是又有人会有疑问，如果第一次就选择场景4，一次就Ok，但是大家要想到业务组合越多，对后测试执行时脚本调试、数据准备和恢复的工作量是巨大，发生错误的概率更大，而且为我们测试结束定位和分析更为困难。测试用例场景的设计一定考虑测试的执行，场景设计一定从简单到复杂。

       什么是最好的性能测试用例，就是在最短的时间内能快速准确的定位到系统瓶颈。

性能测试越来越吃香，所有测试人员都成为这方面的高手，我个人觉得掌握一种测试工具必不难，只要花上个一周甚至更少的时间就Ok了。难在哪里，难在性能需求获取、分析、设计和性能测试结果分析、定位、优化。那我们今天来先说说如何做好性能测试需求获取。

获取，如何真正的获取

  我记得有一次，客服中心反馈：“某某客户公司某某系统收费业务有时很慢”，这个需求看起来好像很完善，但是作为性能测试员怎么下手呢，拿起LR就冲锋一把，肯定解决不了问题，除非瞎猫碰到死老鼠。

后面我拿到客户的电话简单又沟通了一下，大体内容如下：

我：“是一直很慢，还是有规律的，慢的体现是怎么样”，

操作人员：“4点以后就开始，点结账功能要等好久”，

我：“4点以后，你们那时还有哪些事情再做”，

操作员：“交接班，个人要做个人日报，部门领导要做汇总日报等”。

这时提交性能小组的需求是：某系统在做个人日报和汇总日报时，收费业务点击结账时要等很久。

从上面的例子可以看出，我们在性能需求获取时，需要跟客户最好是实际的操作人员交流，在了解功能的基础上，还要交流一些非功能需求，如：什么时候做，有多少人做，每天有做多少次，每次提交哪些信息，有的甚至要了解他们工作性质，如什么时候上班，是否24小时值班，交接班是什么时候，每班几个小时。

要了解业务同时还要获取到当前系统网络架构，网络结构时怎么样，什么数据库，什么中间件，是否能连接外网，系统是什么开发的，当前已数据库有几GB等。当前性能需求业务涉及哪些表，结构是怎么样的。