软件测试概念

什么是软件测试

验证软件功能是否满足用户的需求。

软件测试和研发的区别

1、测试与调试的区别:
目的不同
–测试的任务是发现程序中的缺陷;调试的任务是定位并且解决程序中的问题。
参与角色不同
–测试主要是由测试人员和开发人员来执行,黑盒测试主要由测试人员完成、单元/集成测试主要是由开
发人员执行。调试由开发人员完成。
执行的阶段不同
–测试贯穿整个软件开发生命周期,调试一般在开发阶段
2、难易程度 开发广度小,专业度高。测试广度大,专业度低
工作环境 基本类似
薪水 中小企业总体比研发低,自动化等专业测试领域和研发基本无差距。大厂研发测试基本无差别发展前景 自动化测试、安全测试等领域发展前景和研发基本一致。
繁忙程度 一般比研发轻松,但敏捷模式下差距不大,产品发布前压力比较大
技能要求 测试要求更广泛:业务能力,设计和架构分析能力,测试手段和工具使用,用户模型分析和理解,
编程能力

为什么选择软件测试职位

思维模式、兴趣、性格特征、能力、抗压力等
讲故事方式

什么是需求

满足用户的期望或者软件规定的文档(标准、合同、规范)所需要的条件或者权能,包含用户需求和软件需求
用户需求:可以简单理解为甲方提出的需求,如果没有甲方,那么就是终端用户使用产品时必须要完成的任务。该
需求一般比较简略。
软件需求:或者叫功能需求,该需求会详细描述开发人员必须实现的软件功能。
软件需求是测试人员进行测试工作的基本依据。

BUG

1、当且仅当规格说明存在并且合理,软件实际输出与规格说明之间的不匹配、称之为软件错误(BUG)。
2、如果规格说明不存在,程序没有满足用户合理预期,称之为软件错误。

什么是测试用例

尾了实施测试而向被测试系统提供的一组操作集合,包括测试环境、测试数据、测试步骤、与其结果。

一、软件的生命周期

需求分析、计划、设计、编码、测试、运行维护

二、软件的开发模型

1、瀑布模型
2、螺旋模型
适合项目:项目庞大、前期需求不是很明确、风险比较大的项目
3、增量模型、迭代模型
在这里插入图片描述

4、敏捷开发(scrum)
在这里插入图片描述
Scrum流程:发布计划会议(PO)、迭代计划会议、每日站会(三件事)、演示会议、回顾会议
敏捷开发总结:请流程、轻文档、重目标、重产出
轻量级:迭代周期短、参与人员少
敏捷中的测试:测试用例的作用减弱、主要用思维导图整理测试思路、要运用探索性测试。
测试人员和开发人员关联紧密、测试人员不仅要找BUG、还需要和开发人员一起寻找BUG产生的原因

一、软件测试模型

1、软件测试V模型
特点/优点:后期的测试阶段和前期的阶段可以一一对应起来、清楚的标注每个测试用例的依据
缺点:不利于项目前期风险的及时发现
在这里插入图片描述

2、W模型(双V模型)
在这里插入图片描述

特点:测试在项目前期介入,对需求、系统设计都会进行验证
优点:测试介入早,有利于全面得发现系统前期的风险
缺点:阶段性比较强,强调一个阶段完成之后再进行下一个阶段,不可逆,所以便无法适用需求经常变动的敏捷开发

软件测试的生命周期

需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

需求阶段
–测试人员了解需求、对需求进行分解,得出测试需求
计划阶段
根据需求编写测试计划/测试方案
设计阶段
–测试人员适当的了解设计,对于设计测试用例是很有帮助的,测试人员搭建测试用例框架,根据需求和设计
编写一部分测试用例
编码阶段
–测试人员一般是不需要编码的,但已经编码的模块,专业的白盒测试人员可以计划执行单元测试,完善、细
化测试用例以及调整测试计划和方案。
测试阶段
–测试阶段是软件测试人员最为重要的工作阶段,根据测试用例和计划执行测试,在执行的过程中记录、管理
缺陷,测试完成后编写测试报告。
运行维护
–测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解,加上测试人员的沟通表达
能力一般都比较强,所以测试人员可以参与用户使用软件的培训,在试运行项目时收集问题并及时反馈给相
关负责人。

如何描述一个bug

目的:让开发人员更好的定位BUG
版本号:
测试环境:硬件设备、软件环境(设备系统、浏览器)
操作步骤:
预期结果:
实际结果:
其它:

一个合格的bug描述应该包括以下几个部分:
1、发现问题的版本
开发人员需要知道出现问题的版本,才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析
每个版本的质量。
2、问题出现的环境
环境分为硬件环境和软件环境,如果是web项目,需要描述浏览器版本,客户机操作系统等,如果是app项目,需
要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤
描述问题重现的最短步骤。
4、预期行为的描述
要让开发人员指导怎么样才是正确的,尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故
障,能写明需求的来源是最好的。
要相信:测试人员是最懂需求的。
5、错误行为的描述
描述错误的现象。crash等可以上传log,UI问题可以有截图。
6、其他
某些公司会有一些其他的要求,例如故障的分类:功能故障,界面故障,兼容性故障等。有些有优先级的分类,严
重影响测试需要开发人员优先修改的,可以设置优先级为高。

在这里插入图片描述

bug的级别(严重程度)

崩溃:系统无法运行。例如:运行系统死机;死循环;数据库死锁
严重:系统可以运行,但是不稳定。例如,数据库数据插入错误,密码明文显示;直播画面失真;数据泄露
一般:系统可以稳定的运行,但是功能没有完全实现。例如,查询错误,微信朋友圈图片显示不出来;
次要:建议类问题。。如:错别字、界面格式不规范,
页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受
不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)

与开发人员产生争执怎么办

1、先检查自身,是否bug描述不清楚
2、站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰,这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时,可以问一句:如果你是用户,你可以接受么?
3、BUG定级要按照公司标准、规范
4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案
5、进行Bug评审

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页