从零开始学软件测试这个系列会分成三个阶段
基础篇
过渡篇
自动化测试篇
基础篇(01)谈过了bug的分类,让大家对软件测试的工作对象有了简单的了解,这篇基础篇(02)将会带大家具体了解测试流程,也就是怎样才能更好地找bug
测试过程(以下左图)与测试阶段(或类型)(以下右图)
图文说明
以上左图描述的通用软件测试过程。右图描述的是具体的测试活动阶段,按不同的测试阶段分可分单元测试、集成测试、确认测试、系统测试、验收测试,回归测试,冒烟测试等测试类型。
回归测试是指修改了旧代码后,重新进行测试以确认缺陷的修复,及修改没有引入新的错误或导致其他代码产生错误。软件开发的各个阶段都会进行多次回归测试。
冒烟测试(也叫提交测试),正式测试前对软件主业务流程和主功能进行验证与确认,确保后续测试能正常进行的测试。现状:一般是在新版本提交前,进行正式测试前的进行冒烟测试
右边的每个测试活动阶段,可以按左侧的测试过程进行,文档评审,测试计划、测试设计、测试执行、测试总结等(可根据实际情况对测试过程进行适度裁剪)
左边的和右边两幅图进融入软件开发过程中,就产生了以下将说到的各种测试模型
强调说明
其中系统设计也叫概要设计。
软件需求评审,主要是评审软件需求规格说明书、主要依据是产品需求文档
系统设计评审,主要是评审系统架构设计等,主要依据系统概要设计说明书
详细设计评审,主要是评审详细的设计,比如接口设计是否合理,主要依据详细设计说明书
ps:现实状况是:一般的公司,一般的项目都做不到这么规范的
有些公司甚至没有文档,目前我见过的比较规范的也就银行的质量管理(瀑布模型对银行类项目似乎还是比较实用的)
说明:
V、W模型均存在一些不妥之处。如前所述,它们都把软件的开发视为需求、设计、编码等一系列串行的活动,而事实上,虽然这些活动之间存在相互牵制的关系。
但在大部分时间内,它们是可以交叉进行的,虽然软件开发期望有清晰的需求、设计和编码阶段,但实践告诉我们,严格的阶段划分只是一种理想状况。
试问,有几个软件项目是在有了明确的需求之后才开始设计的呢?
所以,相应的测试之间也不存在严格的次序关系。同时,各层次之间的测试也存在反复触发、迭代和增量关系。
其次,V、W模型都没有很好地体现测试流程的完整性。
为了解决以上问题,提出了H模型。它将测试活动完全独立出来,形成一个完全独立的流程,将测试准备活动和测试执行活动清晰地体现出来。
H模型图仅仅演示了在整个生存周期中某个层次上的一次测试“微循环”。
图中的其他流程可以是任意开发流程。
例如,设计流程和编码流程、也可以是其他非开发流程,甚至是测试流程自身。也就是说,只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以(或者说需要)进行了。
概括地说,H模型揭示了:
测试计划阶段主要工作包括确定测试目的,测试约束,测试需求,测试风险,测试策略,测试资源,测试量化计划,测试进度,测试计划工作量,交付物
测试计划阶段
定义:分析测试需求,设计测试用例,进行测试用例的评审并跟踪测试计划的执行情况。
测试设计阶段
定义:通过测试执行过程中的版本控制、测试环境监控、测试执行进度控制以及变更控制等手段,确保测试对象的质量。
测试执行阶段
定义:对完成的测试任务进行分析、总结,并给出测试结论或建议。
测试总结阶段
定义:主要由开发人员对编写的代码进行自测和交叉测试,检查代码是否实现模块功能,是否符合编码规范,是否存在明显的逻辑错误。
单元测试
定义:将通过单元测试的模块逐步组装成具有良好一致性的完整的程序,制订集成测试实施策略,确定集成测试的实施步骤,设计集成测试用例,逐一地添加模块进行测试。
集成测试
定义:确认测试本身就是属于系统测试,只是有时候强调它的重要性,而单独出来。确认测试确认测试又称有效性测试,的目的是向未来的用户表明系统能够像预定要求那样工作。
确认测试
软件测试的工作归结起来就是两个V,Verification和Validation 。
Verification翻译为验证,在在 ISO9000 中,“验证”的严格定义是:验证是通过检查和提供客观证据,表明规定要求已经满足的认可。
Validation翻译为确认,在 ISO9000 中,“确认”的严格定义是:确认是通过检查和提供客观证据,表明一些针对某一特定预期用途的要求已经满足的认可。
从定义上可以看出“验证”关注是否满足规定,即需求规格说明书
“确认”关注的是是否满足预期用途,即用户的真正需求
我们知道,软件的设计,编码实现都是依据软件的需求规格说明书。对于软件测试来说单元测试,集成测试,系统测试的目的是验证软件是否符合软件的需求规格说明,因此都可归于验证过程。
然而需求规格说明书并不能代表用户的真正需求,而且依据需求的设计也往往同需求会有些偏差,所以得出的软件产品在经过了系统测试以后还需要进行确认测试。
确认测试软件产品是否就是用户想要的产品。
最简单的解释是:
Verification:Are we building the product right?
(功能验证)是否按需求做出了正确的产品
Validation:Are we building the right product?
(有效性确认)是否作出了用户想要的产品
总而言之,验证针对的是软件规则需求说明书,检验软件是不是根据需求来设计实现的,确认针对的是用户,检验软件能否满足用户的需求。
备注:是否要采用确认测试具体要看被测系统的大小。如果被测系统是比较大型的系统,包括软件、硬件等,就需要在集成测试后进行专门针 对软件子系统的确认测试,然后再针对整个系统进行系统测试;如果整个系统就是由软件构成的,就不需要进行专门的确认测试了,在集成测试后直接进行系统测试 就可以了。
定义:验证需求规格说明书中的各个功能点是否齐全、是否正确实现,同时对系统的安装、部署、适应性、信息安全、界面等非功能性需求进行测试。
系统测试
定义:验证需求规格说明书中的业务功能是否满足,并关注系统界面、响应时间等非功能性需求。
用户验收测试(UAT)
以上无绝对描述,具体情况具体分析
测试行业虽然已经步入很多互联网公司的眼帘,但依旧势微,很多公司都不是按着标准的流程再走,况且每家公司不一样,项目不一样,资源不一样,开发模式不一样,流程自然也会不一样
但是讲述本系列的目的,不只让大家知道这些知识,而是需要了解大致思想,了解了测试的思想就可以根据实际情况进行适度裁剪,该有的还是要有的,即便是敏捷测试
以上总结,主要是帮助新手入门,让新手有个大概的印象
最后大家又想交流学习的,可以来我的大家庭聊聊呀点击并输入暗号:CSDN
有资料大礼包相送哦