腾讯学长告诉你软件测试规范是啥!

发表于:2021-3-15 09:45  作者:程序媛小墨   来源:CSDN

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试 软件测试规范

  概述
  本规范是对项目软件测试的一份指导性文件,对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准以及测试流程进行总体规范,以有效保证软件产品的质量。
  项目软件测试是对软件设计的一种控制手段,是对软件产品质量的一种检查和审核手段,项目测试人员应按本规范要求对软件进行检查、测试。
  测试目标
  a.测试是为了发现程序中的错误而执行程序的过程;
  b.好的测试用例是极可能发现迄今为止尚未发现的错误的用例;
  c.成功的测试是发现了至今为止尚未发现的错误的测试。
  == 软件测试流程==
  无规矩不成方圆,做好项目就是做正确的事情,而正确地处理事情才能更好地提高效率。测试部门在接到一个新的项目后,需要按照以下五个流程逐步开展测试工作,该流程在实际的工作中,可根据实际情况进行补充和完善。
  a.测试参考文档
  在测试人员开展工作之后,需要借助产品人员和开发人员提供的文档,形式的文档可以给测试工作带来依据。具体参考文档包括:产品需求说明书、产品设计原型、数据库设计方案、开发部门代码规范说明、开发人员(前端和后台)任务分配表等。
  b.测试工作流程图
  测试工作的基本流程图如下图所示:
  == 软件测试方法==
  根据项目需要,目前主要进行的有功能测试性能测试。现阶段以功能测试为主,而功能测试目前使用最多的测试方法有等价类划分法、边界值分析法和错误推测法。这三种都属于最常用、最典型、也是最重要的黑盒测试方法。 其他的方法还会涉及到因果图法、判定表法、正交分析法、场景法等。
  a.等价类划分方法 
  将所有可能的输入数据划分成若干个子集,在每个子集中,如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果,那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试,就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
  b. 边界值分析方法
  选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上,所以需要对边界值进行重点测试,通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。从方法论上可以看出来,边界值分析是对等价类划分的补充,所以这两种测试方法经常结合起来使用。   
  c.错误推测法
  在很大程度上是凭经验进行的,是凭人们对过去所作的测试工作结果的分析,对所揭示的缺陷的规律性作直觉的推测来发现缺陷的。
  示例:针对“用户登录”功能,基于等价类划分和边界值分析方法,我们设计的测试用例包括:
  1.输入已注册的用户名和正确的密码,验证是否登录成功;
  2.输入已注册的用户名和不正确的密码,验证是否登录失败,并且提示信息正确;
  3.输入未注册的用户名和任意密码,验证是否登录失败,并且提示信息正确;
  4.用户名和密码两者都为空,验证是否登录失败,并且提示信息正确;
  5.用户名和密码两者之一为空,验证是否登录失败,并且提示信息正确;
  6.如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入正确的验证码,验证是否登 录成功;
  7.如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入错误的验证码,验证是否登 录失败,并且提示信息正确。
  如果再加上错误推测法(因人而异),会再增加以下的测试用例:
  1.用户名和密码是否大小写敏感;
  2.页面上的密码框是否加密显示;
  3.后台系统创建的用户第一次登录成功时,是否提示修改密码;
  4.忘记用户名和忘记密码的功能是否可用;
  5.前端页面是否根据设计要求限制用户名和密码长度;
  6.如果登录功能需要验证码,点击验证码图片是否可以更换验证码,更换后的验证码是否可用;
  7.刷新页面是否会刷新验证码;
  8.如果验证码具有时效性,需要分别验证时效内和时效外验证码的有效性;
  9.用户登录成功但是会话超时后,继续操作是否会重定向到用户登录界面;
  10.不同级别的用户,比如管理员用户和普通用户,登录系统后的权限是否正确;
  11.页面默认焦点是否定位在用户名的输入框中;
  12.快捷键 Tab 和 Enter 等,是否可以正常使用。
  非功能性测试
  一个质量过硬的软件系统,除了显式功能性需求以外,其他的非功能性需求即隐式功能性需求也是极其关键的。显式功能性需求的含义从字面上就可以很好地理解,指的是软件本身需要实现的具体功能。比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等,这都是属于典型的显式功能性需求描述。从软件测试的维度来看,非功能性需求主要涉及安全性、性能以及兼容性三大方面。 在上面所有的测试用例设计中,我们完全没有考虑对非功能性需求的测试,但这些往往是决定软件质量的关键因素。
  示例:我们来继续完善“用户登录”的测试用例。
  在安全性方面补充的测试用例包括:
  1.用户密码后台存储是否加密;
  2.用户密码在网络传输过程中是否加密;
  3.密码是否具有有效期,密码有效期到期后,是否提示需要修改密码;
  4.不登录的情况下,在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面;
  5.密码输入框是否不支持复制和粘贴;
  6.密码输入框内输入的密码是否都可以在页面源码模式下被查看;
  7.用户名和密码的输入框中分别输入典型的“SQL 注入***”字符串,验证系统的返回页面;
  8.用户名和密码的输入框中分别输入典型的“XSS 跨站脚本***”字符串,验证系统行为是否被篡 改;
  9.连续多次登录失败情况下,系统是否会阻止后续的尝试以应对暴力破解;
  10.同一用户在同一终端的多种浏览器上登录,验证登录功能的互斥性是否符合设计预期;
  11.同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性。
  站在性能压力测试的角度测试用例包括:
  1.单用户登录的响应时间是否小于 3 秒;
  2.单用户登录时,后台请求数量是否过多;
  3.高并发场景下用户登录的响应时间是否小于 5 秒;
  4.高并发场景下服务端的监控指标是否符合预期;
  5.高集合点并发场景下,是否存在资源死锁和不合理的资源等待;
  6.长时间大量用户连续登录和登出,服务器端是否存在内存泄漏。
  站在兼容性测试角度测试用例补充包括:
  1.不同浏览器下,验证登录页面的显示以及功能正确性;
  2.相同浏览器的不同版本下,验证登录页面的显示以及功能正确性;
  3.不同移动设备终端的不同浏览器下,验证登录页面的显示以及功能正确性;
  4.不同分辨率的界面下,验证登录页面的显示以及功能正确性。
  对于高质量的软件测试,用例设计不仅需要考虑明确的显式功能性需求,还要涉及兼容性、安全性和性能等一系列的非功能性需求,这些非功能性需求对软件系统的质量有着举足轻重的作用。但软件测试的用例设计是不可穷尽的,工程实践中难免受制于时间成本和经济成本,所以测试部门需要兼顾缺陷风险和研发成本之间的平衡。
  缺陷分类
  根据缺陷的定义,将缺陷分为如下4类:
  a.文档缺陷
  指对文档的静态检查过程中发现的缺陷。检查活动包括同行评审、产品审计等。评审的缺陷要根据被评审对象的类型来确定,被评审的对象包括最终出产出物和中间过程产出物。比如产品需求文档、原型设计文档、测试计划、测试用例等。
  b.代码缺陷
  指对代码进行同行评审、审计或代码走查过程中发现的缺陷。
  c.测试缺陷
  指由测试活动发现的测试对象的缺陷,被测对象一般是指可运行的代码、系统,不包括静态测试发现的问题。
  d.过程缺陷
  又叫做不符合项问题,是指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是测试人员、项目经理等。
  == Bug的严重性定义==
  根据所提交bug的严重性,本规范定义以下五个级别。
  A类:严重错误,包括以下各种错误:
  1.由于程序所引起的死机,非法退出。
  2.死循环
  3.数据库发生死锁
  4.因错误操作导致的程序中断
  5.功能错误
  6.与数据库连接错误
  7.数据通讯错误
  B类:较严重错误,包括以下各种错误:
  1.程序错误
  2.程序接口错误
  3.数据库的表、业务规则、缺省值未加完整性等约束条件
  C类:一般性错误,包括以下各种错误:
  1.操作界面错误(包括数据窗口内列名定义、含义是否一致)
  2.打印内容、格式错误
  3.简单的输入限制未放在前台进行控制
  4.删除操作未给出提示
  5.数据库表中有过多的空字段
  D类:较小错误,包括以下各种错误:
  1.界面不规范
  2.辅助说明描述不清楚
  3.输入输出不规范
  4.长操作未给用户提示
  5.提示窗口文字未采用行业术语
  6.可输入区域和只读区域没有明显的区分标志
  E类:测试建议
  Bug的优先级定义
  根据所提交bug的优先级,本规范定义以下五个级别。
  Highest :表示问题必须马上解决,否则系统根本无法达到预定的需求。
  High:表示问题的修复很紧要,很急迫,关系到系统的主要功能模块能否正常。
  Medium:表示有时间就要马上解决,否则系统偏离需求较大或预定功能不能正常实现。
  Low:表示计划解决,表示问题不影响需求的实现,但是影响其他使用方面,比如页面调用出错,调用了错误的等。
  Lowest:即问题在系统发布以前必须确认解决或确认可以不予解决。
  测试标准
  功能测试的通过准则一般有:
  1.单元功能同设计需求一致;
  2.规定的路径覆盖率及覆盖类达到要求,且执行正确;
  3.所规定的黑盒测试手段被使用,且执行正确;
  4.对残留错误有合法解释或被认可暂留;
  5.虽然路径覆盖率不能达到,但其他各测试的错误查出率趋产0或稳定(时间的长短视情况而定)。
  各类软件测试合格须符合以下标准。
  以上比例为错误占总测试模块的比例。
  软件产品未经测试合格,不允许上线发布。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理

评 论

论坛新帖



建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海信义律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2021, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道