填鸭式的授课一定不是学员们最快能接受的方式，而兴趣才是学员学习的最好动力。在激发兴趣的这个环节里，并不需要讲师用过长的时间，只要让学员集中思想，抛出引子，千万不要是正文更不要是结论即可。

在这之后便是提供必要的信息供学员思考和分析，在这里一样只是给信息而非给出结论，接着启发学员思考，引导学员去总结、推进，并突出结论。因为引导学员思考和总结才便于他们对概念的记忆，并且在总结过程中学员也可以更好的发现理解的偏差和问题，从而加深记忆。

最后，也是最重要的一个环节，即是实践，这里的实践最好能联系实际的案例进行，方便学员应用以及加深理解。如果缺少必要的实践，很可能导致学员在实际使用时发生问题，在课堂上的练习会让学员进一步思考在实际环境中的应用。

想想看，在陌生的环境里你的第一感受会是什么？面对不熟悉的面孔你又会有怎样的反应？

封闭？好奇？猜测？试探？又或者急于离开？我猜想不同的人面对陌生的人、陌生的事物都会有不一样的反应，但有一点大家又都是或多或少的相似，那就是面对陌生，我们不会从一开始就完全融入，即便是在商场里试过合适的鞋子，刚开始穿也会磨脚，即便是现在在你身边的朋友，你们从陌生到熟悉也总是有那么一段“不打不相识”的故事。所以，当一群不熟悉的人坐在完全陌生的教室里，面对不曾相识的讲师，这之间一定会有隔膜存在。如果讲师们想要的就是学员们在课堂中的完全融入，那么课堂的开始，破冰环节一定不能少。

破冰顾名思义就是消除陌生和隔阂。很多时候，讲师们需要在课堂里调动学员的积极性，甚至讲师自己面对陌生的环境，也会紧张，当讲师开始紧张的时候，我们可以想象传播到学员，那会变成怎样一种课堂氛围。其实破冰不用花很长的时间，因为破冰只是为了让学员与讲师之间、学员与学员之间、学员与课堂环境之间、讲师与课堂环境之间消除距隔膜，并不是课堂内容的重点。

以下被测试人员遗漏的bug均有相同的两个操作前提：1.进行测试的firefox浏览器安装了支持xhtml语言显示的插件；2.进行测试的手机都可以正常浏览支持WAP2.0的网站。

bug1：使用firefox访问某wap页面，正常打开及显示，但使用手机无法打开该页面。
bug2：使用firefox访问某wap页面，查看该页面中的某个图片，正常显示，但是用手机无法显示。

两个bug现象不同，原因不同，但它们都有个共同点，那就是使用手机测试就会发现问题。
理论上，在我们无法确定到底访问这些wap页面的用户大部分在使用何种型号手机时，通常的做法就是按照wap标准开发，而安装了支持xhtml语言显示的firefox就应该能够供测试人员快速的进行wap测试（该插件定位问题，具体介绍见xhtml插件介绍）。

然而这仅仅是理论。由于每个手机型号的配置各不相同，并且受到手机网络、代理商的影响，同一个页面也会解析出不同的效果。并且这两个bug未能通过firefox测试出的另一个原因就是firefox本身也支持web协议。

？？？？

看到这样的标题，我想一定会有人心中充满了问号。无线测试组里开周会，因为大多是新人，于是当我在白板上写下TQA后，很多人也充满了疑问——什么是TQA？大家隐约的猜到是与QA有关、是与测试有关，其实答案确实很简单，TQA=Test Quality Assurance

就像我也是来到淘宝后才知道TQA这个概念一样，或许这个英文缩写会让我们咋一看有些迷惑，可实际上，我相信TQA的工组内容，大家已经在做，只是不够系统，或者是说我们还没有把他系统的归纳为测试的质量保证，再或者说对于TQA，我们我们都还在摸索。

通常情况下，测试都是软件质量保证的代名词，我们对PD、开发的产出都进行“测试”。可是测试人员的产出其实也一样需要“测试”，这就是TQA存在的意义。

在淘宝，项目都会指定一名TQA，他的工作就是对测试人员的工作内容按照checklist进行检查，将不符合项通知到测试负责人，限期修改。这种行为有些类似于SQA的工作，不同的是，SQA更侧重的是项目的整个过程，而TQA只是侧重测试过程中的内容。

