day 1
学习目标:
- 熟练搭建本地测试环境
- 掌握熟悉项目的步骤和内容
- 掌握项目基本的测试流程
基础环境介绍:
项目环境的组成部分:php
- 操做系统
- windows
- Linux
- Centos 6.x,7.x
- Redhat 6.x,7.x
- Ubuntu 14.z,16.x,18.x
- Mac
- web 服务器
- apache: 稳定,文档齐全 默认监听端口:80
- nginx: 负载均衡器 默认监听端口:80
- tomcat:默认监听端口"8080 ->JAVA
- 数据库
- Mysql
- Oracle
- Sql Server
- DB2
- 项目
- LNMP: LINUX+Nginx+Mysql+PHP
- WAMP: Windows+Nginx+Mysql+PHP
扩展: Apache 与 Nginx 的区别:前端
- apache 与 nginx 都可以做为web服务器使用
- apche 系统稳定性更强文档丰富
- nginx 消耗更少的系统资源(如CPU,内存等)
- nginx 更加典型的应用场景是做为负载均衡器使用
搭建测试环境
准备工做mysql
安装集成环境nginx
- apache 监听端口: 80
- mysql 监听端口: 3306
部署项目web
- 将TPshop 项目压缩包解压后文件夹里的所有内容放入phpstudy安装路径\www中
常见故障面试
熟悉项目的步骤:
- 了解项目的业务特性:项目用来作什么的?
- 了解项目的角色与用户:项目是给谁用的?
- 了解项目的组织架构图:项目包括哪些功能模块?
- 了解项目的技术栈:项目是使用哪些技术实现的?
熟悉项目的信息来源
- 文档
- 需求文档
- 设计文档,数据库表设计文档
- 测试用例
- 用户手册等
- 环境
- 开发环境->开发
- 测试环境->测试环境
- 线上/生产环境->客户,运维
- 人
- 项目中已经存在的文档: 需求说明书,用户使用手册测试用例等
- 试用项目的现有环境:开发环境,测试环境,线上环境
- 询问项目中的其余成员:测试组员\组长,开发人员,产品经理等
熟悉Tshop步骤:
- 业务特性:Tshop 是一个开源的电商系统.
- 用户与角色
- 组织架构图
- 概念:各系统各元素的组织关系,反映的是各个模块以及各个模块的组织关系.
- 做用
- 工具:xmind
- 技术栈
测试流程(重点)
- 需求分析与评审
- 编写测试计划与测试方案
- 设计测试用例与评审(重点)
- 执行测试用例与缺陷跟踪(重点)
- 编写测试报告
SVN服务器设置扩展
- 添加用户
- 添加用户组
- 建立仓库及获取仓库地址
- 服务启动,中止,重启等基本操做
虚拟机(扩展)
装虚拟机的容器软件:数据库
快照:记录如今的状况各类参数配置,方便下次再次使用apache
- 网络类型
- 桥接模式
- NAT模式
- 经过主机IP去链接外部Inter网络(单向,外部Inter网是找不到此虚拟机)
- Host-Only 仅主机模式
- 远程链接设置
- 虚拟机设置容许远程链接
- 主机输入mstsc命令启动本地远程链接
- 在虚拟机中启动cmd窗口,而且输入ipconfig
- 输入虚拟机的帐号和密码
day 2
学习目标
- 需求评审(了解)
- 测试计划与测试方案(了解)
- 注册功能测试用例设计,执行与缺陷跟踪(重点)
- 轮播图功能测试用例设计,执行与缺陷跟踪(重点)
- 购物车功能测试用例设计,执行与缺陷跟踪(重点)
测试流程
- 需求分析与评审
- 编写测试计划与方案
- 设计测试用例与评审
- 执行测试用例与缺陷跟踪
- 编写测试报告
软件需求
为用户解决某一问题或达到某一目标所需的软件功能
为何须要需求评审
如何作需求评审
- 需求评审会
- 参会人员
- 项目经理/产品经理
- 开发工程师,架构师
- 测试工程师
- 运维工程师(DEVOPS)
- UI/UE
- DBA 数据库工程师
需求分析->概要设计->详细设计->编码->集成->实施->交付
测试V:
单元测试设计->集成测试设计->系统测试设计->验收测试设计
测试工程师在需求评审中的主要职责是什么?
- 确认本身对需求要有清晰的理解,没有疑惑
- 确认需求文档的完整与正确性,可以知道后期的工做
- 对需求中不合理的地方提出本身的修改意见
在现实工做中很是多的需求逻辑问题都是由测试工程师发现,比提出修正的.
测试方案
概念:从测试的技术角度去分析需求,在方向上明确要怎么测,分析结果重点在于测试策略于与技术实现
测试方案都包含什么内容
- 测试策略/测试方法
- 测试环境的规划
- 测试工具的设计和选择
TpShop 测试方案 或其余测试方案获取
测试计划与测试方案的区别
- 测试计划是【管理型】文档,注重人员、资源,时间的调配;测试方案是【技术型】文档,注重环境,工具,方法。
- 测试计划主要解决【作什么】【谁来作】,测试方案主要解决【怎么作】
- 主要内容存在差别:
- 测试计划主要内容以下
- 明确的测试目标与测试范围
- 执行计划的角色与职责
- 任务的进度安排与资源分配
- 风险估计和应急计划
- 测试的各项标准
- 测试方案主要内容以下:
- 测试策略/测试方法
- 测试环境的规划
- 测试工具的设计和选择
注册功能(重点)
设计测试用例
设计测试用例方法
测试用例设计步骤
第一步:需求分析
黑盒测试方法:
第二部:划分等价类
执行测试用例与缺陷跟踪
测试执行
执行步骤:
- 查看用例标题-肯定目标
- 检查预置前置条件
- 按照步骤执行测试用例
- 实际结果与预期结果进行比对
缺陷跟踪
- 提交缺陷报告
- ID
- 标题
- 模块
- 优先级
- 严重程度
- 复现步骤
- 预期结果
- 实际结果
- 缺陷状态
- 缺陷类型
- 跟踪缺陷
轮播图功能(重点)
设计测试用例
设计测试用例方法
- 需求->测试点->测试用例
- 一个测试点就是一条测试用例
测试用例设计步骤
- 第一步:需求分析
- 第二部:划分等价类
- 第三部:设计测试用例
业务流程测试用例设计(重点)
流程图基础知识(复习)
概念:
流程图:使用形状和连线来表示业务流程执行顺序的一种图示
流程图法:它时用流程图的方式表示用户的使用场景,经过覆盖流程的路径来设计测试用例的一种方法
基本流:用户的正确操做流程
备选流:用户的错误操做流程
做用:
帮助测试总体理解系统的业务,各个模块、子模块在业务上的关联性
使用阶段:
集成测试、系统测试、验收测试、冒烟测试
经常使用符号:
- 开始或结束:椭圆
- 方向或路径:箭头
- 处理或操做:长方形
- 判断:菱形
- 输入或输出:平行四边形
设计测试用例步骤:
- 需求分析
- 绘制流程图(分析流程节点、节点的前后顺序)
- 设计测试用例(一条流程路径就是一条测试用例,注意覆盖流程图中全部的路径)
绘制流程图
绘制步骤:
- 第一步:肯定业务中的操做
- 第二步:分析执行的顺序
- 第三步:按照业务方向进行连线
绘制工具:
- Microsoft Visio
- 2003?管理员运行
下单流程
Day04
学习目标
- 了解测试报告基本内容
- 了解非功能测试基础知识
- 掌握项目与数据库的关系
- 了解项目中数据库的4种典型应用场景
- 掌握网络基础知识(URL、HTML、HTTP、HTTPS)
- Fiddler 经常使用操做,了解Fiddler 典型应用场景
编写测试报告(了解)
概念
测试活动的总结性文档,表只测试活动的结束
主要内容
- 测试概要
- 缺陷分析与总结
- 给出测试结论与建议
非功能性测试
虽未说起,但有不少默认须要实现的具有的
- 兼容性测试
- 效率性(性能)
- 安全性
- 易用性
- 可维护性
兼容性测试
概念
在不一样的软件环境和硬件环境上都具有很好的可移植性(可以被用户正常使用)
测试关注点
浏览器
注意:实际以客户需求(客户现场的真实使用环境)为准,建议在开发的早期阶段(需求分析)就明确相关的需求
分辨率
网络环境
率性
关注点
访问项目的时间
测试依据(2-5-10s 法)
- 2s:时间性能很是好
- 2s-5s:用户还能暂时可以忍受
- 10s:用户直接中止使用产品
易用性
测试关注点
- 用户点击次数:推荐3次达到用户目的
- Enter 回车事件处理
- 基于特定用户群体需求考虑(老人年、儿童等)
可维护性
- 软件升级过程:停服时间,停服频率
- 数据库升级脚本
- 项目代码的可维护性
安全性
测试关注点
输入数据的安全性
- 敏感信息的遮挡处理
- 输入框种敏感信息(密码)作不能赋值处理
处理数据的安全性(数据传输过程当中的安全性)
- 请求方法决定敏感信息不能暴露在地址栏种(推荐用post 请求方式)
- 数据传输中须要加密
输出数据的安全性
sql 注入(了解)
概念:
主要时利用程序中特殊的 sql 语句漏洞进行非法操做
'or 1=1 #
'or 1=1 --
渗透测试(了解)
登录功能(面试扩展)
功能性测试(功能性需求)
- 正确输入用户名、密码登录成功
- 错误用户名,正确密码,登录失败
- 正确用户名,错误密码,登录失败
- 不输入用户名,登录失败
- 不输入密码,登录失败
- ...
非功能性测试(非功能性需求)
- 兼容性测试
- 操做系统
- 浏览器
- 客户的需求
- 分辨率
- 网络
- 效率(性能)
- 大量用户访问系统响应时间测试
- 安全性
- 密码要遮挡
- 密码不能被复制
- 数据库种存储时密码须要加密
- 地址栏中不显示密码(post)
- 传输过程当中数据要加密
- sql 注入
- 易用性
- 回车
- 可维护性
- 元素定位难题(自动化测试)
项目与数据库关系(重点)

