测试用例

2020年测试部新人入职培训---测试基础

参考资料《http://172.16.111.6:8081/pages/viewpage.action?pageId=3280267》

# 课前活动

# 回顾答疑

《测试设计》作业完成情况总结分析，进行答疑

# 课程引入

我们在"软件测试基础理论"章节中已经讨论了测试类型和测试方法，我们按照 车轮图 ,对被测对象进行测试分析和测试设计，就能知道我们需要从哪些方面来进行测试，从而可以得到测试点。我们以发送电子邮件为例，根据车轮图分析出的测试点，如下图。

那么测试点等于测试用例吗？

# 课程内容

# 一、测试用例是什么

# 1 定义

测试用例（Test Case）是为了某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

# 二、测试点（测试条件）不等于测试用例

测试点（测试条件）≠测试用例，这是我们首先需要认识到的，测试用例是在测试点“加工”的基础上得到的。

首先把测试点“去重”（去掉重复的内容）、“合并”（把太细的测试点合并起来）、“细化”（把太泛的测试点说清楚、说具体），然后再确定各个测试点的测试条件、测试数据、测试结果。

# 1 去重

去重即去掉重复、冗余的内容、操作。

以“用户发送电子邮件测试点”为例，测试点1和测试点5都会测试到“正确发送电子邮件”，删除测试点1。

# 2 合并

把太细的、具有一定顺序性的测试点合并起来，提高测试执行效率。

假如第11条用例修改为 “用户在长时间（如 1天）处于网络故障的情况下，持续发送邮件。”

以“用户发送电子邮件测试点”为例，我们比较按照测试点6、7、11执行与按照测试点6、11、7执行会有哪些差异？如果我们在测试时没有注意到这点，执行完测试点6接着执行测试点7……到执行测试点11时，我们发现还要准备和测试点6一样的环境，做一些一样的操作。如果这种情况很多，就会严重影响测试效率，很明显后者可以最大限度地利用之前的测试环境。

# 3 细化

把太泛的测试点说清楚、说具体，避免遗漏关键内容。

以“用户发送电子邮件测试点”为例,我们不清楚测试点5，“发送电子邮件”与“接收电子邮件”交互点在哪里，是随便发送一份邮件，还是发送超大附件的邮件？测试测试点1时，我们并不清楚要测试哪些“正常的输入数据”，怎么去组合这些数据？

# 三、如何写出漂亮的测试用例

前面几章我们已经讨论过了测试分析和测试设计的技术，但根据以往的经验，即使我们掌握了各种测试设计技术，写出来的测试用例也可能不那么尽如人意，下面这写情况在测试用例中十分常见：

测试用例只有作者才能看懂，其他人看起来会很吃力。有时候其他人会恨不得把用例拿来自己重新写一遍。
测试用例由不同人来执行，结果差别很大。
有的测试用两个i读起来很笼统，有的测试用例又写的特别细，粒度不统一。

# 1 测试用例模板

此表格为FHTP的用例导入模板

对用例模板的核心字段进行说明解释下：

计数：即用例编号，测试用例的唯一标记。
用例名称：概述用例的主要内容，明确该测试用例的意图。
优先级：测试用例的重要程度和执行优先顺序。
用例描述：因用例名称需要言简意赅，此字段可以补充说明该测试用例的信息
前置条件：测试用例顺利执行的前提条件，如一些基本的配置。
测试步骤：如何执行这个测试用例，每步的操作是什么。
用例期望：和测试步骤对应起来，操作后希望系统的返回。
后置条件：测试用例执行完成后（成功或失败）的一些操作，如还原配置项，清理测试数据等。

我们在编写用例前，需要先想一下谁会用测试用例，那就是测试执行者。测试执行者对被测对象应该有所了解，有搭建测试环境的能力，并能使用相关工具，是专业人士。因此我们真没必要把测试用例写的面面俱到，非常细致，而应该简洁无歧义，突出测试用例的目的。描述清楚关键的步骤和检查点即可。好的测试用例，通过阅读用例名称，就能清楚地知道这个用例的测试目的。和测试目的密切相关的步骤才会放在测试步骤中，那些基础的操作步骤是简洁地放在预置条件中。使得执行者能够快速抓住测试地重点，并且预期结果应该是清楚准确、没有歧义的。

