Web手工测试基础案例

最新推荐文章于 2024-05-22 22:19:13 发布

Anthony_231

最新推荐文章于 2024-05-22 22:19:13 发布

阅读量939

点赞数 29

分类专栏：软件测试文章标签：功能测试 python 可用性测试测试工具集成测试 web

本文链接：https://blog.csdn.net/weixin_45693551/article/details/138757982

版权

软件测试专栏收录该内容

6 篇文章 0 订阅

订阅专栏

1 项目介绍以及环境
- 1.1 经典三层架构
- 1.2 常见的web服务器以及项目代码
2 环境搭建
3 TPshop项目熟悉项目
4 熟悉TPshop项目的业务特性
5 用户与角色
6 组织架构图
7 TPshop项目技术栈
8 数据库知识复习
9 总体介绍
10 注册功能
- 10.1 需求
- 10.2 需求评审
- 10.3 编写测试计划
- 10.4 编写测试计划与测试方案
- 10.5 设计测试用例
- 10.6 测试用例评审
- 10.7 执行用例与缺陷跟踪
- 10. 写测试报告
11 轮播图功能
- 11.1 设计测试用例
12 购物车功能
- 12.1 设计测试用例
13 测试报告
- 13.1 写测试报告的时间段
- 13.2 测试报告的概念
- 13.3 测试报告的具体内容
- 13.4 在敏捷流程中测试报告的表现
14 测试报告模板
- 14.1 简介
- 14.2 测试概要
- 14.4 结论&问题&建议
15 基于业务设计测试用例
- 15.1 前台下单流程设计测试用例
- 15.2 后台发货流程设计测试用例
16 测试用例的设计思路
- 16.1 基本原则
17 非功能测试
- 17.1 兼容性测试
- 17.2 性能测试
- 17.3 易用性测试
- 17.4 可维护性测试
- 17.5 安全性测试
- 17.6 登录功能的测试点
- 18 项目和数据库
面试题
- 1 支付功能测试的思路

1 项目介绍以及环境

1.1 经典三层架构

前端
- 浏览器
- 客户端
应用服务器
- 本质上是一台电脑
- 能够发布应用的程序
  - ip
  - 端口
  - 项目代码
数据服务器
- 本质上是一台电脑
- 数据库服务
  - ip
  - 端口

1.2 常见的web服务器以及项目代码

常见的
- 项目代码
  - Java：.war 或者 .jar 文件包
  - C/C++
  - Python
  - PHP：.zip
- web服务器
  - Apache
    - 默认监听端口：80
    - 特点：技术成熟, 社区完善, 文档丰富
    - 主要用来部署 PHP 程序
  - Nginx
    - 默认监听端口：80
    - 特点: 负载均衡
  - Tomcat
    - 默认监听端口：8080
    - 主要用来部署 Java 程序
- 数据服务器
  - mysql / oracle / DB2 / SQLServer
- 操作系统
  - windows / linux (CentOS/ Redhat/ Ubentu) / mac
组合
- 工作中最常见的
  - linux + tomcat + mysql + java
  - linux + nginx + mysql + PHP
  - windows + apache + mysql + PHP
  - linux + apache + mysql + PHP

2 环境搭建

步骤

准备工作
- phpStudy集成环境
- Apache
- mysql
- tpshop项目包
安装集成环境 phpStudy
部署项目
1. 把tpshop项目解压到WWW目录
2. 配置 httpd-conf
3. 项目路径
4. 浏览器输入 localhost 回车, 进行安装
运行项目：启动phpStudy中的 Apache 和 Mysql 服务
访问项目
- 访问前台页面：localhost
- 访问后台页面

3 TPshop项目熟悉项目

原则
4个步骤/3个来源/2个作用
4个步骤
1. 业务特性：项目是用来做什么的
2. 用户与角色：项目给谁用的
3. 组织架构图：项目包含哪些模块
- 扩展2和3应该结合使用
  - 例如结合2和3介绍一个商城
    - 买家
      - 注册
      - 登录
      - 购物车管理
      - 订单模块
      - 支付模块
      - …
    - 卖家
      - 订单管理
      - 物流管理
      - 仓库管理
      - …
        4.技术栈
  - 项目是使用哪些技术实现
    例如, linux + tomcat + mysql + java