- 项目中的数据时存储在数据库终得
- 对数据库修改会影响项目页面显示
项目测试使用数据库场景(掌握)
数据库肯定数据正确
- 执行用例过程当中,有时须要到数据库验证数据的准确性与完整性
借助数据库进行缺陷定位
- 进行BUG定位时,有时须要到数据库查看数据的详细信息
借助数据库构造数据场景(须要特定测试数据)
- 构造某种测试场景时,能够在数据库里直接修改数据,要比使用界面更有效率
借助数据库数据备份更新
- 软件升级过程当中,有时会涉及到历史数据的处理,这种状况须要执行升级SQL,并验证结果
- 数据库表中增长字段:alter TABle xxx add COLUMN xxxx int(3) DEFAULT 100;
网络基础知识
URL
- 名称:赞成资源定位符
- 格式:协议://主机地址[端口号]/资源路径
- 默认监听在80端口,默认端口号能够省略
- 示例:http://localhost/
- 客户端:用户端,好比B/S架构中的浏览器,C/S架构中的手机
- 服务器:对外提供web服务或app服务的服务器,解决资源与数据
- 请求:客户端向服务器索取数据的一种行为
- 响应:服务器对客户端的请求作出的反应,通常指返回数据给客户端
HTML
- 名称:超文本标记语言
- 超文本:声音、视频、超连接等
HTTP
请求(request)
请求内容
- 请求行:请求方式,HTTP协议版本吧
- 请求头:浏览器及操做系统信息,支持的语言
- 请求体:传输的参数
请求方式(GET 和 POST)
GET
参数信息会直接暴露在URL 中,典型应用场景就是访问
POST
不会直接将参数信息暴露在url中,它相对比较安全,典型应用场景:登录、注册等向服务器提交数据的状况
面试题:GET 和 POST区别
- GET数将请求参数包含在URL当中,POST经过request body 传递参数
- GET 比POST不安全,不能用来传递敏感信息
- GET 在浏览器退回无害,POST 会再次提交
- GET直接进行URL 编码,POST 支持多种编码方式
- GET 请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留
- GET请求在URL 中传送的参数时有长度限制的,而POST 没有
- 参数类型看:GET 只接受ASCII 字符,而POST 没有限制
响应(response)
行
- 协议版本
- 状态吗
- 200:成功
- 3xx:数据路径发生改变
- 4xx,客户端存在问题
- 5xx:服务器端问题
头
体
FIddler 的典型应用场景
- 辅助定位bug
- 构建模拟测试场景
- APP 弱网模拟测试
- 前端性能分析及优化
- 其余用户。域名重定向,API 接口测试