软件测试基础概念篇

目录

一、软件测试基础认识

1、软件测试的基础概念

2、调式和测试的区别

3、测试人员需要具备的素质

二、测试的部分名词解释

1、需求的基础认识

2、bug的概念

3、软件测试用例

4、软件开发的生命周期

三、开发模型介绍

1、瀑布模型

2、螺旋模型

3、增量模型和迭代模型

4、敏捷模型

四、bug的相关描述

1、软件测试的生命周期

2、如何描述一个bug

3、bug的级别

4、bug的生命周期

五、软件测试模型

1、软件测试v模型

2、软件测试W模型

3、跟开发产生争执怎么办

---

一、软件测试基础认识

1、软件测试的基础概念

软件测试就是执行和运行软件的过程，其目的是为了发现软件功能和需求不相符合的地方，或者寻找实际输出和预期输出之间的差异，软件测试贯穿整个软件的生命周期的。

2、调式和测试的区别

目的：调式的目的是解决软件的缺陷，测试的目的是发现软件的缺陷

参与角色不同：调式是在开发阶段开发人员的，测试是有测试人员，开发人员等多种人员配合进行

执行阶段不同：测试贯穿软件的整个生命周期，调式主要是在编码阶段进行的工作

3、测试人员需要具备的素质

（1）思维模式

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

案例：手机中有两条通话记录，进行删除。删除为0后，继续删除。

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

案例：测试一台自动售票机。正向，逆向，边界，压力，性能，耗电量，断电，外观，没零钱.....

（2）兴趣

真的有兴趣么？而不是开发加班多，不想编码？

（3）性格特征

好奇心、成就感、敏感、不浮躁、善于怀疑、批判性思维：清楚--准确、切题--深刻，有意义，有逻辑性--公正、全面

（4）能力

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

（5）责任感和压力

责任感：测试往往是产品的最后一个检验者；测试的工作成效很难衡量，测试用例执行、bug数目的多少都无法说明产品是否能

够交给用户使用。所以，责任感是最重要的测试必备素质之一。

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

二、测试的部分名词解释

1、需求的基础认识

（1）需求的概念

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

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

较简略。

软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。 大多数公司在进行软件开发的时候会把用户需

求转化为软件需求，开发人员和测试人员工作的直接依据 就是软件需求。

（2）从软件测试人员角度看需求

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

以“用户登陆”为例，来阐述下整个过程：

（3）如何才可以深入理解被测试软件的需求

测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好 时机。 只有真正理解了

原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用 场景到端到端的覆盖率较高的测试用例集。

2、bug的概念

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

件错误。

3、软件测试用例

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

测试用例解决了两大问题：测什么，怎么测。 测试用例一般使用思维导图完成。

水杯的测试用例

4、软件开发的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事 物，那么软件的生命周期

可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。

阶段	概念解释
需求分析	分析用户提出的需求是否合理(市场分析，技术分析，可行性分析等)
计划	确认需求需要执行多久，对需求进行详细计划
设计	将需求细化为一个个任务
编码	开发人员按照需求进行编码
测试	测试人员参考测试用例执行各种测试
运行维护	项目上线之后对产品进行线上的维护（修复性维护：对项目中未发现的问题进行修复；完善性维护：对功能进行完善；预防性维护：为了避免产品在线上出现一些问题所进行的预防手段）

三、开发模型介绍

1、瀑布模型

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

特点：线性的开发流程

缺点：测试被后置（风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会；必须在代码完成后有足够的时间预留给测试活动， 否则将导致测试不充分，从而把缺陷直接遗留给用户） ，瀑布模型最大的缺陷在于可以运行的产品很迟才可以被看到。

适用场景：需求固定的小项目

2、螺旋模型

螺旋模型引入全流程的风险分析，每次分析完成之后都会生成一个新的原型

优点：强调严格的全过程风险管理

缺点：时间拉长、耗费人力资金

适用场景：规模庞大、复杂度高、风险大的项目

3、增量模型和迭代模型

增量模型：假如用户有A,B,C三个需求，开发完A就可以直接供给用户使用，开发完B就可以直接供给用户使用......

迭代模型：先开发一个简单的基础版本(包含功能A,B,C)，但是功能实现的比较简单，后续会在基础版本上不断进行迭代优化

4、敏捷模型

敏捷宣言：

特点：轻流程，轻文档，重目标，重产出

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

三个角色和五个会议：

产品经理：收集用户需求，编写需求文档，对产品负责的人

项目经理：负责召开各种会议，协调项目，为研发团队服务

研发团队：开发人员，测试人员，ui设计人员等等

发布计划会议，迭代计划会议，每日例会，演示会议，回顾会议

scrum的基本流程：

●产品负责人负责整理用户需求，形成左侧的product backlog。

●发布计划会议: product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。

●迭代计划会议︰项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。

●每日例会:每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。

●演示会议:迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。

●回顾会议:项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

四、bug的相关描述

1、软件测试的生命周期

阶段	解释
需求分析	站在用户的角度：查看需求是否符合用户的行为习惯；站在开发人员的角度：思考希求是否可以实现以及实现的难度大小
测试计划	制定测试计划(不仅仅只有测试人员...)
测试设计、测试开发	设计测试用例，比如经验丰富的白盒测试人员进行单元测试
测试执行	参考测试用例执行测试
测试评估	测试人员记录测试过程数据，做好缺陷管理并进行测试评估

2、如何描述一个bug

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

部分	解释
发现bug的版本	开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于 统计和分析每个版本的质量。
发现bug的环境	环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是 app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
发现bug的步骤	描述问题重现的最短步骤。
预期的结果	要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需 求提出的故障，能写明需求的来源是最好的。
实际的结果	描述错误的现象。crash等可以上传log，UI问题可以有截图。
其他	bug类型以及bug等级等等
注意事项	在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

3、bug的级别

注意：每个企业的定义可能不同，这里提供一个参考

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

4、bug的生命周期

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。

● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。

● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

● Rejected：如果认为不是Bug，则拒绝修改。

● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。

● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。

● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。 无效的bug：open->closed open-rejected-closed

五、软件测试模型

1、软件测试v模型

●明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间 各阶段的对应关系 ●V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功 能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同 的要求 ●局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

2、软件测试W模型

●W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分 别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 ●W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的 ●W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需 求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度 和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。 ●局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系， 上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复 杂多变的情况，W模型并不能解除测试管理面临着困惑。

 

3、跟开发产生争执怎么办

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

●站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员 更加积极地、高质量地修改Bug。

●BUG定级要有理有据

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

●开发人员不接受时，不要争吵