在线测名字免费打分测试(名字测试打分 免费 在线)

分布式服务器

一台主机,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大子特性(重要)

作业安排:

作业提交方式格式:软件测试概述及特性 姓名: 学号

本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 610798281@qq.com 举报,一经查实,本站将立刻删除。
如若转载,请注明出处:https://www.jiangsasa.com/5815.html