欢迎大家前往腾讯云社区，获取更多腾讯海量技术实践干货哦~
作者：高苡新
团队：腾讯移动品质中心TMQ
一、概述
本文以写实风格记录TBS Studio开发调试工具测试全过程。包括测试人力申请、测试策略制定、系统测试以及众测体验。对于测试初学者可以了解到整个流程是如何一步一步走下来的。对于有一定经验的同学可以领略到测试策略制定过程中基于风险和成本的测试理念。
二、提测项目介绍
TBS Studio是面向基于TBS的Web开发者和移动应用开发商（包括微信、手Q，三方App等）打造的开发服务整体解决方案，以提升广大开发者在真机环境下的开发效率，并帮助开发者分析和优化网页的设计，主要功能有网页Inspector调试，网页性能分析等。
详情：https://x5.tencent.com/tbs/guide/debug/season1.html。
三、测试人力申请
5月23日，开发同学Brian找到我，说有一个tbs studio的产品要申请测试资源。经过电话沟通，我了解到这个属于腾讯浏览服务（TBS）的附属产品，提供给开发做网页调试用的。于是我去找我们测试组leader说明了情况。Leader说Bonnie和mekhi对网页调试比较熟悉，建议我拉上他们一起去沟通测试需求 ——实践证明，对于一个陌生的测试需求，多拉几个相关的同事一起去沟通准没错！
第二天，我和Bonnie、mekhi一起去找到开发Brian沟通需求。经过半小时的讲解，我们对测试需求有了比较清晰的了解。也明确了主要工作是项目跟进（我比较擅长），而不是通过技术手段实现测试（Bonnie和mekhi比较擅长）。下面是沟通结果记录：（从中你可以知道测试需求沟通一般需要了解哪些东西）。
背景：
开发调试工具。主要用于提升TBS的影响力。之前都是小规模发布，现在想通过完整测试保证质量加大推广。目前日活xx（具体数据不方便公开，下同），上半年目标是日活xxx。
TBS Studio功能简介及测试重点：
主要分2部分：adb检测和inspector模块。inspector模块主要由开发自测保证。测试负责保证adb检测 模块。adb检测 模块有4步操作。分别是：
Step1：请连接手机，允许USB调试；
Step2：确认需要调试的App，检测当前app是否接入X5内核；
Step3：检测是否支持TBS调试；
Step4：设定TBS调试状态。
Inspector模块本次只需要测试元素更改功能。
TBS Studio发布节奏：
每3周一个小版本，每6周一个大版本（跟随TBS内核版本更新节奏）。
小版本发布遵循如下流程：
（1）开发使用mochr方法自测；
（2）测试验证修改点；
（3）开发内测；
（4）上线前测试。
大版本发布遵循如下流程：
（1）开发自测（主要保证inspector模块 与 新版本TBS内核兼容）；
（2）核心流程用例（比上线前用例更小。主要保证adb检测 正常）。
本次集成预计下周提测，发布计划尚未明确。
TBS Studio参与角色：
产品：Brian
前端开发：April
终端开发：josh
测试：eason
测试点：
（1）功能点：覆盖adb检测 模块 step1-step4操作的不同分支；
（2）平台适配：windows/mac(主要适配adb检测 第1步)；
（3）宿主适配：自有内核/共享内核/QB （主要适配adb检测第3步）；
（4）机型适配：所有安卓手机（主要适配adb检测第1步，第3步）
（5）tbs版本适配：所有线上版本（主要适配inspector模块）；
（6）inspector模块：本次只需要测试元素更改功能（https://x5.tencent.com/tbs/guide/debug/season2.html）。
测试方法考虑：
（1）主要是手工测试；
（2）初步分析不适合使用自动化，具体需要请教下应用宝；
（3）可以考虑众测来发现一些我们考虑不到的问题；
（4）因为当前用户量不大，所以考虑用最小的投入评估产品质量。
跟进计划：
（1）eason先评估工作量和是否采用自动化测试；
（2）eason确认外包人力；
（3）eason编写测试用例；
（4）外包执行测试。
四、测试策略制定
和开发沟通完需求之后，对该项目的情况有了基本的了解。接下来需要评估工作量和制定测试策略。
工时预估：
（1）测试策略制定（选择测试方法、测试机型、覆盖范围等）正职2h；
（2）测试用例编写（集成用例-目前有16个测试点、上线前用例、核心流程用例）正职6h；
（3）测试环境准备（win8、win10、mac电脑，手机协调）正职4h；
（4）集成用例执行（单机全用例16条+平台适配用例6条+宿主适配用例4条+机型适配用例60条+其他6条=92条）外包2-3天；
（5）上线前用例（10条）外包2小时；
（6）核心用例（3条）外包1小时。
本次集成测试总共需要12h的正职人力以及3-4天的外包人力。
测试策略制定：
测试策略制定主要是解答“担心什么”、“测多少”、“怎么测”这3个问题，其中会结合风险及成本的考虑。
担心什么（风险）：
本次提测是为了了解和提高版本质量，为产品加大推广做好准备。所以目前担心的问题是版本发到用户那里会出现各种各样的问题，影响到产品的口碑。那要解除这个担心，就需要了解用户使用场景，我们测试覆盖到这些场景就没问题。用户场景可以有2种方式获取。一是看统计数据，二是找用户（众测和体验）。
总体来说，本项目的风险较小。因为tbs studio目前只有89个日活用户。倘若经过系统测试和众测，依然有个别问题泄漏到真实用户也问题不大。通过用户反馈渠道把问题收集起来就行。
测多少（成本）：
上面提到tbs studio风险较小。同时，tbs studio尚未制定明确的发布计划，所以紧急性也不高。所以系统测试只需要使用初级外包覆盖到最主要的场景，保证80%以上的用户能顺利使用就行。没有覆盖到的场景可以交给众测和体验这两种成本更低的方式去发现。有这两道关，质量基本有保证。
怎么测：
这里主要是自动化测试、人工系统测试、众测这集中方式的选择。跟PC应用宝沟通后得知他们对adb连接这类功能也没有使用自动化测试。所以我们就放弃自动化测试了。系统测试肯定不能少。众测和公司内体验可以补充系统测试覆盖不到的点，所以可以用起来。
测试策略详情：
平台适配：
通过网上资料，我们可以看到win7、win10、mac10 这3个系统的市场份额之和达到78%。所以选择这3个系统为平台适配系统。
https://www.idcps.com/news/20170420/94526.html。
因为window系统分为32位和64位，所以通过查阅资料。我们发现64位系统已经是主流。所以我们在测试中主要使用64位系统来测试。
http://digi.163.com/16/1103/08/C4UDM2QS001687H3.html
屏幕分辨率适配（所有交互界面）：
因为TBS studio是一个桌面应用，所以要考虑显示器的分辨率问题。保证在不同的屏幕上界面显示正常。通过网上数据，我们可以看到1366768（笔记本屏幕主流分辨率）和19201080（台式机屏幕主流分辨率）占了50%以上的比例，其他分辨率的屏幕占比都较低。所以屏幕适配选择了1366768和19201080两种屏幕。
宿主适配
通过tbs（腾讯浏览服务）的后台统计数据，我们可以得知不同宿主（使用腾讯浏览服务的app）的用户数。通过选择每种类型的top宿主，我们可以得知测试用例能覆盖多少用户场景。
最终选择测试宿主如下：
自有内核宿主：微信/手Q（覆盖95%用户场景）；
共享内核宿主：QQ音乐/腾讯新闻/京东/应用宝/王者荣耀/唯品会（覆盖55%用户场景）；
QB：手机QQ浏览器（覆盖100%用户场景）。
机型适配：
对于机型覆盖，我们在选择机型的时候会考虑top覆盖，主流系统版本覆盖，主流手机厂商覆盖3个方面。而因为adb连接和厂商关系较大。所以我们优先通过厂商排名来选择测试机型。通过tbs后台监控数据，可以了解到华为、vivo、oppo、三星、小米为排名前5的厂商。用户数占tbs总用户数的80%。
结合测试组现有机型，我们选择的机型覆盖列表如下：
oppo A33
vivo x7plus
华为p8
小米4
三星S6
测试计划：
（1）跑通上线前用例（冒烟测试）；
（2）跑通单手机全用例；
（3）跑通机型适配top5品牌各1台手机（根据top5测试1台手机测试经过决定要不要增加机型适配）；
（4）宿主适配；
（5）跑通平台适配用例（加屏幕适配测试）；
（6）发布众测；
（7）发布公司内开发者有奖体验。
五、系统测试
测试策略和计划指定后，开始编写测试用例。
1、测试用例编写
首先，为了保证用例能覆盖到每个一个逻辑分支。
我先用思维导图把每个逻辑梳理清楚：
但因为思维导图直接给初级外包去执行不方便（我们很多中级以上的外包直接看着思维导图执行用例，甚至自己编写思维导图用例），所以还需要将思维导图转换为用例。考虑到这个用例除了上线前的用例会每个月用一次之外，其他用例使用频率都很低。所以只有需要交代的地方交代清楚。不需要交代的地方空着就行：
表格中最重要的信息是“功能点”和“测试点”这两列。其他都是需要特别提醒的地方才补充信息。这种用例看起来比较乱，但胜在快速、实用。
编写了单机用例之后，我又补充了各种适配用例：
这些用例都是以单机用例为基础。根据需要适配的内容修改一些测试条件。比如说换一个平台，或者换一个宿主。
这里有一点经验可以和大家分享：就是根据测试条件的影响范围来选择用例，而不是任意一个条件变了都测全用例。
比如说，覆盖不同的平台。我们在单机测试的时候已经在win7电脑上跑了全用例。这里需要适配win10和mac系统，是不是也要跑全用例呢？答案是否定的。因为在和开发沟通的时候，我们已经提前了解到平台适配只对step1有影响，其他步骤的逻辑与平台无关。所以这里只用过step1相关的4条用例。用例量减少了80%。
用例编写完成之后，有一个很容易被忽略的环节是用例评审。很多人觉得用例评审可有可无，或者线上评审一下就行。但按照个人经验，笔者可以很负责任地告诉大家，对于小项目来说线下的用例评审很有价值！因为它不但可以发现用例的问题，还可以通过讨论发现需求和代码实现的问题，性价比很高！
2、单机测试
执行用例的过程大家都比较熟悉了，这里直接粘贴测试报告。
TBS Studio工具 单机用例测试结果：
测试版本：TBS Studio：v1.3.1
平台：windows7专业版64位
手机机型：OPPO A33（5.1.1 已root）
任务链接：略
测试结果：总共22条用例。19条通过，2条不通过，1条未能执行。
不通过及不能执行用例列表：
bug列表：
3、机型适配
单机用例通过后就陆续安排各种适配测试。这里不再展开，只分享一点经验：
“全面”比“深入”重要！
我们在测试中发现了两个有代表性的问题：
win10 32位PC上程序闪退；
7.0手机进入inspector手机闪屏。
这两个问题都很明显，一测就能测出来。而同样的人力投入，如果我们继续测win10 64位系统或者4.x-6.x手机，就很难有这么大的收获。这是因为我们在同一条件下测试越深入，产生的边际效益就会越小。
所以通常来说，“全面”比“深入”重要。
4、宿主适配
略。
5、适配平台
略。
6、Bug回归及上线前测试
略。
六、众测及体验
上线前测试通过后，我们开始做众测。
1、发布众测
公司内有2大众测平台：企鹅众测和QQ众测。企鹅众测倾向于发散性的测试，而QQ众测倾向于用例测试。我们提众测的目的是为了发现系统测试没法覆盖到的点，所以我们选择了企鹅众测。
首先，我跟企鹅众测的业务接口人vincent沟通了他们是否能承接我们这类PC客户端的测试，Vincent说可以。
然后，我就编写了测试要求给vincent。关于测试要求的设计，这里提供2点经验：
（1）测试要求要足够简单明确。因为用户都是非专业认识，太复杂了他们会不懂。以tbs studio的提测为例，我们开始想让用户覆盖很多第三方app。但是要给用户解释第三方app里边怎么进入一个网页是很困难的。所以我们左后只选择了腾讯新闻1个第三方app作为代表。因为它进入网页最简单。
（2）要有明确的反馈要求，做好是格式化反馈。比如说，我们需要了解用的pc和手机的信息。如果让用户在正文里文字反馈，收集到的结果会很乱，也不好统计。于是，我们把这些信息都做成了选项或独立文本框。手机到的信息更规范也方便统计。
具体的测试要求见附件。
经过2天的问题收集。我们得到了40多个反馈。我对问题进行了统计分析，输出了众测结果报告：
TBS Studio工具众测结果分析
测试版本：TBS Studio：v1.3.1 上线前测试版本。
测试时间：2天。
测试要求：见附件。
数据分析：
（1）公共收集反馈42条（众测审核后），其中成功30条，问题反馈有8条。说明遇到问题的用户比例还不少。
（2）8个反馈中，以“inspector页面白屏”反馈最多，有5个。另外，出现crash的用户为1个，占所有win10 64用户的1/18（之前也有不少开发者反馈这个问题）。
（3）按PC类型统计，总共32台PC参与测试（认为一个QQ用户对应台PC）。win10 64位用户比例最大。没有收到mac用户反馈。
（4）按手机品牌统计，总共覆盖8个品牌的手机。参与众测的小米手机最多。没有发现哪个品牌的手机出现问题特别集中。
（5）按手机rom版本统计，覆盖到4.x-7.x的rom版本。其中6.x的手机最多。
（6）按使用app统计，大多数用户使用微信、手Q测试。使用腾讯新闻测试的用户为0。
（7）QB浏览器的6个反馈中，在没有打开网页的情况下开始调试的用户占50%。说明程序的引导提示做得不够。
2、发布公司内开发者有奖体验
众测完成后，我们又在公司bbs论坛发布了公司内部的有奖众测。
在一个星期的时间内，我们收到了6份有效反馈。虽然反馈不多，但是反馈信息比较详细。开发同事April对企鹅众测和内部体验的效果评价是：
“其实都还不错，众测覆盖的比较广，会容易碰到奇葩问题。这次也发现了一个inspector白屏的bug。
内部体验的话，交流比较方便，而且大多都是需要这个工具的同事，更能给到一些建议之类的”。
七、线上数据监控
就此，tbs studio顺利发布。从后台数据看，日活用户数提高不少：（6月16日增长是因为众测、内部体验引入了新用户，以及v1.3.1版本发布）。
