测试报告的编写（转）

测试总结和报告

        测试人员的工作通常并不像开发人员那样能直接体现出来，让大家一目了然。开发人员做的是建设性的工作，如开发了哪些功能，写了几行代码，设计了几个类，都能直观地看到，而且，通过软件能很鲜活地演示开发人员的工作成果。
        但是测试人员的工作相对隐蔽一点，测试人员做的是破坏性的工作，并且没有很多可以直观体现测试人员贡献的东西。笔者曾经听到公司人事部的一位同事说：“你们做测试的真好，整天坐在那里”。当然，这是外行人看内行时说的话，但是给笔者的一个启示是：测试人员需要更多地表现自己，展现自己的工作成果。
        说明：由于缺陷列表太细、太大，测试用例过于专业，很多人对其不感兴趣，因此测试报告能很好地展示自己的工作状况，测试报告是提供给很多人看的一份文档。

        下面是一个项目的测试报告的纲要：
1 简介
1.1 编写目的
1.2 项目背景
1.3 术语和缩略词
1.4 参考资料
2目标及范围
2.1 测试目的及标准
2.2 测试范围
3 测试过程
3.1 测试内容
3.2 测试时间
3.3 测试环境
3.4 测试方法及测试用例设计
4 测试情况分析
4.1 测试概要
4.2 测试用例执行情况
4.3 缺陷情况
4.4 测试覆盖率分析
4.5 产品质量情况分析
5 测试总结
5.1 测试资源消耗情况
5.2 测试经验总结
6 附件
附件1 测试用例清单
附件2 缺陷清单
一、缺陷分类报告
        缺陷分类报告是测试报告的重要组成部分，可以再细分为：缺陷类型分布报告、缺陷区域分布报告和缺陷状态分布报告等。
1．缺陷类型分布报告
        缺陷类型分布报告主要描述缺陷类型的分布情况，看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意，并分析缺陷为什么会集中在这种类型。例如，如果缺陷主要是界面类型的，如界面提示信息不规范、界面布局凌乱等问题，那么就要讨论是否需要制定相应的界面规范，让开发人员遵循，从而防止类似问题的出现。
缺陷类型分布报告一般用饼图或柱状图显示。如图7.29所示，用饼图表示了几种类型的缺陷各自所占的比例。

图  缺陷分布报告

三、典型缺陷与Bug模式
        软件开发有设计模式，测试其实也有模式存在，需要测试人员进行总结和归纳。测试人员应从经常出现的Bug中学习，总结出Bug模式，用于指导测试。如果开发人员能关注这些Bug模式，还能起到预防错误的效果。
        要成为典型缺陷，必须满足以下条件：
        重复出现、经常出现；
        能代表某种类型的错误；
        能通过相对固定的测试方法或测试手段来发现这些错误。
        总结这些典型缺陷出现的现象，出现的原因，以及测试方法，就能成为一个Bug模式。

        说明：根据不同的开发平台、开发工具、开发语言、产品类型、采用的架构等，可以总结出不同的Bug模式，不同的Bug模式可能在不同的平台、语言、产品类型中才会出现。测试人员应该总结适合自己项目特点的Bug模式。

        提炼Bug模式的一般步骤如下：
        步骤1：分析缺陷报告，找出经常出现的Bug类型。
        步骤2：分析Bug的根源，找出Bug产生的深层次原因。
        步骤3：分析找到Bug的方法，总结如何才能每次都发现该类型的Bug。
        下面举一个例子来说明这个过程。
        首先，测试人员在分析缺陷报告时发现，有一类Bug经常出现，并且错误现象一致：执行某功能时提示Time Out。
        测试人员与程序员一起分析原因，发现这些错误都是在操作数据库时发生，发送的SQL语句被数据库长时间执行未返回，因此提示Time Out。通过进一步地分析表明，.NET的SqlCommand的CommandTimeOut属性是用于获取或设置在终止执行命令的尝试并生成错误之前的等待时间。等待命令执行的时间（以秒为单位）默认为30s，而数据库操作在较大数据量的情况下一般都超过这个时间，因此会提示超时的错误信息。
        这样就可以把这种类型的Bug归纳为“数据库操作超时Bug模式”。
        那么，如何才能找出这样的Bug呢？一般情况下，这类Bug基本上不会出现，只有数据量足够大时才会出现，因此需要设置大批数据，结合性能测试或压力测试来发现此类问题。也可以通过白盒的方式，查找程序在使用SqlCommand时是否合理地设置了Command TimeOut属性，这样将更有针对性地揭露上述的错误。
        至此就完成了一个Bug模式的归纳、提炼和总结，如果程序员积极地参与到该总结和分析过程中来，则可形成一个良性的反馈，当下次程序员编写相同的程序时就会避免类似的错误发生。
