软件测试模块有几个 如何为功能模块绘制数据流图 – 高级软件测试之路 （9）。

Q&A（22） 如何绘制功能模块的数据流图？

背景

小密圈的一位同学问：昨天经理给我一个任务，排序，要用一种方法：结构化分析法，但是我看不懂数据流图。为了说明这一点，系统中有一个很大的 query order 模块，它细分了各种 order 的 query 模块。如何绘制数据流图，同时也是一个模块的数据流图？

[你问]。

如何绘制功能模块的数据流图？

[我回答]。

[基本概念]。

结构化方法是一种强调开发方法的结构合理性和正在开发的软件的结构合理性的方法。

结构是指系统的各个组件之间互连和交互的框架。结构化开发方法提出了一套提高软件结构合理性的标准，如分解和抽象、模块独立性、信息隐藏等。它为软件生命周期的不同阶段提供了结构化分析 （SA） 和结构化编程 （SP） 等方法。

数据流图：简称DFD，它从数据传输和处理的角度，以图形方式表示系统的逻辑功能、数据在系统中的逻辑流向和逻辑转换过程，是结构化系统分析方法的主要表达工具和用来表示软件模型的图形化方法。

在结构化开发方法中，数据流图是需求分析阶段的结果。

结构化分析方法

以 order 查询模块为例：

1. 顶层数据流图：用户在前端页面输入查询条件，系统根据查询条件搜索对应的订单数据，返回给前端展示给用户。

顶层视图

2. 第 0 层数据流图：将前端的查询请求发送到服务器，现在在缓存中查询服务器，如果查询不到，则再次查询

第 0 层图

3. 第 1 层数据流图：根据不同的查询条件：订单号、订单日期、订单金额，从数据库中查询对应的订单，并将订单信息输出到服务器。

1 层视图

结构化数据流图的描述

1. 直角框，代表数据的源或终点，是软件系统外部环境中的实体（包括人员、组织或其他软件系统），统称为外部实体。通常，它只出现在数据流图的顶层图中;

2. 箭头，代表数据流，是系统内部数据传输的路径，因此它由一组固定的数据组成。由于数据流是流动数据，因此必须有一个流向。除了带有数据存储的数据流外，数据流的其余部分应使用名词命名;

3. 圆角框，代表处理，是数据处理，对数据流执行某些操作或转换。每个处理还应该有一个名称，通常是一个动词短语，以简洁地描述所完成的处理。在分层数据流图中，还应对转换进行编号。如果 0 层图的数字是 1 和 2，那么 1 层图的数字应该是 1.1 和 2.1;

4. 右侧打开的框代表数据存储，指的是临时保存的数据，可以是数据库文件或任何形式的数据组织;

Q&A （23） 软件测试和质量管理是一回事吗？

背景

随着许多软件公司规模的扩大和市场需求的正规化，越来越多的公司会在招聘岗位上设立「质量管理」或「质量保证」的职位，这让做测试的同学们感到有些困惑。那么，“质量管理”到底是什么呢？

[你问]。

软件测试和质量管理是一回事吗？

[我回答]。

1. 基本概念：

软件测试是验证软件的逻辑是否正确、功能是否齐全、系统是否安全、质量是否可靠的过程。软件测试的经典定义是在指定条件下运行程序，以发现程序错误，衡量软件的质量，并评估其是否满足设计要求的过程。

质量管理是指所有管理职能部门确定质量方针、目标和责任，并通过质量体系中的质量规划、质量控制、质量保证和质量改进来实现这些政策、目标和责任的所有活动。它还解释了质量管理是各级管理者的责任，但必须由最高领导推动，实施涉及单位的所有成员。在质量管理活动中，必须考虑经济因素。

2. 属性比较：

1） 类型

“软件测试”是一种技术型职位，如软件测试工程、自动化测试工程等，而“质量管理”是一种管理型职位，如QA（质量保证）、QC（质量控制）、QM（质量经理）、QE（质量工程师）。

2） 面向对象

“软件测试”是针对产品的，而“质量管理”是针对流程的。

3） 生命周期

“软件测试”贯穿于整个产品开发生命周期中（狭义上，它存在于“编码”之后）。“质量管理”是贯穿整个公司的过程体系，存在于公司的各个部门，软件测试只是其中一个环节。

4） 强调

“软件检测”强调事后通过相应的技术工具对产品进行检验，从而保证质量，而“质量管理”强调与产品研发相关的各个环节的工艺规范约束和检查，以提前预防问题，保证质量。

5） 组织架构

“软件测试部”与“研发部”和“项目管理部”一起，在整个项目过程中形成三管齐下的趋势，直接向技术总监汇报，而“质量管理部”通常是公司级部门，与任何部门都没有隶属关系，直接向公司管理层汇报。

3. 个人补充：

1）质量管理体系是一个管理体系过程，也可以说是一种方法论，它采用了PDCA（戴明环）的核心基本方法，对于大多数领域的产品质量管理都是可用和有效的;

2）我以前在公司做过 2 年的内部审计，简单来说，无论是 ISO 9000（国际标准质量管理）还是 CMMI（软件能力成熟度集成模型），要做什么其实都“很简单”：

a） 谈论你正在做的过程;

b） 按照你描述的过程做事;

c） 记录您的工作和工作;

d） 检查您的工作和流程;

e） 根据检查的问题，不断改进和实践;

