软件测试基础要点总结
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
测试用例部分逐一列出各个测试用例。
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例部分
测试用例通常包含的信息：
用例标识和用例名称
内容描述
前提条件
执行步骤
预期结果
评价准则
用例设计人员和设计时间
用例执行人员和执行时间
c.对每个残留的缺陷,限制,局限,描述如下：
1对软件和系统性能的影响，包括没有满足的需求
2为了更正它，会对软件和系统设计产生的影响。
3推荐的解决方法/策略
8.软件特性software feature
软件项的显著特性。（如功能、性能或可移植性等）。
软件项software item
源代码、目标代码、作业控制代码、控制数据或这些项的集合。
3．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．
测试原则
①应尽早和不断地进行软件“测试”。
②测试用例中，不仅要选择合理的输入数据，还要选择不合理的输入数据。
③在开发各阶段应事先分别制定出相应的测试计划，在测试开始后应严格执行，防止随意性。
④对发现错误较多的程序模块，应进行重点测试。
5.1.14进度（本计划的第14章）
包括在软件项目进度中规定的测试里程碑以及所有测试项传递时间。
定义所需的新的测试里程碑，估计完成每项测试任务所需的时间，为每项测试任务和测试里程碑规定进度，对每项测试资源规定使用期限。
5.1.15风险和应急（本计划的第15章）
预测测试计划中的风险，规定对各种风险的应急措施（如：延期传递的测试项可能需要加夜班来赶上规定的进度。）
⑤避免程序员测试自己的程序。
⑥用穷举测试是不现实的，一般通过设计测试用例，充分覆盖所有条件或所有语句即可。
⑦长期妥善保存测试计划、测试用例、出错统计和有关的分析报告。
2.测试用例文档
测试用例文档通常是由简介和测试用例两部分组成：
简介部分编制了测试目的、测试范围、定义术语、参考文档等，这个与测试计划是一致的。
确认测试又称有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础
14.GUI测试（ui测试）
1.窗体是否能够基于相关的输入或菜单命令适当的打开
（2）测试用例说明：列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试用例时，对测试规程的各种限制。将测试用例与测试设计分开，可以使它们用于多个设计并能在其它情形下重复使用。
（3）测试规程说明：规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。
测试报告包括四类文件：
（1）测试项传递报告：指明在开发组和测试组独立工作的情况下或者在希望正式开始测试的情况下为进行测试而被传递的测试项。
（2）测试日志：测试组用于记录测试执行过程中发生的情况。
（3）测试事件报告：描述在测试执行期间发生并需进一步调查的一切事件。
（4）测试总结报告：总结与测试设计说明有关的测试活动。
这些文件同其它文件在编制方面的关系以及同测试过程的对应关系如图1所示。
10.测试计划要点内容：
1测试计划名称
2引言：
3测试项
测试项test item
作为测试对象的软件项。
9.测试计划描述测试活动的范围、方法、资源和进度。它规定被测试的项、被测试的特性、应完成的测试任务、担任各项工作的人员职责及与本计划有关的风险等。
测试说明包括三类文件：
（1）测试设计说明：详细描述测试方法，规定该设计及其有关测试所包括的特性，还规定完成测试所需的测试用例和测试规程，并规定特性的通过准则。
2.窗体是否能够改变大小、移动和滚动
3.窗体的数据是否能够利用鼠标、功能键、方向箭头和键盘操作
4.当窗体被覆盖并重新调用后，窗体是否能够正确再生
5.窗体相关的功能是否可以操作
6.是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用
7.显示多wenku.baidu.com体时，窗体名称是否能够正确表示
5.1.16批准（本计划的第16章）
规定本计划必须由哪些人（姓名和职务）审批。为签名和填写日期留出位置。
11.软件测试原则
所有的软件测试都应追溯到用户需求
应当把“尽早地和不断地进行软件测试”作为软件测试人的座右铭
完全测试是不可能的，测试需要终止
测试无法显示系统所有潜在的缺陷
充分注意测试中的群集现象
程序员应避免检查自己的程序
④在测试计算器时若发现电池没电会导致计算不正确，而产品说明书是假定电池一直都有电的，从而发现第四种类型的错误。
⑤软件测试员如果发现某些地方不对，比如测试员觉得按键太小、“=”键布置的位置不好按、在亮光下看不清显示屏等，无论什么原因，都要认定为缺陷。
4.缺陷报告里通常包含：缺陷标识、所属系统、所属模块、版本号、严重程度、优先级、测试种类、缺陷概述、缺陷详述以及开发人员意见以及其它内容。、
5.1.10测试任务（本计划的第10章）
指明执行测试所需的任务集合，指出任务音的一切依赖关系和所需的一切特殊技能。
5.1.11环境要求（本计划的第11章）
规定测试环境所必备的和希望的的性质。包括：硬件、通信和系统软件的物理特征、使用方式以及任何其它支撑测试所需的软件或设备，指出所需的特殊测试工具及其它测试要求（如出版物或办公场地等）。指出测试组目前还不能得到的所有要求的来源。
5.1.6方法（本计划的第6章）
描述测试的总体方法，规定测试指定特性组志需的主要活动、、技术和工具，应详尽地描述方法，以便列出主要的测试任务，并估计执行各项任务所需的时间。规定所希望的电低程度的测试彻底性，指明用于判断测试彻底性的技术（如：检查哪些语句至少执行过一次）。指出对测试的主要限制，例如：测试项可用性、测试资源的可用性和测试截止期限等。
4被测试的特性
5不被测试的特性
6方法
7项通过准则
8暂停标准和再启动要求
9应提供的测试文件
10测试任务
11环境要求
12职责
13人员和训练要求
14进度
15风险和应急
16批准
引言（本计划的第2章）
归纳所要求测试的软件项和软件特性，可以包括系统目标、背景、范围及引用材料等。
在最高层测试计划中，如果存在下述文件，则需要引用它们：项目计划、质量保证计划、有关的政策、有关的标准等。
测试报告是测试阶段最后的文档产出物，一份详细的测试报告包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。比如覆盖率分析、缺陷分析。
7.
这部分将被分成下面几段来对测试结果进行概述。
.1
本段应该包括：
a.根据本文档中的测试结果对被测软件的整体评价。
b.任何在测试中检查到的残留的不足,限制,局限。可以用问题/修改报告来提供缺陷信息。
缺陷提交报告主要供两类人阅读，即软件开发人员和项目管理者。
5.常用软件缺陷工具
testDirector
testmanager
专业缺陷管理工具
bugzilla
6.测试报告文档
测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。
5.1.7项通过准则（本计划的第7章）
规定各测试项通过测试的标准。
5.1.8暂停标准和再启动要求（本计划第8章）
规定用于暂停全部或部分与本计划有关的测试项的测试活动的标准。规定当测试再启动时必须重复的测试活动。
5.1.9应提供的测试文件（本计划的第9章）
规定测试完成后所应递交的文件，这些文件可以是前述八个文件的全部或者部分。
5.1.3测试项（本计划的第3章）
描述被测试的对象，包括其版本、修订级别，并指出在测试开始之前对逻辑或物理变换的要求。
5.1.4被测试的特性（本计划的第4章）
指明所有要被测试的软件特性及其组合，指明每个特性或特性组合有关的测试设计说明。
5.1.5不被测试的特性（本计划的第5章）
指出不被测试的所有特性和特性的有意义的组合及其理由。
8.活动窗体是否能够被反显加亮
9.多用户联机时所有窗体是否能够实时更新
10.鼠标无规则点击时是否会产生无法预料的结果
11.窗体声音及提示是否符合既定编程规则
从宏观的角度讲，软件测试过程一般可划分为单元测试、集成测试、验收测试和系统测试等几个主要测试阶段。
1.测试计划注意事项
1．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况；
2．测试计划一旦制定下来，并不就是一成不变的，随着软件需求、软件开发、人员流动等发生变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．
5.1.12职责（本计划的第12章）
指出负责管理、设计、准备、执行、监督、检查和仲裁的小组。另外指出负责提供
5.1.3中指出的测试项和在5.1.11中指出的环境要求的小组。
这些小组可以包括开发人员、测试人员、操作员、用户代表、数据管理员和质量保证人员。
5.1.13人员和训练要求（本计划的第13章）
指明测试人员应有的水平以及为掌握必要技能可供选择的训练科目。
其它内容
3.软件缺陷
缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有：
①软件没有实现产品规格说明所要求的功能模块软件中；
②出现了产品规格说明指明不应该出现的错误；
③软件实现了产品规格说明没有提到的功能模块；
④软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；
⑤软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。
尽量避免测试的随意性，应从工程的角度理解软件测试，它是有组织、有计划、有步骤的活动
12.软件测试对象
程序
数据
文档
过程
硬件
网络
13.确认测试
确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样
测试用例：
以计算器为例
①计算器的产品规格说明定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也是第一种类型的缺陷。
②产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷。
③如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例部分
测试用例通常包含的信息：
用例标识和用例名称
内容描述
前提条件
执行步骤
预期结果
评价准则
用例设计人员和设计时间
用例执行人员和执行时间
c.对每个残留的缺陷,限制,局限,描述如下：
1对软件和系统性能的影响，包括没有满足的需求
2为了更正它，会对软件和系统设计产生的影响。
3推荐的解决方法/策略
8.软件特性software feature
软件项的显著特性。（如功能、性能或可移植性等）。
软件项software item
源代码、目标代码、作业控制代码、控制数据或这些项的集合。
3．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．
测试原则
①应尽早和不断地进行软件“测试”。
②测试用例中，不仅要选择合理的输入数据，还要选择不合理的输入数据。
③在开发各阶段应事先分别制定出相应的测试计划，在测试开始后应严格执行，防止随意性。
④对发现错误较多的程序模块，应进行重点测试。
5.1.14进度（本计划的第14章）
包括在软件项目进度中规定的测试里程碑以及所有测试项传递时间。
定义所需的新的测试里程碑，估计完成每项测试任务所需的时间，为每项测试任务和测试里程碑规定进度，对每项测试资源规定使用期限。
5.1.15风险和应急（本计划的第15章）
预测测试计划中的风险，规定对各种风险的应急措施（如：延期传递的测试项可能需要加夜班来赶上规定的进度。）
⑤避免程序员测试自己的程序。
⑥用穷举测试是不现实的，一般通过设计测试用例，充分覆盖所有条件或所有语句即可。
⑦长期妥善保存测试计划、测试用例、出错统计和有关的分析报告。
2.测试用例文档
测试用例文档通常是由简介和测试用例两部分组成：
简介部分编制了测试目的、测试范围、定义术语、参考文档等，这个与测试计划是一致的。
确认测试又称有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础
14.GUI测试（ui测试）
1.窗体是否能够基于相关的输入或菜单命令适当的打开
（2）测试用例说明：列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试用例时，对测试规程的各种限制。将测试用例与测试设计分开，可以使它们用于多个设计并能在其它情形下重复使用。
（3）测试规程说明：规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。
测试报告包括四类文件：
（1）测试项传递报告：指明在开发组和测试组独立工作的情况下或者在希望正式开始测试的情况下为进行测试而被传递的测试项。
（2）测试日志：测试组用于记录测试执行过程中发生的情况。
（3）测试事件报告：描述在测试执行期间发生并需进一步调查的一切事件。
（4）测试总结报告：总结与测试设计说明有关的测试活动。
这些文件同其它文件在编制方面的关系以及同测试过程的对应关系如图1所示。
10.测试计划要点内容：
1测试计划名称
2引言：
3测试项
测试项test item
作为测试对象的软件项。
9.测试计划描述测试活动的范围、方法、资源和进度。它规定被测试的项、被测试的特性、应完成的测试任务、担任各项工作的人员职责及与本计划有关的风险等。
测试说明包括三类文件：
（1）测试设计说明：详细描述测试方法，规定该设计及其有关测试所包括的特性，还规定完成测试所需的测试用例和测试规程，并规定特性的通过准则。
2.窗体是否能够改变大小、移动和滚动
3.窗体的数据是否能够利用鼠标、功能键、方向箭头和键盘操作
4.当窗体被覆盖并重新调用后，窗体是否能够正确再生
5.窗体相关的功能是否可以操作
6.是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用
7.显示多wenku.baidu.com体时，窗体名称是否能够正确表示
5.1.16批准（本计划的第16章）
规定本计划必须由哪些人（姓名和职务）审批。为签名和填写日期留出位置。
11.软件测试原则
所有的软件测试都应追溯到用户需求
应当把“尽早地和不断地进行软件测试”作为软件测试人的座右铭
完全测试是不可能的，测试需要终止
测试无法显示系统所有潜在的缺陷
充分注意测试中的群集现象
程序员应避免检查自己的程序
④在测试计算器时若发现电池没电会导致计算不正确，而产品说明书是假定电池一直都有电的，从而发现第四种类型的错误。
⑤软件测试员如果发现某些地方不对，比如测试员觉得按键太小、“=”键布置的位置不好按、在亮光下看不清显示屏等，无论什么原因，都要认定为缺陷。
4.缺陷报告里通常包含：缺陷标识、所属系统、所属模块、版本号、严重程度、优先级、测试种类、缺陷概述、缺陷详述以及开发人员意见以及其它内容。、
5.1.10测试任务（本计划的第10章）
指明执行测试所需的任务集合，指出任务音的一切依赖关系和所需的一切特殊技能。
5.1.11环境要求（本计划的第11章）
规定测试环境所必备的和希望的的性质。包括：硬件、通信和系统软件的物理特征、使用方式以及任何其它支撑测试所需的软件或设备，指出所需的特殊测试工具及其它测试要求（如出版物或办公场地等）。指出测试组目前还不能得到的所有要求的来源。
5.1.6方法（本计划的第6章）
描述测试的总体方法，规定测试指定特性组志需的主要活动、、技术和工具，应详尽地描述方法，以便列出主要的测试任务，并估计执行各项任务所需的时间。规定所希望的电低程度的测试彻底性，指明用于判断测试彻底性的技术（如：检查哪些语句至少执行过一次）。指出对测试的主要限制，例如：测试项可用性、测试资源的可用性和测试截止期限等。
4被测试的特性
5不被测试的特性
6方法
7项通过准则
8暂停标准和再启动要求
9应提供的测试文件
10测试任务
11环境要求
12职责
13人员和训练要求
14进度
15风险和应急
16批准
引言（本计划的第2章）
归纳所要求测试的软件项和软件特性，可以包括系统目标、背景、范围及引用材料等。
在最高层测试计划中，如果存在下述文件，则需要引用它们：项目计划、质量保证计划、有关的政策、有关的标准等。
测试报告是测试阶段最后的文档产出物，一份详细的测试报告包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。比如覆盖率分析、缺陷分析。
7.
这部分将被分成下面几段来对测试结果进行概述。
.1
本段应该包括：
a.根据本文档中的测试结果对被测软件的整体评价。
b.任何在测试中检查到的残留的不足,限制,局限。可以用问题/修改报告来提供缺陷信息。
缺陷提交报告主要供两类人阅读，即软件开发人员和项目管理者。
5.常用软件缺陷工具
testDirector
testmanager
专业缺陷管理工具
bugzilla
6.测试报告文档
测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。
5.1.7项通过准则（本计划的第7章）
规定各测试项通过测试的标准。
5.1.8暂停标准和再启动要求（本计划第8章）
规定用于暂停全部或部分与本计划有关的测试项的测试活动的标准。规定当测试再启动时必须重复的测试活动。
5.1.9应提供的测试文件（本计划的第9章）
规定测试完成后所应递交的文件，这些文件可以是前述八个文件的全部或者部分。
5.1.3测试项（本计划的第3章）
描述被测试的对象，包括其版本、修订级别，并指出在测试开始之前对逻辑或物理变换的要求。
5.1.4被测试的特性（本计划的第4章）
指明所有要被测试的软件特性及其组合，指明每个特性或特性组合有关的测试设计说明。
5.1.5不被测试的特性（本计划的第5章）
指出不被测试的所有特性和特性的有意义的组合及其理由。
8.活动窗体是否能够被反显加亮
9.多用户联机时所有窗体是否能够实时更新
10.鼠标无规则点击时是否会产生无法预料的结果
11.窗体声音及提示是否符合既定编程规则
从宏观的角度讲，软件测试过程一般可划分为单元测试、集成测试、验收测试和系统测试等几个主要测试阶段。
1.测试计划注意事项
1．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况；
2．测试计划一旦制定下来，并不就是一成不变的，随着软件需求、软件开发、人员流动等发生变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．
5.1.12职责（本计划的第12章）
指出负责管理、设计、准备、执行、监督、检查和仲裁的小组。另外指出负责提供
5.1.3中指出的测试项和在5.1.11中指出的环境要求的小组。
这些小组可以包括开发人员、测试人员、操作员、用户代表、数据管理员和质量保证人员。
5.1.13人员和训练要求（本计划的第13章）
指明测试人员应有的水平以及为掌握必要技能可供选择的训练科目。
其它内容
3.软件缺陷
缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有：
①软件没有实现产品规格说明所要求的功能模块软件中；
②出现了产品规格说明指明不应该出现的错误；
③软件实现了产品规格说明没有提到的功能模块；
④软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；
⑤软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。
尽量避免测试的随意性，应从工程的角度理解软件测试，它是有组织、有计划、有步骤的活动
12.软件测试对象
程序
数据
文档
过程
硬件
网络
13.确认测试
确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样
测试用例：
以计算器为例
①计算器的产品规格说明定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也是第一种类型的缺陷。
②产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷。
③如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