测试和开发无缝协作——我们为共同目标努力的朋友而不是对立的敌人!
很多朋友问:“VS 2010中的测试功能与业界现有的测试工具相比,最大的优势是什么?”通过这一周发布活动的学习和交流,我发现其最大的优势和不同在于,它定位在如何提高开发人员和测试人员之间有效协作和沟通。而现有的业内工具则更强调测试独立的只能,这往往把测试工作孤立起来,使得开发和测试人员各自在自己的一亩二分地(Silo)中工作,老死而不相往来!正式由于这种彼此之间的孤立,造成了项目开发中的种种资源浪费和效率低下的个现象,如:Bug Ping Pong。更为严重的情况,这种低效率的协作造成了测试与开发的对立,互信的缺失,本来是为了共同目标工作的朋友,却变成了对立的敌人。
Visual Studio 2010中的测试和开发协作流程很好的协调了两者之间的协作关系,提供的多种诊断数据适配器(DDA, Diagnostic Data Adpater)可以自动收集Bug信息,丰富了Bug报告的内容,使得测试人员可以很容易创建出信息丰富、更容易重现的Bug,包括:执行步骤、用户操作、系统配置、现场截屏、操作视频以及IntelliTrace等。其中Intellitrace技术更始锦上添花,它帮助开发人员快速定位问题在代码中的位置。DDA是一套可扩展的框架,用户可以根据需要定义自己DDA来收集想要的信息,例如:dynaTrace就扩展了支持Java/J2EE应用的诊断性能的工具。
自动化测试用例不是仅指自动化界面测试用例,自动化界面测试用例只是自动化测试用例的一小部分
在VS2010中提供了Coded UI Test测试类型,用来实现基于用户界面的自动化功能测试用例,这让很多人非常兴奋。但是在交流过程发现,我也发现,一提到自动化测试用例,很多朋友首先想到的是自动化界面测试用例,VS2010有Coded UI Test,业界常用的还有QTP等。还有部分朋友提到,在他们的团队中全是基于用户界面的自动化测试用例,根本就没有单元测试用例。自动化界面测试用例有其优势,但弊端也是显而易见的:执行速度慢、相对不稳定、创建成本高、维护成本也很高。
自动化界面测试用例是必要的,但绝对是应该有选择的使用。比如说: 可以用它来实现高优先级的验证测试用例(Acceptance Test),或者用来覆盖那些功能的逻辑代码和界面实现代码绑定紧密,无法独立开来测试的产品功能。如果你的项目中自动化测试用例全部是基于界面的,或者有30%以上是,这时候你就不断地要问自己:
● 这些自动化用例维护起来是不是很痛苦?
● 我的自动化测试策略是否需要改进?
● 为什么不能实现更多不需要通过界面就可以覆盖产品核心逻辑的自动化用例?
● 是不是产品的代码将业务逻辑和界面绑定的太死了?
现在70%的测试仍然是手工进行的,提高手工测试的效率至关重要
在VS2010为测试提供了一个全新的集成测试环境(ITE, Integrated Test Environment)- Microsoft Test Manager(MTM),它集成了测试人员常用的功能,包括:创建测试计划、管理测试用例、执行测试用例、快速执行(Fast forwarding)测试用例、创建Actionable Bug、验证修复的Bug、关闭Bug等。MTM的后台就是Team Foundation Server,其数据全部存储在TFS上,所以开发人员也可以通过Visual Studio IDE访问全部的数据,TFS是开发和测试有效的平台,不仅仅数据共享的平台,更是协作流程的有效规划平台。
相关链接:
VS 2010 测试功能学习(十二) 如何用MTM写出高质量的Bug报告?
VS 2010 测试功能学习(十一) 如何用CUIT代码定位UI控件?
VS 2010 测试功能学习(十) 从Generalist到Specialist
VS 2010 测试功能学习(八) RnP与Coded UI自动化测试(下)
VS 2010 测试功能学习(七) RnP与Coded UI自动化测试(上)
VS 2010 测试功能学习(六) Rolling Build
VS 2010 测试功能学习(五)Gated Check-in
VS 2010 测试功能学习(四) Test Impact Analysis
Visual Studio 2010 Beta 2 测试功能学习(三) 真正的主角儿
Visual Studio 2010 Beta 2测试功能学习(二) Q&A
Visual Studio 2010 Beta 2 测试功能抢先学习(一)