熟悉项目
- 项目架构
- 业务模块，模块之间的关系
- 项目干了个啥
测试流程
- 需求评审
- 编写测试计划和测试方案
- 编写测试用例与评审
- 测试执行与BUG跟踪
- 编写测试报告
功能测试：理解需求，根据功能点编写测试用例
基本要求：覆盖需求，需求文档，产品原型图，UI设计图，以用户角度测试软件的可见功能
设计步骤：需求分析==》测试点==》测试用例
轮播图功能测试
需求说明与测试点
需求以需求文档为准，不同意见需要在需求评审的时候提出来
编写测试用例
编写测试用例没有对错之分，自己写着练习
| ID：建用例编号 用例优先级 P0：一般为保证软件中最主要、重要的功能，最基本的流程能正常运行而设计 P1：次要功能、小功能 P2：UI、边界、错误的设置 P3：错误信息、较复杂的场景、不常用的场景 测试结果：pass、fail、block（由于有bug不能继续执行时填写）、NA（由于环境、资源缺失不能执行时填写） 测试版本号：当前测试任务所用的软件版本号 备注： 1. fail的用例问题描述和对应的bugID可填入此项中 2. block和NA的用例需要在此项填写原因 3. 对用例有疑问，或此用例需要更新也可以填写在此项中 |
执行测试用例并记录缺陷
| ID：缺陷编号 问题描述：对应于“禅道”中bug标题，或问题简要描述 严重程度： 严重（S1）：主功能不可用、crash问题、闪退、不能启动 一般（S2）：次要功能不可用，边界、异常未进行处理等 微小（S3）：易用性问题、界面展示，小的性能问题等 建议（S4）：建议性问题 缺陷优先级： Priority 0：必须在24小时之内被解决 Priority 1：产品发布前必须修复 Priority 2：可以在下一个版本中修复 缺陷状态： New：新建 Open：打开 Fixed：修复 Rejected：拒绝 Postponed: 延期 Reopen：再次打开 |
购物车功能测试
需求说明与测试点
测试点尽量写的详细，后面测试用例编写的时候，可以酌情删减
测试点可以excel或者xmind的形式整理
确保需求文档里写的点都要被测到
编写测试用例
有个疑问的地方，设计测试用力的时候，感觉有些测试点可以合并成一条测试用例，不知道这时候是分开写多条测试用例还是写一条覆盖 。
写多条，可以把其他的情况作为前置条件或者测试数据，在测试步骤中体现，预期结果只关注测试点的效果
测试步骤一致时，需要确认的东西都可以写在预期结果中
注册功能测试
需求说明与测试点
编写测试用例
等价类划分，测试用例尽量覆盖全部的有效等价类，每个无效等价类都需要一条测试用例
会员列表功能测试
需求说明与测试点
一些页面截图
抢购功能测试
需求说明与测试点
一些界面截图
优惠卷功能测试
需求说明与测试点
一些界面截图
非功能性测试
- 兼容性测试：不同平台，不同浏览器，不同操作系统，不同操作系统版本，不同网络情况
- 界面测试（UI）：布局、风格、按钮、参照UI设计图
- 易用性测试：用户群体、计算机水平、项目复杂性、快捷操作
- 性能测试：用户量大、并发测试、压力测试、负载测试
- 安全测试：输入数据、传输数据、输出数据、sql注入、渗透测试
业务流程测试
状态转移法
概念：基于系统中模块或节点之间的状态。来描绘状态与状态之间的关系，从而找到状态之间转化的路线设计测试用例的一种方法。
使用：
-
找出系统所有的节点
-
绘制状态迁移图
-
绘制状态迁移树
-
找出状态之间的转换路径
业务流程图
-
业务流程测试的关注点：
-
关注点在核心业务是否能够跑通
-
重点不是关注单个功能模块的细节点
-
-
业务流程测试的价值：
-
客户角度：对客户最有价值的是业务的实现，不是单功能模块的质量
-
测试人员角度：分配任务往往是针对功能模块划分，业务流程的测试容易遗漏
-
-
进行业务流程测试的时机
-
上线前进行业务流程测试的确认
-
单功能模块基本可用的情况下，尽早进行（冒烟测试）
-
-
业务流程测试用例设计
-
需求分析，明确流程
-
画出流程图
-
编写测试用例，一条路径对应一条测试用例
-
路径较多时，根据业务设计优先级
-
-
下单流程图
发货流程图
业务测试用例
前台下单
后台发货
测试思路
写测试点，整理的一些功能测试点的思路，除了这些基本的点以为还要加上业务的规则等
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
