-
锻造软件需求人员的六大要素<转>
2007-07-04 14:17:30
软件公司对从事需求调研人员的基本素质是不太注意的，企业的信息化主管经常可以看到软件公司派住的调研人员的年龄是偏低的、经验是不够的。在我与企业中、高层管理者的交流中，他们普遍都有这样的感觉：“对于企业来讲，我们不太清楚信息化调研应当怎样开始，又怎样结束，我们实际上更关心的事情是把我们现有的管理方式向软件公司转达，并且不要寄希望这种转达是全面的，当面对转达不全面的时候，就需要软件公司的人员多问、多探讨，我们上管理系统的过程中也接触了不少软件公司的设计人员、需求人员，但是在与我们的交流过程中，感觉他们总是缺乏调研思路和必要的管理知识，许多是非常常用的管理知识他们也不太清楚，这样在调研中只能够在一些局部的问题上进行讨论，这些局部还是靠我们自己的中层管理者对于管理中所存在的问题而提出来的，而这种主动提出问题的现象，是当碰到了喜欢交流的经理们和业务骨干们的时候才能够有的情况”。
“大部分的调研情况是不好的，你知道，我们的许多业务骨干和经理们他们对于计算机是陌生的，对于信息化更是陌生，你让他们谈需求，首先是要与他们交流，在交流中获得需求。这就需要、讨论需求的软件公司人员必须有一定的管理知识和一定的管理经验，要用启发方式进行调研，否则我们的许多人不知道说什么，也不知道你们想获得什么，你们的软件究竟与我们所要求的内容之间有多大的差距，这些在调研中好像都没有看到，那么这种情况对于调研的结论就产生很大影响，在许多公司给我们提供的调研报告中都可以反映出来，简单一句话是不了解我们的企业”。某企业副总经理说。
他的观点代表了许多中高层管理者的意见，由于一些软件公司对需求调研工作的不重视，在人力资源的选配方面，总是倾向于给开发人员好的福利，而需求人员却无法获得较为合理的待遇，在这种普遍偏低的待遇下，只能吸收经验较少的人员、甚至经验没有的人员，即便这些人可能学的专业是管理或电脑类专业，但是软件公司往往忽略这样一个事实，这类人员必须招募综合性的人员，电脑要懂、软件功能作用要清楚、管理知识要会运用、沟通要有一定的技巧，组织管理能力也要具备，最好懂得如何作管理类咨询。对于这样一个人员的培养，显然要比培养一个优秀的开发人员要困难的多，目前的这种待遇下是无法吸收到满足要求的人员。而我们回过头去看看西方公司，需求人员的工资却普遍比开发人员的工资要高出很多，对于这种现状，是不是给了我们一些提示，软件的成功从“需求开始”，所以需求人员是软件的成功之本。
如果你是从事信息化工作的人员，并且你希望自己成为一名优秀的需求工作者，那么首先要检查自己是否具备与人实现良好沟通的能力，这种能力不是怯懦，不是没有争吵，而是善于根据自己的调研需求的需要、去诱导和启发企业的管理者和业务骨干，描绘他们自己所要的管理要求。同时你还是需求的传递者，你必须与需求定义的人员实现良好沟通，你也必须与软件的测试人员实现良好沟通，因为在你的下游所做的一切工作都是依赖于你的需求报告而产生。所以你必须有很好的表达能力、也必须有很好的管理知识和经验，因为这两点是成功沟通的基础，没有很好的表达你无法和软件公司的人员“默契”交流、也无法和企业的人员“默契”交流，这里使用了“默契”，是为了强调交流的成功度；而没有管理知识与经验，企业的管理者和业务骨干对于你的信服都将大大折扣。
-
学习QTP的方法
2007-06-13 16:23:00
我们使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等。建议大家参照 Tutorial_oldsidney_cn.pdf 文件来认认真真、从头到尾地执行一遍，包括录制脚本、分析脚本、增加check point、Split Action等。我想这会减少你在学习QTP过程中的不少困惑和疑虑。
这篇文档对如何使用QTP写的非常详细，是QTP初学者的经典教材。我就是看了这篇文档后才对QTP的整个测试流程有了一个初步的认识。在此，表示感谢。注意：
1. 确保你的IE运行正常，依次点击菜单 查看 --> 工具栏，一定要上网助手等插件卸载掉，特别3721这个垃圾网站和其它拦截广告的插件（它也把测试过程中弹出的窗口当成广告，一样会拦截的！）
2. 如果是按照Tutorial_oldsidney_cn.pdf 文件 中的订购飞机票的例子来练习 QTP的使用，那么只需选择Web 插件就可以了。如果是测试其它的应用程序或系统，就要根据需要来选择相应的插件了。
在这个阶段你就要自己针对某个系统去录制脚本、维护脚本了。在录制后的回放过程中，你可能会遇到各种问题，这个时候就需要发挥你的主观能动性来解决遇到的问题。我想你可以按照下面的方法去解决：
1. 查看QTP的有关文档，包括Help 、QTP User’s Guide等文档。这些都是比较系统全面的学习材料。你该好好利用呀。
2. 在本论坛上查看以前别人是如何解决此类问题的（如果有的话）或者是发新贴寻求帮助，也可以搜索Google 等网站寻找问题的解决方法；
3. 与自己部门的同事交流，例如与测试人员交流他们是如何解决的，与开发人员交流某个QTP无法识别的控件具体是是用什么来识别的等。毕竟他们对你测试的环境和测试的软件比论坛上的人熟悉呀。
4. 自己通过学习VB scrīpt 等方式来提高自己的管理QTP scrīpt的能力。或许你会发现许多问题都是由提出问题的人来解决的，因为他们希望问题得到解决的迫切心比谁都强烈。
如果你对VB scrīpt 、QTP和需要测试的程序或系统非常熟悉，你可能就想直接写QTP scrīpt来表现一下了。如果你能达到这个水平，那么恭喜你－－－你就是真正的高手了。这个时候你已经可以从宏观上把握QTP了，也能灵活自如地使用QTP了。 -
管好上司七策略（出处：世界经理人）
2007-05-22 12:33:20
有效的经理人不仅将自己的时间和精力花在管理与下属之间的关系上，而且花费在与上司的关系上。与上司的关系有时直接决定自己的任务是否能够达成，可否在公司内获得更大的发展空间，所以也越来越受到经理人的重视。如何来管理自己的上司？从哪里入手？
了解上司的风格
要想管理好你的上司，你需要很好地理解上司以及他所处的环境。比如，你的上司的目标和压力是什么？他喜欢通过会议、电话或者哪些方式来获取信息？他在决策时，是喜欢征求更广泛的意见，还是喜欢自己根据掌握的资料来决断？如果不能对这些内容有清晰的掌握，则经理人在与上司的沟通中往往出现问题。
能够正确地认识和适应上司的工作风格非常重要，它决定你未来的职业发展。现任惠普大中国区总裁的孙振耀于1982年加入台湾惠普，23年来，他总共换了10个职位，有过18位上司。他分享自己的经验时说："有些领导目的性很强，他很清楚地告诉你他要什么，你只要做得到就可以；有些领导过程性很强，他非常关心你用什么方法来完成，而且有时候会坚持按照他的方法来完成；有些领导关系型很强，就是特别强调彼此的关系，下班以后找你吃吃饭，关心你的家庭。"
七种策略有效管理上司
孙振耀还说："如果你碰到一个目的性很强的领导，就一心把事情做好，拿出很好的成果来给他看。如果碰到一个强调过程性的领导，你可能很多时候都得按照他的方法做。但不管怎么样，在职场中，每个人都要具备适应不同老板的能力。"
具体来说，管理上司有哪些好策略呢？www.Careerjournal.com发表文章，对这些策略进行了概括，强调管理上司是适应上司改变自身的过程。这些策略包括：
1、不要妄想老板会有所改变；
2、将上司的目标纳入到你表述的观点中；
3、小心上司的忌讳；
4、经常寻求上司对自己工作的反馈；
5、在客户关系中运用向上管理。如果你服务的客户对你有很好的口碑，他在你上司面前的沟通就可以帮助你建立专业、良好的形象；
6、提高你在公司的曝光度；
7、成功的经理人对上司和下属同样需要进行有效管理，以自己的知识、才能赢得尊敬。 -
常用测试术语
2007-05-22 12:31:00
一.从测试设计的方法来看，我们知道有两类方法：Black box (黑箱)White box (白箱)二.功能测试在下表所列的测试中，测试的范围有小到大，测试者也由内到外，从程序开发人员（单元测试）到 测试人员，到一般用户（Alpha/Beta 测试）。测试名称测试内容Unit Test单元测试 – 在最低的功能/参数上验证程序的正确性Functional Test功能测试 – 验证模块的功能Integration Test集成测试 – 验证几个互相有依赖关系的模块的功能Scenario Test场景测试 – 验证几个模块是否能够完成一个用户场景System Test系统测试 – 对于整个系统功能的测试Alpha/Beta Test外部软件测试人员（Alpha/Beta 测试员）在实际用户环境中对软件进行全面的测试。三.非功能测试测试名称测试内容Stress/load test测试软件在负载情况下能否正常工作Performance test测试软件的效能Accessibility test测试软件辅助功能测试 – 测试软件是否向残疾用户提供足够的辅助功能Localization/Globalization Test本地化/全球化测试Compatibility Test兼容性测试Configuration Test配置测试 – 测试软件在各种配置下能否正常工作Usability Test可用性测试 – 测试软件是否好用Security Test软件安全性测试四.Ad hoc Test, Exploratory Test “探索式”的测试
“ad hoc”测试的测试流程是不可重复的，因为它的测试都是“特定”测试，没法重复。由于这一原因，“ad hoc”测试不能自动化，就这一点而言，还达不到CMM的第二级 – 可重复级。
五.Regression Test回归测试
Regress的英语定义是：return to a worse or less developed state. 是倒退，退化，退步的意思。
在软件工程中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”- regression, 从正常工作的稳定状态退化到不正常工作的不稳定状态。
在一个模块的功能逐步完成的同时，和此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到此模块的功能基准（baseline）.在某某版本，某某模块的某某测试用例是通过的！如果测试人员发现了在新的构建版本某个测试用例失败了，这就是一个“倒退”，在新版本上运行所有已通过的测试用例以验证没有“退化”情况发生，这个过程就是一个“regression test”. 如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因），那么测试用例的基准就要修改，以和新的功能保持一致。针对一个bug fixed，我们也要作Regression Test，a) 验证新的代码的确把缺陷改正了，b) 同时要验证新的代码没有把模块的现有功能破坏，没有regression。所以我不也知道“回归测试”是如何的“回归”，我们可以理解为“回归到以前不正常的状态”。回归测试最好要自动化，因为对于每一个构建都要运行所有回归测试，以保证尽早发现问题。就是“退化测试吗”?六.Scenario/integration/System Test 场景/集成/系统测试
在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，在各方面都能满足用户的要求。
七.Performance Test 效能测试
用户使用软件，不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平，软件的效能，是这些“非功能需求”，或者说“服务质量需求”的一部分。八.Stress Test压力测试压力测试严格地说不属于效能测试。压力测试要验证的问题是：软件在超过设计负载的情况在仍能够返回正常结果，而没有产生严重的副作用或崩溃。九.Alpha Test, Beta Test在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会在开发过程中让特定的用户（alpha/beta用户）使用正处于开发过程中的版本，用户会用特定的反馈渠道（email, BBS）与开发者讨论使用中发现的问题。 -
常用功能测试方法
2007-05-22 12:30:03
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。
4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错
-
[转贴]新手忠告
2007-05-22 12:28:49
1、你是一个检查者，你不需要为质量负责
很多测试人员误入歧途，不明白他们是评测产品的而不是控制产品的。这两者之间有着天壤之别。例如，一个测试团队花费好几周时间测试并发现很多缺陷，只是为了看着管理层决定发布一个有已知严重缺陷的产品。测试团队经常会感到士气受挫，置疑他们测试的目的。
我询问团队中的成员他们是否被支付薪水了，通常得到的回答都是“是”。我又询问他们是否尽力去做工作了，再一次，通常得到的回答都是“是”。我于是告诉他们，“你们做了你们的工作。你们尽力测试，发现了缺陷并进行了上报。那么现在可以回家休息了。实际上，作为一名测试人员唯一失败的地方是不上报一个已知的缺陷。”
这不会提高士气，但却有助于事情向正确的方向发展，特别是能让人不用每天晚上都在家接着办公。
很多测试人员，包括我，当我们刚开始测试工作时，似乎会觉得自己对我们所测试的系统应用的质量负责。尽管这个工作的出发点是让人钦佩的，可实际上我们测试人员对于产品的质量基本没有控制能力。也是由于这个原因，测试人员不为质量负责。现在问题是管理层并不总是能看到这种区别。所以经常看见管理层提出类似于 “我们付钱给这些人不是为了获得高质量的软件吗？”的问题。
2、缺陷都是有价值的
每一个缺陷都是深入了解和提高的机会。我们可能只有一次机会观察到一个缺陷，所以我总是告诉测试人员始终保持高度注意力，不要为测试的乏味所折磨。
缺陷信息可能是可获取的项目数据中最有效的资源之一。但是这都取决于我们能多好的捕捉和传达我们所发现的缺陷的相关信息。
每个缺陷都会花费整个组织的金钱。如果我们不能从中更进一步了解产品，我们会浪费大量时间和金钱。当我们把一个错误转换成一次深入了解的机会时杠杆作用就出现了。让我们面对它――有些教训只能通过经历来学习的。
由于一个缺陷而责备谁不会有任何好的作用。责备只会让士气低落、沟通中断。这就像不断鞭打一匹死马希望它能活过来一样。
3、你报告第一个问题之前一切都是美好的
这就是一个测试人员所面对的现实。你可以计划测试，获取所需要的资源，看起来所有人都站在你这边。可当你报告第一个问题之后，事情就开始变得紧张了。
出现这种态度上的突然变化的原因是现在你在批评某些人的工作了。自尊心使得自我收到伤害，关系变得紧张。有些情况下自尊心是值得期盼的，只要知道当你开始发现问题的时候态度有可能变化就可以了。
我经常建议测试人员做的一件事是读一读一些你过去写的缺陷报告，假设自己是接收缺陷报告的人。你会发现自己需要更老练一些。写一个没有任何挖苦语句的缺陷报告可能没什么乐趣，但它的确有助于和开发人员之间保持一个好的关系。
4、 只能测试你能观察的
你可能总想测试一些真正有创造性的用例，但如果你没有办法观察到结果，那有什么意义？尽管有些应用让你能观察到很多，但仍然有你没办法接近的，例如结构、隐藏的对象、后台进程等。
5、 别忘记你是怎样到一个地方的
我不是在谈论知道为什么你走进一个房间，而是在测试时执行的步骤。对于测试新手常见的是发现了一个重大的缺陷，但却无法复现它以便定位解决。这样你只会觉得不舒服，不知道自己到底是真发现了一个缺陷，还是说仅仅是错误的使用了应用。
你能用来跟踪你的测试步骤的方法有测试脚本、测试记录、敲键记录器如Spector和屏幕视频捕捉工具如Hypercam。
6、 标准和流程是你的朋友
尽管标准和流程让一些人觉得受限，但它们为你的工作提供了有价值的指导。不要拒绝标准因为它们是详细的、具体的。因此用它们指导自己更快、更一致的完成自己的工作。
7、 没有足够的时间用于测试
几乎每一个测试人员都抱怨没有足够的时间用于测试，但实际情况是测试任何东西到完整的程度都是不可能有充足时间的。当你充分考虑软件的特性如可用性、安全性、兼容性、互操作性等时这一点尤其正确。
不要再抱怨缺少时间，学会根据风险来进行优先级排序，把注意力都放在对管理层很重要的应用目标上。有时候我们测试的内容超出了我们需要测试的，因为我们的目标偏离了产品的价值。
8、 你不可能发现所有的缺陷
如果你测试的东西后来有缺陷被发现，不要变得气馁。你可能已经做了非常全面的工作，获得了高水平的缺陷移除，但100%都是不可能的目标。
9、 保持幽默感和对前景充满信心
经常微笑、保持健康可能是你最好的生存方式。如果你正处在困难条件下，请相信，这一切都将过去。
10、 争取做到最好而不是完美
测试新手经常会陷入追求完美的过程中，认为100%的正确才是标准。我曾经也是受害者之一，但要为自己辩护的是，我以前深受80年代后期类似于“99.9%还不够好”的TQM帖子和文章的影响。
追求完美的问题在于它会让测试进程变慢，将担心引入你所做的一切，使得你对别人更挑剔，而且通常会让你的朋友和家人感到失望。
当然，没人愿意犯错误，但他们稍不注意就出现了。想不犯错误就是否认现实。争取做到最好是一种好的习惯，表明你对工作的态度和投入程度。如果你想努力做到最好，你就会往前再多走一点。
根据我的观察，大多数人看到错误或者经历失误时都是很宽容的。人们最关心的是你对待问题的反应。
11、 开发人员不是敌人
需要整个项目团队的努力才能递交高质量的产品。有时候似乎开发人员不太关心质量，这个时候事情背后可能存在隐情。这时候你需要更好的和开发人员合作而不是反对他们。要始终牢记良好的交流是一个项目成功的关键因素。当你和开发人员站到对立面时，交流就停止了，你测试所需的很多信息也无法获取了。
12、 建立和维护一个私人的交际网
你的私人和工作关系是一个很重要的资产。无论时当你有工作时还是当你没工作时他们都是一个很好的支持系统。找一个好的指导者，而当你学到足够的东西时成为别人的指导者。
13、 持续锻炼自己的技能
你的技能把你和别人区分开。始终通过参加专业会议、获取认证、阅读专业资料等来不断学习。我给自己制定的目标是每周至少读一本和个人发展以及职业发展相关的书（测试、领导艺术、商业、IT等）。
一个个人发展方面的专家说过如果你每天在任何特定的主题上花费30分钟进行阅读，五年之内你肯定能成为这个主题方面的专家。这一点对我是起作用的――你也可以试试。
另一种让自己始终内行并建立网络的好的方式是活跃在一些QA或者测试论坛上。
14、 当前进变得困难，懒惰就需要创造力了
当我第一次成为一个测试团队负责人时，我用这句话做了一个字条挂在我的桌上。它不断提醒我把创造力作为我解决问题的一个杠杆。
学着从一个新的有创造性的方式来看待问题。你可能有一个好的测试计划，但你如何应付各种变化呢？弹性是一个优秀的问题解决负责人的关键特性。
15、 简单并不总是很容易
我们测试中做的很多工作看起来都很简单。但是，挑战在于保持努力的连贯性。
有些解决问题的方式刚开始看起来很简单，但不要由于它简单和明显就丢弃任何一种想法。同样，不要低估实现一个简单想法所需要付出的努力。
一些看过我和William E.Perry合著的书“Surviving the Top Ten Challenges of Software Testing”评论说这些挑战都很简单且很容易解决。这就让我奇怪为什么人们还在年复一年的提出“人的问题”。我认为在大脑中产生想法比实际实现出来要简单的多。
结论
智慧比知识更重要。你可能已经学习了大量测试技术，但如果你没有足够的智慧判断什么时候采用它们，没有从整体上理解它们，你应用它们的能力将受到很大限制。对任何都有涉猎的你存在的一个问题是“你不知道什么你不知道”。智慧帮助你明白你需要知道哪些东西才能成功。
-
[转贴]测试经验
2007-05-22 12:27:22
一、 测试的目的和原则
1、测试概念的范畴
广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。如：设计评审、系统测试。
狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同
时对产品质量进行客观的评价。
2、测试的目的
简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把
尽可能多的问题在产品交给用户之前发现并改正。
具体地讲，测试一般要达到下列目标：
1、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说
明------在某种意义上与ISO9001是同一种思想。
产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期
利益看，这是很不划算的。我有个感觉，接触过的软件产品，很少有向方正这样大大的产品、薄薄的文档。
当然，书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难，也是最容易被忽略的。
最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。
2、确保产品满足性能和效率的要求
使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一
个有竞争力的产品。
用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好
处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。
3、确保产品是健壮的和适应用户环境的
健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。
另外就是不能假设用户的环境(某些项目可能除外)，如：报业用户许多配置是比较低的，而且是和某
些第三方产品同时使用的。
3、测试的原则---Good Enough
对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。
Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种
资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，
什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题
具体分析。最明显的例子就是FIT3.0中文报版的产品测试。
4、测试的规律----木桶原理和80-20原则
1、木桶原理。
在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测
试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，
测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反
过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。
2、 Bug的80-20原则。
一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能
找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试
只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。
二、测试中心测试组织、测试实施的现状和改进
1、测试中心的任务和发展目标----质量
参与到监控产品生命周期中一切影响到质量的因素的工作中去。
目前测试中心的主要任务是负责产品的系统测试。
但实际上，因为单独的系统测试不能保证产品最终的质量，所以测试中心在部分项目中也参与到集成
测试和用户测试中。
另外，测试中心也承担了部分系统评测的任务和用户技术支持的任务。
测试中心将来的发展目标是研究院开发的产品的质量保证中心，我们的中心任务只有两个字："质
量"，测试中心也只对这两个字负责，并且将参与到监控产品生命周期中一切影响到质量的因素的工作中去。
2、测试中心的组织方式----小组
测试中心内部的个体分为测试人员和支持人员(管理人员属于支持人员)。
测试中心的工作实体(最小组织单位)是测试小组和支持小组，分别由小组长全权负责。小组长向测试
中心主任负责。
测试小组根据测试项目或评测项目的需要临时组建，小组长也是临时指定。与项目组的最大区别是生
命周期短，一般是2周到4个月。在系统测试期间或系统评测期间，测试组长是测试中心对外(主要是项目
组)的唯一接口，对内完全负责组员的工作安排、工作检查和进度管理。
支持小组按照内部相关条例负责测试中心的后勤保障和日常管理工作，机构设置一般相对比较稳定。
主要负责网络管理、数据备份、文档管理、设备管理和维护、员工内部培训、测试理论和技术应用、日常
事务管理和检查等。
另外，测试中心对于每一个重要的产品方向，如：报社系统(包括采编、FIT、RIP、字模等)、电视台
系统(包括点睛、新闻等)…，均设置1-3个人长期研究和跟踪方正及竞争对手的产品特征、性能、优缺点
等。在有产品测试时，指导或参加测试(但不一定作为测试组长)，在没有产品测试时，进行产品研究，并
负责维护和完善测试设计。目前希望在需求分析阶段多多参与(如：Chirashi2.1)。
3、测试中心的运作方式----制度化并形成应用
主要介绍一下项目组关心的系统测试流程：
1、项目组提交系统测试申请给测试中心指定帐号。由专人检查文档格式和完备性。
2、检查合格后交给该产品对应方向的研究人员，评价其内容的有效性和真实性。
3、检查合格后由测试中心主任审查并通过，成立测试组，指定测试组长(但暂时没有组员)。
4、测试组长根据该产品的申请报告、测试设计和以往测试数据，制定测试方案。
5、测试中心主任审核通过测试方案后，根据测试方案指定测试组成员，并由支持组完成其他支持任
务(如：设备的配备、测试数据库的建立、网络权限的修改…)。
6、测试期间测试组根据测试方案进行实际测试，记录并跟踪测试缺陷报告，填写测试记录。测试期
间测试组长与项目组(测试经理)经常沟通，并获取产品的更新版本。同时，测试组长审查、修改并提交所
有缺陷报告，保证随时掌握产品的质量情况，并监督测试进度。
7、产品进行到一定阶段后(标志是测试缺陷报告库中所有的报告处于归档状态)，由项目组和测试组
长共同决定产品进入稳定期测试。稳定期测试版本之前的版本必须在显著位置标明为测试版字样。
8、稳定期测试期间所发现的缺陷报告也需要记录在测试缺陷报告库中，并在稳定期结束后由双方(有
时可能也有市场方面的意见)共同决定对这些缺陷的处理方式。如果需要改动产品，则重新开始稳定期，
否则通过稳定期测试。
9、测试组长对于通过稳定期测试的产品填写综合测试报告，测试中心依此发布产品发行通知。
10、测试组对整个测试过程和产品质量进行总结和评价，形成文档并备案。同时，将测试过程中对测
试设计的改动纳入基线。最后，组长整理并在指定地点保存相关测试数据和测试样张。
11、测试中心解散测试小组。
另外，在系统测试阶段，我们要求测试小组要进行一些常规内容测试(如：Y2K测试，病毒检查、裸机
测试、加密检查、说明书检查…)，并要求写入测试方案中。
4、传统测试流程遇到的挑战和对策----问题发现得越早，解决的代价就越小
1、自动测试工具和测试理论
由于我们的产品开发模式还不够规范、相关文档不够完备，所以测试工具的应用效果不理想，只能部
分应用。如：SQA。
对于测试理论，测试思想/测试理念的灌输工作还是有成效的，但是测试数学模型的研究和建立工作
进展不顺利，主要原因也是我们的产品生命周期内部操作不够规范。
目前主要依赖于：测试人员的经验和素质；产品说明文档和项目组的技术咨询；测试设计。
2、 测试分类
根据目前的实际情况(已经由传统的瀑布开发模式、使用结构化设计和实现手段，变为现在的RAD开发
模式、使用OOD和OOP)，我们将把测试分为三种：产品测试、项目测试、系统评测。我们的依据是：问题
发现得越早，解决的代价就越小。
产品测试的流程基本和上面提到的一样。
项目测试的原则是尽早加入测试，并充分重视和支持用户测试。
系统评测是简化工作流程。三、测试中常见问题分析及对策 我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为4类：死机(系统崩溃或挂起)、致命
(使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免
的)、严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)、一般(界面拼写错误或用户使用不方便)。
我们也把发现的错误按优先级分为三种：高、中、低：一般是越影响用户接受或使用该产品的错误优
先级越高。
但下面，将不对所有的问题进行列举和分析，而只是列出一些显而易见的、容易被项目组忽略的错
误，这些错误可能是容易修改的、或是容易避免的，但是对于测试组或用户来说可能却是非常头痛和不方
便的。
1、形象类问题：---不专业、用户不信任
1、不符合用户操作习惯。如，快捷键定义不科学、不实用(键位分布不合理、按键太多，甚至没有快
捷键)。
2、不够专业，缺乏基本知识，而又没有高手检查：CMYK(0-255)
3、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词
4、SETUP界面：CopyRight 1994-1996；缺省认为用户使用某种分辨率；
5、说明书或帮助的排版格式不专业：中英文搭配不对、标点符号全角半角部分、没有排版禁则…
6、程序名/路径名是程序员的名字、或没有安装程序、或安装程序不完善(丢掉一些必要的模块或文
件)
7、界面元素参差不齐，文字不能完全显示，TAB时鼠标乱走。
2、可用性问题：---用户无法使用或不方便使用
“用户比开发或测试人员在接触界面上要花费更多时间。表面上不重要的方面的影响会变得越来越
大，最终甚至会掩盖了产品得有用得方面。”
下面是一些用户界面错误的例子：
1、输入无合法性检查和值域检查，允许用户输入错误的数据类型，并导致不可逆料的后果
2、界面中的信息不能及时更新，不能正确反映数据状态，甚至对用户产生错误的误导。如：数据库
中剩余记录个数；参数设置对话框中的预设值
下面是一些低效的用户界面的例子：
1、表达不清或过于模糊的信息提示
2、要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修
改某些配置文件。
3、为了达到某个设置或对话框，用户必须做许多冗余操作。如，对话框嵌套层次太多。
4、不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。
5、使用不完善的功能且不给用户以恰当的提示，如：对于TIF图片的不完全支持；Undo功能的局限
性。
6、不经用户确认就对系统或数据进行重大修改
3、稳定性问题：---影响用户正常工作
1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低
2、主系统和子系统使用同样的临界资源而互相不知道。如：使用同样的类名或临时文件名、使用同
样的数据库字段名或登录帐号。
3、不能重现的错误，许多与代码中的未初始化变量(在Debug时一般是缺省初始化的)有关，有些与系
统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。
4、其他问题
1、文档匮乏：无标准；无新功能使用方法；无版本改动说明。我们不仅要认为没有说明文档的产品
不是是一个完整的产品，也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户
无法用得起来。
2、运行时不检查内存、数据库或硬盘空间等
3、无根据地假设用户环境：硬件/网络环境；有些动态库；安装程序换台机器不正确；假设网络随时
都是连通的
4、提供的版本带病毒，或根本无法安装，或没有加密
5、提供Debug版本给测试组或测试用户，或项目组与测试组使用不同版本
6、用户现场开发和修改，又没有记录和保留
7、错误反复出现，改动得不彻底、或版本管理出现混乱
8、错误越改越多，改动得不彻底、或改动得不小心
9、版本中部分内容和接口倒退
10、有些选项永远是灰的；有些选项、菜单项在该灰时还不灰，并且还能状态显示
11、资源没有和代码分离，不同语言版本间不能平滑转换
12、缺少第三方产品的评估：广告管理系统2000年问题
13、产品配合不利，准备当作一套产品或方案推出，互相之间却各不负责，(没有整个项目负责人，
是面向组织的而不是面向产品或方案的)，如：采编+FIT；Gallery+FIT。
……
5、期望项目组关注的一些问题
1、修改Bug的人考虑得不够周全，也可能是没有能力考虑周全---不懂全部程序
2、问题留给测试组去发现的心态----不仔细测试、不小心修改、甚至不全面改(不彻底)
3、自己不会用，不了解产品的用法。
4、更多地从用户使用的角度考虑设计、编码与测试
四、结语
本文准备得匆忙，可能不够全面和细致。这里只希望我们的产品以高质量和全面为用户着想的态度来进入
世界市场，并垄断某些市场。切记：用户和市场是我们的衣食父母… -
[转贴]对测试职业的看法
2007-05-22 12:23:08
迷茫：这就是一个词，描述了现在很多做测试的人的心态，关于这个不想多说，和人的思想有关，我有个朋友，做事情很简单，就是如果他认定了这件事，错的也做下去，你可以说是偏执，其实不见得是，如果在没做之前就仔细的想清楚了，也就不能说是偏执了，何况对职业来说没有什么选择错的，只要你坚定的做下去，古人有云：行行出状元。只怕你不想做状元，只想学会写两个字。拥有这种想法，偶的认为是，要么你找个认为有希望的职业，要么你就迷茫的过吧，反正不是我的生活。
工资，这个问题不能不能，工作嘛，当然考虑到工资，不然吃什么，刚毕业的，拿个2K左右，已经算是可以了，可是也有些人拿1K多，心里总是不爽的，觉得自己低了别人一头，技术上也觉得自己低了一半，这种想法是没有必要的，技术和工资不成比例也有可能，再说刚毕业，学知识是第一的，不然以后你一定是会低一头的，看到有帖子上说工资的，有的人拿的少了，就又晕又汗的，要是你敢拿出技术来要钱，相信你也不会有什么可不服气的。面试，人家一定会问一些技术问题，你会的比人家要的还高，一个月多给你1K、2K的其实对公司来说不算什么，只要你能做事。当然有的人认为和机会有关，机会是什么，人创造的，人家敢做，敢拼，就机会多了。天天缩在被子里喊工资少，没人会理你。有一天和一个网友聊天，说，他什么都挺好，就是工资少，我说为什么呀；他说，我的技术关都过了，可是人家都说我要的工资太高，又没有什么经验。我说你有经验吗？要不我考考你。问了几个问题（针对他说的自己较强的一方面），大部分没回答上来，我说要是我是公司的人员也不给你那么多工资。既然做技术，那就拿出技术来问人要工资（这里不排除走后门和掉馅饼的可能性）。我现在拿的工资我就很满意，我知道自己的份量。
做事，既然是工作就要做事，别的不说，首先要认真，可以不懂，但不能不承认不懂，谁都不是万能的，能全会？不懂就问，上面安排下来一些事，给你一周时间，你可以说，我可能需要多一点时间，因为有些我还不太懂，但别一口答应，信心十足，最后两周没做完，还弄了个烂摊子，没人收得了。和一个朋友聊天：说有一个人，在单位里做事，上面给了一个FTP方面的事情（具体就不用描述了），给了时间限，最后到时间了，去拿结果。那人说，不会弄。不会弄你早干吗呢，怎么不问？没办法就又给了时间，
最后还是不会。这就是技术问题了。还有做错事要敢承认，是我的工作有问题，我就承认，错就错了，都是人，没有不犯错的人，上面会体谅的，不敢承认自己的错误，那是素质问题。做事不能没有这点素质。条理，这里说的是做事，不能乱七八糟的一团，搞到最后自己都不知道哪有问题。本来我们就是做测试的，结果软件的问题没找到，自己的问题一大堆，那怎么办？还要专门整个部门来解决测试工作人员的问题？那炒了可能更简单一点。这里我想说的是，工作要认真负责。别以为是老生常谈，看看自己做好了没有再来体会‘认真负责’几个字。
学习，论坛上看到一些帖子，问了些问题，描述得不清楚，问得又是搜索一下或者看看手册就能明白的问题，后面可能没人愿意回，最后一直喊，怎么没高手？怎么没高手？自己不主动就别叫天喊地的，没用。还有的帖子后面说，谁知道这个问题，我的MSN是＊＊＊@hotmai.com，QQ：＊＊＊＊＊＊＊＊，。不知道这样的人等什么，等上门服务的？手册留着当传家宝吗？这里说的是学习要主动，不然没人愿意一步步告诉你，又没收你钱。
当然谁都有不会的问题不是吗？把问题的出现，描述清楚，手册找找，论坛翻翻，实在找不着，也描述多一些，打几个累不死人。别让后面跟了十个帖，全是在猜你要干什么的。
测试职业，做的就是它，当然要说它，有很多人对测试还是没信心，前面我说了，测试没有什么迷茫的，只是一个职业，现在测试发展的已经不错了，51论坛的浏览量可以做个证明（这里不是广告哈，因为你都到这里看帖了），和一些做过一两年测试的人聊天，说前几年的时候测试资料网上都找不见，看现在，一搜一堆，这就是见证。所以这个职业的前景是很好的。软件的错是不会完全消失的。所以测试就得继续下去。做好它，这就是选择了这个职业的人最应该坚定的事情。所以不会存在二义性。 -
软测工程师需要具备四种能力
2007-05-22 12:21:32
作为IT测试的重要组成部分，软件测试近年来一直稳定增长，尤其是在电信、银行、军工、航天等领域。在软件业较发达的国家，软件测试不仅早已成为软件开发的一个有机组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。与此同步的是，软件测试市场已成为软件产业中的一个独特市场。
软件必须经过测试，测试是验证软件是否能达到期望功能的唯一有效的方法。据了解，目前国内的软件测试一般有下列几种形式：一是软件公司内部进行的功能性测试；二是用户进行的测试；还有就是第三方测试，即专业软件测试人员运用一定的测试工具对软件的质量进行检测。
那么软件测试工程师（Software Testing Engineer）究竟是做什么的？什么样的人适合做这个职业呢？
据较早开展软件测试工程师培养项目的51testing的老师介绍，软件测试工程师就是一群专门挑错的人。他们按照产品的功能要求，并对其进行测试，检查软件有没有错误，决定软件是否具有稳定性，写出相应的测试规范和测试案例。简言之，他们在软件企业中担当“质量管理”的角色，以确保产品的正常运作。
●做软件测试至少要有专科学历
据前程无忧职业顾问分析，目前企业在招聘软件工程师时，一般需要至少专科学历，有一到两年的测试工作经验。还要熟悉软件的测试技术、方法、流程、测试文档。
若想得到职业生涯的进一步提升，还要熟悉自动化测试的流程、管理及深层开发（包括测试框架等）；了解若干主流测试工具，如功能测试工具，性能测试工具，配置管理工具等；熟悉一些主流的软件工程方法论和思想；了解软件工程，软件生命周期模型基础，了解软件配置管理；能够根据不同企业的产品特点，要求了解相应的开发测试方法。对于资深的软件测试人员，有些企业还要求其本身有自主开发测试工具的能力。
另外，由于需要与开发人员及时沟通，因此作为一个出色的软件测试工程师，还要有出色的沟通技巧以及优秀的言语表达能力，具备良好的团队合作精神。
●做软件测试至少要有四种能力
曾经在方正研究院担任测试工程师的肖先生分析说，能胜任软件测试工程师的人，至少需要以下几个能力。
一、缜密的逻辑思维能力。为应对软件使用者千差万别的使用习惯和软件在使用过程中出现的各种现象，软件测试工程师应具有逆向思维能力，能够以用户角度出发，捕获一切可能性，对细节有不同寻常的关注能力。
二、出色的沟通能力。优秀的软件测试工程师，应具备出色的沟通和表达能力。既能和技术开发人员沟通，又能简洁明了地向客户、管理者等这些非技术人员阐述系统在哪方面有缺失。当发现软件有问题时，不仅需要跟开发人员沟通，找到问题出在哪儿，阐述自己挑错的理由，有时候甚至要提出解决方案，直接参与前期需求和代码的修改。
三、全面的技术能力。作为软件测试工程师，虽然无须精通各种语言各类技术，但必须全面理解被测软件系统，明白该使用何种工具进行测试。
四、耐得住性子。软件测试工作是枯燥的，甚至是重复性的，有时需要花费惊人的时间去分离、识别和分派一个错误，因此需要测试人员能静得下心、耐得住性子，心浮气躁是做不好的。
加拿大技术皇家学院的金教授分析说，相对于其他软件工程人员，软件测试工程师的知识面应非常宽广，最重要的品质应能够在第一时间内接受新技术。
目前软件测试人才的培训体系除正规院校外，更多以IT职业培训为主。 -
当遇到没有文档的时，如何进行软件测试？
2007-05-22 12:20:16
在国内的许多公司，系统需求的文档化方面是比较差的，根据我的经验，我们可以从下面来改进我们的测试效率：
1、多和相关的软件开发人员进行沟通，或者针对某个功能，让开发人员进行培训，尽量了解功能在系统的作用以及特点等。
2、进行探测性测试，来慢慢熟悉系统的功能，同时了解系统的测试环境。
3、进行探测性测试，来发现系统中存在的一些问题，通过分析问题的原因，我们可以来决定功能的哪些部分是需要我们重点进行测试的，即测试的方向。因为系统缺陷的存在分布，也是符合80/20原理的。
4、通过探测性测试，也可以来决定系统模块中的功能参数的阈值：最大值、最小值等等。
更重要的，从我们测试的角度，慢慢实现软件测试的规范化、文档化，同时来推动公司组织内软件流程的改进。从测试来推动软件流程的改进也是一种比较有效的方法。 -
一经验之谈
2007-05-22 12:18:46
1，测试路。
这一年一直在一家公司里做测试，虽说在公司里接触的不多，而在网络上接触了很多的东西。常逛论坛也认识了一些测试同行。
坛子上的迷茫的人依旧不少，回头看这一年的时间，想来想去，嗯，还在坚持。在一个正当的行业上，只要坚持，我觉得就不会有迷茫的想法了。纵然不知道你会努力成功到什么样子，可是也不会觉得没有重心。有人在谈论测试前途的问题时，总是一头雾水，其实对每个行业的人来说，可能有大多数的人处于这个状态。而能改变这个状态的，只有自己心态的改变。我记得有一个朋友给我发过一个短信：人们总结成功应具备三种素质：1，有肚量去容忍那些不能改变的事；2，有勇气去改变那些可以改变的事；3，有智慧去区分上述两类事。我觉得说的挺有道理，其实人遇到迷茫的事情，应该做的事，就是思考和判断。
谨希望各位同仁做到思考和判断。
2，工作相关。
不管个性是什么样的，在工作中一定要跟同事融洽相处。这一点真的很重要。特别是和开发的关系。我在公司里和开发的关系是最好的，因为我很尊重开发。大家一块工作，合作好一些，工作进度也会快一点。针对测试和开发对立的状况，我觉得尤为不妥。做测试是在针对开发的程序来做的测试。而一定要搞清楚的是，不是对人测试的。即对事不对人。但是呢，人都是有性情的，所以要明白开发的一些性情。千万不要对着干。这样一来可能导致的是测试的工作越来越难做。和开发要有互助的感觉。
对文档，我的想法在这一年里有所改变的。文档还是写的详细一些为好。刚开始进公司的时候。文档是很散乱的，看别人的文档总是晕乎乎。搞不明白。可是也没人问去，只有慢慢琢磨。后来我把文档整理了一下，在我的眼里看来：我的文档很容易理解了。但是，后来新来了两个新人，看我的文档也是一头雾水。所以写文档要尽力的写详细些。当然事无巨细也是做不到的，看具体的情况了。
沟通。这一点很重要。
做测试一定要学会沟通，做事要细致。
3，感恩。
我不知道其他人在公司里是什么样的感觉。不知道是不是满腹的抱怨。
我对第一家公司没有任何的抱怨的，我很感激第一家公司给我的机会。让我在测试这个行业深入了一些。有机会做自己喜欢做的事还是很开心的。
我想有些人对感恩嗤之以鼻。建议这样的人，好好的想一想。机会是很多人都可以提供的。这不错，可是也不是谁都愿意给你提供的。并且在生活中遇到的人，都应该好好的取之长。善于学习才能进步的更快。
不要只会抱怨，要学着感恩，学习中成长。
4，努力提高自己。
自学是持续的过程。千万不要放弃的就是自学。建议业余时间少打会游戏。多看点资料。以前我写过一些关于学习的话。现在对自学这一点感触更深。如果只等着别人拿食物来喂，那种状态是很慢的、可怜的状态。有些人工作三五年还是一个样子。这就绝对怪不得环境了，只能怪自己。别人花了一个月的时间的努力，比你一年的努力都多，那就显然相别人形见自己绌了。并且学习的心态要主动。被动的和主动的心态，即便在看同一份文档，收获也肯定是不同的。我不知道其他人有没有这种感觉。我自己是有的。
学习要靠自己 -
人生少走弯路的10条忠告
2007-05-22 12:17:10
如何在涉世之初少走弯路，有一个好的开端，开始一番成功的事业？以下是一些先行者积累的10条有益的涉世忠告。好好地遵循、把握这些忠告和建议吧，比起所学的课堂课程来，它毫不逊色！
1. 买个闹钟，以便按时叫醒你。贪睡和不守时，都将成为你工作和事业上的绊脚石，任何时候都一样。不仅要学会准时，更要学会提前。就如你坐车去某地，沿途的风景很美，你忍不住下车看一看，后来虽然你还是赶到了某地，却不是准时到达。“闹钟”只是一种简单的标志和提示，真正灵活、实用的时间，掌握在每个人的心中。
2. 如果你不喜欢现在的工作，要么辞职不干，要么就闭嘴不言。初出茅庐，往往眼高手低，心高气傲，大事做不了，小事不愿做。不要养成挑三拣四的习惯。不要雨天烦打伞，不带伞又怕淋雨，处处表现出不满的情绪。记住，不做则已，要做就要做好。
3. 每个人都有孤独的时候。要学会忍受孤独，这样才会成熟起来。年轻人嘻嘻哈哈、打打闹闹惯了，到了一个陌生的环境，面对形形色色的人和事，一下子不知所措起来，有时连一个可以倾心说话的地方也没有。这时，千万别浮躁，学会静心，学会忍受孤独。在孤独中思考，在思考中成熟，在成熟中升华。不要因为寂寞而乱了方寸，而去做无聊无益的事情，白白浪费了宝贵的时间。
4. 走运时要做好倒霉的准备。有一天，一只狐狸走到一个葡萄园外，看见里面水灵灵的葡萄垂涎欲滴。可是外面有栅栏挡着，无法进去。于是它一狠心绝食三日，减肥之后，终于钻进葡萄园内饱餐一顿。当它心满意足地想离开葡萄园时，发觉自己吃得太饱，怎么也钻不出栅栏了。相信任何人都不愿做这样的狐狸。退路同样重要。饱带干粮，晴带雨伞，点滴积累，水到渠成。有的东西今天似乎一文不值，但有朝一日也许就会身价百倍。
5. 不要像玻璃那样脆弱。有的人眼睛总盯着自己，所以长不高看不远；总是喜欢怨天尤人，也使别人无比厌烦。没有苦中苦，哪来甜中甜？不要像玻璃那样脆弱，而应像水晶一样透明，太阳一样辉煌，腊梅一样坚强。既然睁开眼睛享受风的清凉，就不要埋怨风中细小的沙粒。
6. 管住自己的嘴巴。不要谈论自己，更不要议论别人。谈论自己往往会自大虚伪，在名不副实中失去自己。议论别人往往陷入鸡毛蒜皮的是非口舌中纠缠不清。每天下班后和你的那些同事朋友喝酒聊天可不是件好事，因为，这中间往往会把议论同事、朋友当做话题。背后议论人总是不好的，尤其是议论别人的短处，这些会降低你的人格。
7. 机会从不会“失掉”，你失掉了，自有别人会得到。不要凡事在天，守株待兔，更不要寄希望于“机会”。机会只不过是相对于充分准备而又善于创造机会的人而言的。也许，你正为失去一个机会而懊悔、埋怨的时候，机会正被你对面那个同样的“倒霉鬼”给抓住了。没有机会，就要创造机会，有了机会，就要巧妙地抓住。
8. 若电话老是不响，你该打出去。很多时候，电话会给你带来意想不到的收获，它不是花瓶，仅仅成为一种摆设。交了新朋友，别忘了老朋友，朋友多了路好走。交际的一大诀窍就是主动。好的人缘好的口碑，往往助你的事业更上一个台阶。
9. 千万不要因为自己已经到了结婚年龄而草率结婚。想结婚，就要找一个能和你心心相印、相辅相携的伴侣。不要因为放纵和游戏而恋爱，不要因为恋爱而影响工作和事业，更不要因一桩草率而失败的婚姻而使人生受阻。感情用事往往会因小失大。
10. 写出你一生要做的事情，把单子放在皮夹里，经常拿出来看。人生要有目标，要有计划，要有提醒，要有紧迫感。一个又一个小目标串起来，就成了你一生的大目标。生活富足了，环境改善了，不要忘了皮夹里那张看似薄薄的单子。 -
测试用例模板
2007-05-22 12:13:25
测试用例
编号：
编制人
审定人
时间
软件名称
编号/版本
测试用例
用例编号
参考信息（参考的文档及章节号或功能项）：
输入说明（列出选用的输入项，覆盖正常、异常情况）：
输出说明（逐条与输入项对应，列出预期输出）：
环境要求（测试要求的软、硬件、网络要求）：
特殊规程要求：
用例间的依赖关系：
-
编写测试用例的方法
2007-05-22 12:07:33
一、对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。如果根本没人看，测试用例则是用来提示自己不要忘记了要测试哪些项。所以只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。
二、测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。熟悉了软件的业务才能去写测试用例，才能更好的去测试。三、１、测试用例要根据测试大纲来编写２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。
３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。
４、熟悉系统，对编写测试用例很有帮助。
５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。
