广州红匣子新闻中心

关注互联网,关注技术开发,透析与分享移动互联网行业最新动态

主页 > 新闻中心 > APP开发 > 手机APP开发项目质量保证深究

林楚群

13年全栈工程师

广州红匣子科技创始人

13年APP开发经验、精通JAVA框架

86

开发案例

190

已咨询人数

手机APP开发项目质量保证深究

时间:2021-01-15 18:28:00来源:红匣子科技阅读:210115
随着当今社会的快速发展,尤其是在软件行业,移动APP的发展异常迅速。越来越多的应用程序陆续问世,让用户大开眼界。这时候,一个APP想要赢得用户的好感,就必须以质量取胜。

  随着当今社会的快速发展,尤其是在软件行业,移动APP的发展异常迅速。越来越多的应用程序陆续问世,让用户大开眼界。这时候,一个APP想要赢得用户的好感,就必须以质量取胜。

用户直接觉得产品好,就是问题少。但是每个产品在投放市场后或多或少都有一些生产问题,我们不一定能消除这些生产问题。但是我们可以有效地管理它,从收集、处理到回溯,最终避免一些问题。通过这样做,我们的产品质量将得到提高。那么我们如何收集问题,收集到的问题是否是有效问题,如果确认是有效问题,如何处理,处理后如何总结追溯?为了解决这些问题,我们需要制定一套有效的“生产问题管理标准”。生产问题的管理需要以下功能:

手机APP开发

  下面我们分别来阐述这些功能的实现方法。

一、问题收集流程

为了找到尽可能多的生产问题,我们需要找到尽可能多的渠道来收集问题。

手机APP开发

  最常见的渠道是用户反馈,通常由专门的客服收集。我们需要的是获取这部分数据进行分析,为后续处理做准备。我们把这个渠道叫做“客服反馈”。此外,每个公司都会有一些技术监控方法来发现问题,如市场系统监控、异常服务系统等。通过这些技术手段,我们可以监控生产环境中的系统是否异常。这些被监控的问题也是生产问题。员工在使用过程中也发现了一些问题,所以“员工反馈”也是一个重要的渠道来源。

  在质量工作过程中,我们经常会开展一些特殊的活动,比如常见的代码飞检。代码飞检是对已经定期发布生产的合格代码进行整理,由质量部组织有经验的员工(通常是技术经理、架构组等熟悉业务的员工)对这部分代码进行检查。发现的问题是生产问题。专项检查中也有一种情况,一般是监控崩溃率、HTTP错误、JS错误等。应用客户端的数量。如果监测结果是错误率非常高,APP开发部门可以找到错误的原因。这部分问题也是生产问题,需要集中收集和修改。产品发布前,一般都是在准生产环境下进行测试,此时发现的问题理论上也是生产问题。这部分问题也需要纳入管理。

二、问题确认流程

质量部在每个方式搜集难题,可是搜集到的难题有一些很有可能并不是开发难题。这就必须产品经理和技术经理开展确认。产品经理必须从要求层面开展确认,这种难题的作用情景是否沒有相对要求。技术经理要从技术性层面开展确认,发觉的这种监管出现异常等难题是否压测造成的,并不是确实开发难题。难题确认步骤以下:

手机APP开发

  当产品经理和技术经理对难题确认以后,必须给出一个确立的结果:1、该难题是/否开发难题;2、要不是生产难题,则必须给出缘故;3、若是生产难题,则必须给出难题缘故、恢复方案。全部这种回应都必须纪录账表,做为之后分析问题的根据。必须留意的是,研发部门给出回应时,一定要确立,不可以靠质量部猜想,不然会忽略真实的开发难题。

三、非生产问题处理流程

  前面问题确认时,也明确了“研发部确认该问题不是生产问题后,需要给出原因”。质量部会对这些回复记录台账。适当的时候还会对研发的回复截图记录,这样也是为了后续免责。毕竟生产问题是个大事情,若研发部为了掩盖问题,可能会故意将“生产问题”说是“非问题”。为了以后问题追溯时有依据,所以记录结果是必不可少的步骤。

