前些日子上线了新版的app,在上线后发现了几个重大的bug,在此总结,在以后的测试工作中需要额外的关注。
- 需求流程bug
- 页面刷新bug
- 标签栏刷新bug
第一个bug出现的原因是产品需求与运营实际操作不同步而产生的bug
产品上线的需求是上线一个活动,活动有报名时间,报名通过公布名单时间。在流程图上,所有一系列的操作都是在活动时间内操作的(包括活动报名,查看名单,通过报名,上传活动体验),而在活动结束后没有任何的操作。但是实际上线后发现的问题是,运营都是在活动结束后才会公布名单,然后用户才可以查看名单,上传活动体验。而此时操作按钮都已经变成了"已结束"。这就十分尴尬了,因为在测试过程中我们根据流程图进行测试,活动时间内可以进行相关的操作,而活动结束了变为了已结束,完全符合需求,功能实现也没有问题,但是实际运营就有问题了。
这个bug的出现很难说是谁的问题,从项目流程来说,在需求定义、流程确认阶段就有问题,导致下游一系列的工作都是在错误的方向;但是从实际工作内容来讲,测试及开发人员对相应地需求没有进行很好地确认,对需求进行深层次的解读,仅仅是看着需求文档就完成了自己的工作,这也是存在问题的。
从测试人员角度出发,这个bug的出现可以让我们反思到一些问题,作为一名测试,如何测试才是有效的测试?是一条条详细的测试案例?是对需求文档的详细分析?我认为这些都不是重点,当我们完全认同这份文档,无论我们提出怎样的问题,设计怎样的案例,都无法测试出其中的问题。拿上述例子来说,就看到的流程来说是没有任何问题的,需求文档得到了开发,测试,产品多方的认同。但就是在实际操作方面出现了问题,那么如何避免这样的问题,或者说可以测到类似的问题?
我认为测试人员应当明确自身的责任,作为一名测试,不是让一个app能够完美运行,让一个系统正常运行就可以了,或者提出这样那样的bug,而是将自己放到一个产品运营,项目开发的质量保障位置,用自己的技术、思维来解决问题,能够发现在项目开发,产品运营中的痛点(这不仅仅是指bug),并能以自己的能力去解决这些痛点,可以让开发、运营更高效的工作,产品系统运营的更好,这才是一名优秀的测试人员,测试人员不应把自己放到提出问题的位置,而是能解决问题的位置,间接的解决问题。莫要先入为主,我就是个测试,我测试的东西能够跟产品需求吻合就OK了,这样可能会测试工作完成的很好,但是从测试人员角度来说已经把自己限制死了。
第二个bug出现的原因是常见的app中cell的复用问题
做过app开发的同学可能都清楚,大部分的app页面都是一个个tableview,tableview重要的一个功能是cell复用,当我们上滑页面,一个cell消失,下面cell出现,其实不是出现了一个新的cell,只是滑出屏幕的cell被复用了,这样做的目的是可以大大优化tableview的性能,但是如果cell复用的时候数据处理不好可就有bug了,没有将之前的数据清除,那么就会造成下滑出现的cell的数据跟上面是重复的,造成各种各样的问题,这个在测试过程中需要多多注意。
第三个bug是标签栏刷新bug
一个标签刷新了,再去点击另一个标签,数据刷新了,但是标签栏选中状态还是上一个标签,常见bug,该拿程序猿祭天了,不多说了。