测试是什么

我们生活中的测试其实无处不在做核酸就是为了测试自己是否变成了小阳人~ 考试就是为了测试自己的平时学习的咋样还有很多例如接热水你要测试这个水是否是热水即使你去使用眼看水蒸气也是测试的过程 ……
总结来说 测试是为发现错误而执行一个程序或者系统的过程

调试和测试的区别

我们写代码过程中不免出现一些错误此时我们可以借助调试来查看程序运行从而寻找代码bug 那么测试和调试又有什么区别呢？
目的：

调试：发现并解决软件中的缺陷
测试：发现软件中的缺陷

参与角色：

调试：开发人员（研发人员）
测试：测试人员、开发人员等

执行阶段不同：

调试：编码阶段
测试：贯穿软件的整个生命周期

什么是需求

测试需求主要解决“测试什么”，即指明被测对象中什么需要测试
需求测试通常是以软件开发需求为基础的分析，通过对需求的细分化和分解，形成可测试的内容。

需求的定义

用户需求：可以简单理解为甲方提出的需求
软件需求：功能需求
我们也要明确用户需求就是一句话软件需求是一个文档软件需求的文档是根据用户需求制作出来的

需求的特征

制定的测试需求项必须是可核实的它们必须有一个可观察、可评测的结果无法核实的需求不是测试需求
测试需求应指明满足需求的正常的前置条件同时也要指明不满足需求时的出错条件

测试人员眼里的需求是什么

在这里插入图片描述
测试人员眼中是根据需求文档进行演变以及转化分析出业务需求软件功能需求测试所需点测试用例来进行测试的

如何深入了解需求

一般来说会通过参加需求评审会议还有查阅文档以及沟通

测试用例

测试用例在测试人员中通常称位case

什么是测试用例

测试用例是一组集合测试环境测试数据预期结果操作步骤

为什么有测试用例

测试用例有利于提高测试人员工作效率 / 可以降低测试人员工作的重复性
测试用例是后期建立自动化的基础

因为测试用例是无穷无尽的测试人员不能做到所有的都测试并且如果同样一百份测试用例两个人想出来的是大概率有一部分重复的所以此时就需要做出一个测试文档出来将测试用例分配给两个测试人员所以如果可以避免重复性
并且如果建立起来一定数量的测试用例根据测试点就可以编写自动化测试的工具使用自动化测试工作可以大大提升效率尤其是那种需要一直点点点的工作

bug

当且仅当规格说明是存在并且正确程序与规格之间不匹配才是错误的

如何描述一个bug

发现问题的版本
开发人员需要问题知道的版本才能获取对应版本的代码来重现故障并且版本的标识也有利于统计和分析每个版本的质量
问题出现的环境
环境分为硬件环境和软件环境如果是web项目那么就需要描述浏览器的版本操作系统等如果是app项目需要描述机型分辨率操作系统等详细的环境描述有利于故障的定位与记录
错误重现的步骤
描述问题出现的最短步骤（需要有一定的测试经验以及代码研发能力）
预期行为描述
要站在用户的角度来描述程序的行为是怎样的如果是依据需求提出的故障能写明需求来源是最好的
错误行为的描述
描述错误的现象 crash等可以上传log UI问题可以截图
其他
故障分析、功能故障、界面故障、兼容性故障等有些比较严重的bug严重影响后续的测试所以就需要开发人员优先来进行修复
不把多个bug放一起
在无法确定bug是同一个代码造成的故障时不要将bug放在一起提交

如何定义bug的级别

Blocker（崩溃）
Criticcal（严重）
Major（一般）
Minor（次要）

理解这些bug的级别也是很简单的我们把视角转变到女盆友身上（什么？你告诉我你没有？ Java new一个）首先我们都知道男人本色对于男友看美女来说这个级别为Minor（次要）看看美女其实没有特别的严重跪键盘就好了 ~
男友跟别的女人单独去吃饭这个级别为Major（一般）揍一顿其实也没啥男友跟其他女人搞暧昧这个级别为Critical（严重）这个就非常的严重了是属于一件令人很崩溃的事情男友出轨了这个级别为Blocker（崩溃）OMG 这个是一件令人崩溃的事情已经没有继续过下去的必要了

如果发现崩溃级别的BUG 那么此时就需要停止测试测试打回

bug的生命周期

在这里插入图片描述

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed

软件测试的生命周期

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

需求阶段
测试人员了解需求对需求进行分析得出测试需求
计划阶段
根据需求编写测试用例/测试方案
设计阶段
测试人员适当的了解设计对于设计测试用例是很有帮助的测试人员搭建搭建测试用例框架根据需求和设计编写一部分测试用例
编码阶段
测试人员一般是不会去关注编码的但已经编码的模块白盒测试人员可以计划执行单元测试、完善、细化测试用例以及调整测试计划和方案
测试阶段
测试阶段是测试人员最为重要的工作阶段根据测试用例和计划执行测试在执行过程中记录、管理缺陷并在测试完成后编写测试报告
运行维护
测试人员需要参与项目的实施工作测试人员对于项目产品的业务和了解操作非常了解所以测试人员可以参与用户使用软件的培训在试运行项目时收集问题并进行反馈
并且不单单是只要项目上线测试人员的工作就结束了我们刚开始提到了 测试贯穿软件的整个生命周期