大家好！

我领导LANIT公司系统部门的系统分析和测试部门的测试部门。我进入该领域已有14年了。2009年，我第一次面对状态信息系统的测试。对于LANIT和客户而言，这是一个巨大而重大的项目。它已经投入商业运营超过九年。

资源

本文将向您介绍我们公司使用的GIS测试方法。特别是，您会发现（该链接将您带到特定段落中提到的文章片段）：

在加入LANIT之前，我曾在一个由五个人组成的测试小组中工作，在那里将任务分配给团队负责人。当我来到LANIT时，我被分配去管理一个由四个测试人员组成的地理分布测试团队，他们在项目开始时就参与了测试状态信息系统的工作。随着项目的发展，该组中测试人员的数量与功能的增加成比例地增加。

第1章第一个GIS测试项目的开始

当我们开始使用GIS时，首先，我们必须处理大量的功能（几十个子系统，每个子系统最多具有数百个功能），这些功能需要在短时间内进行测试。团队的任务是不要在功能范围上感到困惑，并最大程度地减少遗漏缺陷的风险。

在制定技术规范的基础上，规范性文档不断变化，整个团队不得不适应创新：我们针对开发和项目优先级修订了技术规范（因此，测试计划已更改）。

分析人员很难适应法规文档的频繁更改，这导致人们对如何保持技术规范保持最新状态，如何始终为每个版本的系统拥有一套相关规范，如何以及在何处显示一个规范更改对许多其他相关文档的影响程度缺乏了解。。

由于开发人员和测试人员使用了分析师的工作成果，因此对于项目团队中的所有参与者来说，对于技术规范的相关性，规范历史的可理解性，即将发布的版本的技术规范的一致性等问题都非常敏感。与文档混淆，技术规范版本化的后果影响了项目成本。

有时情况变成180度。同意，当火车高速驶过时，不可能迅速改变方向而不会造成后果。

我定期参加会议，了解项目变更的原因。最困难的部分是向远程测试人员解释为什么我们要测试一个月的新注册表，现在我们需要忘记所有内容，并准备测试该注册表的完全重新设计的功能。人们开始感觉自己像是一台巨型机器中的齿轮，他们的工作被认为完全没有用。

起初，这种变化使团队感到恼火，并极度消极。但是该团队接受了这样的事实，即不可能影响技术规范的更改，但是您可以学习如何使用它。在该项目的那个困难时期，测试团队有一项新任务，通常在较小的项目中是缺少的，即测试需求。

结果，变更需求的弊端以新的测试任务和影响项目最终结果的能力的形式，转变为测试人员的优势。

除了与分析师互动之外，测试团队还依赖与必须集成的外部系统的通信。并非所有人都准备好提供测试电路并通知第三方系统其发布日期并交换有关服务更改的信息。这种通信的不同步或对外部系统通知Web服务的更改构成的粗心态度导致产品错误和进行集成测试的困难。测试人员必须与外部系统建立通信，开发测试集成技能，并吸引开发人员实施存根。

参与项目的整个测试团队都面临着将开发团队融入生产过程的需求。在项目开始时，开发团队开始寻找新的工作组织方法，介绍了分支模型Feature Branch Workflow和Gitflow模型。以前小项目的开发没有一堆分支，每个人都很舒服。但是面对无法在几个月内将版本稳定下来以向客户进行下一个项目演示的问题，开发经理和架构师在分析了原因之后得出的结论是，需要更改软件的创建过程。然后，他们开始在项目上积极使用Feature Branch Workflow和Gitflow。出现了另一个新的测试任务-研究开发模型的工作原理，以适应创建软件的过程。

GIS涉及将项目划分为功能块，每个功能块均包含一组因业务和/或执行独立技术功能而彼此紧密相关的组件。如果在项目开始时所有测试人员都检查了新到达的功能模块，并且团队中的每个人都可以互换，并且对所有模块都具有同等的知识，那么随着项目的扩展，测试人员的数量也必须增加并分成几组。团队的成长导致了将测试过程分为测试组，在每个组中分配项目角色的过程。

