分布式服务器

一台主机，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大子特性（重要）

作业安排：

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

在线起名，免费送 8个好名字

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

在线测名字免费打分测试（名字测试打分 免费 在线）