一、TPshop
1.怎样熟系一个项目
4个步骤
- 业务性
- 项目用来做什么（一句话）
- 用户与角色
项目给谁用 - 组织架构图
项目包含哪些模块
- 扩展2和3应该结合使用
- 例如
- 买家
- 卖家
- 项目的技术栈
- Linux
- Tomcat
- MySQL
- Java
3个来源
- 文档
已经存在的文档- 需求说明书、原型
- 概要设计、详细设计、数据库设计
- 测试用例、缺陷报告
- 用户手册
- 环境
已经存在的环境- 开发环境
- 测试环境
- 线上环境/生产环境
- 人
项目组的同事- 产品经理/项目经理
- 开发工程师
- 测试总监、测试架构师、测试主管、各级别测试工程师
2个作用
- 学习一个项目
- 介绍一个项目
2.业务特性
是一个电商系统，通过互联网来实现商品的销售与业务流程的电子化
3. 用户与角色
- 前台
- 游客
- 注册会员
- 后台
- 超级管理员
- 仓管员
- 客服人员
4. 组织架构图
- 概念
组织架构图是能反映项目，各系统和各模块组织关系的图 - 作用
帮助整体理解项目 - 工具
思维导图 - 绘制
- 前台
- 原则
一个独立的页面就是一个模块
对具有共同特性的页面进行合并整理（按照业务流程） - 内容
注册
登录
商品浏览
购物车管理
订单管理
支付管理
- 原则
- 后台
- 原则
- 系统–>子系统 -->模块–>子模块
- 推荐：
模块 -->菜单 -->子菜单 -->标签 - 见到具体页面结束
- 内容
- 系统
设置
会员
广告
。。。 - 商城
- 插件
5.技术栈
组成
操作系统
6.项目总体介绍
- 是一个电商系统，实现了综合类的线上选购，下单支付等业务
- 系统分为前台和后台
- 前台只要是给买家购物使用，用户可以注册，登录，搜索商品，下单，支付等
- 后台主要给管理员/卖家/仓管使用
- 管理员可以查看卖家和订单数据，审核商品上架，处理对卖家的投诉等
- 卖家可以上下架商品，打广告，确定订单，通知发货等
- 仓库可以对货仓进行管理，管理对应的库存，可以通知卖家及时补货等
- 它的技术栈是PHP+Apache +MySQL+Windows
二、项目与数据库
1. 项目与数据库的关系
项目中的数据是存储在数据库中的
- 界面操作 -->会影响数据库中存储的数据
- 对数据库中数据的操作–>会影响界面显示
2.测试人员使用数据库的场景
- 验证数据的准确性与完整性
- 如，注册账号，系统提示成功，需要进数据库查看数据
- 用户下单，会生成订单数据，需要进数据库查看数据，比如订单生成时间，成本订单状态等
- 辅助进行bug定位
- 如，用户注册后，性别显示有误
- 如，用户搜索产品，应该实现10条，结果只有8条
- 构造测试场景
- 如，测试店铺评分逻辑，需要构造一个1000条以上差评的店铺
- 如，测试商品分页展示，需要10000个商品信息
- 测试SQL脚本
- 如，版本升级，增加为用户提供运费险功能，但原用户没有用户信用字段，需执行SQL增加
三、测试实战
1.测试流程
- 需求评审
- 制定测试计划于测试方案
- 设计测试用例，发起测试用例评审
- 执行测试用例，管理bug
- 编写测试报告
- 其他
- 验收测试
- 线上测试
- 收集线上反馈，验证用户提出的问题
2.需求分析和评审
做需求评审的原因是：
产品，开发，测试达成共识
怎么做需求评审？
- 产品人员邮件将文档提前发给相关：UI，开发，测试
- 评审会议
- 修改与确定
测试工程师在需求评审中的主要职责是什么？
- 确定自己对需求的理解是否清晰
- 对需求中不合理的地方提出修改意见
- 用户体验
- 对比市场上的同类产品
- 确认需求文档的完整和正确性，能够指导后期的工作
3.编写测试计划和测试方案
测试计划
- 概念
是藐视了要进行的测试活动的范围，方法，资源，进度和文档 - 内容
- 明确的测试目标与测试范围
- 执行计划的角色和职责
- 任务的进度安排与资源分配
- 风险评估和应急计划
- 测试的各项标准
测试方案
- 概念
从测试的技术角度去分析，重点在于测试策略和技术实现 - 内容
测试策略
- 功能性–对与需求文档中所描述的功能完成度/精准度
- 性能–是否满足需求文档中的性能需求
- 安全–认证/授权/隐私
- 兼容性–操作系统兼容、硬件兼容、向后兼容、应用兼容
- 可靠性–错误处理、可恢复性、稳定性
- 用户体验测
测试方法 - 黑盒
- 白盒
- 灰盒
- 动态
- 静态
测试环境的规划
测试用具的设计和选择
小结
测试计划和测试方案的区别？
测试计划是管理型文档，测试方案是技术型文档
测试计划主要解决做什么，谁来做，测试方案主要解决怎么做
实际工作中的测试计划和测试方案
实际工作中越来越多的公司不在乎测试计划和测试方案
沟通交流比文档更重要
一般不区分计划和方案，实际有一个文档就可以了
资源分配很重要
- 人力
- 测试资源
- 时间资源
分享
项目实操
注册功能
总体介绍
设计测试用例
-
步骤
- 需求分析
- 输入分析：
长度、类型、组成规则
是否为空、是否重复 - 交互分析
所有数据都正确
有错误，给出提示 - 输出分析
前台
后台
数据库
- 构造数据库（等价类+边界值）
- 编写用例
构造数据中，一个数据对应的一条测试用例，用例的预期结果要参照需求分析中的输出分析
测试用例评审
- 内部评审
- 测试组内部
测试经理、测试主管、高级测试工程师
- 测试组内部
- 外部评审
- 测试组外部
测试、产品、开发、客户
- 测试组外部
- 最佳推荐评审
- 对应模块的开发人员是必须要参加的
- 其他人可选，如开发老大，测试老大，产品经理
执行用例与缺陷跟踪
- 执行测试
- 逐条执行
- 按照用例的详细内容执行（预置条件，测试数据，执行步骤，预期结果）
- 注意：不能只看测试用例标题执行
- 执行用例的结果：pass（成功），fail（失败），block（阻塞），N/A（不用执行）
- 执行失败的用例要及时填写缺陷报告（在禅道或类似的缺项管理工具上记录发现的bug）
- 缺陷跟踪
- 在哪提交？ 禅道或jira
- 怎么写？ 按照表单填写
- 提交给谁？ 对应的开发人员
- 如何跟踪？ 缺陷的状态变化会给相关人员发邮件
- 何时结束？ 验证通过，不是bug
写测试报告
一般不在这个阶段写测试报告，要全部模块都测完成，才同意写测试报告
轮播图功能
- 总体介绍
- 设计测试用例
步骤
- 需求分析
- 拆分测试点（最小的需求点或者规则）
- 根据测试点，分析设计测试用例
- 五星推荐 根据需求找到测试点使用测试用例设计方法，生成测试用例
- 编写测试用例，一个测试点对应一条或多条测试用例
- 执行用例与缺陷跟踪
登录功能
参照注册测试用例
购物车功能
- 设计测试用例
步骤
- 需求分析
- 拆分测试点
- 根据测试点，分析用例设计方法（等价类，边界值，判定表，场景法，流程图，没方法）
- 编写用例
一个测试点至少对应一条测试用例 - 测试用例评审
- 执行用例与缺陷跟踪
- 写报告
测试报告
- 什么时候写？
整个版本测试完成 - 什么是测试报告？
测试活动的总结性文档，标志测试活动的结束 - 测试报告都包含什么内容
测试工作的经过和结果
风险评估 - 重点列出不能进行测试的功能
缺陷的汇总和分析
测试工作的总结和改进 - 在敏捷流程中测试报告的表现
是一个文档，是一封邮件
内容：
- 测试负责人
- 什么时间测试完成了什么版本，测试结果是否测试通过
- 测试汇总，风险评估，工作总结
测试用例设计
复习
- 场景法
- 应用场景
- 核心步骤
- 流程图
- 应用场景
- 常用符号
测试用例设计思路
基本原则
- 什么时候用等价类和边界值组合？
具有典型输入的功能，例如注册、登录 - 拆分需求形成测试点：
需求–>功能点–>测试用例设计方法–>测试用例（一个测试点对应至少一条用例）
例如：轮播图、购物车、大篇幅文字描述 - 流程图与场景法
- 前台下单
- 后台发货
- 需求文档存在业务流程
总结
- 需求–>相关业务–>各个角度–>精简，补充
- 覆盖需求
- 分析需求
- 抽取测试点
- 相关业务
- 提到的业务流程
- 影响到的业务流程
- 各个角度
- 正向
- 逆向
- 主流程
- 分支流程
- 异常操作
- 补充
- 需求文档
- 测试策略
- 业务知识
- 测试经验
面试题
支付功能如何测试？
支付金额
支付操作
支付接口可以调用成功
异常处理
其他–反洗钱–
非功能测试
1.兼容性测试
- 概念
指被测软件在不同的软硬件环境下是否能正常使用 - 测试关注点
- 操作系统
- 浏览器
- 屏幕分辨率
- 网络要求
2.性能测试
- 关注点
访问项目时所消耗的时间 - 测试依据（3-5-8S）
- 小结
后续还会介绍
3.易用性测试
- 测试关注点
点击次数：三次以内达到用户目的
回车事件的处理
基于特定用户群体需求考虑(如，老人，小孩)
4.可维护性测试
测试关注点
- 软件升级过程 ：停服时间，停服频率
- 数据库升级脚本
- 项目代码的可维护性
- 自动化测试代码
5.安全性测试
测试关注点
- 输入数据的安全性
- 敏感信息的遮挡处理
- 输入框中敏感信息做不能复制处理
- 传输过程的安全性
- 请求方法决定敏感信息不能暴露在地址栏中（使用post请求）
- 数据传输过程中需要加密
- 输出数据的安全性
- 数据库存储敏感信息加密
面试题
登录功能怎么测试
- 功能性
登录成功
登录失败 - 非功能性
- 兼容性
- 性能
- 安全
- 易用性
- 可维护性
6405
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
