非寻常实习记Ⅱ:改变中的快乐成长

从第一篇《非寻常实习记》至今,已经过了一年多的时间。这一年多里,感受着周遭的变化。同时,我也从一个艺术设计专业的大三女生,到如今成为一名用户研究及交互设计专业的研一新生;从很不习惯听到与计算机相关的术语,到如今会很欣然地与许多计算机专业的朋友们交流;从不知道什么是用户体验设计(User Experience, 简称UX)到参加人生中第一个用户体验设计比赛并获得了第一名。不禁感叹“改变”,更感叹改变过后自己收获的“成长”。 当初一直感到很“莫名”,莫名着好不容易考进一所男生比例极高的学府,却在一个女生比例最高的学院读书;意外地进入了一个以男性为主导的行业,却在一个男女比例差不多的小组实习。今天,这种“莫名”已然蜕变成了一种“习惯”,甚至是“乐在其中”。乐于继续享受着已经工作了的同龄人享受不到的读书时光;乐于继续享受着在STB China 付出、更收获学习做事、做人的实习历程。 改变带来的“新” 体验 今年一月,我工作的地点从紫竹信息数码港5号楼搬到了新落成的微软中国上海科技园区。工作地点的改变带来的不仅是更好的工作环境,更让我结识了许多从市中心搬来的同事们。 我们用户体验设计团队也有了自己独立的办公区,这打破了原先团队成员们各自坐在不同产品组的分散状况,让我们大家有了更自由交流的空间。我们的办公区位于在大楼四层一处两面临窗的角落,依窗而望就是园区内大片的绿草地。下午时分,我可爱的法国老板 Nico会放些轻松的曲子,工作之余坐在窗沿上,或是躺在窗边的沙袋沙发上看看窗外的蓝天和绿草,顷刻所有的压力和烦恼都会抛诸脑后。 微软中国上海科技园区(一期) 办公桌一角   暴雨放晴后在窗户上作画 在园区内捡到的石子上作画   改变带来的“新” 机遇 从小就喜欢画画的我本科四年学的是艺术设计。大四的时候,在工作还是直研的问题上,我毫不犹豫地选择了直研。最主要的原因之一就是近一年的用户体验设计实习让我在自己的职业规划上有了很清晰的定位:要成为一名最优秀的交互设计师。希望自己能在用户体验设计上有更多的知识和实践的积累,也因此选择了与之相关的并且也是我最想了解的用户研究方向。 与其说,我是改变了自己的专业方向,不如说我是开拓了自己的学习领域。怎么样在自己最擅长的视觉设计基础上,结合自己实习过程中不断增强的交互设计能力,以及在研究生学习中积累的用户研究知识,这对于我是一个挑战,更是让我跨向更高层次设计阶梯的机遇。 本科毕业设计的作品之一 现已代表团队送予美国微软的同事 闲来无事时的小画   改变带来的“新”思考 前不久,团队里两位同事的离开带给我很大的影响,这影响不仅包括要适应新的团队环境,更包括让我重新思考诸如理想、工作、人生等很多方面的问题。 他们的离开带给我最多的思考就是关于“快乐”的。正像一次公司培训中老师讲的那样:“快乐不是没有痛苦。快乐不是结果而是过程。”什么才是快乐呢?对于我而言,快乐不在于我是否失去了什么,而在于我知道我已经获得了太多太多的东西。快乐不在于我是否感到会痛苦,而在于即使我有时难过想到那些一直都陪伴着我的人们就会不由得绽放出笑容。快乐不在于找什么方法让自己去变得快乐,而在于让那些我爱的人们快乐了就会很快乐。 手绘的啤酒杯 送给喜欢旅行的同事的礼物 送给喜欢阅读的同事的礼物 其实,我是个挺不喜欢改变的人。也许是因为天生比较感性的缘故,总觉得只要周遭一有什么东西改变就会带给我不安定的感觉。但往往环境不是由我们个人的意志所能改变的,从积极的一面去看待改变,正如古语所云:“流水不腐,户枢不蠹。”它能让我们始终保持前进而不停止,也能始终让我们有所收获而不退步! 刘蕙

2

重访四川山区乡村小学—— 糖房村明日中华小学落成典礼小记

