2007年12月10日14:49:39
改变组件的宿主：Change parent first, then change owner(by RemoveComponent & InsertComponent)

2007年12月11日9:09:16
标准组件
listbox：item，itemindex，multiselect，使用循环判断选择项
listbox中无内容时，itemindex为-1，编程时注意加判断。
Edit的onEnter事件，状态栏的改变
Handled参数被预初始化为False，如果在时间处理程序中添加代码代替常规的弹出式菜单，应该将Handled设为True。如OnContextPopup事件。

2007年12月12日10:30:53
定制系统菜单：AppendMenu函数，WMSysCommand消息（注意inherited）
OwnerDraw：适用于按钮、列表框、组合框、菜单项
mainmenu的OwnerDraw属性若为True，菜单的快捷键就不使能了。

 

2007年12月7日10:32:24
定义类写在type下
类方法的实现也卸载implement下，快捷键ctrl+shift+c
使用T作为类及其他类型的前缀。T代表Type
每个对象建立之后都必须手动释放
private在声明类的单元外不能访问
public可以被程序代码中的任意部分访问
protected只能被当前类和它的子类访问
一般情况，类的元素应为专用，方法应为共用部分。
为每个类的元素提供访问的方法，保证元素的专用性。可扩展性：类的变更不会引起其他使用它的程序的变更
封装：如果想要相同类型的每个窗体都有自己的数据，解决方法是向窗体类中添加它。并提供访问该数据的方法。

Q：事件写在哪里？form的mousedown函数声明写到public运行报错，但写在上边不会报错

在代码中创建组件，需要用self将窗体作为参数传递给create事件，并将self赋给parent。
同时也可以使用with..do来实现
当需要当前对象时，引用一个类的特殊实例不是好的编程习惯。
为类添加定制的构造器，预防出错。

做了3年的测试，做了1年多的测试管理，我终于决定要转开发了。

我自己为自己设定的职业发展，我选择了通过深入体验和学习开发技能来进一步提高自己的水平。将来我想我的发展肯定还是会转回到测试管理上，但我相信等我再次回到测试岗位的时候，我一定能比现在做得更好。正所谓不入虎穴焉得虎子，沟通上的问题、技能上的问题、到底如何才能真正的实现bug预防，测试的质量要通过什么样的方式才能更有效的提高……？

带着这些问题，我要转开发了：）

祝福我所选择的路吧，God bless me!

今天在版上拜读了几个测试计划的模板，对比自己公司的测试计划模板，对比自己写过的若干测试计划，有以下感想：

一.《XX银行测试计划模板》

测试风险方面划分为了3个方面

1.人力、时间资源方面

资源方面，风险有人力风险，如人员变动可能导致测试水平下降，时间方面可能因为市场压力导致进度过紧，这个部分主要考虑测试内部的问题更多一些

2.测试环境方面

3.部门配合方面

部门配合方面的风险主要来自于需求部门和开发部门。需求部门的需求变更可能带来不可预估的风险。针对需求变更的风险考虑主要由公司的变更管理机制来做限制。而开发人员带来的风险则非同小可，可测试版本的提供是否及时、bug的修改是否及时，修改bug引发了新的问题，开发人员的人员流动，版本重大错误影响测试……

二.XX文档整理

在测试计划中加入明确的评价尺度

三.XX信息系统测试计划

1.在模板中将公司定义的测试阶段的所有测试使用一张表格来画出，在做测试计划时在需要进行的项目后打勾，这种形式感觉非常直观。对于管理多个项目的公司来说，可以很直接的看出测试计划的合理性及覆盖度。

  在详细编写测试项计划时再明确定义测试目标、测试范围、技术、开始标准、完成标准、测试重点。

2.人力资源部分的计划

  做计划时只是将测试过程所需要的角色列出，如需要测试执行工程师XX工日，需要用例设计工程师XX工日，自动化测试工程师XX工日，并能制定出不同角色介入的时间。如果做到这样，计划应该是做得比较好的。对于对测试部门有统一管理的公司，这样的计划可以让人员调度部门有更合理的安排。我们目前的计划是具体到人，这样的计划在后期可能会因为人员的调整发生计划变更，应该是不可取的。

3.bug严重级别的定义

  bug严重级别的定义在测试计划中。

 

今天跟公司的几位领导一起讨论了关于是否有必要在公司内进行测试人员的详细划分的问题。

公司目前的测试人员不划分详细工作职责，除了管理人员外的测试人员，有少部分专职负责自动化测试的，用例设计和执行测试则是每个测试工程师都要做的工作。在讨论中我跟头头提出现在的方式可能导致甚至已经导致了普通测试工程师可能出现迷茫的情况，大家对自己将要达到什么目标并不是很清楚。尽管公司也对测试工程师划分了1级、2级、3级、4级，但是各个级别之间工程师所做的事情都是一样的，充其量只是任务完成质量的差异，然而质量本身在衡量标准上又缺少精确性，存在的问题可见一斑了。

我们都知道测试工程师分为以下的种类：测试执行工程师、用例设计工程师、自动化测试工程师、测试工具开发工程师、测试管理人员等，由这些种类划分很明显就看出了测试人员的职业发展道路。我认为在公司中明确化这些工程师的称呼会对人员的发展有好处，这样有针对性的发展同时也可以提高每个环节测试人员的专业程度，提高工作效率。比如用例设计，如果用例设计人员也要负责用例执行的话，那么用例的质量就无法衡量，用例设计工程师本身的技能提高也会相应的缓慢。自动化测试工程师如果不能专注于自动化测试，那么公司的自动化程度提高相信还只能停留在一个长远目标，我们只能遥望。。。

