Day01

阶段⽬标

能独⽴针对web项⽬实施功能测试

⼀、测试介绍

• 什么是软件测试？

使⽤技术⼿段验证软件是否满⾜需求

-测试主流技能

1、功能测试
2、⾃动化测试
3、接⼝测试
4、性能测试
主流⽅向建议：1、功能测试+接⼝测试2、⾃动化测试+接⼝3、功能+性能

⼆、测试常⽤分类

分类

• 阶段划分（阶段：软件产出过程顺序）
• 代码可⻅度

2.1 阶段划分

单元测试

说明：针对程序源代码进⾏测试（单元：最⼩独⽴功能代码段）
提示：
1、国内单元测试⼀般开发⾃测
2、单元测试可以解决-快速定位缺陷
3、提高测试执行效率

集成测试

说明：针对单元与单元之间的接⼝进⾏测试
提示：⼜称接⼝测试。

系统测试

说明：针对系统整体功能+兼容+⽂档（说明、安装⽂档）

验收测试

内测：公司内部⼈员使⽤，发觉缺陷并修复。
公测：让⽤户帮忙测试
提示：验收测试,⼀般要根据项⽬类型决定是否使⽤。

2.2 代码可⻅度划分

代码可⻅度：代码可⻅的程度上划分

⿊盒测试：主要针对功能（阶段划分->系统测试）

灰盒测试：针对接⼝测试（阶段划分->集成测试）

⽩盒测试：针对程序源代码进⾏测试（阶段划分->单元测试）

2.3 总结

系统测试和⿊盒测试重点核⼼是功能测试

集成测试和灰盒测试⼜称接⼝测试

单元测试和⽩盒测试是对代码进⾏测试

⾃动化测试归属功能测试

性能测试、安全测试归属专项测试

三、模型

3.1 质量模型

说明：质量模型能告诉我们，测试时应该考虑的⽅⾯

重点：功能、性能、兼容、易⽤性、安全
结论：⽆论测试硬件或软件，都应该从以上⼏点来进⾏分类验证

四、测试流程

1. 需求分析（评审）

确保各部门需求理解一致

前提：阅读1遍需求⽂档，记录不明确之处。
参与⼈员：前端、后端、测试、产品
⽬的：1、确保各部⻔需求理解⼀致2、各⻆⾊对需求进⾏查漏补缺3、了解软件有些功能
提示：需求分析阶段->软件还未实现（刚⽴项）

2. 计划编写

说明：指导测试执⾏的⽂档（重要）
测什么（⽬标、范围）
谁来测（⼈员进度及安排）
怎么测（测试⼯具、测试策略）

3. 用例设计

验证项目是否符合需求的操作文档

说明：保证能准确验证软件测试点执⾏的⽂档。
1、分析需求
2、提取测试点
3、设计⽤例覆盖测试点

4. 用例执行

项目模块开发完成开始执行用例文档实施测试

说明：实施测试

5. 缺陷管理

对的缺陷进行管理的过程

提交->验证->关闭

6. 测试报告

实施测试结果文档

1、bug分析及统计
2、测试中遇到的问题
3、测试总结（本次测试中的优点和不⾜）

五、测试⽤例

⽤例：⽤户使⽤的案例
⽣活中的⽤例

⽤例的作⽤

1、防⽌漏测
2、衡量软件是否通过的标准

⽤例模板

⼋⼤要素编写规范

六、⽤例设计⽅法

1、能对穷举场景设计测试点
2、能对限定边界规则设计测试点
3、能对多条件依赖关系进⾏设计测试点
4、能对于项⽬业务进⾏设计测试点

6.1 能对穷举场景设计测试点

穷举：⽆穷⽆尽
⽅法：等价类划分法
介绍

重点总结

6.2 解决边界限制问题

说明：使⽤边界值解决边界位数限制问题。2.1 边界值说明

提示：1、有关范围限制，最多7条⽤例（暂时未优化）2、边界值能解决位数限制问题，但是不能解决类型问题（要结合等价类）

步骤

1、明确需求
2、确定有效和⽆效等价
3、确定边界范围
4、提取数据编写⽤例

6.3 解决多条件有依赖关系测试

重点：使⽤判定表

6.4 业务测试覆盖