随着项目的发展，状态信息系统的功能开始出现。

第2章GIS的功能。测试人员如何与他们一起生活和合作

首先，大型GIS对可靠性和负载的要求不断提高，系统处于24/7模式，系统故障不应导致数据丢失，系统恢复时间应不超过1小时，响应时间应不超过2秒，并且多得多。

由于它是一个Web门户，因此测试人员必须投入多用户Web门户的测试过程，并考虑Web界面的特殊性，构建一种测试设计和测试过程的方法。

一个Web应用程序可以同时被大量用户使用。需要对所有用户使用的GIS的开放部分进行负载测试，以预测负载模型并进行负载测试。

用户可以具有自己的访问级别。需要使用测试设计技术在应用程序管理子系统中测试用户角色矩阵。

用户可以访问一个实体，这导致竞争性访问。为了使一个用户的输入数据不会覆盖另一个用户的数据，我们必须对可能同时更改用户个人仪表盘中数据的情况进行测试分析，以在测试中包括对带有诊断消息的正确测试的检查。

该系统的功能之一是使用SphinxSearch搜索引擎。测试团队不知道该如何工作。为了了解测试的复杂性，Sphinx必须咨询开发人员并了解数据索引是如何发生的。

测试人员掌握了通过单词形式，单词片段，同义词进行搜索的功能，通过在随附的文档中进行搜索，他们开始理解了为什么新创建的搜索数据没有出现在搜索结果中以及这是否是错误。

该项目具有应用管理子系统，该子系统不仅包括用户注册，而且由于存在用户角色矩阵而变得复杂。它是在组织管理员的个人帐户中配置的。角色矩阵的检查组合数量众多，组织的类型数量也不少，也就是说，检查组合的数量呈指数增长。有必要改变熟悉的方法来设计早期用于小型项目的测试。

由于该系统采用了Web界面，因此有必要提供跨浏览器测试，这并不是最初计划的。当该项目刚刚开始时，Internet Explorer 7.0是唯一支持家用加密的浏览器，大多数用户都使用该浏览器。因此，在项目开始时，为了测试个人帐户工作的逻辑和功能，仅使用此版本的IE，但是对于门户的开放部分，当时所有现有浏览器都需要支持。但是，那时他们还没有考虑跨浏览器测试。

当他们问我：“系统在所有已知版本的浏览器中如何运行？” -坦率地说，由于测试模型的数量巨大（约4,000个测试用例），我感到非常恐慌，回归测试集约为1,500个测试用例，并且测试团队仅在默认选择的一个浏览器上检查了整个人群。这种情况必须很快解决，并且要巧妙使用，以便赶上第一版的截止日期，并通过测试涵盖主要的浏览器版本。

在Internet上，关于测试，测试模型开发的文章很少。在当时，对于我们的团队而言，一项不可理解的任务是如何创建，存储在何处以及如何使大型测试模型保持最新状态。目前尚不清楚如何摆脱可能无限的研究测试，也没有无休止的测试资源：既不是人类也不是暂时的。

在GIS投入试运行，然后进入工业生产后，出现了一项新任务-处理用户事件。

在创建功能完善的GIS用户支持服务之前，测试团队满足了用户请求的第一击，这是系统细节中最沉浸的团队，他们试图结合测试新改进的主要任务以及及时处理SLA叠加的传入事件。

测试团队之前从未遇到过这样的任务。需要对事件流进行处理，系统化，本地化，更正，验证并纳入新的发布周期。

随着系统本身的发展，对操作过程的了解和成熟程度也不断提高和提高。

我只列出了测试团队在使用GIS时遇到的部分功能。

第3章GIS测试问题及其解决方法。对团队经理的测试建议。

在测试团队处理多个大型GIS的过程中，我们提出了针对测试经理的建议。后来，它们被转换为我们部门中此类系统测试过程的方法，并在解决类似规模项目中的新问题时不断改进。

