测试过程的实施-排版
根据个人的测试相关工作经验,一个测试过程大致分为7个阶段:
- 需求分析阶段
- 测试需求编写和评审阶段
- 测试分析阶段
- 测试用例评审阶段
- 测试执行阶段
- 缺陷管理
- 测试报告
每个阶段的详细说明:
一、需求分析
获取需求相关的材料 一般有产品原型图、产品需求文档或者任何有真实记录的资料。
分析需求 首先要自己熟悉需求,其次理清需求中的每一个业务流程,实际中可以采取画流程图的方法来把每一个业务流程明确清楚。最后确定需求中的每个功能点,可以通过思维导图的方式把主功能点、次功能点、分支功能点依次找出,一直找到最小不可再分的功能点,把这些功能点形成功能清单,最后确定每一个功能点的规则和要求,详细描述出来形成一份供测试作为入口的文档,也就是【测试需求文档】。
- 在需求分析的过程中,一定要多和需求来源方进行沟通,确保需求的真实性和正确性。
二、测试需求及评审
针对需求分析后形成的测试需求文档,再次仔细核对每一个功能需求点,并且与产品人员、市场人员、高层领导以及可能对需求产生影响的相关人员核对确认。
及时关注需求的变更情况,如有变更要及时更新到测试需求文档中,做好变更记录及文档版本管理。
最后在准备好完整的测试需求文档后,就可以发起测试需求的评审了。参加评审的人员一般是项目组全部成员。在评审过程中收集好反馈信息,并修正测试需求文档,并最终确定一个正式版本的测试需求文档。
三、测试分析
根据测试需求文档来确定测试策略,哪些功能点要测试,为什么要测这些内容;哪些功能点不需要测试,为什么不要测这些内容,哪些功能点先测哪些后测,最后还要做一些风险分析,在测试过程中可能会遇到的问题,并且做好预备方案,如需求变更,人员变更,技术风险以及测试环境风险。
确定测试方案内容,根据实际情况,在不同的阶段对测试对象采取什么样的测试方法,如功能测试,系统测试,兼容测试,性能测试等,在什么时间段开始或结束这些测试,每一种测试方法包含哪些测试功能点,也是要确定下来的。
在测试分析完成后,要形成测试方案和测试计划这两分文档,并确定一个正式版本,同时也要对文档进行版本管理,有任何变动及时修正。
四、编写用例及评审
根据正式的测试需求文档、测试方案和测试计划来按照计划的时间进度来编写测试用例,测试用例一定要按照规范来编写,至少包含用例编号,用例标题,前置条件,测试步骤,预期结果,实际结果,优先级。
用例按时编写完成后,就可以发起评审了,一般是先在测试组内部先进行一次评审,修正反馈后,再项目组全部成员进行评审。收集反馈后,及时进行修正,就可以确定一个正式版本,用例文档同样也是要做好版本管理。
测试用例编写完成后,建议进行按不同测试方法分类,哪些用例是在哪种方法里面要执行的,比如冒烟测试就是挑选主要的几个功能点用例来执行,系统测试就需要挑选所有的功能点进行测试。
编写用例的相关人员,可以进行统一的培训,增加他们的需求理解,熟悉产品的业务流程。
建议使用用例管理平台来编写和维护测试用例,这样可以做到容易查找,修改,并且不容易丢失和出错。
五、测试执行
根据测试计划的要求,选择对应的测试用例进行执行,比如现在是执行功能测试,那么就把测试用例文档里的功能测试相关的挑选出来分配到相关测试人员进行。
确定好要执行的测试用例后,就要分配好各测试人员的测试任务,哪些人员执行哪些用例,并按照项目进度来规定测试执行的时间。
要求测试人员百分是百的执行每一条用例,做到不遗漏,不做假,执行结果精确无误,并做好记录,填写执行结果。
测试执行可能会涉及到多轮测试,那么要及时关注测试对象的变更,测试环境是否要重新部署,测试用例是否要全量测试,还是增量测试。
在测试执行过程,要求测试人员及时反馈影响测试执行的问题,做到早发现,早干预,早解决。
六、缺陷管理
提交高质量的缺陷单。每个测试人员必须要清楚一个高质量的缺陷单应该包括哪些基本内容,建议在这方面多培训测试人员,例如把每一个优秀的缺陷单进行组内分享和演讲,让大家互相学习借鉴;也可以根据实际情况不断改进缺陷单的模块供大家使用。
缺陷管理必须采用缺陷管理平台来进行管理,方便提交,方便修改,方便共享,方便跟踪状态及分类。
提交了缺陷后,要求测试人员积极跟进自己提交的缺陷,不要提交后就不管了,要积极的与开发人员沟通,尽早的修复缺陷,提高产品的质量。
如果缺陷有得到修复,那么一定要主动及时地进行验证,对缺陷相关的测试用例进行回归,确保缺陷得到完全解决。
七、测试报告
- 一个测试过程最后的阶段就是进行测试总结和形成测试报告,测试报告的主要内容包括:
- 测试用例执行情况:执行了多少?还有多少没执行?
- 缺陷的统计和分析:总共发现了多少个缺陷?严重的有多少?不严重的有多少?
- 测试成本分析:用了多少人员?花了多少时间?消耗了多少测试资源?
做好相应的成本统计,最后进行质量评估,评估的标准一般是缺陷的解决情况
- 不允许遗留的是否全部解决了
- 所有的功能点需求是否都实现了
根据质量评估情况得出结论当前版本是通过还是不通过,也就决定了是否可以交付。
总结在这个测试过程中遇到的风险,有哪些做得不足或可以改善的地方。
把所有测试过程中产生的正式文档进行归档处理,方便以后随时查阅。