除此之外，我们还要注意测试用例的粒度。所谓用例的粒度，通俗来讲就是指一个测试用例包含的测试内容。从项目的角度来说，我们希望项目中所有测试用例的粒度都是基本统一的，这样才方便估计工作量和布置工作任务。从测试执行者的角度来说，过细的测试用例会让执行者感到繁琐、疲惫，过粗的测试用例又容易遗漏掉检查点。下述经验值可以作为大家在控制测试用例粒度时的参考：

测试用例名称不要超过30个汉字，不要少于10个汉字。
测试步骤不要多于7步，不要少于2步。
预期结果不要多于5个，不要少于1个。

# 2 测试用例名称要是一个完整的句子

只有当测试用例名称是一个完整的句子时，读者才能完整地了解这个测试用例的意图。推荐使用下图所示的句式：

举几个例子：

例1
- 修改前：同时对源IP和目的IP进行限制。
- 点评：缺少主语，不知道对象是什么（其实是个在线抓包工具）；另外为什么要限制？测试目标不明确（目标是验证抓包工具能否只抓取指定的源IP和目的IP的数据包）。
- 修改后：在线抓包工具抓取指定源IP和目的IP的数据包测试。
例2
- 修改前：申请员查询列表测试。
- 点评：没有明确条件---不同的用户角色登录会造成测试结果不一样，所以在测试用例名称中最好明确需要在怎样的条件下进行测试。
- 修改后：普通用户登录系统申请员查询列表测试。

# 3 用条件而不是参数来描述测试用例名称

做完测试设计，我们得到的其实是一些条件集（如XXX流程路径、XXX常见的集合）和一些数据集（如输入参数）。这使得测试用例标题有两种表述方式：

以条件作为用例标题
以参数作为用例标题

哪种表达方式更好？

TODO

# 4 明确测试步骤和预期结果的对应关系

一个测试用例通常会包含好几个测试步骤和多个预期结果。有时候不同的测试步骤可能会有相同的预期结果，为了描述简便，很多测试用例作者会省略相同的预期结果。另外也不是所有测试步骤都有预期结果，一般是重要、关键的测试步骤才会有预期结果。这时我们可以在测试用例中，增加简单的标记（如[check n]）来明确测试步骤和预期结果之间的关系，让测试执行人员一目了然。

# 5 不要在测试用例中引测试用例

在编写测试用例时，不宜在测试步骤中又引用别的测试用例。

举个例子：

测试用例1：用户登录成功后，访问服务，30分钟内不需要再次认证。

测试用例2：用户认证通过后，超过30分钟重新认证后访问服务。

1
2
3

在上面的例子中，我们在测试用例2的测试步骤1中，又引用了测试用例1。这样便那些用例，会使得测试用例内容变多，不仅测试执行者在执行用例时容易遗漏，也不利于测试计划的安排，还会给后续测试用例的修改、维护和移植带来麻烦。

我们会在测试用例中引用另一个测试用例，在很大程度上是因为用例中存在先后关系，即测试用例2一定会在测试用例1之后执行。

这时我们可以考虑这样来编写测试用例：

方法1：把测试用例1和测试用例2合并成一个大的测试用例。
方法2：把测试用例1的主要内容放到测试用例2的前置条件中。

方法1比较适合测试用例1和测试用例2都比较简单的情况，相对来说方法2更通用一些。

我们来看具体如何改造上面这个测试用例。

举例：用方法1对测试用例1进行改造

考虑合并测试用例1和测试用例2，得到新测试用例3

在测试用例3中，步骤1~步骤4即为原测试用例1的步骤，步骤5~步骤6为原来测试用例2的步骤

举例：用方法2对测试用例2进行改造

我们考虑将测试用例1中的主要内容，总结为测试用例2的预置条件，见下图，测试用例2：用户通过普通用户+密码认证后，超过30分钟重新认证后访问服务。

其中用户通过认证后，访问服务，就是对原测试用例1的概述。

# 6 避免测试用例中包含过多的用户接口细节

在介绍测试用例模板时，我们已经提出测试用例执行者应该是专业人士，测试用例不必写的面面俱到，我们来看下面的例子。

举例：在测试步骤中描述得面面俱到的测试用例

测试用例1：首次购物的用户，先选择物品，再登录系统购物测试，见下图