已经记不得我们的3T交流会到底是在哪一天正式成立，只是依稀记得半年多前受到UED懒懒交流会的启发，子柳兄在测试交流群里也提议我们建立起一个“民间”的测试技术交流会，不用很严谨的形式，只是期望大家能在繁忙的工作之余一起坐下来交流交流自己的心得，还记得第一次会议的时候，我还在华星世纪闭关做项目，无奈项目紧张没能参加第一次交流会，看了他们后来发出的会议记录，更是眼红的一塌糊涂，也是从那次之后，3T交流会开始变得“一发不可收拾”。

再后来，3T交流会成为了名副其实的“分享会”，越来越多的同学通过3T分享他们的收获，跟大家交流测试的技能、技巧。甚至有的时候一周会有多场3T交流会，我猜这也是很多人没有料到的情况。因为这是“民间的”组织，所以分享的礼物都是整个测试组里同学们自发捐出来的，不论是一个小钥匙孔，还是一瓶香水，或者一个小玩偶，这里面有着太多太多的友爱。其实不论是组织者也好，分享者也好，听众也好，提供礼物的支持者也好，大家通过3T都在成长着，学习着，并为我们自己骄傲着。

先科普一下，标题的前两个字念taotie。^_^  这四个字合在一起通常用来形容指有很多吃的东西的宴席或者有很多给人带来享受东西的宴席。联想起我们整个测试团队近来轰轰烈烈的测试用例PK大赛，我想用这四个字形容再合适不过。

作品PK环节中每个团队的分享都让我们每个参赛的同学醍醐灌顶，原来我们经常编写的测试用例，其中的奥妙玄机和博大精深，即使有10支队伍也PK不够。亦如每个团队都有闪光之处，我们的OH MY 囧 小队也有自己的思考和亮点。类似PK大赛上单刀直入的解说在这里我不想再多说，今天我想说的只与饕餮盛宴有关。因为仔细想想，我们的测试设计过程本身就和饕餮宴席有着异曲同工之秒，具体内容且听我细细说来。

我们的需求和UC其实分别就是一场盛宴的菜单和为这分菜单准备的材料、烧法说明。是要满汉全席还是要家常小菜取决于我们的需求，而我们的大厨们也就是我们的开发为这道宴席准备的材料、烧法说明的是否齐全和好坏就决定了我们所看到的UC的质量。只有当这些UC充分满足需求，品鉴师（当然这里的品鉴师是广义的品鉴师包括对材料的鉴定等）也就是我们的测试人员们才能充分验证这场盛宴是否如满足这份菜单的原始需求。

这周大部分时间都在使用描述性语言编写脚本，之前关于描述性语言宝驹同学也曾写过一些介绍，大家可以参考一下。个人感觉使用该种方式编写脚本的一个最大好处就在于省去管理对象库的成本，但其实对象这个概念并没有放弃，只是通过我们脚本的描述来定义对象，这个时候，如何更准确的描述对象，让脚本运行时更好的定位到，是该种方式的核心之处。

以点击页面的搜索按钮为例，语句如下：
Browser("title:=.*").Page("url:=.*").WebButton("html id:=DoSearch").Click
由于当前只打开一个ie，故可以使用“.*”通配符来定义页面，若页面多于一个时，需要同时指定浏览器和页面。需要注意的是，某一对象的属性是多元的，当使用一个属性仍然无法唯一确定该对象时可以使用多个属性来定义某一个对象，写法如下：对象类型名("属性名1:=属性值2","属性名1属性值2")，即多个属性用“,”分割。

可能很多人都知道，利用QTP提供的data table中的Global sheet可以方便的通过指定不同的数据来做到一个脚本运行多次不同的数据。但有的时候我们又只需要通过数据多次运行脚本的某一部分，而非整个脚本的多次运行。这个时候我们不妨使用指定的sheet（非Globalsheet，若不需要多次运行整个脚本，切记不要在global中添加数据）在需要的脚本位置循环遍历该表中的数据。

例如某个脚本中有部分内容需要实现以下功能，在Action1数据表中，定义了名为test的列，该列中包含4个数据，依次是11，22，33，44，现需要循环打印出这4个值，则具体实现语句如下：

'计算“Action1”sheet中的行数，即需要循环的次数
rowsum=DataTable.GetSheet("Action1").GetRowCount

'从第1行开始循环打印出指定列（test）中的单元格内容
For i=1 to rowsum