2009年4月28日,HPC中国团队及其家人一行近二十人实地考察了四川省营山县合兴乡糖房村大垭口民办乡村小学,当场慷慨捐赠物资来支持校舍建设。之后,团队成员和美国明日中华教育基金会(CTEF)为使这些孩子们有一个更安全的校舍进行了广泛募捐。2010年8月19日,小学校的八十多名师生终于搬出了昏暗的租借民房,从此有了属于自己的崭新校舍! 学校修好了之后,捐助者们也很挂念,都想去看看。不过因为工作或家庭的原因,想要付诸实践并不容易。这次小学新校舍的落成典礼就由服务器与开发工具事业部的四位同事代表大家参加了。 这个国庆,我终于读了仰慕已久的书《三杯茶》。故事是说一个美国登山者Greg Mortenson在攀登世界第二高峰失败后,饥寒交迫、又迷了路,幸而得到巴基斯坦村民的搭救。虽然村民们很穷,一年吃不上一次肉,还拿出了家里最好的东西,热情地款待了他。在那里养病过程中,他注意到村里的84个孩子坐在门外,用小木棍在泥地里扒拉着识字上课。这村子穷到连一天花一美元雇个教师都做不到。 Greg离开村子时,他立誓一定要回来,为恩人们建所学校。他辛苦奔走,历时12年,迄今为止在巴基斯坦和阿富汗地区建了60余所学校。但故事绝不是一帆风顺的,Greg最初尝试写信给580位名人、商人和其他美国精英人士筹集钱款,结果只收到100美元,还需要面对恶劣的自然条件、地头蛇的算计和塔利班的监狱。对比一下我们项目的大事记,我只觉得自己是多么的幸运啊。 另外很受触动的是,我们并不需要等到非常富有之后才能为公益慈善事业做贡献,因为钱从来都不是最重要的因素。很多事情看起来不可能,但这也许是因为我们对“关注圈”和“影响圈”的归类有些悲观,太容易找到借口说服自己接受“不能改变的事情”? 我和三位同事张璐、熊小锐、赵迎宾拜访了由各位热心同事、朋友捐资修建的四川山区的小学校,与村民、师生欢聚一堂,共同参加了“糖房村明日中华小学”的落成典礼。 从上海出发,3个小时飞机到成都,4个小时汽车到营山县,3个小时汽车到合兴乡,半小时山路徒步到小学。这一路除了驴车,我们啥都坐了,hoho。 蒙蒙小雨中,我们从县城出发。小轿车满载着大家从上海带去的衣服、书包、纸笔、橡皮泥和在县城买的乒乓球器具等,沿着弯弯曲曲的山路开往合兴乡。十点多到达时,雨恰好停了。车刚在路边停下,就有好几个村民热情地迎上来。 经过一段有惊无险的崎岖山路,远远地就听到了乡村小学里孩子们稚气而嘹亮的歌声:“爱心叔叔来了吗?爱心阿姨不怕苦,我们大家学习他,学习他们的好榜样,我们在学习上要努力,长大了不忘记,不忘记叔叔的爱心,学习他的好榜样。” 原来这是乡村小学的廖老师指挥着孩子们唱着她自己作词作曲的歌在欢迎我们呢!我又一次被深深打动了。忘了是谁说的,这一刻开始,觉得前面辛苦地走那么远都是值得的。 快步走到新建的乡村小学校门,不太宽敞的校园已经被学生、家长和他们的欢声笑语挤得满满的。升旗台下搭了一排“主席台”,教室外墙张挂着大红的横幅,校门外还准备了鞭炮。没想到村里把这个“糖房村明日中华小学”的落成典礼安排得相当隆重,有升国旗、嘉宾和学生代表发言、剪彩等环节。仪式过程中,乡村小学还送给我们两件珍贵的礼物:一面锦旗和一个装有全部学生照片的大相册。 接下来的节目是给孩子们上课。幼儿园和一年级有小孩子在哭闹,幸好有大姐姐一样亲切的熊小锐在廖老师的配合下带着小朋友们一起高兴地做游戏;赵迎宾按照教案给“高年级”的学生寓教于乐地讲解了“二分法”找数。可爱的孩子们面对镜头,有的兴奋,有的淡定,但那份纯真,是任谁看了心都要为之柔软的。 教室窗外挤满了家长,大都是老人或妇女,也就是当地人自嘲的386199部队——包括妇女、儿童和老人的留守群体。从他们殷切的眼神,不难看出,这些孩子们就是他们的希望。他们自己在大山里辛苦劳作了大半辈子,多么希望儿孙能学有所成,改变这面朝黄土背朝天、靠天吃饭靠地收的命运。而我们则应该有一分热,发一分光,努力帮他们改善办学条件。这个乡村小学的建成,离不开许许多多我们团队微软热心同事和其他朋友们的关心和支持,在此感谢大家。 魏臻 注:希望了解更多有关这所山区小学捐助进展的同学请关注http://blogs.technet.com/b/chinahpc/archive/tags/villageschool/。

0

第8章 用户体验:上海汽车工业集团(下)

刚参加完中国高性能计算2010年会 (HPC China 2010),HPC的几位工程师们忙着相互校审徐博士的《微软高性能计算服务器》的英文翻译,准备在几周后的SuperComputing10上发表。某日下午,突然传来一声”惨叫“,原来有人发现有几段文字漏了翻译,尤其这些段落读来极具有“娱乐性”,又鲜活地展现了高性能计算在目前工业界应用的现实挑战,因此在这里与各位读者分享。 8.4 SimCloud: 基于Windows HPC Server 的门户环境 上汽使用了泛云公司提供的高性能计算门户系统——SimCloud。 8.4.1 平台架构 SimCloud仿真云计算平台是将CAE/CFD等仿真应用、高性能计算集群管理、SOA(Service-Oriented Architecture,面向服务架构)等IT技术高度融合的企业级高性能计算中心软件系统方案。 我们可以从多个角度分享、剖析这个全新的云计算平台。 平台的整体网络架构如图8-1所示。 图8‑1 高性能计算平台网络架构 平台架构的中心是仿真云管理门户,它负责联通客户端与HPC集群,实现活动目录(AD) 用户管理、邮件服务、仿真流程/数据管理、仿真数据存储等功能的表现层服务。仿真云管理门户的左侧主要是HPC集群及相关附属设备,右侧主要是各种类型的仿真应用(图中仅为示例,可拓展至所有仿真应用客户端)。 8.4.2 功能架构 SimCloud平台的功能架构可以分为资源层、服务层、业务层与表现层,具体如图8‑2所示。 图8‑2 SimCloud系统栈 资源层主要负责整合硬件资源、网络资源与软件资源,Windows HPC架构下的SimCloud平台主要利用Windows HPC Server操作系统进行这一整合工作,通过.NET服务将仿真软件封装成Web Service接口。 服务层封装了Windows HPC Server R2,Email Server,FTP Server,AD Server等服务器角色功能,为整个平台提供丰富的服务接口与扩展功能接口。 业务层囊括了用户管理、作业管理、数据管理、邮件通知、调度策略管理、系统资源管理、日志管理、统计报表等业务功能,并为PLM等工作流系统提供业务流程扩展接口。 表现层通过SimCloud仿真云管理门户,以Web Portal的方式统一整合了任务提交、资源监控、管理作业、文件传输、License管理、使用统计、用户管理、决策分析等一系列应用功能。 8.4.3 仿真工程师”常用场景: SimCloud仿真云计算平台具有操作便捷、功能丰富的特点,其应用流程也紧密贴合企业内部不同角色的使用人员,在功能完备的基础上力求逻辑简洁。 图 8‑3 仿真工程师常用场景 如图 8‑3所示,一般仿真用户可以使用企业域用户帐号登录SimCloud仿真云管理门户,通过简单操作之后即可将仿真任务提交到高性能计算集群头节点,头节点遵循既定任务调度策略,根据当前硬件资源利用情况以及仿真软件License使用情况,提交任务至计算队列并进行自动的任务分配,计算完成后,计算节点整合仿真数据,通过邮件通知仿真用户,用户即可从SimCloud门户获取仿真结果文件。 8.5 应用集成案例 SimCloud仿真云计算平台可以集成多种仿真应用软件,包括计算结构力学、计算流体力学、计算声学、多体动力学、计算电磁学等多种学科常用商业软件,并且提供开放的接口方便集成各类软件应用。架构于Windows HPC Server 2008…