有很多功能时该怎么办？

不要惊慌并将功能分解为块/模块/功能，将分析人员与结果审计联系起来，确保功能块的愿景正确。

我们建议做：

.

, , , , production. , .
//.

, , — , ///. , , , - , , , / // , , « » , .

如何处理知识矩阵和功能需求的覆盖范围？

功能不会变小。现在仍然有很多，但是它以新的表示形式（以矩阵的形式）。有必要从业务角度确定哪些功能最重要，以及哪些功能不能以原始形式提供给用户。因此，开始对功能进行优先级排序。理想情况下，如果分析师在此方面帮助测试人员。至少，他将欣赏测试所确定的优先级的正确性。

对于最重要的功能/块/模块，将为测试分配较高的优先级，对于次要的功能/模块/模块将由第二优先级测试覆盖，其余的将为第三优先级，或者如果“最后期限已启用”，则可以将其测试延迟一段安静的时间。

因此，我们有机会测试对客户真正重要的功能。我们将各种功能按顺序排列在一起，我们了解测试所涵盖的内容以及尚待涵盖的内容，我们知道在内部有必要加强测试，以防万一，请负责测试人员生病/解雇，我们了解团队应将哪些改进意见传递给测试人员（在（与知识矩阵相对应），当他们厌倦了测试同一件事时，我可以为其提供哪些新的有趣功能/模块/子系统。就是说，我有一个可视化工具来激励想要学习项目新知识的测试人员。

当需求不支持历史性，混乱，重复时，该怎么办，测试人员如何处理呢？

我们建议在项目上实施需求测试过程。发现缺陷越早，其成本越低。

由知识矩阵分配的测试人员在准备好技术规范以进行开发后，便立即开始研究和验证它们。为了使所有人都清楚需求中有什么错误，针对分析人员制定了一套规则“质量要求食谱”，并据此尝试编写需求，并创建了技术规范模板以一种样式描述它们。已向测试人员发布了技术规范格式规则和关于需求描述的建议，以了解在需求中查找哪些错误。

当然，测试人员的主要任务是发现逻辑上的不一致或对分析人员可能会遗漏的相关功能/子系统/模块的影响的未知时刻。在检测到缺陷之后，将它们固定在bugtracker中，分配给需求的作者，分析师停止开发和/或与测试人员聊天，并且开发人员告知将根据缺陷对条件进行修改（以免减慢开发速度），进行更正并发布更正的版本要求。测试人员检查并结束了缺陷方面的工作，使其达到了要求。此过程使团队充满信心，在经过几周的开发之后，检测到的问题肯定不会出现在测试中。

除了及早发现缺陷，我们还获得了一个功能强大的工具，可用于收集有关分析师工作质量的指标。该项目的首席分析师拥有需求中错误数量的统计信息，可以采取措施来改善其团队中的工作质量。

有必要进行负载测试时该怎么办？

有必要研究负载的需求，提出其模型，开发测试用例，与分析师协调负载的测试模型，并在有能力的专家参与负载测试的情况下开发负载脚本。

当然，您无法猜测测试模型的负载，但是为了获得更准确的结果，除了分析师之外，您还可以吸引一名架构师或DevOps专家，他们在分析了信息，统计数据和指标之后，可以判断建议的负载模型中还需要哪些其他情况。

还值得实施运行负载测试，获取负载结果并将其传递给开发人员以消除瓶颈的过程。

加载过程应在每次发布之前定期进行，并定期更改负载模型以发现新的瓶颈。

在没有经验的情况下需要进行集成测试时该怎么办？

有一些基本方法：例如，您可以参加有关Rest API测试主题的高级培训课程，在Internet上阅读文章，通过Skype与同事进行经验交流，并演示该过程，并聘请精通Rest API测试的专家加入测试团队。

有很多方法可以让您沉浸在这种测试中。我的团队聘请了一位经验丰富的专家，他将来会培训我和整个测试团队，并编写手册：测试Rest API时要寻找什么，如何制定测试设计以验证集成，进行网络研讨会并演示整个团队的测试过程。

