软件测试基础篇(4)

一)软件测试的生命周期:

1)需求分析:站在用户角度，查看需求逻辑是否正确，是否符合用户的需求和行为规范，站在开发角度来说，技术可行性分析和市场可行性分析；

2)测试计划:按照需求计划文档，测试目标，测试范围，测试人力安排，测试工时，测试方法，测试所需要的工具

3)测试设计，测试开发:根据需求文档和开发的设计文档来编写测试用例，开发人员可能已经写好了一些小的模块，经验丰富的白盒测试人员对已经编码好的代码可以进行单元测试

4)测试执行:根据测试用例执行测试

5)测试评估:做好测试记录，做好缺陷管理，然后进行测试的评估，哪些功能是项目上线需要组内成员关注的地方，那些地方没有及时的关注，遗漏了哪些BUG；

二:为什么说软件测试贯穿于软件开发的生命周期？

将软件测试的生命周期贯穿于软件开发的生命周期

1)当测试人员进行产品的演示和功能的介绍的时候，会在演示会议里面，演示会议里面通常由项目组的所有成员来组成，比如说运营同学，产品经理；

2)最终开发出来的软件要符合产品经理的一个需求，开发人员和测试人员往往不会和用户来进行对接，而是产品经理，开发人员和测试人员往往是来从产品经理了解需求；

3)后台管理软件:不是给线上用户来使用的，这个功能是给运营同学，产品经理来进行使用的，方便与查看用户的一些情况以及其他的一些数据，因为运营同学不懂数据库不会写SQL，比如说运营同学或者产品经理想要查看某一位符合要求条件的用户，这时候就需要开发人员来帮助产品经理进行查找，并把截图或着导出一个文件文件发送给产品经理，但是这无疑增加了开发人员的压力，所以就直接开发创建一个后台管理软件来提供给产品经理进行使用，减少开发测试人员的工作量，这个软件还是有测试人员来进行演示；

 

螺旋模型拥抱需求变化，适用于前期需求不确定，风险大，规模大的项目

增量模型:适用于快速发布项目，逐快建造

迭代模型:先上线一个版本，后续不断地进行产品的优化，精益求精

三)如何描述Bug？如何提出一个BUG？

开发人员首先看到第一眼看到的就是标题，简单描述必须简介明了，开发人员收到这个BUG的第一部一般是来确认这个BUG，确认这个BUG是否存在，是否是真正的BUG，要复现这个BUG，针对于BUG来说，标题写得好，开发人员才能及时的点进去这个BUG

四)描述一个BUG如何描述呢？

注意发现问题的版本:测试包/版本，正式包/版本

发现BUG的环境:不同的浏览器打开的页面是不同的，不同的终端打开的页面也是不一样的，把环境描述好了，接下是让开发人员去复现出来BUG，并且认可这个BUG；

测试人员提出了一个BUG，开发人员修复了，但是测试人员回归的时候发现这个BUG仍然存在，这是什么原因导致的?

1)可能是是因为开发人员他没有修复正确；

2)测试人员没有拉取最新的测试代码进行进行测试；

网易邮箱注册:邮箱地址输入5个字符，输入符合需求规则的密码和手机号，注册成功

zhw11@163.com huiwen123456 18947174037

1)测试版本：verson11

2)BUG标题：输入长度小于6个字符，网易邮箱注册成功

3)测试环境：Windows10，64位， Chrome浏览器，版本:90.0.4430.212

4)测试数据：zhw11@163.com huiwen123456 18947174037

5)测试步骤：

1)进入网页邮箱注册页面，http://mail.163.com/register/index.html?from=163&utm_source=163mail地址进入到注册页面，

2)输入邮箱地址为5个字符，填写符合需求的手机号和密码，这里最好把自己手机号和密码都传递给开发人员；

3)勾选同意，点击注册

6)实际结果：注册成功

7)预期结果：注册失败

五)BUG的级别

这里仅供参考，今后在工作中需要提前看一下企业对应的BUG顶级标准文档

