3、 要有分析，并提醒相关问题（如，培训方面），使报告更有价值。
面向管理层的测试报告，一般是综述性报告，用于判断质量情况，做出相关决策。
这时的报告要考虑：
1、 有分析模型（公司要有自己的模型），有判断和结论。
2、 与历史数据有比较，评估风险。
3、 是一定范围的集体意见的反映，也反映其它项目相关人的意见（作为代言人）。
公司对各类测试报告要有模板和写作要求，并通过这些指引，培养一致的风格，有利于报告的理解。
看一个对话：为何这么明显的问题没有报告出来？我以为别人已报告了这个问题。
因此，不要假设明显的程序错误已经写入报告。大家都有这种假设时则会遗漏。
设计错误谁来报告？当然还是由测试员来报告。测试员的测试可以作为设计的后期评判。为了能对设计进行测试，测试组只要有一定比例的领域专业人员。
（3）：测试数据能用于考核吗？
这还真是个问题，不知你想过没有。
在强调绩效考核、量化考核的今天，企业常常拿测试数据直接作为考核指标，因为，这是容易拿到的数据，也容易推理到绩效上去（测试数据——>产品质量——>绩效）。
我们看一下几种情形：
1、 将测试BUG个数用来考核程序员：这会使程序员与测试员之间产生极大的矛盾，不利于二者之间的沟通，程序员争辩设计问题并不是程序问题将导致仲裁的管理成本。或测试员被程序员拉拢会使数据失真（问题数变小或合并填报）；
2、 将测试BUG个数用来考核测试员：则他既是运动员又是裁判员，会夸大数据，其方式有重复（一个问题的多个实例）和扩大（将肤浅的事项扩大成问题），这时测试员不愿帮助程序员改正BUG（因他下一次又能发现）。
测试数据的跟进属技术管理范畴，而考核是属人力资源管理范畴，前者要求真实性，后者要求公正合理。因此，选取测试数据作考核要慎重。
比较合理的考核指标：将缺陷清除率作为程序员的质量考核指标，将产品投产后一定周期内客户发现的问题密度作为考核测试员的质量指标。
文章来源于领测软件测试网 https://www.ltesting.net/
