【软件测试】软件测试的基础概念

一、一个优秀的测试人员需要具备的素质

技能方面：

• 优秀的测试用例设计能力：测试用例设计能力是指，无论对于什么类型的测试，都能够设计出高效的发现缺陷，保证产品质量的优秀测试用例。这就需要我们掌握设计测试用例的方法、阅读好的测试用例设计案例、积累和总结来提高我们测试用例设计的能力。
• 掌握自动化测试技术（编写测试工具，自动化测试用例）。掌握自动化测试技术，可以吧你从大量重复性的手工劳动中解放出来，这样就可以把更多的精力花在更多类型的测试上。
• 业务快速学习能力：我们在工作的时候，不可能一直做一类工作（不同的工作小组，负责不同的业务），所以就需要我们快速学习不同的业务。
• 开发能力：掌握一定的开发技术，这对于测试人员来说是一个优势。

综合方面：

• 沟通能力：测试工程师的沟通能力会对测试工作的开展具有很大的影响，良好的沟通能力可以让我更快更好的完成我们的工作。
• 文字表达能力：测试用例是用文字写出来的，你找到的bug，也要通过文档来具体的描述。我们在测试完成之后，是需要总结出来一个测试文档的，里面详细记录了有那些bug,这些bug在哪里，产生了什么问题等等，都需要我们能够表述清楚。
• 抗压能力：抗压能力并不是测试人员独有的，这是所有从事互联网人员都需要具备的能力。比如：我们工期时间比较紧的时候，就需要我们加班。
• 责任感：责任感是任何工作都需要的，对于测试工作而言，测试往往是产品质量的最后一个把关者；由于测试工作成效很难衡量，测试用例执行、bug数量的多少都无法说明产品的质量是否合格，所以责任感是最重要的测试必备素质之一。

二、衡量软件测试结果的依据——需求

1、什么是需求

需求可以分为两部分：一部分是用户需求，一部分是软件需求

• 用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务，该需求一般比较简略。
• 软件需求：或者较功能需求、该需求会详细描述开发人员必须实现的软件功能。

2、案例—平台支持邮箱注册

我们实现一个支持使用邮箱注册的一个注册系统，如下

用户需求：平台支持邮箱注册。

软件需求：

1.1.1.1、注册账号

1.1.1.1.1、 功能概述 ：用户可以通过填写邮箱信息在平台注册个人用户。

1.1.1.1.2、用户角色 ：匿名用户。

1.1.1.1.3、前置条件 ：无。

1.1.1.1.4、输入

1.1.1.1.5 处理

1.1.1.1.5.1 基本事件流

1、 用户选择注册；

2、 系统展现用户协议界面，并请用户确认是否同意用户协议

•  若用户不同意协议，系统禁止用户注册。
•  若用户同意协议，用户进行注册信息填写。

3、 用户填写注册信息。 注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。

4、 用户提交注册信息；

5、 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收 到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。

6、 用户可执行激活操作，直接跳转至注册邮箱门户页面。

7、 用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。

1.1.1.1.5.2 扩展事件流

•   用户注册并激活成功后，第一次登录平台时，提示用户完善信息；

1.1.1.1.5.3 异常事件流

• 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
•  每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。

1.1.1.1.6 输出 用户注册成功

1.1.1.1.7 后置条件 该模块为用户登陆等的前置模块

3、从软件测试人员角度看需求

需求是测试人员开展软件测试工作的依据。

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件需求点，软后分析出每个软件需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

过程如下，业务需求—>软件功能需求点 —>测试需求点—>测试用例

 对一个软件功能需求点，进行拆分，涉及到那些测试需求点。（功能、兼容性、安全性、性能等等）。每个测试需求点在拆分多种测试用例（如：用户登录的软件功能的功能测试需求点可以拆分为输入的密码和用户名正确，验证是否登录成功、用户名和密码中出现空格，登录时是否成功、用户名和密码是否大小写是否敏感）。

 三、测试用例

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

• 测试环境：就比如我们在力扣上做题，他提供给我们一个测试环境（Chrome浏览器）
• 测试数据：我们将代码完成之后，会出现测试用例的通过率，涉及到的数据就是测试数据。
• 预期结果：我们做完题之后，期待的通过率为100%，这就是预期结果。

测试用例提高测试人员工作效率、降低测试人员工作的重复性问题。测试用例是建立自动化的基础。

四、软件错误（bug）

1、什么是bug

软件错误的一般定义：程序与规格说明书之间不匹配。这是比较片面的说法，准确的来说：当且仅当规格说明是存在的并且正确（软件需求，规格说明书），程序与规格说明之间的不匹配才是错误（预期结果 != 执行结果，即bug）.

当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期功能要求时，就是软件错误（bug）。

2、如何描述一个bug

1、发现问题的版本

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

2、问题出现的环境

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

3、错误重现的步骤

猫叔重现的最短步骤，方便开发人员复现问题。

4、预期行为的描述

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

5、错误行为描述

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

6、不要把多个bug放在一起

在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

3、如何定义bug的级别

1、Blocker（崩溃）

阻碍开发或测试工作的问题，造成系统崩溃、死机、死循环、导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失问题。

2.Critical（严重）

