软件测试——基础概念篇_blocker、critical

开启新副本软件测试环节~~本文将从需求、bug、测试用例等方向入手，了解软化测试的一些基本概念。

1.需求的概念

        需求是衡量软件测试结果的依据。那么何为需求？

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

IEEE定义：软件需求是 (1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。

在公司中会将需求分为俩部分：1.用户需求 2.软件需求

1.1 用户需求

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

官方一点的说法是：用户需求是指用户对某个产品或服务的期望和要求，也就是他们想要这个产品或服务做到哪些事情。为了更好地满足用户的需求，我们需要了解用户的痛点、问题和使用场景，并从中确定目标人群和角色，以便更准确地定义用户需求。通过定义用户需求，我们可以更好地建立共识，减少分歧，确保后续工作围绕着明确的目标展开。

1.2 软件需求

或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能

在公司中，或者整个开发这个过程来说，就是将用户需求转变成软件需求再开发出产品。开发人员的开发依据就是软件需求。

 

2.测试用例

        测试用例是一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

测试用例解决了俩个问题：测什么，怎么测？

测试用例在我们做oj题的时候，会遇见：

测试环境就是我们做题时用的浏览器，测试数据就是它给的用例，预期结果我们当然是希望全过100%，操作步骤：写代码 提交。

测试过程中可能会遇到以下问题： –不知道是否较全面的测试了所有功能 –测试的覆盖率无法衡量 –对新版本的重复测试很难实施 –存在大量冗余测试影响测试效率
测试用例的产生就是为了解决上述的问题

3.BUG

        我们经常说Bug，但是Bug是啥捏？通俗来讲:bug就是这个程序在运行的时候，不符合我们预期就是Bug 。

        但上面的说法是片面的，准确来说：当前仅当规格说明是存在的并且正确 程序与规格说明之间不匹配才是错误的。 (预期结果 ！= 执行结果)

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

4.软件生命周期

       软件生命周期包含：需求分析 、计划、编码、测试、运行维护。

5.开发模型

        1.瀑布模型

瀑布模型在软件工程中占有重要地位，每个环节只执行一次，因此瀑布模型是线性的，也如其名，环节在执行完之后就像瀑布的流水，不能回头了。

特点：线性的

优点：每个阶段做什么，具体的事项是非常清晰的。

缺点：风险往往是在后期发现了，前面做的努力全部浪费，失去及早纠正的机会。

适用场景：小项目、比较急的项目

        2.螺旋模型

螺旋模型是一种软件开发过程模型，它结合了瀑布模型和增量迭代模型的特点。它强调风险管理和迭代开发，通过重复执行计划、风险分析、工程构建和评估的阶段，来满足项目需求并降低风险。螺旋模型适用于复杂、不确定和变化频繁的项目，可以快速响应变化并提高开发效率。

优点:每个阶段都会进行风险分析，及早避免一些问题的发生 

缺点：风险分析可能分析错，需要大量的人力财力。

适用项目：适用于比较大的项目。

         3.增量、迭代

增量迭代模型是一种软件开发过程模型，结合了增量模型和迭代模型的特点。在增量迭代模型中，一个大型的项目会被分成多个独立的小项目（即增量），每个增量会依次实现一些预定的功能或者特性。而每个增量内部则采用迭代模型进行业务功能的开发和测试。这样做的好处是，各个增量之间相对独立，可以并行开发，同时在每个增量内部采用迭代模型，可以逐步实现、验证和交付具体的业务功能。增量迭代模型适合于需求比较明确，但仍然存在一定程度变化的项目开发，能够提高开发周期的灵活性和项目的可控性。

以软件开发为例，假设我们要开发一个电商网站。在增量迭代模型中，我们将项目拆分成多个独立的小项目（即增量），每个增量包含一些预定的功能或特性，比如“用户注册”、“商品浏览”、“购物车”等等。

而每个增量内部则采用迭代模型进行业务功能的开发和测试。也就是说，增量是逐步构建的概念，而在每个增量内部采用迭代模型，则可以逐步实现、验证和交付具体的业务功能。例如，“用户注册”这个增量可以分成多个迭代，分别实现基本雏形、完善具体功能、进行测试等等。

同时，由于各个增量相对独立，可以并行开发，各个增量可以依照开发的优先级依次完成。而增量迭代模型适合于需求比较明确，但仍然存在一定程度变化的项目开发，能够提高开发周期的灵活性和项目的可控性。

再举一个简单的例子：我们想要开发网课这个项目，包含几个模块：登录、创建课程、上课

增量：登录开发完成->创建课程->上课

迭代：登录开发一部分->创建课程一部分->开发上课模块一部分

        4.敏捷模型

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

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

 由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程(Social Engineering)的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。

其中敏捷模型比较常见的方式是 srume

        4.1 scrume

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

        4.2 scrum的基本流程

 6.软件测试模型

        6.1 V模型

特点：左边是开发、右边是测试 有点类似瀑布模型

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

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

        6.2 W模型

 

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

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

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

7. 软件测试的生命周期

         

 8.如何描述一个bug

1、发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2、问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤
描述问题重现的最短步骤。
4、预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。
要相信：测试人员是最懂需求的。
5、错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。
6、其他

某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
7、不要把多个bug放到一起

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

 8.如何定义bug级别

1、Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
2、Critical（严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
3、Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）
4、Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
 

用一个具体的例子来表示以上四种等级：对象劈腿会让我们崩溃，所以这个级别就是Blocker、如果是对象搞暧昧 会让我们稍微不那么崩溃 这就是Critical级别、如果是对象和其他异性一起吃饭 这就是Major级别、如果是和异性打招呼 就是Minor级别。当然 这种对对象忍受程度每个人都不一样，因人而异、而公司也是这样的，每个公司对bug定义都是不一致的。

9. bug的生命周期

        

 10.如何发现更多的bug

1、软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度！
2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度！
3、多进行逆向思维和发散性的思维
4、不要局限于用例和需求文档
5、尽早介入项目, 不要等到开发的差不多了再介入项目