重点:
1、覆盖业务测试,需要使⽤流程图法
2、先测试业务，在测试单功能、单模块、单⻚⾯

4.1 流程图

6.5 错误推荐法

应⽤场景：当项⽬⽤例都执⾏完毕，且BUG修复完成，离上线还有⼀段时间，在这段时间中可是使⽤错误推荐法复测主要业务或测试未覆盖的功能。

总结

Day02

6.2 解决边界限制问题

说明：使⽤边界值解决边界位数限制问题。2.1 边界值说明

提示：1、有关范围限制，最多7条⽤例（暂时未优化）2、边界值能解决位数限制问题，但是不能解决类型问题（要结合等价类）

步骤

1、明确需求
2、确定有效和⽆效等价
3、确定边界范围
4、提取数据编写⽤例

6.3 解决多条件有依赖关系测试

重点：使⽤判定表

6.4 业务测试覆盖

重点:
1、覆盖业务测试,需要使⽤流程图法
2、先测试业务，在测试单功能、单模块、单⻚⾯

4.1 流程图

6.5 错误推荐法

应⽤场景：当项⽬⽤例都执⾏完毕，且BUG修复完成，离上线还有⼀段时间，在这段时间中可是使⽤错误推荐法复测主要业务或测试未覆盖的功能。

总结

作业 设计注册功能的用例

Day03

⼀、⽤例执⾏

说明：执⾏结果与⽤例的期望结果不⼀致（含义），为缺陷

执⾏失败的⽤例

提示：⽤例执⾏不通过为缺陷，需要进⾏缺陷管理

⼆、缺陷

2.1 定义

软件中存在的各种问题，都为缺陷，简称bug； 1

2.2 缺陷标准

1、少功能
2、功能错误
3、多功能
4、缺少隐性功能
5、易⽤性（软件测试⼈员专业⻆度）

3.3 缺陷产⽣的原因

1、需求⽂档
2、架构设计
3、编码实现
4、环境（硬件、软件）

3.4 缺陷的⽣命周期

1、回归测试：①常规项⽬回归：项⽬本次发布新增2个模块，最基本要测新增模块功能及新增模块关联的旧模块。②⾮常规项⽬（银⾏、部队、航天）：新增功能，必须全部复测。
2、回归bug：上⼀个版本发现的缺陷，开发修复完毕，在下个版本进⾏重新验证。

3.5 缺陷核⼼要素

3.6 缺陷提交要素

3.7 缺陷类型 ★（功能、界面、兼容性、数据、易用性）

1、功能错误
2、UI⻚⾯错误
3、兼容性
4、数据（数据库）
5、易⽤性
6、建议
7、架构缺陷

⼯作流程（⼩结）

设计⽤例->执⾏⽤例（执⾏测试）->缺陷（提交、验证、关闭）
缺陷定义：任何问题（Bug）
缺陷标准：多功能、少功能、错误、缺少隐性功能、易⽤性
描述缺陷重点：缺陷标题、前置条件、复现步骤、预期结果、实际结果、附件备注
提交缺陷信息：指派⼈、缺陷等级、修复优先级、类型、状态（统计缺陷）

三、缺陷管理

3.1 excel示例

3.2 缺陷跟踪流程

提示：知道测试和开发流程中涉及的⼯作即可。

3.3 提交注意事项

⾯试题：发现缺陷后，⾸先回怎么办？--确定Bug可复现、确定是Bug。
提交时，要检查缺陷是否已存在。

3.4 缺陷管理⼯具

1、项⽬管理⼯具-管理缺陷 (禅道、JIRA、TFS)
2、Excel管理缺陷

3.5 禅道（项⽬管理⼯具）

地址：https://demo.zentao.net/user-login.html
特点

缺陷标题扩展

缺陷总结：★

bug编号、标题、严重程度、优先级、bug类型、缺陷状态、前提条件、复现步骤、预期结果、实际结果、证明材料、

总结

Day04

⼀、html介绍

html

Day05

针对登录模块实施测试设计
针对发布⽂章模块实施测试设计

⼀、项⽬介绍

⼆、项⽬实施

1、分析需求
2、设计测试点
3、编写⽤例覆盖测试点
4、执⾏⽤例
5、缺陷管理
6、测试总结

2.1 登录

登录需求

2.2 发布⽂章

总结