系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，一级功能菜单不能使用等问题，这就是严重的bug.

3、Major（一般）

功能没有完全实现，但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。比如：操作时间长，查询时间长、格式错误等。

4、Minor（次要）

界面、性能缺陷、建议类的问题，不影响操作功能的执行，可以优化性能的方案等。比如：错别字、界面格式不规范等问题。

4、bug的生命周期

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

五、开发模型和测试模型

1、软件生命周期

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

 1.1、软件测试的生命周期

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

1、需求分析

• 验证需求的正确性以及合理性。
• 接着便是细化需求，找出测试点，方便后面写测试用例。

2、测试计划

• 确定软件有谁测试，什么时候开始测试，什么时候结束测试、有谁测试

3、测试设计、测试开发

• 根据需求、写出测试用例（手工测试用例、自动化测试用例）
• 编写测试工具

4、测试执行

• 测试用例设计完成之后，就要执行测试用例来验证程序功能了。
• 在执行测试用例的过程中，可能会遇到软件功能与需求不相符的情况，也就是出现bug，测试测试人员需要将bug记录下来交给开发人员来处理。

5、测试评估

在测试完成之后就需要测试人员编写一个测试报告。

测试报告中包含了下面的内容

• 测试人员
• 测试时间：开发时间~结束时间
• 开发人员
• 开发时间
• 测试用例
• bug

2、开发的五大模型

2.1、瀑布模型

特点：瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点：每个阶段做什么，产出什么非常清晰

缺点：风险往往迟滞后期的测试阶段才显露，因此失去及早纠正的机会。

项目的使用：小型的项目使用于这种模型。

2.2.、螺旋模型

一般在软件开发初期需求不是很明确时，采用渐进的开发模式。螺旋模型是渐进式开发模型的代表之一。

这对于那些规模庞大、复杂度高、风险大的项目尤为适合。这种迭代开发的模式给软件测试带来了新的要求，他不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

优点： 每个阶段都会进行风险分析，避免一些线上问题发生

缺点：风险分析依赖于专业的风险评估人员评估，这也就存在分析出错的问题，反复分析会出现大量的人力和财力的投入。

适用项目：庞大的、复杂的并且具有高风险的项目

2.3、增量，迭代

假设我们要实现一个项目，该项目有3个模块ABC。

增量模型：将3个模块按顺序开发，先完成A，然后完成B，接下来完成C，按照顺序一个一个完成。

迭代模型：先将3个模块的基础框架建好，然后在这个基础上，继续完善3个部分的一些代码。（就像盖房子一样，将整体的墙体构建完成，然后再对每个房间进行细节上的完善）。

2.4、敏捷（思想）

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过 程派聚集在犹他州的Snowbird，决定把“敏捷”(Agile)作为新的过程家族的名称。

在会议上，他们提出了《敏捷宣言》（http://agilemanifesto.org/）： 我们通过身体力行和帮助他人来 揭示更好的软件开发方式。经由这项工怍，我们形成了如下价值观。

• 个体于交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划
• 再每对比对中，后者并非全无价值，但我们更看重前者。

scrume开发模式 

scrum开发模型中的三大角色

scrum由product owner（产品经理）、scrum master(项目经理)和team（研发团队）组成。

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

 迭代开发

与瀑布不同，scrum将产品的开发分解为若干个小sprint（迭代），其周期从1周到4周不等，单不会超过4周；参与的团队成员一般是5到9人，每期迭代要完成的user story（用户故事/需求）是固定的，每次迭代会产生一定的交付。

scrum的基本流程。

• 产品负责人负责整理user story ，形成product backlog（产品代办事项）
• 发布计划会议：产品经理（product owner）负责讲解user story，对其进行评估和排序，发布计划会议的产出就是指定出这一期迭代要完成的story列表，product backlog（产品代办事项）。
• 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
• 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么，今天计划做什么，有什么问题。
• 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由产品经理整理，形成新的story.
• 回顾会议：项目团队本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果。

 3、测试模型

3.1、v模型

 各阶段的大概过程

• 用户需求：产品经理将用户需求收集形成软件需求
• 需求分析与系统设计：验证需求是否正确，确定编程语言，确定框架等。
• 概要设计：项目结构如何设计。
• 详细设计：每个接口涉及那些库表，涉及那些任务。
• 编码：写代码。
• 单元测试：我们再编写项目的时候，再Controller层编写完成一个方法的时候，就会进行单元测试。
• 继承测试：将许多方法集成，测试不同模块接口见是否可以正常的配合使用。
• 系统测试：对整个系统功能进行测试，也要保证模块和模块之间不会相互影响。
• 验收测试：产品和运营确认软件系统符合用户和利益相关者的要求。

特点：左边是开发，右边是测试。类似于瀑布模型

优点：测试被划分成许多类型。

缺点：测试人员介入太晚，发现问题时机太晚。

3.2、W模型（双V模型）

特点：开发是一个V，测试是一个V

优点：测试人员尽早介入了需求。

缺点：测试人员和开发人员一定程度上还是串行的，不能拥抱变化，不能使用于敏捷。

V模型和W模型都不能拥抱变化，一旦开始就不能再修改用户需求了。（不能添加新的需求，这就是不能拥抱变化）。