0

第8章 用户体验:上海汽车工业集团(上)

刚参加完中国高性能计算2010年会 (HPC China 2010),HPC的几位工程师们忙着相互校审徐博士的《微软高性能计算服务器》的英文翻译,准备在几周后的SuperComputing10上发表。某日下午,突然传来一声”惨叫“,原来有人发现有几段文字漏了翻译,尤其这些段落读来极具有“娱乐性”,又鲜活地展现了高性能计算在目前工业界应用的现实挑战,因此在这里与各位读者分享。 中国是个制造业的大国。但在制造业中高性能计算普及度并不高。原因如同郎咸平教授所说,中国制造业企业大部分从事来料加工,处在制造业下游利润最低处。没有自主产品的设计,就无法获取丰厚的利润,也无法使企业的可持续增长有任何保障。本章我们走近我国一个具有自主设计能力的制造业公司——上海汽车公司。在上汽,高性能计算在产品设计中起到了举足轻重的作用。 过去,基于Linux系统的集群给IT部门和工程师带来诸多管理和使用的障碍,使高性能计算技术在上汽各部门难以推广。从2009年开始,上汽IT部门成功地部署了Windows HPC Server集群及应用,成功地将高性能计算资源提供给多部门、上百个设计工程师,大大地提高工程师的设计的效率,同事降低了IT部门的管理开销。 我们在本章介绍上汽的商务需求,过往使用Linux系统遇到的挑战和Windows HPC Server 解决方案带来的优势。 在以前的章节里,读者了解到Windows HPC Server 如何能够简化上汽系统和作业调度的配置、定制和管理。在本章,我们着重介绍简化提高工程师运行应用、监控结果的另外一个常用的解决方案 —— 仿真门户系统。 本章的8.3~8.6节内容是摘录泛云公司的《仿真云计算平台SimCloud解决方案—Windows HPC 架构》白皮书,8.3~8.6节的内容属泛云公司的知识产权。笔者得到泛云公司对8.3~8.6节内容的书面许可,特此鸣谢! 本章要点 上海汽车工业集团简介和商务需求 计算机辅助仿真(CAE)在高性能计算环境的应用现状和挑战 泛云SimCloud:基于Windows HPC Server 的门户环境 8.1 上海汽车工业集团简介和商务需求 作为中国三大汽车制造商之一,上海汽车工业公司(简称上汽)主要致力于生产、销售、研发客车、商务车及其部件。在2008年,上汽销售超过182.6万辆车、营业额超248.8亿美金居全国榜首,在全球五百强企业中居第359位。上汽也在自主设计、生成和销售自己的品牌的小轿车,包括荣威750、550,MG 3-SW,MG 7和MG TF的品牌在中国成功推出,增强了上汽的品牌形象。上汽高性能计算中心是为了支撑自主品牌的小轿车的设计和安全分析。 上汽开始主要为其他汽车厂商,如大众和通用。 自2004年其, 上汽开始自主设计和生产自己品牌的汽车。一开始他们使用的是租用的设计和测试设备。到了2006年,上汽开始创建自己的设计中心。 2007年,上汽购买一个基于RedHat Linux操作系统高性能计算集群并使用此集群运行汽车设计模拟仿真应用。上汽在此集群上运行多种商业计算机辅助设计应用,包括FLUENT, STAR-CD, STAR-CCM, LS-DYNA, MSC.Nastran 和 ABAQUS。 对于熟悉Windows工作站的工程师和管理人员来说, 管理、定制和使用一个基于Linux的集群是有很大的挑战的。 工程师被迫使用Linux的命令行界面与集群交互。这种体验既不友好又费时,极大地限制了IT部门向其他部门推广计算资源的能力。许多工程师情愿继续使用安装在Windows工作站上的应用。 8.2 基于Windows HPC Server解决方案和优势 2009年夏, 上汽决定采纳基于惠普刀片机和Windows HPC…

0

