关于软件测试

作者：~小明学编程

文章专栏：测试开发

格言：热爱编程的，终将被编程所厚爱。

什么是软件测试？

软件测试就是一系列活动，这些活动是为了评估一个程序或者软件系统的特性或能力，并确定是否达到了其预期的效果。

通俗的来说 : 软件测试就是执行和运行软件的过程，为了发现软件功能和需求不相符合的地方，或者寻找实际输出和预期输出之间的差异。

1.验证软件的功能是否能正常的执行。

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

软件测试和软件开发的区别？

• 软件开发主要是以编码为主而软件测试是以测试为主。
• 一般情况下软件开发的广度小，但是专业度高，而软件测试的广度高但是专业度低。
• 一般比研发轻松，但敏捷模式下差距不大，产品发布前压力比较大 。
• 测试要求更广泛：业务能力，设计和架构分析能力，测试手段和工具使用，用户模型分析和理解，编程能力。

调试和测试的区别？

目的：调试是为了解决程序的bug，而测试是为了找出程序的bug。

参与角色：调试是开发人员参与的，而测试是测试和开发人员都有。

执行阶段：调试是在编码阶段进行的而测试则贯穿软件的整个生命周期。

优秀的测试人员应该具备哪些素质？

1.思维模式：

逆向思维：开发盖房子，测试拆房子。不走寻常路。

例如我们在打游戏的时候一个分数最多显示99999这个时候我就想要知道如过我超过这个分数会怎么样。

发散性思维：探求多项答案。

在做力扣的时候遇到一些测试案例很多的里面会有各种奇奇怪怪的测试样例，这个时候就很佩服出这些样例的人。

2.兴趣：

因为自己比较喜欢测试这个方向，相比于盖房子我觉得拆房子发现房子的问题更加的有趣。

3.性格特征：

好奇心，成就感，敏感，不浮躁，善于怀疑。

4.能力:

快速学习能力,沟通能力,文字能力,开发能力。

5.责任感和压力：

责任感：测试往往是产品的最后一个检验者；测试的工作成效很难衡量，测试用例执行、bug数目的多少都无法说明产品是否能够交给用户使用。所以，责任感是最重要的测试必备素质之一。

压力：来自开发人员、用户、上级、自己的压力。测试人员的压力比想象中的要大。

需求

用户需求

可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成
的任务。该需求一般比较简略

软件需求

或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。

什么是BUG

当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能和要求时，就是软件错误。

测试用例的概念

测试用例是为了实施测试而向被测试系统提供的一组集合，包括，测试标题，测试步骤，前置条件，测试预期，测试环境，测试平台等。

测试用例主要解决了两个问题：测试什么，怎么测。
测试用例 ecsp-439:
用户注册成功步骤动作:期望的结果:进入注册页面，选择注册系统展现注册页面输入符合要求的单位名称、单位邮箱、密码、确认密
码、组织机构代码、验证码，并确认同意《用户注册
协议》，提交注册信息系统进行注册操作，发送激活邮件。注册
成功后，跳转到注册成功页面，并提示用
户进行激活操作。进入注册用的邮箱，进行激活操作激活成功用注册的邮箱和密码，进行登录操作登录成功，系统展示欢迎页面测试方式手工重要性重要测试环境CHROME,IE10+测试前提系统运行正常，邮件服务器已开启功能模块注册登录

软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。

开发模型

瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点：强调开发的阶段性； 强调早期计划及需求调查； 强调产品测试。

缺点：

• 依赖于早期进行的唯一一次需求调查，不能适应需求的变化。
• 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程。
• 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

• 优点： 强调严格的全过程风险管理。 强调各开发阶段的质量。 提供机会检讨项目是否有价值继续下去。
• 缺点： 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入。

增量迭代模型

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。
增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

敏捷模型

敏捷宣言：

个体与交互重于过程和工具：轻流程，强调人与人之间面对面的高效交流。
可用的软件重于完备的文档：轻文档，重产出。
客户协作重于合同谈判
响应变化重于遵循计划：用户可能会增加功能或者修改功能。
在每对比对中，后者并非全无价值，但我们更看重前者。

敏捷开发有很多种方式，其中scrum是比较流行的一种。

scrum里面的角色：scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成

1. 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
2. scrum master 负责召开各种会议，协调项目，为研发团队服务。
3. 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

scrum的流程：

1. 发布会议：产品经理将会告诉我们我们有哪些需求，制定我们的需求列表。
2. 迭代计划会议：把需求一一的列举出来，分解出所有的需求并且将这些需求分给开发人员，划分负责人，初步工时。
3. 每日例会：报告一下我们每个负责人所负责的需求都做到哪了，并且这个过程遇到了哪些问题。
4. 演示会议：经过一段时间的开发，我们的需求已经全部都做完了，然后我们的负责人需要给用户进行演示这个软件到底该怎么去使用，在这个过程中我们的用户可以提出修改，或者添加需求然后我们再次经历前面一轮。
5. 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

测试模型

软件测试V模型

• 优点：明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
• 缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试，导致发现问题的时间较晚。

软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分
别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

• 优点：有利于尽早地全面的发现问题。
• 缺点：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作，无法支持敏捷开发模式，对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

软件测试的生命周期

软件测试的流程

软件测试的生命周期： 需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估。

**需求分析阶段 **：阅读需求，理解需求，分析需求点，参与需求评审会议。

**测试计划阶段 **：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试 范围，进度安排，人力物力分配，整体测试策略的制定。

设计测试阶段：
适当的了解设计，搭建测试用例框架，根据需求和设计编写测试用例。

**测试执行阶段 **：搭建环境准备数据，执行冒烟测试（预测试）然后进入正式测试（系统测试、回归测试、交叉测试、自由测试），bug管理直到测试结束。

测试评估阶段：输出测试报告，确认是否可以上线。

如何描述一个BUG

一个合格的BUG描述应该具备下面几个部分：

1.发现问题的版本：开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。

2.问题出现的环境：环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3.错误重现的步骤：描述问题重现的最短步骤。

4.预期行为的描述：要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。

5.错误行为的描述：描述错误的现象。crash等可以上传log，UI问题可以有截图。

定义BUG的级别

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

一般情况下我们将BUG分为四个等级：

1.崩溃：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2.严重：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。

3.一般：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）。

4.次要：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）。

BUG的生命周期

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

1、先检查自身，是否bug描述不清楚

如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是总有“书难达意”的耐候，这时就需要测试人员主动与开发人员进行沟通了。 如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思，而不要等待开发人员找自己了解更多的信息。

2.站在用户角度考虑问题

应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？

3.提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案

提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。在工作中，你会发现同一个bug，资深测试工程师提出和初级测试工程师提出，两者的结果完全不同，两者最大的差别是资深测试工程师往往会提出解决方案。而长此以往，权威性逐渐的建立起来，那么开发人员看到bug的第一反应，就是这是一个bug，而不是这是一个bug吗？

4.发起Bug评审

Bug评审要注意的问题 缺陷的评审应该包括以下两个层面

● 决定如何处理Bug。

● 分析缺陷产生的原因，找出预防的对策。