项目介绍

满足经典三层架构:前端 后端 数据库

前端:运行在用户端的浏览器和客户端

后端:运行在应用服务器上,作为前端的数据库的中间人,处理业务逻辑和数据(有能够发布的程序,ip与接口 如:ping 百度 可以通过返回的ip进行查询)

数据库:用于存储用户数据(也存在相应的ip与端口)

项目技术分析

1.前端代码:

技术栈:HTML+css+js等

部署位置:一般和后端代码一起,也可以单独

2.后端代码:

技术栈:Java+springboot或Python+Django也可以用PHP/C++写代码

部署位置:在应用服务器的中间件,用于实现项目功能

中间件:介于系统和应用之间的一类软件如:web服务器

常见服务器:

1.Apache默认端口 80 技术成熟,社区完善,文档丰富

2.Nginx:默认监听端口 80 负责负载均衡 (当数据大量访问服务器时,Nginx可以将数据进行平均分摊,防止服务器暴毙)

3.Tomcat:默认8080 主要用于Java开发

常见的项目构成组合

Java+Tomcat+mysql+linux

php+apache+mysql+Windows

项目学习

待测项目为一款PHP语言的网上商城 根据技术栈php+apache+mysql+Windows分析需要准备环境

1,一台Windows电脑

2.电脑上安装MySQL服务

3.在电脑上准备能够运行PHP代码的中间件Apache

4.在电脑上准备好项目包

准备工作

1.tpshop项目 2.Apache 3.mysql 4.部署文档

1.部署项目

1.把tpshop项目解压在phpstudy(可以官网下载)的WWW目录下

2.打开httpd.conf配置项目路径,添加DocunmentRoot (项目路径)

3.浏览器输入localhost回车,安装

如何快速熟悉项目

在测试项目时应该先熟悉项目,如何快速熟悉项目?

四个步骤: 1.业务特性:我们的项目是用来干什么的?

2.用户与角色:项目给谁做?普通商家还是企业

3.组织架构图:项目包含的模块(买家模块,卖家模块)

4.技术栈 项目是使用什么技术实现的

三个来源:

1.文档:已存在文档(需求/设计/测试文档/用户手册)

2.环境:现有环境(开发/测试/预生产/生产)

3.人:项目组同事(产品/开发/测试)

两个作用: 工作和找工作

举例熟悉TPshop项目

一个电商系统,实现了综合类产品的线上选购,下单,支付等业务

TPshop用户与角色

前台:

1.游客 2,注册会员

后台: 卖家,仓管员,超级管理员

模块划分原则:1.前台 a.按页面进行划分

b.按照业务流程进行整理(支付是一个功能 ,支付功能的使用需要 登录->选择商品->加入购物车->下订单->支付)

c.其他功能按照特性整理(如 限时抢购 可以整合为活动模块 轮播图整合至广告模块)

后台:模块->菜单->子菜单->标签 见到具体页面结束

组织架构图: 反映各系统和各模块关系
作用帮助理解项目,工具可以使用XMind等
项目技术栈: php+apache+mysql+Windows

总体系统项目介绍

​ TPshop是一个电商系统,实现了综合类产品的线上选购,下单支付等业
系统分为前后台 前台主要给买家购物使用,用户注册,登录,搜集商品,下单支付

后台:主要给管理员/卖家/仓管使用

管理员可以查看卖家和订单数据,审核商品上架,处理对卖家的投诉

卖家可以上下架商品,打广告,确认订单,通知发货

仓管可以对货架进行管理,管理对应库存,可以通知卖家补货等

项目技术栈:php+apache+mysql+Windows

项目与数据库

界面操作->会影响数据库中存储的数据

对数据库数据操作->会影响界面显示

测试人员使用数据库的场景

1.验证数据的准确性与完整性

如:注册账号,系统提示成功,需要进行数据库查看数据

用户下单,会生成订单数据,需要进数据库查看数据,比如订单生成时间,订单状态

2.辅助进行bug定位

如 用户注册后,性别展示有误

用户搜索商品,应该显示10条却只有7条

3.构造测试场景

如,测试店铺评分逻辑,需要构建一个1000条以上差评店铺

4.测试SQL脚本

版本升级,增加新的用户状态,需要SQL增加

测试流程

内容
1.需求评审
​ 2.制定测试计划与测试方案
​ 3.设计测试用例, 发起测试用例评审
​ 4.执行测试用例, 管理Bug
​ 5.编写测试报告
​ 6.其他 验收测试 线上测试
​ 收集线上反馈, 验证用户提出的问题

什么是软件需求

就是软件要实现的目标:可以大体上分为 功能需求(假设一个电梯要实现上下楼的功能), 非功能需求(在可以上下楼的基础上对速度进行要求) 会以文档形式呈现呈现形式:需求说明书又叫需求文档 prd文档

需求评审

需求评审:产品,开发,测试等对需求达成共识

怎样做需求评审
1.产品人员邮件将文档提前发给相关: ui, 开发, 测试
2.评审会议
3.修改与确认

测试工程师在需求评审中的主要职责是什么
1.确认自己对需求的理解是否清晰
2.对需求中不合理的地方提出修改意见
用户体验
对比市场上的同类产品
[可能]确认需求文档的完整和正确性, 能够指导后期的工作

测试计划

是指描述了要进行的测试活动的范围, 方法, 资源, 进度的文档
内容
1.明确的测试目标与测试范围
2.执行计划的角色和职责
3.任务的进度安排与资源分配
4.风险评估和应急计划
5.测试的各项标准

测试计划参考:一个项目的测试计划模板该怎么写？【附案例】_如何制定测试计划-CSDN博客

测试方案

是从测试的技术角度去分析, 重点在于测试策略和技术实现

内容
测试策略
1.功能性 对于需求文档中所描述的功能完成度/ 精准度
2.性能 是否满足需求文档中的性能要求 (安全 认证/ 授权/ 隐私)
3.兼容性 操作系统兼容, 硬件兼容, 向后兼容, 应用兼容
4.可靠性 错误处理, 可恢复性, 稳定性…
5.用户体验测试
测试方法

1.黑盒/白盒/灰盒, 动态/静态 (测试的分类)
2.测试环境的规划
3.测试工具的设计和选择

测试方案参考:一份完整测试方案模板_测试方案编写模板-CSDN博客

测试计划和测试方案的区别

测试计划是[管理型]文档, 测试方案[技术型]文档
​测试计划主要解决 [做什么][谁来做], 测试方案主要解决 [怎么做]
实际工作中的测试计划和测试方案
实际工作中越来越多的公司不在乎测试计划和方案文档,沟通交流比文档更重要
测试负责人以邮件的形式做测试计划和方案, 通知各组员甚至开个碰头会, 也算是完成沟通
​ 一般不区分计划和方案, 实际有一个文档就够了资源分配人力,测试资源,时间资源

打算从事软件测试的小伙伴注意啦!!领取软件测试零基础全套入门学习资料，扫码加微领取
添加wx好友时备注: 111 !!!