TEL : 0558-4285588

1名6年测试经老司机自述-安徽弘展网络科技-互联互生创新领航

作者:弘展网络科技

测试工作不仅仅要从产品的角度去保证产品质量,还要完善研发流程,就像一条流水线工作,每个环节都不能出错,才能生产出优质的产品。

前言:

本篇文章更适用于敏捷开发的团队,如有不足,欢迎探讨。

测试工作不仅仅要从产品的角度去保证产品质量,还要完善研发流程,就像一条流水线工作,每个环节都不能出错,才能生产出优质的产品。

本文所指开发周期15工作日左右,测试时间5天左右。

主要流程:


一、需求评审

由产品经理发起,参会人:产品经理、项目经理、开发、测试,如有需要,提出需求方,如业务人员、运营人员也可参与。产品经理讲解产品设计,主要包含用户场景、业务流程、页面设计、交互设计等。建议遵循互联网人人都是产品经理的理念,每个人提出自己认为最好的实现方式,但最终还是由产品经理定义。

(1)开发同事要从技术角度、和现有框架支撑情况评估各个功能是否可以实现,如不能实现,要与产品沟通折中方案。若产品一定要实现该功能,开发要给出时间,也就是开发成本。

(2)测试同事相对更了解整个系统的业务逻辑,要判断每个功能的实现,是否与系统整体的使用习惯匹配,若差异较大,要提醒产品经理,否则会让用户觉得系统逻辑混乱,使用困难。同时思考每个功能点的测试方法,如需要开发协助的,也要及时提出,让开发做好后门,如果有测试点评审流程,也可以在测试点评审时提出。

(3)业务、运营人员要确定产品设计是否符合需求,并认真学习产品的使用。

评审过程中,产品经理记录要修改的地方,会后第一时间修改(建议当天完成),然后发出需求邮件,进入开发阶段。

二、测试点编写(开发阶段)

该阶段分为两个部分,测试点编写和测试开发

测试点编写和开发并行,个人建议不需要写详细的测试用例,测试点和测试用例的取舍,可另行探讨。测试点编写同时,要及时与产品沟通,有修改的地方,第一时间同步到开发。

测试点应包含:

(1)本次新增、修改功能点。

(2)可能影响到的功能的回归

(3)系统重要功能回归

如果有需要的话,进行测试点评审,且要至少在提测前2天进行,由测试人员发起,给开发人员缓冲的时间,产品、项目经理、开发、测试参与,测试点评审重点要强调流程、异常处理、测试方法等,一定确保大家对产品的理解没有偏差。测试人员记录要修改的地方,会后第一时间修改(建议当天完成),然后发出测试点邮件。

测试开发部分,根据项目实际情况安排工作,如自动化用例的持续集成、mock系统的开发等,个人认为这些很重要,是提高测试从业者个人能力的重要环节。

三、提测

提测要求开发方满足一定要求,要求可酌情而定。但至少要做到本次迭代的主要功能在测试环境可跑通,如果提测不通过,开发加班修改,当天知道满足提测要求为止。避免开发挤压测试时间的情况发生。

四、测试阶段

通常分为三轮:

(1)第一轮,产品可满足用户场景,且主要流程可通。

(2)第二轮,进行异常操作、兼容性等测试。

(3)第三轮,功能回归。

如果测试人员在2人以上,建议进行交叉测试。

测试阶段可以对bug修复做一些要求,如:

(1)提交bug后,开发做出响应,比如在bug管理系统中,bug状态处于处理中,若10分钟内没响应,测试人员应提醒一下。

(2)对bug修复做出时间要求,如当天某个时间点之前提出的bug,今天必须修复完成。时间点可根据具体情况定,我们是下午4点。

对于封版要求,各不相同,比如bug修复率达到95%以上;代码覆盖率100%等等,本人更倾向于x小时内没有严重问题产生才可以封版。封版前的多半都是回归测试、冒烟测试阶段,若此刻还有严重问题产生,证明第一轮、第二轮测试不充分,或者开发修复bug时未考虑周全,引出其他bug。针对封板要求,希望可以和大家讨论一下,各取所长。如果未满足封板要求,但项目要求必须上线,则需要将风险体现到测试报告中

封版前(可以是当天下午),建议不修复bug,产品、项目经理、测试人员一起评估,若一定要修复的,要谨慎修复并验证,不修复的遗留到下一期处理。

五、封版、上线

封版和上线对于测试来说没什么区别,最重要的是发布包不能变更,至于上线与否,根据公司情况而定,本人公司测试完成仅封版,上线时间由产品和开发决定,上线后通知测试,在正式环境验证功能是否正常。

此时需要发测试报告,应包含内容:

(1)结论:如测试通过、不通过(原因)

(2)工时:人/时

(3)bug统计

(4)存在风险

(5)附件:发布包

六、项目总结

由项目经理发起,总结本次迭代中存在的问题及改进措施。也可以收集在团队协作中,各个角色间是否对他人不满意,并进行疏导或改进。

总结:

还有两个本人认为很重要的流程没有加进来,开发代码review和功能验收。对于大多数敏捷团队,因为各种原因,这两个流程都会被省去。代码review应该加到提测前,益处多多,不赘述。功能验收,应该由需求提出方和产品功能验收,以确保产品满足需求,但此阶段如果出问题,对整个项目来说都是致命的,即使功能上有出入,产品被打回的几率还是很低,所以验收流程对于敏捷开发似乎存在的意义不大。

会议发起者或项目经理要适当控制会议节奏,避免话题无限延伸的情况,做无意义的讨论,浪费时间。

项目经理要将每个阶段,至少精确到天,当天差一丢丢能完成,就要加班,如果差很多,就要延期,并有明确的延期原因。

工欲善其事,必先利其器,本人更注重提测前的准备工作,如需求评审、测试点编写、测试点评审阶段,统一思想,明确产品方向,准备测试数据,保证测试方法可行,后期的工作会更顺利。

任何流程的制定,可能最终都会变成“道理我们都懂,但实践起来困难重重”,本人觉得我们至少要总结出一套高效、完善的工作流程,即使不能完整的执行,但也要朝着正确的方向不懈的努力。

今天安徽弘展科技就和大家一起分享到这里,对于正在寻求探索经营之路的顾客们,希望能够帮到你们,想要了解更多经营百科经营攻略,请关注我们安徽弘展网络科技,也可以直接联系我们的在线客服了解更多。



会员登录
登录
留言
回到顶部