某某系统软件测试计划软件测试面试必备.docx

资源描述

某某系统软件测试计划软件测试面试必备.docx

《某某系统软件测试计划软件测试面试必备.docx》由会员分享，可在线阅读，更多相关《某某系统软件测试计划软件测试面试必备.docx（33页珍藏版）》请在冰豆网上搜索。

某某系统软件测试计划软件测试面试必备.docx

某某系统软件测试计划软件测试面试必备

_软件测试面试必备

某某某某某某系统

软件测试计划

版本V1.0

软件开发部门：

BTEST

软件测试部门：

Z**第****小组

编写：

******日期：

****年**月**日

审核：

**老师日期：

批准：

**老师日期：

版本历史

版本/状态

作者

参和者

起止日期

备注

1.0

张三

2010-7-15

建立文档

1.2

张三

2010-7-30

修订文档

2.2

张三

2010-8-15

修订文档

版本历史是指测试计划修改的历史.

某某某某某公司

二00八年

测试计划有三重境界：

第一重：

什么都有用

第二重：

什么都没用

第三重：

仅部分有用

计划:

达成统一认识,对过程控制

一、项目简介2

1.1、目的2目的（文档目的,测试目的）

1.2、背景2

1.2文档受众:

2.适用对象

开发经理

测试经理

公司高层领导

二、测试参考文档和测试提交文档4

文档写法一定要统一（不用写扩展名.doc,具体哪一个文件）

三、术语介绍：

所有软件测试的专业词汇都要写！

（如果是第三方，或者是用户要看测试计划，要保证用户看懂）如：

缺陷的定义，功能测试，压力测试，性能测试等

看hf_____________________________________________________________________________________________________________________________

（测试模型（这个看受众用户,如果用户是开发团队,是第三方测试,要写清楚）

测试架构（测试模型）1.为什么选择模型2.模型细化,每个阶段做什么->输出好几版本:

V,螺旋（边测边改,1个计划,死亡线）用例结果带给下一个版本H模型）

四、测试需求测试范围

依据需求分析,找测试需求

五、测试策略

1.值域测试:

2.数据库测试3.功能测试4.裸机测试5.版本验证测试->冒烟测试6界面测试

7.可用性测试8.强度测试9.安装测试10.安全性测试11.加密测试12.接口测试13.集成测试

14.配置测试15.压力测试16.容量测试17.故障转移和恢复性测试18.负载测试

验收测试

注意:

测试结构:

功能,性能不属于策略,黑白盒也不属于策略,测试阶段也不属于策略.

六、严重程度、优先级的定义（可写在这里））

1）用例的优先级

2）缺陷的优先级

3）缺陷的严重程度

七、测试进度5模型->对规模再细化阶段->里程碑->具体每天

里程碑-----要加评审（时间安排,考虑并行的情况:

需求计划在评审中,写用例,搭建环境,时间紧且人员充足的情况下这样做）

需求分析

需求评审

测试计划

计划评审

编写用例

用例评审

执行用例

测试总结

八、测试资源6

系统:

是实体机还是虚拟机,要写清楚

硬件:

不用网络就不写.游戏:

要写显卡

硬盘工具:

研发人员开发,内部开发的工具.

九、系统风险（不写）

1系统风险

1.1影响计划的潜在因素

1.2应急措施

1.3测试的局限性

2测试通过标准

2.1测试模块通过标准

2.2系统测试通过标准（ISO9000规定,有些公司会更严格一些）

当没有发现致命性错误，严重功能性错误数量小于测试用例总数的2%，一般功能性错误数量小于测试用例总数的5%，则认为系统通过本次测试，但要以测试结果评审会的评审结果为最后标准

十、附录：

一般添加模板：

计划模板，用例模板，日志模板，缺陷报告模板，会议记录（记录人，参和人，评审人）

测试说明:

各种模板,如何使用,如何做需求分析的?

1.简介

1.1测试目的:

1.确定项目的信息和软件构件。

2.需求

3.策略