1)崩溃:系统已经无法正常运行，已经严重的阻碍了开发人员或者测试人员的工作，查询的时候死循环，无法刷新，一些严重的BUG已经影响了到了测试工作的进行(性能非常差)，系统崩溃，死机，主要功能确实，数据库大面积数据的丢失，如果线上出现了这种问题，立马版本回退到一个系统稳定的状态，某一个步骤出现了严重的错误，测试人员和开发人员的工作已经没有办法继续执行了，开发人员应该立马修复这个BUG；

2)严重:系统还可以进行运行，但是此时系统已经不稳定了，如果继续运行下去，会产生很严重的后果例如直播画面失真模糊会丢失用户，丢失流量百度账号串号了，不可泄漏用户隐私

3)一般级别:系统可以稳定的运行，但是会影响用户的操作，功能实现了，但是有问题；

翻页功能，300条数据，一个页面展示50条，一条相同的数据在不同的页面同时出现；排序出现了问题，1-50出现在第一页；50-100出现在第二页.......忘记排序，每一页都有相同的数据，用户不舒服；

性能问题:卡，一条数据在不同的页面都出现过(排序出现了问题)(根据权重来进行排序)

4)次要建议型的:页面的排版，字体的大小，弹出框没有确定按钮，图片显示不好看，让开发人员修改并进行回归；

六)BUG的生命周期:什么是Bug的生命周期呢？

是指:从测试人员创建Bug产生到被开发人员解决的过程

测试人员在创建完BUG之后，开发人员要确定这是一个BUG并且还要修复BUG，测试人员还需要进行回归测试验证

七)开发人员不认可这是一个BUG，怎么办，下面的建议一定做到

测试人员需要具备良好的软件素质，工作能力以及协作沟通能力，千万不能吵架，开发人员说这不是一个bug，复现不出来？开发人员要复现BUG，解决BUG；

1)具备批判性思维，多反思自己，先检查自己的问题，看看自己的对于BUG的描述是否清楚，是否上传了错误截图，是否指明了测试环境，测试数据等等；

2)BUG定级要有理有据，是否符合公司的规范，站在用户的角度和使用情况来进行判定，而不是说我认为感觉他是一个严重的BUG，就是一个严重的BUG，要参考公司的规范；

测试人员提了一个BUG是严重级别，开发人员不同意；

3)要不断提升自己的业务水平和技术水平，学会SpringBoot，redis也会开发方面的知识，要是开发人员开发能力差，测试人员提出了一堆BUG，定位BUG出现的位置何原因，提出这个BUG的可能的解决方案，与开发人员进行沟通是很方便，多多学习的，给出解决方案，定位问题，要提升自己的技术能力；

4)不仅提出问题还可以提出解决方案，高级的测试人员在提出BUG的时候也能告诉开发人员的原因是什么，比如说测试人员在代码中发现if条件不对，那么就直接画一个框，在旁边说正确的逻辑应该是什么样子；

初级测试提了一个BUG，开发人员直接进行反问，这是一个BUG吗？

高级测试提了一个BUG，给明了解决方案，并在错误截图旁边进行有效的标记，树立权威性

5)开发人员直接说，BUG可以进行忽略，不需要进行修改，需求也没有提及到，用户也能正常使用，小问题，测试人员要从用户的角度来看来劝说开发人员，来考虑这个问题，了解原因，软件的性能比较差，用户体验感不强，合理友好的进行沟通:如果你是用户？你能接受这个BUG吗？符合用户的需求吗？你使用方便吗？

6) 可以和产品经理进行商量，邀请代表进行开展BUG评审

此时良好的沟通已经无法解决问题

讨论这个BUG有没有修改的必要以及解决方案，或者产品经理，开发小组长，测试小代表进行三方会谈，讨论这个BUG的解决方案，本来是一个BUG，但是开发人员就是不改，这时面对面高效沟通已经劝说不了你了，必须要请产品代表，开发代表，测试代表邀请这些人进行BUG评审，必须由第三方来进行BUG公平公正的一个评判；

