第五章 tpshop项目实战（阶段三）

软件测试基础学习--第五章 tpshop项目实战（阶段三），分为 1.tpshop环境搭建、快速熟悉项目、测试流程、熟悉数据库、轮播图、购物车，适合小白了解观看。

第五章 tpshop项目实战

• 1.tpshop环境搭建
  • 1.1 基础环境介绍
  • 1.2 tpshop环境搭建说明
  • 1.3 tpshop 设置本地域名扩展
    • 
• 2.快速熟悉项目
  • 2.1 熟悉项目步骤
    • 业务特色
    • 用户与角色
    • 组织结构图
    • 技术栈
  • 2.2 熟悉信息来源
    • 寻在文档 ： 、如需求说明书、用户使用手册、测试用例等
    • 现有环境 ：如 开发环境、测试环境
    • 人 ：如开发人员、产品经理、组长
  • 2.3 熟悉tpshop项目的业务特性及用户与角色
    • 业务特性： tpshop是一个开源的电商系统
    • 角色与用户：
      • 前台
        • 游客 、 、注册会员
      • 后台：
        • 超级管理员、仓管员、客服
  • 2.4 熟悉tpshop项目的组织架构图绘制后台
    • 反映各子系统之间和各元素之间的组织关系，各个模块以及各个模块下面的子模块，子模块下面的子模块之间的组织关系
    • 作用 ： 整体性认识被测试的项目
    • 绘制 ：
      • 后台
        • 系统 > 子系统 >模块 > 子模块
        • 见到具体的页面截止
      • 前台
        • tpshop购买流程
          • 注册登录 》 商品页面 》 购物车 》支付 》 订单管理
  • 2.5 熟悉tpshop项目的组织架构图绘制后台点评
  • 2.6 熟悉tpshop项目的组织架构图绘制前台规则说明
    • 前台规则：
      • 一个独立的页面就是一个模块
      • 具有共同点的模块可以进行归纳整理合并
  • 2.7熟悉tpshop项目的组织架构图绘制前台梳理
  • 2.8 熟悉tpshop项目技术栈
    • 数据库： MySQL
    • web 服务器： Apache
    • 开发语言 ：PHP
    • 操作系统 ：window（Linux）
• 3.测试流程
  • 需求分析与评审
    • 怎么做需求评审？
      • 1.需求评审会议
      • 2.参与人员
        • 产品经理/项目经理
        • 开发/UI
        • 测试
        • DBA
        • .....
    • 测试工程师在需求评审中的主要职责是什么？
      • 确认人自己理解需求、无异议
      • 确认需求无明显错误、无疑义
      • 确认需求无明显的错误，能支撑后续的用例设计等
      • 提出一些改进建议
    • 评审案例1
  • 编写测试计划与测试方案
    • 测试计划
      • 概念; 是为了描述要进行的测试活动的范围、方法、资源和进度的文档
      • 
    • 测试方案
      • 概念 ： 从测试的技术角度去分析需求，在方向上明确怎么测，分析结果重点与技术实现
      • 核心内容
        • 方法
        • 环境
        • 工具
  • 设计测试用例与评审
    • 基本测试策略
      • 冒烟测试 单功能测试 集成测试与回归 系统测试与回归 验收测试与回归
    • 测试用例核心要素
      • ID 模块 优先级 标题 测试数据 前置条件 测试步骤 预期结果
  • 测试用例与缺陷报告重点
    • 缺陷模板核心要素
      • ID 标题 优先级 严重程度 预置条件 测试数据 复现步骤 预期结果 实际结果 缺陷类型 缺陷状态
  • 编写测试报告
• 4.熟悉数据库
• 5.轮播图
  •  工具 ：禅道
• 6.购物车

第五章 tpshop项目实战

• 7.会员列表
• 8.抢购
• 9.非功能
  • 1.兼容性测试
    • 主要浏览器
  • 2.界面测试
    • 参照UI设计图
  • 3.易用性测试
    • 关注点：用户群体、计算机水平、项目复杂性、tab/enter等
  • 4.性能测试
    • （并发测试、压力测试、负载测试）
  • 5.安全性
    • 测试业务关注点（业务层面）
    • 输入（敏感信息遮挡测试）、传输（数据要加密，有复杂度）、输出（敏感信息要加密）、