3个来源
1. 文档
  - 已存在的文档
    - 需求说明书, 原型
    - 概要设计详细设计数据库设计
    - 测试用例, 缺陷报告
    - 用户手册
2. 环境
  - 已存在的环境
    - 开发环境
    - 测试环境
    - 线上环境/生产环境
3. 人
  项目组的同事
  产品经理/项目经理
  开发工程师
  测试总监, 测试架构师, 测试主管, 测试leader, 高/中级测试工程师
2个作用
1. 学习一个项目：工作
2. 介绍一个项目：面试/工作

4 熟悉TPshop项目的业务特性

是一个开源的电商系统, 通过互联网来实现商品的销售与业务流程的电子化

5 用户与角色

前台
- 游客
- 注册会员
后台
- 超级管理员
- 仓管员
- 客服人员

6 组织架构图

概念
组织架构图是能反映项目各系统和各模块组织关系的图
作用
帮助整体理解项目
工具
思维导图工具, 如 xmind 等
绘制

前台
- 原则
  1. 一个独立的页面就是一个模块
  2. 对具有共同特性的页面进行合并整理 (推荐: 按照主业务流程)
- 内容
  1. 注册
  2. 登录
    3，商品浏览
  3. 购物车管理
  4. 订单管理
  5. 支付管理等等
后台
- 原则
  系统 -> 子系统 -> 模块 -> 子模块
- 推荐
  模块 -> 菜单 -> 子菜单 -> 标签
  见到具体的页面就结束
- 内容
  - 系统
    - 设置
      - 商城设置
        网站信息
        基本设置
        短信设置等等
      - 地区&配送
      - 短信模板等等
    - 会员
    - 广告等等
  - 商城
  - 插件等等

7 TPshop项目技术栈

组成
- 操作系统：windows
- web服务器：Apache
- 项目代码：PHP
- 数据库：Mysql
思考
- 如何绘图表示技术栈 (参考经典三层架构)

8 数据库知识复习

比较重要的表
- tp_users 用户表
- tp_goods 商品表
- tp_order 订单表
练习1
- 查询用户表中最后一条记录
  SELECT * FROM tp_users ORDER BY user_id DESC LIMIT 1
练习2
- 查询商品表中前10个商品信息, 注意只显示: id , 名称, 库存, 售价
  SELECT goods_id, goods_name, store_count, shop_price FROM tp_goods LIMIT 10
作业1
- 注册一个用户, 修改这个用户的昵称
作业2
- 查询手机号是"xxx"的会员账号和昵称, 以及这个会员所下的订单的订单编号

9 总体介绍

思考：
为什么要学习测试流程?
内容：
1. 需求评审
2. 制定测试计划与测试方案
3. 设计测试用例, 发起测试用例评审
4. 执行测试用例, 管理Bug
5. 编写测试报告
6. 其他（验收测试、线上测试和收集线上反馈, 验证用户提出的问题）

10 注册功能

10.1 需求

什么是软件需求
就是软件要实现的目标
可以大体上分为功能需求, 非功能需求
呈现形式
- 文档
  - 需求说明书,又叫需求文档,又叫 prd文档
  - 原型图

10.2 需求评审

为什么要做需求评审
产品, 开发, 测试等对需求达成共识
怎样做需求评审

1. 产品人员邮件将文档提前发给相关: ui, 开发, 测试
2. 评审会议
3. 修改与确认
**测试工程师在需求评审中的主要职责是什么**
- 确认自己对需求的理解是否清晰
- 对需求中不合理的地方提出修改意见
	- 用户体验
	- 对比市场上的同类产品
- [可能]确认需求文档的完整和正确性, 能够指导后期的工作

10.3 编写测试计划

概念 :是指描述了要进行的测试活动的范围, 方法, 资源, 进度的文档
内容