3）在质量管理体系中，软件测试部门其实可以起到连接前下者的作用，市场/客服部门可以反馈现网问题，经过测试和统计分析后，找到可以防止问题再次发生的改进点，然后交给QA（质量保证工程师）推动实施和检查， 在质量管理体系中形成一个小的闭环;

Q&A （24） 如何区分测试报告和质量报告？

背景

前天，有同学问我一个基本问题，软件测试报告和回归测试报告有什么区别？测试规则是什么？简单来说，软件测试报告可以理解为一个通用术语，回归测试报告只是子项之一。测试规则，按照我的理解，其实就是测试计划中具体的测试策略和步骤，用来做执行参考，如果放进测试报告里，应该代表测试的执行步骤和细节。在实际项目中，真的很容易混淆和混淆“检测报告”和“质量报告”。

[你问]。

我应该如何区分测试报告和质量报告？

[我回答]。

如果把软件测试报告定义为一个狭义的报告名称，那么就是每个项目完成所有测试，准备上线时，测试部门出具的测试报告，运维部门以此作为上线活动的开始，我之前的公司就是这种情况， 美国的发布经理没有收到测试部门出具的测试发布报告，她不会发布正式的工程发布报告。

回顾性测试报告其实可以理解为每个测试包的一对一回归测试总结，在很多公司，包括我之前的这家，其实是每天项目报告的一部分，并没有单独出具报告。

言归正传，我想问您，您能区分一下检测报告和质量报告吗？你知道如何区分它们吗？

你可以告诉我，当然，你能分辨出区别，毕竟你已经在这个项目上工作了这么多年。

但是如果我真的让你写一份测试报告，也许你不会那么清楚，你可能会详细列出所有的测试环节、步骤、方法，所有发现的缺陷，以及缺陷的原因和分析，每个环节遇到的问题，甚至你会列出由于需求测试时间的延迟而导致的自检质量开发延迟的问题， 等等把测试数据和问题分析混在一起，散布几十页，这是常见的。“美观”和“实质性”的测试报告。

我不去评判这种报道是对是错，因为我一直认为，很多事情都没有明确的对错，只有适用于当下的情况才有。

让我先谈谈测试报告和质量报告之间的区别，然后让我们回过头来看看上面的报告是否合适。

1. 报告的读取对象决定了两种报告之间的本质区别：

测试报告主要由负责产品发布的经理阅读，在我之前的公司，职称是Release Manager，阅读这份报告的目的是获取对应版本的质量，是达到了release、Pass、Faile还是Pass with Risk的标准， 我们做了哪些测试，以及当前未解决的 bug 有多少，已知问题是什么等等，当然，他还需要从这份报告中知道这个版本有什么需求和变化;

质量报告主要由负责产品研发的经理阅读软件测试模块有几个，在一些大型企业中，还有一个岗位的人员会阅读这份报告，也就是EPG（流程改进团队），他们的目的是阅读这份报告，从问题清单中找出所有可以改进的要点并进行原因分析， 可能是过程，也可能是技术方法，当然也可能是人的问题，总之，他们就是想通过这份报告中的问题找到需要改进的地方，然后有计划地、循序渐进地改进它。

让我们回到前面提到的 “混合” 报告，你现在应该能够告诉我它是否是一份好的报告，对吧？

对于熟悉发布要求和更改的产品开发经理或 EPG（流程改进团队），或者只关注整个开发流程而不关注产品本身，您会在报告中花费大量时间列出需求和更改，这没有意义。

对于发布经理，我只想让你告诉我目前的质量能不能发布，其他问题是你研发流程或者研发团队的问题，我不在乎（如果从产品研发团队的经理的角度来看软件测试模块有几个，那些研发流程或者研发团队的问题其实是“丑陋的”， 那么你认为它应该被 “公开” 吗？）

2. 报表的编译器角色决定了两个报表之间的直观差异：

测试报告由测试经理或测试项目负责人撰写;

质量报告由 QA 撰写，在 QA 也由测试经理或测试负责人撰写的公司中（我之前工作的外国公司将测试和 QA 的职责合并到一个职位上，称为 QA）。

3. 最后，我想列出一些我认为在两份报告中更重要的项目，但它们可以根据当地情况进行调整，而且并非所有项目都是强制性的。

检测报告：

1. 版本信息：包括所有已发布组件的名称和版本号;

2. 依赖性：所有组件之间的依赖性，无论是强依赖还是弱依赖，如果有依赖性，都需要说明上线的部署顺序和原因，以免出现问题;

3. 测试环境配置：包括服务器的系统版本、中间件的版本、数据库的版本、客户端的浏览器类型/版本、操作系统的类型等;

4. 完成测试的范围、类型和方法，包括结果，如果完成了性能测试，则附上性能测试结果，如果完成了安全测试，则附上应用程序 Scan（一种安全扫描工具）的扫描结果，如果执行了手动用例，则附上用例的实现， 等。;

5. 测试结论：版本发布的标准是什么？该版本是否根据标准准备好发布，如果没有，为什么？如果可以带风险释放，那么风险是什么？

6. 已知问题列表：截至版本发布日期，当前版本中还有哪些未修复的剩余缺陷;

质量报告：

1、同类型项目的历史质量数据对比;

2. 当前版本的质量期望;

3、统计分析后的缺陷分布图和缺陷修复曲线图;

4. 针对过程中遇到的问题进行 3W 分析：

4.1 问题是什么？问题是什么？

4.2 根本原因是什么？根本原因是什么？

4,3 解决方案是什么？解决方案是什么？

5. 总结分析当前版本的质量问题（数据和过程），并提出改进建议;