前言
说到专项测试，大家的第一反应可能是流量测试、电量测试、弱网络测试等及其对应的专项测试工具。除了以上，关于专项测试我们还要知道：文章源自玩技e族-https://www.playezu.com/194315.html
1) 我应该在什么阶段去做专项测试。文章源自玩技e族-https://www.playezu.com/194315.html
2) 每个阶段做什么。文章源自玩技e族-https://www.playezu.com/194315.html
3) 应该做到什么颗粒度。文章源自玩技e族-https://www.playezu.com/194315.html
4) 怎么样才算完成了专项测试。文章源自玩技e族-https://www.playezu.com/194315.html
下面我们就来聊聊专项测试在项目不同阶段的不同策略及专项基线、规范。文章源自玩技e族-https://www.playezu.com/194315.html
一、项目中的专项实践流程文章源自玩技e族-https://www.playezu.com/194315.html
1.1 第一阶段：项目需求阶段文章源自玩技e族-https://www.playezu.com/194315.html
该阶段属于项目需求说明书、测试分析、系统分析三个文档的评审阶段。开发并没有编写代码，测试也没有编写用例，仅仅都在做项目需求和研发架构的确定。这里简单说明下三个不同的文档。文章源自玩技e族-https://www.playezu.com/194315.html
1.需求说明书：PRD。就是一般的需求说明文档，各企业应该都类似。文章源自玩技e族-https://www.playezu.com/194315.html
2.系统分析：一般分成APP的系统分析及后台的系统分析。包括以下几点：
1) 系统或者模块架构。
2) 系统或者模块的交互时序图。
3) 每个模块的详细的业务描述。
4) 本次新增哪些功能。
5) 本次哪些模块、系统会有升级。
6) 影响的风险评估。
7) API的描述以及详细的参数类型列表。
往往这些都会有很详细的说明，之后的实施则完全根据这份文档来做。
3.测试分析：测试分析往往都在系统分析之后，测试分析和往常的checklist有点类似，但又不仅仅只是checklist，它基本包括了以下几点：
1) 本次测试的功能点范围。
2) 详细的业务描述以及业务对应的前后端的系统时序图。
3) 每个业务对应的测试点，类似于checklist。
4) 每个模块的测试负责人等相关信息。
这三个文档都要有评审会议，产品、测试和开发都需要参加。我们这提到的专项测试的流程和技术则是让业务组中的测试人员去实践的，针对某个模块做深入的专项测试，而不是用工具组那类集成的专项测试。
从上面描述上看可能觉得测试好像在这个过程中也不用做什么，实际上专项测试人员要做的事情很多，而且其中还有一部分需要凭借自己丰富的经验来做判断。
1) 需要深入去了解被测产品的研发架构，对产品有一个全面的理解。
2) 需要去制订详细的专项测试计划。比如测试会选用哪些机型，哪些版本号，会测试哪些网络等。
3) 需要去深入了解被测产品到底有哪些需要专项特别注意的功能点。
4) 需要去紧跟开发人员每天check in的代码。这并不是需要专项人员去做所谓的CR(Code Review)，更多的是去了解开发的一些细节，每天跟着会比最终一股脑地去看代码有效得多。
5) 需要去评估哪些场景要测试哪些专项，哪些专项可能在技术上攻克有困难等。
接下来根据第一个阶段，举个实际的案例。
专项测试计划书
(一) 本次专项要覆盖的网络有：弱网、2G、3G、4G、WiFi(各个网络的上下行、延迟、丢包等数据全部根据国际标准数据来进行模拟)，模拟的工具为ATC和Charles以及iOS开发者模式。
(二) 专项测试的场景都会包括以下三种：首次启动、非首次启动、静默状态。
(三) 要对比的竞品有：A、B、C。
(四) Android使用的机型分别是Nexus6(CM rom或者原生rom)、小米9(开发者系统)以及魅族16s(Android10)。iOS使用机型分别是iPhone8(12.4)、iPhone XR(12.0)，有必要的话可能还需要一个越狱的机器。
(五)本次专项会涉及的功能场景有a、b、c等(这里需要详细列出场景以及对应要测试的专项类型)。
(六)重点专项：定位服务、长链接机制、Push相关机制等。
(七)其他：目前Android和iOS针对A专项的技术所获取的数据颗粒度比较粗，需要进一步探索相关深入的技术和测试工具。
当然在详细的计划书中，我们需要详细的描述每项专项到底使用什么技术，获取数据的颗粒度，包括单位以及达到什么样的目的等。其中也有与技术不相关的东西，包括业务分析、场景分析等。
1.2 第二阶段：功能测试与修复bug
其实在第一阶段和第二阶段我们还有个过渡的阶段——开发编写代码和测试编写测试用例的阶段。该阶段之前已经提到过一部分，也就是CR。但同样的，专项人员在这个过程中要做三件事：
1) 跟着check in的日志对产品代码有一个及时的了解。
2) 初步对代码进行扫描。比如FindBugs、Lint等。
3) 准备好本地编译调试代码的环境。Mvn、Gradle等，很多产品模块分的很细，而且也有自己的打包工具和流程，所以在这个阶段专项人员整理清楚这些很重要。
接下来说第二阶段。在该阶段，专项团队会根据项目在每一周的实际情况以及本次项目迭代功能的新功能和影响功能制定对应的测试重点。包括但不仅限于以下几点：
1) 跟踪代码。
2) 耗电量测试。
3) 风险评估。
4) ......
在第二阶段以周为单位来做汇报，一方面在修复bug的过程中代码变更更大，同时功能也没稳定下来。另一方面也和公司项目架构模型有关系。所以这里的流程和方法也要视公司项目而定，不要按部就班。
1.3 第三阶段：集成测试与灰度测试
终于到了最后一个阶段了，在该阶段功能基本上也稳定了，应用的各个模块都会进入最后的集成测试。一般稍大规模的公司就会进行RC测试以及灰度测试。在这个时间点，我们就需要进行最后一轮完整的专项测试了，根据我们最初定的专项测试计划即可。不过由于最后的这段时间基本上临近发布了，所以以天为单位来做汇报，而且在这个阶段内专项的缺陷优先级会比其他相对应的功能缺陷更高(当然，具体问题具体分析)。那么最终需要在发布时间点之后给出一个完整的详细报告。
二、专项基线和规范
专项基线和规范也是专项测试中最为关键的一块。但是基线和规范这个数据是最为机密和不可复用的。这里只简单说下实践的思路。
首先，基线本身的来源一般有以下三种，重点是颗粒度要尽可能的细。
1) 结合自己产品的几次迭代所产生的数据。
2) 结合竞品的专项数据。
3) 拍脑袋。
可能很多人说大部分情况都是第三种，因为前两种相对来讲还是要有很多数据和技术积累才能够获取的。一般结合这三者的数据，然后通过团队的讨论评审最终可以定出初步的专项基线。其实大家不要小看拍脑袋，尤其是定基线这种工作往往会是产生分歧的，这个时候就需要拍脑袋先定下来，毕竟基线是一个目标，不是一个死线，制定基线也是为了让大家在做项目的时候奔着这个目标前进，而不是说不达标就不能release。在很全的专项测试报告中可能会有许多不达标的指标存在，但是只要是风险不高的，或者说与之前的版本相比是进步的，那么不会block整个项目的发布。
基线的指标很多。几乎可以说每个专项背后都是有基线的，比如CPU、内存、图片大小、流量大小、弱网响应等。每一项都是需要有具体的数据来作为基线标准，数据的获取方法和详细程度在专项的基线中有着决定性的意义。比如：
1) 客户端中的小缩略图流量控制在小于5KB。
2) 客户端中的中缩略图流量控制在25KB左右。
3) 客户端中的大缩略图流量控制在50KB左右。
类似上面的这些指标等都是需要这样去细化的。仅仅有标准和基线还是不够的，更多地需要有代码编写规范、埋点规范、优化我们自己产品的架构等，只有这些做好了，才能够真正地去保证我们的专项质量，所以作为测试来讲不能老是兜着问题，更多地需要去优化、改变导致这些问题的源头。
关于基线和标准还有一个重要的注意点就是需要去固定一些Android和iOS的测试机型、系统版本以及应用的类型。做专项最忌讳的就是每次测试环境、机型、应用都不同，说明不了问题也就罢了，更会扰乱整个项目组的判断。
三、总结
专项测试一定要结合业务背景、产品技术实现、产品定位等各个方面的信息来做，否则就是空中楼阁。掌握了工具的使用并不是关键，落地和找到问题才是主要的。专项测试既需要面的广度也需要深度。
评论