软件测试概念

什么是软件测试

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

软件测试和研发的区别

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评审