1. 明确的测试目标与测试范围
 2. 执行计划的角色和职责
 3. 任务的进度安排与资源分配
 4. 风险评估和应急计划
 5. 测试的各项标准

[作业]

TPshop测试计划
- 15分钟去网上找一找测试计划模板
- 15分钟理解测试计划所包含的内容
- 10分钟简单的写一个测试计划

10.4 编写测试计划与测试方案

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

测试策略
- 功能性:对于需求文档中所描述的功能完成度/ 精准度
- 性能:是否满足需求文档中的性能要求
- 安全:认证/ 授权/ 隐私
- 兼容性:操作系统兼容, 硬件兼容, 向后兼容, 应用兼容
- 可靠性:错误处理, 可恢复性, 稳定性…
- 用户体验测试等等-
测试方法
- 黑盒/白盒/灰盒, 动态/静态 (测试的分类)
测试环境的规划
测试工具的设计和选择

[作业]

TPshop测试方案

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

测试计划是[管理型]文档, 测试方案[技术型]文档
测试计划主要解决 [做什么] [谁来做], 测试方案主要解决 [怎么做]

实际工作中的测试计划和测试方案

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

10.5 设计测试用例

需求分析
- 输入分析
  - 长度
  - 类型
  - 组成规则
  - 是否为空
  - 是否重复
- 交互分析
  - 所有数据都正确
  - 有错误, 给出提示
- 输出分析
  - 前台
  - 后台
  - 数据库
构造数据 (等价类+边界值)
编写用例
- 构造数据中, 一个数据对应一条测试用例, 用例的预期结果要参照需求分析中的输出分析
- 可以根据需求文档去补充没有写到的测试用例

10.6 测试用例评审

内部评审
- 测试组内部：测试经理, 测试主管, 高级测试工程师
外部评审
- 测试组外部：测试, 产品, 开发, 客户
最佳推荐评审
- 对应模块的开发人员是必须要参加
- 其他人可选, 如, 开发老大, 测试老大, 产品经理

10.7 执行用例与缺陷跟踪

执行测试
- 逐条执行
- 按照用例的详细内容执行 (预置条件, 测试数据, 执行步骤, 预期结果)
- 注意: 不能只看测试用例标题执行
- 执行用例的结果: pass (成功), fail (失败), block (被阻塞), N/A (不用执行)
- 执行失败的用例要及时填写缺陷报告 (在禅道或者类似的缺陷管理工具上记录你所发现的bug)
缺陷跟踪
- 在哪提交?
  禅道或者 Jira等缺陷管理工具
- 怎么写?
  按照表单填写
- 提交给谁?
  对应的开发人员
- 如何跟踪?
  缺陷的状态变化会给相关人员发邮件
- 何时结束?
  验证通过, 不是bug, 不予解决等等

10. 写测试报告

一般不在这个阶段去写测试报告, 要全部模块都测试完成, 才统一写测试报告

11 轮播图功能

在这里插入图片描述

11.1 设计测试用例

需求分析

拆分测试点 (最小的需求点或者规则)
根据测试点, 分析设计测试用例
**[五星推荐]**需求 -> 测试点 -> 测试用例设计方法 -> 测试用例

编写测试用例, 一个测试点对应一条或多条测试用例
执行用例和缺陷跟踪

测试用例
在这里插入图片描述

12 购物车功能

12.1 设计测试用例

步骤

需求分析
- 拆分测试点 (最小的需求点或者规则)
- 根据测试点, 分析设计测试用例（等价类、边界值、场景法、判定表、流程图法、其他方法）
- **[五星推荐]**需求 -> 测试点 -> 测试用例设计方法 -> 测试用例
编写用例
用例评审
执行用例与缺陷跟踪
写报告

测试点

在这里插入图片描述

测试用例

在这里插入图片描述

13 测试报告

13.1 写测试报告的时间段

整个版本都测试完成，最后写测试报告

13.2 测试报告的概念

测试活动的总结性文档，标志测试活动的结束

13.3 测试报告的具体内容

