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

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

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

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

一、问题收集流程

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

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

　　在质量工作过程中，我们经常会开展一些特殊的活动，比如常见的代码飞检。代码飞检是对已经定期发布生产的合格代码进行整理，由质量部组织有经验的员工(通常是技术经理、架构组等熟悉业务的员工)对这部分代码进行检查。发现的问题是生产问题。专项检查中也有一种情况，一般是监控崩溃率、HTTP错误、JS错误等。应用客户端的数量。如果监测结果是错误率非常高，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开发公司通过这样规范与问题处理流程，开发问题就可以得到很好的处理和记录。处理问题是过程，最终的结果还是需要大家提高产品质量，避免生产问题。