软件测试标准标准.docx
- 文档编号:6974116
- 上传时间:2023-01-13
- 格式:DOCX
- 页数:15
- 大小:51.61KB
软件测试标准标准.docx
《软件测试标准标准.docx》由会员分享,可在线阅读,更多相关《软件测试标准标准.docx(15页珍藏版)》请在冰豆网上搜索。
软件测试标准标准
软件测试标准标准
1目的
为了确保软件产品质量,使产品能够顺利交付和通过验收,特编写本文档,以作参考
2适用范围
本文档适用于项目开发进程中的单元测试、集成测试、系统测试、业务测试、验收测试和一些专项测试。
3职责
Ø项目测试负责人组织编制《测试打算》、《测试方案》,指导和催促测试人员完成各时期的测试工作。
Ø项目组测试人员依照《测试打算》、《测试方案》完成所承担的测试任务,并按要求填写《问题报告及保护记录》。
Ø测试领导依照确认规程和准那么对工作产品进行确认,提出对确认规程和准那么的修改意见
Ø项目负责人组织测试环境的成立。
Ø项目领导审核负责操纵整个项目的时刻和质量。
Ø研发人员确认修改测试人员提交的bug。
4工作流程
4.1测试依据
详细设计是模块测试的依据。
因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。
测试人员必需认真阅读,真正弄懂系统需求和详细设计。
4.2制订《测试方案》
在测试之前,由项目负责人依照《测试打算》的要求,组织人员编制相应的《测试方案》,《测试方案》应包括以下内容:
Ø测试目的;
Ø所需人员及相应培训要求;
Ø测试环境、工具和测试软件;
Ø测试用例、测试数据和预期的结果。
4.3单元测试
项目开发实现进程中,每一个程序单元(程序单元的划分视具体开发工具而定,一样定为函数或子程序级)编码调试通事后,要及时进行单元测试。
单元测试由单元开发者自己进行,利用白盒测试方式,依照程序单元的操纵流程,争取达到分支覆盖。
关于交互式运行的产品,不便于进行自动测试的,能够采纳功能测试的方式进行。
单元测试针对程序模块,从程序的内部结构动身设计测试用例。
多个模块能够独立进行单元测试。
Ø单元测试内容包括模块接口测试、局部数据结构测试、途径测试、错误处置测试等;
Ø单元测试组织原那么一遍依照开发进度安排对已开发完成的单一模块进行测试;
Ø单元测试停止标准:
完成了所有规定单元的测试,单元测试中发觉的bug已经取得修改。
4.4集成测试
编码开发完成,项目组内部应进行组装测试。
集成测试由项目负责人组织策划(编写测试打算、测试用例)并实施。
集成测试着重对各功能模块之间的接口进行测试,验证各功能模块是不是能和谐工作、参数传递及功能挪用是不是正常。
测试采纳交叉方式,即个人开发的软件应由其他的项目组成员进行测试。
集成测试进程应填写《问题报告及保护记录》,测试结果应形成《测试报告》。
4.5系统测试
在项目开发完成以后,应付整个系统软件和硬件进行系统测试。
对性能、靠得住性、健壮性、压力经受力等方面别离进行评判,以验证系统是不是知足规定的需要。
系统测试由测试负责人组织策划(编写测试打算、测试用例)并实施,系统测试进程应形成《问题报告及保护记录》。
系统测试一样进行如下几种情形的测试:
Ø正常情形
Ø非正常情形
Ø破坏性测试
Ø边界情形
Ø非法情形
Ø强度测试
Ø性能测试
Ø兼容性测试
Ø用户友好性测试
界面设计标准测试:
Ø光标的初始位置
Ø字体是不是统一
Ø字号是不是符合规定
Ø题目颜色
Ø按钮的名称是不是标准
Ø界面布局是不是合理,整体成效如何
输入值测试:
Ø数据类型
Ø数据长度
Ø约束条件是不是知足,是不是完整
ØTAB和Enter键是不是起作用
Ø键盘操作可否全数代替鼠标操作
Ø输入(光标)是不是依照顺序前进
按钮测试:
Ø将按钮放开和封锁是不是严格、准确,不能利用的按钮必需封锁
Ø检查“退出”、“取消”等具有共性按钮的功能
异样情形测试:
在完成正常功能测试后,安正常处置的相同操作顺序,执行与正常处置不同的动作例如
Ø正常处置中要求输入日期的字段,这时输入字符或数字
Ø正常处置中输入字段有范围要求,这时输入超过范围的值
Ø正常处置顶用两个值限定范围,这时用一个值或不限定
Ø正常处置中要求用“Tab”键,这时安“Enter”键或其他键
Ø正常处置中单项选择框、多项选择框、下拉框等,十一偶那个非指定键操作
Ø利用不同于指定的按钮操作
4.6业务测试
在组装测试与系统测试终止后,都可由最终用户或测试人员对系统进行测试。
业务测试着重测试业务流程,功能、用户界面等方面。
项目、测试负责人负责组织相关人员制定测试方案和测试用例,并进行测试。
测试的结果应形成《问题报告及保护记录》。
4.7验收测试
4.7.1验收测试的条件
Ø依照项目打算规定的验收测试进度安排进行测试预备
Ø在验收测试前,各项内部的测试活动都受到监控并争取执行
4.7.2交付版本的要求
Ø依照集成测试用例完成了整个系统的集成测试
Ø集成版本知足设计概念的各项功能、性能要求
Ø提交的数据库脚本样本需要完整,没有冗余数据
Ø在集成测试中发觉的bug已经取得解决,各级缺点修改率达到标准
Ø软件需求分析说明书中概念的所有功能都已经实现,性能指标全数达到性能需求指标
Ø提交时期性测试报告,包括功能和性能测试报告
Ø所有文档齐全完整
4.7.3版本发布的准那么
Ø软件产品通过了单元测试、集成测试、业务测试、系统测试、性能测试
Ø测试部提交文档:
测试打算、测试方案、测试用例、测试分析报告
Ø所有测试项必需符合以下标准
⏹致命错误:
无
⏹功能错误:
无
⏹功能缺点:
项目领导、技术领导、测试负责人审核通过
⏹界面缺点:
项目领导、技术领导、测试负责人审核通过
⏹建议:
项目领导、技术领导、测试负责人审核通过
Ø以上几项其中之一不知足要求,视为不合格
在产品交付和用户验收之前,通过验收测试来确认在规定的利用环境下整个产品的运行情形是不是知足规定的要求。
在产品交付之前,由指定的验收负责人组织制定测试方案和测试用例,主持验收。
验收测试进程应形成《问题报告及保护记录》。
4.8用户现场测试
将软件部署到用户实际生产环境后,由于环境不同,需要在用户现场进行确认测试,保证系统功能、性能完备,可正常运行。
测试内容:
Ø依照软件系统规模,预备现场测试用例,涵盖所有重要功能点,假设规模小,需要将全数功能点全数测试一遍
Ø关于后台已概念好的工作流、功能栏目途径和用户信息等数据,不可进行修改和删除操作,新增的测试数据也需要在测试完成后给予清楚
Ø重点检查上传、下载的数据是不是能够正常的打开或保留
Ø确认界面美观,大体信息和链接无错误
Ø考虑用户实际的软件环境和网络环境,以客户端最为复杂的软硬件环境作为测试机械,检查有无异样情形显现
Ø针对前期发觉的bug进行回归测试,以保证发布版本为最新版本
4.9编写测试文档
4.9.1测试点
将测试模块分解成多个功能点,测试点应涵盖功能点,也涵盖了正常测试和异样测试。
4.9.2输入数据
输入数据包括界面输入数据、数据库的初始数据及其他外部输入数据。
专门是数据库的初始所需属性一一列出,全面是指:
数据能达到模块所涉及的全数功能,典型是指那个数据能充分反映功能特点。
4.9.3测试描述
描述测试步骤,包括:
操作员所执行的动作(包括鼠标、键盘、加载外部数据等操作);系统的反映,包括:
光标定位、光标聚焦、显示字段值、按钮的封锁和放开、功能键的封锁和放开、系统提示和系统消息等。
4.9.4预期输出数据
按预备的输入数据和设计要求的处置进程,模块应输出的数据。
输出数据包括:
屏幕输出数据、输出到数据库的数据、输出到其他外部介质上的数据,并指出断点结果或最终结果。
4.9.5实际输出
填写本测试点程序运行后的实际输出。
4.9.6正确与否
程序运行后,实际输出结果和预期输出结果一致时,为正常,不然为不正常。
4.9.7测试结论
填写本次测试的结论,是合格或不合格。
假设不合格时,应总结存在的问题,能够让修改者一目了然。
5缺点治理
5.1缺点的概念及其大体属性
缺点是指在软件开发进程中的针对软件产品和开发进程中的问题,这些问题已经阻碍或可能会阻碍软件产品的质量。
缺点应该具有以下属性,也确实是往缺点治理库或缺点列表中提交的缺点应该具有以下属性:
属性名称
描述
缺陷标识
标记某个缺陷的一组符号,每个缺陷必须有一个唯一的标识
缺陷类型
根据缺陷的自然属性划分的缺陷种类
缺陷验证程度
因缺陷引起的故障对软件产品的影响程度
缺陷所处的模块或子系统
缺陷分步的模块或子系统
缺陷出现几率
指发现错误的几率
缺陷的重现步骤
详细的缺陷重现步骤
附件
与缺陷相关的附件(截图、附件、用例等)
备注
对缺陷的其他描述
5.2缺点分类
依照缺点的概念,将缺点分为如以下:
Ø文档缺点:
是指对文档的静态检查进程中发觉的缺点。
检查活动包括同行评审、产品审计等。
评审的缺点要依照被评审对象的类型来确信,被评审的对象包括最终出产物和中间进程产出物,比如需求文档、设计文档、打算、报告、用例等
Ø代码缺点:
是指对代码进行同行评审、审计或代码走查进程中发觉的缺点
Ø测试缺点:
是指由测试活动发觉的测试对象(被测对象一样是指可运行的代码、系统,不包括静态测试发觉的问题)的缺点,测试活动包括单元测试、集成测试、系统测试、性能测试等
Ø进程缺点:
有称为不符合项问题,是指通过进程审计、进程分析、治理评审、质量评估、质量审核等活动发觉的关于进程的缺点和问题。
进程缺点的发觉者一样是测试人员、项目领导等
5.3文档缺点分类
缺陷分类
描述
描述不完整
文档内容缺失,或文档应该包括的范围没有涵盖
不一致
一致性问题有两类:
一是与源头说明书不一致,比如需求和客户业务需求不一致、设计与需求不一致等
二是上下文或者与前提不一致
描述错误
文档描述是错误的,不可实现或导致错误的输出或结果
功能问题
该缺陷将会导致用户功能的错误、不满足、不可用
不清楚或有歧义
内容的描述不清楚、不能准确表达、或表达的意思有歧义
逻辑错误
内容组织逻辑不清楚、逻辑错误
接口问题
与最终用户接口问题、与外部系统的接口问题、内部子系统或模块的接口问题
输入输出问题
输入输出不完整、不正确、不可测试或验证
不细化
内容还需要进一步细化
性能问题
文档的设计或实现方式存在性能问题
安全性问题
文档的设计或实现方式存在安全性问题
5.4代码缺点分类
缺陷分类
描述
常量变量定义问题
不满足设计或需求
编写代码不符合规范
条件判断处理
循环处理错误
异常处理
算法逻辑问题
注释问题
代码冗余
性能问题
5.5系统测试缺点分类
缺陷类型
描述
功能错误
影响了重要的特性、用户界面、产品接口或全局数据结构,并且设计文档需要争取的变更。
如逻辑、循环、递归、功能等缺陷
结构错误
Web应用程序结构化页面无法显示,或者显示错误
脚本错误
Web应用程序当中出现脚本错误,包括客户端对数据进行校验和运算的各种情况下产生的错误
页面链接错误
Web应用程序页面出现空链接、错误链接、死链接
页面文字错误
Web应用程序页面出现的中外文拼写、使用、以及不同语种页面的编码错误
页面图形错误
Web应用程序页面出现图片内容使用不当,或者无法显示
ALT错误
Web应用程序页面当中超文本标识语言、文本标签解释错误
排版错误
Web应用程序页面排版不符合要求或者不符合使用习惯
业务逻辑不合理
应用程序的实现流程和规定业务流程不一致,或者实现流程无法正确完成。
包括流程数据的部分并行、争用、同步等操作,引起的流程断裂、死锁、以及其他异常情况
业务逻辑不方便
应用程序实现流程在实际情况下虽然可以完成,但是存在不必要的反复、等待、冗余等影响使用效率的情况
其他错误
其他未分类错误
建议
系统改进建议
5.6缺点品级概念
缺点的严峻程度对以上所述的缺点类型都是适合的,缺点的严峻程度反映的是对缺点的发觉对象可能造成的阻碍或后果来概念的。
缺陷等级
缺陷性质
系统中对应的错误分类
描述
一级
致命错误
系统崩溃
系统死锁
导致对被描述的主要对象的理解错误、不可行、不可运转、对业务和整个系统造成重大损失或损害;对使用、维护或保管人员有危险或不安全,以及对产品的基本功能有致命影响的缺陷
二级
严重缺陷
严重错误
对被描述的部分对象的理解或实现错误,部分的模块或系统不可行或不能运转或部分模块和系统缺失,对整个系统有重大影响或可能造成部分的损失或损害;严重影响使用安全
三级
一般缺陷
次要错误
布局不合理
文字错误
系统中部分单元模块或单个功能描述和实现有错误、有偏差、不一致或有缺失,不影响模块的正常运行,或有影响,但可以有替代的办法或避免办法
四级
微小缺陷
微不足道
基本不影响系统的运行和功能的实现。
但是与标准、规范和定义不一致
五级
建议缺陷
新特性
不在定义、标准、范围的定义和约束之内,但是从提出者来看是需要完善的建议
5.7缺点优先级概念
缺陷优先级
描述
特急
需要立刻进行修改
加急
一天到两天之内必须修改
高
介于中和加急之间
中
缺陷需要正常排队等待修复或列入软件发布清单
低
留到组后解决,如果项目的进度跟紧张可以在产品发布以前不解决
5.8缺点状态概念
缺陷状态
描述
初始状态(New)
测试或开发人员提交一个新的缺陷,等待开发人员或项目经理分配修改负责人
打回(FeedBack)
要求缺陷的报告者再次对缺陷进行说明
已分配(Assigned)
是指已经分配给属主,等待修改。
已解决(Resolved)
缺陷被属主修改,等待测试人员验证
关闭(Closed)
测试人员验证缺陷已经修复
重新打开(Reopen)
测试人员验证,缺陷没有修改正确
遗留(Later)
经项目经理和技术经理验证此缺陷在本版本中不用修改
5.9缺点完成度
缺陷完成度
描述
打开(Open)
缺陷没有被解决
已解决(Fixed)
缺陷已经修改
遗留(Suspended)
此缺陷步骤本阶段解决
重新打开(Reopen)
重新打开某个缺陷
不做修改(Won’tfix)
不对这个缺陷进行修改
重复(Duplicate)
与某个缺陷重复
需求如此
经理和开发人员经过需求和设计的核实后决定不需要修改
不可重现
被指派的开发人员想要再现缺陷进行修改个时候,发现缺陷始终不能再现
5.10缺点治理流程
6处置机制
6.1退回机制
假设在测试进程中发生如下情形,将系统退回到申请部门:
Ø通过测试后,发觉与需求说明规格说明书中概念的功能项存在较大的不同
Ø单一模块,测试进程中发觉缺点输了较多或无法继续进行系统其它功能模块的测试,继续测试无心义
Ø测试进程中,频繁死机或系统崩溃
Ø主业务流程显现断点
6.2异样情形处置机制
非正常情形下,需要进行专门处置的情形,此情形需要主管领导签字确认:
Ø上线时刻紧急的情形下,未经测试部充分测试就需要部署到用户现场
Ø作为总包时,子商进度明显延迟,尚未进行验收测试就需要上线
6.3报告机制
假设显现以下情形,需要及时向部门领导和项目领导汇报的情形:
Ø测试后期显现重大逻辑错误,修改测试阻碍上线时刻
Ø测试进程顶用户需求显现重大变更
Ø测试负责人按期汇报测试情形
7测试完成的标准
7.1被测试出的、在软件错误级别分类中概念的:
Ø一级缺点,致命错误,100%取得修改而且复测通过
Ø二级缺点,严峻错误,100%取得修改而且复测通过
Ø三级缺点,一样错误,95%取得修改而且复测通过
Ø四级缺点,轻微错误,95%取得修改而且复测通过
7.2用户能够同意未修改的软件错误
7.3测试超过了预按时刻表,由项目领导决定是不是停止测试
7.4测试结论及评判标准
测试结论
评价标准
拒绝发布
遗留了一级、二级缺陷
测试通过版本
不能遗留以一、二类缺陷
三类一般缺陷95%得到修改并且通过复测
四类轻微缺陷85%得到修改并且通过复测
推荐使用版本
不能遗留以一、二类缺陷
三类一般缺陷95%得到修改并且通过复测
四类轻微缺陷90%得到修改并且通过复测
可以证实发布版本
不能遗留以一、二类缺陷
三类一般缺陷97%得到修改并且通过复测
四类轻微缺陷90%得到修改并且通过复测
7.5输出
《时期性测试报告》
《性能测试报告》
《测试总结报告》
《测试问题列表》
8其他约束
9记录
序号
名称
编号
1
测试计划
2
测试方案
3
问题报告及维护记录
4
测试总结报告
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 标准
![提示](https://static.bdocx.com/images/bang_tan.gif)