测试工作的经过和结果
风险评估：重点列出不能进行测试的功能
缺陷的汇总和分析
测试工作的总结和改进

13.4 在敏捷流程中测试报告的表现

是一个文档或者是一个邮件
内容：
1. 测试负责人
2. 什么时间完成了什么版本，测试结果是否通过
3. 可能需要缺陷汇总，风险评估，工作总结

14 测试报告模板

[http://blog.51cto.com/xqtesting/2057574][http://blog.51cto.com/xqtesting/2057574]

14.1 简介

14.1.1 编写目的

本文档用于记录测试过程，总结各轮次的测试情况，分析测试数据，归纳测试工作进行过程中暴露的问题与遗留的风险，给出相应的测试建议以供后续项目参考。

14.1.2 项目背景

xx需要一个拥有真实用户的社区化产品，通过真实高信任度用户关系的建立，提高用户粘性，提升活跃会员数，带来长效的增长。在此背景下，以真实用户为基础的社区应运而生。主要具有以下5点意义：

提高社区活跃会员数
提高用户粘度
建立真实（和用户的社区身份相一致）的多维用户信息
建立高信任度的用户关系
达到真实可信用户关系中的用户之间的传播效应

14.1.3 定义、首字母缩写词和缩略语

无

14.1.4 参考资料

各轮系统测试阶段总结

14.2 测试概要

整个xx项目的测试经历了xx-1.0与xx-1.1两个阶段，共经历了1轮集成测试、6轮冒烟测试和7轮系统测试和1轮上线跟踪测试。整个测试过程中累计执行用例8100条，发现缺陷1026个。截至xx-1.1第四系统测试结束，所发现的高权重问题已得到修复和验证。

14.2.1 测试时间

整个xx项目的测试时间从xx年2月18日开始，到xx年3月27日上线止，期间各阶段工作情况如下：

工作阶段	开始时间	结束时间	工作量(人日)
xx-1.0	xx-1.0需求确认、评审、测试用例编写&评审	2008年2月18日	2008年2月25日	30
xx-1.0集成测试	2008年2月22日19：30	2008年2月23日 1：00	4
xx-1.0第一轮系统测试之冒烟测试一	2008年2月26日 10：30	2008年2月26日 17：00	5
xx-1.0第一轮系统测试之冒烟测试二	2008年2月29日 13：00	2008年2月29日 19：00	4.5
xx-1.0第一轮系统测试之冒烟测试三	2008年3月3日 10：00	2008年3月3日 16：00	4.5
xx-1.0第一轮系统测试	2008年3月5日 15：00	2008年3月8日 16：30	36
xx-1.0第二轮系统测试	2008年3月10日 10：30	2008年3月11日 19：00	20
xx-1.0第三轮系统测试	2008年3月11日 21：00	2008年3月11日 22：00	1
xx-1.1	xx-1.1需求评审、测试用例编写&评审	2008年3月12日	2008年3月17日	15
xx-1.1第一轮系统测试之冒烟测试	2008年3月18日 10：00	2008年3月18日 15：30	4
xx-1.1第一轮系统测试	2008年3月19日 10：00	2008年3月21日 18：00	20
xx-1.1第二轮系统测试之冒烟测试	2008年3月22日 16：00	2008年3月22日 18：30	1.5
xx-1.1第二轮系统测试	2008年3月22日 16：00	2008年3月24日 16：00	18
xx-1.1第三轮系统测试	2008年3月25日 10：00	2008年3月25日 17：00	6.25
xx-1.1第四轮系统测试	2008年3月25日 21：30	2008年3月26日 1：30	4
xx-1.1上线跟踪测试	2008年3月27日6:30	2008年3月27日12:00	4.5
合计	178

14.2.2 测试范围

本次测试覆盖的范围包括：功能测试、兼容性测试、接口测试、数据迁移测试、性能测试、安全性测试和品质监控。以下分别对功能测试、兼容性测试、接口测试、数据迁移测试、性能测试和安全性测试进行说明。

功能测试

xx-1.1在xx-1.0基础上更新的主要功能如下：

No.	模块	权重
1	通行证注册、登录，及个人社区产品的开通	A
2	系统消息	A
3	订阅	A
4	即时聊天	B
5	名片	B
6	更新提示	B
7	Feed改造	B
8	UIC 改造	B
9	报错页	B
10	xx-1.0遗留到xx-1.1的缺陷	C
11	各个产品针对xx-1.1的改造	C

xx-1.0 包括的主要功能如下：

No.	模块	权重
1	登录注册开通	C
2	导航	C
3	Profile	A
4	Account帐户管理	B
5	Privac隐私设置	B
6	Feed	A
7	个人资料	B
8	Space-q	B
9	Space-bbs	B
10	Space-bar	B
11	Firend好友	A
12	Vistor访客	A
13	纸条箱	A
14	留言	A
15	UIC（头像、昵称）	A
16	帮助	C
17	各个产品针对xx-1.0的改造	C

数据迁移测试

No.	关注项	权重
1	博客播客相册圈子论坛与Space的用户头像切换	A
2	博客老用户访客数据为Space的提供	A
3	博客播客相册圈子论坛老用户好友数据与Space的整合	A
4	博客播客相册圈子论坛老用户纸条箱数据与Space的整合	A
5	圈子老用户个人资料数据与Space的整合	A
6	博客播客圈子老用户留言数据与Space的整合	A

接口测试

No.	关注项	权重
1	各产品与Space的feed功能的接口测试	A

兼容性测试

No.	关注项	权重
1	IE6	A
2	IE7	B
3	Firefox2.0	C

性能测试

参见SVN中的性能测试报告。

安全性测试

整个xx测试过程中先后进行了三轮安全性测试，发现了2个影响较严重的安全性问题，且都已得到修复和验证。

14.2.3 测试版本

下表显示了各轮次测试版本和对应测试范围的分配情况：

14.2.4 测试用例

根据需求文档，测试人员编写和内审了测试用例，为xx项目共计编写用例3558条，累计执行用例8100条。

14.2.5 测试策略

xx-1.0测试策略

测试类型：按阶段划分定义为集成测试和系统测试。
集成测试阶段进行了一轮集成测试，主要以需求挖掘、分析、确认和寻找实现与需求不一致为主要目标
系统测试阶段分三轮进行，基本策略如下：

第一轮为覆盖性测试，测试范围覆盖以上描述的所有范围，关注所有级别的bug；

第二轮对权重为A、B的模块进行功能测试、兼容性测试，权重为C的模块进行冒烟测试，回归测试所有已修复的bug；

第三轮对权重为A的模块进行功能测试、兼容性测试，对权重为B、C的模块进行冒烟测试，回归测试所有待解决的bug，及已关闭的高优先级bug。

每轮测试开始前都进行快速的冒烟测试，通过冒烟确信系统可测时进入下一轮系统测试。

数据迁移测试、接口测试只在第一轮进行。

缺陷评估：每轮测试结束后都组织开发工程师、测试工程师、产品工程师等共同评估产品缺陷，评估内容包括缺陷解决方案、是否涉及需求变更、下一轮开始时间及是否可以结束测试等。

xx-1.1测试策略

测试类型：按阶段划分定义为系统测试。
系统测试分四个轮次进行，基本策略如下：

第一轮为覆盖性测试，测试范围覆盖以上描述的所有范围，关注所有级别的bug；

第二轮对权重为A、B的模块进行功能测试、兼容性测试，权重为C的模块进行冒烟测试，回归测试所有已修复的bug；对系统进行性能测试。

第三、四轮对权重为A的模块进行功能测试、兼容性测试，对权重为B、C的模块进行冒烟测试，回归测试所有待解决的bug，及已关闭的高优先级bug；

每轮测试开始前都进行快速的冒烟测试，通过冒烟确信系统可测时进入下一轮系统测试。

数据迁移测试、接口测试只在第一轮进行。

缺陷评估：每轮测试结束后都组织开发工程师、测试工程师、产品工程师、QA等共同评估产品缺陷，评估内容包括缺陷解决方案、是否涉及需求变更、下一轮开始时间及是否可以结束测试等。
结果分析

整个xx测试过程中累计发现有效缺陷1026个，其中A级缺陷3个，B级21个，C级800个，D级169个，E级33个。经项目组成员评估，到xx-1.1发布止遗留缺陷51个，其余975个缺陷均已修复且全部验证通过。下面分别从xx-1.0和xx-1.1两个阶段、从不同角度对缺陷进行分析。

14.3.1 缺陷趋势

xx-1.0

整个测试过程中累计发现缺陷734个，各轮次缺陷分布情况。

xx-1.1

整个测试过程中累计发现缺陷292个，各轮次缺陷分布情况如下表。

显示了xx-1.1测试过程中缺陷的发展趋势：

从缺陷趋势图中可以看出，xx-1.0和xx-1.1两个测试阶段，缺陷均随着测试过程的推进呈现收敛趋势，这符合测试缺陷的发展规律，证明测试计划和策略是可靠有效的。

14.3.2 缺陷优先级分布

xx-1.0

每轮次各级别缺陷分布情况如下：

xx-1.1

每轮次各级别缺陷分布情况如下：

整个xx项目测试过程种中发现的C级以上（包括C级）缺陷824个，占总缺陷数的80.31%，这说明系统在测试过程中处于不稳定状态，存在大量较为严重的问题，但随着测试过程的推进，高优先级问题又逐渐减少，整个系统趋于稳定。

14.3.3 缺陷按模块分布

下表显示了整个xx测试过程中发现缺陷在各模块中的分布情况

模块	缺陷数	%
需求0221	223	21.73%
好友	101	9.84%
个人资料	75	7.31%
Feed	74	7.21%
登录注册开通	61	5.95%
Space-blog	54	5.26%
纸条	53	5.17%
Space-q	52	5.07%
帐户管理	38	3.70%
Space-bbs	35	3.41%
Space-gallery	31	3.02%
UIC	31	3.02%
留言	31	3.02%
Space-bar	25	2.44%
系统消息	25	2.44%
其它	21	2.05%
Space-vblog	20	1.95%
名片	17	1.66%
订阅	17	1.66%
访客	15	1.46%
导航	11	1.07%
隐私设置	10	0.97%
Space管理后台	4	0.39%
安全	2	0.19%
合计	1026

从下图中可以看出各模块缺陷的分布趋势：

从以上缺陷分布情况看，所有缺陷中有近30%是和产品需求相关的，诸如需求定义欠明确、需求描述有歧义、需求没有定义、实现和需求不一致等。

14.3.4 重开缺陷情况

从上表可以看出整个Space测试过程中，各轮验证缺陷的重开比率都偏高，这是我们后续项目中需要关注和提高的地方。

14.3.5 遗留缺陷情况

到xx-1.1发布止，整个Space项目遗留缺陷51个，且这些缺陷均通过PDT相关成员评估后确信可以遗留，待后续版本规划处理。具体缺陷信息此处略去。

14.3.6 上线跟踪测试结果

xx-1.1于3月27日7:00上线后，我们在当日的7:00-12:00进行了集中跟踪测试，且在此之后安排有2名测试工程师，每天用一些时间跟踪上线情况、客服反馈问题的最新动态。截止4月2日上午11:00上线跟踪测试结果是：累计缺陷40个，且都是C级以下。其中属需求相关问题5个，因上线后环境差异导致问题35个，开放中缺陷4个，已关闭缺陷16个，已解决待验证缺陷20个。

14.4 结论&问题&建议

14.4.1 测试结论

经过前后两个阶段的多轮测试，虽遗留了一些缺陷没有解决，但系统功能已趋于稳定，且项目确定的范围、策略和计划均已实现，项目测试可以结束、xx-1.1可以上线。
通过测试觉得产品在用户体验方面有待后续版本进一步改进，不排除用户在使用该产品时有“晕”的感觉。

14.4.2 呈现的问题

**需求问题。**特别是xx-1.0项目需求，虽然陆续看到了好多需求文档，但这些文档给人的感觉是：需求分析不完整、需求描述不清晰，需求文档的逻辑性、可读性、可实现性、可测试性比较差，需求的歧义性较大。从而感觉在整个xx-1.0测试过程中不断地在挖掘需求、确认需求、变更需求和评审需求。xx-1.1的项目需求有了很大改观，xx本身需求经过和收集、分析、确认和评审的过程，但对各接口产品的需求仍然没有进行统一的分析、确认和评审，这部分需求的歧义性较大且变更较多，整个需求文档的可读性、可测试性、完整性和清晰性仍然较差。
**变更控制问题。**这在xx-1.0的测试过程中体现的比较明显，如项目需求的变更、项目责任人的变更、项目计划的变更等。xx-1.0整个测试过程中一直在确认和变更需求，且需求变更的机制没有规约，一个会议、一封mail或是一个口头传达就可能变更需求。xx-1.1测试过程中这一问题得到了较好的改进，但变更控制规约的实施欠佳。所有的需求变更均没有及时很好的更新至需求文档，xx-1.0体现的更为明显。
**版本控制问题。**xx-1.0测试过程中没能进行版本管理；xx-1.1测试过程中对xx本身的代码进行了版本管理，各接口产品的代码均由各技术负责人进行管理，在这期间出现过代码覆盖的情况、代码忘记上传或遗漏部署的情况。难以保证每轮测试版本的清晰、和发布版本与测试版本的一致性。
**测试环境问题。**xx-1.1测试期间测试环境和开发环境没能很好的分离，导致测试和开发修复缺陷不能并行；测试期间有开发工程师直接在测试环境上修复缺陷和修改测试环境的情况；测试环境不稳定，如hosts设置不正确等。
项目计划欠明确、人员职责欠清晰。

14.4.3 测试建议

**遗留缺陷。**建议在xx-1.1上线后以patch方式，或在后续版本中解决遗留缺陷，以提升产品的稳定性和用户体验。
**需求建议。**不论是xx本身还是各接口产品，建议进一步加强需求收集、分析、确认和评审过程，进一步提升需求文档的质量：减少需求的歧义性，提升需求的完整性、描述的清晰性、一致性、可读性、可实现性和可测试性。同时建议在后续项目中能对设计文档（如UI/UE等）进行评审，以增强产品的使用性、提升用户体验。
**变更控制。**建议在后续项目中进一步加强变更控制策略和规约制定，并强化变更控制规约的执行。不怕变更，关键要控制好变更的时机和策略。
**版本控制。**加强xx本身，特别是各接口产品的版本控制策略，以保证测试版本的清晰性、发布/上线版本和最终测试版本的一致性。
**测试环境。**期望在后续项目中xx及各接口产品的测试环境和开发环境完全分开，或阶段性完全独立，且各部分环境有专门的接口人负责，在测试期间严格禁止在测试环境上修复缺陷或更改环境配置（如确实需要更改配置，请提前通知测试及其它相关负责人）。以减少因此带来的沟通、反复侦测的成本。
**项目管理。**主要是建议加强项目的计划性，诸如：进度计划、人力资源计划、风险预防机制等，这也将更利于项目成员间高效的配合：大家能更适时的、更合理的制定各自工作计划，也更清楚到什么时候我会输出什么、我将配合他人做些什么。减少项目进行过程中的紧张和慌乱、项目也变得更加易控和可控。

15 基于业务设计测试用例

15.1 前台下单流程设计测试用例

流程：

需求分析
绘制流程图
1. 确定业务中操作以及执行顺序
  1. 登录
  2. 选购商品
  3. 加入购物车
  4. 支付
  5. 等待收货
2. 按照业务方向进行连线
设计测试用例

15.2 后台发货流程设计测试用例

流程：

需求分析
绘制流程图
1. 确定业务中操作以及执行顺序
  1. 货到付款
    1. 商家，收到前台订单
    2. 商家，确认订单
    3. 商家，确认发货
    4. 商家，前台确认收货付款
    5. 商家，确认付款
  2. 先付款后收货
    1. 商家，收到前台订单
    2. 商家，确认订单
    3. 商家，确认发货
    4. 商家，前台确认收货
    5. 商家，确认付款
2. 按照业务方向进行连线
设计测试用例

16 测试用例的设计思路

16.1 基本原则

等价类和边界值组合：典型的功能【注册、登录等等】
常用方法：拆分需求形成测试点，需求->功能点->测试用例设计方法->测试用例（一个测试点对应至少一条用例）【轮播图、购物车，需求文档有大篇幅的文字描述】
流程图和场景法（业务流程）：【前台下单流程、后台发货流程】
总结：覆盖需求->相关业务->各个角度->精简再补充
1. 覆盖需求：
  - 分析需求
  - 抽取测试点
2. 相关业务：
  - 提到的业务流程
  - 影响的业务流程
3. 各个角度：
  - 正向
  - 逆向
  - 主流程
  - 分支流程
  - 异常操作
4. 精简再补充：
  - 需求文档
  - 测试策略
  - 业务知识
  - 测试经验

17 非功能测试

17.1 兼容性测试

概念： 指被测软件在不同的软件/硬件环境下是否能够正常使用

测试关注点：

操作系统
浏览器
屏幕分辨率
网络

17.2 性能测试

**关注点：**如：访问项目所消耗的时间

测试依据：

<= 3s 响应还不错
3-5s 还可以
5-8 不太好
8s+ 换产品

小结： 以上内容只是性能内容的其中一方面

17.3 易用性测试

测试关注点：

用户点击次数：推荐3次内达到用户的目的
回车事件处理
基于特定用户群体需求考虑（如：老年人、小朋友）

17.4 可维护性测试

测试关注点：

软件升级过程：停服时间、停服频率等
数据库升级脚本
项目代码的可维护性
自动化测试代码的可维护性

17.5 安全性测试

测试关注点：

输入数据的安全性
- 敏感信息的遮挡处理
- 输入框敏感信息做不能复制的处理
数据传输过程中的安全性
- 请求方法据欸的那个敏感信息能不能暴露在地址栏中【推荐使用post请求方式】
- 数据传输过程中需要加密
输出数据的安全性：数据库存储敏感信息需要加密

17.6 登录功能的测试点

功能测试
- 登录成功
  - 用户名/密码正确
- 登录失败
  - 用户名或密码错误
  - 用户名或密码为空
非功能测试
- 兼容性
  - 操作系统
  - 浏览器
  - 屏幕分辨率
  - 网络
- 性能
  - 大量用户同时登录
- 安全性
  - 密码要遮挡，不能复制
  - 地址栏不要显示密码
  - 传输过程要做数据加密
  - 存储敏感数据要加密
- 易用性
  - 回车事件处理
  - Tab切换键
- 可维护性
  - 元素是否可以统一管理

18 项目和数据库

项目测试使用数据库的场景：

验证数据的准确性和完整性，如：存在截取的展示的规则
借助数据库进行缺陷定位，如：用户性别的显示有误
借助数据库构造测试数据，如：批量生成各种面值的优惠卷
借助数据库备份更新，如：软件升级，可能需要处理历史数据，需要测试升级的sql脚本，验证结果

面试题

1 支付功能测试的思路

支付金额
支付操作
支付接口
异常处理
其他-> 反洗钱

Anthony_231

关注

29
点赞
踩
16

收藏

觉得还不错? 一键收藏
0
评论
Web手工测试基础案例

前端浏览器客户端应用服务器本质上是一台电脑能够发布应用的程序ip端口项目代码数据服务器本质上是一台电脑数据库服务ip端口为什么要学习测试流程?1. 需求评审2. 制定测试计划与测试方案3. 设计测试用例, 发起测试用例评审4. 执行测试用例, 管理Bug5. 编写测试报告6. 其他（验收测试、线上测试和收集线上反馈, 验证用户提出的问题）
复制链接

扫一扫