（1）：测试分类多多

        测试类型有很多分类，很杂，如何理顺？上一节我们知道，测试系统有五个要素，测试手段的分类也可以按要素来考虑。

        从“测试人员”（代表谁）这个要素来看，有：用户测试、阿尔法测试（内部代表测试）、贝塔测试（外部代表测试）；

        从“覆盖率”（内容）这个要素来看，有：功能测试、域测试、等价类分析、边界测试、最佳代表测试、逻辑测试、状态测试、语句与分支覆盖率、配置测试、基于规格说明书的测试、基于需求的测试、组合测试，等等。

        从“潜在问题”（风险）这个要素来看，是基于风险的测试，关注：输入约束、输出约束、计算约束和存储（或数据）约束。

        从“活动”这个要素来看，有：回归测试、脚本测试、冒烟测试、探索式测试、游击式测试、场景测试、安装测试、负载测试、长序列测试、性能测试。

        从“评估”（是否通过）这个要素来看，测试手段有：自校验数据、与已保存的结果进行比较，与规格说明比较。

        还可以从多个要素或多个测试手段的组合来了解测试方法。从上面可以看出，测试的分类是很庞杂的，对此我们要有一个基本的认识，即是关注哪方面，从哪个角度来说的。

        上述测试手段或方法就不去一一定义了，常用的术语随便找一本测试类教科书都可以找到。

        给大家留一道思考题：IBM推崇的“静态测试”主要涉及哪些要素？最好归于哪一类中？
（2）：用心写好测试报告

        将测试的问题呈现给他人，就是通过你的测试报告（这里的报告是指对问题测试的描述），它是测试员的主要工作产品，如果报告写得好，则声誉高。

        有不同类型的测试报告，即面向不同的读者。

        面向程序员的测试报告，通常是放到测试管理工具中流转到程序员，这时要注意几点：

1、  客观描述现象，列出具体测试用例。

2、  可以提供一些分析和建议，但不要作出评价。

3、  对测试中没有再现的现象，也要作出说明，以期引起注意。

        面向生产例会提供的测试报告，通常由测试经理带到会上，这时要考虑：

1、  有综述性地统计信息，反映全貌；

2、  要重点突出，以便测试经理能在较短的时间里向会议表达重点事项。

3、  要有分析，并提醒相关问题（如，培训方面），使报告更有价值。

        面向管理层的测试报告，一般是综述性报告，用于判断质量情况，做出相关决策。

        这时的报告要考虑：

1、  有分析模型（公司要有自己的模型），有判断和结论。

2、  与历史数据有比较，评估风险。

3、  是一定范围的集体意见的反映，也反映其它项目相关人的意见（作为代言人）。

        公司对各类测试报告要有模板和写作要求，并通过这些指引，培养一致的风格，有利于报告的理解。
        看一个对话：为何这么明显的问题没有报告出来？我以为别人已报告了这个问题。

        因此，不要假设明显的程序错误已经写入报告。大家都有这种假设时则会遗漏。

        设计错误谁来报告？当然还是由测试员来报告。测试员的测试可以作为设计的后期评判。为了能对设计进行测试，测试组只要有一定比例的领域专业人员。
（3）：测试数据能用于考核吗？

        这还真是个问题，不知你想过没有。

        在强调绩效考核、量化考核的今天，企业常常拿测试数据直接作为考核指标，因为，这是容易拿到的数据，也容易推理到绩效上去（测试数据——>产品质量——>绩效）。

我们看一下几种情形：

1、  将测试BUG个数用来考核程序员：这会使程序员与测试员之间产生极大的矛盾，不利于二者之间的沟通，程序员争辩设计问题并不是程序问题将导致仲裁的管理成本。或测试员被程序员拉拢会使数据失真（问题数变小或合并填报）；

2、  将测试BUG个数用来考核测试员：则他既是运动员又是裁判员，会夸大数据，其方式有重复（一个问题的多个实例）和扩大（将肤浅的事项扩大成问题），这时测试员不愿帮助程序员改正BUG（因他下一次又能发现）。

        测试数据的跟进属技术管理范畴，而考核是属人力资源管理范畴，前者要求真实性，后者要求公正合理。因此，选取测试数据作考核要慎重。

        比较合理的考核指标：将缺陷清除率作为程序员的质量考核指标，将产品投产后一定周期内客户发现的问题密度作为考核测试员的质量指标。