uTest遵循一种结构化的测试流程，通常包括项目入职、测试用例执行、缺陷报告和测试周期闭合。测试人员被分配特定的测试用例，并在指定的测试环境中执行。执行后，测试人员向平台提交详细的缺陷报告。

如果一个缺陷报告被拒绝，它会根据所收到的拒绝类型对测试人员的评分产生负面影响。

测试人员可以就被客户拒绝的缺陷报告提出异议。

占位符是禁止的。

测试人员可以在匹配测试周期要求的情况下使用任何已注册的设备。

测试工程师选择要参与测试的测试人员。

Test IO采用一种敏捷的测试流程，其中包括测试计划、执行和持续反馈。测试人员参与与其语言、设备和地点匹配的测试周期。我们强调实时和手动的探索性测试，使测试人员能够即时发现并报告缺陷。

要开始为一个测试周期做出贡献，测试人员需要提前开始测试会话，并确认已阅读和理解了范围内功能的说明。

为了识别重复的情况，在提交缺陷时，缺陷表格右侧的“相似的缺陷”列表将显示当前测试中已提交的缺陷列表，您还可以搜索和筛选缺陷以及已知缺陷列表来实现这一点。

如果一个缺陷报告被拒绝，根据所收到的拒绝类型，会对测试人员的评分产生负面影响。

测试人员可以与团队领导就被拒绝的缺陷提出争议。 一旦一份报告被提出争议，它会被锁定，由缺陷争议团队进行审查。

占位符报告是严格禁止的。

根据测试人员档案中注册的设备和其他信息，系统会选择其中一个设备，并邀请您参与测试。

根据每个测试周期剩余的名额，您可能无法选择与系统选择的设备不同的设备。一旦您已被邀请到一个设备上，您就无法切换到另一个设备。因此，您只能提交在这个设备上发现的缺陷。

uTest的缺陷表格结构如下：

而另一方面，Test IO的缺陷表格通过以下结构简化了测试人员的文档记录：

您不必遵循特定格式来构建一个标题。然而，您必须回答发生了什么、缺陷出现在哪里以及它是在何时触发的。

在我们的缺陷表格上，您无需添加步骤编号；我们的表格已经提供了它。您可以随意拖动它们并重新排列它们。

除了在测试网站时的浏览器外，设备的信息是从您接受参与测试周期时选择的设备中检索的，之后无法更改。

uTest分类缺陷如下：

测试人员需要准确识别和报告这些缺陷。
​

Test IO将缺陷分类为：

我们不执行安全性测试。

以下是更多的规格。内容缺陷涉及各种信息类型，不仅仅是文本（例如，翻译；错别字不需要报告），所以缺失的图像和按钮被视为内容缺陷而不是视觉缺陷。

功能性缺陷被视为性能问题，例如无限加载，如果它们直接影响最终用户，比如访问内容或任务进度。

另一方面，在性能测试周期期间，这些测试是根据需求运行的，无限加载被视为性能问题，并且会如此报告；因此，测量互联网速度和.har文件是附加到报告的必要部分之一。

uTest缺陷的严重程度包括：

您可以决定哪种严重程度更适用于该问题。

在Test IO，我们提供特定的场景来指导您正确选择严重程度；这些只有三种：

我们提供的场景将有助于以不同的方式分析问题，例如考虑功能受损和缺陷对最终用户的潜在影响。例如，致命性缺陷是关键的，而如果存在一种简单和直观的解决方法，比如重新加载页面，那么正确的严重程度将是低的。

uTest允许测试人员在其缺陷报告中附加相关文件，如屏幕截图、屏幕录制和日志文件。

屏幕截图：

屏幕录制：

Test IO的测试人员可以包括附件，如屏幕截图、屏幕录制和崩溃日志。

屏幕截图：

屏幕录制：

对于性能测试，需要.har文件。

uTest通过专用的消息系统促进测试人员、项目经理和开发人员之间的沟通。测试人员可以就需求寻求澄清，并在整个测试周期中与相关方互动。

​

Test IO强调实时沟通，使测试人员能够通过测试聊天、缺陷报告评论、Discord服务器和电子邮件平台，在测试人员、团队领导（TL）、客户成功经理（CSM）和客户之间协作和讨论问题。测试人员可以提出问题、寻求澄清，并从上述相关方获得即时反馈，因为它们可以要求测试人员的任务信息。

在uTest上，酬金取决于缺陷的价值：

Test IO的酬金取决于执行的任务类型。有些任务与测试周期直接相关。相比之下，其他任务，如复制、缺陷修复确认和缺陷报告确认，可以在不加入与报告相关的测试周期的情况下执行。

然而，在测试周期中，酬金取决于缺陷的类型和严重性，以及设备规格。

在uTest上，测试人员可以执行：

​

在Test IO，自由职业测试人员可以执行以下付费任务并获得以下奖金：

在Test IO，你不必等待客户接受或拒绝你的工作，只要团队领导接受了你的缺陷或执行，你就会得到报酬。