烟台app开发:产品经理做好APP测试的八条法则

2016-12-26
阅读:120

  之前有同学希望我写写产品经理怎么做测试。测试,其实就是产品上线之前我们按照一定规则对产品进行检查的工作,确保我们的产品在上线之后没有重大和明显的BUG,并保证用户可以流畅正常地使用我们的产品。我从自己的工作经历出发,谈谈自己对测试的理解,有不对的地方欢迎大家指正。本文只写了一般功能测试的流程和情况,性能测试等模块因为专业性不够,还是留待专业的同学来写吧。

  一、测试谁来做? 在大部分公司里这一块会由专门的测试同学负责,然而在很多创业团队里却并没有专门的测试岗位,测试的工作就需要由产品经理或是产品新人来负责组织。现在也有很多第三方的测试公司承担测试外包工作,如果你的团队人手有限,自己测试确实没有精力兼顾,建议可以考虑第三方测试公司。目前国内这块比较知名的有云测、wetest腾讯质量开放平台等等,大家如果有需要可以自行去了解。

  二、产品经理在测试中扮演什么角色? 如果你的公司有正规的测试部门,那产品经理首先需要做好和测试人员的沟通工作。沟通什么?其实和开发一样,就是要让测试同学充分理解产品的需求,明确各个功能的使用逻辑和场景。这样测试同学才可以更充分理解产品逻辑、功能要求,可以提前做好测试用例的编写和相关的准备工作。我建议,产品经理在需求评审会的时候就要邀请测试部门的负责人和主要负责同学参加。在需求的开端就让测试同学参与进来,除了方便了解产品需求以外,测试同学也会从自己的工作经验出发给产品指出哪里有坑。

  产品经理是对产品需求最了解的人,因此即使有专门的测试团队,你也需要全程参与。除了自己参与测试以外,产品经理也要多和测试同学沟通,及时了解进度,如果有重大问题或BUG,要及时响应,协调相关人员解决问题。测试完成之后,产品经理也应该对产品做一次验收工作。

  如果你的公司请了第三方团队来做测试工作,产品经理需要投入更大的精力去做前期的磨合与协调工作。由于第三方团队大多是异地工作,因此沟通成本会比较大。我们也很难邀请他们来公司当面沟通。除掉前期充分沟通之外,我建议测试用例由产品经理自己来撰写。产品经理是对需求最了解的人,而测试用例和场景是测试的基石,在无法保证测试团队充分理解需求的情况下,产品经理只能通过保证测试用例的高质量来确保测试的质量。

  如果你的公司既没有测试团队,也没有请第三方团队,那么产品经理就要承担起测试的全部工作。也就是产品经理要自己编写测试用例,组织测试(很多时候就是苦逼的自己测试),编写BUG,回归测试。这个时候产品经理虽然会比较辛苦,但我觉得这也是一个很实用的过程。你一方面可以对测试有所了解,一方面也是对你自己的产品思维一次重新磨炼。

  接下来我会重点描述在产品经理承担测试的全部工作情况下,我们要怎么做才能做好测试工作。

  三、测试的类型 以手机APP为例,从全面的角度来说,我们要做:功能测试、兼容性测试、稳定性测试、安全性测试、耗电量测试、弱网络测试……那么对于一款全新app来说,最重要的测试是功能测试、机型适配测试、网络测试、回归测试、UI测试。

  四、测试前要准备什么? 测试用例的编写

  如上文所说,测试用例是测试的基石。在没有专业测试团队的时候,很多时候我们需要其他部门的同事来一起进行测试。那么一个清楚明确的测试用例可以指导大家高效的进行测试。那测试用例都包含哪些内容呢?

  测试用例一般要包括的内容有:

  模块:需要测试的功能模块、页面;

  前提条件:触发该用例的前提条件,比如是否需要用户登录,比如是否需要用户点击某个事件;

  测试环境:比如WiFi、比如移动网络等等要注明;

  测试步骤:描述操作该用例的步骤,引导测试人员。

  期望结果:即按照产品需求规定,一系列步骤应该达到的正确结果。

  设备型号、系统版本:用以让测试人员填写测试的手机型号和系统版本,便于快速定位问题。

  实际结果:测试人员在此填写实际测试的结果,是否和期望结果相同。其实就是BUG描述。

  测试设备的准备

  现在APP的测试,一定要预先准备好各种机型。尤其是安卓机,至少要将市面上主流的机型备齐。同时要兼顾主流的系统版本。测试机可以购买二手机或使用公司同事手机,但绝对不能没有。有些团队对此不重视,或者是为了省钱没有准备充分测试机,结果产品上线之后会发现安卓各品牌会有一些深度定制的情况,冒出很多BUG。影响了用户体验。

  测试人员的分工和培训

  大部分创业团队都是全民测试,但是大家手上都有各自工作,很多时候没有办法全程投入。因此需要提前安排好测试人员的分工。一般来说,产品经理和UI设计师要负责全流程测试,其他同学可以按测试用例分配不同模块进行测试。安排好分工之后,要对相应人员进行一定的需求说明和测试培训,让他们了解如何测试。

  五、如何正确的提BUG? 测试的目的是为了发现BUG,并让开发人员及时定位问题解决问题。那对BUG的正确描述就很重要了。我认为要想正确的描述BUG,需要注意以下几个方面:

  BUG出现的模块/页面:即bug是在哪个模块,哪个页面下出现,最好是明确到在哪个内容/商品下的;

  BUG出现的操作步骤:详情描述出现BUG的所有完整步骤;

  机型和系统版本:清楚列出BUG出现的机型和手机系统版本;

  BUG的重现:一般是截图,有条件可以用手机拍摄小视频,这样可以更立体更直观的重现BUG,开发人员也可以更直观的明白BUG流程。同时要说明是BUG是偶现还是必现

  BUG的优先级:和需求一样,BUG也需要区分优先级。优先级的划分各公司会有自己的机制,但一般来说都遵循这个原则:严重影响用户使用流程的BUG一定要修复,比如崩溃,闪退,无法进入下一流程等;一些比较细微的BUG,不会对用户造成明显影响的BUG,在时间紧张的情况下,可以后续修复。

  六、回归测试很重要 回归测试是测试中必不可少的一环,我们在提出BUG,开发人员修复完成后,我们一定要对修复的BUG进行回归测试。一来确保BUG得到了完全修复,二来检查一下会不会出现延伸BUG。这个工作在没有测试团队的时候,一般是产品经理自己进行(毕竟其他同事还有自己的工作)。

  七、上线后测试 产品上线之后并不代表测试工作结束了。我们需要在正式的线上环境对产品再进行一轮测试,毕竟正式的线上环境可能会暴露出之前没有发现的问题。这时候的测试力度视情况而定,可以是全面测试也可以是冒烟测试。

  上线后测试还可以通过用户访谈和用户评论去发现BUG,毕竟我们无法完全处于用户的使用场景之下。

  八、BUG管理工具 好的BUG工具是工作利器。市面上的工具很多,比如禅道、bugtags等等,这可以根据团队实际情况去采用。最不济,你可以使用excel表格。

  九、测试常见的错误 发现一个BUG立马告诉开发:尽量避免这样,会打断开发的工作流程,影响工作效率,通常都是统一输入BUG管理平台,除非是很重大的BUG或是很难重现的BUG。

  BUG描述不清:尽管上文说了很多规则,但是实际工作中其他部门同学难免会出现BUG描述不清的情况,这时候产品经理就需要去沟通了解清楚,最好可以带上开发同学一起。

  机型不充分:这个上面已经说过,但是还要再次强调!不要怕麻烦,想尽办法搞到尽可能多的主流机型。

  测试是一项重要的工作,需要测试人员的耐心、创造力、观察力。产品经理虽然不是也不太可能成为专业的测试人员,但是仍然需求对这项工作予以重视。

分享到: