浅谈软件测试流程(一)
2017-12-17 12:29 第二个卿老师 阅读(693) 评论(0) 编辑 收藏 举报看了虫师的测试流程总结有感,笔者做测试近两年了,前后经历了两家公司,热衷于测试技术,却很少关注测试流程。好比谈恋爱一样,不讲究流程一看到女孩子就上前送礼物,约会,看电影吗,只有清楚自己所在阶段,才能做对应的事。想想也是惭愧,这里回忆总结一下,个人薄见,欢迎指正。
笔者的第一家公司,公司的第一个测试。做第一是美好的,同时也是孤独的,公司是创业公司,有自主的Web产品,笔者介入测试时,产品已经上线了,处于持续改进的状态,不定期发布新需求。
下面是新需求的测试流程:
● 需求分析
新需求获取有两方面,一是客服销售,直接从用户方调研;二是公司经理,他具有敏锐的商业洞察力,同时担任产品的角色,新需求抛出后会由大家一起进行评审。
● 功能设计
评审通过后,由技术老大进行架构设计,分解功能清单,并分配相应任务给对应的UI、开发、测试。老大是多年开发的牛人,亲和力强,感觉什么都会。
● 开发
功能的具体实现(php+mysql+apache),由开发人员编码并调试。笔者此时根据功能清单在禅道中设计测试用例,没有详细的文档,只能大概描述业务逻辑。
● 测试
开发人员调试通过后,SVN提交代码,并部署至测试环境,笔者执行测试,发现的Bug记录在禅道中并通知相应开发人员,修复后再进行回归验证。后来发现缺少规格说明和需求模糊,只能根据实际开发功能测试,也就是说用例的实际意义不大,基本需要重新设计。
● 部署上线
回归测试通过后,提交版本,并由项目经理部署上线。期间用户反馈的问题,再由笔者跟踪修复。
总结分析:
1,可以看出这是很简单的测试流程,重在沟通,往往能很快的修复Bug。
2,整个需求的开发周期要求很短,同时也得负责android和ios端的测试,笔者往往来不及完成系统测试,回归测试也只能选择主要的业务验证,所以每次上线都有很大风险。
3,对应的文档也显得可有可无,没有规范,测试往往显得力不从心。
4,后来笔者分析测试要点并收集典型的测试用例,久了就会有测试思路,测试时也算对产品建立起了一点信心。
笔者的第二家公司,有独立的测试部,不是一个人摸索奋斗了,所以看到师兄师姐,总觉得有股亲切感,这与上家单枪匹马不同,在这里有了更清晰的测试流程。测试人员是根据项目分配的,所以流动性很大。
下面是笔者所处项目的测试流程:
● 需求分析
因为是外包项目,所以需求来源就是乙方公司,由产品和业务人员产出。笔者是由项目支撑的角色进入的,但是需求已经确认了,据说因平台较大,需求写了近一年,分几期开发。
● 需求评审
不同于上家公司,需求评审前会发给参会人员,以便有足够时间分析准备,并且需求会进行几次评审,下次评审会解决上次的需求疑问,直到各方对方案无异议。笔者对需求检查主要针对业务逻辑,是否有定义模糊、需求重复、需求冲突的地方等。
● 设计阶段
此阶段在需求评审完后进行的,项目经理进行架构设计、产品完善需求进行原型开发、测试经理编写测试计划等。及时沟通并组织会议,开发根据进行功能模块的程序编码,测试根据原型以及需求负责用例的编写。
● 执行阶段
在开发人员的编码完成后,由乙方项目经理进行代码审查,部分重要的功能模块由测试经理负责单元测试。完成后,进入集成测试阶段 ,测试组长分配测试任务,和详细的计划目标。从功能测试到可用性测试,再到兼容性测试,安全性测试,最后进行初步的性能测试。
● 验收阶段
在正式的验收测试前,经历了三轮系统测试,期间优化测试用例与追踪问题,在测试退出准则下,笔者测试退出。由乙方公司组织开展验收测试,邀请平台用户进行beta测试,同时引入第三方测试团队,主要负责性能测试。笔者此时准备测试报告、操作文档、功能清单等,之外也会追踪他们发现的其他问题,压力很大啊。
● 上线阶段
验收测试通过后,部署到生产环境,因为是新老平台切换,需要进行数据迁移,笔者在时,这块是重点关注的,进行过埋点数据的验证,还做过多次上线演练。生产环境由乙方运营人员熟悉系统后,再对接切换老平台,上线试运行。
总结分析:
1,此测试流程比上一个描述的更清晰,有了明显的计划目标,测试过程更有信心。
2,相关文档详细,便于业务理解,对缺陷的确认,与开发产生分歧时提供了依据。
3,笔者花了很多时间写测试用例,包括后期完善,它能反映一个人的测试思路,也体现了我们测试的工作。
4,开发提供了相关接口进行集成测试,测试数据的准备,对笔者SQL语言有很大的提高。
5,该测试过程本质还是线性模型,对于需求的变化不够灵活。后期因国家政策,部分需求更新,加上团队没有实现自动化,所以测试工作量很大。国内开发模式大多数是基于RUP统一过程的,而更轻量级的敏捷开发过程还有待我们去实践。