app专项测试工具，专项测试工具

前言

当你想到特殊测试时，你的第一反应可能是流量测试、功率测试、弱网测试等，以及它们相应的特殊测试工具。除了上述内容外，您还应该了解特殊测试。

1）什么阶段需要做特殊测试？

2）每个阶段做什么。

3）您需要达到什么粒度？

4）如何完成特殊测试。

接下来，我们将讨论项目不同阶段的特殊测试的不同策略和特殊基线和规范。

1、项目中的特殊实践过程

1.1 第一阶段：项目需求阶段

该阶段属于项目需求说明书、测试分析、系统分析三个文件的评审阶段。开发不写任何代码，测试不创建用例，只是确定项目的需求和研发架构。这里我们简要讨论三个不同的文档。

1.需求规格：PRD。这是一份描述一般要求的文件，对于任何公司都应该相似。

2、系统分析：一般分为APP系统分析和后台系统分析。它包括以下几点：

1）系统或模块架构。

2）系统或模块交互时序图。

3）各模块的详细业务描述。

4）这次会增加哪些新功能？

5）本次升级的模块和系统。

6）影响风险评估。

7) API说明及详细参数类型列表。

这些通常会被详细描述，后续的实现完全基于此文档。

3. 测试分析：测试分析通常紧随系统分析之后。测试分析类似于常规检查表，但它不仅仅是一个检查表。基本上包括以下几点：

1) 本次测试的功能点范围。

2）详细的业务描述以及支持该业务的前后端系统时序图。

3）测试点，例如与每个任务相对应的清单。

4）各模块的测试负责人等相关信息。

这三个文件都需要召开评审会议，产品、测试、开发都必须参加。我们提到的特殊测试流程和技术可以让业务组测试人员对特定模块进行详细的特殊测试，而不是像工具组那样使用集成的特殊测试并运行它。

从上面的描述中，你可能会认为这个过程不需要任何测试，但实际上，很多工作需要专业测试人员来完成，其中一些测试人员利用他们丰富的经验，一些测试人员做出他们需要的决定。

1）需要深入了解目标产品的研发体系，全面了解产品。

2) 必须制定详细的特殊测试计划。例如使用哪些型号进行测试、测试哪些版本号、测试哪些网络等。

3）需要深入了解被测产品需要特别关注的功能点。

4）您需要掌握开发人员每天签入的代码。这就是所谓的CR（code review），不需要专人来做，而是为了了解开发的细节，每天做比全部看代码要有效得多立刻。

5）需要评估哪些场景需要测试，哪些特殊项需要测试，哪些特殊项在技术上难以克服等等。接下来我们将在第一步的基础上给出一个实际的例子。

特别测试计划

（1）本专项覆盖的网络为脆弱网络、2G、3G、4G、WiFi（根据国际标准数据对各网络的上下行、时延、丢包等进行仿真），以及仿真工具分别是ATC、Charles、iOS开发者模式。

(2)特殊测试场景分为首次启动、非首次启动、静默状态三种。

(3) 比较的竞争产品为A、B、C。

（4）Android使用的机型有Nexus6（CM rom或原生rom）、小米9（开发者系统）、魅族16s（Android10）。使用的iOS型号是iPhone 8（12.4）和iPhone XR（12.0），但如果需要的话您可能还需要越狱的机器。

（5）与本次专项会议相关的功能场景包括a、b、c等（此处应详细列出场景并测试相应的特殊类型）。

（六）重大项目：定位服务、长链接机制、推送相关机制等。

（7）其他：目前Android和iOS对于特殊A技术获取的数据粒度比较粗，相关详细技术和测试工具有待进一步探索。

当然，详细的计划必须详细描述每个项目将使用哪些技术、获取的数据包括单元的粒度以及要实现的目标。有些是非技术相关的，比如业务分析、场景分析。

1.2 第二阶段：功能测试和错误修复