四、生产问题处理流程

  前面搜集的难题许多,经研发部确定为开发难题以后,这种难题就必须依照“开发难题解决步骤”解决。在这里全过程时要标明难题递交方、难题解决方、难题怎样运转和难题确定方。

  质量确定后,BUG基本信息将通告检验单位,检验单位对于此事难题明确提出BUG单。对BUG的形成原因进行深入分析,寻找解决方法,并明确提出修改计划方案。在恢复BUG后,科学研究工作人员将BUG的情况置为“已处理”,并备注名称“BUG的缘故”,“解决方案”和处理結果。BUG在接口测试中由检测单位进行验证。假如接口测试验证未根据,BUG将被“再次开启”,并再次被开发改动。假如BUG完成检测了,走开发公布步骤,向生产环境公布特点。如今,产品运营必须验证发布产品时的作用。假如未根据生产环境验证,开发将必须再次解决BUG;假如根据生产环境验证,将在BUG单里备注名称“生产环境验证結果”,并通告检测单位。检验单位接纳产品运营的表明信息内容,确定生产环境验证根据后,“关掉”BUG单。

  完毕全部处理方式。它是一个简易的难题处理方式,根据这一全过程,开发难题大部分能够被处理。可是在执行全过程中会发觉有下述难题:a)质量部怎样对所明确提出的商品BUG单进行统计分析检测?如何区分BUG发觉方式的工作能力,便于为事后深入分析做准备?如何区分每一个BUG归属于哪一个程序模块?怎样界定BUG中的缺陷等级?(e)不一样等级的缺陷是不是有解决期限?发觉了开发BUG以后,怎样可以快速地寻找开发责任人?假如开发工作人员发觉了难题,而沒有立即回应和处理,应该怎么办?每一个人物角色都有哪些实际岗位职责?

  对于之上难题,大家必须填补一些有关的标准规定。第一,缺陷管理方案。如今销售市场上面有许多缺陷智能管理系统,每一种规定都不一样。JIRA的事例就是这个事例。要差别商品难题发觉方式,大家可以用“标识”来鉴别;要差别BUG隶属的程序模块,大家可以用“控制模块”来维护保养;要用“端”来鉴别出現难题的类型。因而,之后的统计分析难题将越来越十分清晰。为了更好地防止检测和开发全过程中BUG级别界定的矛盾,商品缺陷等级的界定应该是清楚的。并采用“严治”的标准解决开发难题。换句话说,在接口测试中,难题的缺陷等级是接近比较严重和一般中间的,而在生产环境中则被界定为比较严重。另外也提升了每一个人的质量意识,让每一个人都高度重视开发难题。每一个控制模块都是有好几个连接工作人员,包含:产品运营,技术经理,检测主管。为这种连接人列举的报表,也必须放进标准中。一是能让质量部快速寻找相对责任人连接,二是也可以提升诸位连接工作人员的质量意识。

  依据上述标准步骤,我们可以为每一个人物角色设置岗位职责,使每一个人物角色的岗位职责清楚一目了然,防止在后面造成矛盾。

  除此之外,不一样缺陷等级的缺陷,其处理時间也需作明文规定。一般来说,缺陷等级越高,恢复時间便会越少。因而公司依据自身的业务流程要求作出相对的处理時间长短就可以。

  最后,需要定期报告处理这些问题的过程和结果。质量部门需要通过每周跟踪和每月统计的方式报告这些问题。最终,所有问题形成一个闭环。当遇到一些导致生产事故的生产问题时,需要进行质量回溯,找出根本原因,采取规避措施,以避免今后出现类似问题。

  APP开发公司通过这样规范与问题处理流程,开发问题就可以得到很好的处理和记录。处理问题是过程,最终的结果还是需要大家提高产品质量,避免生产问题。

文章关键词:手机APP开发项目质量

广州APP定制开发公司

上一篇:移动APP开发用户信息安全分析

下一篇:安卓系统的安卓APP开发架构与研发

相关推荐

立即联系 售前产品经理

电话沟通

微信咨询