企业官网建设流程全解析

测试目前主要有自动化测试、接口测试、功能测试以及性能测试

目前主流的测试工具有：Jmeter、Postman以及seleium

常见测试分类：

按测试阶段划分

单元测试：针对源代码测试

集成测试：又称为接口测试，针对模块之间访问地址进行测试

系统测试：对整个系统进行测试包括功能、兼容、文档等测试

验收测试：主要分为内测、公测，使用不同人群来发掘项目缺陷

按代码可见度划分：

黑盒测试：看不见源代码，主要对程序功能进行测试。

灰盒测试：看见部分源代码，主要对接口进行测试。

白盒测试：看见全部源代码，主要对程序源代码测试

测试策略：

冒烟测试：运行主功能，看主功能是否能够正常执行，大规模测试之前，针对程序主功能进行验证，保证程序具备可测性。

提测之前需要冒烟测试通过。

模型：

质量模型：提供测试用例的不同角度视野和验证方向

测试：功能性、性能效率、兼容性、易用性、可靠性、可维护性、可移植性

功能性：功能满足需求

性能效率：性能满足实际需求

兼容性：软件能与主流硬件和软件兼容

易用性：便于使用

可靠性：性能和功能应用可靠

信息安全：信息在传输和存储过程的安全程度

可维护性：便于维护

可移植性：具备迁移和便捷性

测试模型（w模型）：

开发：用户需求--需求分析--概要设计--详细设计--编码--集成--实施--交付

测试：验收测试设计--系统测试设计--集成测试设计--单元测试设计--单元测试--集成测试--系统测试--验收测试

不仅是程序还有需求、测试文档，及早发现问题。

测试流程：

需求分析：确保各部门理解一致

计划编写：测什么、谁来测、怎么测

用例设计：验证项目是否符合需求的操作文档

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

缺陷管理：对缺陷进行管理的过程

测试报告：实施测试结果文档

需求分析：阅读需求文档，记录不明确之处

确定各部门对需求理解一致、站在不同角度对需求进行查漏补缺

测试计划：测什么：测试目标及范围、谁来测：测试人员的安排、怎么测：测试策略

测试用例：设计执行测试的文档

测试报告：bug分析、总结、不足、测试流程、测试背景。

测试用例

什么测试用例？

用例：用户使用的案例

为测试项目而设计的执行文档

作用：防止漏测、实施测试的标准

格式（用例的八大要素）：

用例编号：项目+模块+编号

用例标题：预期结果+操作步骤

模块/项目：所属模块或项目

前置条件：执行词条用例，需要哪些前置条件

优先级：用例的重要程度

测试步骤：描述操作步骤

测试数据：操作的数据

预期结果：预期达到的结果

如何设计用例？

等价划分法

解决穷举问题

说明：在所有测试数据中，具有某种共同特征的数据集合进行划分

分类：有效等价类：满足需求的数据集合

无效字符串：不满足需求的数据集合

步骤：

1、明确需求

2、确定有效和无效等价类

3、提取数据编写用例

适用场景：

1、输入框

2、下拉列表

3、单选复选框

边界值分析法

针对限定边界规则设计测试点

边界范围节点：

应用设计步骤

案例

适用场景

节点：

上点：边界上的点

离点：刚好大于、刚好小于，距离点最近的点

内点：范围内的点（区间范围内的数据）

设计步骤：

1、明确需求

2、划分有效和无效等价类

3、确定边界范围值

4、提取数据编写测试用例

需求：通过边界发验证QQ号码的合法性：

需求：6-10位

划分有效划分和无效划分类：

有效：6、7、8、9、10位数字QQ号

无效：5、11、非自然数

如何优化？

结论：7个优化位5个点

上点：必选

内点：必选

离点：开内闭外 开区间选择内部离点闭区间选择外部离点

优化：针对边界上的点，采用开内比外最终为：5、11（7、9去除）

适用场景

对于有边界范围的数据输入的地方

提示：编辑之可以覆盖等价类的长度，但是无法覆盖类型，所以设计时必须两者结合

判定表法

解决多条件问题

等价划分法主要关注单个输入类的条件的测试

组成：

条件桩：列出问题的所有条件，次序无关紧要：

动作桩：累出可能采取的操作

条件项：列出条件对应的yongli取值，所有可能动作的真假值

动作项：列出所有条件项的、各种取值情况下应该采取的动作结果

1、明确需求

2、画出判定表

3、按照规则设计测试用例

订单表查询：

条件：是否大于500、是否过期

动作：发出批准单、提货单、通知单

以上为判定表

需要多个输入条件，多个输出结果，输入条件之间有组合关系，输入和输出结果之间有依赖关系。

如果碰到项目中多条件组合大于四个相互依赖，可以使用正交表和因果图

场景法：

流程图

使用标准图形和箭头来表达程序和业务的走向

主要用来解决业务用例。

首先设计业务用例，然后设计单功能

流程图优先单功能测试

场景法测试用例：

错误推荐法：

根据经验推测系统可能出现的问题。

时间紧任务大，没有足够时间取写用例。

缺陷

定义：软件再使用过程中存在的任何问题都叫软件的缺陷，简称bug

判定标准：少功能、功能错误、多功能、隐形功能错误、不易使用

隐形功能：说明中未明确说明但应该实现的需求

产生原因：需求描述不易理解，有歧义，错误

设计阶段：设计文档存在错误或者缺陷

代码出现错误

软硬件系统本身故障导致软件缺陷

常见岗位扩展

开发（前端后端）

测试（研发）

UI

运维

产品

运维

缺陷的生命周期：

从产生到发现再到修复

缺陷的描述和提交要素：

缺陷标题、缺陷的预期结果、缺陷的预置条件、缺陷的实际结果、缺陷的复现步骤、缺陷的必要附件。

提交要素：缺号报告编号、严重程度、缺陷优先级、bug类型、缺陷状态

缺陷类型：

功能错误、界面错误、兼容性错误、数据错误、易用性错误、改进建议、架构

管理工具：

禅道