自动遍历测试参数(参数化数据驱动)

一、软件测试的流程是什么

软件测试的基本工作流程，大致梳理一遍。

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

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

第一、把用户需求转化为功能需求：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、重视不易重现的缺陷场景，可能是一个bug。

7、执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。

8、建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现网。

9、如有需要，建议保留测试结果，结果可视。也便于不同版本间的测试结果对比。

10、已确认问题需及时按照问题单提单要求（规范和缺陷定级）提单。

11、跟踪问题单修复情况并回归验证问题单。

12、每轮次测试结束，find一下是否有core文件产生。

13、测试结束，将最终测试用例文档上传到归档目录，实现用例重用。

以上是真对一般的软件测试流程，如果是自动化测试得话，应该还有根据测试用例进行脚本编写，运行脚本等。

在测试用例执行过程中，包含了：功能测试阶段、缺陷跟踪阶段（bug tracking）、回归测试阶段、系统测试阶段、验收测试阶段等（系统已满足测试条件（开发完成），按照已经评审过的测试用例依次执行，执行过程中及时记录问题，将问题及时提交到QC上，要跟踪缺陷。等开发修复后进行回归测试，确认修复后关闭缺陷，如果说该问题要更新而生产上未进行验证，就把缺陷状态改为生产未验证。对有异议的缺陷经甲方、开发和测试三方进行沟通讨论，由甲方最终确定处理方式。在测试过程中也会碰到对需求有异议，会反馈给经理，由经理与甲方沟通来对该需求提出一些可行性建议，最终还是由甲方来确定具体根据各个公司的业务流程而不一样）。

最后已达到准出要求的根据测试情况写测试报告，对整个测试过程和版本的质量做一个评估

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

测试报告的内容可以总结为以下目录：

首页

引言（目的、背景、缩略语、参考文献）

测试概要(测试方法、范围、测试环境、工具)

测试结果与缺陷分析（功能、性能）

测试结论与建议（项目概况、测试时间测试情况、结论性能汇总）

附录（缺陷统计）

至此并不算最后的完结工作，软件测试还包含了线上功能检查、当前版本问题反馈以及改进建议等。这样才算是软件测试最终结束，软件测试是贯穿于整个软件生命周期的。

二、参数化数据驱动

在自动化测试中，经常会遇到如下场景：

这里只是随意找了两个典型的例子，相信大家都有遇到过很多类似的场景。总结下来，就是在我们的自动化测试脚本中存在参数，并且我们需要采用不同的参数去运行。

经过概括，参数基本上分为两种类型：

然后，对于参数而言，我们可能具有一个参数列表，在脚本运行时需要按照不同的规则去取值，例如顺序取值、随机取值、循环取值等等。

这就是典型的参数化和数据驱动。

如需对某测试用例（testcase）实现参数化数据驱动，需要使用 Parameters函数，定义参数名称并指定数据源取值方式。

参数名称的定义分为两种情况：

数据源指定支持三种方式：

三种方式可根据实际项目需求进行灵活选择，同时支持多种方式的组合使用。假如测试用例中定义了多个参数，那么测试用例在运行时会对参数进行笛卡尔积组合，覆盖所有参数组合情况。

使用方式概览如下：

将参数名称定义和数据源指定方式进行组合，共有 6种形式。现分别针对每一类情况进行详细说明。

对于参数列表比较小的情况，最简单的方式是直接在 pytest中指定参数列表内容。

例如，对于独立参数 password，参数列表为 ['aA123456','A123456','']，那么就可以按照如下方式进行配置：

进行该配置后，测试用例在运行时就会对 password实现数据驱动，即分别使用 ['aA123456','A123456','']三个值运行测试用例。运行日志如下所示：

可以看出，测试用例总共运行了 3次，并且每次运行时都是采用的不同 password。

对于已有参数列表，并且数据量比较大的情况，比较适合的方式是将参数列表值存储在 CSV数据文件中。

对于 CSV数据文件，需要遵循如下几项约定的规则：

例如，password的参数取值为"aA123456","A123456",""，那么我们就可以创建 password.csv，并且在文件中按照如下形式进行描述。

然后在 pytest测试用例文件中，就可以通过内置的 Parameterize（可简写为 P）函数引用 CSV文件。

假设项目的根目录下有 data文件夹，password.csv位于其中，那么 password.csv的引用描述如下：

即 Parameters函数的参数（CSV文件路径）是相对于项目根目录的相对路径。当然，这里也可以使用 CSV文件在系统中的绝对路径，不过这样的话在项目路径变动时就会出现问题，因此推荐使用相对路径的形式。

对于没有现成参数列表，或者需要更灵活的方式动态生成参数的情况，可以通过在 debugtalk.py中自定义函数生成参数列表，并在 pytest引用自定义函数的方式。

例如，若需对 password进行参数化数据驱动，那么就可以在 debugtalk.py中定义一个函数，返回参数列表。

然后，在 pytest的 Parameters中就可以通过调用自定义函数的形式来指定数据源。

另外，通过函数的传参机制，还可以实现更灵活的参数生成功能，在调用函数时指定需要生成的参数个数。

对于具有关联性的多个参数，例如 username和 password，那么就可以按照如下方式进行配置：

进行该配置后，测试用例在运行时就会对 password和 error_code实现数据驱动，即分别使用

{"error_code":"0","password":"aA123456"}、

{"error_code":"3007","password":"A123456"}、

{"error_code":"3001","password":""}

运行 3次测试，并且保证参数值总是成对使用。

对于具有关联性的多个参数，例如 username和 password，那么就可以创建 username_password_errorCode.csv，并在文件中按照如下形式进行描述。

然后在 pytest测试用例文件中，就可以通过内置的 parameterize（可简写为 P）函数引用 CSV文件。

假设项目的根目录下有 data文件夹，username_password_errorCode.csv位于其中，那么 username_password_errorCode.csv的引用描述如下：

对于具有关联性的多个参数，实现方式也类似。

例如，在 debugtalk.py中定义函数 get_account，生成指定数量的账号密码参数列表。

那么在 pytest的 Parameters函数中就可以调用自定义函数生成指定数量的参数列表。

完成以上参数定义和数据源准备工作之后，参数化运行与普通测试用例的运行完全一致。

采用 hrun命令运行自动化测试：

采用 locusts命令运行性能测试：

区别在于，自动化测试时遍历一遍后会终止执行，性能测试时每个并发用户都会循环遍历所有参数。

三、测试脚本的基本信息

概述

更改目标软件时，需要对测试过程进行局部的可控制的变更。这将使得测试过程和测试脚本对目标软件的变化有更大的应变能力。例如，假设软件的登录部分已经改变。在遍历该登录部分的所有测试用例中，只有关于登录的测试过程和测试脚本需要进行改变。

测试脚本是针对一个测试过程的。一个测试过程往往需要众多的数据来测试。通过自动录制得到的脚本，所有的输入数据都是常数，是固定的。

如果需要使用一个测试脚本测试多组数据，就需要对脚本进行参数化，把固定的常数修改为来自数据源变量。