目录
1. 什么是软件测试
2. 软件测试和软件软件开发的区别
3. 软件测试(Testing)和软件调试(Debug)的区别
4. 什么是需求?
5. 需求是测试人员开展软件测试工作的依据
6. 测试人员如何深入了解需求?
7. 测试用例(Test Case)
7.1 测试用例的好处
8. 什么是软件错误(Bug)
9. 开发模型(5个)
9.1 软件的生命周期
9.2 瀑布模型
9.3 螺旋模型
9.4 增量 和 迭代模型
9.5 敏捷模型
10. 软件测试模型
10.1 V模型
10.2 W模型(双V模型)
比如说,我们在刚买来一部手机的时候,最先做的事就是找问题,看这部手机有没有什么Bug。所以,对于软件测试最常见的理解就是:找Bug。
软件测试就是软件测试人员验证软件产品特性是否满足用户的需求。
从难易程度上来说:开发所需要的广度小,但专业度高。测试所需广度大,专业度低。
从技能要求上来说:测试要求更广泛(业务能力,设计和架构分析能力,测试手段和工具的使用,用户模型分析和理解,编程能力)
目的不同:调试是软件开发人员确保程序做了自己想要程序实现的功能;测试是软件测试人员确保程序解决了它应该实现的功能。
参与角色不同:调试是由开发人员完成;测试是由测试人员和开发人员共同完成。
执行阶段不同:测试贯穿整个软件开发的生命周期;调试一般在开发阶段。
需求:满足用户期望和合同的规定,所需的条件和权限,包含用户需求和软件需求。
用户需求:甲方提出的需求,或者是终端用户使用产品时,必须要完成的任务。该需求一般比较简略。
软件需求(功能需求):详细描述开发人员必须实现的软件功能。
在进行设计具体的测试用例之前,要先搞清楚每个业务需求对应的多个软件功能需求点,在分析出每个软件功能需求点对应的多个测试需求点,针对每个测试需求点设计测试用例。
测试人员应在需求分析和设计阶段就开始接入,更好的理解和掌握软件的原始业务需求。
测试用例是 向被测试系统发起的一组集合,包含测试环境、测试数据、测试步骤、预期结果等要素。
测试用例告诉测试人员测什么(系统展现注册页面是否合理)、怎么测(手工)。
衡量需求的覆盖率(测试用例和需求对比,查看还缺少什么),有复用性和借鉴意义,可以用于回归测试,防止遗漏测试需求。
当且仅当软件需求存在且合理,若软件功能和软件需求不相符合,就是Bug。
当软件需求不存在,用户需求存在并且合理,软件功能和用户需求不相符合,就是Bug。
软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。
软件的生命周期分为6个阶段:
需求分析 ---> 计划 ---> 设计 ---> 编码 ---> 测试 ---> 运行维护
瀑布模型的每个阶段只执行一次,故是线性顺序进行软件开发模式。
优点:阶段性强,每个阶段都比较独立,看重前期的需求分析和后期的测试阶段。
缺点:测试在编码之后才进入,导致前期的问题后期才发现,失去补救的机会。
螺旋模型一般在软件开发初期,需求不是很明确时,采用的渐进式开发模式。
适合项目庞大,风险大,目标不明确的项目。
优点:强调个开发阶段的质量,分析项目是否有价值继续下去。
缺点:投入人力物力很多,成本较大。
增量模型和迭代模型通常混为一谈,但两者之间还是存在区别的:比如同一系统的四个模块A,B,C,D,要求在两周完成。增量模型:第一周开发A,B功能的模块;第二周开发C,D功能的模块。迭代模型:第一周开发 A,B,C,D基础功能;第二周在A,B,C,D已经开发的基础功能上开发别的功能。
优点:抗风险能力增加。
敏捷开发以用户需求为核心,采用迭代、循序渐进的方法进行软件开发。软件项目在构建初期被切分成多个子项目,各个子项目的成果经过测试,都具备可视、可集成和可运行使用的特征,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成。在此过程中,软件一直处于可使用状态。敏捷开发的宣言就是尽早的、持续的交付有价值的软件来使客户满意。开发宣言如下:
特点:个体与交互 重于 过程和工具可用的软件 重于 完备的文档客户协作 重于 合同谈判响应变化 重于 遵循计划有效、简单、持续交付的能力。
优点:高适应性,以人为本。注重市场快速反应能力,即就是具体应对能力,客户前期满意度高。
缺点:注重与人员的沟通,但忽略文档的重要性,若项目人员流动太大,胡给维护带来不少难度;项目周期长,很难保证开发的人员不更换,没有文档就会造成在交接的过程中出现很大的困难。
scrum 基本流程:
三个角色:
PO:产品经理,整理需求。
SM:项目经理,保证敏捷流程。
ST:各种技能的工程师组成,开发产品。
五个会议:
产品发布会议:产品经理负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的产品功能列表。
迭代计划会议:项目团队对每一个产品功能进行任务分解,分解的标准是完成该产品功能列表的所有任务,每个任务都有明确的负责人,并完成工时的初估计。
每日站会:团队成员回答昨天做了什么今天计划做什么,有什么问题。
产品演示会议:相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由产品经理整理,形成新的产品功能。
项目回顾会议:项目团队对本期迭代进行总结,发现不足,制定改进计划,下一次迭代继续改进,已达到持续改进的效果。
V模型大体可以划分为以下几个不同的阶段步骤:客户需求分析、软件需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。
客户需求分析:明确客户对于产品的需求,软件所具备的功能。
软件需求分析:根据客户需求分析出软件方面的需求。
概要设计:主要是架构的实现,指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。
详细设计:对概要设计中表述的各模块进行深入分析,对各模块组合进行分析等,这一阶段要求达到伪代码级别,已经把程序的具体实现的功能,现象等描述出来。需要包含数据库设计说明。
软件编码:按照详细设计好的模块功能表,编程人员编写出实际的代码。
单元测试:按照设定好的最小测试单元进行按单元测试,主要是测试程序代码,确保各单元模块被正确的编译。
集成测试:单元测试后,将各单元组合成完整的体系,主要测试各模块间组合后的功能实现情况,以及模块接口连接的成功与否,数据传递的正确性等,其主要目的是检查软件单位之间的接口是否正确。
系统测试:经过了单元测试和集成测试以后,我们要把软件系统搭建起来,按照软件规格说明书中所要求,测试软件其性能功能等是否和用户需求相符合,在系统中运行是否存在漏洞等。
验收测试:主要就是用户在拿到软件的时候,在使用现场,会根据前边所提到的需求,以及规格说明书来做相应测试,以确定软件达到预期的效果。
优点:
1. 描述了这些 测试阶段和开发过程之间各阶段对应的关系(从左到右一一对应)。
2. 每个阶段独立性强,指出单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求。
3. 是瀑布模型的变种。
缺点:编码后才进行测试,前期的错误后期才发现,失去修改的机会,模型灵活性低。
由两个V字型模型组成,克服了V模型的缺点,W模型增加了软件开发各阶段中同步进行的验证和确认活动。由两个V字型模型组成分别代表测试与开发过程并行的关系。
测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计文档等开同样要测试, 也就是说,测试与开发是同步进行的。
W 模型有利于尽早全面地发现问题。 从需求分析开始测试工程师就参与到项目的测试中,当需求分析完成后,测试工程师就需要参与到需求的验证和确认活动中,并需要提供可测试性需求分析说明书,这样可以尽早地发现需求阶段的缺陷。 同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,这将显著减少总体测试时间,加快项目进度。 但W 模型也存在局限性,需求、设计、编码等活动被视为是串行的,同时,测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一阶段工作,这样就无法支持迭代的开发模型。
优点:每个阶段独立性强,测试一开始就介入保证前期的问题及时发现更改,测试伴随整个开发周期,测试与开发并行。测试的对象不仅仅是程序,还有需求和设计。
缺点:每个阶段都是串行的过程,一个阶段完成之后就直接进入下一个阶段,无法支持敏捷开发。测试技术要求高,实现起来困难。