测试报告编写指南Word文件下载.docx
《测试报告编写指南Word文件下载.docx》由会员分享，可在线阅读，更多相关《测试报告编写指南Word文件下载.docx（65页珍藏版）》请在冰豆网上搜索。
此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。
1.2项目背景
对项目目标和目的进行简要说明。
必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。
1.3系统简介
如果设计说明书有此部分，照抄。
注意必要的框架图和网络拓扑图能吸引眼球。
1.4术语和缩写词
列出设计本系统/项目的专用术语和缩写语约定。
对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。
1.5参考资料
1．需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。
2．测试使用的国家标准、行业指标、公司规范和质量手册等等
PARTⅢ测试概要
测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。
（其他测试经理和质量人员关注部分）
2.1测试用例设计
简要介绍测试用例的设计方法。
例如：
等价类划分、边界值、因果图，以及用这类方法（3-4句）。
如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念，顺便说一句，在这里写上一些非常规的设计方法也是有利的，至少在没有看到测试结论之前就可以了解到测试经理的设计技术，重点测试部分一定要保证有两种以上不同的用例设计方法。
2.2测试环境与配置
简要介绍测试环境及其配置。
提示：
清单如下，如果系统/项目比较大，则用表格方式列出
数据库服务器配置
CPU：
内存：
硬盘：
可用空间大小
操作系统：
应用软件：
机器网络名：
局域网地址：
应用服务器配置
…….
客户端配置
对于网络设备和要求也可以使用相应的表格，对于三层架构的，可以根据网络拓扑图列出相关配置。
2.3测试方法（和工具）
简要介绍测试中采用的方法（和工具）。
主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。
工具为可选项，当使用到测试工具和相关工具时，要说明。
注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。
PARTⅣ测试结果及缺陷分析
整个测试报告中这是最激动人心的部分，这部分主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。
对于不需要过程度量或者相对较小的项目，例如用于验收时提交用户的测试报告、小型项目的测试报告，可省略过程方面的度量部分；
而采用了CMM/ISO或者其他工程标准过程的，需要提供过程改进建议和参考的测试报告－主要用于公司内部测试改进和缺陷预防机制－则过程度量需要列出。
3.1测试执行情况与记录
描述测试资源消耗情况，记录实际数据。
（测试、项目经理关注部分）
3.1.1测试组织
可列出简单的测试组架构图，包括：
测试组架构（如存在分组、用户参与等情况）
测试经理（领导人员）
主要测试人员
参与测试人员
3.1.2测试时间
列出测试的跨度和工作量，最好区分测试文档和活动的时间。
数据可供过程度量使用。
例如XXX子系统/子功能
实际开始时间－实际结束时间
总工时/总工作日
任务开始时间结束时间总计
合计
对于大系统/项目来说最终要统计资源的总投入，必要时要增加成本一栏，以便管理者清楚的知道究竟花费了多少人力去完成测试。
测试类型人员成本工具设备其他费用
总计
在数据汇总时可以统计个人的平均投入时间和总体时间、整体投入平均时间和总体时间，还可以算出每一个功能点所花费的时/人。
用时人员编写用例执行测试总计
这部分用于过程度量的数据包括文档生产率和测试执行率。
生产率人员用例/编写时间用例/执行时间平均
3.1.3测试版本
给出测试的版本，如果是最终报告，可能要报告测试次数回归测试多少次。
列出表格清单则便于知道那个子系统/子模块的测试频度，对于多次回归的子系统/子模块将引起开发者关注。
3.2覆盖分析
3.2.1需求覆盖
需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。
需求/功能（或编号）测试类型是否通过备注
[Y][P][N][N/A]
根据测试结果，按编号给出每一测试需求的通过与否结论。
P表示部分通过，N/A表示不可测试或者用例不适用。
实际上，需求跟踪矩阵列出了一一对应的用例情况以避免遗漏，此表作用为传达需求的测试信息以供检查和审核。
需求覆盖率计算Y项/需求总数×
100％
3.2.2测试覆盖
需求/功能（或编号）用例个数执行总数未执行未/漏测分析和原因
实际上，测试用例已经记载了预期结果数据，测试缺陷上说明了实测结果数据和与预期结果数据的偏差；
因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差，列表的目的仅在于更好的查看测试结果。
测试覆盖率计算执行数/用例总数×
3.2缺陷的统计与分析
缺陷统计主要涉及到被测系统的质量，因此，这部分成为开发人员、质量人员重点关注的部分。
3.3.1缺陷汇总
被测系统系统测试回归测试总计
按严重程度
严重一般微小
按缺陷类型
用户界面一致性功能算法接口文档用户界面其他
按功能分布
功能一功能二功能三功能四功能五功能六功能七
最好给出缺陷的饼状图和柱状图以便直观查看。
俗话说一图胜千言，图标能够使阅读者迅速获得信息，尤其是各层面管理人员没有时间去逐项阅读文章。
图例
3.3.2缺陷分析
本部分对上述缺陷和其他收集数据进行综合分析
缺陷综合分析
缺陷发现效率＝缺陷总数/执行测试用时
可到具体人员得出平均指标
用例质量＝缺陷总数/测试用例总数×
缺陷密度＝缺陷总数/功能点总数
缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷最多，从而在今后开发注意避免并注意在实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。
测试曲线图
描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向
重要缺陷摘要
缺陷编号简要描述分析结果备注
3.3.3残留缺陷与未解决问题
残留缺陷
编号：
BUG号
缺陷概要：
该缺陷描述的事实
原因分析：
如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因
预防和改进措施：
弥补手段和长期策略
未解决问题
功能/测试类型：
测试结果：
与预期结果的偏差
缺陷：
具体描述
评价：
对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响
PARTⅤ测试结论与建议
报告到了这个部分就是一个总结了，对上述过程、缺陷分析之后该下个结论，此部分为项目经理、部门经理以及高层经理关注，请清晰扼要的下定论。
4.1测试结论
1．测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
2．对测试风险的控制措施和成效
3．测试目标是否完成
4．测试是否通过
5．是否可以进入下一阶段项目目标
4.2建议
1．对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响
2．可能存在的潜在缺陷和后续工作
3．对缺陷修改和产品设计的建议
4．对过程改进方面的建议
测试报告的内容大同小异，对于一些测试报告而言，可能将第四和第五部分合并，逐项列出测试项、缺陷、分析和建议，这种方法也比较多见，尤其在第三方评测报告中，此份报告模板仅供参考。
进行可用性测试的8个指南
引言:
在专业的web设计圈，可用性测试会议已经成为任何重点项目的一个基本组成部分。
对于关注品牌发展和产品开发的人群来来说，可用性测试是提供获取网站目标人群的反馈意见的宝贵机会，并且应该尽早开始.
但是你怎样才能从这些可用性测试会议中收获最多的东西呢？
1.选择你的课题
正如任何市场研究项目，结果和你需要测试的人一样，不要以你自己公司的人或者朋友以及家人作为测试人群。
可以去任何一家市场研究公司或者临时代理机构和他们沟通关于这个课题的参与者。
确定市场研究公司不会提供公司的名称或任何其它细节，从而避免这些东西影响参与者的判断。
2.可用性测试前期
就如生命中的任何事情，第一印象是最关键的，每个参与者必须很放松。
记住，可用性测试会议室通常是一个极端人造的环境，并且最有益和最具信息的结果就是，我们希望他们他们的行为就像他们在家里或者办公室里一样。
为如何到达可用性测试场所提供清晰的指引，必要的话，在当地会见这些参与者。
不要使用诸如“可用性测试”或者“市场调查”这样的术语，因为这些会干扰参与者并使他们紧张。
同样，确保参与者知道可用性测试时间需要多久，希望他们执行的任务类型是什么。
在最开始的问候和欢迎酒之后，通常会签署一些法定的条款。
这些用最通俗易懂的的英文来书写是很重要的，并且要尽可能的简短。
最后一件事是任何一个紧张的可用性测试项目需要的，就是给一份类似他们签署的东西的合同。
对于他们来说，你想要的全部就是保证这些测试是完全保密的，并且在测试过程中，作为我们测试结果的一部分允许生成数据。
所以告诉他们这些。
3.可用性测试的开始
在进入到关键任务之前，先让使用者熟悉环境，告诉他们网站的名称和URL，并且询问他们他们所喜欢的网站的类型是什么以及他们希望从他们喜欢的网站获得什么信息或者需求，从而来获得反馈。
将他们使用的任何术语和语句都做下笔记，这并不仅仅代表你正在认真地对待他们的反馈，而且对于关键的功能性和导航性的可用标签可以提供有用的东西。
其次，让他们看看他们所测试的网站，在他们熟悉网站之前度量他们最初的印象。
4.选择任务
设定任务对于一个新网站的成功是至关重要的，例如：
（某电子商务网站）
.购买东西
.付钱
.联系顾客
记住，你并不是在寻找自我信息。
网站的建立是有原因的-你的目标观众是不是在做你希望他们做的事情？
询问用户来建议任务也是一个很好的主意，虽然这会给出他们期望和需求的另一种暗示，但是这可能建议了新的功能性和优先性。
5.怎样来写任务
如果你给定他们一定的情节而不是指令，人们趋向于更自然的行为。
当给定他们任务时，你可能会使用这样的句子“事件A已经发生，你现在需要马上拨打公司电话-找到电话号码”。
这比“找到网站的联系我们的部分”要好得多。
6.提出任务
一个事件只给参与者一个任务，这样会让他们更快或者改变他们到达测试的路径。
如果使用者从测试外部需要进行用户输入（例如：
一个email地址让他们输入密码进入网站），在给他们提出的任务的表格中给出他们这些输入项。
者将给整个过程的所有元素提供有用的反馈，而不是简化网站。
7.在可用性测试过程中如何执行
记住正在测试的网站非常重要，不仅是你或者课题，而且包括任何你获取的有价值的反馈-确保参与者也要知道这一点。
如果他们什么也做不了，要让他们确信这不是他们的错。
在整个测试过程中你必须保持安静并且视而不见。
你不能通过提供线索，暗示方向或他们所说或所作事情的反应来改变测试结果，年给出的所有反馈都必须中立的。
不要摇头或发怒，但是可以诱惑！
唯一你能说话的时间就是帮助参与者给出他们的观点或者阐明的时候给予一个响应，如果存有疑惑，那就闭嘴！
让投资者参与项目，客户通常很难在测试过程中保持沉默，如果你的客户想在场，把他们安排在另一间有声音和视频连接的房间.
8.可用性测试之后
在完成所有的测试之后，你应当汇集尽可能多的信息，询问对网站的整体印象将使你能够判断是否已达到预期的期望，而不管参与者对于客户或者网站的观点在这个过程中是否发生了改变。
经常的询问建议-这不仅证明你对他们想法的价值的认同，而且能更好的洞察网站如何才能更好的支持用户。
最后，询问参与者他们所能记住的网站的结构和功能。
清晰的回忆将会确认网站结构的逻辑性并帮助识别任何你可能忽略的分类标签.
个人理解：
1，清晰明了，为什么要做这个测试，测试的目的性，和最后得到的结果。
如果是和外部参与的话请注意保密性和尽量减少由于外部的参与而对结果样本的影响.
2，有关前期准备的一些细节上的准备.
3，暖场和模拟用户环境等任务前期的动作.
4，回应第一步，理解和设计用户参与测试的测试任务以及完成.
5，在模拟和设计用户虚拟任务过程中的注意事项.
6，对于虚拟任务的执行.
7，过程控制，和注意事项.
8，测试后期的处理.
个人认为，此文章更多的是提供了一个测试的思路，而实际的状况却是千百万化的，每个网站的目的性和用户，以及前期的习惯的培养和养成都是不同的。
此文的价值和意义更多的在于是提供了思路和流程性发散的建议，而不是一个模式的套路。
测试能力成熟度模型
在衡量软件企业的是研发和管理能力的是CMM以及后面推出的CMMI，很多公司通过CMM的各个级别的认证，为企业承接项目添加了砝码，而对于软件测试行业来说，还没有出现一个认证机构，测评一个从事软件测试项目的企业具有的能力。
其实在几年前，已经推出的TMM（TestingMaturityModel），而我个人认为使用TCMM（TestingCapabilityMaturityModel）更为合适，TCMM也分为五级。
下面我们就看看是如何划分的，来评判一下各位同仁自己所在的公司，所在的级别。
TCMMLevel1：
Initial（初始级）
测试处于一个混乱的状态，还不能把测试同调试分开，在编码完成后才进行测试工作，测试和调试交叉在一起，目的就是发现软件中的bug。
测试的目的是表明程序没有错。
软件产品发布后没有质量保证。
缺乏测试相应的测试资源、例如专职测试人员和测试工具，测试人员没有经过培训。
这种类型的公司属于这个阶段，处于这个阶段的公司在测试中缺乏成熟的测试目标，测试处于可无可有的地位。
TCMMLevel2：
PhaseDefinition（阶段定义级）
测试同调试分开且把测试作做为编码后的一个阶段。
尽管测试别看做是一个有计划的行为，但是由于测试的不成熟仅在编码后制定测试计划，因为测试完全是针对于源代码的。
处于这个级别的公司测试的首要目的就是验证软件符合需求，会采用基本的测试技术和方法，由于测试处于软件生命周期的末尾环节，导致出现很多无法弥补的质量问题。
另外，在需求和设计阶段产生的很多问题被引入到编码中，但基于源代码的测试导致产生了很多的问题无法解决。
TCMMLevel3：
Integration（集成级）
测试不再是编码后的一个阶段，而是把测试贯穿在整个软件生命周期中。
就象软件测试领域的V模型，在需求阶段软件测试就介入了，测试是建立在满足用户或客户的需求上，根据需求设计测试用例和作为测试的依据。
处于这个级别的公司测试工作由具有独立的部门负责，测试部门与开发部门分开，独立开展工作。
测试部门有自己的技术培训并且有测试工具辅助进行测试工作。
尽管处于这个阶段的公司认识到了评审在质量控制中的重要性，但是并没有建立起有效的评审制度，还不能在软件生命周期的各个阶段实施评审制度。
没有建立起质量控制和质量度量标准。
TCMMLevel4：
ManagementandMeasurement（管理和度量级）
测试是一个度量和质量控制过程。
在软件生命周期中评审作为测试和软件质量控制的一部分，被测试的软件产品标准包括可靠性、可用性和可维护性等。
在测试项目中设计的测试用例别保存在测试用例数据库中便于重用和回归测试。
使用缺陷管理系统管理软件缺陷并划分缺陷的级别。
但是处于这个阶段的公司还没有建立起缺陷预防机制，且缺乏自动地对测试中产生的数据进行收集和分析的手段。
TCMMLevel5：
Optimization（优化级）
具有缺陷预防和质量控制的能力。
建立TCMM4基础上的测试公司已经建立起测试规范和流程，测试是受控的和被管理的。
而达到TCMM5的公司，则坚决贯彻落实测试规范和流程且不断地进行测试过程改进，在实践中运用缺陷预防和质量控制措施。
整个测试过程是被以往经验所驱动的，且是可信任和可靠的。
选择和评估测试工具存在一个既定的流程。
测试工具支持测试用例的运行和管理，辅助设计用例和维护测试相关资料，缺陷收集和分析，为缺陷预防和质量控制提供支持。
看了上面对于测试能力成熟度模型的分析，我们不难看出，目前我们国内从事软件测试的公司所处的级别，很多公司还处于2级或3级，这虽然与现在软件测试还是一个尚未成熟的行业有关，测试技术和测试工具还在发展之中，各个公司都在摸索阶段，从事测试外包的公司会好一些，这些公司为微软、IBM、Motorala等公司提供测试服务，基本上是按照委托方的要求或带领下进行测试工作，而国内做软件产品和承接软件开项目的公司，虽然有的建立了独立的测试团队，制定了测试规范和测试流程或者评审制度，但是测试工作还是在摸索阶段，现在是百家争鸣、百花齐放的阶段，除了引入国外的测试理论之外，目前国内也有很多人在研究测试理论，但是还没有出来领军人物。
很多公司做软件测试时，几乎大多没有现成的经验可参考，所以目前急需建立软件测试的行业标准，推动测试行业的发展，让测试有依据可查。
测试与改错
编程大师说：
“任何一个程序，无论它多么小，总存在着错误。
”
初学者不相信大师的话，他问：
“如果一个程序小得只执行一个简单的功能，那会怎样？
“这样的一个程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生一个错误。
但初学者不满足，他问：
“如果操作系统不失效，那么会怎样？
“没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生一个错误。
初学者仍不满足，再问：
“如果硬件不失效，那么会怎样？
大师长叹一声道：
“没有不失效的硬件。
但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是一个错误。
没有错误的程序世间难求。
[James1999]
错误是一种严重的程序缺陷。
测试的目的是为了发现尽可能多的缺陷，并期望通过改错来把缺陷统统消灭，以期提高软件的质量。
但关于测试与改错实在没有什么高明的方法值得大书特书，也不能表现出程序员的聪明才智。
相反地，它们带来了更多的牢骚与痛苦。
因此在教学和开发实践中，测试与改错总是被当作万般无奈的工作踢到角落里。
医生可以把他的错误埋葬在地下了事，但程序员不能。
我们必须要学会测试与改错，并且把测试与改错工作做好。
7.1对测试的理解
测试的道理并不深奥，计算机专业人员都应该明白。
但就是这么简单的事，计算机专业的博士们也未必都已经理解。
有一天，一位比我聪明，编程比我快，学习能力比我强的计算机专业博士生恭恭敬敬地请我坐好，并且史无前例地削了苹果请我吃，为的是向我请教“软件工程”问题。
你必定以为这位仁兄好学之极。
非也，我和他同事三年来从未探讨过“软件工程”问题。
只因为他明天要去应聘，参加面试，生怕被人问倒，就央我当晚为他恶补一把“软件工程”。
他还特地问我“什么是白盒测试和黑盒测试？
应该由谁来执行？
”（有公司曾经这样面试应聘者）当我解释完测试的道理时，他叹了一口气说：
“这些玩意儿我读大学十年来都没搞过，怎么能讲得出道理来。
唉，就去碰碰运气吧。
”我有“兔死狐悲”的感觉。
我们这一群博士生三年来尽干些自欺欺人的事，到毕业时学问既不深也不博。
个个意志消沉，老气横秋。
长此以往，总有一天招聘会的大门前将贴出标语“博士与狗不得入内”。
以下是关于测试的几个重要观念。
7.1.1测试的目的
测试的目的是为了发现尽可能多的缺陷。
这里缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等等。
测试总是先假设程序中存在缺陷，再通过执行程序来发现并最终改正缺陷。
理解测试的目的是个很重要的意识问题。
如果说测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。
这样的测试是虚假的。
目前高校的科技成果鉴定会普遍存在类似的虚假现象。
我在读硕士时就亲身经历过这样的事。
我们的项目是研究集成电路制造过程中的成品率问题。
当时国内大多数工厂的集成电路成品率只有百分之几，我编写的示例程序可以将集成电路的成品率优化到98%。
示例效果是如此的好，以致一位评委（某厂的总工程师）不无讽刺地说：
“采用你们的成果，我们可要发大财了。
”这个项目就轻易地通过了鉴定，并且不久后获得了电子工业部科技进步二等奖。
这就象在考试时通过作弊取得了好成绩而被表扬。
我那时尚且纯真，羞愧之余，不禁对高校科研成果的水平和真实性大失所望（现在我已不再失望，因为很少抱希望）。
一个成功的测试示例在于发现了至今尚未发现的缺陷。
测试并不仅是个技术问题，更是个职业道德问题。
7.1.2测试的心理要求
测试
升级会员 