如何做好和完善功能测试总结
作者:网络转载 发布时间:[ 2011/8/16 17:23:49 ] 推荐标签:
boss问我们对于公司当前功能测试是否有完善意见,突然觉得这个话题离我们很近,却总来没深入总结过。还好要求明天上交报告,先在此做些总结,到时候拼装下给boss.
接触测试三年了,从测试工程师到测试组长兼sepg,然后跳槽继续测试工程师。一路下来都在跟需求跟业务打交道。做好测试首先要做好需求、理解业务,这个不用多说了,相信很多人都总结过。当然也听到过一些言论“换单位了,那业务不是没用了”,换单位后,业务没用这是必然的,我也是从易制毒换到当前的税务,但有一点都是跟政府行业,其实我们要做的是摸索和总结如何快速获取和掌握新业务,内容不同,但方法是可以通用的。
对于需求处理,我接触的有以下三种情况。
A、有需求说明,无设计文档。
B、有需求分析文档,快完成时临时补充设计文档。
C、有需求分析文档和设计文档。
A这种情况一般分工不是很明确的小团队都会出现,需求来源为客户或者区域客服(特点是太简单了没经过提取,或者太自我了,很难实现),这时候在不规范的过程也会弄一次需求讨论。这个时候测试务必要做到这点??争取参加需求讨论会议,不用发言,只要听可以。因为这里没有写文档的习惯,很多测试标准、需求处理细点都会在口头上体现,你得眼疾手快,参加会议很好的一点是测试过程中,碰到不一致的地方,可以有足够的重语气让开发修改,因为你有证据,而不用去问开发这点是不是要改,如何实现。
B这种情况其实是头痛的,在时间紧和维护项目中经常出现。软件需求功能在界面上都实现了,但开发只是考虑实现需求,却没有把需求与当前业务(其他模块的逻辑),后台数据处理(例如某个字段更新)这些弄好。因为功能测试时,测试人员大都会跑流程或者数据库测试,这时候模糊无标准的问题来了,头痛。另外一些开发人员会以功能实现,进入测试、或者边设计边改,测试大工作量了。这个时候测试有这些可以扭转一些局面??版本验收流程、开发人员给测试人员培训。版本验收:像前面提出的,设计不全面等,很容易导致只完成需求,破坏了原有功能或流程功能,在拿到版本后,进行初步的重要流程验收,可以减少很多测试工作量。开发人员讲解培训:这个很好的解决了由于没设计文档导致的测试不了解内部,被动,另外也是给开发压力,逼他们做单元和集成自测,从中测试也可以提问,不要觉得这是浪费时间,好处你试了才知道。我很坏,呵呵。
C这种情况一般实行Cmmi3之后的企业都很规范。这里我讲下自己的几个方法,更好的理解需求:模块间逻辑图、数据流向图、需求用例矩阵。模块间逻辑图:其实usecase图、流程图,只要能让自己摸清楚模块间的业务联系即可,为自己的业务测试用例做准备。数据流向图:目的是搞清楚,该某块功能涉及哪些表、存储过程,数据表见关系如何,其实有点像数据库模型的小型版,很多问题在界面上实现了,但后台sql处理却有错误。例矩阵这个主要是对覆盖率进行校验,其实是一个execl,针对某个需求点有哪些用例。这些文档我稍后上转。另外在阅读需求时,多写一些为什么(例如:文档上写着某输入框有默认值,那你注明下:默认值可以修改吗?)
或许你们觉得让测试参加会议,让开发讲解这些有点难,但记住一点:做测试的一定要“主动”。
在做功能测试过程中,经常会碰到其他的问题。例如:对于web,所用控件的ie兼容性,标签值显示格式、长度,提示信息风格、内容,按钮大小,名称等这些,当前项目和开发人员都习惯后处理。更多时候测试跟开发还不能达成一致,维护时还有“这是以前开发人员弄的,当前不予修改这些。” 一些通用的界面要求可以定个标准并维护,这个初步难的话,在项目测试计划里能注明下,并达成统一。这样避免项目后期,开发人员改动,测试人员由于对工作负责又得全部测试一遍,减少工作量。
功能测试,先抓主干,在测分支这是恒定的原则。但如何完善功能测试这个值得讨论,测试前如何分析需求,编写用例,测试通过准则。测试中确定测试版本,选择用例,测试优先级。项目后期的测试分析,用例优化等等。
相关推荐
最新发布
性能测试之测试环境搭建的方法
2020/7/21 15:39:32软件测试是从什么时候开始被企业所重视的呢?
2020/7/17 9:09:11Android自动化测试框架有哪些?有什么用途?
2020/7/17 9:03:50什么样的项目适合做自动化?自动化测试人员应具备怎样的能力?
2020/7/17 8:57:06几大市面主流性能测试工具测评
2020/7/17 8:52:11RPA机器人能够快速响应企业需求,是怎么做到的?
2020/7/17 8:48:05Bug可以真正消灭吗?为什么?
2020/7/17 8:43:03软件测试基本概念是怎么来的?软件测试生命周期的形成历经了什么?
2020/7/16 9:11:10