Visual Studio 2001让“缺陷无法再现”成为绝响
在真实环境中,开发人员说软件没有问题,然后交给测试人员,但问题却出现了,有些问题还无法重现,也无法解决,浪费了项目时间,并最终导致互相推诿责任,团队协作效率低下。
无法重现的原因:1.缺少问题发生的过程记录,2.测试人员的步骤不确定,透明,3.测试人员和开发人员的环境不同。
微软在visual stdio 2011中集成了对microsoft test manager工具的支持,这样IDE与ITE就能够知己知彼,使开发环境和测试环境保证一致的进行还原,创建可以采取行动的缺陷响应, 迅速还原场景,找到根源,并轻松,自动验证所提交的更改。
微软提供的ITE可以方便的截图,视频分段捕捉,自动记录操作步骤,提交详细的堆栈等运行信息,Intellitrace(智能调试器),同时ITE可以进行测试生命周期的管理,用例可以自动或手工进行,可以编写用例,提供标准的测试UI,集成了截屏工具,步骤自动录制,系统现场信息捕捉等功能,测试人员不需要很多操作。
当错误发生时,ITE发送TMS给开发人员,2011可以打开该消息,通过视屏回放,还原现场操作,启动调试时,并可直接定位代码,堆栈信息。
当发现
问题后,修改完,可以使用录制的步骤进行验证测试,并生成测试代码,自动化执行这个用例,在提交给测试人员前,进行充分验证。
Windows 8开发框架,windows runtime全景体验
windows 8的界面将实现三屏合一,winRT是较win32 runtime,是新一代的运行时环境,需要提供以下新特性:
1.自然的用户体验,触屏,多触点,这也是最大驱动力;
2.支持三屏(手机,PC,TV)等各种移动终端。
3.与云集成,与web集成。
4.支持各种传感器。
旧的win32 runtime对这些新特性需求,已经不能支持,winRT是构建下一代基于windows metro风格应用的平台,该平台是支持多语言,如C++, C#和JS,metro风格的组件新语言平台,需要提供统一的user,设备,media和
通信等API和类库。
多语言的支持主要有以下方案:
1.将各个语言纳入到统一中间语言,统一的.NET引擎中(中间语言,通用类型,元数据规范),这样可以统一无缝的集成,但是会以牺牲性能为代价,并且丧失语言的部分灵活性。
2.托管调用native:P/Invoke, COM Interrop,C++/CLI。微软.NET与C++的互操作,一般都是转化为COM组件,在C++中是无法直接访问C#的。这样做的缺点是mashall等转换工作非常复杂,实现成本高。
winRT实现的
方案选择:综合以上两者优势,对C++, C#/
VB, HTML等转化为元数据,它起到接口定义的角色,基于组件进行封装。在COM中,代码和元数据是分开的(分别是COM组件和
类型库);在.NET中,把两者封装在一起,构成程序集;在winRT中,代码和数据再次被分割开来。元数据是组件级复用的基础,复用是软件开发的永恒主题。对元数据描述有以下几点:
描述组件的标准接口
多语言支持
可以由C++, C#, JS生成
与CLI元数据几乎相同的规范和结构
可以使用ILDASM.EXE工具查看
winRT的边界交互:对象(接口)传引用,所有的其他类型传数据。基于metro风格的应用,必须确保及时响应,建议超过50ms的操作应设计为异步,而且任何时候不要阻塞UI线程。
在winRT中,对C#的支持组件的支持,public要符合签名规则,struct只能拥有共有字段,仅支持部分泛型;对C++,又一定程度的扩展,需要增加C#的一些数据类型,映射事件,属性,设计规范和模。无论基于C/C++还是.NET,编译生成的都是native的COM组件的代码,并与STL深度集成,二进制的接口规范,以支持跨平台。某种层面上来说,他集成了C++的效率,.
NET的概念,对C++社区的人来说,意味着C++的强势回归,让C++进入未来操作系统和产品开发的支持,但另一方