4.确定资源,任务,工作量,工作进度

5.可交付元素

＜某某某某某某某某系统＞的这一“测试计划”文档有助于实现以下目标：

●确定现有项目的信息和应测试的软件构件。

●列出推荐的测试需求（高级需求）。

●推荐可采用的测试策略，并对这些策略加以说明。

●确定所需的资源，并对测试的工作量进行估计。

确保测试工作进度

●列出测试项目的可交付元素。

1.2测试背景

软件名称:

用户:

开发者:

测试版本:

最新版本:

2.2

某某某某某某某某系统,为***公司提供更好的高效办公环境,而设计***系统.主要是通过文件发送和接收、文件下载、文件查询、错误处理、站点监控、权限控制等功能，使文件流转顺畅、资源共享、信息有序管理，基本实现无纸化办公，从而提高办公效率和工作质量，降低管理成本，为核心业务工作提供强有力的技术支持。

1.3范围

测试操作的范围,描述测试各个阶段的测试类型.

各个阶段:

单元,集成,系统,验收;

测试类型:

功能,性能,压力;

描述测试的各个阶段.这个范围,有多种写法

第一种:

按照测试类型分类,画表格:

（这种常用）

测试类型

是否计划进行测试

测试的优先级

说明

安装/卸载测试

是

最高优先级

程序的安装和卸载测试

功能测试

是

最高优先级

系统功能的正确实现及和需求是否符合的测试.

●平台之间的接口

●数据流程控制

●业务流程控制

●用户权限控制

资源占有测试

否

对系统在安装或运行后对硬盘、内存、CPU及网络占有率测试

兼容性测试

是

低优先级

系统对各种运行环境的兼容性（例如操作系统、浏览器）以及和历史版本的兼容性、和第三方软件的兼容性测试

可靠性/稳定性测试

是

最高优先级

系统运行的可靠性、对各种异外情况错误处理能力的测试

●系统响应时间

●系统稳定性

并发测试

是

系统对并发操作的支持性测试

●并发用户访问同一资源

压力测试

否

系统在大负载量条件的性能测试

用户友好性测试

是

中等优先级

主要是指测试人员以用户的角度对系统操作的方便性、可使用性、界面友好性的给出评价。

软件安全性测试

否

主要从软件安全性角度测试系统对业务数据保存、访问及软件系统自身的安全性进行测试。

配置测试

否

指对被测系统使用说明书中要求的软硬件配置进行验证。

在此主要指硬件的配置要求验证测试。

恢复测试

否

是指被测试系统的服务器端或客户端或网络在机器突然出故障（例如突然断电或断网）后重新恢复正常的能力测试。

文档检查

否

对提供的用户手册、系统的在线帮助等技术文档进行一致性检查。

其他测试：

否

备注：

（1）请在表中选择本次测试计划进行的测试类型，并对测试的优先级给以说明。

（2）测试的优先级分为四个级别，请在表格中填写相应序号。

1最高优先级：

首先测试，并详细测试；

2中等优先级：

正常测试；

3低优先级：

只需粗略测试，但本次测试必须进行；

4最低优先级：

只需粗略测试，可以留到下轮测试进行；

第2种:

按模块名称,各模块的测试需求是什么

本计划主要定位于各模块功能测试，界面测试，验收测试的工作，测试类型以功能测试为主，辅以用户界面测试。

模块名称

测试需求

测试优先级

备注

文件发送和接收

网络正常情况下发送和接收;网络中断情况一发送和接收,判断是否支持续传;当文件本身发生错误时发送和接收情况

高

文件下载

网络正常情况下,下载;网络中断时下载情况;当正在下载,突然管理员删除文件时的情况;

高

文件查询

根据文件名称查询;根据文件内关键字查询;判断查询提示信息,并显示相应的查询结果

高

错误处理

当网络出现错误时,各种提示错误信息是否正确

高

站点监控

各个终端,进行监控,查找各个终端上传下载情况;并且进行压力和负载测试,查看站点繁忙时的状态