这个测试用例在测试步骤中描述了很多用户接口的细节，如：”用户输入正确的ID和密码“、用户输入正确的姓名、街道地址、城市、邮编、电话号码”……并且还不忘记“点击OK“、”点击确认付款“等操作。过多的细节使得测试执行者无法快速抓住测试用例执行步骤的重点，而且一旦产品的细节在设计上有所变化，测试用例也需要修改，不利于用例的后期维护。

所以，用例步骤最好是对系统操作的概况描述，无须叙述所有的细节。基于这个思路，我们来对此用例进行改造。

# 7 避免在测试步骤中使用笼统的词

我们在描述测试步骤时，需要尽量避免那些笼统的表述方式，如”反复“、”长时间“、”大量“等。因为这样描述，不同的测试执行者的理解会有所不同。比如”反复“，有人会认为执行两次就是反复了，有人认为至少执行10，这样就会造成测试执行上的差异，很可能会达不到测试的效果，那么我们在测试用例中应该如何描述呢？

# 7.1 测试用例中需要反复、多次操作的描述方法

问题示例：反复执行接口up/down的操作

解决方法1：在测试用例中确定反复的具体次数

修改1：反复执行接口up/down操作100次
解决方法2：也可以未测试用例确定一个反复的范围

修改2：反复执行接口up/down操作至少100次
解决方法3：如果反复多次执行某个操作多次后，会出现某种特定的效果（例如内存会升高到某个特别值），但是需要反复执行多少次这样的操作却并不确定，可以这样描述

修改3：反复执行up/down操作，直至系统内存值达到最大值的45%

# 7.2 测试用例中需要长时间测试的描述方法

问题示例：系统长时间转发HTTP业务

解决方法1：在测试用例中确定长时间的测试时长

修改1：系统持续转发HTTP业务24小时
解决方法2：也可以为测试用例确定一个长时间的测试时间范围

修改2：系统持续转发HTTP业务至少24小时

# 7.3 测试用例中需要大量操作的描述方法

问题示例：大量用户同时连接服务器

解决方法1：需要确定大量的具体数量，如1000、2000

修改1：2000个用户同时连接服务器
解决方法2：可以以产品规格作为大量的参照值，如满规格、系统支持数的50%

修改2：满规格用户同时连接服务器

# 四、测试用例的策略

# 1 测试用例优先级

测试设计过程中，需要对测试优先级进行明确，并体现在测试用例中。测试优先级不是主观臆断，而是通过一定依据进行划定，这里我们介绍一种常见的测试优先级划定方法——根据质量目标和特性分类来确定测试优先级，如下图。

# 2 测试用例粒度

穷尽测试是不可能的

穷尽测试是不可能的，当满足一定的测试出口准则时测试就应当终止。

考虑到所有可能输入值和它们的组合，以及结合所有不同的测试前置条件，这是一个天文数字，我们没有可能进行穷尽测试。在实际测试过程中，测试人员无法执行“天文”数字的测试用例。

所以说，每个测试都只是抽样测试。因此，必须根据测试的风险和优先级，控制测试工作量，在产品质量、测试成本、效率和风险之间求得平衡。

# 2.1 何为测试粒度？

软件测试从某种程度上说是一种在质量、效率、风险、成本之间平衡的艺术。

粗颗粒度面向宏观，面向正向功能点、大的功能模块和整体性，体现测试用例的设计思路。
细颗粒度面向微观，面对具体的一个个功能点的正向、负向逻辑，体现测试用例的细节和完备性。

# 2.2 如何选择测试粒度

我们可以根据 测试优先级（依据质量目标和特性分类划定） 结合 项目周期 进行粒度划分。

这里需要强调的是，测试用例粒度细，不是指的每一条用例的操作步骤详细。同时应避免编写测试用例时，对每一个操作步骤进行描述，如验证某查询功能时，不需要写，1.打开浏览器；2.输入手机号；3.点击回车…… 仅说明核心步骤或者不说明步骤，仅明确期望即可。