我们提出了测试任务，每个人都有机会练习并沉浸于此过程中。现在，多年来已开发的材料仅在改进，学习和深入研究Rest API测试的过程需要1-2周，而更早的时间则需要一个月或更长时间才能进行潜水，具体取决于项目的复杂性和测试模型的数量。

资源

如何不混淆代码分支，立场，部署和测试必要的代码？

尽管GIS处于开发的初始阶段，但是只有两个代码分支：主代码和发布代码。第二个在稳定阶段分离，以进行最终的回归测试和校正回归的点缺陷。

当发布分支发送到生产环境并且开发的下一个迭代版本开始时，我们决定在某个时候并行化新任务的开发，以便可以按时完成通过发布计划的较大任务。在某个时候，有3-4个或更多这样的分支。部署了三个以上的测试台，目标是尽快开始测试未来版本。

测试人员确保基础架构专家在其中一个测试台上安装了版本10001，例如修订版，并正确执行了所有操作，然后他们便可以开始测试。基础架构专家从代码分支执行了部署，报告说已经部署了展台，已经安装了代码，并且可以对其进行测试。

我们开始测试并了解：

有已经解决的错误；
现有块中的功能与另一个测试台上的，正在为下一个计划版本进行准备的相似功能有很大不同，而在已转移的代码分支中不应对其进行任何修改；
我们开始记录缺陷，开发人员将它们退回，然后开始在设计聊天中弄清楚我们实际安装了什么以及为什么不期望我们进行安装。

我们进行了分析，发现开发人员没有向基础架构专家提供有关从哪个分支进行部署，从开发分支收集员工的指示，并且开发人员仅设法将功能分支中的部分代码合并到了开发分支中。

测试人员根本不了解分支机构的管理，他得到了任务和到展位的链接，跑去测试，花费了时间，发现了很多缺陷，由于这些混乱，大多数缺陷都不重要。

为了避免将来发生类似情况，我们做了以下事情：

开发人员为基础架构专家准备说明，以指示从何处进行部署，该指令通过任务传递给jira；
基础架构专家不会感到困惑，并且会尽其所能；
GIT, , jira ;
jira :
Gitflow , , hotfixes develop, .

, , ?

我们建议您提前制定测试策略，但是由于您错过了这一点，因此我的经验可能会派上用场。

首先，您需要了解需求中指定了哪些浏览器。如果您已决定，但绝对没有时间，我们将在这里查看最常用浏览器的统计信息。然后，我们尝试访问三到五个最受欢迎的浏览器。

由于项目规模很大且测试团队很大，因此实际上可以根据统计数据为每个测试人员分配一个流行的浏览器。他在专用的浏览器版本上进行回归案例，必须特别注意布局，按钮和链接的可单击性。这个过程看起来像这样：例如，有100个脚本用于回归测试，团队有5个测试人员，每个可以使用20个脚本来工作，每个脚本都分配有一个浏览器。对于一次回归运行，每个测试人员都在一个浏览器中检查了他们的案例。最终的覆盖范围还不完整，但是由于许多场景仍在某种程度上重复出现，因此覆盖百分比的增加是由于不同浏览器传递了部分回归脚本所致。

当然，这并未给出所有功能的100％测试覆盖率，但是它可以根据系统中的主要业务场景显着降低跨浏览器缺陷进入生产的风险。

此外，我们不仅在回归上，而且在改进和验证缺陷的测试上，都在不同的浏览器上进行了检查，从而扩大了跨浏览器兼容性的覆盖范围。

将来，他们开始将这种方法应用于细化测试中的浏览器分发测试器，而无需等待回归测试阶段，从而进一步增加了涵盖不同版本浏览器的测试百分比。

我们得到了：

在一个时间间隔内，优化了财务和时间上的测试成本，我们同时检查了回归测试和跨浏览器；
, Severity;
, , .

?

