测试的流程，jira工具的使用

目录：

1. 测试流程价值与体系
2. 测试计划
3. 业务架构分析思路
4. bug基本概念
5. bug处理流程
6. 测试总结
7. 业务架构分析工具plantuml
8. 测试流程管理jira系统-测试流程定制
9. 测试流程管理 jira 系统-Bug管理流程定制

1.测试流程价值与体系 

软件测试流程

• 完成软件测试工作的必要步骤

 测试流程价值

• 可以完成最佳测试方式的提炼和固化，提高测试效率
• 是平台化管理的基础
• 有助于更好的跨部门沟通

测试流程学习路线 

2.测试计划

测试计划作用

• 定义测试目标和范围：测试计划明确说明了测试的目标和范围，帮助团队了解需要测试的功能、特性和业务流程。它确保了测试团队和其他项目参与者对于测试的期望和目标的一致性。

• 提供测试策略和方法：测试计划描述了用于执行测试的策略和方法。它包括测试的种类、级别、技术，以及测试环境和工具的选择。测试计划还可以提供具体的测试活动和测试用例的计划，确保测试工作按照一定的计划进行。

• 分配测试资源和责任：根据测试计划，可以确定测试所需的资源，包括硬件、软件、人力和时间资源。测试计划还明确了每个测试活动的责任人和时间表，确保测试团队和其他团队成员之间的协调工作。

• 控制测试进展和风险：通过测试计划，可以监控和控制测试的进展情况。它可以指导测试团队按计划完成测试活动，并对测试结果进行评估和反馈。此外，测试计划还可以识别和管理测试过程中的风险和问题，以便及时采取纠正措施。

• 提供沟通和报告依据：测试计划为项目参与者提供了一份共同的文件，用于沟通测试策略、计划和进度。它可以作为测试团队与项目管理者、开发团队和其他利益相关者之间的沟通依据。此外，测试计划还为测试结果和问题报告提供了基础，确保测试活动的透明度和可跟踪性。

测试计划模板：

写一份高质量测试计划，需要包含那几个方面？

1. 引言和背景：提供项目的背景和目标，介绍测试的重要性以及测试计划的目的和范围。

2. 测试目标和策略：明确测试的目标，包括功能、性能、安全性等方面。定义测试策略，如测试覆盖范围、测试技术、测试环境和数据管理策略等。

3. 测试计划和时间表：详细规划测试活动的执行计划，包括测试阶段、测试任务和时间计划。确保测试工作按计划进行，以满足项目的进度需求。

4. 测试资源和责任：确定测试所需的资源，包括硬件、软件、设备和人员。明确测试团队的组成、职责和贡献，确保资源分配和团队合作的有效性。

5. 测试环境和工具：描述测试所需的环境，包括硬件、软件和网络配置。提供测试工具的选择和使用情况，如自动化测试工具、性能测试工具等。

6. 测试用例和数据：定义测试用例编写和管理的方法，包括用例设计、执行和维护。说明测试数据的收集、准备和管理，以确保测试场景的覆盖和有效性。

7. 测试执行和报告：描述测试执行过程，包括测试活动的启动、执行和监控。说明测试结果和缺陷管理的方法，以及测试报告的格式和频率。

8. 风险管理和质量评估：识别、评估和管理测试过程中的风险和问题。定义风险管理计划，包括风险识别、响应策略和监控措施。提供测试质量评估方法和指标，以衡量测试的质量和效果。

9. 交付和验收标准：确定测试交付物和验收标准，以便项目方和利益相关者评估测试的完成情况和质量。

10. 审核和批准：确保测试计划的质量和可行性，进行内部审核和相关方的评审。获得项目负责人的批准和支持，以确保计划的有效执行。

测试计划模版

测试计划编写要点

• 5W + H 原则
• why：为什么要进行这些测试
• what：测试哪些方面，不同阶段的工作内容
• when：测试不同阶段的起止时间
• where：相应文档，缺陷的存放位置，测试环境等
• who：项目有关人员组成，安排哪些测试人员进行测试
• how：如何去做，使用哪些测试工具以及测试方法进行测试

3. 业务架构分析思路

业务架构：

业务模块之间的关系，具体来说，业务架构可以涉及以下方面：

1. 业务流程：业务流程描述了组织内不同业务活动的执行顺序和相互作用。它们描述了业务活动如何组织、整合和协调以实现特定的业务目标。

2. 业务功能：业务功能指的是完成某个特定业务任务所需的功能或模块。例如，一个电子商务系统的业务功能可能包括产品管理、订单管理、支付处理等。

3. 业务关系：业务关系描述了不同业务模块之间的相互关系和依赖。这些关系可以是顺序的、并行的、层次的或协作的。例如，订单管理模块可能依赖于产品管理模块来获取产品信息。

4. 数据流和信息交换：业务模块之间的关系通常涉及数据流和信息交换。数据流描述了在不同业务模块之间传输的数据，信息交换描述了不同业务模块之间的通信和协作方式。

5. 业务规则和策略：业务架构还包括定义业务规则和策略的部分。这些规则和策略定义了业务模块的行为和执行方式，可以帮助确保业务流程的执行和业务目标的实现。

技术架构：

技术组件之间的关系与通讯方式，它描述了系统中不同技术组件之间的交互方式，以满足业务需求并支持系统的功能和性能。

1. 技术组件：技术组件是构成系统的基本单元，可以是软件模块、硬件设备、网络设备或第三方服务等。每个技术组件承担特定的功能，并与其他组件进行交互。

2. 关系和依赖：技术组件之间可以有不同类型的关系和依赖。这些关系可以是层次关系（例如客户端/服务器模型），也可以是模块之间的调用关系或数据依赖关系。了解和管理这些关系可以确保系统的正确运行和协调。

3. 通信方式：技术组件之间的通信方式描述了它们之间如何交换数据和信息。这可以通过不同的通信协议、接口或格式实现。例如，组件可以通过 API 调用、消息传递或共享数据库等方式进行通信。

4. 扩展和集成：技术架构还要考虑系统的可扩展性和集成性。系统应能够方便地扩展以满足未来的业务需求，同时能够与其他系统或服务进行无缝集成。

5. 可靠性和性能：技术架构应考虑系统的可靠性和性能要求。这可能包括负载均衡、高可用性、容错机制等，以确保系统在高压力和异常情况下的稳定运行。

组织架构：

协作团队的组织关系，它描述了不同团队、部门或岗位之间的职责、权责和沟通渠道，帮助组织有效地协调和管理工作。

1. 层级结构：组织架构描述了组织中的层级关系。这包括高层领导、中层管理和基层员工之间的层级关系。层级结构可以决定决策权、授权和责任的分配，以及信息流向和沟通方式。

2. 部门或团队：组织架构确定了不同部门或团队的职能和责任。各个部门或团队在组织中担负不同的任务和目标，并具有相应的权力和资源。例如，一个软件开发团队可能专注于产品开发，而市场营销团队则负责推广和销售。

3. 跨功能协作：组织架构描述了不同团队之间的协作关系。这包括跨部门或跨团队的信息共享、资源协调和协作流程。有效的跨功能协作可以提高组织的效率和绩效。

4. 管理层级：组织架构确定了各个层级的管理职能和责任。管理层负责决策、协调和管理团队，以确保组织的目标和战略得以实现。管理层级的设计和配置对于组织的成功至关重要。

5. 沟通和协调：组织架构还包括决定沟通渠道和协调机制的部分。有效的沟通和协调可以确保信息流畅和问题被及时解决。沟通方式可以通过会议、报告、邮件、团队协作工具等进行。

数据架构：

数据的关联关系，

1. 数据结构：数据架构定义了数据的组织结构。这包括数据实体（例如表、文件、文档），数据属性（例如字段、列、属性）以及数据之间的关系（例如主键、外键）等。数据结构的设计应该能够满足系统的需求，并支持有效的数据存储和检索。

2. 数据库设计：数据架构可以涉及数据库的设计和构建。这包括确定数据库的表结构、数据模型、索引和约束等。数据库设计应该能够实现数据的一致性、完整性和安全性。

3. 数据关联关系：数据架构描述了不同数据之间的关联关系和依赖关系。这可以通过主键-外键关联来实现，或是通过其他方式，如关系型数据库的关联表或非关系型数据库的嵌入式文档来实现。通过定义和管理数据的关联关系，可以确保数据的一致性和可靠性。

4. 数据访问：数据架构定义了数据的访问方式和机制。这可以包括数据查询语言（如SQL）、API接口或其他访问方式。数据架构还可以规定数据的安全性和权限控制，以确保只有经授权的用户可以访问和修改数据。

5. 数据集成：数据架构还涉及不同数据源之间的集成。通过数据集成，不同的数据源可以共享和交换数据，以满足系统的整体需求。数据集成可以通过ETL（抽取、转换、加载）流程、API集成或其他数据交换机制实现。

4.bug基本概念

Bug 定义

Bug 判定标准：

• 软件未达到客户需求文档的功能和性能
• 软件出现客户需求不能容忍的错误
• 软件的使用未能符合客户的习惯和工作环境
• 软件超出需求文档的范围

如果开发人员认为你提交的bug不是一个bug，这时候你怎么办? 

1. 重新评估：我会重新评估我提交的Bug，并与开发人员共享我观察到的问题的详细信息，并解释为什么我认为这是一个Bug。我会检查我提供的测试数据、步骤和相关日志，以确保我没有遗漏任何重要的细节。

2. 提供证据：如果可能的话，我会提供额外的证据来支持我的Bug报告。这可以包括截图、错误消息、日志文件或任何其他相关的信息，以帮助开发人员更好地理解问题。

3. 沟通和讨论：我会与开发人员沟通，详细讨论我对Bug的看法，并听取他们的意见。通过开放的对话，我们可以共同探讨问题的原因，并找到解决方案。

4. 遵循问题跟踪流程：如果开发人员仍然坚持认为这不是一个Bug，我会遵循组织或项目的问题跟踪流程。这可能包括将问题提交给负责Bug管理的人员或团队，以便进行更深入的分析和评估。

5. 寻求第三方意见：如果需要，我可以向其他团队成员、质量保证人员或领导层寻求第三方意见。他们可能能够提供更客观的观点，并帮助我们做出决策。

Bug 严重程度：

什么是bug?如何描述一个bug?_bug描述_阿瞒有我良计15的博客-CSDN博客

Bug 优先级：

严重程度和优先级的关系：

• 严重性程度高的软件缺陷具有较高的优先级：
  例子：如果一个电子商务平台的支付功能存在严重的安全漏洞，导致用户的支付信息被盗取，这是一个非常严重的缺陷。尽管其他较小的问题可能存在，但解决这个安全漏洞应该成为最高优先级，以保护用户的安全和保障平台的声誉。

• 严重性高的软件缺陷，优先级不一定高，甚至不需要处理：
  例子：在一个视频游戏中，某个特定的敌人形象在某些特殊条件下出现错误的颜色。虽然这可能是一个明显的Bug，但它对于玩家的游戏体验并没有明显的负面影响。在这种情况下，尽管严重性较高，但由于不会影响游戏的功能或玩法，所以优先级可能不会那么高。

• 严重性低的缺陷却需要及时处理，具有较高的优先级：
  例子：一个电子邮件客户端中，如果某个功能的图标显示不正确，这可能是一个严重性较低的问题。然而，如果该功能在公司内部被大量使用，并且显示不正确的图标可能导致用户误操作，这可能导致数据丢失或其他问题。在这种情况下，尽管严重性较低，但它需要及时处理以避免潜在的问题，因此优先级可能会提高。

5.bug处理流程

不同角色的对 Bug 的职责

项目经理

• 分配 Bug：当团队成员报告Bug时，项目经理将收集、审查和整理这些Bug。然后，项目经理会将每个Bug分配给适当的开发人员或团队来进行处理。分配时，项目经理会考虑开发人员的专长、资源可用性和项目时间表等因素，以确保Bug得到及时和高效的处理。
• 处理意见：在分配Bug给开发人员之前，项目经理会提供处理意见。这些意见可以包括对问题的初步分析、建议的解决方案或对可能造成的影响的评估。这些意见旨在帮助开发人员更好地理解和解决Bug，并为他们提供指导和支持。
• 定优先级：每个Bug都要根据其严重性和影响程度确定优先级。项目经理会评估Bug对软件功能、用户体验、系统稳定性、安全性等方面的影响。通常，严重性高、影响广泛以及导致系统崩溃或数据丢失的Bug会被赋予较高的优先级。而严重性较低、只影响特定条件下的Bug可能被赋予较低的优先级。在确定优先级时，项目经理还会考虑项目时间表、团队资源和客户需求等因素，以确保最有价值和关键的Bug得到优先处理。

开发人员

• 分析Bug：当开发人员收到一个Bug时，开发人员会仔细分析这个Bug并尽可能地重现它。开发人员会仔细阅读Bug报告中提供的详细信息，包括问题描述、复现步骤和相关的环境信息。开发人员会尝试重现Bug来确认它是否存在以及复现条件。通过对Bug的分析，开发人员能够更好地理解Bug的本质和影响，并确保开发人员有足够的背景知识来修改它。
• 修改Bug：在分析了Bug之后，开发人员会执行必要的修复工作来解决Bug。这可能涉及修改代码、修正配置问题、更新依赖项等等，以便消除触发Bug的根本原因。在进行修改之前，开发人员会确保理解了整个系统的工作原理，并尽可能遵循项目的编码和测试标准。在修改Bug时，开发人员会记录所做的更改，并确保开发人员的修改不会引入新的问题或副作用。

测试人员

• 提Bug：在执行测试任务时，如果测试人员发现软件中存在问题或异常，测试人员会及时记录并提供Bug反馈。测试人员会详细描述Bug的现象，包括复现步骤、触发条件和相关的环境信息。测试人员会尽可能提供截图、日志文件或其他支持材料，以便开发人员更好地理解和定位Bug。
• 反应 Bug的严重程度：当提供Bug反馈时，测试人员会对Bug的严重程度进行评估。这通常涉及对Bug的影响、紧急程度和重要性进行综合考虑。严重程度高的Bug可能会导致软件崩溃、数据丢失、安全漏洞或影响核心功能的故障。严重程度低的Bug可能会影响用户体验、功能的完整性或导致次要问题。通过评估Bug的严重程度，测试人员可以帮助项目经理和开发人员确定Bug的优先级，并决定是否需要进行紧急修复。
• 验证Bug：一旦开发人员对Bug进行修复并发布修复版本，测试人员会负责验证已解决的Bug。测试人员会重新执行相关的测试用例，以确保修改后的软件行为符合预期，并且原先的Bug已经被成功消除。测试人员会仔细检查相应的Bug报告和修复说明，确保Bug已经完全修复且相关功能没有引入新的问题。如果验证成功，测试人员会将Bug标记为已解决，并随时关注反馈中可能出现的新Bug。

测试组长

• 审核提交的Bug：当测试人员提交Bug时，测试组长会对每个Bug进行审核。测试组长会仔细阅读Bug报告，核对其中提供的详细信息和支持文件。测试组长会对Bug的描述、复现步骤、触发条件和环境信息进行验证，以确保提交的Bug符合项目的Bug报告标准。如果Bug的描述不清楚或缺少必要的支持材料，测试组长会与测试人员进行沟通，以补充和完善Bug报告。通过审核Bug，测试组长可以确保团队提交的问题是准确、详尽和可追溯的。
• 总结Bug情况：在项目进行过程中，测试组长会对所有提交的Bug进行汇总和总结。这包括分类、统计和分析Bug的数量、严重性、优先级以及修复时间等等。测试组长会生成Bug汇总报告，以便项目经理、开发人员和其他相关利益相关者了解当前软件质量状况以及需要解决的主要问题。在总结Bug情况时，测试组长会着重关注严重性较高、影响范围较广以及需紧急处理的Bug，并与开发人员和项目经理协商确定修复计划和优先级。

产品人员

• 解释需求：当收到一个需求时，产品人员的任务是仔细阅读并理解其背景、目标和功能需求。产品人员会与需求提出者进行沟通，以澄清任何不清楚或模糊的方面，并尽可能详细地了解业务需求和用户期望。产品人员会将需求细分为各个模块或功能，并创建相关的需求文档或用户故事来记录需求细节和预期的功能行为。通过解释需求，产品人员能够确保团队对于构建正确的功能有清晰的理解，并帮助开发人员和测试人员更好地进行任务分配和开发工作。
• 给出处理意见：在产品开发过程中，可能会遇到需求变更、设计决策或技术选择等问题。作为产品人员，产品人员会提供处理意见来解决这些问题。产品人员会综合考虑需求、用户体验、技术可行性和项目目标，并与开发人员、设计师和其他相关利益相关者进行讨论。产品人员会基于这些考虑因素给出建议，帮助团队做出明智的决策。产品人员的处理意见可能包括调整需求、重新优先级、修改设计方案或推荐适用的技术解决方案。通过提供处理意见，产品人员能够促进团队达成共识，并确保产品在满足需求的同时具备良好的用户体验和可行性。

Bug处理流程：

Bug处理意见：