事实上，第一阶段和第二阶段之间还有一个过渡阶段——，即开发和编写代码以及编写测试和测试用例的阶段。 CR是这个阶段的一部分，前面已经提到过。但同样，专业人士在此过程中需要做三件事。

1）跟踪签到日志，及时了解产品编码。

2）提前扫码。 FindBugs、Lint 等

3) 准备本地编译和代码调试的环境。很多产品模块，比如Mvn、Gradle，都非常碎片化，甚至有自己的打包工具和流程，所以现阶段专家对它们进行清晰的分类非常重要。

现在我们来谈谈第二阶段。在这个阶段，工作组每周根据项目的实际情况以及本次项目迭代出现的新的、有影响的特征，制定相应的测试优先级。这包括但不限于：

1) 跟踪代码。

2）功耗测试。

3）风险评估。

四）……

第二阶段涉及每周报告，但错误修复过程会导致更大的代码更改和不太稳定的功能。另一方面，这也与公司的项目架构模式有关。所以，这里的流程和方法也是依赖于公司的项目，不应该一步步来的。

1.3 第三阶段：集成和灰度测试

现在我们处于最后阶段，功能基本稳定，应用程序的每个模块都经过最终的集成测试。一般大公司都会进行RC测试和灰度测试。这个时候，就必须按照原来的特别考试计划进行最后一轮的全面特别考试。不过由于上一期基本已经接近发布了，几天后报告就会完成，而且这个阶段特殊缺陷的优先级会高于相应的其他功能缺陷（当然，具体问题会详细分析））。最后，发布点后必须提交完整详细的报告。

2. 特殊基线和规范特殊基线和规范也是特殊测试中最重要的部分。然而，基线和规范数据是最敏感的并且不能重复使用。我将在这里简要讨论一些实用的想法。

首先，基线本身通常从以下三个来源获得，但重要的一点是使其尽可能细化。

1) 合并您自己产品的多次迭代生成的数据。

2）结合竞品特殊数据。

3）拍拍你的头。

很多人可能会说，大多数情况都是第三种情况。相对而言，前两者还需要大量的数据和技术积累。通常，这三部分数据结合起来，通过团队讨论和审查确定初步的临时基线。事实上，不要低估拍拍头的重要性。这通常会导致分歧，尤其是在设定基线时。现在你必须先拍拍自己的头并配置它。毕竟，底线就是目标。建立基线的目的是为了确保大家在做一个项目的时候，都在朝着这个目标前进，而不是假设不符合标准就不能发布。一份全面的专项测试报告可能会包含大量不合格的指标，但这会阻碍整个项目的发布，除非风险很大或者相对于之前的版本有改进，否则是没有的。

有许多基线指标。几乎每个项目背后都有一个基线，包括CPU、内存、图像大小、流量大小、网络响应弱等。每个项目都需要具体的数据作为基线标准，而数据获取的方法和详细程度对于专项项目的基线至关重要。例如：

1) 客户端内小缩略图流量控制在5KB以下。

2) 客户端内的缩略图流量控制在25KB左右。

3) 客户端内大缩略图流量控制在50KB左右。

类似上述的指标也应该这样细化。光有标准和基线是不够的，还需要代码编写规范、嵌入规范、优化产品架构。只有这些做得好，才能真正保证您的专项工程的质量。测试一般来说，你不能总是纠缠于问题，而是有更多的东西可以优化和改变这些问题的原因。

关于基线和标准，另一个需要注意的重要事项是，一些Android 和iOS 测试模型、系统版本和应用程序类型需要修改。做特殊项目时最忌讳的就是每次的测试环境、机器型号、应用都不一样，导致无法解释问题，混乱整个项目组的决策。

3、总结根据业务背景、产品技术实现、产品定位等多方面信息进行专项测试。否则，就会成为空中楼阁。重要的不是掌握如何使用工具，而是实施和发现问题。专业测试需要广度和深度。

注：参考书- 《大话APP测试2.0-移动互联网产品测试实录》