八开这个BUG评审会的目的是什么呢？

在这里面一定要说明，表达清楚

5.1)测试人员讲解这个BUG是什么？当前遇到的问题是什么？

5.2)开发人员不进行修改的理由是什么？

5.3)测试人员要求你改的理由是什么？

5.4)讨论如何进行修复BUG，提出解决方案

5.5)如何避免类似的BUG出现

九)软件带来的错误有很多，主要的原因有哪些？  

1)需求不明确，软件需求不清晰或者开发人员对需求理解不明确,导致软件在设计时偏离客户的需求目标,造成软件功能或特征上的缺陷，此外,在开发过程中,客户频繁变更需求也会影响软件最终的质量。

(2)软件结构复杂，如果软件系统结构比较复杂,很难设计出一个具有很好层次结构或组件结构的框架,这就会导致软件在开发、扩充、系统维护上的困难。即使能够设计出一个很好的架构,复杂的系统在实现时也会隐藏着相互作用的难题,而导致隐藏的软件缺陷。

(3)编码问题，在软件开发过程中,程序员水平参差不齐,再加上开发过程中缺乏有效的沟通和监督,问题累积越来越多,如果不能逐一解决这些问题,会导致最终软件中存在很多缺陷。

(4)项目期限短，现在大部分软件产品开发周期都很短,开发团队要在有限的时间内完成软件产品的开发,压力非常大,因此开发人员往往是在疲劳、压力大、受到干扰的状态下开发软件,这样的状态下,开发人员对待软件问题的态度是“不严重就不解决”。

(5)使用新技术现代社会,每种技术发展都日新月异。使用新技术进行软件开发时,如果新技术本身存在不足或开发人员对新技术掌握不精,也会影响软件产品的开发过程,导致软件存在缺陷

十)两个测试模型:

一:软件测试V模型:缺陷和瀑布模型一样

从上到下是一个开发模型，从下到上是一个测试模型

单元测试和集成测试通常由开发人员来完成的，验收测试是用户来验收

二.软件测试W模型:测试贯穿于软件开发的生命周期

两个V进行相互交叉，又称之为双V模型

1)W模型增加了软件开发阶段应该同步进行的验证和确认活动，在我们的需求分析完成之后，测试人员就应该参与到对需求的验证和确认活动中，早早地找到问题所在，同时对需求的测试也有利于及时了解项目难度和测试风险，及早的制定应对措施

2)显著减少总体测试时间，加快项目进度，测试介入比较早，前期的风险可以比较早的发现，快速的纠正；

用户需求 -->    做好验收测试的准备                         支付    开始进行验收测试
   需求分析 -->  做好系统测试的准备                    实施    开始进行系统测试
      概要设计 -->  做好集成测试的准备              集成   开始进行集成测试
        详细设计 -->   做好单元测试的准备            单元测试
                                        编码                        

优点:

1)测试从需求阶段就开始介入了，项目风险在早期就能够被发现，项目风险遗漏的概率还是比V模型小的；

2)两个V迭代了一起，用户需求阶段，测试阶段就开始进行介入了，验证了各个阶段的合理性，更好的保证软件的质量，前期的缺点可以及时地发现；

缺点:

黑盒测试工程师:把代码看成一个黑匣子，只关心输入和输出结果之间的一个关系，只是关心输入对应的输出一定是符合需求要求的，产品质量也不一定是好的，是否符合功能的基本需求，比如说给定很多输入数据，进行登陆注册给定的页面结果是否符合预期

白盒测试工程师:把代码看成一个百匣子，可以看到代码的逻辑，针对代码进行测试，发现可能会存在缺陷的情况；

比如说举个例子:需要对QQ账号进行测试，要求QQ账号的长度范围是0-10

1)但是黑盒测试假设此时输入的QQ账号长度是2，5，8，此时软件功能没有任何问题

2)但是在代码中，假设变量是${length}

if(${length}==4)  return；

3)此时开发的代码就是有问题的，因为此时如果说输入了字符长度是4，那么就会跳出循环，出现BUG