高性能计算成就光荣与梦想

     中国高性能计算大会(HPC China 2010)今天在北京举行,微软高性能计算产品的第三个版本Windows HPC Server 2008 R2也将于同期发布。这是高性能计算领域的两大盛事,加之我的新书《微软高性能计算服务器》也将一起与读者见面,这三者交织在一处令我异常激动。想当初,我就是被一股无法逆转的大趋势 —— 高性能计算的普及所推动,才义无反顾地投身这一激动人心的领域。也是这一全身心的投入带我穿越迷雾,走向明朗的未来,成就了我生命中的光荣与梦想。        什么是高性能计算?高性能计算是提高仿真和决策支撑应用性能相关的硬件、网络和软件技术的总称。高性能计算通过整合、管理和调度硬件和网络资源,提供强大的计算和数据处理能力,帮助人们随时随地精确的模拟现实,认识现实,使得现实为己所用,为己造福。从应用方面看,高性能计算最开始都是用在先进国家的一些科学前沿的基础研究上面,而现在已经普及到了普通的通用产品,象汽车、飞机、医药和金融风险分析等。事实证明,高性能计算有效地压缩了从建立模型和分析数据到提出解决方案所需的时间,被誉为名副其实的创新催化剂,也是各个国家创新竞争力的重要指标之一。        这股时代的浪潮从20世纪80年代末开始,把高性能计算技术从发达国家的实验室推向全球的实验室;从高等学府和研究院推向工业界;从制造最先进的杀人武器推向研究将生命从绝症中挽回的药物;从研究大自然的规律的应用推向预测市场风险和决策支撑的应用;从少数几个推进科技前沿的项目的数据中心里,推向普通学校、研究院教授和研究人员桌面。        我是一名六零后。八十年代初,我作为大学生见证了高性能计算普及浪潮的开端。1987年,我获得“中英友好奖学金”赴英留学。我选择了并行计算——这一我认为当时最先进的技术。同年,我以英国埃克塞特大学博士生的身份去伦敦参加研讨会。会上,我遇到一个工业界人士,当他问及我的研究方向时,表达了他的观点:“你这是在浪费青春。第一,未来会有越来越快的向量机;第二,没有人会修改自己的应用,并让这些程序运行在并行机上。”然而,我还是偏执地认为,并行一定是未来的方向。后来回想,正是这种偏执,让我在这条路上,披荆斩棘,迎接曙光;更让我明白了,哪怕是权威人士,一样会有局限性,自己的抉择才是最重要的。这两点道理,让我不论在研究方面,还是职业选择方面,都能够听凭自己内心的声音,做出无悔的选择。        今天,我在中国、在微软从事高性能计算技术的研发——从某种意义上来说,微软是最具草根精神的企业之一。比尔·盖茨在创立微软的时候,有个家喻户晓的愿景:“让每个家庭有台电脑。”微软所培育出来的600万名开发者,给整个PC产业带来了杰出的贡献,这也为微软成为整个软件界的霸主奠定了坚实的基础。全面的通用化给整个产业带来了快速的发展和进步,而包括以TCP/IP为基础的互联网产业的兴起,更是将原来神神秘秘的企业计算、网格计算等云端的技术带到了一般开发者面前。        2004年,微软成立了高性能计算产品组。在一次产品组策略审核会议上,盖茨看了高性能计算产品组的演示。演示包括两步,使用的是一个制造业的应用。第一步是串行应用运行,花了很多时间。第二步,把应用连到集群,很快就结束。盖茨当时就说了一句话,在创建公司的时候,他的愿景是让每个家庭都有台电脑,看了这个演示后,他觉得高性能计算的下一个目标就是让每个科技人员都拥有高性能计算机!        也正是在2004年,在从事了8年时间集群、网格作业调度系统、并行应用运行时环境的产品架构和开发工作后,我意识到了我的职业理想与微软的草根精神、公司愿景是一致的,于是我加入其中,决心将HPC的事业彻底贡献给每一个专业用户。        在过去6年中,我和中国研发团队一起顺利完成了新平台作业调度模块中的全新用户界面、SOA(面向服务架构)编程模型的开发和测试工作。在上述几个重要功能中,全新用户界面包括图形用户界面和传统的命令行界面,不仅使系统管理人员能直观、快捷地管理整个HPC集群,更帮助桌面用户在熟悉的界面上使用高计算能力解决复杂问题;SOA编程模型为开发人员提供了简单易用的并行计算编程方法,为并行计算进入主流应用打下坚实基础;报表功能帮助系统管理人员及时收集集群运行和作业执行信息,以图表形式显示集群、各个用户、作业等的“健康”状况;基于PowerShell的全新命令行管理工具,加速系统管理和提交作业任务的自动化。   此时,整个高性能系统栈的重建几近完成,原来的向量机系统已开始出现被通用型微机体系取代的真正可能。最初偏执的信念,让我抓住了趋势的发展。用我的总结来说,微软具备做高性能计算,并且完成高性能系统栈所缺乏的关键的优势在于以下方面:   1、拥有600万程序员用户——了解他们的编程习惯和模式。 2、拥有最流行的编程环境——Visual Studio的多年积累。 3、一流的作业调度和管理系统——Windows 高性能计算服务器。 4、基于WCF的高性能面向服务的平台作为运行时环境。        这些优势全都是独一无二并令人心动的。加上微软长期以来在大规模客户端和服务器平台的丰富经验,让我对微软充满信心。我坚信,我将伴随微软最终能实现整个高性能计算普及的目标;我也相信,微软的理想足以打动那些有志于此的同仁加入,并为之奋斗。        美国总统杜鲁门在二战后和冷战期间的1950年发表如下讲话:“我们已经意识到我们国家生存和发展的能力在极大的程度上取决于我们的推进科技的步伐。此外,仅仅跟上世界其他国家科学的脚步是不够的。我们必须保持我们的领先地位。”的确,美国在科学和工程领域的领先地位得益于杜鲁门政府所设立的目标。今天,杜鲁门所说的话对于任何希望通过创新来维持可持续的竞争力和经济增长力的国家依然有极大的可借鉴价值。        有人说:“要与他国竞争取胜,必须在计算模拟上取胜。”在计算模拟上取胜是什么概念呢?IDC 2009年发表的“全球高性能计算硬件、网络设备和软件销售数据”显示:高性能市场份额中北美占了50%,欧洲32%,日本5%,亚太12%,其他地区1%。北美绝大部分是美国所占有。所以,从资金投入上,我们清楚地看出美国在高性能计算上的投入超过世界上任何国家,显示出美国要在计算模拟领域继续保持领先地位的决心。因此,高性能计算技术的重要性不言而喻。        承载了我多年来在高性能计算领域积累的思想和经验,我希望通过《微软高性能计算服务器》一书帮助专业领域的读者一步步掌握HPC服务器的使用诀窍。它有几百张截图,而且书中所有的示例代码、脚本文件、Visual Studio项目都可以从TechNet下载。  …