高

权限控制

不同的人,有不同的权限访问不同的文件;判断权限是否正确

中

退出系统

低

第3种:

按照测试实施的各个阶段来划分:

测试的各个阶段：

1.测试设计

根据需求规格说明书和最终的系统设计，制订测试计划、测试方案，包括收集测试方法、测试用例，可能的测试工具等。

2.集成测试

前期主要针对单个的功能和模块，及简单的功能组合，后期主要针对基本的流程；同时进行对新加入测试人员的培训。

3.系统测试

前期根据需求规格说明书进行功能测试，中期是针对重点模块的性能测试，后期是模拟用户的业务测试，并结合可能的用户测试。

4.验收测试

根据用户手册对功能进行检查，复查报告库中的所有BUG，对Release版本进行安装测试，典型配置环境的裸机测试，加密测试。

备注：

此测试计划不包含单元测试的内容。

2.测试参考文档和测试提交文档

第一种写法:

分别列出来,如下:

（这种常用）

2.1测试参考文档

Ø产品需求说明书

Ø产品概要设计

Ø产品详细设计

Ø产品使用说明书

2.2测试提交文档

Ø测试计划

Ø测试用例设计和执行报告

Ø测试用例设计评审记录

Ø功能测试报告

Ø性能测试报告

Ø压力测试报告

Ø安装测试报告

Ø测试日志

Ø缺陷报告

Ø验收测试总结报告

第二种方法:

将测试计划参考文档,写上:

下表列出了制定测试计划时,需要参考哪些文档,全列在下方,并且标识这些文档的可用性：

（这个偏硬件）

[注：

可适当地删除或添加文档项。

]

文档

（版本/日期）

已创建或可用

已被接收或已经过复审

作者或来源

备注

可行性分析报告

是□　否□

软件需求定义

是□　否□

软件系统分析

（STD,DFD,CFD,DD）

是□　否□

软件概要设计

是□　否□

软件详细设计

是□　否□

软件测试需求

是□　否□

硬件可行性分析报告

是□　否□

硬件需求定义

是□　否□

硬件概要设计

是□　否□

硬件原理图设计

是□　否□

硬件结构设计（包含PCB）

是□　否□

FPGA设计

是□　否□

硬件测试需求

是□　否□

PCB设计

是□　否□

USB驱动设计

是□　否□

TunerBSP设计

是□　否□

MCU设计

是□　否□

模块开发手册

是□　否□

测试时间表及人员安排

是□　否□

测试计划

是□　否□

测试方案

是□　否□

测试报告

是□　否□

测试分析报告

是□　否□

用户操作手册

是□　否□

安装指南

是□　否□

下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性：

（一般项目用）

文档

（版本/日期）

已创建

或可用

已被接收或已经过复审

作者或来源

备注

需求规约

☐是　☒否

☐是　☐否

功能性规约

☐是　☒否

☐是　☐否

用例报告

☐是　☒否

☐是　☐否

项目计划

☑是　☐否

☐是　☐否

设计规约

☐是　☒否

☐是　☐否

原型

☑是　☐否

☐是　☐否

用户手册

☐是　☒否

☐是　☐否

业务模型或业务流程

☐是　☒否

☐是　☐否

数据模型或数据流

☐是　☒否

☐是　☐否

真实原始数据

☐是　☒否

☐是　☐否

业务功能和业务规则

☐是　☒否

☐是　☐否

项目或业务风险评估

☐是　☒否

☐是　☐否

3.术语和定义

程序员和开发人员,因为术语不同,发生争执.统一术语

此部分定义和测试计划执行有关的重要术语和缩略语，其中主要对软件错误和缺陷的划分标准进行定义。

3.1软件错误和缺陷定义

软件错误和缺陷定义见附录Ⅰ。

3.2其他术语的定义

无。

4.测试功能模块范围

模块名称

对应测试用例编号

主要功能

测试内容

优先级

5.测试策略

把讲的测试策略,再结合着要求的进行修改.

