1 软件测试定义
在规定的条件下对程序进行操作，以发现程序错误。
2 软件测试目的
验证软件需求和功能是否得到了完整的实现，发现软件bug，对软件的质量、性能、效率做出合理的评估。
3 软件测试流程
3.1 概述
（1）需求分析
（2）制定测试计划
（3）设计及编写测试用例
（4）实施测试
（5）提交bug，及缺陷报告
（6）生成测试总结和报告
3.2 过程介绍
3.2.1 需求分析
“需求分析”阶段：这个阶段主要是对业务的学习，包括：阅读需求，理解需求，分析需求点，参与需求评审会议，评审需求是否合理。
3.2.2 制定测试计划
这个阶段的主要任务就是通过参考“软件需求规格说明书”以及“项目总体计划”，来编写测试计划。
所编写的测试计划的内容包括：
① 测试范围（依据需求文档）
② 进度安排（时间进度、流程进度）
③ 人力、物力的分配
（人员有哪些、都有哪些业务点、以及相对应的资源，对于这些的分配）
④ 对于整体测试策略的制定
⑤ 对于风险评估与规避措施要有一个制定
3.2.3 设计测试用例、编写测试用例
通过参考需求文档（原型图）、概要设计、详细设计等文档，来编写测试用例，用例编写完成之后会进行评审。
3.2.4 实施测试（执行测试用例）
实施测试主要包括以下几个部分：
① 搭建相应的测试环境
② 执行冒烟测试（预测试）：对主环节的关键点进行测试（若主环节有问题要打回去重新开发，例如提交基础信息、提交报名信息。其中基础信息无法提交。此项为冒烟测试后需要打回去的）。
③ 进行正式的测试
④ 回归测试（修改了旧代码后，重新进行测试以确认修改没有引入新的错误）：用户经常使用的功能、或者核心点。
3.2.5 bug的管理，提交缺陷报告
这个阶段主要是将执行测试过程中发现的bug提交到bug管理平台上，最后可能需要提交缺陷报告。
4、测试中常见的问题
（1）环境迁移问题
测试环境部署成功，部署到预发布、正式环境失败。
（2）未查询到数据空指针问题
（3）小数位数问题，单位问题
小数点保留位数不对，或者未带单位
（4）数据同步策略问题
（5）文件导入导出问题
导入类型与文件大小问题；导出数据格式不对
（6）界面时间格式显示不正确
（7）输入字段内容超长报数据库错误
（8）业务逻辑规则不符合需求
根据项目中实际测试遇到的问题，及测试复杂度等经验提出下列测试流程。
5 测试概念
5.1 单元测试
完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
5.2 接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
5.3 集成测试
集成测试是将单元或者模块组装在一起进行的测试。因为：一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。
5.4 系统测试(含界面测试、功能测试)
是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。
5.5 安全测试
安全性测试(Security Testing)是指有关验证应用程序的安全等级和识别潜在安全性缺陷的过程，其主要目的是查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力，安全指标不同，测试策略也不同。
5.6 性能测试
性能测试包括：基准测试、负载测试、压⼒测试、并发测试、容量测试、可靠性测试（稳定性测试）、配置测试、失败测试。主要测试系统的负载能力和压力能力。
5.7 验收测试
验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。
验收测试包括Alpha测试和Beta测试。
Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。
Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。
6 最佳实践
6.1 参与需求评审
对于新产品迭代中，需要参与产品需求评审会，对于一些需求变更的内容，需要参与需求变更会。对需求详细分析，理解系统角色、操作流程。
测试经理需要参与安全性测试、性能测试、回归测试、单元测试、集成测试需求的评估。
6.2 制定测试计划
对系统进行详尽的分析，分析需要测试哪些内容。测试架构师，需要参与测试计划的制定，包含范围、进度、成本、资源等方面。
6.2.1 对系统的安全性测试需求、性能测试需求进行评估
从数据内容的保密级别、针对的用户群体类型、用户群体数量、用户的使用场景，同时结合对应业务的法律法规要求进行具体评估。
（1）数据保密级别高，系统稳定性要求高？
对保密性和系统稳定性要求比较高的需要进行安全测试。
（2）是否用户群体大，实时性要求高？
需要进行性能测试。
6.2.2 对系统的回归测试需求进行评估
（1）判断系统使用年限、系统业务的后期变更频率与程度？
如果部分业务模块或系统变动不大、使用年限大于3年，则需要考虑回归测试。
（2）判断是否为公用的，重要的基础平台、模块、工具？
如果为其他系统、业务模块频繁调度的平台、模块、工具则需要考虑回归测试。（例如权限、文件上传）
6.2.3 对集成测试需求进行评估
（1）判断业务模块是否非常重要，是否影响其他各个模块？
如果当前业务模块非常重要（用户使用频次高，错误代价大），一崩溃影响主流程使用，则需要进行集成测试。
6.2.4 对接口测试需求进行评估
（1）判断是否某个接口包含复杂的逻辑，是否同时影响主要的业务流程？
如果以上两者均满足，则需要进行接口测试。
（2）此项功能，通过界面测试是否需要经过复杂的数据准备、流程准备？
可以考虑接口测试，可采用自动化测试方式。
6.2.5 对单元测试需求进行评估
（1）判断是否某个接口包含复杂的逻辑？
例如包含多种判定条件，复杂的计算公式与算法则需要进行单元测试。
6.3 评审测试计划
产品经理、项目经理、测试经理、测试架构师等相关重要岗位对测试计划进行评审。
6.4 测试人员编写测试用例
测试人员，需要根据测试计划及需求文档编写测试用例。
6.5 评审用例
测试人员、开发人员、测试架构师等相关人员评审测试用例
6.6 执行测试
根据测试用例，执行测试，提交bug，跟踪bug。
6.7 编写文档
测试总结、 测试报告、操作手册
7 如何进行测试
7.1 用什么工具测？
（1）接口测试：APIFOX ，手工或自动化
（2）集成测试：APIFOX，自动化
（3）单元测试：Junit 编写代码
（4）性能测试： JMeter 编写代码
（5）系统测试：浏览器访问 手工
（6）回归测试： CyPress 录制脚本与编写
（7）安全测试：AppScan、MetasploitMetasploit 利用开源工具编写
7.2 不同环境怎么测？
测试一般在测试环境进行，其他环境主要做主流程测试、常用功能测试。特别要注意数据库中基础数据的一致性、测试环境与正式环境软件系统及系统硬件参数的比较、换了环境后文件导出上传可用性、单点登录的可用性、国产化的适配性等。
8 在什么时间节点测试
- 单元测试、集成（接口）测试、系统测试需要在当前迭代完成。
- 其他测试在整个项目完成后实现。
- 测试计划在需求评审后1周内。
- 测试用例在第1周编写，测试在第2周及以后·进行。
- 相关文档在系统开发完成后，交付前编写、
9 软件测试模型
用于指导测试活动流程
9.1 V模型
①测试工程师在研发人员编程过程中，对其生成的代码函数做单元测试
②单元测试通过后进行集成测试
③集成测试通过后做系统测试、验收测试
9.2 W模型
W模型是在V模型的基础上演变而来的，一般又称为双V模型。在V模型中，研发活动没有完成、无任何输出物时，测试工程师无法开展测试工作，相对而言，测试活动严重滞后。为了解决V模型的缺点，W模型提出了测试活动与研发活动并行的概念，并且在生产流程演进过程中，增加了验证与确认活动。
9.3 X测试
X模型左边表明针对单独的程序片段n进行独立的编码和测试活动，以此为基本过程，不断迭代，通过集成活动最终成为可执行程序，然后再对这些可执行程序进行测试。通过集成测试的成品可以进行封装并提交给系统测试环节或直接给用户。多条并行的曲线表示变更可以在各个部分发生。
9.4 H模型
H模型将测试活动与其他研发流程独立，测试活动分为测试准备与测试执行两个部分，便于测试设计与测试执行活动定义，如图所示。测试准备活动包括测试需求分析、测试计划、测试设计、测试编码、测试验证等，测试执行包括测试运行、测试报告、测试结果分析、确认回归测试等。
9.5 敏捷测试模型
强调从客户角度进行测试；
重点关注迭代测试新功能，不再强调测试阶段
尽早测试，不间断测试，具备条件即测试
强调持续反馈
预防缺陷重于发现缺陷
附图
