测试计划及测试报告
测试计划:
1.测试计划的定义:
测试计划,描述了要进行的测试活动的范围、方法、资源和进度的文档;是对整个信息系统应用软件组装测试和确认测试。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险,保障计划的顺利实施。
2.测试计划的目的:
(1)为测试各项活动制定一个现实可行的、综合的计划,包括每项测试活动的对象、范围、方法、进度和预期结果。
(2)为项目实施建立一个组织模型,并定义测试项目中每个角色的责任和工作内容。
(3)开发有效的测试模型,能正确地验证正在开发的软件系统。
(4)确定测试所需要的时间和资源,以保证其可获得性、有效性。
(5)确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。
(6)识别出测试活动中各种风险,并消除可能存在的风险,降低由不可能消除的风险所带来的损失。
3.测试计划的作用:
通常分内部作用和外部作用,内部作用有以下3种:
(1)作为测试计划的结果,让相关人员和开发人员来评审。
(2)存储计划执行的细节,让测试人员进行同行评审。
(3)存储计划进度表、测试环境等更多的信息。
测试计划的外部作用是为顾客提供一种信心,通常向顾客交代有关测试过程、人员的技能、资源、使用的工具等信息。
4.测试范围:
(1)测试计划和设计:根据软件需求说明书,制定测试计划,测试方案,包括收集测试方法,测试用例,测试工具等。
(2)单元测试:根据系统详细设计,制定测试计划,测试方案。此项由开发人员自测。
(3)集成测试:将各个模块进行组合测试,保证所有功能和界面都正确。对产品重点模块进行负载测试,确保软件性能达到软件需求说明书的要求
5.测试输出文档:
文档 |
使用工具 |
提交日期 |
责任人 |
《测试计划》 |
Word |
|
测试经理 |
《测试用例》 |
QC |
|
测试经理 |
《缺陷报告》 |
QC |
|
测试经理 |
《测试报告》 |
Excel |
|
测试经理 |
- 项目的测试人员、职位、工作职责
角色 |
姓名 |
工作内容 |
测试经理 |
|
编写测试计划 缺陷管理 测试结果分析 |
黑盒测试工程师 |
|
编写测试用例 执行测试 报告缺陷 |
自动化测试工程师 |
|
编写脚本 自动化测试执行 |
性能测试工程师 |
|
分析软件功能 开发脚本 性能测试执行 |
- 需要配合的部门与人员
角色 |
姓名 |
工作内容 |
开发人员 |
|
协助搭建测试环境 |
业务人员 |
|
协助测试人员理解需求,提供业务帮助 |
6.测试流程:
如图:
**冒烟测试:
1.冒烟测试是什么?
针对每个版本或每次需求变更后,在正式测试前,对产品或系统的一次简单的验证性测试。
2.冒烟测试的目的
为正式测试前,验证是否产品或系统的主要需求或预置条件是否存在bug。
3.冒烟测试怎么做?
最好的方法,设计出自动化测试脚本,每一次版本更新后都可以去执行脚本验证一下。
编写测试计划 --- 评审测试计划 --- 编写测试用例 ---- 评审测试用例 ---- 执行测试阶段(冒烟测试,系统测试)----- 分析和总结测试结果 ----- 完成测试
7.测试方法:
一、按是否查看程序内部结构分为:
1、黑盒测试(Black Box Testing):
黑盒测试是根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。简单来说,这种测试只关心输入和输出的结果,并不考虑程序的源代码。黑盒测试分为功能测试和性能测试:
1)功能测试(function testing),是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求。包括逻辑功能测试、界面测试、易用性测试和兼容性测试。
2)性能测试(performance testing),软件的性能主要有时间性能和空间性能两种。其中,时间性能主要指软件的一个具体事务的响应时间,而空间性能主要指软件运行时所消耗的系统资源。
2、白盒测试(White Box Testing):
白盒测试是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时,需要测试软件产品的内部结构和处理过程,不需测试软件产品的功能。与黑盒测试相反,这种测试就要研究程序里面的源代码和程序结构。
二、按是否运行程序分为
1、静态测试(static testing):
静态测试指测试不运行的部分,只是静态地检查程序代码、界面或文档可能存在的错误的过程。例如测试产品说明书,对此进行检查和审阅.。
2、动态测试(dynamic testing):
动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。具体操作就是输入相应的测试数据,检查输出结果和预期结果是否相符的过程。
三、按阶段分为:
1、单元测试(Unit Testing):
单元测试是最微小规模的测试,测试的是某个功能或代码块。典型地由程序员而非测试员来做,因为它需要知道内部程序设计和编码的细节知识。
2、集成测试(Integration Testing):
集成测试是指一个应用系统的各个部件的联合测试,以决定他们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前,单元测试需要完成。
3、系统测试(System Testing):
系统测试是将整个软件系统看做一个整体进行测试,包括对功能、性能,以及软件所运行的软硬件环境进行测试
4、验收测试(Accept Testing):
验收测试是基于客户或最终用户的规格书的最终测试,或基于用户一段时间的使用后,看软件是否满足客户要求。一般从功能、用户界面、性能、业务关联性进行测试。
5、回归测试(Regression testing):
回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再次出现。
1、黑盒测试(Black Box Testing):
黑盒测试是根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。简单来说,这种测试只关心输入和输出的结果,并不考虑程序的源代码。黑盒测试分为功能测试和性能测试:
1)功能测试(function testing),是黑盒测试的一方面,它检查实际软件的功能是否符合用户的需求。包括逻辑功能测试、界面测试、易用性测试和兼容性测试。
2)性能测试(performance testing),软件的性能主要有时间性能和空间性能两种。其中,时间性能主要指软件的一个具体事务的响应时间,而空间性能主要指软件运行时所消耗的系统资源。
2、白盒测试(White Box Testing):
白盒测试是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时,需要测试软件产品的内部结构和处理过程,不需测试软件产品的功能。与黑盒测试相反,这种测试就要研究程序里面的源代码和程序结构。
二、按是否运行程序分为
1、静态测试(static testing):
静态测试指测试不运行的部分,只是静态地检查程序代码、界面或文档可能存在的错误的过程。例如测试产品说明书,对此进行检查和审阅.。
2、动态测试(dynamic testing):
动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。具体操作就是输入相应的测试数据,检查输出结果和预期结果是否相符的过程。
三、按阶段分为:
1、单元测试(Unit Testing):
单元测试是最微小规模的测试,测试的是某个功能或代码块。典型地由程序员而非测试员来做,因为它需要知道内部程序设计和编码的细节知识。
2、集成测试(Integration Testing):
集成测试是指一个应用系统的各个部件的联合测试,以决定他们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前,单元测试需要完成。
3、系统测试(System Testing):
系统测试是将整个软件系统看做一个整体进行测试,包括对功能、性能,以及软件所运行的软硬件环境进行测试
4、验收测试(Accept Testing):
验收测试是基于客户或最终用户的规格书的最终测试,或基于用户一段时间的使用后,看软件是否满足客户要求。一般从功能、用户界面、性能、业务关联性进行测试。
5、回归测试(Regression testing):
回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再次出现。
测试报告:
1.测试报告是什么:
测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力;
一份详细的测试报告包含足够的信息,包括产品质量和测试过程的评价,测试报告基于测试中的数据采集以及对最终的测试结果分析。
2.测试报告内容:
· 首页
· 引言(目的、背景、缩略语、参考文献)
· 测试概要(测试方法、范围、测试环境、工具)
· 测试结果与缺陷分析(功能、性能)
· 测试结论与建议(项目概况、测试时间 测试情况、结论性能汇总)
· 附录(缺陷统计)
缺陷报告:
1.bug的生命周期:
bug的生命周期是指在Bug管理工具中,一个bug被发现到这个bug被关闭的过程,Bug的生命周期被分成的阶段是新建、确认,解决,重新验证,关闭,重新打开。
2.bug优先级:
按照bug严重程度如果分为4级:
系统崩溃 严重 一般 建议
1 – 非常严重的缺陷,例如,软件的意外退出甚至操作系统崩溃,造成数据丢失。
2 – 较严重的缺陷,例如,软件的某个菜单不起作用或者产生错误的结果;
3 - 软件一般缺陷,例如,本地化软件的某些字符没有翻译或者翻译不准确;
4 - 软件界面的细微缺陷,例如,某个控件没有对齐,某个标点符号丢失等;
2 – 较严重的缺陷,例如,软件的某个菜单不起作用或者产生错误的结果;
3 - 软件一般缺陷,例如,本地化软件的某些字符没有翻译或者翻译不准确;
4 - 软件界面的细微缺陷,例如,某个控件没有对齐,某个标点符号丢失等;
bug修正优先级如果分为4级:
最高 高 中 低
1 –最高优先级,例如,软件的主要功能错误或者造成软件崩溃,数据丢失的缺陷。
2 – 较高优先级,例如,影响软件功能和性能的一般缺陷;
3 -一般优先级,例如,本地化软件的某些字符没有翻译或者翻译不准确的缺陷;
4 – 低优先级,例如,对软件的质量影响非常轻微或出现几率很低的缺陷;
2 – 较高优先级,例如,影响软件功能和性能的一般缺陷;
3 -一般优先级,例如,本地化软件的某些字符没有翻译或者翻译不准确的缺陷;
4 – 低优先级,例如,对软件的质量影响非常轻微或出现几率很低的缺陷;
3.缺陷报告的要点:
1、缺陷概要
2、简要的缺陷描述
3、产生缺陷的先决条件及重现的步骤
4、实际结果
5、预期结果
6、严重性及优先级
7、必要的屏幕截图,及AUT日志
8、应用程序测试在版本上产生的错误
9、标记该缺陷出现的频率。 经常/偶尔
缺陷报告应该使开发人员获得缺陷重现的所有信息。可以从以下有几点考虑:
1、在整理每个缺陷文档的之前先检查一遍。问问自己以下几个问题:
- 总结是否描述清楚了缺陷的要点?
- 我是否将所有的缺陷的信息整理好了?
- 我还可以再做什么让开发人员更了解问题所在?
- 严重性和优先级是否合理?
- 我是否添加了过多附件? 所有添加的是否都是必须的?
2、你经常会遇到一些不能重现或者在所有的环境中都不能重现的缺陷(操作系统,数据回库,等等)。答这样的问题你要提出。那些缺陷很可能被标记无效。要加倍消息这样的报告,确保重现的每条信息都完整。
3、 如果该缺陷第二次被发现。 如果你延迟,你很可能会忘记一些信息或者其他,那样的话你将要花更多时间去重现这个问题。
4、当你整个一个或多个应用程序时,确保你指定的版本正确。
2、简要的缺陷描述
3、产生缺陷的先决条件及重现的步骤
4、实际结果
5、预期结果
6、严重性及优先级
7、必要的屏幕截图,及AUT日志
8、应用程序测试在版本上产生的错误
9、标记该缺陷出现的频率。 经常/偶尔
缺陷报告应该使开发人员获得缺陷重现的所有信息。可以从以下有几点考虑:
1、在整理每个缺陷文档的之前先检查一遍。问问自己以下几个问题:
- 总结是否描述清楚了缺陷的要点?
- 我是否将所有的缺陷的信息整理好了?
- 我还可以再做什么让开发人员更了解问题所在?
- 严重性和优先级是否合理?
- 我是否添加了过多附件? 所有添加的是否都是必须的?
2、你经常会遇到一些不能重现或者在所有的环境中都不能重现的缺陷(操作系统,数据回库,等等)。答这样的问题你要提出。那些缺陷很可能被标记无效。要加倍消息这样的报告,确保重现的每条信息都完整。
3、 如果该缺陷第二次被发现。 如果你延迟,你很可能会忘记一些信息或者其他,那样的话你将要花更多时间去重现这个问题。
4、当你整个一个或多个应用程序时,确保你指定的版本正确。
4.bug的处理:
5. bug不同时期的状态:
缺陷报告样式: