软件测试工作流程的摘要和摘要

最近准备面试的新工作，因此请考虑整理软件测试的基本工作流程并进行粗略整理，以便您可以冷静地面对面试过程中面试官的测试工作如何进行的问题. .

首先，作为测试人员，您需要学习和理解业务并分析需求点

为什么测试人员要参加需求分析？也就是说，测试需求分析的目的是什么？

首先，将用户需求转换为功能需求

1）测试范围的进度量

2）测量处理分支

3）测量需求业务的场景

4）明确其功能对应的输入，处理和输出

5）将隐性需求转化为显性需求.

第二，阐明测试活动的五个要素:

测试要求是什么，决定如何测试，澄清测试时间，确定测试人员以及确定测试环境.

测试所需的技能，工具和相应的背景知识，测试过程中可能遇到的风险等. 测试要求必须尽可能详细和清楚，以避免测试遗漏和误解.

如何进行测试需求分析？

首先，确认功能（业务功能，辅助功能，数据约束，可用性要求，编辑约束，参数要求，许可要求，性能约束）:

1. 业务功能: 与用户的实际业务直接相关的功能或详细信息

2. 辅助功能: 协助完成某些功能或业务功能的详细信息，例如: 设置过滤条件

3. 数据约束: 功能的细节主要用于控制数据的显示范围以及执行该功能时数据之间的关系

4. 易用性要求: 产品中必须提供的功能细节，以方便某些细节的操作和使用，例如: 快捷键等.

5. 编辑约束: 函数的详细信息，执行函数时，对输入数据项的一些约束，例如: 只能输入数字等.

6. 参数要求: 功能细节，执行功能时，需要根据不同的参数设置进行不同处理的细节

7. 权限要求: 功能的详细信息，在功能执行过程中，根据不同的权限进行不同的处理，不包括直接限制功能的权限

8. 性能约束: 功能细节，执行功能时必须满足的性能要求

第二，场景分析

1. 考虑场景的调用者: 考虑调用每个场景提供的服务的外部模块或系统，并找出所有调用者. 必须考虑先决条件和约束. 每个呼叫都可以视为一个大型业务流程（通常，与外部交互的业务的错误率相对较高，需要重点关注）

2. 考虑系统内的各种场景: 要形成内部业务流程测量工作的基本程序，您需要分析每个场景，执行条件之间的约束关系，并组织各种业务流程图.

第三，挖掘隐藏需求

这需要积累测试工程师的经验:

1）常用或规定的业务流程

2）遍历各个业务流程分支

3）明确规定不可用的业务流程

4）没有明确规定但不应使用的业务流程

5）其他异常或不合规操作

以上是对如何进行测试需求分析的粗略解释. 在需求分析过程中，将编写整个测试计划. 在此过程中，有必要参考需求规范. 在此阶段，它通常由测试主管编写. 包括测试人员，测试时间，测试工具和测试方法.

接下来是测试用例设计:

测试用例是测试工作的核心模块. 在执行任何测试之前，您必须首先完成测试用例的编写. 测试用例是一种指导您执行测试并帮助证明软件功能或发现软件缺陷的描述. 设计并审查了用例. 在这个地方还有很多要讨论的话题，如何设计测试用例，如何设计测试方法，如何审查测试用例等.

如何设计测试用例

在编写测试用例之前，我们需要对项目的需求有清楚的了解，知道要测试什么，以什么顺序进行测试以及要了解哪些要求. 作为测试用例编写者，不仅要了解存在常见的测试用例，而且要编写一种方法，还需要了解被测软件的设计，功能规格，用户使用场景以及程序/模块的结构.

步骤:

1. 测试需求分析

从项目部门收到软件需求规范后，他们开始分析项目需求. 通过他们自己的分析和理解，他们将它们组织到测试需求中，并清楚地分析了测试对象具有的功能. 弄清测试集用例与测试用例中需求之间的关系，即一个或多个测试用例集与一个测试需求相对应.

2. 业务流程分析

在分析了需求之后，阐明了每个功能的业务处理流程，业务的不同功能点的组合以及项目的隐含需求. 如果是复杂的测试用例设计，请首先绘制软件业务流程. 从业务流程中，应获取以下信息:

A. 主要过程是什么？

B. 条件的替代过程是什么？

C. 数据流向是什么？

D. 关键的判断条件是什么？

3. 测试用例设计

完成上述两个步骤后，您可以设计测试用例. 对于功能测试用例，应尝试考虑边界，异常和性能的情况，以便发现更多隐藏的问题.

设计测试用例的常用方法:

1）等效类

2）边界值

3）因果关系图

4）决策表

5）状态转换

6）正交实验

7）场景方法

8）计算错误

（注意: 在编写测试用例时，我们应尽量不要使用有效的等效类，而应使用无效的等效类）

4. 撰写后对部门进行自我检查和内部审查

1）测试用例本身的描述是否清晰，语言是否准确；是否有歧义；

2）测试用例的内容是否完整，是否清楚地包含输入和预期输出的结果；测试步骤是否明确；

3）测试用例中使用的测试数据是否适当，准确；

4）测试用例是否具有启发性，是否可以灵活地指示软件测试工程师通过测试用例发现更多缺陷，而不是限制他们的思维；

5）是否考虑测试用例的执行效率. 对于重复的步骤，是否保证验证点相同？或测试用例的设计是否多余. 这些可能导致测试用例执行效率低下；

6）绘制软件需求跟踪矩阵，验证测试用例是否完全满足需求，并验证测试用例的覆盖范围；

7）测试测试用例是否完全符合软件要求. 这实际上很难实现. 考虑时间/成本关系，应根据具体情况.

5. 测试用例的更新和改进

在编写完成后，需要不断改进测试用例. 如果需求或新功能发生变化，则必须修改和更新测试用例. 同时，在测试过程中，发现对测试用例的考虑不充分，需要对测试用例进行修改和完善. 客户在交付和使用软件后报告的软件缺陷，这些缺陷是由测试用例中的漏洞引起的，需要改进测试用例.

首先构建测试环境，准备测试数据，进行预测，然后再通过测试，根据测试用例进入正式测试. 有效的测试执行可以最大化测试用例的价值. 因此，执行测试用例规范有助于更好地发现代码中的缺陷. 根据个人测试工作经验，良好的测试执行应包括以下内容:

1. 在执行测试过程中，评估测试执行时间不足，需要及时报告风险. 首先满足质量，然后安排日程.

2. 测试用例按优先级顺序执行，通常以基本，详细和异常顺序执行.

3. 未使用的用例，标记为已删除或无效的用例，需要说明原因.

4. 在执行过程中有疑问的测试用例（场景，操作步骤，检查点等）需要测试设计者加以澄清.

5. 测试执行需要逐一检查用例中描述的检查点，以避免遗漏.

6. 注意不容易重现的缺陷场景，这可能是一个错误.

7. 在实施过程中，发现以前的设计中缺少用例，需要对用例文档进行补充和验证.

8. 建议测试人员交叉执行重复的测试用例. 用例执行不受同一测试人员的影响. 为避免可能的缺陷遗漏到当前网络.

9. 如有必要，建议保留测试结果，结果可见. 为了比较不同版本之间的测试结果.

10. 识别出的问题需要根据提单的提单要求（规格和缺陷等级）及时开具.

11. 跟踪问题单的维修并返回以验证问题单.

12. 在每一轮测试结束时，找出是否生成了核心文件.

13. 在测试结束时，将最终的测试用例文档上传到归档目录，以实现对用例的重用.

以上是针对一般软件测试过程的. 如果是自动测试，则应基于测试用例编写脚本并运行脚本. 此处可能不会详述. 希望您可以在下面的评论中对其进行改进.

在测试用例执行期间，它包括: 功能测试阶段，错误跟踪阶段，回归测试阶段，系统测试阶段，验收测试阶段等（根据测试条件，系统已满足（开发完成））审查后的测试用例将按顺序执行，并在执行过程中及时记录问题，并将问题及时提交给质量控制部门，并跟踪缺陷，在开发和修复后进行回归进行测试以确认缺陷在维修后是否已关闭；如果需要更新和生产问题而未进行验证，则将缺陷状态更改为生产未验证；甲方，开发人员和开发人员就不可接受的缺陷进行了交流和讨论. 测试，甲方最终确定处理方法测量工作的基本程序，在测试过程中，还会有异议要求反馈给经理. 与甲方沟通，针对需求提出一些可行性建议. 最后，由甲方决定每个公司的具体流程，这是不同的.

测试报告是指将测试过程和结果写入文档，分析发现的问题和缺陷，为纠正软件的现有质量问题提供基础，并为软件验收和交付奠定基础. 测试报告是测试阶段的最终文档输出. 优秀的测试经理或测试人员应具有良好的文档编制能力. 详细的测试报告包含足够的信息，包括产品质量和测试过程的评估. 测试报告基于测试期间的数据收集以及最终测试结果的分析.

测试报告的内容可以归纳到以下目录:

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/shumachanpin/article-284237-1.html