谈谈关于我自己做量化的经验：

sword_zhu_1

谈谈关于我自己做量化的经验：

        我到现在为止，在两家公司做过测试方面的工作：

        1）在第一家公司里面，我们主要做黑盒测试，针对的产品是PDA，所以我们只能按照软件设计规范和相关的说明书进行测试。我们也根据软件设计说明书编写了测试设计说明书。但是发现比较难根据这个进行量化。我们后来改进了一下，尽管方法比较土。我们把量化分为了两个方面，一个方面是对测试报告进行量化。我们每天都向开发人员发出测试报告。测试报告中涉及的内容主要有测试人、审核人、问题修改人、问题验证人、问题缺陷等级分类（也分为A,B,C,D四类，分类的标准主要是针对所发现的问题对产品质量和产品整个生命周期的影响）和问题描述（包括发现问题的操作过程简要描述、问题现象并且在问题修改后验证的情况描述）。
       另外我们在一个比较大的测试阶段完成后，我们编写测试报告。测试报告的格式我们基本上是按照国标编写的。但是我们增加了一些自己的特色。比如说，我们增加了问题跟踪图和问题分布图。有了问题跟踪图，我们就可以判断目前产品质量的情况。如果跟踪图的趋势变化平稳，我们认为这一阶段的测试效果不错。如果跟踪图变化不正常的话（既有突变的时候），那么我们就可以分析原因，不是开发人员的问题，就是测试人员的问题。

      另外我们对系统测试操作过程也进行了量化，我们的办法比较土，就是在每一步测试的时候，记录下测试的具体过程和测试的结果，不管是正确的测试结果还是错误的测试结果。我们把这个文档叫做具体测试过程记录手册。关于这个手册，也可以事先编写。但是编写者要对被测试产品有足够多的了解和熟悉。在编写完这个手册后，我们的量化工作就非常方便了。我们可以对测试人员每天的工作量都可以统计。对所采用的测试方法可以评估。并且可以更加高效地进行回归测试。另外由于我们有这样的文档，所以在ISO审核的时候，我们部门更快就通过了。

       2）在第二家公司里面，我们的测试主要是编写脚本进行测试。而每个脚本都是有消息组成的。每条消息都是由参数组成的。而且培植这些参数都使得按照一定协议规定来进行配置的。所以我提出了纵横量化方法。纵就是每一个测试脚本的设计和流程。横就是消息的配置。这样我们就可以将测试人员分为两大类。第一类的就是熟悉通信协议流程的，由他们来设计测试脚本流程。第二类就是熟悉消息参数配法的，由他们来设计相关的消息。由于如果修改一点消息里面的参数，就会产生一定的影响的话，那么消息就会很多。而测试脚本流程设计人员就可以通过这些消息的组合来作出各种的脚本。所以我们的量化就分为了两个部分，脚本编写的量化和消息编写的量化。

wxj234

我觉得问题跟踪图和问题分布图比较不错,那样的话,可以看得比较清楚.