测试人员(工作流程、测试种类、测试手段、用例方法、bug等级划分、发现bug处理流程、软件生命周期)

目的：明确产品或者系统的功能需求，业务需求、以及非功能需求

需求分析：测试人员通读文档、理解需求背后的目标、确保需求是明确可测试的。

与相关人员沟通：如果文档中有不清晰或者模糊的，测试人员要及时与产品经理，开发人员，业务分析师等沟通，澄清问题。

需求变更管理：需求在开放过程中可能会变化，测试人员应该跟进更新需求的变更，确保测试计划和测试用例的及时更新。

产出：需求文档分析报告，记录需求中需要重点测试的功能点。

2.把需求转化为测试点

目的：将需求转化为具体的测试点，明确要测试的功能和场景

功能点提取：从需求文档中提出各个功能模块，并理解每个模块的功能实现。例如：一个用户注册功能可能涉及用户输入、校验、保存数据等操作。

非功能需求转化：关注性能、安全、易用性等。例如系统响应时间可能成为一个性能测试点。

产出：测试点列表，列出所有需要验证的功能和场景，并表明是否需要测试数据的支持。

3.把测试点转化为测试用例

目的：根据测试点，设计详细的设计用例，确保测试全面且覆盖全部需求

用例设计：

1.测试用例id、2.测试用例描述、3.（前提）准备条件、4.输入数据、5.操作步骤、预期结果、后置条件

ps：后置条件：测试完成后，是否要清理测试数据

正向测试和负向测试：测试用例设计时，要包括正常流程（正向设计）和异常流程（负向设计）。例如用户注册时，输入有效数据和无效数据分别测试。

边界值分析（主要用于测试数据的输入输出）：对于输入框，字段长度等。通常需要设计边界值设计用例，如最小值，最大值，超出范围的值。

自动化测试用例：如果是自动化测试，还要设计自动化脚本，标明哪些用例需要自动化测试。

产出：设计用例文档、测试用例的详细信息

4.用例评审

目的：确保测试用例的完整性、正确性，查漏补缺

用例自评：测试人员先检查一遍测试用例，确保所有需求都被覆盖，测试步骤清晰，预期结果明确

团队评审：组织团队进行内部评审，邀请产品经理、开发人员、其他测试人员参与。评审时重点检查以下方面

覆盖度：确保所有需求、功能、边界场景都被覆盖到

正确性：确保测试用例能够准确描述预期结果，避免设计错误的测试步骤

可执行性：测试用例是否具备可执行性，能否在没有依赖情况下进行

用例优化：有些测试场景可以合并，或者增加测试驱动的情况

产出：评审反馈，更新后的测试用例文档

5.执行测试用例

目的：按照测试用例进行实际的功能测试，验证软件是否符合需求

环境准备：确保测试环境已经准备好，包括硬件，软件，网络等资源。以及所需的数据库或者测试数据。

手动执行测试：测试人员根据测试用例进行手动测试，包括功能验证，UI检查、数据验证登。

自动化测试执行：测试人员自行自动化脚本，验证系统是否按照预期工作

通过：如果与预期结果一样则通过

失败:如果实际结果和预期不一致，需要提交bug并描述错误

产出：测试执行记录、测试结果截图、日志文件等

6.提交bug

目的：在测试过程发现缺陷并报告，协助开发修复

bug报告：测试人员在发现bug时候要详细记录下这个bug，详细包括如下

1.缺陷ID

2.缺陷描述：例如登录功能异常，无法使用正确的用户名和密码登录

3.重现步骤：详细的重现步骤，能够帮助开发人员快速复现问题

4.预期结果：正常情况下的预期结果

5.实际结果：系统表现出的实际性错误问题

6.环境信息：测试环境（操作系统、浏览器、版本等）

7.截图或者日志

缺陷跟踪：测试人员要跟踪这个bug，验证相关的缺陷是否已经修复，并重新执行测试用例

产出：缺陷报告、缺陷报告修复验证

7.测试报告

目的：总结测试工作，提供测试的整体视图，帮助决策者做出判断

测试覆盖率：报告中应该展示测试用例的覆盖情况，哪些功能和场景还没有被覆盖

缺陷统计：统计测试过程中发现的测试数量、验证级别、状态（修复、未修复）

