回归测试
软件测试中的回归测试和压力测试方法
软件测试中的回归测试和压力测试方法软件测试是保证软件质量的重要环节，其中回归测试和压力测试是两种常见的测试方法。
本文将分别介绍回归测试和压力测试的定义、目的、方法和相关工具，并探讨它们在软件开发过程中的重要性。
一、回归测试1.定义回归测试是指对软件进行修改或更新后，验证已有功能是否受到影响的测试过程。
其目的是确认新的代码变更未对现有功能产生负面影响。
2.目的回归测试的主要目的是确保软件修改后仍能保持原有的稳定性和可靠性。
当软件代码发生了更新或修复之后，需要通过回归测试来验证已有功能是否仍能正常运行，以保证软件整体的质量和稳定性。
3.方法回归测试通常包括以下步骤：（1）确定回归测试的范围：根据软件的修改内容确定需要进行回归测试的范围，包括受影响的功能模块和相关的测试用例。
（2）执行回归测试：运行已有的测试用例，检查修改后的软件是否产生了新的问题或影响了已有功能。
（3）修复问题：如果在回归测试中发现了问题，需要及时修复并再次进行测试，直到问题得到解决。
（4）更新测试用例：根据软件的修改内容更新测试用例，以确保回归测试的全面性和有效性。
4.相关工具在执行回归测试时，可以利用一些自动化测试工具来提高测试效率，如Selenium、JUnit、TestNG等。
这些工具可以帮助快速运行测试用例并生成测试报告，提高测试的自动化程度。
5.重要性回归测试是软件开发过程中非常重要的一环。
通过回归测试可以保证软件的修改不会破坏已有的功能，避免因修改而引入新的问题，保证软件的稳定性和可靠性。
二、压力测试1.定义压力测试是通过模拟大量用户同时访问软件系统，来评估系统在高负载情况下的性能和稳定性能力。
其主要目的是找出系统在极限负载下的性能瓶颈和问题，以及系统的承受能力和性能表现。
2.目的压力测试的主要目的是评估系统在高负载情况下的表现，包括系统的性能、稳定性和可扩展性。
通过压力测试可以发现系统的性能瓶颈，避免系统因高负载而崩溃或出现性能问题。
软件测试中的回归测试技术
软件测试中的回归测试技术回归测试是软件测试中的一种重要技术，用于确保已修改或添加的软件功能不会对原有功能产生负面影响。
本文将介绍回归测试的定义、流程和常见的回归测试技术。
一、回归测试的定义回归测试是在软件功能发生变化或添加新功能后，重新执行已验证过的测试用例，以确保新的变化对现有功能没有负面影响。
回归测试的目标是发现和解决已修改部分与其他功能之间的冲突或问题。
二、回归测试的流程1. 确定测试范围：根据软件的变动确定需要执行回归测试的范围，包括涉及到的功能模块、测试用例和测试数据等。
2. 选择回归测试技术：根据软件的复杂度和测试资源的限制，选择合适的回归测试技术。
3. 执行回归测试：根据预定的测试计划和测试用例，执行回归测试，并记录测试结果和问题。
4. 分析问题：对回归测试中发现的问题进行分析，确定其原因和解决方案。
5. 修复问题：开发团队根据测试结果中的问题进行修复，并重新进行测试确认修复是否有效。
6. 再次执行回归测试：在问题修复完成后，再次执行回归测试，以确保修复过程中没有引入新的问题。
7. 重复步骤4-6，直到回归测试通过为止。
三、回归测试的常见技术1. 选择性回归测试：根据变更的影响范围，选择部分测试用例进行执行，以减少测试资源的消耗。
2. 完全回归测试：执行所有已验证的测试用例，确保软件的所有功能都得到验证。
3. 全量回归测试：执行所有测试用例，无论是否与变更有关，以确保所有功能都得到验证。
4. 自动化回归测试：使用自动化测试工具执行回归测试，提高测试效率和一致性。
5. 增量回归测试：仅执行与变更相关的测试用例和功能模块，减少回归测试的执行时间和资源消耗。
6. 分层回归测试：将测试用例按照功能模块进行划分，每次只执行与变更有关的功能模块的测试用例。
回归测试技术的选择应根据实际情况进行评估，综合考虑软件变更的复杂度、测试资源的限制和测试周期等因素。
总结：回归测试在软件开发中起到了至关重要的作用。
软件测试中的回归测试
软件测试中的回归测试
软件测试中的回归测试是一项非常重要的测试活动，其主要目的是确保软件系统在经过修改或更新后依然能够正常运行，并且不会对原有功能产生负面影响。
在软件开发过程中，经常会出现需要对软件进行修改或更新的情况，这可能是由于修复bug、添加新功能或优化现有功能等原因。
回归测试的核心思想是将修改后的软件与原有版本进行比较，验证修改的部分没有引入新的bug，同时确保原有功能仍能正常工作。
通常情况下，回归测试会在每次软件修改后进行，以保证软件质量和稳定性。
在进行回归测试时，可以采用手动测试和自动化测试两种方式。
手动回归测试需要测试人员逐一验证所有功能，确认修改是否正确且未对其他功能造成影响。
虽然手动测试能够覆盖更全面的测试用例，但其效率较低且容易出现遗漏。
因此，许多公司会选择使用自动化测试工具来进行回归测试，以提高测试效率和准确性。
自动化回归测试可以通过编写测试脚本或使用专业的自动化测试工具来实现。
测试人员可以编写测试脚本来验证特定功能或场景，然后通过执行这些脚本来检查软件的正确性。
自动化测试工具则可以记录用户操作并生成自动化脚本，从而实现自动执行和结果验证。
除了验证功能是否正常工作，回归测试还需要关注软件性能和稳定性。
在进行回归测试时，需要重点关注软件在修改后的性能表现和稳定性，以确保用户体验和系统稳定性不受影响。
在实际项目中，回归测试是软件测试过程中不可或缺的一环。
通过回归测试，可以有效减少软件修改后的风险，保证软件质量和用户体验。
因此，软件开发团队应重视回归测试的重要性，并积极采用适合的方法和工具来进行回归测试，以确保软件系统的稳定性和可靠性。
自动化测试中的回归测试与迭代测试
自动化测试中的回归测试与迭代测试自动化测试是现代软件开发过程中的重要环节，它可以大大提高测试的效率和准确性。
而在自动化测试过程中，回归测试和迭代测试是两个重要的测试方法。
本文将详细介绍回归测试和迭代测试的概念、流程和应用场景。
一、回归测试回归测试是指在进行软件版本升级或修改后，重新执行旧有测试用例的过程，以确保修改或增加新功能后的软件仍然具有原有功能。
回归测试的目的是验证软件在经历改动后是否仍然能够正常工作，并且不会引入新的错误。
在自动化测试中，回归测试通常有以下几个特点：1. 自动执行：回归测试通常通过测试脚本来进行自动化执行，以提高测试效率。
2. 全面性：回归测试需要覆盖所有可能受到改动影响的功能模块，确保整个软件系统的稳定性。
3. 可重复性：回归测试需要能够重复执行，以便在每次软件改动后进行验证。
回归测试的流程一般包括以下几个步骤：1. 确定回归测试范围：根据软件版本的改动情况，确定需要执行回归测试的功能模块和测试用例。
2. 编写测试脚本：根据回归测试范围，编写相应的测试脚本，覆盖需要测试的功能点。
3. 执行回归测试：使用自动化测试工具执行回归测试脚本，检测软件在改动后的表现。
4. 分析测试结果：根据回归测试的结果，分析是否存在功能异常或者性能问题。
5. 报告缺陷：如果回归测试中发现了功能异常或者性能问题，需要及时报告给开发人员，并追踪问题的修复情况。
回归测试在以下情况下特别适用：1. 软件版本升级：当软件经过版本升级后，需要进行回归测试，以确保新版本仍然具有原有的功能和稳定性。
2. 缺陷修复：当修复了软件中的缺陷后，需要进行回归测试，以验证修复是否成功，并确保修复过程没有引入新的问题。
3. 新功能添加：当向软件中添加新功能时，需要进行回归测试，以确保新功能的添加没有破坏原有的功能或者引入新的错误。
二、迭代测试迭代测试是指在软件开发的迭代周期中，针对每个迭代阶段进行测试的过程。
软件开发一般采用敏捷开发或者瀑布模型等迭代式开发方法，每个迭代周期可以包含需求分析、设计、编码和测试等阶段。
回归测试的名词解释
回归测试的名词解释回归测试是软件开发周期中的一种测试方法，旨在检测软件修改或更新后是否产生了新的错误或导致了现有功能的中断。
本文将对回归测试的定义、目的、特点、流程、工具以及常见的相关概念进行解释，来帮助读者更好地理解和应用回归测试。
一、回归测试的定义回归测试指的是在对软件进行修改、修复漏洞或进行其他类型的更新后，重新运行已有的测试用例，以确保新的更改没有产生新的错误或导致现有功能的中断。
这种测试方法旨在验证软件的稳定性和兼容性。
回归测试的主要目的是防止在软件开发的后续阶段中引入新的错误。
二、回归测试的目的回归测试的主要目的是验证软件的正确性和稳定性。
通过回归测试，可以确保软件在修复漏洞、修改功能或增加新功能后的可靠性。
另外，回归测试还可以帮助开发团队发现和纠正可能存在的软件缺陷，防止错误扩散到模块之间或系统的其他部分。
三、回归测试的特点1.自动化：回归测试通常使用自动化测试工具来执行已有的测试用例，节省测试人员的时间和精力，并提高测试效率。
2.可重复性：回归测试的测试用例必须具备可重复执行的特点，以便在每次软件更新后都能使用相同的用例进行验证。
3.全面性：回归测试需要覆盖整个软件系统或相关模块，以确保涉及的功能都得到了正确的测试。
4.灵活性：回归测试需要根据软件更新的内容进行相应的调整和修改，以更好地适应变化的软件需求。
四、回归测试的流程回归测试的流程可以分为以下几个步骤：1. 确定回归测试的范围：根据软件的更新内容和相关需求，确定需要进行回归测试的模块和功能。
2. 创建或更新测试用例：根据回归测试的范围和目标，创建或更新相应的测试用例，包括输入数据、预期输出和操作步骤。
3. 执行回归测试：使用自动化测试工具执行回归测试，检查更新后的软件是否符合预期的行为，并记录测试结果。
4. 分析测试结果：根据回归测试的结果，分析可能存在的错误或功能中断，并进行相应的修复和调整。
5. 重复执行回归测试：在修复错误或调整功能之后，再次执行回归测试，确保修复和调整的有效性。
回归测试在验收测试前还是后
回归测试在验收测试前还是后回归测试和验收测试都是软件测试的重要环节，它们有着不同的目的和时间节点。
在软件开发过程中，回归测试和验收测试的顺序安排一直是一个争论的话题。
有些团队倾向于在验收测试前进行回归测试，而有些团队则选择在验收测试后进行回归测试。
那么，究竟回归测试在验收测试前还是后更为合适呢？接下来将讨论这个问题。
回归测试在验收测试前优势：1.提前发现问题：在验收测试前进行回归测试可以提前发现并修复之前开发阶段引入的缺陷，保证软件的质量。
2.节省时间成本：如果在验收测试前就完成回归测试，可以避免因为验收测试发现问题而导致的多次返工，节省时间成本，提高开发效率。
3.减少风险：早期发现和修复问题可以减少软件上线后出现严重问题的概率，降低风险。
劣势：1.重复工作：在验收测试前进行回归测试可能会导致重复测试，某些问题可能在验收测试中也会被发现，从而造成一定程度的重复工作。
2.时间压力：在验收测试前进行回归测试可能会增加测试团队的时间压力，需要保证回归测试的质量和有效性，加大了测试人员的工作负担。
回归测试在验收测试后优势：1.确保软件稳定性：在验收测试验证通过后再进行回归测试，可以确保软件已经达到基本的稳定性，回归测试的效果更为显著。
2.减少重复工作：避免在验收测试中已经确认的问题再次进行回归测试，减少重复工作，提高测试效率。
3.更清晰的测试目标：在验收测试后进行回归测试，测试人员更清晰地知道需要测试的功能点和修复的问题，测试目标更加明确。
劣势：1.延迟问题发现：如果在验收测试通过后再进行回归测试，可能会延迟问题的发现和修复，导致问题在软件上线后被用户发现。
2.测试效率降低：在验收测试后进行回归测试可能会导致测试效率的降低，因为一旦发现问题，需要重新进行修复和回归测试，耗费更多的时间和精力。
综上所述，回归测试在验收测试前还是后并没有绝对的答案，具体的选择应根据项目的具体情况和团队的实际需求来确定。
在实际工作中，可以根据项目的进度和时间安排，灵活选择在验收测试前或者后进行回归测试，以达到最佳的测试效果和效率。
测试中的回归测试和冒烟测试
测试中的回归测试和冒烟测试回归测试和冒烟测试是软件测试中常用的两种测试方法，它们在不同的阶段扮演着重要的角色。
本文将对回归测试和冒烟测试进行详细介绍，并探讨它们在测试过程中的作用和应用。
1. 测试介绍在软件开发的过程中，为了确保软件产品的质量，测试是一个至关重要的环节。
而测试又可以分为多种类型和方法，其中回归测试和冒烟测试是最常见的两种。
下面我们将逐一介绍它们的定义和作用。
2. 回归测试回归测试是在软件开发过程中进行的一种测试方法，它的目的是验证已经修改、添加或删除的代码对原有功能是否产生了影响。
回归测试的主要目标是确保已经通过的功能在进行修改后依然能够正常工作。
回归测试的流程一般包括以下几个步骤：- 确定测试用例：根据软件需求和修改的代码，选择合适的测试用例进行回归测试。
- 执行测试用例：按照预定的测试计划和测试用例，对修改后的软件进行测试。
- 检查结果：检查回归测试的结果，确定是否存在新的缺陷或者已有缺陷是否修复。
回归测试的优点在于能够确保新的修改不会对已经测试通过的功能产生负面影响，从而提高软件的稳定性和可靠性。
3. 冒烟测试冒烟测试是软件测试过程中的一个快速的测试方法，其目的是在软件的初始开发阶段或者重要的版本更新时，对软件的主要功能进行初步的验证。
冒烟测试主要是为了检查软件是否能够基本运行，并提前发现潜在的严重问题。
冒烟测试的流程主要包括以下几个步骤：- 确定关键功能：选择软件中的关键功能或者模块。
- 执行测试用例：使用基本的测试用例对关键功能进行测试。
- 检查结果：根据测试结果确定软件是否能够基本运行，并记录潜在的问题。
冒烟测试的优点在于能够快速检查软件的关键功能，确保软件在最初的阶段就有基本的可用性。
4. 回归测试和冒烟测试的区别回归测试和冒烟测试虽然都属于软件测试方法，但它们在目的和应用场景上存在一些不同点。
回归测试主要是为了确保已经通过的功能在修改后依然能够正常工作，一般在软件的后期进行。
用户验收测试和回归测试
用户验收测试和回归测试用户验收测试（User Acceptance Testing，UAT）和回归测试（Regression Testing）是软件开发过程中重要的测试阶段。
它们旨在确保软件产品的质量和稳定性，满足用户需求并保持相对稳定的功能。
一、用户验收测试用户验收测试是在软件开发过程的最后阶段进行的一项测试活动。
它的目的是验证软件是否符合用户需求和预期，以及是否满足用户的功能和性能要求。
用户验收测试通常由最终用户或代表用户的专业人员来执行，他们会模拟真实的使用场景，检查软件在各种情况下的表现。
用户验收测试的步骤通常包括以下几个方面：1. 确定测试目标和范围：明确测试的目标和范围，确定要测试的功能和性能要求。
2. 创建测试计划和用例：根据用户需求和功能规格说明书，编写测试计划和测试用例，详细描述测试的步骤和期望结果。
3. 执行测试用例：按照测试计划和测试用例，逐步执行测试，记录测试结果和问题。
4. 验证修复问题：对于发现的问题，与开发团队合作进行修复，并验证修复后的软件是否符合用户需求和期望。
5. 编写测试报告：总结测试结果，编写测试报告，包括测试的覆盖率、通过率、未通过的问题和建议等。
用户验收测试的重点是验证软件是否满足用户需求，并且在用户使用场景下是否能够稳定运行。
通过用户验收测试，可以及早发现和解决问题，提高软件产品的质量和用户满意度。
二、回归测试回归测试是在软件开发过程中的多个阶段进行的一项测试活动。
它的目的是确保在对软件进行修改或添加新功能后，原有的功能仍然能够正常运行，不会引入新的问题或导致原有功能的失效。
回归测试的步骤通常包括以下几个方面：1. 确定回归测试的范围：根据软件的修改或新增功能，确定需要重新测试的功能模块。
2. 创建回归测试套件：根据软件的功能和性能要求，编写回归测试用例，覆盖需要重新测试的功能模块。
3. 执行回归测试用例：按照回归测试套件，逐步执行测试，检查原有功能是否正常运行。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
0C202 Software Testing
7-11 Chapter 7
A A’ A’
B B’
C C’
D
E
原先版本：所有测试用例全部通过
D
E
新版本：有几个测试用例失败
B B’
C
D
E
运行失败的测试用例，只有组件A是新版本
A
C C’
D
E
运行失败的测试用例，只有组件B是新版本 运行失败的测试用例，只有组件C是新版本
与一般测试有什么不同？(2/3)
时间分配：回归测试所需的时间、资源需 要根据开发具体情况进行（尤其是修正性 的回归测试）。
开发信息：回归测试可能会在不同的地点 和时间上进行，及时记录开发信息以保证 回归测试的正确进行。
0C202 Software Testing
7-5 Chapter 7
与一般测试有什么不同？(3/3)
n1kn1
nkn
nkn
(a)
(b)
7-28 Chapter 7
直接波及是波及效应分析过程中要进行进一步更改的 第一候选集。如果直接波及后不需要进一步的更改， 那么诱发波及就不需要分析，以节省波及效应分析时 间。
7-29 Chapter 7
0C202 Software Testing
控制的依赖性
0C202 Software Testing
7-23 Chapter 7
自动化进行
开始
用户参与
1
实施初始的改变
0C202 Software Testing
2
识别哪些区域受到潜在的影响
决定如何进行修改
4
3
决定这些区域的哪些部分需要 进一步修改以保持一致性
对于每一个更改
没有需要修改的地方 结束
7-24 Chapter 7
完成时间：通常比一般测试所需时间少，因为 回归测试只需测试程序的一部分，且采用测试 脚本自动化执行。
0C202 Software Testing
执行频率：在一个系统的生命周期内往往要多 次进行，一旦系统经过修改就需要进行回归测 试。
7-6 Chapter 7
回归测试过程
七个步骤：
0C202 Software Testing
7-8 Chapter 7
识别错误
在识别错误时，为了确认软件中失败的组件，在列表 中所有列出来的模块都有可能是要查找的目标。
0C202 Software Testing
系统性的识别错误方法－组测试（Group Testing）。
7-9 Chapter 7
波及效应分析
（1）软件被修改； （2）与软件相关的所有东西（需求款项，设计款项，代 码，测试用例，文档）都可能被修改； （3）任何时候，修改都可能发生，比如在软件开发阶段 和软件维护阶段。
0C202 Software Testing
7-19 Chapter 7
修改中遇到的问题
if-then-else，while，for, 顺序型语句和面向对象 程序中的消息传递。
0C202 Software Testing
如果一个if-then-else语句的条件改变了，then部 分和else部分都要因为条件改变而被影响。
7-30 Chapter 7
数据的依赖性
数据的操作主要有三个：数据的使用、数据
7-21 Chapter 7
0C202 Software Testing
因为软件中所有类型的工件都可能变化，需
要对所有工件进行波及效应分析。波及效应 分析共有四种类型：
0C202 Software Testing
（1）需求的波及效应分析， （2）设计的波及效应分析， （3）代码的波及效应分析， （4）测试用例的波及效应分析。
0C202 Software Testing
7-15 Chapter 7
有选择的重新测试方法：
优点是当测试用例的数目很多，而且系统的更改只是一 小部分，那么这个方法是很有用的。 缺点是需要费精力对测试用例进行选择。当全部测试用 例的数目不是很大，或者对系统的更改也很多，那么这 个方法就不适合了。
程序切片
程序切片定义切片标准（slicing criteria）来说明 所关心的切片语句开始点和一些变量。程序切片结果 产生一个语句集（路径集），这些语句影响到切片标 准里被定义的语句的变量值。
7-32 Chapter 7
0C202 Software Testing
切片有向前和向后两个方向
向后程序切片：给定一个语句i和一个变量集N，由 它们产生语句集L，产生L的规则是程序执行到i止， 与N中元素关联的所有语句。 向前程序切片：给定一个语句i和一个变量集N，由 它们产生语句集L，产生L的规则是程序由i向前执行， 与N中元素关联的所有语句。
7-10 Chapter 7
如何进行组测试呢？
假设一个程序有5个组件，分别是A，B，C，D，E， 在早期的测试中，各个组件都有一个可以信赖的版本， 即正常工作版本。 假设现在A，B，C被修改了，而D， E没有被修改， 仍然是之前能正常工作的组件。 假设这一新版本软件未能通过几个测试用例，我们需 要发现错误的组件所在。
0C202 Software Testing
7-16 Chapter 7
有选择的重新测试方法中需要对测试用例进行选择，
选择的最常用算法是选择所有与某个特定模块相关的所 有测试用例，及所有集成测试用例。 而对那些固定的特征，保持它们不变。
0C202 Software Testing
7-17 Chapter 7
在识别相关的测试用例时，依据可追溯性原理，从需 求到代码，然后再到测试用例，都要能可追溯。 所有黑盒测试和白盒测试的测试用例都要做到能可追 溯。
0C202 Software Testing
因为软件工件间的依赖性，所以需要使用波及效应分析 来确认那些被影响到的部分。
7-18 Chapter 7
直接波及
诱发波及 11
111
直接波及
诱发波及 11
组件 1 依赖于
…
…
组件 1 依赖于
1k1 直接波及 21 依赖于 211
… …
…
11k11
1k1
…
初始改变
直接波及
…
0C202 Software Testing
2 初始改变
n1k21
2
2k2
…...
n1
…...
n11
n11
…
n
…
n1
…
…
…
n
n1kn1
为了保证在软件维护时，那些未更改的代码功 能不会受影响。 升级不同功能区域、信息系统持续维护、协作 关系。作为开发乃至软件使用过程中的定期常 规活动； 使E2E测试（端到端测试）成为整个软件生命 周期的测试。 是软件测试框架的必要组成。需要考虑该阶段 资源投入。
7-3 Chapter 7
0C202 Software Testing
回归测试与一般测试有什么不同？(1/3)
测试计划的可获性：回归测试面临的可能 更改的规格说明书、修改过的程序和一个 需要更新的旧的测试计划。 测试范围：一般测试过程目标是要检测整 个程序的正确性，而回归测试目标是要检 测被修改的相关部分正确性。
0C202 Software Testing
7-4 Chapter 7
对于各阶段之间同样也需要进行波及效应分
析，也就是从需求文档到设计文档，再到代 码，最后到测试用例。
Chapter 7
7-22
波及效应分析步骤
波及效应分析是一个迭代过程，直至不再有任何波及。
1. 实施初始的改变； 2. 识别潜在的受影响的组件； 3. 决定这些受到潜在影响的组件中哪些需要改变； 4. 决定如何进行这些改变，对于每一个改变都要从第1 步开始重复。如果没有要进行改变的，就结束。
0C202 Software Testing
7-33 Chapter 7
源代码
1. a = 1; 2. b = 2; 3. c = a * a; 4. d = a * b; 5. e = c + d; 1 2 a b
数据流信息
3 c e d 4
0C202 Software Testing
5
向前切片
0C202 Software Testing
第七讲： 回归测试
7-1
OUTLINE
引言 回归测试特点 回归测试过程 回归测试策略 波及效应分析 程序切片 回归测试的花费 总结
7-2 Chapter 7
0C202 Software Testing
为什么要回归测试？
Slicing Criterion: <1, { a } > Slice: 1. a = 1; 3. c = a * a; 4. d = a * b; 5. e = c + d;
向后切片
Slicing Criterion: <5, { d } > Slice: 1. a = 1; 2. b = 2; 4. d = a * b; 5. e = c + d;
0C202 Software Testing
A
B
D
E
7-12 Chapter 7
用这个方法，我们可以决定是否是新版本的A、B、 C中的某一组件有错。也可以重复多次运行测试用例 以查明导致用例失败的具体组件。 问题是这个方法安全吗？