测试1:测试相关概念

1.测试相关概念


1.1.测试概念

1.1.1.需求

符合正式文档规定的条件和权能,包括用户需求和软件需求
测试1:测试相关概念

它们之间的的转换是:沟通

测试1:测试相关概念

用户需求和软件需求的区别:

能否指导开发人员开发,测试人员编写测试用例

1.1.2.缺陷Bug

正确的需求规格说明书不一致或与用户合理的期望不相同

缺陷的状态:

new、open、fixed、closed、reopen5 $ L l :、rejected、delay

测试1:测试相关概念

1.1.3.测试用例

向被测程序输入的一组集合,包括要素:

测试环境、测试数据、测试步骤、测试预期结果、测试版本、备注

思路:

1.对核~ . { ` ` Y 1 Q z心主要功能进行测试

2.进行异常(逆向、扩展、发散)--容错性测试

3.g { j g : .写功能测试之外的测试点(安全、性能、界面、易用)

存在的问题:

1^ | , ! @ | p.设计测试用例是费时费力6 5 E ` ` P u的工作,比执行时间长

2.测e b y + 8 % e试的覆盖率无法衡量,对新版本的重复测设很难实施

2.开发模型和测试模型

1.软件生命周期

软件生命周$ U w ~ F z u期是指软件的产生直到报废的生命周期。从软件产品的设想开始到软件不再使用而结束的时间

具体包括m f Y d 3 l
问题的定义及规划,需求分析,软件设计(概要,详细),软件编码,x W K ( w软件测试(单元测试,集成测试,系统测试,验收测试),运行维护

2.测试生命周期

测试周期是指从测试F 1 ,项目计划建立到BUG提交的整个测试过程。 软件测试周期并行与软件生命周期,存在于软件生命周期的各个阶段

参考 :软件测试的流程

1、需求分析阶段:阅读需求、对需求进行分解、分析, w F 5 ( s主要就是对业务的学习,分析需求点,参与需求评审会议

2、测试计划阶段:主要任务就是编写测试计划、测试方案,参考软件需求规格说明书,项目总体计划,内容包括测试范围(来自需求文档),进度安排,人力物力的分配,整体测试策略的制定。风险评估与规避措施有一个制定。

3、测试设计、测试开发阶段:测试人员适当的了解设计,对于设计测试用例是很有帮助的,测试人员搭建测试X z 5 | i L用例框架,根据需求和设计编写一部分测试用b : ] & - n U例。

4、测试执行阶段:测试执行阶段是软件测试人员最为重要的工作阶段,根据测试用例和计划执行测试。

​ 搭建环境,执行冒烟测试(预测试)-然后进入正式测试,bug管理直到测试结束

5、测试评估阶段:执行的过程中记录G H d、管理缺陷,测试完成{ & 2 z % $ C N [后编写测试报告,进行测试评估,确认是否可以上/ ^ O n r X线

测试1:测试相关概念

  • 测试报告包含哪些内容

    测试概况--测试过程分析--缺陷分析--测试结论--测试清单

3.开发模型

3.1o F n 瀑布模型:串行

适用n | 4 i ?:项目需& N / y i ~ M求稳定,需求变更较少的项目或 } 2 ) / =是之前已有的做过的产品
测试1:测试相关概念
优点:

分步清晰,阶段性强:测试阶段单独分出来

缺陷:集成之日就是爆炸之时

(1)测试阶段靠后,发现问题的时机晚,修改成本高,风险大。

(2)测试阶段靠后,误认为测试不重要

(3)项目成果不能及时分享其它项目

(4)不能适应需求变化

瀑布W Q j u | E模型

把软件开发模型分为好几个阶段[ * $ ~ m j z ^ K,包括软件计划、需求分析、设计、实现、软件. O f a测试、软件运行维护。

具有一种比较明显的分层,每一阶段的结果文档会作为下一阶段的输入i { u _ T X y I,强调文档,整个周期完成的差不多了才能看到结果;

没有迭代和反馈,只能一步一步来,流程没有回头路。不能适应客户不断变化的需求,后期需要改动时成本也比较大

测试比较晚,基本上是在软件完成之后进行的测2 q 6 p g

3.2 螺旋模型:渐进式

适用:复杂度高、风险大、规格大,做一点测一点,测试O r M必须跟随开发。没有独立的s , G g % A测试时间和阶段

强调:风险,保证各个阶段的质量

缺陷点: ( N r Z i 7 M o对人员的要求比较高,投入时间多,人力成本高,进度缓慢

3.3 增量和迭代:

目的:大型项目,为减少项目的风险

增量:显著降低项目风险,逐块建造,一部分一部分的做,新版本、新加功能对软件其他功能没有影响

迭代:反复求精,先轮廓再细化,新版本、新加、删除功能对软件其他功能有影响,原来功能需要修改

3.4敏捷开发模型:快速迭代,若干小迭代

敏捷宣言4条:(敏捷开发与传统开发的区别)

(1)轻文档,对Y ( s F 6 Q文档依赖度低,但还是需要。强调软件Z s B u S t的可用性

(2)强调人? I h与人之间的沟通

(3)客户参与

(4)在正式发布之前拥抱变化,

敏捷开发有很多+ 8 k .方式,SCRUM是比较流行的一种

特点:

(1)三种角色:产品经理、项目经理、研发团队

(2)不超过10人(5-9人)

(3)每天有站立会不超过15分钟,回答昨天2 t s G P t做了什Y y 1么,今? # R m G M z c g天要做什么,有什么问题

(4)迭代时间1-4周。每次迭代产生一定的交付(会做出一点功能,即使还不完善)

流程:

po整理USER STO{ E ! ) YRY --开会学习USER STORY,确定每次迭代完成的USER S* n z L $ 9 CTORY

----分配USER STORY,确定完成时间--开发完成--测试中--测试完成--待发布上线--发布上线

敏捷开发:

按一个短的迭代周期工作,强调“快”,每次迭代交付一些成果,(或者@ / Z 9 ^ j i T Y说先做出一个不完美但能实现一定的功能的版本)F { G q H;让客户参与进来,有新需求就,快速响应变化,迭代产生新版本,缩短软件版本的周% & n U x 3 ` J c期。

强调开发软件而不是文档。r 8 b m M B H t Z

特点:让客户参与进来,客户需求的变动和软件有些$ ; m V ! B =不符合需求的地方可以第一时间进行了解和改动; 缩短版本周期; 每隔一段时间(一个迭代周期),团队可以在工作方面进行反省和改进,调整自己的行为; 强调开发软件而不是文档,提高编程人员的积极性。

敏捷测试:

以用户需求为中! e , [ ?心,Q r @ 1 h在每一个迭代周期都需要进/ . C [ y 7行测试m t v t

基于自动化测试->速度快、敏捷

更强调测试的速度和适应性,侧重计划的不断调整以适应需求的变化

强调面对面的沟通、协作,强调团队的责任,不太关注对缺陷的b B f 8记录与跟踪。缺陷修复的成本也较低

4. 软件测试V模型

目的:改进软件开发的效率和效果

是瀑布模型的变种

测试1:测试相关概念

单元和集成测试:检测程序的执行是否满足设计的要求

系统测试:检测系统功能和性能的质量特性是否达到系统要求的指标

验收测试:确定软件的实现是否满足用户需求、合同要求

局限= ; . # U性:测试阶段在编码之后,未在许爱u阶段就进入测试

4.2 W模型(双V)

解决V的缺点,每个阶段都有测试工作,不一定是测试人员参与

测试1:测试相关概念

特点:

1.测试与开发并行

2.测试的对象不仅是程序,好包括需求、设计等

3.能尽| S B 6 ^ y早全面发现问h , W S

局限性:测试盒开发保存一种线性的前后关B h y J 7系,上一阶段完全结束,才可开始下一阶段,不能支持敏捷开发模式

V模型和W模型的比G c z ,较:

V模型:把测试过程作为在需求分析、系统设计及编码之后的一个阶段,忽视了测试对需求分析,系统设计的验证,需求的满足情况一直到后期的验B x L 2 { * *收测试才被验证。(应该比较多包括系统测试和验收测试)

W模型:测O w ] k试的活动与软件开发同步进行,测试的对象B E c @ c @不仅仅是程序,还包括需求和设计。因为在需求阶段测试就已经介入了,后面每一阶段的开发都需要经过测试,能够尽早发现软件的缺陷,降低debug的成本

4.3 敏捷测试(解决VW的缺陷):

沟通、适应

文档可v [ 4 9 $ ~以写粗略,可以画思维导图,借助自动化

3.如何t f h e K j 8 p %描述一个缺陷

对bug的描述尽量简短但要求清晰,对bug出现的条件进行详细的描述,包括输入的测试用例、使用的环境、有T J h 6 ! B m V没有和其他软件同时运行,以及需要写清bug出现的位置,Z % V z # 2 2帮助开发更好J % 9 ( 4 @ J 0定位。

按照j B H ?用户体验(bug是h 7 s ( G否很严重的影响用户体验)、影响系统的程度进行评级。

3.1 要素(一条bug记录的组成)

测试环境、测试数据(内容)、测试步骤、F q N预期结果、实际? R k b L ~结果、缺陷级别、测试版本、前提条件、发生的位置

3.2C l V 缺陷的d o + j k g级别(如何对一个bug评/ o ( p M t !级)

3.2.1 简单版

测试1:测试相关概念

崩溃 严重 一般 次要 建议

A B C D E

崩溃:直接造成软件不能使用,造成死机、数据丢失等

严重:功能不能使用,数据丢失。与需求严重不0 L L _ n符,不影响其他功能测试的情况下可以继续版本测试

一般:功能没有完全实现但不影响使用,不影响系统的稳定性

次要X 6 G 8 }:界面、性P c C { o E能缺陷,建议类问题,文字错误等

3.2.2 详细描述

Bug的priority()和severityI T w T { * O()是两个重要属性,通常人员在提交bug的时候,只定义severityO 5 b ! V q,而将priority交给leader定义,通常bug管理中,severity分为四个等级bl% t o 2ocker、critical、major、minor/trivial,而priority分为五个等级immediate、urgent、high、normal、low。 Severity:

14 e / t、blocker:即系统无法执行,崩溃,或严重资源不足,应用模块无法启动或异常退出,无法测试,造成系统不稳定。常见的有严重花屏、内存泄漏、用户数y r B ?据丢失或破坏、系统崩溃/死d 5 _ e 4 M S R o机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致$ 7 9 Q 7无法测试的错T & ~ O 5 6 L误, 如服务器500错误。

2、critical:即映像系统功能或操作,主要功能存在严重缺陷,但不会映像到系统稳定性。常见的有:功能未实现,功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。

3、major:即界面、性能缺陷、兼容性,常见的有:操作界面错误,边界条件错误,提示信息错误,长时间操作无进度提示,系统未优化,兼容性问题。

4、minor/trivial:即易用性及建议性问题。 Priority 1、immediate:即马上解决, 2、urgent:急需解决 3、high:高度重1 V ! k $ L 视,有3 R } ~ v R时间要马上解决

5、low:在系统发布前解决,或确认可以不用解决。

3.3 bugY 0 _ l i 的生命周期

测试1:测试相关概念

Start--New :测试人员发现bug,提交到平台后的状态为new

New--Open:测试人员将bug提交给某个研发人员的状态为Open

Open--Regected:研发人员验证不是缺陷,将状态改为rejected,返回给测试

Open--Delay:研发人员验证是缺陷,但不影响s 6 ` 0 % . X 3使用,等下个版本在修改,De4 j %lay

Open--Fixed:研发人员验证是bug,T f ] - % A ^ {进行修改

Fixed--Closed:G _ Q - : , g研发人员修改完成,测试人员验证通过,就Closed改bug

Fixed--Reopen:研发人员修改后,测试人员没有验证通过,就是Reopen再到Fixed

无效的bug:

open--closed open--rejected--closed

3.4bug都有哪些周期,请你描述不同类别的bug?

测试1:测试相关概念
测试1:测试相关概念

3.5 如何发现更多的缺陷

1.二八原则--人员、模块
测试1:测试相关概念

2.逆向思维、扩展性思维

3.不要依赖需求和测试用例

4.测试尽早介入