移动测试

关于 Bugtags ，网上已经有相关的报道，用来干嘛的我就不说了，就分享几个很爽的点以及感受。以下是以 iOS 为例。 手机截屏直接提 Bug 早些日子在做黑盒测试的时候，先手机截屏，然后手机连接数据线，取出截屏图片，再打开网页，选择图片，点击上传，等待，最后才传到了测试管理平台（如 JIRA）上。使用 Bugtags 只需在手机屏幕上点几下即可完成！节约生命！ 自动添加设备信息 在手机上提交的 Bug 都会自带这些属性，完全不用自己写这些信息了，开发同学一目了然。回想从前手动 Copy、Paste 这些基本信息到 Bug 描述里，真是辛酸。 记录操作步骤 非常好的解释了「这个 Bug 是怎么出现的」这个问题。 当然，也是在手机上提交的 Bug 才会有这样的记录。 清晰的 ViewController 名字、行为、操作的 View 类型、Selector、应用状态变更等，Bug 复现是不是没那么难了？😁 // 保护隐私，截取了部分记录并替换了前缀 21:36:35.3635 Application: DidBecomeActive 21:36:36.3636 Top View: Demo.DemoNavigationController 21:36:36.3636 Top View: Demo.BookViewController 21:36:36.3636 Top View:

遇见 bugtags 之前那点事 那些年，我们单车娱乐 App，自研发到上线，苦逼的在友盟，bugly，bughd 等各种 bug 反馈的工具来来回回踩坑，然而让 QA 和 PM 以及最身同感受的我们这些一线开发工程师表示各种吐槽... 线上的bug收集时候，都不是实时的，很容易丢失现场环境数据，难以跟踪并重现问题，鉴于使用环境以及设备的多样性，一旦发布出去的 App，必然或多或少都有各种奇葩兼容崩溃问题。全世界手机这么多，能 fix 得过来么？ （各种 npe，各种 ise，别介，我已经懒得吐槽了） 大部分 bug 展示的信息只有基础设备信息和一些崩溃的日志，然而没什么用，因为崩溃或多或少都涉及到用户的使用环境才能重现并得知问题原因从而进行修正处理。 人肉测试占比例很大，尤其是在测试过程中，一旦发生意外，处于一线开发的工程师就像消防员那样十万火急的救火，为的是意外的现场日志以及相关操作流程。（人肉测试的苦，谁做谁知道） 曾经对 QA 来说的一场噩梦：截图，情况描述，环境描述，操作描述等等相关bug的反馈，让 App 的质量保证越发紧张和效率低下。 QA：这个bug修复了么？ App工程师（就是我）:没有，我还在研究这怎么出现的 （10分钟过去了。。。） PM：刚才我测试崩了，你们看看神马情况 QA，一众工程师全围观上纷纷议论。。。。 鉴于以上四点吐槽，我相信各位看官感触良多

Bug 管理系统，技术同学都见过很多，和 最适合移动应用 、 智能 几乎扯不上半毛钱关系，就是一个登记 Bug 的工具而已。 那么 Bugtags 的特别之处是什么呢？为什么说它是 最适合移动应用 的 智能 Bug 管理系统呢？ 最适合移动应用 大家在测试移动应用的时候，发现一个 Bug 通常会收集以下数据： Bug 产生界面的截屏； 测试设备信息； Bug 的重现步骤等。 在传统的 Bug 管理系统里，上述数据都需要我们手动收集并提交，所以我们通常只会用文字描述一下 Bug，因为要收集以上数据，确实挺费时间的，而且还是在移动设备手动收集数据（想起截屏导到电脑，是不是很崩溃？），然后在电脑上提交到 Bug 系统，怎么也得几分钟吧？面对繁重的测试任务，只能选择「轻描淡写」了。后续就靠口头沟通来协助技术同学定位及解决 Bug。 Bugtags 最适合移动应用，就在于它不只是一个记录 Bug 的系统，还能够协助测试、自动收集 Bug 相关数据。 从发现 Bug 到提交 Bug 在你的应用端里就能够「所见即所得」的高效完成，同时还会自动附带 Bug 产生时的相关数据，技术同学只需要在 Bugtags 的管理云端通过查看提交的数据就可快速定位及解决 Bug。 现在你的测试方式是： 发现 Bug，在应用中点击 Bugtags 悬浮球，自动完成截屏； 在 Bugtags 弹出的截屏上直接标记