测试用例

测试用例

测试用例的特性

1.有效性:测试用例的能够被使用,且被不同人员使用测试结果一致
2.可重复性:良好的测试用例具有重复使用的功能。(回归测试)
3.易组织性:好的测试用例会分门别类地提供给测试人员参考和使用(功能、性能、易用分类编号)
4.清晰、简洁:好的测试用例描述清晰,每一步都应有相应的作用,有很强的的针对性,不应出现一些无用的操作步骤。
5.可维护性:由于软件开发过程中需求变更等原因的影响,常常对测试用例进行修改、增加、删除等,以便测试用符合相应测试要求。

测试用例包含什么类容

测试用例包含什么类容
用例编号,所属模块,用例描述,前置条件,优先级,输入数据,操作步骤,预期结果,实际结果,测试人员,测试时间

测试用例的编写方法有哪些?
等价类划分,边界值,错误推测,因果图,场景法,正交表

应用的场景等价类划分
  多用于输入框:注册/登录
边界值(掌握上点和离点的取值)
	多和等价类划分结合使用,有边界限制的:注册的密码长度,,
场景法	
	从基本流开始,再将基本流和备选流结合起来,可以确定用例场景
正交表	
	用于多个下拉框之间的组合,可以通过正交助手生成测试用例
错误推测
	错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
	一般这种方法是基于经验和直觉推测程序中可能发送的各种错误,有针对性地设计。只能作为一种补充
因果图
	因果图法比较适合输条件比较多的情况,测试所有的输入条件的排列组合。所谓的原因就是输入,所谓的结果就是输出
3.测试用例的评审

包含:参与评审人员(需求人员,对应的开发人员,对应的测试人员,项目经理)
评审内容,评审的时间

测试计划

测试背景
测试目的
确定测试范围
制定测试策略(功能测试/业务测试…)
测试资源安排
测试时间安排
测试人员分配
风险评估

缺陷报告

所属产品,所属模块,当前指派(重要),bug类型,操作系统,重现步骤(重要),验证程度(重要),优先级(重要),附件等

测试报告

测试目标,测试的范围,测试环境,测试结果分析(多少轮测试,测试多少,失败多少,成功占比),遗留缺陷,测试结论(本次测试涉及xxx个功能点,发现xx个缺陷,其中,xx个已修复,xx个遗留。)测试过程完整有效,系统测试通过。

软件缺陷的种类划分

功能不正常:简单地说就是所应提供的功能,在使用上并不符合产品设计规格说明书中规定的要求,或是根本无法使用。
软件在使用上感觉不方便:只要是不知如何使用或难以使用的软件,在产品设计上一定是出了问题。所谓好用的软件,就是使用上尽量方便,使用户易于操作。
软件的结构未做良好规划:这里主要指软件是以自顶向下方式开发,还是以自底向上方式开发。如果是以自顶向下的结构或方法开发的软件,在功能的规划及组织上比较完整,相反 以自底向上的组合式方法开发处的软件则功能较为分散,容易出现缺陷。
使用性能不佳:被测软件功能正常,但使用性能不佳,这也是一个问题。此类缺陷通常是由于开发人员采用了错误的解决方案,或使用了不恰当的算法导致的
边界错误:缓冲区溢出问题在这几年已成为网络攻击的常用方式,而这个缺陷就属于边界错误的一种。简单来说,程序本身无法处理超越边界所导致的错误。
计算错误:只要是计算机程序,就必定包括数学计算。软件之所以会出现计算错误,大部分出错的原因是由于采用了错误的数学运算工时或未将累加器初始化为0

软件缺陷的严重程度

按照严重程度分为:系统崩溃,严重,一般,次要,建议 按优先级分:高,中,低

Bug定级示例

1级,系统崩溃
定义:严重阻碍测试和开发工作
对应优先级:最高
具体可分为:
1.功能完全没有实现
2.应用闪退/崩溃无法运行
3.应用必现安全模式,无法运行
4.其他导致功能无法测试的问题
2级,至关重要
定义:非阻碍用例执行的严重问题
对应优先级:高
具体可分为:
1.简单操作应用闪退/崩溃,卡死
2.数据丢失
3.严重影响系统,自身功能无法运行
4.严重数值计算错误
5.数据库损坏或无法保存配置
6.安全性问题(包括数据加密等)
3级,主要
定义:功能存在缺陷,但不影响应用和系统的稳定性
对应优先级:中
具体可分为:
1.内存泄露(长时间不用的对象需要被回收,不被回收占内存)
2.功能实现逻辑覆盖不全面
3.非必现,但复现概率超过50%的闪退/崩溃和安全模式
4级,一般
定义:对应用熟悉度高才能感知到的问题,对应用基本功能实现无影响
对应优先级:中
具体可分为:
1.轻微数值计算错误
2.功能实现有误,与产品文档不完全贴切
3.用户简单操作,即可明显感知的UI问题
5级,较小
定义:界面,性能缺陷
对应优先级:低
具体可分为:
1.操作界面错误(提示显示规则,刷新规则是否与文档一致)
2.边界条件显示错误      
3.提示信息和界面效果展示错误(包括未给出信息、信息提示错误等)
4.复现率低于5%的闪退/崩溃和安全模式      
5.插件兼容和性能未优化问题      
6.非正常操作导致UI显示异常
6级,建议
定义:对于产品的意见或者建议
对应优先级:低
具体可分为:
1.对于产品设计方面的意见和建议
2.对于产品界面优化方面的意见和建议
3.对于产品需要优化增强用户体验方面的意见和建议

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
AUTOSAR(Automotive Open System Architecture)是汽车领域的一种开放系统架构标准。测试用例是为了验证AUTOSAR软件的正确和稳定而设计的一组测试脚本。以下是关于AUTOSAR测试用例的相关解答。 1. 测试用例的目的:AUTOSAR测试用例的目的是验证AUTOSAR软件在不同的测试场景下是否能够按照规范要求正确运行。测试用例可以覆盖软件的各种功能、能和可靠要求,确保软件在实际使用中的稳定和安全。 2. 测试用例的类型:AUTOSAR测试用例可以分为功能测试用例测试用例和可靠测试用例。功能测试用例验证软件的各种功能是否按照规范要求正确运行;测试用例验证软件在负载和压力下的处理能力和效率;可靠测试用例验证软件在异常和故障情况下的鲁棒和恢复能力。 3. 测试用例的设计:AUTOSAR测试用例的设计应根据软件的规范和要求进行。测试用例应该覆盖软件的各种功能和边界条件,以验证软件的正确和稳定测试用例设计还应考虑到软件的可测试和可维护,以提高测试的效率和质量。 4. 测试用例执行:AUTOSAR测试用例执行应根据设计的测试计划进行。测试用例执行过程中,需要记录测试结果,包括测试用例执行时间、执行结果和异常情况等。测试用例执行结果可以用来评估软件的质量和稳定,并作为软件发布前的决策依据。 5. 测试用例的管理:AUTOSAR测试用例的管理应采用测试用例管理系统进行。测试用例管理系统可以帮助管理测试用例的版本和变更,方便测试用例的复用和维护。测试用例管理系统还可以提供测试报告、缺陷跟踪和能分析等功能,提高测试过程的效率和可靠。 总之,AUTOSAR测试用例是为了验证AUTOSAR软件的正确和稳定而设计的一组测试脚本。良好的测试用例设计和执行可以提高软件的质量和稳定,并帮助开发人员发现和修复软件中的缺陷和问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值