内容测试

对于系统来说，总有些内容部分需要测试，例如帮助等。

对于网站来说，文字说明也是相当重要的。

内容测试的第一步就是将内容部分标识出来，再确定谁来实施测试。

提示和技巧

如果内容只是一些帮助文件，用户教育部门会编写和验证这些内容。

如果系统是以内容为主的，拥有上百万的文字、千个链接以及不计其数的图片，在这种情况下需要使用由编辑、校对和测试人员组成的小组来负责内容测试。

和内容提供者确定“什么是内容的缺陷”。

避免出现模糊的问题，比如“读起来有点问题”或者“太文绉绉”。

哪些内容需要测试。

如何将内容测试和其他工作分开。

4.1测试策略

下面列出了在进行每项测试时需考虑的事项，除此之外，测试还应在安全的环境中使用已知的、有控制的数据库来执行。

注意：

不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。

例如，“将不实施该测试。

该测试本项目不适用”。

4.1.1数据和数据库完整性测试

数据库和数据库进程应作为一个子系统来进行测试。

在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。

对于数据库管理系统（DBMS），还需要进行深入的研究，以确定可以支持以下测试的工具和技术。

测试目标：

确保数据库访问方法和进程正常运行，数据不会遭到损坏

测试范围：

数据库及表结构

技术：

检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件已正常发生；或者检查所返回的数据，确保正当的理由检索到了正确的数据

开始标准：

系统数据库设计完毕

完成标准：

所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。

测试重点和优先级：

需考虑的特殊事项：

[测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。

进程应该以手工方式调用。

应使用小型或最小的数据库（记录的数量有限）来使所有无法接受的事件具有更大的可视度。

]

4.1.2单元测试

测试目标

确保模块及单元的正确性

测试范围：

记录输入输出数据

技术：

开始标准：

编码完成

完成标准：

集成测试

测试重点和优先级：

需考虑的特殊事项：

接口的限制条件

4.1.3功能测试

对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。

这种测试的目标是核实数据的接收、处理和检索是否正确，以及业务规则的实施是否恰当。

此类测试基于黑盒技术，该技术通过图形用户界面（GUI）和使用程序进行交互，并对交互的输出或结果进行分析，以此来核实使用程序及其内部进程。

以下为各种使用程序列出了推荐使用的测试概要：

测试目标

确保测试的功能正常，其中包括导航，数据输入，处理和检索等功能。

测试范围：

技术：

利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：

在使用有效数据时得到预期的结果。

在使用无效数据时显示相应的错误消息或警告消息。

各业务规则都得到了正确的使用。

开始标准：

集成测试完成

完成标准：

所计划的测试已全部执行。

所发现的缺陷已全部解决。

测试重点和优先级：

需考虑的特殊事项：

确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）

4.1.4用户界面测试

用户界面（UI）测试用于核实用户和软件之间的交互。

UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。

另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。

测试目标

通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口和窗口之间、字段和字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用

窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。

测试范围：

技术：

为每个窗口创建或修改测试，以核实各个使用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。

开始标准：

系统整合完毕

完成标准：

成功地核实出各个窗口都和基准版本保持一致，或符合可接受标准

测试重点和优先级：

需考虑的特殊事项：

[并不是所有定制或第三方对象的特征都可访问。

]

4.1.5性能评测

性能评测是一种性能测试，它对响应时间、事务处理速率和其他和时间相关的需求进行评测和评估。

性能评测的目标是核实性能需求是否都已满足。

实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。

注：

以下所说的事务是指“逻辑业务事务”。

这种事务被定义为将由系统的某个Actor通过使用测试对象来执行的特定用例，添加或修改给定的合同。

测试目标

核实所指定的事务或业务功能在以下情况下的性能行为：

正常的预期工作量

预期的最繁重工作量

测试范围：

用户登录，查询，添加，修改，删除、发送、下载等

技术：

[使用为功能或业务周期测试制定的测试过程。

通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。

脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多个客户机（虚拟的或实际的客户机，请参见下面的“需要考虑的特殊事项”）上重复。

]