“重要功能”、“特殊功能”颗粒密集度高，“通用功能”可以试用通用测试粒度，密集度应该可以大致界定。个人认为，假如你非要为了一个字体的样式而写了一大长串的测试用例，那么这个颗粒度就毫无意义了。
颗粒度的大小还取决与客户对“产品”的要求。测试有一个难题是测试的精度，或者说颗粒度的定义，不要说一个程序，就算是一个简单的登录都可以写出几乎无穷尽的测试用例，所以你需要指明功能、性能需求，使用环境等，并说明对缺陷容忍的限度。才好依据最终的需求来定义测试的颗粒度，也才好写测试用例，总之，客户的要求越详细所得到的测试用例越准确。如果客户跟你说这个地方你必须仔仔细细的测试。那么我们在写测试用例的时候。这个颗粒度一定要小了。
一般功能颗粒密集度可能会根据项目或是时间来确定。如果时间充裕颗粒度可以适当小。 4.粒度取决于测试的种类，一般用验收测试用例是项目测试中颗粒度比较大。集成、系统测试用例颗粒度相对较小。

# 3 测试数据准备

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其像测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

# 测试数据来源

造数据
- 关于造数据的时间成本问题:大量的造测试数据意味着需要投入较多的时间做重复性的事情，如，不断的填写或替换某些字段值，可以通过自动化提高造数据效率。关于造数据的可靠性问题:人为造的数据是否符合真实环境中数据情况？造的数据是否过于理想，基于这种数据的进行的测试，结果是否可靠。需要结合业务测试经验进行测试数据设计，提高测试数据可靠性。
真实数据
- 真实数据规避了造数据面临的测试数据可靠性问题，但引入了数据安全性问题。为满足某些测试场景必须要使用真实数据进行测试的要求。真实数据导出，需先经领导批准后方可进行导出，同时注意真实数据不得存放在本机，必须存放至服务器中（数据安全仓库中），做好数据安全管理并在使用完后及时清除。

# 思考——下面不同测试类型测试数据来源有什么异同？

功能测试的测试数据
性能测试的测试数据
自动化测试的测试数据
可用性测试的测试数据

这里延伸一下话题，随着软件行业的不断，对应的对开发、测试人员的要求也不断的提高。我们在测试过程中，难免会遇到一些简单的重复性的工作，建议大家遇到这种情况时，发挥主观能动性，通过自动化等方式提高测试效率，与此同时也提高了自身的测试水平。

# 4 思考

除此之外还应测试用例中还能包含什么内容？

# 五、测试用例评审

# 1 测试用例评审内容

是否覆盖测试需求上的所有功能点，不违背产品原型和代码设计，用例设计的结构安排是否清晰合理，有利于高效覆盖需求
用例是否具有可执行性，前提条件、执行步骤和预期结果是否正确，有明确的验证方法。优先级安排是否合理
是否从用户层面来设计用户使用的场景和业务流程
是否包含充分的异常测试用例 5.是否简洁，不冗余，复用性强

# 2 测试用例评审过程

提前发出初稿和会议邀约，至少提前一天发出用例初稿，并确定参与用例评审人员，以便项目经理，产品和开发提前阅读用例，让会议更有效率的进行。
先做简单的业务流程介绍，这个是在评审开始尤为重要的一个过程，刚开始评审，参与人员会比较蒙圈，产品和开发都不知道测试的思路，或者半途加入新的开发和测试，对需求和业务都不够熟悉，如何让评审快速进入状态，先做简单的需求业务流程介绍，说明白打算如何去做评审。
- 【举例】一个项目有用户体系、电子账户、理财、生活模块，可以先由大到小的细分下去；可用事先画好的脑图，各种流程图，也可当场快速写上板书。
按模块进行，有些模块，业务性不是特别强的，可以简单说下有哪些模块，每个模块评审的时候，按测试项分类，UI、核心功能、基础功能、边界测试、兼容测试和异常测试等，预期结果类似的，主要讲清楚用例主题，让参与人员知道每条用例是做什么的。
.按业务流程进行，业务流程性较强的需求，需要有业务场景和逻辑，按一定的顺序来，让参与人跟着你的思想，避免东一句西一句.。
- 【举例】一个理财活期产品的测试用例评审，购买和赎回，跑批时间段分日间和日终，工作日和周末四个场景，按不同场景分为不同的业务流程进行评审，有理有据，逻辑思路清晰。
按测试数据进行，涉及到计算逻辑、收益、报表等需求的，用例编写时会先规划好测试数据，尽管测试数据也是按不同的业务场景来设计的，但直接用测试数据来评审你的测试点，会更清晰，跟上你思路的开发和产品会对应上自己的产品设计和代码设计去评审你的测试点是否不合理或覆盖率不全的地方，从而有效的评审测试用例。

