拥抱高效、拥抱 Bugtags 之来自用户的声音（五）

Bugtags使用心得（创业公司场景篇）

——成都嘿嘿科技有限公司 作者：小花

一、产品定义

关于手机客户端产品（APP）的 bug 提交、监测及管理且具有团队协作性质的系统。

二、使用环境

公司：初期创业公司，团队 10 人以内，全体使用。
产品：初期，稳步迭代中。

三、测试类产品分析

从进入互联网行业中一直从事与 APP 测试、运营相关的工作，因为初创公司没有测试团队，都是全民测试，所以从 14 年至今也积累了一些非专业的测试经验，也使用过一些软件来进行测试工作的管理与团队协作。

目前市场上与 bug 与相关的产品或服务大致分为两大类：

1. bug 测试类-为了进一步进行专业全面的深度测试

2. bug 管理监控类-为了自己团队进行测试工作体验更便捷和科学

区别

1、Bug 测试类：

关于 bug 测试类有大概分为专业测试和分众测试，比如 testin 和 fir.im。
由于创业团队的产品线和业务部门没有已据规模的公司那样多和规范，所以一般的创业公司没有也养不起一个专业的测试团队，不会设立测试部门，而一个新的产品或版本开发完成之后，又没有比较多的种子用户可以帮助测试以达到收集更多样本信息。
所以 bug 测试类产品主要解决的时创业公司无法对自己的产品进行专业、大范围的测试工作。
如下图：

Bug测试类

2、Bug 管理监控类类：

一般的对于 bug 管理的需求大概分为三种：

1. 提交（使用产品的人主动提交并说明）；

2. 对 bug 进行管理（bug 状态处理、任务指派、bug 说明等）；

3. 对 bug 进行监控（监控非主动提交情况之外的 bug，崩溃、闪退等）；

至于 bug 的监测，通常会另外使用一个第三方的产品（大公司除外），比如友盟统计中的错误分析功能，bugly 等，暂不详细描述。

四． Bugtags 使用场景分析

Bugtags 属于 bug 管理类产品，解决的问题是打通所有测试环节，优化每个环节，从而使整个流程更轻。

1、正常场景

我接触过的大多数创业公司通常的测试工作是这样展开的：

流程图

2、创业公司场景

在没有测试团队的情况下，创业公司通常需要团队的每个人都参与到非专业的测试工作中来，包括产品、市场、运营、客服、以及他们身边的朋友。当非测试与专业人员一同参加测试，随时随地心系产品发现问题提交问题时，这是一件好事。
可是由于非专业人员不懂得开发人员的工作属性，当每个人都把发现的问题丢给开发人员时，由于缺少梳理和明确的描述，会让程序员耗费大量重复性的沟通时间和精力。
一般来说开发者面对一个 bug 通常需要以下四个问题来帮助自己进行判断：

1. bug 描述是否清楚？（非程序员：一直闪退！ 程序员：你干了什么闪退？）

2. bug 能否复现？（非程序员：聊天闪退！程序员：我试了没闪退啊！）

3. bug 出现前做了哪些操作？（非程序员：我真的闪退！ 程序员：我看看你怎么操作引起闪退的？）

4. bug 是否有对应的记录日志？（非程序员：你看我就正常操作，真的闪退吧！ 程序员：我看了下代码逻辑都没问题，等我给你打个日志你再操作一遍我看看问题出在哪！）
   整个流程大致如下图：

工作洲

3、遇到的问题

可以看出正常流程会带来以下三个问题：

1. 降低开发效率

   Bug 的提交通常需要口述或者演示给开发人员，再由开发人员记录，降低了效率，给开发人员增加了一些不必要的工作。

2. 描述与提交 bug 的衔接不够平滑

   即使人人都可以登录 bug 管理系统自行提交，bug 的发现和提交通常会脱节或操作不便捷。我经常在随意使用中突然发现了一个 bug，我需要登录系统提交以及对 bug 进行截图辅助说明。那么我会受到环境的影响，会需要进行截图、编辑、上传等动作，会有一些不便捷。

3. 操作步骤不易记忆与描述

   Bug 出现前的操作需要记忆。跟开发人员沟通过 bug 问题的人都了解，开发人员面对一个 bug 时，最关心两点，能否复现和操作步骤，后者能帮助他们判断问题出在哪和寻找逻辑上的错误。而非专业或不经常进行测试工作的人来说，比如团队中的运营、市场、身边朋友，他们通常是无法清晰的口述 bug 出现之前的操作步骤。
   所以，尤其在创业公司，每个参与测试中或可以为测试贡献一些力量的人，都有一个可以提高效率、操作平滑、符合使用习惯的 bug 管理系统的需求。Bugtags 很好的满足了这一需求，简单来说的话，Bugtags 解决和优化思路有点类似流行的“云”，互联互通。大致流程和原理如下图：

   

   优势

五．Bugtags使用步骤

1. 在线截图、编辑与描述问题，且崩溃会自动截图发送。
   接入了 Bugtags 的 SDK，会出现一个悬浮小球。如果在使用过程中发现了 bug 或问题，直接点击小球，Bugtags 会自动截取当前屏幕图片，然后进入编辑状态，然后就可以使用标签编辑 bug 信息了，整个过程无需跨平台，和二次编辑。

   

   在问题页面直接点击小球

   在问题页面直接点击小球

   

   再点击铅笔，自动截图进入编辑页面

   再点击铅笔，自动截图进入编辑页面

   

   自动截图完毕

   自动截图完毕

   

   点击有问题的地方，直接在线编辑 bug

   点击有问题的地方，直接在线编辑 bug

   

   发送提交

   bug 编辑完成，点击小飞机图标发送提交就搞定啦♪(^∇*)

   

   后台查看

   bug 提交成功后会自动出现在后台，程序员查看即可

   通过以上操作，大多数产品经理或者老板，可以随时随地向程序员、设计师反馈问题。

2. 自动生成设备与环境信息

   

   自动生成设备与环境信息

3. 自动记录用户步骤和日志

   

   记录用户步骤和日志

六．Bugtags 总体使用感受

首先，简单、便捷、专业，很好的解决了上面所列出来的问题：

1. 提高沟通和开发效率；
2. 流程平滑；
3. 自动记录解决 bug 所需的环境与信息。

然后，因为这些优化，让很多场景可以融入到测试工作中，比如产品经理在家里躺着给程序员反馈哪些细节需要调；比如客服小妹妹可以和用户沟通过程中及时反馈 bug。
这无疑是从场景出发设计出来的满足用户需求的产品，联通了数据，联通了操作，联通了场景，也联通了需求。
好的产品总是给人一种“自然”的感觉，似乎也没办法生硬的赞美什么。

七．给 Bugtags 一些建议

1.可以接入或开发配套的监测用户 bug 数据的产品。
2.集合所有接入 Bugtags SDK 的开发者，集中大家在开发中遇到的问题，建立一个有别于 Github 的垂直创业公司的轻开发社区。

Alt text