我们很快就对在单个存储库中运行测试，使其保持最新状态以及在执行结果上带有标记的情况下运行测试运行提出了疑问。

该团队包括具有TestLink测试管理系统经验的员工。这是唯一的开源测试用例管理系统，因此被选择使用。在这个系统中，非常简单的图形界面和设计没有多余的装饰。我们很快用测试对程序进行了填充，出现了如何维护它的问题。刚开始，每次修订都花费了大量资源来更新案例；事实证明该选项无效。

在与分析人员和测试团队协商之后，我们决定由于支持成本高昂而不必始终保持如此庞大的测试模型为最新。

根据功能需求矩阵将所有案例划分为文件夹，每个功能模块/子系统将一组案例存储在单独的文件夹中。这使我们能够直观地构造测试用例。关键字是在TestLink中创建的，案例属于特定组，例如，关键字：

烟雾-用于烟雾测试中包含的测试用例（执行最少的一组测试以检测关键功能的明显缺陷）；
自动测试-用于开发自动测试的测试用例；
优先级1-用于与标记为优先级1的业务功能相关的测试用例。

因此，测试设计总是针对新的改进而设计的，因此会出现清单文件。其中，对检查进行了优先排序，并且只有部分检查属于“优先级1”，或者在TestLink系统中已经在其上创建了冒烟和回归测试用例。

如何始终为计划的发布和生产中突然的HotFix拥有实际的回归案例模型？

在回归测试开始之前，所有准备工作都已完成，包括对回归进行更新或添加新案例。这意味着，如果您运行与新版本相关的测试用例运行，则在检查此类测试用例上的HotFix时可能会导致缺陷。

HotFix在旧的代码分支（最新发行版）上进行了更正，并通过缺陷修复对代码进行了更改，而当前的测试用例可以从将来的发行版中进行修改。也就是说，运行与将来版本相关的测试用例可能会导致错误缺陷的注册并延迟HotFix的发布。

为避免错误缺陷的注册和HotFix测试期限的中断，我们决定使用某种类似于维护代码分支的机制。测试人员仅根据某种算法手动执行TestLink分支（读取的“文件夹”）之间的合并和更新案例，而在Gitflow模型中，此操作由Git自动完成。

这是TestLink中的一组测试用例：

发明了在TestLink中更新案例的过程

测试管理器复制带有案例“ Test Project 1.0.0”的文件夹，并创建一个新的测试套件，其名称为下一个计划发行版的编号。事实证明该文件夹带有“ Test project 2.0.0”案例。
在研究了将来版本的改进之后，将分析“ Test Project 2.0.0”文件夹中的测试用例，以了解是否需要更新它们以进行新的改进。

如有必要，请更新案例：

负责修订的测试人员对“测试项目2.0.0”集中的测试用例进行更改；
如果您需要删除一个测试用例，首先需要将其移动到“ Delete”文件夹中，这样做是为了能够恢复一些意外删除的测试用例，或者如果要求又返回了并且测试用例又有需求（测试仅来自与未来计划发行版的测试套件相对应的文件夹中的案例，其中该测试案例将不相关）；
如果我们添加一个测试用例，则仅需要在与将来计划发行版的测试套件相对应的文件夹中完成；
更改的测试用例用关键字“已修改”标记（需要评估改进对回归功能的影响程度的度量）；
添加的案例将用关键字“已添加”标记（通过改进对回归函数的影响来评估度量标准是必需的）。

因此，我们始终拥有与系统的先前发行版相对应的实际案例测试套件，并将其用于HotFix测试，以及更新新测试套件，为回归测试做准备以及稳定新计划版本的过程。有时，可以同时获得对应于系统不同版本的TestLink的3-4个测试分支（读取的“文件夹”），这在测试功能分支的改进时尤其重要。

每次发布后，我们都可以基于“添加” /“更改”标签来估计我们的回归模型已更改了多少。