0

用Visual Studio实践敏捷测试(四) 下

测试运行的实现       测试运行可以通过Team Foundation Server提供的生成功能来实现。在Team Explorer的生成菜单中选择创建新的生成定义(Build Definition),通过指定不同的触发器(Trigger)就能使其分别适应于封闭签入、滚动生成或定期测试运行的需要,如图一所示。 图一 触发器       在生成默认值选项卡中指定生成控制器(Build Controller),在生成控制器接到生成请求的时候会在生成代理(Build Agent)池(即在该控制器上注册的所有生成代理)中选择一个来执行生成任务。 图二 生成默认值       而在流程选项卡中可以指定需要生成的对象、运行的测试用例等具体内容,如图三所示。这里需要特别指出的是在指定运行的测试时,还可以指定测试配置文件,在该配置文件中可以将测试执行方法(Test execution method)设置为远程执行(Remote execution)并选择一个测试控制器(Test Controller)。这样测试控制器就能将测试分配到器上注册过的不同测试代理(Test Agent)上运行了。 图三 流程       关于如何创建和配置生成控制器、生成代理、测试控制器、测试代理,感兴趣的读者可以查阅msdn上有关的信息,在此我就不再赘述了。       通过这些设置,就可以配置出不同的生成,以满足开发过程中各种不同的测试运行需要。 小结       在本系列的最后一篇中,我们讨论了各种不同的生成和测试运行的目的、作用以及如何选择运行的测试用例。各种不同层次的测试运行相结合,才能最大限度的发挥测试用例的作用,在兼顾“敏捷”的同时,保障产品的质量。另外,我们还简单介绍了Team Foundation Server提供的生成服务,以及如何通过生成服务来实现测试运行。         至此,我和大家分享了整个敏捷开发的测试流程、我们的开发团队的如何利用Visual Studio作为辅助工具实现敏捷测试以及我们在实践中积累的经验教训。希望这个系列能抛砖引玉,为大家实现自己的敏捷测试提供一些参考资料。 🙂 林俊彦 软件测试开发工程师 本文收录于《程序员》10月刊。

0

