软件测试基础

软件基础

软件的构成

软件 = 程序 +文档 + 数据

程序：程序员通过开发语言编写的代码集合
文档：软件开发过程中所产生的图文文档集合，如《需求规格说明书》、《用户手册》、《数据库设计说明书》等
数据：使用软件过程中所产生的的本地数据，以及服务器数据

软件研发中的角色

一款软件的诞生，离不开中间多种岗位角色的努力

产品经理：负责市场调研用户需求，确定需求方向，设计软件产品的原型
项目经理：负责驱动整个项目组的运转，制定项目计划、安排人力、管理进度、协调团队等
系统架构师：负责设计满足需求的系统主体框架结构、系统模块设计、项目技术选型，指导程序员进行开发工作
UI设计师/交互设计师：负责根据产品原型设计出符合要求界面设计稿、交互设计稿，提供给前端程序员进行界面开发
前端开发工程师：负责前端界面编程开发工作，包括web端、安卓端、IOS端、PC桌面程序端
后端开发工程师：负责后端逻辑编程开发工作，包括业务逻辑处理、数据增删改查、性能优化等
测试工程师：负责测试软件的功能性、易用性、准确性等，发现软件的bug，推进bug解决，最终呈现出较完美的软件
运维：负责将软件发布上线、监测管理服务器工作情况
DBA：数据库管理员，负责各个环境的数据管理、制定数据库使用标准
运营：负责软件日常线上运营，收集分析用户行为，根据用户情况调整项目运营策略，从而扩展用户群体和创收

软件文档
软件在研发过程中，会产生许多文档，用于推进项目开发上线
产品经理：《客户需求说明书》、《需求收集分析书》、《竞品分析》、《需求规格说明书》、《原型稿》
项目经理：《项目计划书（立项书）》、《项目版本计划书》
系统架构师：《技术选型报告》、《概要设计说明书》
UI设计师/交互设计师：《UI设计稿》、《交互设计稿》
前端开发工程师：暂无
后端开发工程师：《数据库设计说明书》、《接口设计说明书》
测试工程师：
功能测试：《测试计划》下载、《测试方案》、《测试需求分析》、《测试用例》下载、《缺陷跟踪单》下载、《测试报告》下载
性能测试：《性能测试计划》下载、《性能测试报告》下载
运维：暂无
DBA：暂无
运营：《运营方案说明书》

软件过程

概念：软件产品从最初构思到公开发行上线的过程，称为软件开发过程。通常会根据软件开发模型进行软件开发工作的推进。
常见的软件开发模型：

瀑布模型：最传统、最常规的模型，注重结构化和流程。
V模型：快速应用开发模型，每一个开发环节都有相对于的测试方案。
需求分析—》概要设计—》详细设计—》编码—》单元测试—》集成测试—》系统测试—》验收测试—》交付
W模型：测试工作和开发工作同步并行，测试工作贯穿整个项目流程。
螺旋模型：在软件开发初期阶段需求不是很明确时，采用渐进式的开发模型，边摸索边前进。
X模型：对V模型的完善，更注重探索性测试
敏捷开发模型：以用户的需求为核心，快速进行项目迭代
把项目需求收集到一个需求池中，对需要做一个优先级排序，采用迭代式开发，每次在一个短周期中迭代一个版本，选择一些优先级高的需求作为一个迭代版，一个版本迭代完了就继续迭代下一个版本；敏捷开发中有一个看板管理，每天会开一个看板会议，检讨前一天的开发进度，并且要解决前一天遇到的问题（痛点）

软件生命周期

需求→设计→编码→测试→维护→升级→废弃

质量的六大特征

功能性
可靠性
效率（性能方面）
维护性（安全性）
可移植性（兼容性）
易用性

列举实物，怎么测？

功能性： 业务功能的实现，正向与反向
可靠性： 长时间运行是否会闪退，
性能方面：响应时间，多用户大批量的请求成功率，占用资源多少
兼容性： 能不能兼容不同的系统版本，手机品牌，
安全性：密码输入有没有隐藏，是否加密保存到数据库
易用性： 界面布局是否美观，实用，方便

QA和QC

概念：

QA：主要是事先的质量保证类活动，以预防为主。期望降低错误的发生几率。例如，提前指定质量规范、流程、标准等。
QC：主要是事后的质量检验类活动为主，默认错误是允许的。期望发现并选出错误、跟进错误解决。

真实项目开发流程