经过讨论和思考，我们也一致认为划分这些不同的测试工种和领域非常有必要，然而真正要明确这些定义还有一些重要的前提条件。首先，明确划分后要保证每个领域都有一部分成员，有成功案例，这样才能让大家看到发展方向。其次，明确划分了职责定义后，要保证目前的测试工作的正常运转。比如有些项目组测试资源本来就严重匮乏，已经到了项目后期，没有足够的用例积累，进度压力却非常大，在这样的情况下强行划分可能会导致测试进度延迟。第三，群众基础也必不可少。这个变革对测试部门来说是一个不小的变动，应提前考虑到风险，考虑到众多测试人员的接受情况，拟定全面的利弊分析。

在这样的情况下，推进测试工程师合理划分的进程可能会稍微慢一些，我们第一步要做的是通过各个项目组的leader先从小范围内将测试工作范围进行适当调整，培养合适的组员逐步转型，在工作职责可以划分之后，再进一步推行。

antibiotic: anti+bio+tic  常pl.

anticipate: foresee，look forward to,expect

antique

apartment

apparent, apparently

appeal

appetite

applaud: cheer, acclaim

applicable: from apply

applicant

appointment

appreciate: recognize

apprentice:  The carpenter's apprentice built this beautiful bookcase.

approach: n. way; v. n. near

appropriate：a. suitable,becoming; vt. engross

appropriately；inappropriate

approve: pass,ratify,assent

approximate: vi. close to; adj. about 

aquatic: a. marine (Most aquatic animals breathe by means of gills.)

aquarium: n.

arbitrary: a.  an arbitrary decision

archaeology: n. archaeological, archaeologist

architect, architecture, architectural

arid: dry, barren

arithmetic: n.

arrange: plan, prepare

array: series

articulate: a.有关节的， vt.清楚的说

artifact---artificial: synthetic, false

artificially

artisan: workman,craftsman

artistic: aesthetical

ascending: climbing

ascribe(~ to): attribute

aspect: facet

assemble: gather, fit together assembly language

resemble

assert: affirm, declare

assign

associate: relate, consort； a.副的

associated

association

 

做了快3年的测试了，当测试经理也差不多一年了，昨天与2个公司同事一起参加了51testing在北京举办的测试管理人员的沙龙，听了回来感想还是蛮多的。

我了解过很多公司的测试管理、测试流程，也深深的明白自己所在的公司所存在的问题，然而这些问题想要改变并非是一朝一夕所能达成的，还得公司的领导重视和支持，否则我们这些项目组的测试经理们想法再多也都是白搭。

有时候想想也挺郁闷的，自己空有一腔抱负，空学了那么多的理论，然而在实际的工作中我能用到的只不过是极少极少的一部分。改变，是迫切的。改变的道路是艰难的。

我还要努力啊！

Different terms to describe what happens when software fails with the Chinese meanings from the PowerWorld following behind:

defect 过失, 缺点   

variance 不一致, 变化, 变异, 变迁, 分歧, 不和  

fault 过错, 缺点, 故障, 毛病

failure 失败, 失败者, 缺乏, 失灵, 故障, 破产, 疏忽

problem 问题, 难题

inconsistency 矛盾

error 错误, 过失, 误差

feature 面貌的一部分(眼,口,鼻等)特征, 容貌, 特色, 特写

incident 事件, 事变

bug 程序缺陷、臭虫  电脑系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷

anomaly不规则, 异常的人或物

etc.

Problem, error and bug are probably the most generic terms used.

Fault, failure and defect tend to imply a condition that's really severe, maybe even dangerous.

Anomally, incident and variance are often used to infer unintended operation rather than all-out failure.

 

开博了这么久，竟然只写了一篇文章，想想觉得有点对不起自己的博客。今天是春节后上班的第二天，第一天的时候太忙了，根本就没有时间写东西，回来的时候一门心思的扑在了新的任务上。目前自己所在的维护项目组维护任务一个接一个，没有什么新的东西，可每一样事情却都不能放松。自己是个很认真的人，刚当上测试经理的时候领导们就给我介绍经验，说当领导了要学会放权，可是我觉得自己这一点上做得并不好，习惯了亲历亲行，事事亲为，也许我对别人的能力有相当大程度的不信任，其实这是不对的。我想作为一个测试经理，必须培养得力的人，这一点上我真的应该好好改变一下。

2007年是我的本命年，这对我来说不知道是好还是坏，不管如何，2007对我来说都是充满挑战的一年。刚回到工作岗位上，发现身边很多同事都决定要离开公司。我的心态一直是很好的，我努力工作，但公司必须给我相当的报酬，如果二者悬殊不大，我会继续努力的做好自己的事情，甚至超出大家的期望，但是如果二者悬殊太大，我可能也会选择离开。

现在这个年代，对女人来说也一样有事业，对于我现在的职业，我不是把它当一个糊口的工具，而是把它当成我的事业，当成我的兴趣，希望公司能认可我的想法吧，还是希望自己能够继续留在公司发展，但是也许事情不是我所能左右……

网上有很多只能试听的音乐，一直知道能试听的音乐理论上讲都是可以下载的，可是一直以来都还不知道要怎么搞，昨天在经过嘲笑加鄙视之后，终于知道了一个简单的方法。

傲游中有一个ViewPage的扩展插件，使用这个插件可以看到网页中所有使用的资源，music、flash、图片、源码等都可以看到，想要下载音乐，只需要点击到“媒体”页，即可看到相应的链接，然后就可以方便下载了~~~~

想学习，想写下自己的工作和生活，于是开通blog了

恭喜恭喜~~