boss问我们对于公司当前功能测试是否有完善意见,突然觉得这个话题离我们很近,却总来没深入总结过。还好要求明天上交报告,先在此做些总结,到时候拼装下给boss.

  接触测试三年了,从测试工程师到测试组长兼sepg,然后跳槽继续测试工程师。一路下来都在跟需求跟业务打交道。做好测试首先要做好需求、理解业务,这个不用多说了,相信很多人都总结过。当然也听到过一些言论“换单位了,那业务不是没用了”,换单位后,业务没用这是必然的,我也是从易制毒换到当前的税务,但有一点都是跟政府行业,其实我们要做的是摸索和总结如何快速获取和掌握新业务,内容不同,但方法是可以通用的。

  对于需求处理,我接触的有以下三种情况。

  A、有需求说明,无设计文档。

  B、有需求分析文档,快完成时临时补充设计文档。

  C、有需求分析文档和设计文档。

  A这种情况一般分工不是很明确的小团队都会出现,需求来源为客户或者区域客服(特点是太简单了没经过提取,或者太自我了,很难实现),这时候在不规范的过程也会弄一次需求讨论。这个时候测试务必要做到这点??争取参加需求讨论会议,不用发言,只要听可以。因为这里没有写文档的习惯,很多测试标准、需求处理细点都会在口头上体现,你得眼疾手快,参加会议很好的一点是测试过程中,碰到不一致的地方,可以有足够的重语气让开发修改,因为你有证据,而不用去问开发这点是不是要改,如何实现。

  B这种情况其实是头痛的,在时间紧和维护项目中经常出现。软件需求功能在界面上都实现了,但开发只是考虑实现需求,却没有把需求与当前业务(其他模块的逻辑),后台数据处理(例如某个字段更新)这些弄好。因为功能测试时,测试人员大都会跑流程或者数据库测试,这时候模糊无标准的问题来了,头痛。另外一些开发人员会以功能实现,进入测试、或者边设计边改,测试大工作量了。这个时候测试有这些可以扭转一些局面??版本验收流程、开发人员给测试人员培训。版本验收:像前面提出的,设计不全面等,很容易导致只完成需求,破坏了原有功能或流程功能,在拿到版本后,进行初步的重要流程验收,可以减少很多测试工作量。开发人员讲解培训:这个很好的解决了由于没设计文档导致的测试不了解内部,被动,另外也是给开发压力,逼他们做单元和集成自测,从中测试也可以提问,不要觉得这是浪费时间,好处你试了才知道。我很坏,呵呵。

  C这种情况一般实行Cmmi3之后的企业都很规范。这里我讲下自己的几个方法,更好的理解需求:模块间逻辑图、数据流向图、需求用例矩阵。模块间逻辑图:其实usecase图、流程图,只要能让自己摸清楚模块间的业务联系即可,为自己的业务测试用例做准备。数据流向图:目的是搞清楚,该某块功能涉及哪些表、存储过程,数据表见关系如何,其实有点像数据库模型的小型版,很多问题在界面上实现了,但后台sql处理却有错误。例矩阵这个主要是对覆盖率进行校验,其实是一个execl,针对某个需求点有哪些用例。这些文档我稍后上转。另外在阅读需求时,多写一些为什么(例如:文档上写着某输入框有默认值,那你注明下:默认值可以修改吗?)

  或许你们觉得让测试参加会议,让开发讲解这些有点难,但记住一点:做测试的一定要“主动”。

  在做功能测试过程中,经常会碰到其他的问题。例如:对于web,所用控件的ie兼容性,标签值显示格式、长度,提示信息风格、内容,按钮大小,名称等这些,当前项目和开发人员都习惯后处理。更多时候测试跟开发还不能达成一致,维护时还有“这是以前开发人员弄的,当前不予修改这些。” 一些通用的界面要求可以定个标准并维护,这个初步难的话,在项目测试计划里能注明下,并达成统一。这样避免项目后期,开发人员改动,测试人员由于对工作负责又得全部测试一遍,减少工作量。

  功能测试,先抓主干,在测分支这是恒定的原则。但如何完善功能测试这个值得讨论,测试前如何分析需求,编写用例,测试通过准则。测试中确定测试版本,选择用例,测试优先级。项目后期的测试分析,用例优化等等。