面试问答：*上家公司的项目流程是什么？*
答：
我上一家公司使用的是传统的项目流程，每次版本大约会经历2~3周左右的时间，流程大概是这样的：
①首先，产品经理会收集需求，需求可能来自于市场、领导、运营部门等。收集到需求后，会进行需求可行性分析，最终设计成原型图，并组织需求评审。需求评审通过的话，项目经理会进行立项；不通过的话，产品经理需要二改需求，再举行需求二审，直到需求评审通过。
②项目立项后，UI人员会根据原型图设计UI稿，并举行UI稿评审会，测试人员也需要参加会议，因为后续需要进行UI界面测试。
③同时，后端开发人员会根据需求原型设计数据表结构、接口设计，并出具相关的文档，也会举行评审会，测试人员也会参会，因为后续需要进行数据准确性校验、接口测试。
④与此同时，测试组长会编写测试计划，在计划当中规定好测试范围、测试策略、以及每个测试组员需要负责的模块等。
⑤测试人员接到分配的模块任务，开始对需求进行分解，一般会使用Excel表格、流程图或者xmind思维导图来分解需求，目的是为了更加透彻地理解需求。
⑥接下来，测试组员开始编写测试用例，功能测试用例一般会使用到等价类、边界值、判定表、场景法、错误推论等设计方法。编写完测试用例，会邀请对应的测试人员、开发人员、产品经理一同参与用例评审。若评审通过，用例就基本成型；若评审不通过，那么就需要二改，直到用例评审通过为止。
⑦等前后端开发人员完成编码后，会进行项目联调。联调完成，开发人员会先进行自测，自测用例由测试人员提供。自测通过，会正式进行提测。
⑧项目提测后，测试人员会进行一次冒烟测试，一般冒烟测试通过率达到90%，项目才可正式进入测试阶段。否则，会打回项目，重新进行项目调整后，再提测。
⑨正式进入测试阶段后，测试人员会逐条执行测试用例，记录下测试结果。若实际操作结果与预期结果不符合，则视为bug。就需要在bug管理工具上，如禅道上进行提bug、bug追踪。直到所有的用例都执行完毕，bug都解决完毕。但，偶尔也允许出现遗留bug，就算是遗留bug，也需要给出后续的解决方案，一般遗留bug数量不能超过2%。
⑩测试完成后，会编写测试报告，描述项目的测试结果、bug分布、遗留bug、风险、是否通过测试等。并让产品经理、UI设计人员进行验收，在必要情况下，会要求代表用户进行项目内测，有问题再及时修改。
⑪ 验收完成，运维就会安排项目上线。上线后，测试人员会使用专用的测试账号进行线上验收测试，验收完成进行线上脏数据处理。
⑫ 最终，会举行一个项目复盘会议，总结项目研发过程中的遇到的技术问题、协作问题等，后续要如何避免。
这样，一个版本的项目就完成了！

软件测试

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

按阶段分类

单元测试

  针对每一个方法代码测试，一般有后端工程师自测，或由专门的`白盒测试`人员测试

集成测试

  对集成的子系统进行测试，一部分代码不可见，属于`灰盒测试`

系统测试
将已经集成好的系统与计算机硬件、外设、网络等其他元素结合在一起，模拟实际使用环境下的测试工作，属于黑盒测试。
```
 系统测试划分：
 功能测试、性能测试、兼容性测试、易用性测试、安装卸载测试、文档测试
```
验收测试

属于黑盒测试，其主要目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务
非正式验收测试：Alpha 测试（α测试）、Beta 测试（β测试）
1) Alpha 测试（α测试）:由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。俗称内测。
2) Beta 测试（β测试）:开发给一部分用户进行真实使用场景测试，并要求用户报告异常情况、提出批评意见，然后软件开发公司再对β版本进行改错和完善。俗称公测。
正式验收测试：有正规的测试过程，需要制定测试计划、定义测试方案、选择测试用例，进行测试，结果提交。着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面

按功能作用分类

兼容性测试
兼容性测试分为三大类：
1) 硬件兼容性测试
2) 软件兼容性测试
3) 数据兼容性测试
安全性测试
性能测试
性能自动化工具，模拟各种可能
接口测试
自动化测试
app测试
1) 专项测试（耗电测试、弱网测试、monkey压力测试、断网测试）
2) 兼容性测试
3) 功能测试（功能性、可靠性、性能、兼容性、安全性、易用性）
4) 性能测试
大数据测试

测试类型划分：