# 3 用例评审后的确认

为了节约时间成本，第一次评审尽量对用例设计全面考虑，提前发现其中的不足之处；但是第一次评审难免会要修修补补的地方，在评审时尽快的修复，不能在一两分钟修复的，记录下来，在会议结束后进行修改，如果改动不是很多的，可以发出邮件，标明修改部分，再最后确认最终版。如果需要进行二次评审，那么重新开始邀约会议做二次评审。

# 4 用例评审禁忌

测试点含糊用语，每个用例评审都应该确定最终版，稍有矛盾或疑惑的需求点，都应该在评审前确认下来，不能含糊不清。
杂乱无章的评审，有顺序有逻辑的进行评审是很重要的一点，如果臆想按照自己的思路评审，不顾他人感受，那么就等同于做无用功。这样的用例执行出来也会有一定的质量风险。

# 六、测试分层中的测试执行

没有失效不代表系统是可用的

系统的质量特征不仅仅是功能性要求，还包括了很多其他方面的要求比如稳定性、可用性、兼容性等等。假如系统无法使用，或者系统不能完成客户的需求和期望，那么，这个系统的研发是失败。同时在系统中发现和修改缺陷也是没有任何意义的。在开发过程中用户的早期介入和接触原型系统就是为了避免这类问题的预防性措施。有时候，可能产品的测试结果非常完美，可最终的客户并不买帐。因为，这个开发角度完美的产品可能并不是客户真正想要的产品。

# 1 单元测试

单元测试又称模块测试，是指对软件中最小的可测单元（模块）进行检查和验证。单元测试是为了测试“新开发的功能和模块是否符合设计”，是白盒测试，使用内部接口进行测试。单元测试主要使用白盒测试方法：

代码评审：静态的检查代码是否符合规范；白盒测试:动态的运行代码检查其实际运行结果；其他：程序的容错处理，程序的边界值处理等；

该阶段可以进行接口的自动化测试，设计阶段接口明确后即可以开展接口自动化测试开发。

# 2 集成测试（相对于公司模块测试阶段）

集成测试是单元测试的下一个阶段，指将通过测试的单元模块组装成系统或子系统，再进行测试。集成测试重点测试不同模块之间的接口部分，检查各个单元模块结合到一起能否协同配合，正常运行。

# 2.1 集成测试对象与目标

集成测试相当于是在测试验证“新合入功能能否在系统中被正确地装配起来（前提是功能是我们想要的那个功能）”，是“黑盒测试”，也是系统级的测试，应该使用系统提供给用户的输入接口来进行测试，使用提供给用户输出接口来判断接口的正确性。

集成测试需要测试内容包含以下几点：

确认新合入的功能是否正确；
验证功能集合后系统功能的正确性；
确认原来的系统功能没有被新合入的功能所破坏。

# 2.2 何时可以开始集成测试

开发方面准入要求

一个集成计划中功能开发完成，并且完成自测，确保测试能够进行系统级的黑盒测试。其余准入条件及规范，详见测试流程课程。

研发达到开发方面集成测试准入要求后，按照测试流程提交测试，进入集成测试阶段。这里说明一下研发提测邮件中需包含哪些内容（不局限于此，详细要求详见测试规范培训课程）。

提测组件包，包含：规范文档、安装包、md5、release-note
提测时间、需求分析阶段共同制定的测试周期
组件包依赖关系说明
其他重要信息说明（风险）

测试方面准入要求（ 测试准入条件需要在研发约定提测前完成。）

测试用例已经输出，并通过评审；
测试基础环境已经准备好；

其余准入条件及规范，详见测试流程规范课程。

# 2.3 测试执行

我们前面确认了测试用例优先级，但在具体执行中除了根据优先级还要采用一定策略,例如：

根据业务场景或业务流程，首先验证业务流程是否存在问题，即，如果存在较多严重问题或严重影响测试进度，则视情况测试打回。如测试淘宝下单流程，发现商品无法添加至购物车，该问题严重影响了后续，下单、支付流程功能的测试，则测试打回。
集成测试后期，视情况，如系统已经相对比较成熟、稳定的时候，可以适当选择性能、稳定性、压力方面的测试用例来执行，以避免这类“非功能”方面的问题在系统测试阶段密集爆发。（性能、稳定性、压力对测试环境要求较高，一般来讲当家里环境不满足性能测试条件时，大多将该部分测试后移至现场实测阶段）
结合项目情况，集成测试后期，系统已经相对比较成熟、稳定的时候，对测试用例进行自动化测试转化。
集成测试阶段可以开展易用性方面测试，易用性方面主要可以选择一致性测试法和可用性测试法开展。

