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

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

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

1、产品定义

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

2、使用环境

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

3、测试类产品分析

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

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

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

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

一、Bug 测试类：

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

二、Bug 管理监控类类：

通常的对于 bug 管理的需求大概分为三种：

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

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

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

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

四． Bugtags 使用场景分析

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

一、正常场景

我接触过的大多数创业公司一般的测试工做是这样展开的：

二、创业公司场景

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

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

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

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

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

三、遇到的问题

能够看出正常流程会带来如下三个问题：

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 提交成功后会自动出如今后台，程序员查看便可

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

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

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

六．Bugtags 整体使用感觉

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

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

而后，由于这些优化，让不少场景能够融入到测试工做中，好比产品经理在家里躺着给程序员反馈哪些细节须要调；好比客服小妹妹能够和用户沟经过程中及时反馈 bug。
这无疑是从场景出发设计出来的知足用户需求的产品，联通了数据，联通了操做，联通了场景，也联通了需求。
好的产品老是给人一种“天然”的感受，彷佛也没办法生硬的赞美什么。

七．给 Bugtags 一些建议

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

​