系统测试是软件测试的一种类型，对系统整体进行检查。
它涉及到整合你所开发的软件的所有单个模块和组件，以测试系统是否按照预期的方式一起工作。
系统测试是一个重要的软件测试步骤，它将进一步使测试团队验证构建的质量，然后再发布给终端用户。
在这篇文章中，我们将探讨系统测试：它是什么，它如何工作，谁进行系统测试，以及测试团队可以采取什么方法和工具来使系统测试更快、更可靠。
简而言之，你会在这里找到关于系统测试的所有知识。
什么是系统测试？
系统测试是软件测试的一种类型，总是在整个系统上进行。 它检查系统是否符合其要求，无论这些要求是什么。
测试人员进行系统测试，在各个模块和组件被整合在一起后，评估系统的功能和非功能要求。
系统测试是黑匣子测试的一个类别，这意味着它只测试软件的外部工作特性，而不是测试应用程序的内部设计。
测试人员不需要对软件代码的编程和结构有任何了解，就可以在系统测试期间全面评估软件构建。 相反，测试人员只是从用户的角度评估软件的性能。
1.我们什么时候需要做系统测试？
系统测试是在集成测试之后、验收测试之前进行的。 系统测试是由软件测试团队定期进行的，以确保系统在开发过程中的关键阶段按规定运行。
进行系统测试的一些场合的例子是：
在开发新的软件版本期间。
在应用启动期间，当α-和β-测试发生时。
●单元和集成测试完成后。
● 当系统构建的要求完成后。
当其他测试条件得到满足时。
像其他形式的软件测试一样，建议定期进行系统测试，以确保软件按规定运行。
进行系统测试的频率取决于你的团队的资源以及你用来进行系统软件测试的方法和工具。
2.当你不需要系统测试时
如果你还没有进行初步测试，如烟雾测试、单元测试和集成测试，那么你还没有准备好开始系统测试。
在集成测试完成后进行系统测试总是很重要的，但是如果你遇到了导致系统测试失败的bug和问题，你可以停止系统测试，回到开发和bug修复上，然后再继续进行。
3.谁参与了系统测试？
系统测试是由测试人员和QA团队进行的，而不是开发人员。 系统测试只考虑软件的外部元素，或者换句话说，用户试图访问软件功能的体验。
这意味着进行系统测试的测试人员不需要任何关于计算机编码、编程和其他可能需要开发人员投入的软件开发方面的技术知识。
唯一的例外是在自动系统测试的情况下，这可能需要开发人员的一些投入，这取决于你如何处理这个问题。
在系统测试中我们要测试什么？
系统测试是软件测试的一种类型，用于测试软件的功能和非功能方面。
它可以用来测试大量的功能和特性，其中许多在系统测试的类型下有更深入的介绍。
系统测试验证的一些软件方面详见下文。
1.功能性
测试人员使用系统测试来验证已完成的系统的不同方面是否具有应有的功能。
之前的测试可以用来评估内部代码的结构和逻辑，以及不同模块如何整合在一起，但系统测试是第一步，以这种方式测试软件功能的整体。
2. 整合
系统测试测试不同的软件组件如何一起工作，以及它们是否能顺利地相互整合。
测试人员还可以测试外部外设，以评估这些外设如何与软件互动，以及它们是否正常运作。
3.预期产出
测试人员在系统测试中像用户一样使用软件，以验证软件在正常使用中的输出。 他们检查软件的每个功能和非功能特性的输出是否符合预期。
如果软件的表现不尽如人意，那么明显的结论是它需要进一步的开发工作。
4.缺陷和错误
系统测试是用来评估软件在多个平台和操作系统上的功能和可靠性。
系统测试人员验证软件在所有预期运行的平台上没有错误、性能问题和兼容性问题。
进入和退出标准
进入和退出标准用于系统测试，以确定系统是否准备好进行系统测试，以及是否满足系统测试要求。
换句话说，进入和退出标准帮助测试人员评估何时开始系统测试，何时结束系统测试。
进入标准
进入标准确定了测试人员应该何时开始系统测试。
项目之间的准入标准可能不同，这取决于测试的目的和所遵循的测试策略。
进入标准规定了系统测试开始前必须满足的条件。
1.测试阶段
在大多数情况下，在系统测试开始之前，被测试的系统已经完成了集成测试，并满足了集成测试的退出要求，这一点很重要。
集成测试不应该发现组件集成的重大错误或问题。
2.计划和脚本
在系统测试开始之前，测试计划应该已经写好，签署并批准。
你还需要提前准备好测试案例，以及准备好执行的测试脚本。
3.准备情况
检查测试环境是否准备好了，测试的所有非功能要求是否都有了。
不同项目的准备标准可能不同。
退出标准
退出标准决定了系统测试的结束阶段，并确定了系统测试必须满足的要求，才算完成。
退出标准通常以单一文件的形式呈现，简单地确定该测试阶段的可交付成果。
1.执行
完成系统测试的最基本的退出标准是，系统测试计划和进入标准中列出的所有测试案例都已被正确执行。
2.虫子
在退出系统测试之前，检查是否有任何关键或优先的错误处于开放状态。
中等和低优先级的bug可以保持开放状态，只要它们的实施得到了客户或最终用户的认可。
3.报告
在系统测试结束前，应提交一份退出报告。 这份报告记录了系统测试的结果，并证明测试达到了要求的退出标准。
系统测试的生命周期
系统测试生命周期描述了系统测试的每个阶段，从计划阶段到报告和完成。
了解系统测试生命周期的每个阶段将帮助你了解如何进行系统测试，以及它是如何工作的。
阶段1：创建一个测试计划
系统测试的第一个阶段是创建一个系统测试计划。
测试计划的目的是概述测试案例的期望以及测试策略。
测试计划通常定义了测试目标和目的、范围、领域、可交付成果、时间表、进入和退出标准、测试环境，以及那些参与软件系统测试的人的角色和责任。
第二阶段：创建测试案例
系统测试的下一个阶段是创建测试案例。
测试用例定义了你在系统测试中要测试的精确功能、特性和指标。 例如，你可能会测试一个特定的功能是如何工作的，或者一个特定的加载时间是多长。
对于每个测试用例，指定一个测试用例的ID和名称，以及关于如何测试这个场景的信息和测试用例的预期结果是什么。
你也可以在这里概述每个测试案例的通过/失败标准。
第三阶段：创建测试数据
一旦你创建了测试案例，你就可以创建执行测试所需的测试数据。
测试数据描述了测试团队需要的输入，以测试他们的行动是否导致了预期的结果。
第四阶段：执行测试案例
这个阶段是大多数人提到系统测试时可能想到的：测试用例的执行或实际测试本身。
测试团队将单独执行每个测试案例，同时监测每个测试的结果，并记录他们遇到的任何错误或故障。
第五阶段：报告和修复bug
在执行完测试用例后，测试人员会写一份系统测试报告，详细说明测试过程中出现的所有问题和错误。
测试发现的一些错误可能很小，很容易修复，而另一些错误则可能使构建工作落后。 修复这些出现的bug，并再次重复测试周期（包括其他类型的软件测试，如烟雾测试），直到没有重大bug的情况下通过。
厘清困惑：系统测试VS集成测试VS用户验收测试
许多人将系统测试与其他类型的软件测试混淆，如集成测试和用户验收测试。
虽然系统测试、集成测试和用户验收测试确实有一些共同的特点，但它们是不同类型的测试，有不同的目的，每种类型的测试都必须独立于其他类型的测试进行。
什么是集成测试？
集成测试是软件测试的一种类型，软件模块和组件作为一个群体进行测试，以评估它们在一起的集成程度。
集成测试是软件测试的第一种类型，用于测试单个模块的协同工作。
集成测试是由测试人员在QA环境中进行的，它是必不可少的，因为它暴露了单独编码的组件在一起交互时可能出现的缺陷。
系统测试和集成测试之间有什么区别？
虽然系统测试和集成测试都是将软件构建作为一个整体进行测试，但它们是不同类型的软件测试，工作方式截然不同。
集成测试首先发生，系统测试在集成测试完成后进行。 系统测试和集成测试的其他主要区别是：
1.1.目的：
集成测试的目的是评估各个模块在集成时是否能正常工作。 系统测试的目的是测试系统如何作为一个整体工作。
2.类型：
集成测试纯粹是测试功能，它不是验收测试的一种。
相比之下，系统测试同时测试功能和非功能特性，它属于验收测试的范畴（但不是用户验收测试）。
3.技术：
集成测试同时使用黑盒和白盒测试，从用户和开发者的角度评估软件构建，而系统测试则纯粹使用黑盒测试方法，从用户的角度测试软件。
4.价值：
集成测试用于识别接口错误，而系统测试则用于识别系统错误。
什么是用户验收测试？
用户验收测试，或称UAT，是一种由最终用户或客户进行的软件测试，以验证软件是否符合预期要求。
用户验收测试是在软件进入生产环境之前进行的最后一种测试形式。
它发生在功能测试、集成测试和系统测试已经完成之后。
系统测试和用户验收测试之间有什么区别？
用户验收测试和集成测试都是验证软件构建是否正常工作，这两种类型的测试都侧重于软件如何作为一个整体工作。
然而，系统测试和用户验收测试之间有很多区别：
1.测试人员：
系统测试是由测试人员（有时是开发人员）进行的，而用户验收测试是由终端用户进行的。
2.2.目的：
用户验收测试的目的是评估软件构建是否满足最终用户的要求，而系统测试的目的是测试系统是否满足测试者的要求。
3.3.方法：
在系统测试期间，软件构建的各个单元作为一个整体被整合和测试。 在用户验收测试过程中，系统被最终用户作为一个整体来测试。
4.阶段：
系统测试是在集成测试完成后，在用户验收测试进行前进行的。 用户验收测试是在产品发布之前进行的，也就是早期采用者。
系统测试的类型
如果你想测试你的软件构建的整体工作情况，有超过50种不同的系统测试，你可以采用。
然而，在实践中，大多数测试团队实际上只使用了这些类型中的少数几种系统测试。
你使用的系统测试的类型取决于很多不同的因素，包括你的预算、时间限制、优先级和资源。
1.功能测试
功能测试是系统测试的一种类型，旨在检查软件的各个特性和功能，并评估它们是否能正常工作。
这种类型的系统测试可以手动或自动进行，它是测试团队进行的系统测试的核心类型之一。
2.性能测试
性能测试是系统测试的一种类型，涉及测试应用程序在正常使用过程中的性能如何。
这也被称为合规性测试，通常意味着测试一个应用程序在多个用户同时使用时的性能。
在性能测试中，测试人员将查看加载时间以及错误和其他问题。
3.负载测试
负载测试是一种系统测试，测试人员进行这种测试是为了评估一个应用程序处理重负载的能力。
例如，测试人员可能会测试当很多很多的用户试图在同一时间执行同一任务时，应用程序的运行情况如何，或者应用程序同时执行多个任务的情况如何。
4.可扩展性测试
可扩展性测试是一种软件系统测试，测试软件的扩展性如何，以满足不同项目和团队的需求。
这是一种非功能测试，涉及评估软件对不同数量的用户或在不同地点和不同资源下使用时的表现。
5.可用性测试
可用性测试是系统测试的一种类型，涉及测试应用程序的可用程度。
这意味着测试人员评估和评价应用程序的导航和使用有多容易，其功能有多直观，以及是否存在任何可能导致可用性问题的错误或问题。
6.可靠性测试
可靠性测试是系统集成测试的一种类型，检查软件的可靠程度。
它要求在受控环境中测试软件的功能和性能，以评估一次性测试的结果是否可靠和可复制。
7.配置测试
配置测试是系统测试的一种类型，评估系统在与各种类型的软件和硬件一起工作时的表现。
配置测试的目的是确定软件和硬件的最佳配置，使整个系统的性能最大化。
8.安全测试
安全测试是一种系统测试，评估软件在安全性和保密性方面的表现。
安全测试的目的是识别任何潜在的漏洞和危险，这些漏洞和危险可能是数据泄露和违规的来源，可能导致金钱、机密数据和其他重要资产的损失。
9.迁移测试
迁移测试是对软件系统进行的一种系统测试，以评估它们如何与旧的或新的基础设施互动。
例如，测试人员可能会评估旧的软件元素是否可以迁移到新的基础设施而不产生错误和误差。
你需要开始运行系统测试的东西
在系统测试开始之前，重要的是你有一个明确的计划，汇集成功和顺利的系统测试过程所需的资源和工具。
无论你是手动、自动或同时使用两种方法进行测试，这都是一个相对复杂的过程，所以在开始之前知道你需要什么，是减少测试期间延误和中断风险的最好方法。
1.一个稳定的构建，几乎可以启动了
系统测试是软件测试的最后阶段之一，它发生在发布之前：在系统测试之后发生的唯一类型的测试是用户接受测试。
重要的是，在开始系统测试之前，你已经进行了其他类型的软件测试，包括功能测试、回归测试和集成测试，并且你的软件构建已经满足了这些类型软件测试的退出标准。
2.系统测试计划
在你开始测试之前，写好正式的文件，概述你要进行的测试的目的和目标，并定义系统测试的进入和退出标准。
你可以用这个计划来概述你要测试的各个测试场景，或者定义你对系统性能的期望。
系统测试计划应该使测试人员很容易按照计划来设计和进行系统测试。
3.测试案例
在系统测试开始之前，列出你在系统测试中要测试的测试用例是很重要的。
测试用例可能并不详尽，但它们应该足够完整，以测试系统最重要的功能和非功能特性，并对系统的整体工作情况作出准确的概述。
4.技能和时间
确保在你的系统测试开始之前，你为系统测试分配足够的资源。
系统测试可能需要相对较长的时间，特别是与其他类型的测试如烟雾测试相比。
你需要确定你的团队中哪些人要进行测试，以及在测试开始前他们需要封锁多长时间。
5.系统测试工具
系统测试可以手动进行，也可以自动进行，但无论你采取哪种测试方法，都可以通过采用有助于测试的不同方面的工具和技术来简化和优化你的系统测试工作流程。
例如，你可以使用人工智能工具来自动化你的一些系统测试，或者你可以使用文件管理软件来帮助跟踪测试的进展和结果。
系统测试过程
在你开始之前，重要的是要了解系统测试过程以及如何进行其每个步骤。
这个分步骤的计划遵循前面详述的系统测试生命周期，但进一步详细概述了系统测试中涉及的各个步骤。
第1步：创建一个系统测试计划
在你开始系统测试之前，创建你的系统测试计划。 每个系统测试计划都会有所不同，但你的计划至少应该包括测试目的的概要，以及决定何时开始测试和何时完成测试的相关进入和退出标准。
第2步：生成测试方案和测试案例
下一个阶段是生成测试方案和测试用例，准确概述你要测试的内容和你要如何测试它。
包括现实生活中的测试场景，测试软件在典型使用情况下是如何工作的，对于你写的每个测试案例，包括测试的通过和失败标准以及预期结果的细节。
第3步：创建所需的测试数据
为你计划执行的每个测试场景创建所需的测试数据。
你计划运行的每个测试方案需要的测试数据，是影响或被每个特定测试影响的任何测试数据。
有可能手动生成测试数据，或者如果你想节省时间并有足够的资源，你可以将这个阶段自动化。
第4步：建立测试环境
下一步是设置测试环境，准备运行你的系统测试。 如果你建立一个类似生产的测试环境，你将从你的系统测试中获得更好的结果。
确保你的测试环境包括你在配置和集成测试期间要测试的所有软件和硬件。
第5步：执行测试案例
一旦你建立了测试环境，你就可以执行你在第二步创建的测试案例。
你可以手动执行这些测试用例，也可以使用脚本来自动执行测试用例。
当你执行每个测试案例时，记下测试的结果。
第6步：准备好错误报告
一旦你执行了所有列出的测试案例，你就可以利用每个测试的结果来写出错误报告，详细强调你在系统测试中发现的所有错误和缺陷。
将此报告转给开发人员，以便进行错误修复和修正。 错误修复阶段可能需要一些时间，这取决于你所发现的错误的复杂性和严重性。
第7步：错误修复后重新测试
一旦软件开发人员在修复了bug后将软件送回进一步测试，就必须再次对软件构建进行重新测试。
至关重要的是，在这一步没有显示出任何错误或缺陷之前，系统测试不应视为完成。
假设所有的bug都已经被修复，并且现在已经准备好进入用户验收测试，这是不够的。
第8步：重复循环
最后一步是简单地重复这个循环，需要多少次才能通过第七步而不发现任何错误或缺陷。
一旦系统测试通过，并且你已经满足了系统测试计划中列出的所有退出标准，就该进入用户验收测试，并最终发布产品了。
手动与自动系统测试
像其他类型的软件测试一样，系统测试既可以由人类测试人员手动进行，也可以由软件至少部分自动化。软件测试自动化简化了测试过程，节省了时间和金钱，但有时进行人工系统测试也很重要。
手动和自动系统测试都有优点和缺点，在决定进行哪种类型的系统测试之前，了解这些是很重要的。
手动系统测试
人工系统测试是指手动进行系统测试，而不是将所有测试过程的一部分自动化。
人工系统测试比自动测试需要更长的时间，但这也意味着测试过程得益于人类的洞察力和判断力。
人工测试经常与自动化测试相结合，以最大限度地提高系统测试和其他类型的软件测试的效率和准确性。
1.进行手工系统测试的好处
进行手动系统测试有许多好处，这些好处解释了为什么许多测试团队选择继续进行手动测试以及自动化测试，甚至在自动化测试脚本之后。
复杂性
手工测试适用于测试复杂的测试场景，这些场景不一定容易实现自动化。
如果你的系统测试的要求很复杂或很详细，你可能会发现手动测试这些场景比为它们编写自动测试脚本要容易。
探索性测试
当你自动化任何种类的软件测试时，测试遵循它的脚本，并且只测试那些你已经编程的测试评估的功能。
相比之下，当你进行手动测试时，你可以选择探索不同的功能，当它们引起你的兴趣时，例如，如果你注意到软件界面中的一些东西看起来不符合要求。
简洁性
一旦你写好了你的自动化测试脚本，自动化测试就很容易了。 但这通常需要开发专家首先编写测试脚本，而较小的测试团队可能没有资源来实现这一目标。
手动测试不需要技术专长或编码知识。
2.手动系统测试的挑战
手动测试也带来了自己的挑战。 与那些同时使用两种方法的团队相比，只进行手动系统测试而不加入自动测试元素的软件测试团队可能会发现自己处于不利地位。
耗时的
如你所料，进行手动系统测试比自动系统测试更耗时。 当需要进行敏捷测试时，这尤其是一个弱点。
这意味着进行定期或非常彻底的系统测试不太现实，而这又可能影响结果的可靠性和范围。
人为错误
当人类进行手动测试时，总是有人为错误的空间。 人类会犯错，会感到无聊或分心，在进行重复的、耗时的测试时，这种情况特别容易发生，因为这些测试可能更容易使测试人员感到疲惫。
测试覆盖率
手动测试不能提供与自动测试相同的覆盖范围。
因为测试人员必须自己进行手动测试，与自动测试相比，手动测试时不可能覆盖那么多地方，这可能导致测试结果不那么全面。
何时使用人工软件测试
手工软件测试并没有被自动化测试所取代，手工测试仍然是系统测试过程中的一个重要阶段。
手工测试适用于规模较小的软件团队，他们可能没有资源独立进行自动化系统测试，即使是已经采用自动化测试的团队也应该使用手工测试来评估更复杂的测试场景或探索性测试提供价值的测试案例。
系统测试自动化
通过自己编写测试脚本或使用超自动化工具和流程来实现系统测试的部分或全部自动化，是可以实现系统测试自动化的。
大多数情况下，自动化系统测试与人工系统测试相结合，以提供覆盖率、效率和准确性的最佳平衡。
1.系统测试自动化的好处
自动化系统测试越来越受欢迎，部分原因是自动化测试工具的广泛使用，使软件系统测试容易实现自动化。
自动化系统测试有很多好处，特别是与人工测试相结合时。
效率
自动测试比人工测试更有效率，因为在测试人员和开发人员进行其他任务时，有可能在后台运行自动测试。
这使得在更经常的基础上进行自动化测试更加实际，并减少了在自动化测试建立后委托大量资源进行测试的需要。
更大的测试覆盖面
自动测试通常可以比手动测试覆盖更大的软件构建区域，这在很大程度上是因为其效率的提高。
当测试人员手动进行系统测试时，他们必须挑选最重要的测试案例进行评估，而自动化测试使软件团队能够在更短的时间内灵活地测试更多的场景。
消除人为错误
自动测试不象手工测试那样容易受到人为错误的影响。
当进行重复的、耗时的、会使人工测试人员疲惫不堪的测试时，自动测试会继续以同样的速度和准确度测试软件。
人类也更有可能专注于发现容易的错误，而不是困难的错误，这可能导致一些重要但不太明显的错误被遗漏。
标准化测试
当你写一个脚本来实现系统测试的自动化时，你是在为你的软件测试工具创建一套指令。
这有效地规范了你所运行的软件测试，并确保你每次运行测试时，都是按照相同的标准运行相同的测试和测试软件。
2.系统测试自动化的挑战
自动系统测试并不完美，这就是为什么它经常与人工测试一起进行以获得最佳效果。 它比人工测试更有效，但在深度或定性数据方面可能提供不了那么多。
灵活性
因为自动化测试总是遵循一个脚本，所以没有灵活性来测试那些写入测试脚本之外的机制或功能。
虽然这导致了一致性，但它确实意味着如果在规划阶段没有考虑到错误，就可能会错过这些错误。
资源
自动测试需要时间和资源来建立。
虽然有可能使用现成的软件和工具来实现系统测试的自动化，但大多数时候，这些仍然需要根据你的软件要求进行调整。
传统上，自动化测试意味着要投入技术资源来编写和正确运行自动化测试，尽管越来越多的工具如ZAPTEST在无代码界面中提供先进的计算机视觉软件自动化。
复杂的测试案例
在大多数情况下，不可能在完全不依赖任何人工测试的情况下实现100%的系统测试自动化。
当你需要测试大多数自动化工具无法测试的复杂测试场景时，这一点尤其正确。
3.何时实施自动化系统测试
如果你的测试团队有资源来实现自动化测试，无论是通过编写自定义的测试脚本还是使用自动化工具来编写，自动化测试可以使系统测试更有效率，更可靠。
然而，即使你对自动化测试的质量和覆盖面有信心，继续进行手动测试始终是很重要的，因为自动化测试不能复制只有手动测试才能提供的深度和洞察力。
结论：自动系统测试与手动系统测试
自动系统测试和手动系统测试在软件开发的测试阶段都很重要。
虽然较小的公司可能一开始只进行手动系统测试，因为自动化测试需要额外的投资或资源，但大多数测试团队在实际情况允许的情况下，会采用涉及自动化测试的综合方法。
通过将自动化测试与人工测试相结合，测试团队可以在不影响系统测试的任何结果的情况下最大限度地提高效率、准确性和灵活性。
系统测试的最佳实践
如果你想优化你的系统测试工作流程以获得最大的效率和准确性，遵循系统测试的最佳实践是最好的方法。
最佳实践可以帮助你确保在系统测试阶段不遗漏任何东西，并确保你的系统测试始终是一个高标准。
1.充分计划系统测试
所有的系统测试应该从一个正式的测试计划开始，清楚地列出测试案例和测试过程中要使用的方法。
从一个正式的计划开始，可以减少测试过程中发生延误的风险，并防止因含糊不清而产生的干扰。
它确保所有相关方知道他们的角色是什么，以及他们的责任是什么。
2.始终写出详细、准确的报告
重要的是，系统测试总是被很好地记录下来，否则测试人员和软件开发人员可能发现不容易根据你的测试结果采取行动。
为你进行的每一次测试写出清晰、彻底的报告，详细说明你发现的任何bug，准确说明如何复制这些bug，并确定软件在修复后应如何表现。
确保你的错误报告毫不含糊，易于理解。
3.在真实设备上测试
通常，测试团队选择在测试环境中复制不同的设备，而不在不同设备上实际测试软件。
如果你构建的软件要在不同的平台上使用，如手机，即 安卓、iOS等平板电脑、网络和台式机，即。 Windows、 Linux等，确保你在这些设备上进行测试，以评估它们在不同负载下的表现，或者网络连接问题是否会在特定平台上造成问题。
4.在可能的情况下实现测试自动化
通常最好是将手动系统测试与自动系统测试相结合，以获得最佳效果。
如果你还没有尝试过自动化系统集成测试，尝试一下RPA+软件测试工具，至少可以帮助你实现部分系统测试的自动化，这将使你在不影响结果准确性的情况下提高覆盖率和效率。
5.每个案例测试一个功能
当你写测试用例时，在可能的情况下，专注于每个案例只测试一个功能。
这使得在未来的测试中更容易重复使用这些测试用例，并使开发人员更清楚地了解错误是如何产生的，以及它们是由哪些功能触发的。
系统测试的输出类型
当你运行系统测试时，重要的是要知道从你的测试中期待什么类型的输出，以及如何使用这些输出来通知未来的开发和测试。
测试输出实际上是你通过进行系统测试获得的资产和信息。
1.测试结果
你的测试结果包括关于软件在你进行的每个测试案例中的表现的数据，以及你预期软件的表现的比较。
这些结果有助于确定每个测试用例是通过还是失败，因为如果软件的表现与你的预期不符，这通常意味着它失败了。
2.缺陷记录
缺陷日志是在系统测试期间发现的所有bug和缺陷的日志。
缺陷日志列出了所有发现的缺陷，以及其他重要信息，如每个缺陷的优先级、每个缺陷的严重程度、以及缺陷的症状和描述。
你还应该记下检测到该错误的日期和其他信息，以帮助开发人员再次复制该错误。
3.测试报告
测试报告通常是完成系统测试的退出标准的一部分，它通常包括所进行的测试的总结，GO/No-Go建议，阶段和迭代信息，以及测试日期。
你还可以包括有关测试结果的任何其他重要信息，或者在这份报告中附上一份缺陷清单。
系统测试的例子
系统测试的目的是将系统作为一个整体进行测试，这意味着它们测试所有不同的软件单元作为一个系统一起工作。
系统测试的例子可以帮助你更好地理解什么是系统测试以及它所测试的内容。
1.测试功能
一个软件工程师团队正在组建一个新的购物应用程序，帮助杂货店更有效地挑选和包装在线订单。
该应用程序由多个不同的模块组成，其中每个模块已经在单元测试中独立测试，并在集成测试中与其他模块一起测试。
系统测试是第一次对所有模块进行统一测试，测试人员设计测试用例来评估应用程序的每个单独功能，并在所有模块一起运行时检查它们的功能是否符合预期。
2.测试加载时间
一组软件测试人员正在测试一个应用程序在不同压力水平下的不同点的加载速度。
他们创建测试案例，描述应用程序处于什么类型的压力之下（例如，有多少用户同时使用它），以及用户试图加载什么功能和特性。
在系统测试期间，负载时间被记录到测试报告中，被认为太慢的负载时间将触发另一个阶段的开发。
3.测试配置
当建立一个可以与很多不同的外围设备一起使用的视频游戏时，包括电脑鼠标、VR头盔和游戏板，软件测试人员进行配置测试，以测试这些外围设备与游戏的配合情况。
他们通过每个测试场景单独和一起测试每个外设，记下每个外设在游戏中的不同点的表现，以及性能是否比预期的还要差。
通过系统测试发现的错误和漏洞的类型
当你进行系统测试时，你所进行的测试将允许你在软件中找出在单元测试和集成测试中没有发现的错误和漏洞。
在系统测试过程中，有可能发现多种类型的bug，有时是因为它们以前被遗漏了，或者通常是因为它们只在系统整体运行时出现。
1.性能误差
系统测试可以突出软件构建的速度、一致性和响应时间方面的性能错误。
测试人员可能会评估软件在执行不同任务时的表现，并记录下使用过程中出现的任何错误或延迟。 这些是性能缺陷，可能被认为严重到需要进一步开发，也可能不被认为严重到需要进一步开发。
2.安全错误
在系统测试过程中，有可能发现安全错误，突出系统安全层中的漏洞。
安全测试是在系统测试阶段进行的，它可以用来识别软件内的加密错误、逻辑错误和XSS漏洞。
3.可用性错误
可用性错误是指那些使人难以按照预期方式使用应用程序的错误。 它们可能给用户带来不便，这反过来又会导致用户放弃应用。
可用性错误的一些例子包括一个复杂的导航系统或一个不容易在平台的所有方面进行导航的布局。
使用可用性工具，错误可能会在测试过程的早期被发现，但它们也可能在系统测试中出现。
4.通讯错误
当软件的一部分试图与另一个模块进行通信，而一个错误导致该通信失败时，就会发生通信错误。
例如，如果软件提示用户下载一个新的更新，但当用户点击更新下载按钮时，无法找到该更新，这是一个通信错误。
5.错误处理错误
即使软件在正常工作时，有时也会出现错误。 也许是因为某个组件没有被正确安装，或者是因为用户没有正确操作。
然而，系统必须能够正确地处理这些错误，以帮助用户识别和解决这个问题。
如果错误信息不包含有关错误发生的充分信息，用户将无法修复错误。
系统测试中的常见指标
当你进行系统测试时，你可能会跟踪某些测试指标，以帮助你的测试团队监控系统测试的有效性，发现错误的频率，以及系统测试是否发生在测试周期的正确阶段。
例如，如果你跟踪测试通过的数量和失败的数量，发现系统测试失败的比例很高，你可能会得出结论，在测试周期的早期需要进行更彻底的测试，以便在系统测试开始前发现错误和误差。
1.绝对度量
绝对数是那些简单地给你一个绝对数而不是比例或比率的指标。
绝对指标可能是有用的，但由于它们是绝对数字，要解释它们的含义并不总是容易的。
绝对指标的一些例子包括系统测试持续时间，运行一个系统测试的时间长度，以及在系统测试期间发现的缺陷总数。
2.测试效率指标
测试效率指标帮助测试团队了解他们目前的系统测试程序的效率如何，尽管他们没有提供任何关于系统测试质量的信息。
测试效率指标的一些例子包括测试通过率和缺陷修复率。
通过的测试可以告诉你，你是否通过了太多的测试，从而错过了错误，特别是当你看到高的测试通过率指标与高的缺陷逃脱率一起出现时。
3.测试有效性指标
测试有效性指标告诉测试人员一些关于他们正在进行的系统测试的质量。
他们衡量系统测试在识别和评估系统内的bug和缺陷方面的效率如何。
总缺陷控制效率是测试有效性指标的一个例子，它显示了在测试阶段发现的错误与发布后发现的错误的比率。
4.测试覆盖率指标
测试覆盖率指标帮助测试人员了解他们的覆盖率在他们试图测试的整个系统中是如何完成的。
例如，你可能会衡量你的系统测试中有多少百分比是自动化的，或者到目前为止有多少必要的测试被执行。
需求覆盖率指标还可以帮助测试人员跟踪测试所需功能的比例是多少。
5.缺陷度量
缺陷指标是指以不同方式衡量缺陷存在的指标。 一些缺陷指标可能侧重于缺陷的严重性，而另一些缺陷指标可能侧重于缺陷的类型或根本原因。
常见缺陷指标的一个例子是缺陷密度，它衡量的是整个版本的缺陷总数。
缺陷密度通常表现为每1000行代码的缺陷数。
系统测试案例
系统测试用例是在系统测试中用来测试软件的功能以及是否符合开发人员、测试人员、用户和利益相关者的期望的测试场景。
1.什么是系统测试中的测试用例？
测试用例本质上是一种指令，它定义了要测试的内容，以及测试人员必须执行哪些步骤来测试每个单独的案例。
当你为系统测试编写测试用例时，重要的是包括测试人员执行每个测试所需的所有信息。 包括每个测试用例的测试用例ID，以及如何执行测试和你期望的结果的信息，以及每个测试用例的相关的通过和失败标准。
2.如何编写系统测试案例
如果你是写测试用例的新手，你可以按照下面的步骤来写系统测试用例。 为其他类型的软件测试编写测试用例是一个非常类似的过程。
- 定义你希望你的测试用例覆盖的区域。
- 确保测试用例易于测试。
- 对每个测试案例应用相关的测试设计。
- 给每个测试案例分配一个唯一的测试案例ID。
- 包括对如何运行每个测试案例的明确描述。
- 为每个测试用例添加前提条件和后置条件。
- 指定你期望从每个测试案例中得到的结果。
- 概述应该使用的测试技术。
- 在继续前行之前，请一位同事对每个测试案例进行同行评审。
3.系统测试案例的例子
使用示例测试用例可能有助于你编写自己的测试用例。 下面是两个系统测试用例的例子，测试人员可能用来测试一个应用程序或软件的功能。
杂货店扫描应用程序的价格验证
测试ID：0788
测试案例：验证项目价格
测试案例描述：扫描一个物品并验证其价格。
预期的结果：被扫描的价格应该与当前的股票价格一致。
结果：该项目以1美元的价格扫描，这与当前的股票价格一致。
通过/失败：通过。
管理软件端到端的交易响应时间
测试ID：0321
测试案例：主屏幕加载时间
测试案例描述：确保应用程序的加载屏幕在一个良好的时间内加载。
预期的结果：屏幕应在四秒或更短时间内加载。
结果：屏幕在6秒内加载。
通过/失败：不合格。
最佳系统测试工具
使用系统测试工具是简化测试过程的最简单方法之一，可以减少测试团队花在耗时的手动任务上的时间。
系统测试工具可以为你实现系统测试过程的自动化，或者它们可以使编写测试用例和跟踪测试进展更容易。
五个最好的免费系统测试工具
如果你还没有准备好在系统测试工具上花一大笔预算，但你想探索外面的东西，也许同时可以提高你的系统测试过程的效率，好消息是，网上有很多免费的测试工具。
免费测试工具不能提供与付费测试工具相同的所有功能，但它们可以为小型企业提供一种具有成本效益的方式来探索软件自动化和RPA。
1.ZAPTEST免费版
ZAPTEST是一套软件测试工具，可用于系统测试和其他类型的软件测试。
ZAPTEST有免费和付费的企业版，但免费版是小型公司和想迈出测试自动化第一步的企业对自动化系统测试的完美介绍。
ZAPTEST可以实现桌面和手持设备的系统测试自动化，并允许测试人员无需编码即可实现测试自动化。
2.硒
Selenium是市场上最知名的开源测试工具之一。
Selenium的免费版本提供了自动化测试工具，可用于系统测试、回归测试和错误再现，你可以用它来创建自己的测试脚本，用于很多不同的测试场景。
然而，它确实以简单和易于使用为代价，对于非技术用户来说，可能相当难以学习。
3.浏览器
Appium是一个免费的系统测试工具，适合专门用于移动应用程序。
你可以使用Appium对设计用于iOS和Android智能手机和平板电脑的应用程序进行自动化系统测试。
这个免费工具不适合与桌面应用程序一起使用，这是它最大的弱点之一。
3.测试链接
如果你只是想让计划、准备和记录系统测试变得更容易，Testlink是一个伟大的免费工具，使测试文档管理变得简单。
使用Testlink，你可以很容易地将报告分门别类，在你需要的时候找到你需要的信息。
Testlink是一个有价值的测试工具，无论你是进行系统测试，烟雾测试，还是任何其他类型的软件测试。
5.负载
Loadium是一个免费的测试工具，专门为性能测试和负载测试而设计。
虽然它专注于性能和负载测试，但对于希望自动化整个端到端测试的用户来说，这代表了一个显著的弱点。
4个最好的企业系统测试工具
随着你的业务增长，你可能发现免费的测试工具不再适合你的要求。 很多免费工具，如ZAPTEST，都提供企业版和免费版。
1.ZAPTEST企业版
ZAPTEST提供了一个企业版的测试工具，它拥有与免费工具相同的易于使用的功能和直观的界面，但对于那些可能需要更密集的测试或想要测试更复杂的软件构建的大型团队来说，其扩展性更好。
ZAPTEST的企业版提供无限的性能测试和无限的迭代，以及指定的ZAP认证专家作为客户团队的一部分随叫随到提供支持（这本身就代表了与任何其他自动化工具相比的显著优势）。
其无限许可证模式也是市场上的一个领先主张，确保企业在任何时候都有固定的成本，无论其增长速度如何。
2.SoapUI
SoapUI是一个测试工具，它使管理和执行各种网络服务平台和API的系统测试成为可能。
测试团队可以使用SoapUI来最大限度地减少他们花在耗时的任务上的时间，并制定更彻底和有效的测试策略。
3.检验报告
Testigma是一个现成的软件测试平台。 它允许产品团队在网站、移动应用和API上自动计划和执行软件测试。
该平台是用Java建立的，但它可以用简单的英语编写的测试脚本工作。
4.测试机器人
TestingBot是一个相对低成本的企业解决方案，适合那些想在这一领域进行试验而又不想从一开始就花费大量资金的企业。 TestingBot为测试人员提供了一种简单的方法，使用3200个浏览器和移动设备组合的网格来测试网站和移动应用程序。
它缺乏大型企业工具的功能，但对于预算较低的公司来说，它是一个不错的选择。
什么时候应该使用企业级与免费的系统测试工具
你是选择使用企业级还是免费的系统测试工具，取决于你的团队的需求、你的预算、你的优先级和你的工作日程。
不言而喻，与免费工具相比，企业工具提供了更多的特性和功能，但对于预算没有多少空间的小公司来说，免费工具是一个绝妙的选择。
如果你的业务在增长，或者你发现你的测试团队在系统测试和其他类型的软件测试上花费的时间比你希望的要多，升级到企业测试工具并学习如何充分利用这些工具可以帮助你进一步扩大你的业务，以满足不断增长的需求。
此外，通过使用像ZAPTEST Enterprise这样的工具，它提供了创新的软件+服务模式，以及无限制的许可模式，保证了你既能缩小技术知识的差距，又能保持你的成本固定，无论你的增长速度有多快，使用的工具有多少。
系统测试检查表、技巧和窍门
在你开始系统测试之前，通过下面的系统测试清单，并遵循这些提示来优化你的系统测试的准确性、效率和覆盖率。
系统测试清单可以帮助确保你在进行系统测试时已经涵盖了你需要的一切。
1.在设计阶段让测试人员参与进来
虽然测试人员通常在开发和设计阶段完成之前不会在软件上工作，但通过让测试人员早期参与，测试人员更容易理解不同的组件是如何一起工作的，并将其纳入他们的测试。
这往往会导致更有洞察力的探索性测试。
2.编写清晰的测试案例
当你写你的测试用例时，确保它们是清晰和明确的。
测试人员应该能够阅读测试用例，并立即理解需要测试的内容和如何测试。
如果需要的话，说明在哪里可以找到需要测试的功能，以及在系统测试过程中要采取哪些步骤。
3.最大限度地提高测试覆盖率
当你进行系统测试时，通常不可能达到100%的测试覆盖率，即使你使用自动化工具。
然而，你的测试覆盖率越大，你就越有可能在发布前发现并修复错误。
尽量使测试覆盖率达到至少90%或尽可能接近这个数字。
4.彻底分析结果
彻底分析每个系统测试的结果，并在你的文档中清楚地报告错误和缺陷。
你能提供的关于bug的细节越多，开发者以后复制这些bug就越容易。
如果你对为什么会出现bug以及如何修复bug有想法，请在你的测试结果中包括这些。
5.超越需求测试
不要只是测试你的应用程序，看它们是否做了它们应该做的事情。
测试你的软件是如何在其要求之外工作的，看看它对预定用途之外的任务和操作是如何反应的。 这可以帮助你发现否则你会错过的错误和缺陷。
实施系统测试时应避免的7个错误和误区
在第一次实施系统测试时，重要的是要注意测试团队经常犯的常见错误和陷阱。
知道这些错误是什么，就会很容易避免犯这些错误，这应该会提高你自己的系统测试的有效性和准确性。
1.开始时没有测试计划
在开始系统测试之前，建立一个详细的测试计划是很重要的。
如果你在没有计划的情况下开始集成测试，很容易忘记一些你打算执行的测试用例或测试计划之外的测试用例。
大多数人无法记住测试计划的全部细节，除非它被清楚地记录下来，而且它还可以防止团队将其传递给其他测试人员。
2.没有界定系统测试的范围
系统测试是一项多维度的任务，涉及到对单一软件构建的许多不同方面的测试。
根据你所开发的软件类型和你目前所测试的内容，系统测试的范围在不同的测试之间可以有很大的差异。
重要的是在测试开始前确定测试的范围，并确保测试团队的所有成员都理解这个范围。
3.忽视假阳性和假阴性结果
当系统测试通过时，尽管测试方案实际上并不像预期的那样工作，也会出现假阳性结果。
同样地，当一个测试尽管按预期工作而失败时，也会出现假阴性。
有时发现假阳性和假阴性是很困难的，特别是如果你只是看测试结果而不深入研究测试的实际产出。 在进行自动化系统测试时，假阳性和假阴性特别容易发生，而且容易被遗漏。
4.用类似类型的测试数据进行测试
如果你使用多种不同类型的测试数据，尽可能地改变你使用的测试数据的属性，将增加你的系统测试的覆盖率。
这意味着你不太可能错过错误和缺陷，并为你进行的测试增加价值。
通过涵盖不同类型的测试数据，你将获得一个更详细的关于产品在发布后将如何表现的图片。
5.忽视探索性测试
虽然遵循测试计划很重要，但为探索性测试留出空间也很重要，允许测试人员在测试中发现不同的特性和功能时进行尝试。
探索性测试通常可以发现新的错误，否则会被遗漏，或者在其他测试阶段已经被遗漏的错误。
你甚至可以通过组织测试果酱会议来安排探索性测试会议，测试人员都在规定时间内进行无计划的系统测试。
6.没有定期审查测试自动化结果
如果你是软件系统测试的新手，特别是自动化测试，你可能会认为你可以只设置测试的运行，然后离开它。
但是定期审查测试自动化结果并在必要时对测试自动化代码进行修改是很重要的。
例如，如果你对正在测试的软件做了任何改动，这些应该反映在自动化测试的代码中。
仔细阅读自动化测试结果，了解测试的每个输出，而不仅仅是通过/失败的结果。
7.使用错误的自动化工具
今天有很多自动化工具，其中一些是免费使用的，另一些则是用户必须支付月费的。
虽然初学者通常选择开源工具，但重要的是要确保你选择使用的工具适合你的要求，并提供你需要的功能。
例如，开源工具因其有限的功能、非直观的用户界面和非常困难的学习曲线而臭名昭著。相比之下，像ZAPTEST免费版这样的全栈测试工具，在一个易于使用的无代码界面中提供高端测试和RPA功能，如1SCRIPT、跨浏览器、跨设备、跨平台技术，既适合非技术性测试人员，也适合经验丰富的测试人员。
而且，有时候，如果一个稍微昂贵的企业级自动化工具所提供的功能更适合你的项目，那么它是值得投资的。
结论
系统测试是软件测试的一个重要阶段，它将系统作为一个整体来检查，并确保每一个单独的组件都能顺利和有效地工作。
这是软件测试的阶段，在集成测试之后和用户验收测试之前，是初始发布前最后的正式软件测试阶段之一。
系统测试允许测试人员识别不同种类的错误，包括功能和非功能错误，以及可用性错误和配置缺陷。
可以手动进行系统测试，也可以自动进行系统测试，尽管在大多数情况下，建议采取混合方法，以最大限度地提高效率，同时仍然为探索性测试留出空间。
通过遵循最佳实践和避免系统测试的常见陷阱，测试团队可以进行准确、有效的系统测试，涵盖构建的大多数关键领域。
常见问题和资源
如果你是系统测试的新手，网上有很多资源可以帮助你了解更多关于系统测试和如何进行系统测试。
以下是一些有用的在线系统测试资源的细节，以及一些关于系统测试的最常见问题的答案。
1.关于系统测试的最佳课程
参加系统测试或软件测试的在线课程可以帮助QA专业人士发展他们对系统测试的理解，并获得证明该知识的资格。
像Coursera、Udemy、edX和Pluralsight这样的在线培训网站为专业人士和初学者提供免费和付费的软件测试和自动化课程。
系统测试的一些在线课程的例子是：
- 完整的2023年软件测试训练营，Udemy
- 软件测试和自动化专业，Coursera
- 自动化软件测试，edX
- 用Python进行自动化软件测试, Udemy
- 商业分析师：软件测试流程和技术, Udemy
寻找符合你的经验水平和适合你预算的在线课程。 如果你在QA工作，你可以要求你的雇主赞助你参加软件测试的认证课程。
2.关于系统测试的5大面试问题是什么？
如果你准备面试一个可能涉及系统测试或其他类型的软件测试的角色，提前准备好常见面试问题的答案，可以帮助你在面试中的表现。
一些最常见的关于系统测试的面试问题包括：
- 系统测试与集成测试有什么不同？
- 自动化系统测试的优点和缺点是什么？
- 你能说出多少种系统测试的类型？
- 在系统测试过程中，你会如何最大化测试覆盖率？
- 你希望在系统测试中发现什么样的bug和缺陷？
你可以利用这些问题，在面试前按照STAR结构准备答案，用过去职业生涯中的例子来证明你对系统测试和其他类型的软件测试的了解。
3.关于系统测试的最佳YouTube教程
如果你是一个视觉学习者，你可能会发现通过观看系统测试的视频更容易理解什么是系统测试，以及它如何与其他类型的软件测试一起工作。
YouTube上有很多教程视频，解释什么是系统测试，以及如何开始系统测试，无论你想手动还是使用自动化工具进行测试。 一些关于系统测试的最好的YouTube教程包括：
4.如何维护系统测试
测试维护是调整和维护系统测试和其他种类的软件测试的过程，以便在你对软件构建进行修改或改变代码时保持它们的更新。
例如，如果你进行了系统测试并发现了错误和缺陷，你会把软件构建送回给开发者进行调整。 然后，测试团队可能需要维护测试脚本，以确保在再次测试时充分测试新的软件构建。
测试维护是软件测试的一个重要方面，测试人员可以通过遵循维护的最佳实践来确保他们保持软件的维护。
这些措施包括。
1.协作：
开发人员和测试人员应该一起合作，以确保测试人员知道代码的哪些方面被改变了，以及这可能对测试脚本产生什么影响。
2.设计：
在开始自动化测试之前，设计测试脚本。 这可以确保你所做的自动化测试总是适合于目的。
3.过程：
在设计过程中要考虑到软件测试维护。 记住，你必须维护测试，并将其纳入日程安排、测试计划和测试设计。
4.4.便利性：
如果可能的话，从一个仪表盘上更新你的所有测试，包括系统测试和理智测试。
这意味着更新测试更快、更方便，而且当软件构建发生变化时，它可以最大限度地减少忘记更新某个特定测试的风险。
系统测试是白盒还是黑盒测试？
系统测试是黑盒测试的一种形式。
黑盒测试与白盒测试不同，它只考虑软件的外部功能和特性。 白盒测试测试软件的内部运行方式，例如代码的功能和工作方式。
黑盒测试不需要了解系统的内部工作原理或代码，而只是要求测试人员测试软件应用程序的输出和功能，并根据设定的标准评估这些。
系统测试确实涉及功能和非功能测试，但测试人员使用黑匣子技术，甚至对构建的非功能方面进行测试。
由于这个原因，系统测试通常被认为是一种黑盒测试。