# 2.4 集成测试准出要求

系统需要集成的功能全部开发、集成完成。
计划执行的测试用例已经完成。
达到了集成测试阶段的产品质量目标。

其余准出条件及规范，详见测试流程课程。

# 3 系统测试（相对公司系统测试+现场测试）

系统测试是将整个软件模块看做一个整体系统进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。

# 3.1 系统测试对象与目标

集成测试主要还是针对功能的集成，在集成测试中我们无法（或者说没有足够的测试时间，或者说系统还是不够稳定）对被测对象的其他非功能方面的质量进行测试验证，只通过集成测试无法对系统进行全面的测试，因此系统测试是有必要的，在系统测试中需要测试的主要内容包括：

从系统角度来验证测试功能的正确性。从系统角度来验证各种非功能的质量的正确性。

# 3.2 何时开展系统测试

集成测试的准出就是系统测试的准入。

# 3.3 测试执行

系统测试阶段需要对功能、可靠性、性能、易用性等各方面进行测试，我们可以基于以下几点优化我们的测试执行顺序：

有些测试方法需要满足一定的条件才能开展，我们就 按照测试方法本身的的条件来安排测试顺序，如先进行稳定性测试、再进行压力测试，然后进行恢复性测试。（性能、稳定性、压力对测试环境要求较高，一般来讲当家里环境不满足性能测试条件时，大多将该部分测试后移至现场实测阶段）
有不同的的测试方法，都能对测试对象进行测试，先执行优先级高的、复杂的、再进行简单的，目的在于，重要的、难发现缺陷能够尽量在测试的前期发现，另外也是先执行优先级高、复杂的测试用例也能保证这些测试用例有充足的执行时间。
可以 考虑组合多种测试方法，或者说把一些测试用例放在一起执行。 例如，可以将功能测试的测试用例与满规格（产品规格指的是产品承诺的能够处理的最大容量或能力）的测试用例放在一起执行，在满规格的情况下测试功能，往往可以发现很多新的问题。
系统阶段的测试用例执行不是将集成阶段的测试用例再执行一遍，可以按照一定策略（集成测试覆盖、遗留情况、优先级、场景、常用功能等）选择部分集成测试阶段执行过的用例进行执行，更多的是对非功能方面进行测试和考虑。
1. 非功能类的测试方法：
  - 可靠性测试，如稳定性测试法、故障植入法
  - 易用性测试，如一致性测试法、可用性测试法
  - 性能测试等
系统测试阶段中的现场实测，该阶段属于系统测试末端，指的是在测试环境完成系统测试后（即达到系统测试准出要求），进入线上部署测试阶段，通过执行核心功能点测试用例、测试环境不具备执行条件的用例（遗留用例）以及非功能性测试（性能测试、稳定性测试、压力测试）保障系统上线后，满足系统测试准出要求，同时产出实测报告。

# 3.4 系统测试准出条件

计划执行的测试用例已经完成。
达到了系统测试阶段的产品质量目标。

# 4 验收测试

验收测试是指按照项目任务书或合同、供需双方约定的验收依据文档进行对整个系统的测试与评审，用户决定是接收或拒收系统。

# 4.1 验收测试对象与目标

验收测试的对象是需求，需要基于用户场景来测试。(从需求出发，结合背景、场景的是整个测试生命周期的要求，而不是仅在验收测试阶段)，验收测试是产品在发布前的一种测试，它是对用户需求的确认。

# 4.2 测试执行

验收测试一般有公司内测试人员或客户指定的第三方公司进行执行。

# 七、FHTP测试用例中心

# Q&A问答

# 课后练习

根据测试分析和测试设计的产出，对食药环”案件协查“模块进行测试用例设计，由实战讲师讲解需求和布置任务。

#测试基础

上次更新: 7/26/2026, 3:17:15 PM

← 测试设计 Wady（绿洲）Java SDK单元测试从0到1的突破→