分布式服务器
一台主机,N多台子节点
一台主服务器控制可以控制多台子节点的服务,用户分布不同的服务器上,A节服务器有100个用户,B节点服务器存在100个用户。
分布式压力测试。
c/s :某信、某钉、聊天软件
Web的项目系统架构:B/S
前端—功能问题
接口—-性能、数据交互
后端(WEB服务器、数据库服务)
软件测试的定义:发现程序中的错误而执行程序的过程。
如何定义错误?
判断预期结果与实际结果是否相等,如果预期结果与实际结果相等则不是bug。
软件测试的目的是:找bug
什么是bug?就是一个缺陷
什么是预期的结果?需求规格说明严格规定要实现的功能。
实际结果:用户通过操作软件功能,输入相对应的数据进行测试的过程所得出的结果。
案例:给你一个登录功能
1.打开浏览,输入URL
2.点击登录功能
3.输入正确的用户与密码登录—-预期结果:用户登录成功—-测试用例–正向
用户名 密码
admin admin 123456666
kitty kitty 123456
zhang zhang123456
假设登录页面出现一个bug
用户输入正确的用户名与密码—登录失败了—实际结果
实际结果与预期的结果不相等。
异常的用例个数要大于正常的用例。
4.输入错误的用户与密码登录—-预期结果:用户登录失败—-测试用例–正向
通过测试人员设计的测试案例来覆盖需求的功能点。
bug是分布在不同层面的
基本前端的功能、界面bug—-功能性问题、兼容性、性能,NAN—读取后端接口的参数错误—JS的坑
基于接口层面的bug:接口不通过,性能问题—多用户、多线程、模拟真实的用户场景
基于代码—JUnit—基本JAVA的单元测试,对需求的功能进行测试,测试代码是否满足需求规格说明书要求。
开发人员编写单元测试案例来验证程序的正确性。
基于V模型分类:单元测试、集成测试、系统测试
前端-系统测试
接口-集成测试
代码-单元测试
需求文档的测试
操作系统、浏览器等相关的软件或者硬件跨平台的兼容性测试
单元测试工具一般用sonar
def add(a,b):
c=a+b
return c
软件测试与调试的区别:
软件测试仅发现问题,不修复问题–测试人员的职责
软件调试:不但要发现问题而且要解决问题(修复问题)–开发人员、产品经理、UI设计人员
前端写页面,写JS脚本
后端:写整个网站的模块内容,所有接口的开发,后端框架的设计、业务逻辑的处理。
测试–偏向于业务层–功能、性能、用户体验、处理客户反馈的信息、测试开发—-不仅要会测试还要会开发。
技术:业务方向功能测试、测试管理,技术方向 :自动化、性能测试、测试开发、安全性测试
软件测试的原则:
一、所有的测试都要基于需求去验证
二、设计的测试用例要包括有效(合理地输入)的用例与无效(异常输入)的用例
基于浏览器兼容性问题的核心原因:因为不同的浏览器内核不一样,对前面页的代码渲染解析不同,所以产生不同的展现效果
页面错乱,而格局混乱,控件不显示。
对于兼容要求比较高的产品有哪些?
电商网站:PC端、移动端-app–不同品牌的手机、型号、网络等等相关的测试需求要点的覆盖。
兼容性问题带来的后果:用户量的流失,会造成一定的经济损失。
测试需要用户参与:游戏测试–公测
疫情—回归测试—-发现了一个问题开发修改后,又带来了新的bug,循环没有结束。
做好软件测试需要大家具备一颗追求完美的心态。
一个系统中模块的业务越复杂,出现的bug就越多。
冒烟测试:对开发的系统主流程实施测试(订购流程)
冒烟测试不通过的bug属于严重级别为紧急-重要–
1.注册(用户名、密码、性别、年龄、企业、电话号码)
post提交接口
2.登录
3.查找商品
4.添加购物车功能—库存不足—采购,或者商品
5、提交订单
6.订单支付()
7、关注 订单状态流转
8、完成收货
9、好评度
退货或者退款
测试设计–测试用例的设计,基于需求功能–提取的测试点–将测试点转化为测试用例
开发过程是将需求转化成代码的过程
基于需求点—进行框架设计(概要设计-企业后端架构师)详细设计 —-编码–修复bug
开发与测试同步进行,开发人员在做好开发计划之后,开始实施产品研发工作。
测试人员做测试计划后,实施测试阶段的工作(用例设计占比60%,30%执行用例-寻找bug)
一对多
一个功能点至少两条用例,一条正向用例,一条反例。
订购
1、支付成功。
2. 提交订单失败(商品库存不足、没有加入购物车用户注册,或者用户未登录,)
什么是软件质量?
满足需求规格说明书中明确的显性或者隐性的需求。
什么是显性需求?
需求规格说明书中有明确规定要实现的功能,一般来说在需求文档中会详细标识(需求原型图、系统架构图–业务模块-子模块)
关注功能
关注成功(条件:用户未关注)
关注失败-已经关注(用户已经被关注了是不允许点击关注功能,关注功能需要置灰)
系统提示:用户已经被关注,不允许重复关注
关注成功后关注数量增加
取消关注数量减少,总粉丝数=关注数量+视频的数量
什么是隐性的需求?
需求规格说明书中没有明确规定的需求-隐含在需求内部并没有详细描述的需求叫做隐性需求
购物金额达到【100,200】商品打6折,隐性的需求用户打过一次折扣后不允许再次打折
软件测试六大特性:
功能性、可靠性、易用性、可维护性、时效性、可移植性
时效性一般是从性能的时间(以较短的时间产生更大的价值)、资源(cpu\内存、I/O、磁盘)来考虑问题
通过性能测试来节约资源,优化代码。
例如:多线程机制就是一种时效生,在短的时间内以最少的资源产生最大的价值—服务器的资源利用率。
可移植性:一种兼容性测试。
MYSQL-存储数据的仓库,不同的数据库语言的语法有区别。
软件生命周期的:从软件的产生到软件被淘汰的过程。
可移植性:需要根据不同的用户使用环境来满足业务需求的能力。
企业的测试环境分为三个:
QA环境-测试环境—80%的bug来源于QA环境
UAT环境-用户体验环境–20%的bug
PRE环境–灰度发布环境–系统的数据同步来源于生产环境,是一种上线前生产的一种 模拟环境
PRD环境-生产环境-走调拔–走主体流程线上模块测试—-只允许出现严重级别较低的bug.
保障产品质量。
易安装性:C/S架构,客户端的安装方式(软件的安装与删除)。
B/S架构与C/S架构的不同点
C/S架构的系统需要用户主动更新。
如果一个系统出现bug,软件提供服务方将bug已经修复,用户如果不更新软件,这个bug一直存在。
研发成本高于B/S架构
B/S–环境的部署
只要服务更新一个bug的功能代码,bug就能正常修复
课程总结与回顾:
一、软件测试的发展历程(了解)
二、软件测试的重要性(了解)
罗列了软件中常见的严重性bug分享。
三、软件测试的定义(重要)
软件测试的定义及目的。
软件测试的定义:发现程序中的错误而执行程序的过程
目的:寻找bug
四、软件测试的原则(重要)
所有问题都是依据需求而开展
五、软件测试的六特性与27大子特性(重要)
作业安排:
作业提交方式格式:软件测试概述及特性 姓名: 学号
如若转载,请注明出处:https://www.jiangsasa.com/5815.html