《软件测试规范标准.docx》由会员分享,可在线阅读,更多相关《软件测试规范标准.docx(8页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、软件测试规范1、 测试目的为了确保软件产品的质量,使产品能够顺利交付和工程验收。2、 测试职责(1) 编写测试计划&测试方案,指导测试。(2) 搭建测试环境。(3) 完成所承担的测试任务,并按要求填写问题报告。(4) 测试出现bug及时与研发人员进行沟通确认,确认是bug的情况下提缺陷报告 单记录bug,并在下一版本中返测该问题单。3、 工作流程测试依据:详细设计是测试的依据。因此设计人员需向测试人员提供系统需 求规格书、详细设计、概要设计等相关材料,测试人员需仔细阅读相关 材料,弄清系统的功能需求和详细设计。(1) 测试方案的制定:在测试之前需要编写测试方案,测试方案包含:测试目的;所需人员
2、及相应培训要求; 测试环境、工具及测试软件;测试用例、测试数据及预期结果。(3)单元测试软件产品在开发过程中,每个功能模块开发完成代码调试后都要尽快的进行单 元测试,测试出的bug应立即进行修改。(4) 集成测试在单元测试的基础上,在代码开发完成后进行的组装测试,将每个单元组合成 一个软件系统进行集中测试,此时需要进行编写测试计划和测试用例。集成测 试着重验证各功能模块之间能否协调工作,参数传递及功能调用是否正常。集 成测试中出现问题应提交缺陷报告单,记录缺陷,待下一版本中进行验证,也 就是接口之间的测试。(5) 系统测试在项目开发完成后,应对整个系统软件进行系统测试,对功能、性能、可靠性、
3、压力承受能力等方面进行评价,以验证系统是否满足需求规定。系统测试由负 责人组织编写测试计划和测试用例,测试用例中应覆盖绝大部分测试点。系统测试一般测试方法如下:有效等价类及有效边界值;(2)无效等价类及无效边界值;非法情况;性能测试;场景的测试找出基本流和备选流,基本流是模拟用户正确的操作;备选流是模 拟用户错误的操作; 因果图法,找出输入组合和输出组合,根据输入和输出组合进行测试用例的编 写。界面测试一般测试如下情况:光标的初始位置;(2)字体的统一性;符号是否符合规范;字体颜色是否符合需求:按钮名称是否规范;标题颜色。输入参数的规范:数据类型;数据长度;约束条件是否满足;快捷键是否可用(键
4、盘操作是否可完全替代鼠标操作);输入光标是否按顺序推进。按钮测试:按钮的可用性与置灰是否明确;检查“确认”与“取消”功能犍是否实现功能。异常情况测试在完成按正常操作顺序测试后,按照与正常顺序不同的测试动作进行测试需求说明中要求输入数字的地方输入字符串,查看结果; 需求说明中有范围要求的,超出范围很多或者边界值附近取值;需求说明中有按键要求的,我们更改按键操作,查看结果: 不同于指定的按钮操作。(6) 交付版本的要求:集成版本满足设计定义的各项功能、性能要求;按照集成测试用例完成整个系统的集成测试;在集成测试中的bug已经解决,缺陷的修复:率达到标准;系统需求规格书中提到的各项功能均已实现,性能
5、指标全部达到要求;提交阶段性测试报告,功能和性能;所有文档齐全。(7)软件发布要求 软件产品通过了单元测试、集成测试、系统测试和性能测试。测试部门提交:测试计划、测试方案、测试用例及结果报告。(3)各功能模块需符合以下标准:致命错误:无严重问题:无功能缺陷:部门人员进行评审,认为该缺陷不影响客户正常使用情况下可留 待下一版本解决界面缺陷:部门人员进行评审,认为该缺陷不影响客户正常使用情况下可留 待下一版本解决在产品交付和用户验收之前,通过验收测试来确认在规定的环境中整个产品的 运行情况是否满足规定的要求编写测试文档(1)测试点:将测试模块分解成多个功能点,测试点应涵盖功能点,也涵盖正常功能点和
6、异常功能点。(2)输入数据:测试数据的输入应覆盖软件正常功能的测试点和异常功能的测试点。(3) 测试描述:描述测试步骤,包括:测试员所执行的动作(鼠标、键盘、加载数 据等操作);系统的反应,包括:光标定位、显示字段值、按钮的置灰与否、功 能键的实现与否和系统提示、消息等。(4) 预期输出数据:按照准备的数据和设计要求的处理过程,模块应输出的预期数 据,输出数据应包括:屏幕输出的数据、输出到数据库的数据和输出到其他外 部的数据。(5)实际输出数据:程序运行后输出的数据。(6)正确与否:预期结果与实际数据之间是否一致,若不一致则判定为缺陷。(7)测试结论:填写测试结论,是合格还是不合格,若不合格时
7、,应提单进行阐述, 在提单的时候应该详细叙述操作过程和操作步骤,让开发人员能清楚的看到缺 陷在哪一个模块哪一步中产生,便于研发人员修改代码。5、 缺陷管理(1) 什么是缺陷?软件未实现产品所要求的功能; 软件实现了产品未提及的功能; 软件实现了产品指明不应该出现的错误;产品需求虽未说明,但站在客户的角度应该实现该功能; 软件导致系统崩溃,不易使用。(2) 缺陷报告的组成缺陷的编号:缺陷摘要;缺陷的发现者;缺陷发现的日期;所属模块;发现缺陷的版本;指派给谁;缺陷的状态;缺陷的严重程度;缺陷的优先级;缺陷描述:缺陷的出现频率;附件的上传:附注上述选项都是在提交缺陷时测试人员需填写的项n,这可以很准
8、确的记录缺陷的具 体信息,以便在后续操作中进行缺陷跟踪、开发修改代码及货任划定。(3) 缺陷的分类文档缺陷:指对文档的静态检查过程中发现的缺陷,检查过程包括:文档的评 审、产品审计等。评审的缺陷要根据被评审对象的类型来确定,被评审的对象 包括:需求文档、设计文档、报告、用例等。其中软件缺陷中文档中的缺陷就 达到了 80%。代码缺陷:代码走查过程中发现的缺陷。测试缺陷:指由测试活动发现的测试对象的缺陷(测试对象一般指可运行的代 码和系统),测试活动包括:单元测试、集成测试和系统测试、性能测试。(4) 文档缺陷分类(5) 代码缺陷分类缺陷分类描述描述不完整文档内容缺失或文档应该包括的范围没有涵盖不
9、一致一致性问题有两类:1、与源头说明书不一致,比如需求和客户业务需求不一致、设计与需 求不一致等2、上下文或者与前提不一致描述错误文档描述是错误的,不可实现或导致错误的输出或结果功能问题该缺陷将会导致用户功能的错误、不满足、不可用不清楚或有歧义内容的描述不清楚、不能准确表达、或表达的意思有歧义逻辑错误内容组织逻辑不清楚、逻辑错误接口问题与最终用户接口问题、与外部系统的接口问题、内部子系统或模块的 接口问题输入输出问题输入输出不完整、不正确、不可测试或验证不细化内容还需要进一步细化性能问题文档的设计或实现方式存在性能问题安全性问题文档的设计或实现方式存在安全性问题常量变量定义问题、不满足设计或需
10、求、代码编写不合规范、条件判断处理、循环处理出错、异常处理、算法逻辑问题、注释问题。(6)系统缺陷分类(7) 缺陷等级定义缺陷类型描述功能错误影响了重要的特性、用户界面、产品接口或全局数据结构,并且 设计文档需要争取的变更。如逻辑、循环、递归、功能等缺陷结构错误Web应用程序结构化页面无法显示,或者显示错误脚本错误Web应用程序当中出现脚本错误,包括客户端对数据进行校验和 运算的各种情况下产生的错误页面链接错误Web应用程序页面出现空链接、错误链接、死链接页面文字错误Web应用程序页面出现的中外文拼写、使用、以及不同语种页面 的编码错误页面图形错误Web应用程序页面出现图片内容使用不当,或者无
11、法显示ALT错误Web应用程序页面当中超文本标识语言、文本标签解糅错误排版错误Web应用程序页面排版不符合要求或者不符合使用习惯业务逻辑不合理应用程序的实现流程和规定业务流程不一致,或者实现流程无法 正确完成。包括流程数据的部分并行、争用、同步等操作,引起 的流程断裂、死锁、以及其他异常情况业务逻辑不方便应用程序实现流程在实际情况下虽然可以完成,但是存在不必要 的反复、等待、冗余等影响使用效率的情况其他错误其他未分类错误建议系统改进建议缺陷的严重程度对以上所述的缺陷类型都是适合的,缺陷的严重程度反映的是对缺陷的 发现对象可能造成的影响或后果来定义的。缺陷 等级缺陷性质系统中对应的错 误分类描述
12、一级致命错误系统崩溃 系统死锁导致对被描述的主要对象的理解错误、不可行、不可 运转、对业务和整个系统造成重大损失或损害;对使 用、维护或保管人员有危险或不安全,以及对产品的 基本功能有致命影响的缺陷。二级严重缺陷严重错误时被描述的部分对象的理解或实现错误,部分的模块 或系统不可行或不能运转或部分模块和系统缺失,对 整个系统有重大影响或可能造成部分的损失或损害; 严重影响使用安全。三级次要缺陷次要错误 布局不合理,文字错误系统中部分单元模块或单个功能描述和实现有错误、 有偏差、不一致或有缺失,不影响模块的正常运行, 或有影响,但可以有替代的办法或避免办法。四级一般缺陷不影响使用的缺 陷基本不影响
13、系统的运行和功能的实现。但是与标准、 规范和定义不一致。五级建议缺陷优化建议不在定义、标准、范围的定义和约束之内,但是从提 出者来看是需要完善的建议。(8) 缺陷的优先级定义Urgent:紧急,立即解决Veryhigh:加急,本版本中解决High:急,下一版本中解决Medium: 一般,缺陷需进行正常排队进行修复,发布前解决Low: ffi,允许在发布中存在一定的缺陷(9) 处理缺陷的流程图测试人员,测试人员,开发经理+开发人员测试人员,测试人员一该图中测试人员首先提交缺陷报告,缺陷状态为New,指派给开发经理;然后,开发经理在收到该缺陷后进行确认,并将缺陷状态改为open,指派给所属模块的开
14、发人员;开 发人员接收到缺陷后,处理该缺陷,处理完毕后将该缺陷状态改为fixed已修复,并将该缺 陷重新指派给报告人;测试人员在下一版本中对缺陷进行返测,若确认缺陷修复,则将缺陷 状态改为closed,若依旧没有修复则将缺陷状态改为reopen,并指派给开发人员。除以上缺 陷的5个状态外,实际测试中有遗留问题,遗留问题需评审需求或者留待以后有计划解决: 缺陷的合并,一个代码错误导致多个问题的出现,缺陷重复。6、 软件版本的回退机制若软件在测试过程中出现如下情况,可以将测试版本网退到开发部门进行重新评审(1) 经过测试后,发现与需求规格说明书中所要求的功能项存在较大的差异:(2) 单一模块,测试
15、过程中发现测试缺陷较多,影响到其他功能的测试,无法进行 下去的,继续测试无意义的;(3)测试过程中频繁死机或系统崩溃的;(4) 主业务流程出现问题。7、 测试完成标准(1) 被测试出的,在软件错误级别分类中定义的: 一级缺陷,致命错误,100%修复并且回归通过二级缺陷,严重错误,100%修复并且回归通过 三级缺陷,一般错误,95%修复并且回归通过四级缺陷,轻微错误,95%修复并且回归通过(2)用户可以接受未修改的软件错误;(3)超过了预计的测试时间表,由领导确定是否停止测试。8、 开发与测试之间的关系图v型图反应了开发与测试之间的对应关系,在该图中各个阶段的测试任务标注明确;但是它很容易让人理
16、解为开发后期才介入的测试,测试应该越早越好,也没有反应出文 档测试内容。当需求文档和概要设计文档编写出来后,测试人员需进行文档测试;根据 需求文档和开发文档测试人员需要编写测试计划和测试用例。9、 实际工作中的测试流程准备好服务器,等待研发人员给出版本安装包及测试大纲文档和需求文档,该 安装包研发人员已经自测过;(1) 版本安装包出来后进中试流程,测试人员在服务器上进行软件包的安装;(2) 设置调试好测试环境;对照测试大纲进行测试工作,结果填写在测试大纲中,如在测试过程中遇见bug 则需在系统中进行提单,报告bug有特定系统;(3) 第一轮测试结束后,测试人员软件也熟悉了,在下一版本出包前参照
17、第一轮的 包和测试大纲进行测试用例的编写,编写完成后需与软件开发人员等相关人等 评审用例;安装第二轮的软件包,对照测试用例进行测试,并验证第一轮出现的bug是否 得到修友,如没修里则在bug系统中进行注释,并指派给相关开发人员;(4) 如在第二轮中遇到bug依然进行提单,第二轮需验证完第一轮发现的所有bug, 需要挂起(遗留)的做特殊说明并标记,第二轮测试结束;(5) 第三轮测试工作重点在返测,回归问题单,测试需加快速度;(9)测试完毕后,结果报项忖经理,项目经理与研发人员确认该软件是否能发布使 用;(10)后期维护。备注:每个公司都有每个公司的测试流程,但测试工作不应该局限于仅仅对代码 的测试,这样是片面的测试观点,测试工作还应该包括文档测试,需求文档,概要设计 文档,详细设计文档和使用书册等,并且在文档测试的过程中往往发现的问题是最多的, 此时对文档进行的修改比代码写完后修改成本要小的多,所以文档测试必须的。所有的测试都要要追溯到需求,因为最严重的错误是导致程序无法满足需求错误。在设计测试用例的时候,必须明确用例的预期结果,否则很难对实际的输出结果有 明确的评判标准。
限制150内