如果回归模型增加很多，而与以前的版本相比，版本中的改进量没有显着变化，则这是考虑在修订检查清单中设置优先级的正确性的机会。也许测试人员错误地选择了要回归的案例，因此有必要采取措施：例如，向测试人员说明优先级排序的原则，让分析人员参与协调优先级，通过删除多余的测试案例来更改最终的回归模型。

如何优化回归测试模型？

我们开始使用回归测试模型，通过突出显示优先级并在回归中仅包括“优先级1”案例来优化开发回归测试用例的过程。面对测试模型在一段时间后变大的事实，运行其案例的成本增加了，我们不再陷入对项目进行回归测试可接受的时间间隔。

现在是实现测试自动化的时候了，其目的是：

减少完成回归测试用例的时间；
使用自动测试来创建执行后续检查的前提条件，从而优化创建测试数据的时间和人力成本；
通过消除人为因素对手动测试结果的影响来提高回归测试的质量；
, .

开发了一个框架来自动化Java中的GUI测试（GIT被用作源代码控制版本系统）。

一个独立的自动化测试团队参与了自动测试的开发，成功地完成了该任务。对于类似规模的未来项目，计划在将来应用现有开发并在项目开始时启动自动化测试，以便尽快从其使用中受益。您可以在直接参与组织和进行自动化测试的同事的文章中阅读有关大型GIS 自动化测试的更多信息。

在功能手动测试方面，还对回归模型进行了优化。

以两个大型GIS为例，我和团队提出并实施了测试会话或测试流程，其实质如下：有必要分析每个子系统中的业务流程，并考虑通过该业务流程的检查会话（流程），模拟最多在流程上经常执行的用户操作。

在一个GIS项目中，这被称为“测试会议”，在另一个项目中，这被称为“测试之旅”。但是本质保持不变-我们考虑了端到端（通过整个修订版）关键业务场景，该场景完全涵盖了已实施修订版的业务构想（可能有几种这样的场景）。

测试漫游的场景已与分析师达成一致，开发了详细的回归测试案例，并且在无法对整个测试模型进行回归测试的情况下，他们可以将自己限制为进行“回归会话”或“回归测试漫游”，通常，花费的时间更少，并且可以清楚地了解系统中的关键业务流程是否存在问题。

将来，测试之旅将由自动测试覆盖，使测试人员从例行检查中解放出来，转而测试下一个计划发行版的改进。
测试之旅的一个示例：“创建，编辑，发布和废除实体”。

测试之旅可能很复杂，例如：

授予创建，编辑和废止的权利，
在用户的“个人帐户”中创建一个具有“专家”角色的实体，
,
,
,
« » «»,
, .

SLA?

我建议不要将对用户的事件进行本地化的过程视为低级任务。您应该将此作为测试过程的一部分。另外，与例如检查测试用例相比，这是一个更具创造性的过程。必须运用逻辑，测试设计技术人员的经验来使错误根源，发现错误并将其传递给开发人员。

当然，最好在三个层次的支持下组织GIS操作流程（理想情况下），结果，通常只有测试人员才能定位的最明显的事件将在测试团队中失败，而这已经在前两行中被滤除了。

为了遵守SLA，我们建议将事件本地化过程作为具有最高优先级的测试团队的职责，并尝试引入优化方法，以使事件回放速度尽可能快。

要优化测试人员花费的时间，您可以：

通过典型或经常遇到的SQL查询维护项目知识库；
在Bugtracker中组织对传入任务进行排名的过程，以便测试人员在指示器面板上立即看到下降的事件，并将其作为第一要务；
在JIRA中为具有SLA的任务添加倒数计时器；
建立事件警报系统；
production ( — ), , , , , , production;
« » « ». .

关于“知识矩阵”的内容已在上面写过。关于“责任矩阵”，此表类似于“知识矩阵”，其中写出了功能块/模块/子系统，由哪个测试组负责测试功能，通常，这是团队负责人或高级/首席测试员在一组。

如果一个功能块/模块/子系统的测试人员不了解项目中业务流程的全部情况怎么办？

这是我们在几个大型GIS项目中遇到的一个棘手问题。团队制作了一个“知识矩阵”，测试人员对功能的沉浸程度进行了自我评估，并分配了自己的功能。但是到了某个时候，从项目开始就参加的经验丰富的测试人员退出了小组，新的专家还没有沉浸在所有业务流程中，也没有看到完整的画面。这导致以下事实：在一个模块中测试案例时，应在下一个模块中使用此案例的结果，因此，如果将错误结果提供给第二个模块的输入（前提条件不适合执行前一个模块中的案例），则有必要分析情况和记录错误。

但是测试人员没有考虑为什么要输入这样的数字而只是计算出他们的案子。正式地进行了测试，一切都很好，没有发现缺陷，并且当分析师接受功能或为接受测试做准备时，可以澄清测试中遗漏的业务逻辑工作中的重大问题。原因是缺乏对系统执行的端到端业务流程的了解。

在这种情况下，进行了以下操作：

在分析师的参与下沉浸在功能中；
在测试小组中进行了培训，经验交流，关于子系统的集会及其中发生的事情的故事，在下一个计划发行版中计划为子系统进行的新改进的讨论；
吸引分析人员，并在规范规范中引入有关改进对第三方模块/子系统的影响程度的通知模板；
测试过程（巡回测试）的测试过程的实施，这些测试过程是测试人员，并与分析师进行协调（有助于减少团队误解业务流程的风险以及系统中业务错误的数量）。

！我试图收集主要问题和消除这些问题的建议，但这与我想分享的所有有用信息相去甚远。

第4章。确定项目质量的度量标准和评估测试人工成本的方法

在介绍该项目的指标集合之前，我们问自己：“为什么要这样做？”主要目标是监视测试团队的质量，生产中生产的发布的质量，并监视测试小组参与者的绩效指标，以了解如何发展团队。

进行了分析哪些指标是实现目标所必需的。然后将他们分为几组。然后，他们考虑了在不进行其他更改的情况下可以衡量哪些内容，以及在何处需要其他项目团队成员的帮助。

当所有准备阶段都完成后，便开始定期进行度量标准的组装：每月一次/发布/冲刺/季度-取决于项目和生产过程的特征。

收集了第一个指标后，有必要确定在项目开发此阶段我们要争取的目标指标。然后，需要定期采取度量标准并分析其偏离目标指标的原因，采取旨在改进指标的措施，即不仅要优化测试过程，还要优化项目的整个生产过程。

当然，不仅测试人员参与了质量改进工作，分析人员以及开发和发布经理还参与了流程优化，DevOps工程师都是该过程的关键参与者，因为每个人都希望提高发布质量并改善他们的工作。

一个关于完成的项目之一的指标和目标的收集的示例如下所示：

评估测试人工成本的方法

为了通知项目经理完成测试的更准确的截止日期，基于类似项目的指标收集，开发了一种方法来评估测试工作，该方法可以最准确地报告测试的完成日期并通知测试风险。

这项技术在所有GIS实施项目中都使用，差异只能在某些度量值上，但是计算原理是相同的。

用于对测试成本进行详细评估的指标

通过重复测量不同项目中不同能力水平的测试人员的实际成本来获得时间度量，并采用算术平均值。

注册错误的时间为10分钟（在错误跟踪器中注册1个错误的时间）。
验证错误/优化的时间为15分钟（验证1个错误/优化的正确性的时间）。
编写1 TC（测试用例）的 时间-20分钟（在TestLink系统中开发测试用例的时间）。
完成1 TC的时间-15分钟（完成对TestLink系统中的测试用例的检查的时间）。
测试时间。通过在“清单中的最小时间”的清单中添加成本获得的总时间。
测试报告时间 -20分钟（根据模板编写报告的时间）。
犯错的时间。计划所有错误/说明的注册时间，（注册1个错误/说明的时间*可能的错误/说明的数量（10个错误进行修订-每次修订的估计错误数））。
DV上的总时间（缺陷验证）。验证所有找到的和已纠正的错误/改进的计划时间（1个错误/改进的验证时间*错误/改进的估计数量）。
测试数据准备。准备测试数据的时间是根据不同参数对当前项目中的相似任务进行测试的经验来主观计算的（从测试分析师的角度来看，任务的范围，代码开发团队的能力（新的未知团队或经过验证的团队都有其工作质量的统计数据），不同模块之间的集成等）。