按照先后顺序来划分：单元测试、集成测试、系统测试、验收测试（alpha,beta）
按照测试软件内部是否可见：白盒测试、灰盒测试、黑盒测试
按照测试时是否运行这个软件：静态测试、动态测试
按照是否使用到工具：手动测试，自动测试

按先后顺序划分

单元测试

  针对每一个方法代码测试，一般有后端工程师自测，或由专门的`白盒测试`人员测试

集成测试

  对集成的子系统进行测试，一部分代码不可见，属于`灰盒测试`

系统测试
将已经集成好的系统与计算机硬件、外设、网络等其他元素结合在一起，模拟实际使用环境下的测试工作，属于黑盒测试。
```
 系统测试划分：
 功能测试、性能测试、兼容性测试、易用性测试、安装卸载测试、文档测试
```
验收测试

属于黑盒测试，其主要目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务
非正式验收测试：Alpha 测试（α测试）、Beta 测试（β测试）
1) Alpha 测试（α测试）:由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。俗称内测。
2) Beta 测试（β测试）:开发给一部分用户进行真实使用场景测试，并要求用户报告异常情况、提出批评意见，然后软件开发公司再对β版本进行改错和完善。俗称公测。
正式验收测试：有正规的测试过程，需要制定测试计划、定义测试方案、选择测试用例，进行测试，结果提交。着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面

测试环境

常见测试环境

常用测试环境

本地开发环境（Local Development Environment/ LDE）
单元测试环境（Unit Testing Environment/ UTE）
集成测试环境（Integration Testing Environment / ITE）
系统测试环境（System Testing Environment/STE）
用户验收测试（UAT）环境（User Acceptance Testing Environment）
性能测试环境（Performance Testing Environment）
预生产环境（Pre-production Environment）
FAT（工厂验收测试）环境（Factory Acceptance Testing Environment）
SIT（系统集成测试）环境（System Integration Testing Environment）
沙箱测试环境（Sandbox Testing Environment）
————————————————
以下是根据软件开发生命周期的测试环境先后顺序，以及它们所处的阶段和测试人员在每个阶段中的职责：
本地开发环境（LDE）：
- 阶段：开发阶段
- 测试人员职责：在此阶段，测试人员的职责通常较小，可能包括协助开发人员理解测试需求和提供测试用例。
单元测试环境（UTE）：
- 阶段：开发阶段
- 测试人员职责：开发人员通常会编写和执行单元测试，但测试人员可能需要协助编写测试用例，确保测试的全面性。
集成测试环境（ITE）：
- 阶段：集成阶段
- 测试人员职责：测试人员在此阶段会执行集成测试，确保不同模块或服务之间的交互符合预期。
SIT（系统集成测试）环境：
- 阶段：系统集成阶段
- 测试人员职责：测试人员会执行系统集成测试，验证系统各部分的集成是否成功，并检查系统级的功能。
系统测试环境（STE）：
- 阶段：系统测试阶段
- 测试人员职责：测试人员进行全面的系统测试，包括功能测试、接口测试、性能测试等，确保系统的质量。
沙箱测试环境（Sandbox Testing Environment）：
- 阶段：验证阶段
- 测试人员职责：测试人员在此环境中进行实验性测试，可能包括探索性测试、安全测试等。
性能测试环境（Performance Testing Environment）：
- 阶段：性能测试阶段
- 测试人员职责：测试人员专门进行性能测试，评估系统的响应时间、负载能力、资源使用等。
预生产环境（Pre-production Environment）：
- 阶段：预部署阶段
- 测试人员职责：测试人员在此环境中进行最终验证，确保生产部署前系统一切正常。
用户验收测试（UAT）环境：
- 阶段：用户验收阶段
- 测试人员职责：测试人员支持用户进行验收测试，可能包括协助用户理解测试用例和记录测试结果。
FAT（工厂验收测试）环境：
- 阶段：验收阶段
- 测试人员职责：在某些项目中，测试人员可能会参与FAT，确保供应商提供的系统满足要求。
性能测试环境（Performance Testing Environment）：
- 阶段：性能测试阶段（如果单独设置）
- 测试人员职责：与上述性能测试阶段的职责相同。

请注意，性能测试环境在列表中出现了两次，这可能是因为在某些情况下，性能测试会在系统测试阶段之后进行，而在其他情况下，它可能被整合到系统测试中。

这个顺序并不是固定不变的，不同的组织和项目可能会有不同的流程。此外，测试人员的职责也可能根据项目的具体情况和组织结构有所不同。