• 10.用例评审总结
  • 测试数据
    • 注意测试数据的时效性（测试准备)
      • 如注册时的手机号第一次注册时是未注册的，第二次注册时就变为已注册，在特定的数据场合下，我们可以省略这些测试数据
    • 标题与预期结果要明确
      • 注意：如果需求中没有说明类似的错误提示提示信息，我们应该借助于其他同类或消息来设置用例的预期结果
    • 测试标题
      • 直接点明测试的目的
      • 简明扼要，不要太冗长
        • 比如异常类测试时，重点关注异常的条件即可,（其他正确参数可以放一边，实际工作中约定的规则下可以不写其他正常的参数
        • 如果是正常类测试时，可以依据有效等价类别来细分设计测试用例
      • 标题一般来说不重复
    • 优先级
      • 
    • 测试用例设计时依据需求说明书还是系统？
      • 流程规范的公司，一定是基于需求说明书（或原型图）来设计测试用例
      • 进入项目节点的时间点来看
        • 初期介入，依据需求说明书
        • 中后期介入，依据需求说明书
          • 有可能在实际测试过程中，没有需求说明书，可以参考当前的系统
        • 项目维护介入阶段，依据需求说明书
          • 有可能在实际测试过程中，没有需求说明书，可以参考当前的系统，用户手册、bug清单等
• 11.状态迁移
  • 概念
    • 基于一种产品规格分析，对系统的每个状态及与状态相关的功能进行测试，通过不同的状态验证程序的逻辑流程
      • 首先要找出被测试的对象的所有状态，然后在分析各个状态之间的装换，据此建立测试用例的一种设计方法
      • 注意：状态迁移不保证单个功能点的正确性，仅保证状态间的装换是否与需求描述一致
  • 使用场景
    • 复杂的业务场景设计用例时
  • 步骤
    • 1.明确状态节点：分析被测试的对象的需求规格说明，明确被测对象的状态节点数量
    • 2.绘制状态迁移图：利用圆圈表示状态节点，有箭头表示状态间的迁移关系
    • 3.绘制状态迁移树：根据状态迁移图的节点和箭头绘制状态迁移树（首先明确起始节点及终止节点
    • 4.找出状态之间的转换路径
• 12.流程图
  • 代表
    • 椭圆： 开始/结束
    • 箭头： 路径，流程的走向
    • 平行四边形：数据的输入与输出
    • 长方形：处理/步骤/过程
    • 菱形：判定/判断
  • 原则
    • 流程正确、不遗漏路径
    • 先判定、在判定结果
    • 主流程保持在流程图的中间位置方便阅读
• 13.数据库
  • 应用场景
    • 艳增数据的准确性与完整性
    • 借助数据库进行缺陷定位
    • 救助数据库构造测试场景（需要特定的测试数据）
    • 借助数据库数据备份更新
• 14.抓包
  • 概念
    • 就是将网络传输发送与接收的数据包进行截获、重发、编辑、转存等操作、也用来检查网络安全。
  • 工具
    • fiddler（PC)
      • 请求内容：
      • get：
        • 不安全、只能查询，不能传递敏感信息，暴露在URL上，请求参数会保留，请求参数有长度限制，只接受ASCII字符
      • post：
        • 支持多种编码，可携带敏感信息，请求参数不会保留，没有长度限制（根据浏览器导致），没有字符限制
    • charles(手机）
    • f12开发工具
  • 设置过滤
    • 
  • 修改请求
    • 
      • 拦截符：
  • 响应修改
    • 
  • 自动响应
    • 
  • HTML与HTTP协议
    • URL: 统一资源定位符
      • 
        • 格式： 协议 ---IP或域名----端口号（http：80 ，HTTPS：443 ，ssh :22） ------资源路径----参数：（用？与URL的主体分开； 格式：参数名=参数值，有多个参数用&符号拼接即可
    • http：超文本传输协议
      • http响应内容 ：
    • HTML：超文本标记语言