通过测量其中一个项目的实际成本，计算出以下内容：

每个任务最多不超过60个小时的开发时间，
每个任务最多不超过3个小时，最多不超过150个小时的开发时间，
每个任务最多不超过4个小时，最多不超过300个小时的开发时间。

在特殊情况下，准备测试数据的计划成本可能会与测试经理达成协议而发生变化。

是时候写TC了。编写TC的时间，该时间是在检查表准备好检查和确定测试优先级之后估算的。对于回归测试，TC被标记为“优先级0”（优先级检查的次数为0 * 20分钟（1个TC的写入时间））。
根据TC退缩的时间。根据TestLink系统中的TC完成一次回归测试迭代的时间（TC数量* 1 TC的平均执行时间（15分钟））。
风险性 15％的时间用于测试（风险表示所有人工操作，跌落，阻塞问题等）。
测试总时间。一个HL的测试总成本（测试数据准备+测试执行+错误/澄清的注册时间+错误/澄清的验证时间+根据TC优先级0 +风险的回归时间），以h / h为单位。
任务的总时间。整个测试任务的总成本，以小时/小时为单位（总测试时间+报告时间+编写TC时间）。

所有这些度量标准都用于项目上，以解决与计划，工作评估（临时和财务）相关的各种任务。如实践所示，这样的估计给出了最小误差（不超过10％），这是估计可靠性的相当高的指标。

当然，您可能不会使用任何度量标准，或者根据统计信息所得出的度量标准可能会有很大差异，但是估算测试工作成本的原理可以应用于任何项目，并为您的项目和团队选择最佳的计算公式。

第5章成功进行GIS测试的方法

向测试经理和测试人员表明，当遇到困难和新任务时，您可以找到解决方案，优化测试过程，并尝试将积累的经验应用于将来的项目，这一点很重要。

我为所有读者带来了惊喜-一个成功的GIS测试过程和文档模板的秘诀，您可以在项目中下载和使用这些模板。
因此，关于如何使大型信息系统的测试过程成功的秘诀以及我们建议在该过程中包括的内容，我将尝试简明扼要地陈述一下。

通过分析过程：

实施技术要求模板
在一组分析师中执行制定技术要求的规则；
制定有关项目团队技术要求准备就绪通知的法规。

- ;
;
;
:

○ - ;
○ -;
○ ;
, , , , , ;
, , , , ;
;
;
;
;
(, , ..);
, , ;
使用更有经验的同事的建议，其他项目的进展，现成的备忘单，与团队进行头脑风暴会议，并寻找优化和改进流程的新方法。

现在，我准备测试新的GIS。这是我的工作Wiki的外观，它已经考虑了我们建议做的许多事情：

给耐心的读者带来惊喜。

如果您读完这篇文章，应该得到一份礼物。我想与您分享可以在工作中使用的有用模板：

清单模板包括用于测试屏幕表格界面元素的最少建议集（当然，检查的选择范围更广，这只是一个示例），其中包括用于计算测试成本的公式，并附有计算方法的说明；
测试报告模板 ;
矩阵模板：知识/通过浏览器分发/平台/项目团队的假期时间表；
该项目的关键指标列表及其说明。

我希望我们的建议，示例，想法，链接和我的模板将帮助许多团队胜任地建立测试流程，优化成本并成功完成负责任且复杂的项目中的任务。

如果您想加入LANIT测试团队并参与GIS测试，建议您查看我们公司的职位空缺。

来到我们的测试学校！

, , .

祝大家有有趣的项目，并祝你好运！

PS真的很希望进行一次小型调查。

我们从测试状态信息系统中学到了什么