软件测试流程进阶----两年软件测试总结 - 虫师 - 博客园

2019-04-03 04:54 澳门葡京官网
工作两年了,我一直希望让自己每年对测试的理解更深入一层。工作一年的时候我写了《谈软件测试---一年工作总结》,谈轮了自己对各种测试的理解,这一年来,虽然对那些理概念的有所加强,自我感觉没有什么质的变化。前些天听我们公司的一位测试经理讲《敏捷测试》豁然开朗。他在学造飞机,而我一直在学造飞机里的一个发动机。我从来没想过,一个完整飞机的架构应该是怎样的。如果想让测试在公司的项目中发挥出它最大的价值,并不是招两个测试技术高手,或引入几个测试技术,而是测试技术对项目流程的渗透,以及测试流程的改进与完善。虽然,当然测试行业前景乐观,许多中小企业也都在引入测试,但一百个公司就有一百种测试,每个公司对测试的看法不同,公司对测试的定位也不完全一样。本人前后经历两个公司,以自己的拙见浅谈一下对测试流程的看法。先说笔者入职的第一个家公司,笔者是第一个入职的专职测试人员,相信一两个测试的公司还是不少的,入职后各种项目都在进行当中,上面给我的定位是并没完全融入到项目中去。而通过指派任务的方式。我们做的是某一移动公司内部使用的项目,需求分析与架构全部由项目经理完成,之后由项目经理给具体某个开发人员分配任务,具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高,他既然担任了需求分析师,又担任架构师的角色。笔者入职后的第一个任务是搭建缺陷管理工具,禅道项目管理,通过推广对发现的问题进行跟踪。后来正明效果并不好,因为对于一个六七人的开发团队项目,开发人员更喜欢测试人员能当面反馈,这样更能提高效率。对一个小bug通过当面交流的方式就可以将问题修复。你会发现在流程图中,A程序员是先发上线之后,再进行测试。这是我们一个面向大众用户的网站,上面给于测试人员的定位是测试员兼用户体验员,测试员将发现的bug和体验问题提交到缺陷管理系统,由经理对问题进行分析,指派开发人员解决。定期对系统进行更新。对于测试来说,需求很不明确,测试文档与用例也是可有可无的产物,没有需求文档,或非常简陋,根据需求文档根本无法编写用例。笔者只能收集一些通用的测试用例,如登录、文件上传下载、列表翻页、日期选择、输入框验证、搜索等有一些通用型用例,以便在测试过程中做参考。功能测试的多了,拿到一个功能,测试思路也就出来了。放弃上份悠闲的工作,感谢那个带我入行公司,我想了解真正的测试在公作中如何进行的。所以,来到了现在这家公司。我很欣喜的是这测试有自己的团队,专业(对当时的我来说)的流程,以及与开发等同的地位。需求分析由产品人员制定,他们要做的不是一份简单的文档,而是细化每一个功能的细节,每一个按钮的位置,对于稍大或复杂一点的需求都进行建模。这里会叫上所有参与项目人员进行,开发人员、测试人员、QA人员。测试人员提出需求,开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问,以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人,所以也需求了解需求测试人员根据开发计划,对测试具体测试时间,也就是开发功能完成后的时间,进行几轮测试等。然后,把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。开发人员对于基到测试线的功能进行测式,发现的问题通过缺陷管理工具进行反馈,开发人员对问题进行修复,然后,准备第二轮基。经过两到三轮或四轮的测试后,直到没发现新的问题,或暂时无法解决,或不紧急的问题。通过上级确认,可以通过。编写测试报告与验收方案。验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的,测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的,但这对测试的要求会更高,除了关心功能,还需要关心整体流程与质量。对于刚接触这个流程的我来说,这个流程是规范的,测试真正融入了整个流程,而且还担任了很重的角色,从而也有效的保证了软件产品的整体质量。那么这个流程是不是完美的呢?不,这个项目流程太强化各种文档。我们来看测试的工作内容,测试计划、测试用例、测试结论、测试报告、验收方案、问题的提交跟踪。其实,我们真用于测试的时间是非常少的,在一周的时间,也许只有一天或不到一天的时间是在进行测试的。测试人员只有在测试的时候才会体现出他的价值。而大部分工作却不能体现他的价值。下面来看敏捷测试,本人并没有接触过敏捷,对敏捷也没花时间学习与研究。唯一接触就是听我们测试经理对测度流程讲了两个半小时,听讲的人很多,我站着听的。受益匪浅,凭着记忆也简单谈谈。前面讲的第一种流程,还是第二种流程都是瀑布式的,严格来说第一种简陋的都不能称为瀑布式,对于一个三个月的项目说,产品把需求分析完了给开发,然后产品就没事儿了;开发开发完成之后给测试,然后开发人员也不忙了。测试完成之后上线。那么在产品分析的阶段,开发和测试都是没事干的(这里只对单一项目)。开发阶段,产品和测试也基本没事儿。同样在测试阶段,产品与开发也是没什么事儿的。通过上面的流程图,对于一个月的需求分析,在敏捷中,可能三五天就确定下来。这个需求定得会很模糊,但整体框架确定。产品对其中某一模块功能确认,开发人员开始对确认的功能编码,开发人员编码的过程中,测试进行功能分解,因为根据模糊的需求很难写出具体的用例,所以,只能尽量对功能进行分析得细些,标注需要验证的内容。在这个流程中弱化了文档,强调了各个人员的沟通,通过这种迭代的方式,三个月的项目,可以能两个月和两个半月就会完成。第一块面板中是开发人员未实现的功能,第二块面板中是开发完成功能,测试人员对其进行测试,发现不通过的就放回未开发的面板中,测试通过的将放到第三块面板中。需要说明的是,敏捷测试在国外很流行,在内容,雷声大雨点小,推行的人很多,真正有公司引入的不多。我们所在公司千差万别,测试流程也可能有很大的不同。对于已经工作两年一个测试员来说,从来没关注过测试流程与结构应该是个悲剧。我希望不被思想局限,所以,努力冲破一个又一个的局限。