SIT测试环境、 UAT测试环境、准生产环境
SIT测试环境：（System Integration Testing Environment，系统集成测试环境）是用于进行系统集成测试的环境。在此环境中，不同的组件、模块或系统被整合在一起进行测试，以验证它们在实际运行时是否能够相互协调和正确工作。SIT测试环境通常模拟真实的生产环境，并提供各种必要的资源和工具来执行测试活动，例如模拟数据、测试工具、错误日志等。通过SIT测试环境，可以发现和解决不同组件之间的集成问题，确保整个系统的功能和性能正常。
UAT测试环境：（User Acceptance Testing Environment，用户验收测试环境）是用于进行用户验收测试的环境。在这个阶段，最终用户将对已构建的系统进行测试，以确定其是否符合需求和预期，并决定是否接受发布。UAT测试环境通常在项目开发的后期建立，提供给用户进行模拟生产环境下的测试。在UAT测试环境中，用户可以模拟真实的使用场景，检查系统的功能、易用性、性能等方面，并提供反馈和建议。UAT测试环境的目标是确保系统满足用户需求，并为用户提供一个验证系统的机会。
准生产环境：是指与生产环境相似或接近的一个环境，用于进行最终的测试和验证。准生产环境用来测试在产品发布之前，系统在真实生产环境下的性能、稳定性等方面。通过在准生产环境中进行测试，可以模拟真实的生产环境情况，并进一步评估系统在实际运行环境下的表现。对于复杂的系统或关键业务线上发布，准生产环境的使用有

软件测试的原则

所有的软件测试都应追溯到用户需求。
尽早地和不断地进行软件测试。
完全测试是不可能的，测试需要终止。
测试无法显示软件潜在的缺陷。
充分注意测试中的群集现象（二八法则）。
尽量避免测试的随意性。
程序员应避免检查自己的程序。
测试用例应包括合理的输入条件和不合理的输入条件。
应当彻底检查每个测试的执行结果。
妥善保存测试相关的文档及数据，为管理提供依据，为维护提供方便。

提高用例覆盖度

充分了解需求
使用xmind 提取需求中测试点
选择正确的方法设计用例
需要做规范的用例评审

软件测试的基本流程

参与需求评审，针对需求提取测试思路，提出相关建议

写测试计划（任务分配-按模块、时间节点、准入准出标准、测试重点，测试范围，风险评估）

 准入标准：
     ① 测试系统版本稳定
     ② 测试用例、代码、脚本以准备完毕
     ③ 测试环境完成
     ④ 冒烟测试完成
 准出标准：
     ①用例覆盖100%
     ②缺陷遗留率达标
     ③回归测试执行完毕
     ④需求100%覆盖

设计测试方案（具体实施方法以及合适的测试策略，测试方法）
需求分解
编写测试用例（编号、标题~）
组织用例评审（组织者-测试工程师、参与者-开发和测试经历以及、提议（覆盖代码、覆盖需求））
每天下课回宿舍的路，没有什么故事。
1) 安装JDK,配置其环境变量
2) 在Linux系统安装tomcat,配置其环境变量
3) 安装mysql数据库，启动mysql服务
4) 连上数据库服务器，执行项目sql脚本
5) 将项目代码包（war或jar包）
6) 搭建测试环境（java项目为例）
搭建测试环境
执行冒烟测试（根据实际情况，核心业务流程的用例，大概20%，保证核心功能走动通）
小版本可省略
冒烟测试要通过80%~90%，才能通过，后才能SIT环境下执行第一轮功能测试
执行测试用例
缺陷跟踪管理
回归测试
你们怎么做回归测试？（你们回归测试的策略是什么？）
全面回归测试
选择回归测试
指标法回归测试
自动化回归测试（覆盖率：80% ）

编写脚本运行，自动化测试，反复进行自动化测试
自动化：
1) 自动化不能完全代替人工测试，首先需要完成人工测试，确保主流程没有明显bug，才能编写自动化脚本
2) 手工测试，提升在于用例的提升和业务的理解上
3) 需求变动大、变更频繁、时间比较急的项目不适合自动化测试
4) 自动化分类
```
①web自动化（python+selenium-3.14.1+pytest+POM）---第三方包selenium +POM
②app自动化（python+appium+pytest+POM）少，雷电模拟器
③接口自动化（python+request+pytest）
④单元测试（白盒测试）
```
UAT 验收测试
又需求提出甲方测试，内侧（内部人员测试，在公司环境）或者公测（外部环境）
上线后，总结编写测试报告（用例执行报表统计，缺陷分布报表，测试软件质量评估，遗留缺陷说明）