4.19学习测试模型
1.软件的非正常运行状态也会引发很多问题.
非正常运行状态是指的软件的一些逆向操作
导致软件失效或缺陷(bug).
2.软件是由代码和文档组成的,而这些都是由
“人” 来设计和编写的,人都有可能犯错。
文档;需求文档
代码:开发所编写的项目代码
3.环境也会影响软件,以致出现软件“失效”现象
开发环境;
测试环境:
预发布环境:
生产环境:
不同的环境,服务器的配置,以及其他硬件上
的配置都存在差异。
4. 软件测试活动只是关键的质量保证活动之一
产品经理:尽可能将用户需求梳理正确.保证文档正确性
开发人员:开发代码的质量.
测试人员:最后一道关卡,来进行测试保证产品的质量.
测试用例:是我们测试人员执行测试依据.
软件生命周期的阶段?
1.客户的问题引入定义:
.产品经理引入客户的需求
2.可行性分析:
技术:我当前项目组的开发技术可不可以支持项目
开发工作.
经济:当前我项目组的资金能不能支持项目组的运作.
当前开发出来的产品是否具有一定经济价值
政治:符合政治要求.
法律:不能涉及黄赌毒.
3.项目招投标
项目组拟建公告,吸引有资质的公司来承担我们公司
当中一部分的开发工作.
例:微信视频,朋友圈,支付,聊天,小程序
将支付交给其他公司来做.
4.项目立项.
1.成立项目组
2.招人制定计划,分配任务
5.需求分析.
项目组所有组成员,针对产品经理他输出的需求文档
进行分析了解。
6.开发阶段.
设计:设计我们当前系统的开发框架 ,开发模式.
开发:编码,实现需求当中的功能
测试:针对开发完成的产品,进行检查测试.
7.维护。
1.正式推送用户使用.
2.维护工作,对接客户,解决客户问题
软件的开发模型:
瀑布模型:
瀑布模型是在1970提出.他的开发模式是由上到下按
阶梯进行.每一个阶段任务的完成代表下一个阶段的任务
开始.
缺点:测试行为在末尾阶段,很难在前期引入一些问题.一旦
后期出现需求方面的变动.会导致返工的工作量较大.
一旦后期出现问题也会引起返工工作量增加
优点:
1.适用大型的项目管理.
2.他清晰的表达了软件开发的全部过程.
使用瀑布模型的要求:
1.需求稳定,不会出现频繁的需求变更.
v模型:
1.用户需求:产品经理对接客户收集客户需求
2.需求分析:
分析的对象:需求文档,需求原型图
产品经理会召开需求评审会议,在会议当中产品经理
讲述他需求文档当中的一些功能点,以及具体的业务
逻辑,以及当前开展专业名词讲解.
测试开发人员,进行了解需求,针对产品经理讲述的功
能进行评审,看他讲述的过程当中是否存在需求模糊的
地方,以及需求矛盾的地方,以及当前是否当前是否可
以实现该功能,
目的:达到项目组理解一致,没有任何需求上的歧义.
3.概要设计:HLD
概要设计是由谁设计的?
是由开发人员进行设计.
概要设计主要设计系统的开发框架,以及服务器,数据库
等等相关的设计工作,然后输出相关的文档.
4.详细设计:LLD
详细设计也是由开发人员进行设计的.
主要设计:项目当中一些细节功能点的设计工作.业务功能
逻辑的设计
5.编码阶段:
开发人员根据概设详设文档进行开发代码的工作.
6.单元测试(百盒子测试):
开发完成代码之后,进入单元测试,检查所写的代码,以及
运行代码看有没有出现问题
7.集成测试:简称:IT
集成测试也叫做:组装测试l,把所有开发开发好的功能
集中在一起进行测试.
第一种:模块与模块组装对接
例:支付模块,聊天模块,朋友圈模块,小程序模块
集中在一起进行对接测试,来看有没有问题的产生
第二种:系统与系统进行组装对接
例子:美团系统对接微信系统的支付功能
支付宝系统的支付功能
银联系统的支付功能.
8.系统测试:ST
系统测试的内容:
针对我当前系统的所有功能进行详细检查,包含我功能
下面所有子节点,以及相关的细节进行全面检查.
包含的测试行为:需求测试,界面测试,功能测试,兼容性
,安全性测试,可靠/可用测试,移植性,性能测试,易用性.
9.验收测试 UAT:
阿尔法 α:
由公司项目组员工进行验收测试.开发,产品,测试都
会在场,进行验收这个产品到底合不合格.有没有达到用户
的使用标准,还有没有bug.
贝塔 β:
由客户进行验收.测试完成之后.将产品交付给客户
进行验收,后续在跟进用户反馈的问题做一些整改.
(重点)
v模型的输入与输出关系;
输入:用户需求 输出:需求分析
输入:需求分析 输出:概要设计
输入:概要设计 输出:详细设计
输入:详细设计 输出:开发编码
输入:开发编码 输出:单元测试
输入:单元测试 输出:集成测试
输入:集成测试 输出:系统测试
输入:系统测试 输出:验收测试
v模型:其实也是瀑布模型的衍生.测试的阶段还是在开发编码
之后,这个模式,还是会导致一旦出现需求变更,或者是重大问题
的时候,反工的工作量较大.他是第一个注重测试行为的开发模型
,将测试行为划分为4个阶段(单元测试,集成测试,系统测试,验收
测试)
优点:1.清晰表达全部的开发过程,便于控制每一个开发过程
的任务进度
2.将测试行为具体细化(单元测试,集成测试,系统测试,
验收测试)
3.每个阶段的行为都有了参考的依据,同时他还是一个
串行结构的模型,每个测试节点,都可以参考对应串行
节点的内容.
缺点:
1.测试行为依然在开发编码结束之后,前面很难在需求分
析就引入一些问题。
2.后期如果出现需求变更,或者是重大问题,导致返工的工
作量增加.
W模型;
他是把测试阶段提到需求分析进行同步介入工作。
W模型,每一个对应的阶段执行对应的测试。
优点:
优点:
1.测试行为伴随着整个开发周期.
2.开发和测试进行并行.可以很好的掌控开发测试进度
缺点:
1.对测试人员的技能要求比较高
2.有些项目根本不会产生概要设计/详细设计文档.就
导致了无法按照w模型去走.
H模型:
项目和产品的区别:
项目一般会以产品进行命名.
项目和版本的区别:
一个项目包含多个版本.
敏捷开发模型:
没有具体的模型展示图,他在1990年提出的敏捷开发模式
开发周期短,能够快速适应市面上的需求变动.
敏捷开发模式--->1-2周一个版本功能.
开发周期短,它能够快速适应时长
注重的理念就是:
1.快
2.强调研发部门一个沟通协作的能力,在敏捷开发模式当中
不会产生一些实质的文档,强调的是人与人之间沟通.
缺点:
1.虽然敏捷开发的周期短,与预示着测试覆盖的功能不全
面,会导致线上导致一些问题.
2.对开发/测试要求比较高.
增量开发模式:
例:一个项目当中需要开发:聊天,支付,朋友圈,小程序,视频号
我不是一次性将所有功能交付给客户,我会先发布一个聊天的
功能给用户先使用.接下来的功能开发,按照我当前用户需要紧
急程度,划分我后面功能的开发优先等级.
增量开发模式优点:
1.将所有已知的功能模块化,可以分批次的交付给用户.客户
也可以了解到我们当前软件开发的进度.
2.开发顺序灵活,能够自由调整开发顺序,能够先开发一些
稳定的模块.
迭代开发模型:
迭代开发模型不像瀑布模型一样非常庞大/完美,他是一个阶段
一个阶段实现部分功能.最终迭代完成之后交付给用户一个完善
的产品.
1.开发周期端.每个阶段的成果都可以快速的交付给客户
2.降低产品风险,指定工作计划进行推进.在推进的过程当中
可以结合一个阶段用户反馈的文件进行细化和优化产品.
迭代开发模型和增量开发模型的区别:
迭代的过程阶段我是未知的,我是根据用户不断反馈来完善产品
增量:我已知的工作,按模块划分交付给用户
测试的基本原则:
测试不单单是软件本身的测试.
1.服务器,
2.数据是否正确
3.app手机物理硬件配置
4.网络情况
软件外在没有失效,并不代表软件是用的.
穷尽测试是不可能的.
针对条件组合情况,只是挑选几条测试组合情况进行
测试.
二八原则:
百分之80的错误都会集中出现在百分之20的区域当中
针对出现问题比较多的模块,我们测试人员应该更加
仔细的检测.一个问题的出现会导致新的问题的出现.
杀虫剂效应:
当前新开发好功能模块,执行以前的测试用例去排查
问题,找到问题的几率为零.我们需要根据新的版本去
更新新的测试用例.
测试活动依赖测试对象:
关注界面
关注功能
关注性能
关注兼容性
关注的点不一样,发先的问题也是不一样.我们应该在
早期测试计划当中就制定好所有的接测试测试策略,来
保证全方位的测试覆盖度.
在项目开始时,就应该制定好软件质量标准.
有了质量的标准,那么我们所测试出来的结果,才能够正
确的分析产品的质量,进行评估.
测试的准入阶段:(介入测试条件.)
1.开发完成编码,完成单元测试.
2.需求当中规定所有功能都已经实现
3.基本的主体功能流程畅通,界面上的功能都已经实现
4.开发组向测试组提交(测试申请单),以及相关的服务
,数据配置好之后,测试人员介入测试.
测试分析与设计:
分析:分析需求文档以及对应的生成的开发文档
设计:设计的是测试用例
测试的实现与执行:
执行测试用例--->提交测试出来的问题--->修复bug
--->验证bug ---->关闭bug
测试报告(测试的准出):
1.开发完成编码,完成单元测试.
2.需求当中规定所有功能都已经实现
3.所有的测试用例都以及执行通过
4.输出测试报告:
测试过程当中的资产归档(测试总结)
1.辅助测试工具进行归档
2.此次测试过程当中所有测试用例
3.此次测试所产生bug
4.测试总结
此次测试过程当中所产生的问题(bug)
项目组流程问题.
页:
[1]