Testlio遵循与工作区相关的结构化测试流程。测试人员被分配到特定的工作区，进行各种测试，包括探索性测试、支付测试、功能回归测试、本地化测试、可访问性测试、可用性测试、直播测试和SDK测试。在这些测试中，他们从头到尾执行测试用例。

如果测试用例的步骤失败，测试人员必须提交bug或问题；如果bug已经提交，他们应该执行重现

在提交问题时，测试人员可以通过查看其他测试人员的报告或在“问题浏览器”内搜索来查找重复的bug。如果标题包含至少30个字符，测试人员将自动获得相似问题的建议，这些问题已经被报告。

测试团队会根据测试人员的个人资料和设备信息来选择测试人员，以满足工作区的要求，并通过电子邮件在两个阶段邀请他们。首先，邀请是到工作区；第二阶段是到一个测试的运行，其中给出了测试的时间、设备和日程安排

根据工作区的不同，测试人员可能会或可能不会收到参加测试运行的邀请；一切都取决于工作区的需求。

测试人员必须回复测试运行的邀请才能被邀请参加测试运行。让邀请过期被认为是一个严重的问题。

在完成了分配的测试时间后，测试人员需要回答一个反馈调查。

在提出问题后，团队负责人（TL）可以批准问题，请求额外的信息，或者关闭它。关闭问题是一种拒绝，会损害测试人员的评分。

因此，测试人员会等待其他人提出问题，然后进行复制，因为提交问题可能会恶化测试人员的评分/得分，如果问题被关闭（拒绝）；相反，如果问题被接受，它不会带来任何好处。

Rege
​

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

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

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

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

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

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

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

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

如有需要，Testlio的漏洞表单或问题表单呈现以下结构：

严重程度、功能和标签都是下拉列表，可以从中选择选项；除了附件以外的其他部分都是测试人员必须手动填写的模板。这适用于每个失败的步骤、提交的 bug 或执行的复制。

每个问题在标题之前必须有一个前缀，表示问题发生的部分，除非另有规定。

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

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

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

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

Testlio通常将问题分类为：

功能性问题需要两个附件进行文档记录。

本地化测试需要验证 UI 问题和内容本身。

​

Test IO将缺陷分类为：

我们不执行安全性测试。

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

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

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

Testlio功能性问题的漏洞严重程度如下：

测试人员根据每种严重程度的简要说明来决定哪种更适用于问题。

​

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

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

Testlio允许测试人员附加相关文件到他们的漏洞报告，如截图，屏幕录制和日志文件（崩溃，控制台，有时是查尔斯日志文件）。

日志文件是强制性的，功能性问题必须提供两个不同的附件。

这些附件必须有有意义的名称，以帮助下载它的开发人员诊断问题。

虽然截图或屏幕录制可以轻松记录视觉缺陷，但每个提交的问题需要两个附件来记录功能性问题。

屏幕录制：

所有问题都必须附带页面的屏幕截图（即使测试员已经添加了屏幕录制），并且必须添加一个包含问题的HTML代码片段的文本文件。有时，“故障报告中的附件”部分的信息已经足够了。

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

屏幕截图：

屏幕录制：

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

Testlio通过平台的聊天或特定工作区的RocketChat频道促进测试员和测试主管之间的沟通。不过，只有在测试员通过了认证测试或工作区要求时，他们才会被添加到此聊天中。

电子邮件用于向测试员发送改进请求。
​

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

Testlio按小时支付测试员，而不是按照bug来支付。

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

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

​在Testlio，自由职业测试员根据分配给他们在特定项目的运行中执行特定任务的小时数来获得报酬。

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

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