之前在学习和生活中也碰到过敏捷这个词,对敏捷的理解也只处于灵敏迅速的阶段,关于敏捷开发这个名词还是进入公司之后才接触的,下面就来谈一谈我进入项目组以后对敏捷开发的认识与感受。
1. 理解需求,User Story的编写
迭代初期,通过迭代启动会议将模块分配到人之后,主要是学习流程规范及一些帮助文档,进行需求分析,对所负责的模块要理解透彻,对流程要清晰。虽然User Story是开发人员编写,但是测试人员也要和开发人员常沟通,尽早在需求理解上达成一致,避免在US评审阶段和后期浪费一些不必要的时间和精力。
2. US评审,测试用例和测试规范的编写
User Story编写完成后,要进行评审,就是传说中的“讲故事”,主要是开发人员针对自己所做的模块向大家说明所实现的功能及流程实现,对应的测试人员或其他人员如果有异议则可以提出,共同讨论,商榷定案。US评审之后,开发人员开始编码,测试人员则开始测试用例的编写,主要是根据User Story上每个功能点来编写测试用例,同时要以流程规范为准,确保用例的正确性与完整性。用例编写完之后,测试人员先进行内部交叉评审,修改后交与开发人员评审,得到开发人员的认可,保证测试用例的质量和可行性,之后再修改定稿。用例编写完成后,还要完成测试规范的编写。
3. 单元测试
单元测试期间,主要是针对每日构建版本协助开发人员进行测试,对所实现的功能做随机测试,发现了问题及时知会开发人员修改,并以问题单跟踪。其中,每日站立会议,大家会总结前一天工作情况,模块进度,有什么问题需要帮助解决,以及当天的工作内容等等。在版本构建的过程中,需求可能随时会有变化,所以要及时地对测试用例进行相应的修改,确保无遗漏。经过每日构建版本测试,最终确定ST版本。
4. ST,SDV
ST版本出来之后,测试人员的作用就突现出来了,ST期间主要是执行测试用例,测试整体功能,针对自己负责的模块做重点测试,重点把关。同时,发现的问题需要上Bug库以便跟踪,问题单上Bug需要遵守Bug库操作规范,特别是级别高的要知会到测试负责人或者PM,不能随意为之。一般要经历两轮ST后进入ST回归测试,ST回归主要是对Bug上问题单修改情况做验证。ST回归版本通过后,就是SDV,SDV测试要将之前的测试用例全部过一遍,做一个查漏补缺,发现的问题单也要用Bug库跟踪,SDV测试一般也是两轮,也有可能更多,主要是保证版本的稳定。最后,就是SDV回归,验证问题单修改情况,确定版本稳定的话,验收通过。
5. 迭代回顾会议
迭代结束的时候,都要开一个回顾会议,针对整个迭代中出现的问题做详细的分析,以及在以后的工作中要如何改善提高。此外,对于每个人在迭代中的表现,该批评的批评,该表扬的表扬,自己也可以了解哪些地方欠缺,需要改进。还有就是有经验总结的,以文档的形式展现出来,和大家分享一下,交流一下心得体会,促进大家共同进步。
以上就是我对敏捷开发中关于测试的一些总结,有什么不足或欠缺的地方,欢迎大家指出。