功能测试手工测试黑盒测试系统测试傻傻分不清-总结
功能测试、手工测试、黑盒测试、系统测试傻傻分不清？- 总结
功能测试
目录
功能测试，分为功能测试和非功能测试，先进行业务场景测试，再测试单功能模块。
（1）功能测试：正向、逆向设计
（2）非功能测试：兼容性测试、界面测试、易用性测试、性能测试、安全测试
界面测试，或称UI测试，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否 符合客户使用习惯。
UI原型：布局颜色与原型一致、图片和文字准确无误
如果没有原型图和UI效果图，可以通过一下几个方面考虑 ：导航测试 、图形测试 、内容测试 、整体界面风格测试
- 易用性测试：是指用户使用软件时是否感觉方便。简单说就是：易懂、易学、易用、吸引人。关注点在于：项目难易程度、 适用人群 、用户的计算机水平
- 兼容性测试：兼容性指软件对不同平台，不同环境，不同分辨率的适应能力。谷歌Chrome、火狐Firefox、苹果Safari、Edge ，标注：请使用最新版谷歌、火狐、苹果、Edge
兼容性应用场景：项目要求在不同的操作系统、不同浏览器、不同的平台、不同分辨率下操作时
关注点：浏览器和操作系统
操作系统：
不同的操作系统：Windows、Linux、mac等
相同的操作系统不同的版本：win7、win8、win10
不同的浏览器：三大主流—Edge、Chrome、Firefox 相同的浏览器不同的版本。
分辨率：
具体的兼容测试环境公司来定
- 安全性测试：功能模块涉及到用户隐私信息，人身，财产安全等情况。关注点： 安全性：登录时密码是否进行加密以及密码是否容易破解 SQL注入：攻击者把SQL语句作为参数传入web应用程序，最终达到欺骗服务器执行恶意的SQL语句
（4）其他：站在用户角度
提测标准
符合规定版本及内容
冒烟测试用例100%通过
结束标准
P0—P2全部Bug修复完成
P3 修复完成95%
规定测试对象全部测试完毕
优先级评定
| 用例 | 优先级 | 说明 |
| 业务场景用例 | P0 | 业务场景用例优先级永远是最高的（主业务） |
| 单模块正向用例 | P0 | 测试单个模块放P0 |
| 单模块反向用例 （功能异常） | P1 | 在需求文档中特别强调的错误类型（如 登录强调了与用户名或密码错误时，给出的提示消息） |
| 单模块反向用例 （数据异常） | P2 | 依次递减 （空、长度不符、类型不符） |
功能测试用例设计思路：
有多个输入条件减少测试用例的方法：范围、长度、类型、规则、是否必填、是否重复、空、输入内容
功能测试用例设计原则
正向：一条用例尽可能覆盖多条
逆向：每一条数据都是一个单独用例 （一次只能覆盖一条，其它选项必须正确）
编写测试用例步骤
- 分析需求
- 整理测试点
- 编写测试用例
（1）分析并熟悉需求
- 文档：需求说明书、产品原型图、UI设计图
- 环境：测试环境、预生产环境、正式环境
- 人员：产品、测试老员工
（2）整理测试点
提取测试点：业务测试点、单功能测试点
业务测试点：
思路：（1）梳理业务流程 （2）根据业务流程提取测试点
整理测试点要达到能够直接编写测试用例的程度（能描述出一个测试目的的文字信息）
根据需求拆分：不同的功能点、观察法、用例设计方法（等价类、边界值、判定表、场景法、流程图、正交表、状态迁移法）
按照原型拆分：所见即所测（与被测对象紧密相关的部分）
（3）编写测试用例
按照用例8大要素编写：
| ID | 用例标题 | 项目模块 | 优先级 | 预置条件 | 测试步骤 | 测试数据 | 预期结果 | 测试结果 | 测试人 | 测试版本号 | 备注 |
| qq_login_001 | 登录成功（输入正确用户名和密码） | 登录 | P0 | 账号已注册 | 1、输入账号 2、输入棉麻 | 账号：xxx 密码： xxx | pass 前台 后台 数据库 隐性结果 建议 | pass fail block NA | 回归测试 | 关联bug |
功能测试与数据库
代码中有统计数据
有多个模块显示数据是来自相同数据源，产生bug不能够准确定位bug产生模块
制造测试数据
改变表结构
项目与数据库的关系：
项目中的数据是存储在数据库中的；对数据修改（增删改查）会影响项目页面显示
项目中应用数据库的4种典型场景：
验证数据的准确性和完整性
借助数据库进行缺陷定位
借助数据库构造测试场景（需要特定的测试数据）
借助数据库数据备份更新
功能测试流程
- 需求分析与评审 （对于产品需求文档进行评审和评估的过程）
- 编写测试计划与测试方案 （测什么？谁来测？怎么测？）
- 设计测试用例与评审 - 根据需求将需要转化为具体可以验证的测试点
- 执行测试用例与缺陷跟踪 – 根据评审之后的用例进行执行验证产品质量
- 编写测试报告 –对于整体测试过程的总结和质量的说明
测试计划与测试方案的区别（面试题）：
- 测试计划是【管理型】文档，测试方案是【技术型】文档；
- 测试计划主要解决【做什么？】【谁来做？】，测试方案主要解决【怎么做？】
- 主要内容存在差异：
- 测试计划主要内容如下 ：
- 明确的测试目标与测试范围
- 执行计划的角色与职责
- 任务的进度安排与资源分配
- 风险估计和应急计划
- 测试的各项标准
- 测试方案主要内容如下 ：
- 测试策略/测试方法
- 测试环境的规划
- 测试工具的设计和选择
电商项目说明
背景：为广大企业开发的专业级电子商务B2C电商平台系统，功能强大，安全便捷。
业务特性：开源的电商系统。通过互联网来实现商品的销售与业务流程的电子化。xxx是一个单商户的购物商城，可以实现商品的线上促销活动。
主要模块：注册、登录、订单管理、会员管理、商品管理、营销管理、购物车、下订单、我的购物车、订单、支付
注意：对于模块的划分，不是以菜单划分的（如：登录主页下有xx菜单）
用户与角色
前台：游客、已注册用户
后台：管理员、仓库管理员、客服
重要业务流程
xxx是一个单商户的购物商城，可以实现商品的线上促销活动。
核心业务流程：（1）商品购买流程 （2）商品发货流程 （3）商品退换货流程
前台会员购买流程
- 首页-注册-登录–搜索商品–选择商品-加入购物车-下单-支付(货到付款)
- 后台收款后–前端进入“我的订单”详情–查看订单状态–确认收货–评价完成
简化为：登录-选购商品-加入购物车-支付-等待收货
如果是游客（未注册用户），流程大致是：
打开首页-点选分类-点选商品-加入购物车-去结算—提醒登录—注册—我的购物车–去结算–添加收货地址–提交订单 –选择支付方式 （货到付款）–确认收货
后台发货流程
- 收到前台订单（商城-订单-订单列表）
- 订单确认 （付款、无效）
- 发货（订单号必填）
- 确认收款
- 买家确认收货（前台操作）
后台收到订单，点击 订单管理–确认订单–发货确认–收款
商品退换货流程
- 前台发起售后申请
- 后台进行退换货审核-审核通过-原路返回
- 前端查看个人账户余额
技术栈
Linux (CentOS7) + Apache + Mysql + PHP
系统用例设计方法 ：
等价类 + 边界值搭配使用，更好覆盖测试点
场景法(流程图法）:：可以用于表示某个具体业务处理过程，是分析业务流程的重要工具。通常用一些图 框来表示各种类型的操作，在框内写出各个步骤，然后用带箭头的 线把它们连接起来，以表示执行的先后顺序。
流程图图形
椭圆：表示流程的 开始和结束
箭头：路径，表示流程进行的 方向
平行四边形：表示数据的 输入和输出
矩形：表示 执行 或者 处理 某项工作
菱形：表示对某个条件做 判断