用Visual Studio实践敏捷测试(四) 上

     在上一篇中我们介绍了如何编写自动化的测试用例,在拥有了一定数量的自动化测试之后,随之而来一个很自然的问题就是如何有效地利用这些测试更好地在敏捷开发的过程中保证产品的质量。在这一篇中我们就来讨论一下基于不同目的的各种生成(Build)和测试运行(Test Run)以及如何实现这些运行。   封闭签入(Gated Check-in)      在本文的第一篇中我们曾经提到过在敏捷软件开发过程中每一个Sprint结束时团队都应该有一个可以运行和演示的版本。这对团队成员来说是一个艰巨的任务。因为一方面必须在有限的时间内完成用户故事的开发,提供相对完整的用户体验,这就要求开发人员“敏捷”迅速的签入代码;而从另一个角度来说,频繁而迅速的签入显然会对生成的稳定性带来极大的挑战。尤其是当团队成员以用户故事而不是产品部件来分工时,签入与签入之间常常会有重叠的部分。在这种情况下,如何才能保证各项签入在集成到产品中后,产品还能正常工作呢?封闭签入就是一种比较严格的实时保护产品功能的方法。        所谓封闭签入是指在签入代码之前,先尝试生成文件,如果生成失败则拒绝签入,只有在生成成功的情况下代码才会被签入代码控制系统中去。这里的生成,可以是单纯的编译生成,也可以在此基础上再运行一些指定的自动化测试以验证生成的质量。使用这种方法的优点是能很好地确保了指定的用户场景(即指定的测试用例集所覆盖的用户场景)不会被破坏,而缺点就是拖延了时间甚至可能造成阻塞——签入必须等待生成完成、测试用例运行结束,而且签入还可能被拒绝,一个签入可能要反复多次提交,更糟糕的是在几次提交之间其他团队成员可能也提交了签入请求,这又进一步延长了一次签入所需的时间。        为了使封闭签入不至于成为开发流程中的瓶颈,我们必须在生成测试覆盖和生成时间二者之间找到一个平衡点,即在保证每次签入能在较短的时间内(通常我们认为<10分钟是比较理想的范围,10~15分钟是可以接受的范围)将结果返回的前提条件下选择适当的测试用例以达到所期待的用户场景覆盖。很显然,为了满足上述要求,测试用例的运行时间及其覆盖的内容是选择测试的主要依据,而另外一条不可忽视的选择标准是测试的稳定性——运行不稳定的测试用例显然不适合用于在短时间内决定签入是否符合要求。以下列出几条我们选择封闭签入测试集的原则供大家参考: 从基础用户场景入手:我们不可能在封闭签入中保证所有已有的功能不被破坏,在时间有限的情况下,只能丢卒保车,只关注那些基础的、核心的用户场景,围绕这些场景选择测试。对于其他功能场景的验证保护将由我们稍后介绍的其他一些测试运行来完成。 单元测试是封闭签入测试集的主力:开发人员编写的单元测试通常是直接与产品部件接口对话,运行稳定且速度快,是封闭测试的首选。特别是在我们的开发团队中,对于开发人员签入的功能严格规定了必须同时签入相应的单元测试,这使得单元测试对产品功能的覆盖率相当高,使其更能胜任封闭签入测试的职责。 在单元测试基础上补充部分验收测试:单元测试虽然以运行速度快且稳定两大优势占据了封闭签入测试的主要部分,但是单元测试所针对的还是独立的产品部件或是方法,保证产品各部件正常运作不代表各部件集成起来之后仍正常工作。所以为了确保产品的端到端用户体验,我们有必要从测试人员编写的验收测试中抽取部分核心场景的测试来完善整体用户场景的测试覆盖。 尽量不要在封闭签入测试集中引入UI测试:UI测试不可避免的与运行速度慢和不稳定联系在一起,与封闭签入的需求几乎正好相反。但我们也不能一概而论,直接规定不允许在封闭签入测试集中添加UI测试。比如特定的UI测试能提供别的测试无法达到的产品覆盖,且该测试覆盖到的用户场景十分重要,在这种情况下也可以考虑将该测试添加进测试集,当然前提条件是,该测试足够稳定且运行时间不能过长。      在我们的实践过程中,基本上就是采用了单元测试+核心非UI验收测试这样的组合。另外,我们还在部署测试运行方面利用了Visual Studio提供的测试代理(Test Agent)功能实现测试的分布式运行,大大缓解了运行时间和测试覆盖之间的矛盾,为更全面的用户场景覆盖提供了可能。我将在本文稍后对测试代理再做介绍。   滚动生成(Rolling Build)      滚动生成是另一种实时的保护产品已有功能的方法。与封闭签入拦截签入并插入验证的做法不同,滚动生成并不监控代码的签入,而是采取了相对宽松的方式——允许随时直接签入代码,在代码签入之后再进行相应的验证。滚动生成自动对当前时刻已签入的产品代码重复执行生成文件和运行指定测试操作,每一次的滚动事实上验证的对象是从上一次滚动开始时刻到当前时刻之间的所有签入。当某一次的滚动生成失败时,在此期间签入代码的团队成员应该负责尽快找出并修复错误,或者在错误无法迅速修复的情况下撤回导致问题的签入。也就是说滚动生成并不会直接影响团队成员的正常开发工作,但是要求大家在确实出现问题时暂停手头的其他工作及时将产品代码恢复至一个合理的状态。        对滚动生成测试集的选择标准相对于封闭测试要宽松一些,因为滚动生成并不要求签入的个人等待其结果,所以没有太大的运行时间压力。我们对滚动生成的期望一般是1个小时左右滚动一次。在实践中我们囊括了几乎所有验收测试,对各项功能都有一定程度的覆盖,在滚动生成保持通过的状态的情况下,我们对产品代码的实时质量还是有相当的信心的。另外,为了规避不稳定的测试用例带来的不必要的结果分析时间,我们还引入了再次运行失败的测试的策略,只有2次运行都失败的情况下,滚动生成的结果才会被认为是失败。        与封闭签入相比,滚动生成的主要优势包括: 滚动生成不阻碍签入,不影响正常的开发节奏,不会造成瓶颈 滚动生成每一次运行针对多个签入,测试的效率更高 滚动生成不要求很短时间内出结果,换句话说,可以允许执行更多的测试用例        而滚动生成也有其不足之处: 滚动生成并不能保证产品“随时”都处在可正确运行基本功能的状态 滚动生成不能及时将签入的质量反馈给团队,例如在某一次滚动刚开始后发生的签入几乎需要2次滚动的时间才能确认是否达到了签入的要求 滚动生成在出错时需要分析多个签入以找出问题所在,花费了额外的时间        在实践过程中,通常封闭签入或是滚动生成中的一个就可以满足团队对于产品功能保护的需要了,开发团队可以根据实际情况选择其中之一。不过有时也可以将二者结合起来同时使用。同时使用的好处是分工更加明确,封闭签入就只运行单元测试等少量最核心的测试,甚至可以不运行测试只生成文件,尽可能减少额外的等待时间;而滚动生成则负责完成对基本用户场景的完整覆盖。   定期测试运行      前面介绍的两种生成+测试运行都是用于功能的实时保护的,都对运行时间上有较严格的要求,所以测试用例中大量的功能测试通常是不会在这些测试运行中被执行的。完整的测试集通常只在定期测试运行中使用。这里的定期可以是每天一次、每周一次或是两周一次等等,可以根据团队具体需要以及完整测试集运行所需的时间来确定。        我们的产品开发使用的是三层的分支结构的源代码树,平时的改动都在功能分支(Feature Branch)上进行,每一个Sprint或一个里程碑做一次和产品单元分支(Product Unit Branch)的集成,从产品单元分支到产品主干(Main…

0

用Visual Studio实践敏捷测试(三)下

自动化测试的实现       编写自动化测试也许对很多测试人员来说比较陌生。所幸的是Visual Studio中为实现自动化测试提供了一系列的工具,单元测试(Unit Test)、编码UI测试(Coded UI Test)、压力测试(Stress Test)、网页性能测试(Web Performance Test)、数据库单元测试(Database Unit Test)等等,让实现自动化测试变得轻松。这里我想着重介绍2种最基本的,也是在我们的产品开发中最常用的测试:单元测试和编码UI测试。 1. 单元测试       单元测试是Visual Studio中最基本、应用最广泛的一种测试。通常开发人员可以选择为一个方法或是一个部件创建单元测试,来保证其逻辑正确。       要在Visual Studio中创建单元测试,可以在源代码的上下文菜单中选择“创建单元测试”,并在弹出的窗口中选择需要为其创建单元测试的方法(如图一、图二所示)。这样Visual Studio就会自动创建出一系列单元测试的代码框架,以及针对private/internal等无法直接调用的方法的访问器(Accessor),用户只需修改或添加具体测试逻辑即可。访问器会随着源代码的每一次编译自动更新,为用户节省了不少麻烦。当然,用户也可以使用单元测试向导创建,或是直接添加一个单元测试(测试->新建测试)文件再自行添加逻辑代码。 图一 创建单元测试 图二 创建单元测试对话框       单元测试通常以[TestClass]属性来表示一个测试类,在测试类中使用5种不同的属性标示方法:[ClassInitialize]、[TestInitialize]、[TestMethod]、[TestCleanup]、[ClassCleanup]。一个测试类中可包含多个测试方法(Test Method),但是仅可以有一个类初始化方法(Class Initialize)、一个测试初始化方法(Test Initialize)、一个测试清理方法(Test Method)、一个类清理方法(Class Cleanup)。在测试运行时,类的初始化会被首先调用,然后在运行每一个测试方法之前运行测试初始化,之后运行测试清理,在测试方法运行结束后,类清理方法将被运行。除测试方法外,其他的辅助方法都不是必须的。大家可以根据实际需要来安排代码逻辑。       成功编译后,所有测试方法都会在测试视图(Test View)窗口中列出,在该窗口中还可以对测试方法进行过滤、查询和排序,选择一个或多个测试方法后,可以运行或调试测试用例。测试的结果(是否通过)会显示在测试结果(Test Result)窗口中,双击任意一条测试结果都会打开具体的测试结果日志以获取更详细的信息,如图三所示。单元测试还可以通过直接在测试方法代码中右键选择“运行测试”,或是在命令行中直接执行mstest命令来运行。 图三 测试视图和测试结果       此外,单元测试工具不仅可以用作单元测试的目的,也可以作为一种载体,来实现验收测试或是功能测试。我们在实践中大量利用了Visual Studio对单元测试的管理、运行、日志等功能,通过在测试代码中实现验收测试、功能测试的具体逻辑来完成各种不同类型的测试。 2. 编码UI测试       虽然单元测试框架适用于各种不同的测试,不过其本身却没有提供太多对测试代码实现上的支持。对于自动化测试中常常令人无从下手的UI操作的自动化,Visual Studio 2010中添加了一种新的测试类型——编码UI测试,以帮助用户克服这一难题。编码UI测试是一种能轻松上手,迅速创建出UI测试的框架。       一种最简单的创建UI测试的方法是直接从手动测试入手。如果此前我们曾在Test Manager中创建了测试用例,并曾在手动执行时录制过其测试步骤,那么我们就可以直接将录制的步骤转化为编码UI测试的代码。在Visual Studio中选择创建一个编码UI测试后,会跳出一个对话框询问用户是使用已有的操作录制还是重新录制,选择第二项“Use an existing action recording(使用现有操作录制)”后即可通过查询测试用例工作项将相应的测试转化为自动化测试代码(见图四)。…

0

用Visual Studio实践敏捷测试(三)上

    在上一篇中,我们讨论了敏捷开发流程中的一些由手动执行的测试任务。手动测试是需要人工完成的测试,被广泛应用于各类产品的各种测试任务中,而与之相对应还有自动化测试,即通过程序自动运行完成测试任务。自动化测试能帮助开发团队节省测试运行的人工、提高开发效率。接下来在本篇中,我想和大家讨论一下敏捷开发中手动测试和自动化测试之间的关系以及如何实现和利用自动化测试。   手动测试的特点     由于手动测试依赖于人工操作,很自然的存在着不确定性,每一次的操作都可能或多或少有一些不同。这种不确定性既是手动测试的优点,也为其带来了一定的局限性。从优点的角度来说,手动测试更加灵活多变,可能在不经意间就采用了一种全新的操作序列,或者将产品带入一个意料之外的状态。这有助于深入测试产品功能的细节,覆盖那些常规思路无法到达的用户场景。而从另一个角度来看,手动测试的不确定性也使得其测试覆盖的内容无法预料,在需要保障测试的覆盖面时,就显得有些不足了。此外,手动测试也不适应于大规模、大数据量、长时间或者是多平台的测试,人工完成这样大的工作量是困难且没有必要的。 手动测试的这些特点就导致其适用于那些允许灵活甚至是要求灵活的小规模的测试任务,比如伙伴测试就是个很好的例子——测试内容不那么死板,期望测试执行人有一些创造性。   自动化测试     自动化测试充分利用了计算机“任劳任怨”执行人类给它的指示的特点,用程序实现需要的测试,此后该测试就可以被多次自动执行。在测试会被大量运行的前提下,这不仅能节省重复人工劳动,更重要的是提供了一种迅速而准确的保证测试覆盖的方法。特别是在敏捷开发紧张的节奏下,自动化测试的这些特质能起到十分显著的加快开发进程的作用。       那么什么样的测试需要自动化呢?       最显然的是诸如压力测试等需要大量操作的测试场景。比如我们常常要求产品能承受连续8个小时以上的各种操作,这样大强度的压力测试并不适合人由工完成,显然自动化测试能更好的完成该项任务。 接下来是那些核心的功能和主要的用户场景,这些是产品最需要保护的部分,所以我们希望能在代码改变的情况下及时地运行相关的测试,以保证它们不被破坏。在敏捷开发高速运转、频繁签入的状态下,自动化这些测试以便能将其在封闭签入(Gated check-in)等测试运行中迅速自动执行、及时发现问题,能在很大程度上保证产品开发流程的顺利进行。同时,将这些重要的测试自动化也能避免手动测试的“偷工减料”问题,计算机总是会忠实的执行每一个测试步骤的。       此外还有一些从其本身特性而言不适合手动执行的特殊类型的测试,比如模糊测试(Fuzzing Test)要求大量生成随机数据一一对产品试验,也是自动化测试能大展身手的地方。   自动化测试的度     在这里我想提醒大家的是测试的自动化的程度并不是越高越好。在我的开发团队中,我们曾经将测试计划中高达95%以上的测试都自动化。这样的带来的显著优势是自动的测试运行提供了很好的覆盖率,从而保证了各项功能都能保持正确工作。但是,也带来了一些问题:首先,编写自动化测试程序需要大量的时间,很多时候让程序自动操作执行产品功能特别是产品UI是件很困难的事情,需要大量的时间和精力来实现测试程序本身。其次,当产品功能变化时,修改测试还要花费额外的成本,不像手动测试那样随时都可以更改。另外,自动化测试还有一个容易被忽视却十分重要的问题——远离了用户体验。当测试被“傻瓜式”自动执行时,我们根本无法得知其相对应的用户场景的使用感。举个简单的例子,再不方便使用的功能如果只写一次程序我们多半是可以忍受的,但是如果要手动执行,恐怕三五次就会让人受不了了。所以把握手动测试和自动化测试的比例是颇值得研究的一个话题。       在意识到过量的自动化测试会使其从辅助开发的工具变为团队的负担和障碍之后,我们调整了自动化测试的策略,采取了一种渐进式添加自动化测试的方案。在产品生命周期的前期,功能快速的被添加且行为随时可能改变,此时对测试的需求偏向于尽可能迅速完成对新功能的测试,自动化测试所需的建立测试框架以及在功能改变时修改代码的代价在此时显得过于昂贵了,所以我们更倾向于做较多手动测试,只实现少量简单而核心的自动化测试。而随着产品功能的不断添加和趋于稳定,不再有大量的新功能需要测试,而更多的需要用于保护已有功能不被破坏的自动化测试,此时可以陆续添加测试计划中那些之前没有时间自动化的测试用例。在产品生命周期的末期,特别是产品将有多个版本时,准备全面的自动化测试覆盖以保护产品功能不被破坏则成为主要的测试任务之一。       林俊彦 软件测试开发工程师       本文精简版收录于《程序员》9月刊。

0

BizTalk Server 2010新功能介绍(七):AppFabric的集成

        BizTalk Server是微软构建业务流程和集成解决方案的首选服务器,BizTalk Server 2010是这个产品线的第7个主要版本,提供对Windows Server 2008 R2、SQL Server 2008 R2和Visual Studio 2010的全面支持和集成。         BizTalk Server 2010基于BizTalk Server 2009的核心架构,在应用到应用、业务到业务以及业务流程自动化等方面做了诸多重大改进,能让以前动辄以月和年为单位的设计和实现过程,现在只需要几周甚至几天就能完成。         BizTalk Server 2010增加了与AppFabric的集成,方便用户在以下场景中开发应用: 1. 开发需要和后端LoB(业务线)系统(比如SAP、Oracle DB、Oracle E-Business Suite、Seibel和SQL Server)互联的Windows Workflow应用,而无需专门针对其编写定制代码。 2. 开发基于XML数据转换的应用:因为BizTalk Mapper正好是针对此类任务的利器,而现在BizTalk Mapper可以直接在.Net/WF项目中启动并调用。         AppFabric的集成功能通过WF(Windows Workflow Foundation)活动(Activity)的形式使用户能在编程中引入BizTalk业务线连接和XML数据转换的能力。通过WF的模型,用户可以容易的创建新的复合应用,这些应用能在Windows Server AppFabric中部署、运行和管理。基于web的应用也能基于此访问后端业务线的数据。这些能力对于一些短时运行且不需要传统BizTalk Server提供的持久化能力的应用场景(比如基于web的查询)来说特别有用。一个典型的此类应用的架构如下:           在上图的应用场景中,一个运行在AppFabric/IIS的workflow服务连接到后端的业务线系统。         本文将介绍AppFabric集成功能的一些简单操作步骤。   一、后端业务线系统互联         BizTalk Server提供了一套基于WCF(Windows Communication Foundation)的适配器以和业务线系统互联。在使用这些适配器之前,您必须首先安装WCF LoB Adapter…

0