❗ 本文最后更新于 3383 天前，文中所描述的信息可能已发生改变，请谨慎使用。
经常关注我博客的同学可能会发现，我的博客文章从来没有涉及到我所负责的项目、内部工作流程或配套工具。因为项目中遇到的很多问题和对应的解决方案都是基于一定条件所产生，并不具有普适性。内部的工作流程和配套工具也是一样，对于非开源的内部工具或系统来说，无论我把它写得多么天花乱坠，对于我的读者来说价值都是零。
所以我的博客有很多纯粹的技术知识，例如 HTTP/2、HTTP 协议；也有一些普适的技术经验，例如对 Web 服务性能和安全性的优化；还有一些我对开源工具、系统的试用心得，例如 Sublime Text、Alfred，对代码 Review 系统的思考，以及今天要写的移动应用测试平台 —— Bugtags。
首先用一句话定义这个平台：一款着力于提升移动应用测试效率的产品。
这么说大家肯定不明白，先来描述一下大部分中小移动开发团队进行应用功能测试的流程：开发工程师完成功能开发后，团队里面的每个人都要投入到测试中。测试过程中如果发现了问题，需要截屏、手机连电脑并导入截图、记录设备信息、尽可能详细地描述 bug，最终提交到例如 JIRA、Redmine、Bugfree 这类管理系统中。之后的流程就跟传统 web 项目测试无异了。
可以看到，对于应用的功能测试，如何全面、方便地收集 bug 是一个痛点。
先拿 bug 信息的全面性来说：网络是 2G 还是 3G、GPS 是开启还是禁用、内存是否够用、与服务端的数据交互是怎样的（request 和 response）、产生 bug 的操作步骤，这些都不可或缺。对于开发同学来说，越全面的数据意味着 bug 越容易被复现和定位，也就可以为项目测试阶段节省更多的时间，这一点我想不用多解释了。
再来看看便利性。有些同学会说现在的手机已经做得都挺好用了。是的，单个手机看来都挺好，十几个测试机放你面前就知道安卓机的奇葩之处了。有些手机返回键在左、菜单键在右，有些手机恰好相反。还有，我到现在也没完全搞明白我那些测试机都是如何截屏的，每个手机的截屏方式都不一样，甚至装不同 rom 之后都不一样，有些手机要截屏还需要 root。所以我一般在报 bug 时，如果一定要截屏就拿另外手机拍下来。
我这样喜欢折腾的技术人员都觉得给移动应用报一个高质量的 bug 是一件难事，团队里那些 leader、产品经理、设计师就更痛苦了。
当然，对于大公司来说，这些其实都不算是问题，大公司有专门的测试人力和相对充裕的测试时间，也会开发内部工具和平台解决这些问题。但是这些工具都是基于自己业务开发的，目前还没看到哪家公司开放出来给第三方使用。
而 Bugtags 就是一款试图解决以上痛点，并且开放给第三方开发者使用的平台。经过一段时间的内测，发现相比传统的应用测试流程，它有以下优点：
1）SDK 集成简单
Bugtags 做到了一行代码快速集成，不影响原有程序的结构，也不增加额外开发工作量（地球人都知道，如果集成成本高，再好的东西也没人用）。集成后，会在应用界面出现一个可以拖动的悬浮小球，原有功能没有任何影响。
2）所见即所得提交问题
团队成员在测试应用功能的时候，如果发现了 bug，可以在当前界面点击悬浮小球，实现一键截屏（是的，忘记那些安卓机奇葩的截屏方式吧）、编辑标签、描述问题。
3）自动收集设备与应用运行状态
提交问题的同时，会附带自动收集到的设备信息、应用运行时数据等额外内容（再也不用手机连 PC，借助 Fiddler、Wireshark 来抓包定位问题了），同步传到云平台，帮助开发人员更好了解问题发生时设备和应用的状态，有利于问题定位和解决。
4）自动收集分析闪退信息
对于闪退这种对用户伤害很大的严重 bug，Bugtags 可以自动收集和分析，自动提交到云平台（附赠的全自动功能，不用白不用）。
5）简单高效的 Bug 生命周期管理
Bugtags 云平台抽取传统缺陷管理系统的最核心功能，能有效管理和跟踪问题（Bugtags 自带 bug 管理系统，不需要再搭建 JIRA、Bugfree 等同类软件了，系统越多管理成本越高，能省就省）。
如果你有过类似的移动应用测试经历，看到这里一定也想要试用一下这个平台，Bugtags 目前处于邀请内测阶段，第一批大约有 20 个团队的用户。如果你也想尝试一下，请给我留言。
Update @ 22/08，Bugtags 官网已经上线了，请访问官网了解更多信息：https://bugtags.com。
本文链接：https://imququ.com/post/intro-to-bugtags.html，参与评论 »
--EOF--
发表于 2015-08-17 18:42:02，并被添加「软件开发」标签。查看本文 Markdown 版本 »
Comments
Waline 评论加载中...