四、测试中的PDCA循环
        PDCA循环是一种放之四海皆准的原则。在软件测试的过程中，也充斥着各种PDCA循环。PDCA循环是一个自我完善和改进的全闭环模型，如图7.34所示，对质量的不断提高和改进非常有效。

  PDCA循环模型

软件测试技术
        在外行人看来，软件测试其实没什么技术可言，甚至有人认为测试无非是在摆弄一下软件的功能，只要懂得使用鼠标就足够了，这是对软件测试的一种误解。
1. 黑盒测试与白盒测试
        很多测试人员喜欢讨论黑盒测试与白盒测试的区别，也有些测试人员感觉白盒测试很神秘，很高深，自己没有足够的开发能力是不可能进行白盒测试的。
那么什么是黑盒测试，什么是白盒测试呢？下面对此进行简单介绍。
1.1黑盒测试
        黑盒测试是一种把软件产品当成是一个黑箱的测试技术，这个黑箱有入口和出口，测试过程中只需要了解黑箱的输入和输出结果，不需要了解黑箱里面具体是怎样操作的。这当然很好，因为测试人员不用费神去理解软件里面的具体构成和原理，测试人员只需要像用户一样看待软件产品就行了，如图1所示。

图1  黑盒测试方法

        例如，银行转账系统提供给用户转账的功能，则测试人员在使用黑盒测试方法时，不需要知道转账的具体实现代码是怎样工作的，只需要把自己当成用户，模拟尽可能多的转账情况来检查这个软件系统能否按要求正常实现转账功能即可。
        如果只像用户使用和操作软件一样去测试软件黑盒测试可能存在一定的风险。例如，某个安全性要求比较高的软件系统，开发人员在设计程序时考虑到记录系统日志的必要性，把软件运行过程中的很多信息都记录到了客户端的系统日志中，甚至把客户端连接服务器端的数据库连接请求字符串也记录到了系统日志中，像下面的一段字符串：

"Data Source=192.168.100.99;Initial Catalog=AccountDB;User ID=sa;PassWord=123456;

        那么按照黑盒测试的观点，这是程序内部的行为，用户不会直接操作数据库的连接行为，因此检查系统日志方面的测试是不会做的。这明显构成了一个Bug，尤其是对于安全性要求高的软件系统，因为它暴露了后台数据库账号信息。
        有人把黑盒测试比喻成中医，做黑盒测试的测试人员应该像一位老中医一样，通过“望、闻、问、切”的方法，来判断程序是否“有病”。这比单纯的操作黑箱的方式进了一步，这种比喻给测试人员一个启示，不要只是简单地看和听，还要积极地去问，积极地去发现、搜索相关的信息。应该综合应用中医看病的各种“技术”和理念来达到找出软件“病症”的目的，具体作法如下：
&61548; “望”，观察软件的行为是否正常；
&61548; “闻”，检查输出的结果是否正确；
&61548; “问”，输入各种信息，结合“望”、“闻”来观察软件的响应程度；
&61548; “切”，像中医一样给软件“把脉”，敲击一下软件的某些“关节”。

1.2白盒测试
        如果把黑盒测试比喻成中医看病，那么白盒测试无疑就是西医看病了。测试人员采用各种仪器和设备对软件进行检测，甚至把软件摆上手术台解剖来看个究竟。白盒测试是一种以理解软件内部结构和程序运行方式为基础的软件测试技术，通常需要跟踪一个输入经过了哪些处理，这些处理方式是否正确，这个过程如图2所示。

图2  白盒测试方法

        在很多测试人员，尤其是初级测试人员看来，白盒测试是一种只有非常了解程序代码的高级测试人员才能做的测试。熟悉代码结构和功能实现的过程当然对测试有很大的帮助，但是从黑盒测试与白盒测试的区别可以看出，有些白盒测试是不需要测试人员懂得每一行程序代码的。
        如果把软件看成一个黑箱，那么白盒测试的关键是给测试人员戴上一副X光透视眼镜，测试人员通过这副X光透视眼镜可以看清楚输入到黑箱中的数据是怎样流转的。
        一些测试工具就像医院的检测仪器一样，可以帮助了解程序的内部运转过程。例如，对于一个与SQLServer数据库连接的软件系统，可以简单地把程序的作用理解为：把用户输入的数据通过SQL命令请求后台数据库，数据库把请求的数据返回给程序的界面层展示给用户。可以把SQL Server自带的工具事件探查器当成是一个检查SQL数据传输的精密仪器，它可以记录软件客户端与服务器数据库之间交互的一举一动，从而让测试人员可以洞悉软件究竟做了哪些动作。
        在测试过程中，应该综合应用黑盒测试方法和白盒测试方法，按需要采用不同的技术组合。不要用黑盒测试方法和白盒测试方法来划分自己属于哪一类测试人员，一名优秀的测试人员应该懂得各种各样的测试技术和查找Bug的手段。