手机APP测试之专项测试

手机APP测试之专项测试

　　会员软件下载,视频会员共享软件,餐饮会员软件说到专项测试，大家的第一反应可能是流量测试、电量测试、弱网络测试等及其对应的专项测试工具。除了以上，关于专项测试我们还要知道：

　　该阶段属于项目需求说明书、测试分析、系统分析三个文档的评审阶段。开发并没有编写代码，测试也没有编写用例，仅仅都在做项目需求和研发架构的确定。这里简单说明下三个不同的文档。

　　3.测试分析：测试分析往往都在系统分析之后，测试分析和往常的checklist有点类似，但又不仅仅只是checklist，它基本包括了以下几点：

　　这三个文档都要有评审会议，产品、测试和开发都需要参加。我们这提到的专项测试的流程和技术则是让业务组中的测试人员去实践的，针对某个模块做深入的专项测试，而不是用工具组那类集成的专项测试。

　　从上面描述上看可能觉得测试好像在这个过程中也不用做什么，实际上专项测试人员要做的事情很多，而且其中还有一部分需要凭借自己丰富的经验来做判断。

　　2) 需要去制订详细的专项测试计划。比如测试会选用哪些机型，哪些版本号，会测试哪些网络等。

　　4) 需要去紧跟开发人员每天check in的代码。这并不是需要专项人员去做所谓的CR(Code Review)，更多的是去了解开发的一些细节，每天跟着会比最终一股脑地去看代码有效得多。

　　5) 需要去评估哪些场景要测试哪些专项，哪些专项可能在技术上攻克有困难等。

　　(一) 本次专项要覆盖的网络有：弱网、2G、3G、4G、WiFi(各个网络的上下行、延迟、丢包等数据全部根据国际标准数据来进行模拟)，模拟的工具为ATC和Charles以及iOS开发者模式。

　　(二) 专项测试的场景都会包括以下三种：首次启动、非首次启动、静默状态。

　　(五)本次专项会涉及的功能场景有a、b、c等(这里需要详细列出场景以及对应要测试的专项类型)。

　　(七)其他：目前Android和iOS针对A专项的技术所获取的数据颗粒度比较粗，需要进一步探索相关深入的技术和测试工具。

　　当然在详细的计划书中，我们需要详细的描述每项专项到底使用什么技术，获取数据的颗粒度，包括单位以及达到什么样的目的等。其中也有与技术不相关的东西，包括业务分析、场景分析等。

　　其实在第一阶段和第二阶段我们还有个过渡的阶段——开发编写代码和测试编写测试用例的阶段。该阶段之前已经提到过一部分，也就是CR。但同样的，专项人员在这个过程中要做三件事：

　　3) 准备好本地编译调试代码的环境。Mvn、Gradle等，很多产品模块分的很细，而且也有自己的打包工具和流程，所以在这个阶段专项人员整理清楚这些很重要。

　　接下来说第二阶段。在该阶段，专项团队会根据项目在每一周的实际情况以及本次项目迭代功能的新功能和影响功能制定对应的测试重点。包括但不仅限于以下几点：

　　在第二阶段以周为单位来做汇报，一方面在修复bug的过程中代码变更更大，同时功能也没稳定下来。另一方面也和公司项目架构模型有关系。所以这里的流程和方法也要视公司项目而定，不要按部就班。

　　终于到了最后一个阶段了，在该阶段功能基本上也稳定了，应用的各个模块都会进入最后的集成测试。一般稍大规模的公司就会进行RC测试以及灰度测试。在这个时间点，我们就需要进行最后一轮完整的专项测试了，根据我们最初定的专项测试计划即可。不过由于最后的这段时间基本上临近发布了，所以以天为单位来做汇报，而且在这个阶段内专项的缺陷优先级会比其他相对应的功能缺陷更高(当然，具体问题具体分析)。那么最终需要在发布时间点之后给出一个完整的详细报告。

　　专项基线和规范也是专项测试中最为关键的一块。但是基线和规范这个数据是最为机密和不可复用的。这里只简单说下实践的思路。

　　可能很多人说大部分情况都是第三种，因为前两种相对来讲还是要有很多数据和技术积累才能够获取的。一般结合这三者的数据，然后通过团队的讨论评审最终可以定出初步的专项基线。其实大家不要小看拍脑袋，尤其是定基线这种工作往往会是产生分歧的，这个时候就需要拍脑袋先定下来，毕竟基线是一个目标，不是一个死线，制定基线也是为了让大家在做项目的时候奔着这个目标前进，而不是说不达标就不能release。在很全的专项测试报告中可能会有许多不达标的指标存在，但是只要是风险不高的，或者说与之前的版本相比是进步的，那么不会block整个项目的发布。

　　基线的指标很多。几乎可以说每个专项背后都是有基线的，比如CPU、内存、图片大小、流量大小、弱网响应等。每一项都是需要有具体的数据来作为基线标准，数据的获取方法和详细程度在专项的基线中有着决定性的意义。比如：

　　类似上面的这些指标等都是需要这样去细化的。仅仅有标准和基线还是不够的，更多地需要有代码编写规范、埋点规范、优化我们自己产品的架构等，只有这些做好了，才能够真正地去保证我们的专项质量，所以作为测试来讲不能老是兜着问题，更多地需要去优化、改变导致这些问题的源头。

　　关于基线和标准还有一个重要的注意点就是需要去固定一些Android和iOS的测试机型、系统版本以及应用的类型。做专项最忌讳的就是每次测试环境、机型、应用都不同，说明不了问题也就罢了，更会扰乱整个项目组的判断。

　　专项测试一定要结合业务背景、产品技术实现、产品定位等各个方面的信息来做，否则就是空中楼阁。掌握了工具的使用并不是关键，落地和找到问题才是主要的。专项测试既需要面的广度也需要深度。