测试总结：是否按照计划完成、发现了多少缺陷，影响如何、测试的通过率如何、是否有阻塞需要进一步解决

测试评估：测试过程的评估、测试的充分性、用例的覆盖度、测试环境的稳定性等。

建议：根据测试结果给出建议，例如加大覆盖度、改进自动化测试等。

产出：测试目标和范围、测试执行情况、测试结论、缺陷统计及影响评估

二、阶段性测试

阶段一、冒烟测试

对系统主流程的测试叫冒烟测试。冒烟测试由开发自测后转测试人员测。如果冒烟测试没有通过继续打回给开放重新自测。假设有100条测试用例，选取用例的5%-10%。

冒烟测试的优点：

(1)快速评估构建是否合格，提前发现致命的系统故障，避免浪费大量时间在已经不稳定的版本上。
(2)一般作为回归测试的前置步骤，帮助测试人员快速筛选是否继续深入测试。

阶段二、全量测试（系统集成测试）

对所有的用例进行100%的测试，系统测试和集成测试演变为系统集成测试，第一轮会发现一些bug，提交给对应的开放修复。

阶段三、回归测试

回归测试需要测试什么？

1.对提交的bug已经修复完成进行再次测试

2.新增的测试用例

3.回归与之前修复bug有相关联模块进行测试

三、测试种类

1.黑盒测试

测试人员负责黑盒测试，通过盒子的外部看不到内部的代码，测试的时候不需要关注内部的代码结构，只要测试盒子的外部功能没有问题即可。

2.灰盒测试（接口测试）

测试人员负责做的。盲测：快，效率高，经济实惠，盲测就是没有测试用例作为参考，全凭测试人员自己的理解测试，占比最大。

3.白盒测试（代码测试，单元测试）

白盒测试是开发人员做的，关注内部的代码结构。

白盒中最强的方法是路径覆盖法，最弱的方法是语句覆盖法

1、语句覆盖法
2、判断覆盖法
3、条件覆盖法
4、判定/条件覆盖法
5、组合覆盖法
6、路径覆盖法

四、测试手段进行分类

1.手工测试

2.自动化测试

五、测试的内容进行划分（重点）

1.功能测试

2.界面设计

3.易用性设计

4.安全设计

5.可移植性设计

6.兼容性设计

记：功安可兼易界

六、功能测试的用例方法有哪些？

介绍

常用方法：等价类划分法、边界值分析法、判定表法和状态转换法是功能测试中最常用的设计方法。它们适用广泛、系统化、易于实施，通常可以覆盖大多数常见的功能测试场景。
较少用方法：因果图法和错误推测法虽然也有其特定场景，但由于其复杂性和依赖测试人员经验的特点，应用场景相对较窄，因此不如前者常用。

1.等价类划分法

2.边界值分析法

3.判定表法

4.状态转换法

5.用户场景法

6.因果图法

7.错误推断法

七、典型的软件生命周期有哪些

瀑布模型、敏捷开发模型、迭代开放模型、增量开发模型、H模型、V模型、W模型

详细

1. 瀑布模型（Waterfall Model)

概述：瀑布模型是最传统的软件开发模型，强调阶段性和顺序性。每个阶段的完成都是后续阶段的前提，项目如同瀑布流动一样，严格按照线性流程执行。
主要特点：
每个阶段都有明确的目标和产出。
阶段之间没有重叠，严格按照顺序进行。
需求收集和设计完成后才能进入开发，开发后才能进行测试。
优点：
简单易理解，结构化、规范化。
易于管理和控制。
缺点：
不适应需求变化，难以灵活调整。
对于复杂的项目不太适合，尤其是在需求不确定的情况下。

2. 敏捷开发模型（Agile Model）

概述：敏捷开发强调快速迭代、小步前进、持续反馈、团队协作和客户参与。与瀑布模型不同，敏捷开发能够灵活应对需求变化，并通过频繁发布可工作的产品增量来适应动态变化的需求。
主要特点：
强调与客户的持续沟通和反馈。
每个开发周期（Sprint）通常持续1到4周，每个周期结束时交付一个功能完整的增量。
团队小而高效，跨职能团队协作。
优点：
高度灵活，能够快速响应变化。
更注重用户需求和价值，能够快速交付。
缺点：
对团队和项目管理的要求高。
需要不断的客户参与和反馈，可能导致需求的频繁变更。

