日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | 31 | ||||||
存档
搜索标题
最新来客
我的好友
最新留言
统计信息
- 访问量: 2335
- 日志数: 85
- 建立时间: 2007-06-16
- 更新时间: 2008-11-28
RSS订阅
我的最新日志
-
敏捷测试流程总结
2008-10-20
在敏捷方法中，XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试, 在敏捷团队中, 测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标, 共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。
根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：
1. 验证需求和设计
需求和设计具体来说一般包括：（1）由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）；（2）由开发人员根据功能文本而编写的实施设计文本（Implementation Design Specification）包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员，审核重点[b1] 是检查文本对用户需求定义的完整性、严密性和功能设计的可测性.
在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。
产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来
2. 测试计划，测试用例
2.1编写计划、测试用例
在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。
好处：
客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级。
问题：
在user story的时间估算上，开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。
分析：
由于版本更新很快， 任务的时间都是以小时来进行估算的。 开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。
举个例子：
开发人员估算某个user story 编码的时间需要1.5 天，开发人员自己估算了其他时间为半天。 于是开发人员给的估算时间是2天。
开发阶段实际的花费时间如下，每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。 在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时。（也许更多）。 需要处理一些公司突发性的事务等等。
所以非常建议大家在估算时间上能充分的考虑到以外的因素， 某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2－3倍。 听起来很吓人，但是实际的过程中，的确需要这么多的时间。
测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。
2.2 测试用例的审核
为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出TC的同时，应出一份TC_Matrix（Test Case跟踪矩阵），其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足（如某个重点Feature的Test Case不够）的地方能够及时给出意见。
另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。
在迭代后期 测试要抽时间更新test case
3. 实施运行测试
在敏捷方法中，测试有两种：单元测试和接收测试。 单元测试是由开发人员来完成的， 接收测试是由客户代表来完成。
由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下一个发布完成。
·单元测试
在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。Unit test
做单元测试[b2] 的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。
·验证测试
测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。
为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug趋于零的时间。
对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免
测试需要考虑:探索性测试用例的编写
在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时（敏捷项目中功能设计的更改频繁），所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。
3.3 根据项目不断补充Common Sense
在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的Common Sense标准。例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。
3.4 控制中间版本
为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。
3.5 发布版本前编写Release Note
在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容：Fixed，New Features， Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug；New Features部分写明此版本新增加了哪些功能；Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。
4. 需求管理
采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步。
问题：
客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能， 结果做完以后又觉得不好， 于是让去掉这个功能。 后来又由于一些原因，有需要加上。在整个过程中可能来回修改了很多次。 那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过了吗？这时这些记录才是解决客户疑虑的最好证明。说白了，是有证据证明我们做了很多的变更。 大家可能觉得，怎么会有这个问题。 其实当一个项目长达半年以上，也许大家的记忆力都不可靠了(:p)
建议：
目前采用的是vss工具，对每天的Email中提到的需求变更做一次backup，文档以当天收到Email的日期命名
5. 项目开发末期开展“bug大扫除”
在项目开发的末期，可以开展“bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。注意以下要点：（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。
除了以上流程中所提及的内容，这里还需要补充几点敏捷团队中需要关注和执行的要点：
n 早会
坚持每天早会，一般在10分钟左右。所有项目相关人员均到到场， 汇报前一天所做的工作，今天将做的工作， 以及工作中遇到的问题和需要寻求的帮助。
好处：
通过简短的会议能让项目成员了解项目的最新进展情况， 以及能
-
项目小结。针对不规范的测试。
2008-9-25
进继续教育组已经快半年了，有些疲了，慢慢的就习惯了为了工作而工作。
个人心得体会：
1.测试计划一定要订，不一定执行，虽然计划总是不适合，并且总是处于变化之中，还是需要计划，大的小的，都是要订一个的。
2.不要指望开发人员能帮你进行测试，有这个想法还不如让他们做单元测试。
3.不同的测试阶段测试的重点是不同的。在项目最开始，主要保证流程能走通。流程走通了以后再进行功能的完整测试，包括界面，一些不影响功能使用的，以及边界等方面。
4.测试的过程中尽量多和项目经理或者开发人员交流测试的情况，有什么问题，可以让他们出出主意想想办法。往往他们总会给你提出有建设性的意见。
5.和开发人员之间有什么矛盾，不要憋在心里，要直接交流，虽然有一些聊天或者联系的工具，还是以直接交流比较好，前提是不影响他工作的情况，以及在不频繁的情况下。（有时对一些开发人员的做法很是恼火，但是如果心里压抑着，做事就会很郁闷，所以强迫自己去和开发人员交流 。比如,有一个开发人员，把我提交的问题，全部都以不可再现的解决方式提交，我大为恼火，哪那么多不可再现的，具体情况，你具体备注一下，什么都没有标识就全部不可再现。再加上当时和他关系有点说不清楚（总感觉他对我有意见），所以那时我很郁闷，想了好久，还是决定直接和他说说，哪些是不可再现的，哪些是不属于他的功能，哪些是不需要修改的问题。和他说的时候，其他开发人员也都在，大家在一起笑笑，然后说说，事情就这么给解决了。我重新打开这些bug，他重新提交一下问题解决的方式。后来有什么不懂或者有异议的他都直接和我交流，这样大家做事又恢复了和谐。）
6.多进行交流。无论是和开发人员，还是和测试人员。流程这东西，交流的越多你就理解的越多。有时候交流了才知道，原来他们是这么实现的，于是你就知道自己该如何设计测试。交流的时候，一定要多听听别人的想法，不能想当然，但是也要把握自己的立场。
处理不好的问题：
1.有些开发人员，写出来的代码质量很差，导致修改的时候，一而再，再而三的出现问题，双方都很恼火的时候，该如何解决这样的情况，还不是很有办法。一方面，要考虑他的心情，改的次数太多，他要疯了。而我，因为每次流程走不下来，也快崩溃了。所以有的时候还是尽量以开玩笑的方式对待这些，既不让自己郁闷，也不让他觉得你是故意刁难他。结果就是，他的问题改了很多遍才勉强能使用。让项目经理或者小组组长去批评他？我感觉这样适得其反。现在的年轻人，脾气都大的很。万一不爽，走人。怕怕，得罪不起。
2.总感觉测试受开发人员的制约太严重。有的时候，明明感觉任务很紧很重，可就是力不从心。你加班的时候，开发人员不加班。流程走不下去，根本没办法。我想还是跟公司的测试以及开发的环境有关系。记得有一个贴子说是公司测试部要先进行一个预测试，通过了才提交到测试人员手里。而我们这边是测试人员直接使用开发工具把程序弄过来进行测试，根本不存在什么版本控制以及预测试的说法。这也不是我一个人能说了算的。哎。
-
[Summary]如何描述bug
2008-9-25
Always: 这类bug所要做到的就是如何把bug描述清楚
1． 察看当前和bug相关的条件并列出
2． 按照bug出现的步骤重复做3次以上以此来寻找最短的路径，尽量把不必要的过程过滤，当然不确定的步骤一定不能过滤
3． 描述的时候尽量做到每个步骤最多2个动作
4． 尽量用主动的英语句型，在遇到许多动作可以产生这个bug的时候，可以适当用被动句型，把最好重现bug的那个步骤写出来其他可放在括号中
5． Bug现象的说明一定要描述详细，不要放在步骤中
6． 发现bug之后的操作最好也做几个步骤(如果可以接着做的话)，这样更容易发现周围的bug，同时对开发人员解bug也是有帮助
7．尽量把bug的周围情况描述的详细些，不需要总是等到开发人员问了我们再去做Usually：这类bug和always一样重点就是把步骤描述全面详细且不冗杂
Sometimes：这类bug在遇到的时候可以先和开发人员描述一下然后共同推测路径，如果可以转化为always或usually，解决就容易些了,实在重现不出来可以把自己所做的若干步骤都描述出来
Once： 这类bug，开发人员解起来更难
作为测试人员，所能做的就是除了上述bug的描述之外需要更加注意的：
1． 尽量做到及时和开发人员沟通
2． 立刻检查当前状态并做记录
3． 把和当前bug相关的一切信息全部描述
4． 和当前bug可能相关的信息可以放在note中，一定要详细
此外，如果连续发生好几个bug，需要把每个bug的频率标注好，如果有外部网络或者设备等影响的尽量把这些外部环境也描述清楚，这样有助于开发人员解决问题。
我们的目的：“做到质量更好的同时效率更高，我们不但要发现问题还要帮助开发人员解决问题“
-
软件测试---职业规划
2008-7-24
每个工作三五年的人多少都会遇到瓶颈，要么是技术，要么是管理。没有一条路是可以既定的，都是摸索着前进，网上有专家的介绍，也有前辈们的总结。
对软件测试这样一个新兴行业，在以前是算在软件开发一类的，现在大多公司都会独立出测试部门了，也就有了专职软件测试人员。职业规划一个很重要的点还要看社会环境，在中国大陆做软件开发的都是被认为吃青春饭，很多企业的职位也或多或少都如此设定，大多技术牛人最后都走向项目管理，虽然也许他不喜欢也不擅长，但为了未来为了薪水待遇很多时侯是必然之路。
[软件测试质量保证]书上看来，也算世界通用的：
1～2年，测试技能：熟悉整个测试过程及产品业务领域，学习和掌握自动化测试工具，学习测试自动化编程技术；开发和执行测试脚本，承担系统测试实施任务；掌握编程语言、操作系统、网络与数据库方面的技能。
3～4年，测试过程：深入了解测试过程，掌握测试过程设计及改进，参与软件工作产品的同行评审；进一步了解产品业务领域，改进测试自动化编程技术；能指导初级测试工程师；加强编程语言、操作系统、网络与数据库方面的技能。
4～5年，测试组织工作：管理1～3名测试工程师，担任任务估算、管理及进度控制；进一步培养在软件项目管理及支持工具方面的技能。
5～6年，技术管理：管理4～8名测试工程师，提高任务估算、管理及进度控制能力，完成测试规划并制定测试计划；研究测试的技术手段，保持使用项目管理及支持工具的技能；用大量时间为其他测试工程师提供技术及过程方面的指导；开始与客户打交道并做演示推介。
6～12年，测试管理：管理8名以上测试工程师，负责一个或多个项目的测试工作；与客户打交道并做演示推介；保持使用项目管理及支持工具的技能。
//这个不适应于国内，也许适合老美他们。不过我们可以从中了解软件测试人员需要具备哪些能力。国内最重要的是第一步你入了哪一行业，业务是什么？软件测试也如此，web测试？手机测试？手工还是自动？…
废话一堆之后来摸索软件测试，主要还是寻找自己的未来道路，但要记住的是好职业不是规划出来的，顾问们都是参谋者，总结者也仅是经验，自己的人生规划是自己的选择和实践的过程，需要适时代、市场变化而变化的。可以分步做
Step1:分析自己的优劣势，包括自己的专业技能以及语言能力，业务能力，管理能力
Step2:发掘自己的兴趣，喜欢和人打交道还是喜欢和机器打交道，这只是个偏向问题，人的沟通表达能力是最起码的
Step3:分析市场需求，看看市场上需要什么样的人才以及未来需要什么人才
Step4:结合自己的优劣势给自己定位，设定目标，大公司还是小公司，国企还是外企....
Step5:为自己的目标努力，记住最重要是坚持!
-
与开发人员沟通的五要与四不要
2008-7-09
在我的测试经历中，也接触过相当多的开发工程师，这里我把和开发人员交流的经验归结为“五要四不要”：
1、要耐心和细心
细心是测试工程师的一个基本素质，测试工程师是对质量负责的人，涉及到质量问题，就不能含糊，因此一定要细心，细心对待每一个可能的BUG、细心对待每一段被你检查的代码，细心对待每一个你撰写的BUG报告，细心对待你发出的每一封邮件。细心是一种态度，你的态度迟早会感染和你合作的开发人员，而这往往是合作愉快的基础。
至于说到耐心，在我的工作经历中，不厌其烦地向开发人员解释一个BUG，让他认识到BUG的重要性是经常的事情，其实想想也很正常，对任何人来说，被人指出自己的缺点和不足都不是让人舒服的事情，因此，一点不耐烦的情绪就可能引起对方很大的反感，给自己的工作带来不必要的麻烦。
2、要懂得尊重对方
开发是一件需要全面和综合考虑的工作，开发工作中，由于各种原因导致程序中出现问题是很正常的现象，作为测试工程师，发现了这些问题并不值得你夸耀，也不能说明你比开发工程师聪明。一个好的测试工程师一定是懂得尊重开发工程师的人，尊重对方的技术水平，尊重对方的代码。我接触过的开发人员都是挺和善的，一般来说，对他们最大的尊重就是承认他的专业水平，承认他的代码。对他们来说，代码就像是自己的孩子一样：）因此，记得在合适的时候表达你对他的尊重，赞扬一下他代码的精妙之处。
3、要能设身处地为对方着想
开发工程师一般都处在较大的工作压力下，他的上司直接考核他们的指标很大程度上是已完成的代码，所以在工作任务紧张的时候，对于测试工程师报上来的BUG会拖延解决甚至是推脱，给测试工程师的感觉就是很不合作。那么在这个时候，就需要设身处地的为对方着想了，每个人都会为自己的工作在内心排定优先级，如果他认为解决你发现的BUG不是重要的事情，那么最大的可能就是你并没有向他解释清楚这个BUG的严重程度。
发现BUG是我们的责任，敦促BUG得到解决是我们更重要的责任，因此，我们可以心平气和地和开发人员坐下来讨论一下BUG的严重程度，和他一起排定BUG的优先级别并确定解决的时间。
4、要有原则
不要忘记，测试工程师需要对产品的质量负责，在这一点上一定要有原则。测试工程师可以和开发工程师建立良好的个人关系，但在具体的事情上，一定要按照公司的相关流程来处理。当然，在坚持原则的同时，可以采用一些委婉的表达方式，可以在允许的情况下尽量体谅开发工程师，但请记住，一个有原则的测试工程师才能真正帮助开发工程师，才能赢得开发工程师的尊重。
5、要主动承担
如果开发工程师要求你承担部分不属于你的责任，比如，定位 你发现的BUG到代码一级，或者是帮助他编写部分文档和代码（不要不相信，真的有这样的事情），那么你会怎么做呢？在我的测试经历中，这些事情都遇到过，我的原则是在可能的情况下尽量多承担。其实都是工作上的事情，有能力的话，多做一点也无妨。当然，肯定有人不同意我的意见，在这里我也不想争辩，个人意见而已，仅供参考：）
在我的测试经历中，我会根据自己的进度和时间安排尽可能地提供更多的关于BUG的参考意见，甚至是定位到代码一级，这种方式不是正规的方式，但对于提高自己被信任的程度是非常有益的。但在主动承担时，一定要明确是在自己确有余力的情况下才能去承担，否则，婉拒是最好的对策。
【四不要】
1、不要嘲笑
不要嘲笑你所发现的BUG，即使是非常愚蠢的错误也绝对不要嘲笑，说不定那个错误是因为开发工程师联系加班24小时犯下的，对别人的工作始终应该尊重。如果你觉得有必要提醒他不再犯一些经常犯的错误，可以采用这样的方式：编写一份测试过程中发现的开发人员常犯错误的文档（记住，千万不要写上谁犯了这些错误），用轻松的口气调侃一下，发送给开发人员。这种方法我采用过，开发人员都能很快接受。
2、不要在背后评论开发工程师
永远不要在背后评论开发工程师的技术能力，这个绝对是非常忌讳的事情，一时的口舌之快或许会使你永远不再能同他良好地合作，要知道，开发工程师最在意地就是别人对他的技术能力的评价。其实这个不仅仅是作为测试工程师的准则，也应该是做人的准则。
3、不要动辄用上层来压制对方
在出现和对方的意见分歧的时候，应该采用什么方式说服对方呢？直接向上层求助当然是一个办法，但这种办法带来的负面左右也是很明显的，首先是作为上层的处理结果可能不一定符合你的愿望（在很多公司，开发工程师的地位高于测试工程师的地位，这种地位的不平等导致上层在处理分歧时会有一定的偏向性）；其次是动辄拿出上层来压制对方只能给他人留下无用的印象。所以在出现分歧时，尽量尝试通过沟通 解决吧，实在不行，再动用最后的手段。
4、和开发人员的沟通不要只有BUG
除了在BUG记录单上，在其他的地方也让和你合作的开发工程师接触到你吧：），午餐或是集体活动的时候多和对方聊聊天，一方面可以增进彼此的感情，混个脸熟，打交道的时候也方便；另一方面，从他那里了解业务的知识和他负责模块的方方面面，对自己也是提升。我个人就很喜欢和开发工程师沟通，开发工程师其实一般都是比较健谈的，尤其是对自己程序的精妙之处，多了解一些，多接触一些，对自己总是有益的。
写了这么多，其实关键的就是两点：多从别人的角度去想想，所谓“换位思考”，多尊重对方就一定能得到对方的尊重与配合；其次是加强和开发工程师的沟通，让他清楚地认识到你的工作对他的价值，你发现的每一个BUG的重要性。
我一直认为，一个好的测试工程师一定是在公司里被所有人尊重的快乐分子，而不应该是一个“铁面判官”：）当然，作为我个人来说，绝对不敢说自己做的已经很好了，不过，我经常都记得提醒自己：尊重对方。 -
招聘经理眼中的好简历
2008-7-09
动词列表是简历编写指南里保留的项目，调查还发现：简历里尽可能的堆满动词、形容词和副词的求职成功率更高。
几乎所有的人事经理都喜欢选择有效的字句，而不是花样繁多的词藻的简历。
人事经理心里的单子
简历中的几个字也会惹恼人事经理，而拒绝继续读简历。有相当多的人事经理以及招聘人员都承认，他们心里有一个单子，上面列着让他们厌恶的字句。
尽管他们都说自己不太可能因为这些字句而完全拒绝应聘人员，但是他们相信，利用这些字句来吹嘘的简历给人留下印象还不如没有这些字句的。我在本期专栏里总结了一些例子。
例如，有一个IT公司的人事经理曾经说过，她从来都不喜欢在简历上看到协助（Assist或者Assisted）这样的字眼。“我想知道的是应聘人员（具体）做了什么，而不是他们如何帮助做了什么。如果他们对某项任务足够熟悉，而且想放到简历里，他们就应该使用比‘协助’更好的字，”她解释说。
一篇关于就业的评论建议将任何“协助”这样的表述改为十分具体的内容，说明应聘者在“协助”的时候做了什么。例如，如果你帮助市场部主任研究哪些个人数字助理（PDA）能够满足部门的需要，那么你就可以在简历中这么写：“为市场部研究PDA。”这样修改之后就说明了具体的内容。
出于和“协助”相同的理由，人事经理不会喜欢“试验（experimental）”这个字。没有人想听你尝试做过什么——只想听你完成了什么。你不应该写“试用了新的局域网（LAN）管理软件”，而应该说“评估了LAN管理软件。”
大多数人事经理不喜欢听到任何描述某人怎么好地完成了某项任务的字眼。他们说自己希望了解这个人相关的技能，而且希望自己才是这个人工作效果的评判者。因此，像巧妙地（Skillfully）、有效地（Effectively）、仔细地（Carefully）、迅速地（Quickly）、专业的（Expert）、高明的（Mastered），以及类似的字都会弄巧成拙。
在上面所提到的所有字中间，任何由技能（Skill）衍生出来的词——尤其是巧妙地（Skillfully）——只会引起更多的嘲笑而不是（会心的）的大笑。雇主和招聘人员更希望在应聘者简历里看到的是谦虚而不是吹嘘。
“如果你对它并不很在行，那么你为什么要把它放进简历里呢？”一位招聘人员如是说。
最佳的技能放在最前面的简历是好简历
明确地表示出在某些方面比别人更好，而且正在使用前面提到过的字眼来说明自己的最佳技能，会引得人事经理更多的注目。只把能够用来相当好地完成任务的技能，以及适合于职位要求的技能列出来。
一旦你删掉了所有自我评价的字眼，就要重新浏览一遍简历，去掉令人乏味的商业用语，例如：尖端的（cutting-edge）、联络人（liaison）、协调（coordinate）、推动（facilitate）、被证明了的能力（proven ability）、配合（synergy）和改造（transformed）等等。
人们看到和听到这些字眼太多了，以至于他们再次听到的时候没有一点兴趣。人事经理们说这些字只会占地方，而不会传达有用信息。而且，要知道的是：大多数技术单位的人事经理都会意识到，好的经理人都是注重细节的，所以你可以放心地从你的简历里删掉这些令人乏味的字。
灵光一现的简历
简历里加入更多激情，并且尽可能地具体说明你当前和过去的职责——尤其在这些职责是你现在想要申请的职位内容里一部分的时候。没有什么比看到“负责（responsible for）”这个字之后接有一堆寻常的管理任务更扫兴了。
你是个经理，所以你当然会负责什么东西。准确地告诉人事经理自己的职责是什么，并列出一些来，以帮助他们了解你的工作内容。诸如“管理着X个员工”、“监督Y的资产投资预算”，或者“为Z个雇员建议培训计划”等都是有效的方式，它们能够简明扼要地说明你做的以及取得的成果。尽你所能的具体和详细，但是要记住，你不能够泄漏你当前雇主的机密信息。
简历应该总是在说明事实，但是它也是一个市场推销的工具，你正在用它将你最珍贵的产品推向市场——求职者自己。 -
关于主从表的value的添加
2008-7-09
一直对主从表添加值都比较困惑,比较困难的E-R图也看的头疼,最近别的项目让我帮满写一些SQL的语句,才有所了解
1.要添加从表的数据,从表的外键又是主表的主键.那么要加从表的数据必须先添加主表的数据
2.在select的关于条件的where语句的限制,字段与一个集合数据是不可以相等的,以下语句是不对的:左边是一个字段,右边是多个数据的集合值,不可以用等号
select *
from SLATrigger
where SLAID=(select SLAID
from SLAMaster
where companyid=(select
Companyid
from
CasesList
where caseid=(SELECT CaseId FROM CaseExtension WHERE IntendingAcceptDate < getdate()
and ActualAcceptDate = '9999-12-31 23:59:59')
)
) -
varchar(n)与nvarchar(n)的区别
2008-7-09
varchar(n)
长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度，而不是 n 个字节。nvarchar(n)
包含 n 个字符的可变长度 Unicode 字符数据。n 的值必须介于 1 与 4,000 之间。字节的存储大小是所输入字符个数的两倍nvarchar 和 varchar 的区别是存储方式不同
varchar是按字节存储的.而带"n"的nvarchar是按字符存储的
比如说 varchar(40),能存储40个字节长度的字符,存储中文字符的时候,因为中文字符1个字符就等于2个字节.所以varchar(40)只能存储20个中文字符.
nvarchar(40),就可以存储40个中文字符,也就是说可以存储80个字节长度的字符.nvarchar要相对于存储的字符类型.比如有些字符是占3个字节的.
同样的,char和nchar也一样道理NCHAR、NVARCHAR、NTEXT。这三种从名字上看比前面三种多了个“N”。它表示存储的是Unicode数据类型的字符。我们知道字符中，英文字符只需要一个字节存储就足够了，但汉字众多，需要两个字节存储，英文与汉字同时存在时容易造成混乱，Unicode字符集就是为了解决字符集这种不兼容的问题而产生的，它所有的字符都用两个字节表示，即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之间。和char、varchar比较起来，nchar、nvarchar则最多存储4000个字符，不论是英文还是汉字；而char、varchar最多能存储8000个英文，4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字，较为方便，但在存储英文时数量上有些损失。
所以一般来说，如果含有中文字符，用nchar/nvarchar，如果纯英文和数字，用char/varchar。 -
国外优秀测试站点(转)
2008-7-09
国外优秀测试站点(转)
63个国外优秀测试站点链接
http://bdonline.sqe.com/ 一个关于网站测试方面的网页,对这方面感兴趣的人可以参考
http://citeseer.nj.nec.com/ 一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考网站
http://groups.yahoo.com/group/LoadRunner 性能测试工具LoadRunner的一个论坛
http://groups.yahoo.com/grorp/testing-paperannou-nce/messages 提供网站上当前发布的软件测试资料列表
http://satc.gsfc.nasa.gov/homepage.html 软件保证中心是美国国家航天局（NASA)投资设立的一个软件可靠性和安全性研究中心，研究包括了度量、工具、风险等各个方面
http://seg.iit.nrc.ca/English/index.html 加拿大的一个研究软件工程质量方面的组织，可以提供研究论文的下载
http://sepo.nosc.mil 内容来自美国SAN DIEGO的软件工程机构（Sofrware Engineering Process Office)主页，包括软件工程知识方面的资料
http://www.asq.org/ 是世界上最大的一个质量团体组织之一，有着比较丰富的论文资源，不过是收费的
http://www.automated-testing.com/ 一个自动化软件测试和自然语言处理研究页面，属于个人网页，上面有些资源可供下载
http://www.benchmarkresources.com/ 提供有关标杆方面的资料，也有一些其它软件测试方面的资料
http://www.betasoft.com/ 包含一些流行测试工具的介绍、下载和讨论，还提供测试方面的资料
http://www.brunel.ac.uk/~csstmmh2/vast/home.html VASTT研究组织，主要从事通过切片技术、测试技术和转换技术来验证和分析系统，对这方面技术感兴趣的人是可以在这里参考一些研究的项目及相关的一些主题信息
http://www.cc.gatech.edu/aristotle/ Aristole研究组织，研究软件系统分析、测试和维护等方面的技术，在测试方面的研究包括了回归测试、测试套最小化、面向对象软件测试等内容，该网站有丰富的论文资源可供下载
http://www.computer.org/ IEEE是世界上最悠久，也是在最大的计算机社会团体，它的电子图书馆拥有众多计算机方面的论文资料，是研究计算机方面的一个重要资源参考来源
http://www.cs.colostate.edu/testing/ 可靠性研究网站，有一些可靠性方面的论文资料
http://www.cs.york.ac.uk/testsig/ 约克大学的测试专业兴趣研究组网页，有比较丰富的资料下载，内容涵盖了测试的多个方面，包括测试自动化、测试数据生成、面向对象软件测试、验证确认过程等
http://www.csr.ncl.ac.uk/index.html 学校里面的一个软件可靠性研究中心，提供有关软件可靠性研究方面的一些信息和资料，对这方面感兴趣的人可以参考
http://www.dcs.shef.ac.uk/research/groups/vt/ 学校里的一个验证和测试研究机构，有一些相关项目和论文可供参考
http://www.esi.es/en/main/ ESI（欧洲软件组织），提供包括CMM评估方面的各种服务
http://www.europeindia.org/cd02/index.htm 一个可靠性研究网站，有可靠性方面的一些资料提供参考
http://www.fortest.org.uk/ 一个测试研究网站，研究包括了静态测试技术（如模型检查、理论证明）和动态测试（如测试自动化、特定缺陷的检查、测试有效性分析等）
http://www.grove.co.uk/ 一个有关软件测试和咨询机构的网站，有一些测试方面的课程和资料供下载
http://www.hq.nasa.gov/office/codeq/relpract/prcls-23.htm NASA可靠性设计实践资料
http://www.io.com/~wazmo/ Bret Pettichord的主页，他的一个热点测试页面连接非常有价值，从中可以获得相当大的测试资料，很有价值
http://www.iso.ch/iso/en/ISOOnline.frontpage 国际标准化组织，提供包括ISO标准系统方面的各类参考资料
http://www.isse.gmu.edu/faculty/ofut/classes/ 821-ootest/papers.html 提供面向对象和基于构架的测试方面著作下载，对这方面感兴趣的读者可以参考该网站，肯定有价值
http://www.ivv.nasa.gov/ NASA设立的独立验证和确认机构，该机构提出了软件开发的全面验证和确认，在此可以获得这方面的研究资料
http://www.kaner.com/ 著名的测试专家Cem Kanner的主页，里面有许多关于测试的专题文章，相信对大家都有用。Cem Kanner关于测试的最著名的书要算Testing Software,这本书已成为一个测试人员的标准参考书
http://www.library.cmu.edu/Re-search/Engineer- ingAndSciences/CS+ECE/index.html 卡耐基梅陇大学网上图书馆，在这里你可以获得有关计算机方面各类论文资料，内容极其庞大，是研究软件测试不可获取的资料来源之一
http://www.loadtester.com/ 一个性能测试方面的网站，提供有关性能测试、性能监控等方面的资源，包括论文、论坛以及一些相关链接
http://www.mareinig.ch/mt/index.html 关于软件工程和应用开发领域的各种免费的实践知识、时事信息和资料文件下载，包括了测试方面的内容
http://www.mtsu.ceu/-storm/ 软件测试在线资源，包括提供目前有哪些人在研究测试，测试工具列表连接，测试会议，测试新闻和讨论，软件测试文学（包括各种测试杂志，测试报告），各种测试研究组织等内容
http://www.psqtcomference.com/ 实用软件质量技术和实用软件测试技术国际学术会议宣传网站，每年都会举行两次
http://www.qacity.com/front.htm 测试工程师资源网站，包含各种测试技术及相关资料下载
http://www.qaforums.com/ 关于软件质量保证方面的一个论坛，需要注册
http://www.qaiusa.com/ QAI是一个提供质量保证方面咨询的国际著名机构，提供各种质量和测试方面证书认证
http://www.qualitytree.com/ 一个测试咨询提供商，有一些测试可供下载，有几篇关于缺陷管理方面的文章值得参考
http://www.rational.com/ IBM Rational的官方网站，可以在这里寻找测试方面的工具信息。IBM Rational提供测试方面一系列的工具，比较全面
http://rexblackconsulting.com/Pages/publicat-ions.htm
Rex Black的个人主页，有一些测试和测试管理方面的资料可供下载
http://www.riceconsulting.com/ 一个测试咨询提供商，有一些测试资料可供下载，但不多
http://www.satisfice.com/ 包含James Bach关于软件测试和过程方面的很多论文，尤其在启发式测试策略方面值得参考
http://www.satisfice.com/seminars.shtml 一个黑盒软件测试方面的研讨会，主要由测试专家Cem Kanar和James Bach组织，有一些值得下载的资料
http://www.sdmagazine.com/ 软件开发杂志，经常会有一些关于测试方面好的论文资料，同时还包括了项目和过程改进方面的课题，并且定期会有一些关于质量和测试方面的问题讨论
http://www.sei.cmu.edu/ 著名的软件工程组织，承担美国国防部众多软件工程研究项目，在这里你可以获俄各类关于工程质量和测试方面的资料。该网站提供强有力的搜索功能，可以快速检索到你想要的论文资料，并且可以免费下载
http://www.soft.com/Institute/HotList/ 提供了网上软件质量热点连接，包括：专业团体组织连接、教育机构连接、商业咨询公司连接、质量相关技术会议连接、各类测试技术专题连接等
http://www.soft.com/News/QTN-Online/ 质量技术时事，提供有关测试质量方面的一些时事介绍信息，对于关心测试和质量发展的人士来说是很有价值的
http://www.softwaredioxide.com/ 包括软件工程（CMM,CMMI,项目管理）软件测试等方面的资源
http://www.softwareqatest.com/ 软件质量/测试资源中心。该中心提供了常见的有关测试方面的FAQ资料，各质量/测试网站介绍，各质量/测试工具介绍，各质量/策划书籍介绍以及与测试相关的工作网站介绍
http://www.softwaretestinginstitute.com 一个软件测试机构，提供软件质量/测试方面的调查分析，测试计划模板，测试WWW的技术，如何获得测试证书的指导，测试方面书籍介绍，并且提供了一个测试论坛
http://www.sqatester.com/index.htm 一个包含各种测试和质量保证方面的技术网站，提供咨询和培训服务，并有一些测试人员社团组织，特色内容是缺陷处理方面的技术
http://www.sqe.com/ 一个软件质量工程服务性网站，组织软件测试自动化、STAR-EASE、STARWEST等方面的测试学术会议，并提供一些相关信息资料和课程服务
http://www.stickyminds.com/ 提供关于软件测试和质量保证方面的当前发展信息资料，论文等资源
http://www.stqemagazine.com/ 软件策划和质量工程杂志，经常有一些好的论文供下载，不过数量较少，更多地需要通过订购获得，内容还是很有价值的
http://www.tantara.ab.ca/ 软件质量方面的一个咨询网站，有过程改进方面的一些资料提供
http://www.tcse.org/ IEEE的一个软件工程技术委员会，提供技术论文下载，并有一个功能强大的分类下载搜索功能，可以搜索到测试类型、测试管理、 测试分析等各方面资料
http://www.testing.com/ 测试技术专家Brain Marick的主页，包含了Marick 研究的一些资料和论文，该网页提供了测试模式方面的资料，值得研究。总之，如果对测试实践感兴趣，该网站一定不能错过
http://www.testingcenter.com/ 有一些测试方面的课程体系，有一些价值
http://www.testingconferences.com/asiastar/home 著名的AsiaStar测试国际学术会议官方网站，感兴趣的人一定不能错过
http://www.testingstuff.com/ Kerry Zallar的个人主页，提供一些有关培训、工具、会议、论文方面的参考信息
http://www-sqi.cit.gu.edu.au/ 软件质量机构，有一些技术资料可以供下载 -
CTTS工作总结
2008-6-11
上周一加班到晚上快12点了，版本依然没有发出去，还是等到周二了才发的，上周五加班到凌晨2点，一个星期连着两天加那么晚的班，人好累好累，PM急着交版本，当时我也没有那么多的时间把测试走的非常仔细，后来课想而知，客户给我们的反馈是多么的不好，尤其是对QA的质问，提出的六个问题，只有一到两个是测试的问题，一个问题是需求不明确导致的，这个项目开始到结束就没有一个很规范的需求文档，后来的需求也是PM与客户口头交流，测试总结整理的，也许都没有经过可是的确认，另外三个问题是不存在的问题，是经过测试好了的
只是觉得太不应该了，加班加那么晚，真的是吃亏不讨好，不过就当作是一个经验，第一我们的需求必须是明确的，是有email 文档可以追踪的，而不是口头交流的文档，更不可能是测试来整理需求，就算是也必须是客户得到确认后的，第二发版本的时候一定要交Release Note，把测试中发现的问题说清楚，第三女孩子一定要少加班，最多到10：30就走，加班太多太晚容易变老的，以后就算加班我也只是最晚到10:30就走，在也不加那么晚了，老板不会心疼你，也不会给你加工资，在晚发出去的版本问题会更多，疲劳战的效果总不那么理想的，身体是自己的，要好好爱护自己的身体。