开始标准：

功能开发完毕并可用

完成标准：

[单个事务或单个用户：

在每个事务所预期时间范围内成功地完成测试脚本，没有发生任何故障。

]

[多个事务或多个用户：

在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。

]

测试重点和优先级：

用户登录，查询，添加，修改，删除、发送、下载

需考虑的特殊事项：

[综合的性能测试还包括在服务器上添加后台工作量。

可采用多种方法来执行此操作，其中包括：

直接将“事务强行分配到”服务器上，这通常以“结构化语言”（SQL）调用的形式来实现。

通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。

此负载可通过“远程终端仿真（RemoteTerminalEmulation）工具来实现。

此技术还可用于在网络中加载“流量”。

使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。

性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。

性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。

]

4.1.6负载测试

负载测试是一种性能测试。

在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。

负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。

此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他和时间相关的方面。

注：

以下所说的事务是指“逻辑业务事务”。

这里事务被定义为将由系统的某个最终用户通过使用使用程序来执行的特定功能，例如，发送或接收报文文件。

测试目标

核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。

测试范围：

用户登录，查询，添加，修改，删除等

技术：

[使用为功能或业务周期测试制定的测试。

通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务发生的次数。

]

开始标准：

完成标准：

[多个事务或多个用户：

在可接受的时间范围内成功地完成测试，没有发生任何故障。

]

测试重点和优先级：

功能开发完毕并可用

需考虑的特殊事项：

[负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。

负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。

]

4.2工具

此项目将列出测试使用的工具：

用途

工具

生产厂商/自产

版本

缺陷管理

Bugzilla

TerryWeissman

3.2

功能测试

QTP

9.2

性能测试

Loadrunner

9.1

六、严重程度、优先级的定义（可写在这里））

1）用例的优先级

2）缺陷的优先级

3）缺陷的严重程度

对于软件的错误和缺陷，目前主要依据其严重程度划分五个级别：

1致命性错误

数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机。

2严重性错误

使用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。

系统的主要功能不能正确实现或不完整。

3一般性错误

规定的非主要功能没有实现或不完整、影响系统的运行；设计不合理造成性能低下。

4告警性错误

不影响业务运行的功能问题。

5建议

软件设计和功能实现等不完全合理之处提出建议。

7.资源

培训需求

本节说明项目测试人员需要哪些培训。

提示和技巧：

l对于新手需要先介绍测试系统，如果测试人员比较熟悉该系统，则需要说明新系统的功能。

l是否进行自动测试。

l测试人员要不要培训以编写自动化脚本。

B.硬件需求

本节说明测试人员需要的各种类型的硬件以及这个测试团队需要的硬件。

C.软件需求

本节说明测试人员需要使用的软件。

D.办公空间需求

本节说明需要多少办公空间。

6.1角色

下表列出了在此项目的人员配备方面所作的各种假定。

小公司:

角色

推荐的最少资源

（所分配的专职角色数量）

具体职责或注释

测试经理

张明

进行管理监督。

职责：

提供技术指导

获取适当的资源

生成测试计划，测试方案

管理测试数据（Notes数据库）

收集测试用例

参和测试

测试员

测试中心提供测试员2～3名。

执行测试。

职责：

执行测试

记录结果

从错误中恢复（返测报告）

收集测试用例

测试系统管理员

张明

确保测试环境和资产得到管理和维护。

职责：

管理测试系统

授予和管理角色对测试系统的访问权

大公司:

人力资源

角色

所推荐的最少资源

（所分配的专职角色数量）

具体职责或注释

测试经理

测试项目经理

TBD

进行管理监督。

职责：

⏹提供技术指导

⏹获取适当的资源

⏹提供管理报告

测试设计员

TBD

确定测试用例、确定测试用例的优先级并实施测试用例。

职责：

⏹生成测试计划

⏹生成测试模型

⏹评估测试工作的有

展开阅读全文