3. 迭代开放模型（Iterative Development Model）

概述：迭代开发模型类似于敏捷开发，它强调通过一系列的迭代来逐步实现软件功能。每个迭代周期后，系统会有一个可工作的增量，并且会根据反馈调整下一迭代的目标和内容。
主要特点：
每个迭代周期都有一个具体的功能目标和交付成果。
每次迭代都包含分析、设计、编码和测试等环节。
项目不断调整方向，逐步完善系统。
优点：
灵活，能够快速响应变化。
每次迭代都有一个可工作的产品版本，能尽早获得反馈。
缺点：
如果管理不当，可能导致频繁变更需求，导致项目失控。

4. 增量开发模型（Incremental Development Model）

概述：增量开发模型将系统分为多个增量，每个增量都能实现部分功能。每次发布的增量都是一个独立的、可运行的部分，随着时间推移，整个系统逐渐完成。
主要特点：
软件分为多个独立的增量，每个增量实现部分功能。
每个增量的开发、测试、部署都相对独立，按优先级逐步交付。
每个增量后都能获得用户反馈，逐步改进系统。
优点：
可以提前交付部分功能，提前获得反馈。
灵活性较高，能够快速适应需求变化。
缺点：
系统架构可能需要在每个增量中进行调整。
初期增量的设计可能不够完整，后期可能需要频繁修改。

5. H模型（H-Model）

概述：H模型是一个较少见的模型，主要用于描述软件开发过程中的质量保证与测试活动。该模型将开发和测试过程交替进行，形成“开发-测试-开发-测试”的结构，形成一个类似字母“H”的形状。
主要特点：
在每个开发阶段后都有相应的测试阶段，开发和测试相辅相成。
开发和测试之间相互反馈，有助于提前发现和修复缺陷。
优点：
早期发现缺陷，避免在后期阶段积累大量问题。
强调质量控制，减少问题发生。
缺点：
可能导致开发进度与测试进度脱节。
实施时对资源的要求较高。

6. V模型（V-Model）

概述：V模型是一种扩展的瀑布模型，强调每个开发阶段后都有相应的验证和验证活动，即开发和测试并行。每个开发阶段的输出都会对应到一个测试阶段。
主要特点：
在开发的每个阶段后都进行验证和验证活动（例如，设计阶段后进行设计验证，编码阶段后进行单元测试）。
强调测试的重要性，确保开发的每个部分都经过验证。
优点：
质量控制较强，减少缺陷的产生。
清晰的开发和测试过程，适合需要严格质量要求的项目。
缺点：
对需求变化不够灵活。
在需求不完全明确的情况下，可能导致开发初期过多依赖假设。

7. W模型（W-Model）

概述：W模型是V模型的进一步扩展。它不仅强调开发和测试并行，还加入了“风险管理”的概念。每个阶段不仅考虑开发、测试的并行，还会考虑如何在项目的每个阶段进行风险评估和管理。
主要特点：
每个开发阶段不仅有对应的测试活动，还有专门的风险管理活动。
与V模型相比，W模型更加注重风险评估和控制。
优点：
更加全面的质量管理，关注项目风险。
增强了项目的可控性，适合复杂的项目。
缺点：
实施起来更加复杂，需要专门的风险管理人员。
不够灵活，对变化的适应能力较弱。

八、bug的等级划分

致命级别（L1）：系统崩溃，闪退，死循环，卡顿之后闪退
交易经济的损失，导致数据库数据丢失

严重级别（L2）：重要功能不能实现（微信没有实现聊天，发朋友圈等功能）

一般级别（L3）：例如：删除好友是没有提示，但是被删除方有提示

建议性或者易用性级别（L4）：界面的文字错误，登录位置体验感不好

九、测试人员发现bug的处理流程

1.测试人员在执行测试用例的时候发现了bug

2.在禅道bug处理工具提交报告（bug标题、描述、复现步骤、严重程度、优先级、环境信息、日志或者截图）

bug状态流转

3.指派给前端或者后端开发

4.开发人员修复完成后，测试人员验证修复，验证通过后关闭bug

支持作者和口令大全（获取各种资料）

vip文章：

https://blog.youkuaiyun.com/m0_52861000/category_12272616.html

bug文章大全

https://blog.youkuaiyun.com/m0_52861000/category_12215546.html

口令大全：

各种资料回复大全