1. 可修改：这是最常见的情况，表明发现的Bug是一个实际存在的问题，并且可以通过修改代码或进行其他必要的调整来解决该问题。开发人员应该分析和修复这个Bug。

2. 重复：如果报告的Bug与已存在的Bug报告相同，则可以将其标记为重复。这意味着问题已被确认，并且开发团队已在处理中。可以在备注中提及已有的重复Bug报告，并关闭当前的Bug报告。

3. 推迟处理：有时候，Bug可能与其他更紧急的问题相比不那么重要，或者需要更多的研究和评估。在这种情况下，可以将Bug标记为“推迟处理”。在备注中解释为什么需要推迟处理，并在可能的情况下提供一个预计的解决时间。

4. 设计问题：有时候Bug是由于软件的设计缺陷或问题导致的。在这种情况下，可以将Bug标记为“设计问题”。在备注中详细解释问题所在，并提供任何可能的解决方案或改进建议。

5. 不可复现：如果无法重现报告的Bug，并且无法找到足够的信息来诊断和解决它，可以将其标记为“不可复现”。在备注中记录尝试重现Bug的步骤和环境条件，并鼓励报告人员提供更多详细的信息，以帮助后续的调查和解决工作。

6. 不是问题：有时候报告的Bug实际上不是一个问题，或者根据软件的设计和需求，认为不需要进行修改。在这种情况下，可以将Bug标记为“不是问题”，并在备注中解释原因并提供解释。

7. 不修改：有时候Bug可能会被确认，但在某些情况下决定不进行修改。这可能是出于技术限制、业务需求或其他考虑。在这种情况下，可以将Bug标记为“不修改”，并在备注中提供解释。

Bug 报告

• 记录 Bug
• 跟踪 Bug
• 更好的和开发人员交流

Bug 报告模版（有专门的软件进行bug管理，后序讲解）

6.测试总结

 测试报告作用

• 把测试的过程和结果写成文档
• 对发现的问题和缺陷进行分析
• 为纠正软件的存在的质量问题提供依据
• 为软件验收和交付打下基础

测试报告模板测试报告 

总结要点

• 人力投入
• 用例覆盖情况
• Bug 的分类及数量统计
• 遗留 Bug 情况
• 测试风险
• 测试结论

7.业务架构分析工具plantuml

plantuml介绍

• UML：统一建模语言
• plantuml：第三方插件工具
• plantuml 官网：https://plantuml.com/zh/
• plantuml 在线绘图地址：

时序图

@startuml
skin rose
Alice -> Bob: Hi Bob
Bob --> Alice: Hi Alice

Alice -> Bob: how are you？
Alice <-- Bob: Fine，thanks.
@enduml

8.测试流程管理jira系统-测试流程定制

1.新建测试用例管理项目

2.新建问题类型·测试用例

3.测试用例管理项目关联刚刚创建的问题类型（测试用例） 

4.查看项目是否能够使用刚刚关联的问题类型

5.查看刚才新建的问题（刷新一下浏览器就可以）

6.如果我们想要搭建一套管理测试用例的流程，最起码需要有自己的工作流，域配置，界面

7.现在重新画一个测试用例管理流程

8.测试用例管理项目关联工作流

注意：这些操作会造成数据丢失，所以一定要尽早设计好模型

9.查看项目设置

10.查看刚才设计的工作流是否能正常运行：

11.新建测试用例界面

12.测试用例管理项目关联测试用例管理界面

13.看看刚才关联的页面是否管用

14.新建测试用例特有字段

15.挑选想要显示的字段

16.设置字段配置方案

 17.项目关联域配置方案

18.总结

• 新建问题类型
• 把问题类型添加到项目中
• 新建工作流
• 把工作流与问题类型关联
• 新建界面
• 界面与问题类型关联
• 新建字段
• 把字段添加到界面中
• 新建字段配置方案
• 配置域，并且添加到域配置方案中
• 关联域配置方案和问题类型

9.测试流程管理 jira 系统-Bug管理流程定制

1. 新建bug管理项目

2.新建bug管理项目的问题类型

2.为bug管理这个问题创建个好看的图标

3.新建Bug工作流 

4.新建bug界面

5.新建Bug特有字段

6.新建Bug域配置方案 

7.Bug管理项目设置 

  

 文章来源地址https://www.toymoban.com/news/detail-523185.html

到了这里，关于测试的流程，jira工具的使用的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！