前2天去面试了IBM，突然感觉自己这2年来很失败。有很多东西都没有总结，也有很多东西没有仔细学习。记下这失败的经验，但愿以后任何面试可以顺顺利利。

    现在想想为什么要进去那么早呢。提前到本来是好事，现在却变成了自我施压的时间。以后面试一定只提前5分钟到。他的问题是：

    1。 为什么来面试，上一个公司怎么了？

    2. 英文自我介绍+谈谈对自己的职业规划。

    3. QTP相关的东西。QTP是怎样的东西，怎样概括QTP？ 还有是说到我们QTP frameworks. 其中一个问题是怎样定义reusable action和functions。这2着之间有什么区别？对Object repository的相关问题。有没有改过object descrīption properties,可不可以举个例子用正则表达式来修改object descrīption properties。

    4. 测试的基本功。举个例子怎样做test design，方法是什么？ 怎样测电梯的控制程序？

    5. 你有些什么问题。

    现在想起来，这些问题本不是非常难。为什么当时没有很好的发挥出来呢？郁闷。怎样概括QTP,以前都有总结过，其实就是GUI functional testing tool, using VB scrīpt. 具体有哪些内容的话其实也就是： Objects(TO, RO and Object identifier), parameterize, checkpoints, descrīptive programming, automate QTP and object repository. 

    Reusable action和functions的区别: 1) reusable action本身作为action,可以associate object repository, 可以加resources files. 哎。。看来这里还是没有弄清楚。其实如果是调用reusable action和function，本质上来都是直接跑那些steps而已，如果是这样的话，那理论上funcitons也可以全部用reusable action来实现啊？ 到底2者有什么区别？如果在一个framework中，这2中都希望用到的话，到底怎样定义那些写成reusable action，那些写成function呢？

    有关电梯测试： http://bbs.51testing.com/viewthread.php?tid=110214&highlight=%B5%E7%CC%DD%2B%B2%E2%CA%D4 

  自动化总体要求是 自动化覆盖率更高，维护成本更低，挖掘层次更深，运行速度更快，培训力度和知识分享覆盖面更大，运营管理更加规范， WATIR框架平稳取代QTP框架

         1）   代码更加灵活。 比如代码可以通过配置数据库检查开关

2）   由于代码变更，各小组接口人定期（每2个月？）结合代码覆盖率数据，给出各个小组自动化下一步功能自动化用例建议

3）   人员增长很快，所以培训力度、分级制度更完善。 各个小组接口人注意跟上。 另外，知识分享做好可以大幅度降低学习门槛

4）   项目发布后预留一些自动化脚本编写时间，以便及时维护、完善脚本，从而减少自动化脚本重复执行次数

5）   脚本运行速度进一步提升。 从另外一个角度，力争研发单位预留至少一个晚上运行时间以及前一天必要的准备运行时间

6）   继续完善自动化运行管理平台，自动统计、分析QTP/WATIR框架、脚本运行状况，图形化展现覆盖率数据趋势―――――――――――――――――――――――这个需要额外增强现有框架

7）   接口人定期跟进项目，挖掘可自动化的点，主要由测试组实施。

8）   测试小组第一期自动化脚本由QA架构组主导搭建，后期的维护、增强由测试组实施。工作重心在优化框架，解决部门级别公共自动化问题  

9）   深入接口测试，SOA测试等，不局限于页面级别自动化

 　通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。但是，在系统测试和确认测试中，测试人员容易遗漏一些隐藏的缺陷。众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括：
　　1、安装缺陷

　　通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失;使用绝对路径;安装顺序没有说明书。

　　2、配置文件

　　有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的!这是一个安全隐患。另外，有些安装文件的 XML 文件，为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。所以，配置文件可能成为软件安全方面的一个缺陷。

　　3、网页安全缺陷

　　现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE 窗口输入，可以绕过登陆直接访问。也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。

　　网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。

　　4、判断顺序/逻辑缺陷

　　对界面进行多个输入判断的时候，非常容易出现这种问题。例如判断年月顺序，判断长度，判断非空等。假如操作员仅仅满足单个条件，保存不能成功; 而按界面从上之下顺序一一满足条件之后，保存是没有问题的。但是，改变一下输入的次序，校验失效。例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看看代码是否强健，是否在判断逻辑上没有错误。良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。

　　5、调试语句和冗余信息

    维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为系统发生了严重故障，从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用，其结果可想而知;而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。

　　同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。

    6、不可重现的故障

　　新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗?回答是肯定的。测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。

　　7、多节点的逆向流转缺陷

　　当前软件不少喜欢使用工作流来驱动。工作流的问题，就是可能出现多个流向分支。测试容易忽略的部分，就是工作流多节点的逆向流转。例如，通过不通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外，有些时候默认分支在向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。

　　8、输入框缺陷

　　试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候，输入框会根据长度大小自动截断输入长度。但是用鼠标，截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了，保存的时候，数据库崩溃。有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。

　　输入框可以说是问题最多的部分，能够引起的麻烦也很多。日期、数字、文本等等，都需要耐心的测试一下。

　　9、界面布局缺陷

　　曾经有一次，项目经理回来向测试部反映一个问题，客户对界面不满意。原因很简单，因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员，很容易误按。这个问题是测试人员没有意料到的，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

　　界面布局还可能发生在窗口最大化和最小化上，有可能窗口缩小的时候没有下拉框或不匹配分辨率，对用户来讲，这个错误实在很低级。有些用户由于操作习惯，非常不喜欢腾出手使用鼠标，尤其是大量输入的界面，因此，要注意设置键盘的快捷方式。还有，按 Tab定位到下一焦点时要注意顺序，避免跳转太灵活而让操作人员感到无从适应，在界面进行维护或者修改的时候，不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。

　　10、版本和补丁包的环境问题

　　理论上讲，这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包，问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例，多用不同软件版本的机器跑一跑。软件测试有个定律是：你没跑过的地方，就一定会出事。经常听到开发人员抱怨，怎么我的机器没问题，你的机器就有事了呢?这不能完全靠配置管理员解决问题，环境配置项是大家最容易忽略的。

　　11、用户管理缺陷

　　用户管理的角色和授权需要好好研究一下，作过测试的人员都知道，有时候为了测试的方便，测试用户都是具有超级权限的用户。而且，比较容易忽略用户管理这一部分的测试。往往发往客户的时候，很多测试用户都没有删除。

　　另外，有些接口的用户和口令，到软件使用寿命结束都没有更改过。在一次测试中，软件测试人员发现，给一个用户授超级用户权限，之后更改这个用户为受限权限。使用中发现，用户居然没有真正回收权限，用户管理界面上没有任何不对。及早准备用户管理用例，不要等到测试快结束时候才想起。

　　12、常识缺陷

　　从逻辑或者统计学上讲，计算机是允许如此处理的，但是从常识上来讲，这些情况不可能发生。例如电话号码不可能出现小数点，终止时间不能大于开始时间等等。除此之外，常识还要结合业务特点来进行判断，因此，开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现，对用户来说，这些错误可能是很荒谬的。

 尽管我们不可能完美的测试一个软件，但是我们仍然可以改进我们的软件测试。每次测试结束，及时总结测试中的不足，进一步完善用例。思考一下那些容易忽略的软件缺陷，能提高对软件测试的认识，提高所在组织软件的质量。

 

可能这个标题有点大了，实在想不出什么好的标题了，就让我也标题党一回吧!

多多少少也面试个几个人了，有一点心得，拿出来分享一下：

记得当年我第一次应聘的时候，根本就没意识到面试的重要性，很随意的就去见了我之前的老总，虽然顺利的通过，但后来到了公司之后，才知道我当时是多么的惊险。直到后来，我才明白当初老总那玩味的眼神意味着什么！还好，平时知识积累了那么点，谈吐也不是扭扭捏捏，回头来看，我的运气还不错。

后来，我第一次作为面试官的时候，同样遇到跟我当年作风一样的一个小男孩，我才明白我当年是多么的幸运，而我面前这个男孩是多么的不幸。5

我不大清楚hr是怎么面试的，我大概了解测试的技术面试，那就大概谈谈，我作为面试官，我喜欢什么样的测试，下面我说的主要结合面试官的角度来说说，而不是从应聘者的角度来分析，让大家对面试官的心理有一定把握。

第一印象：

   第一印象非常重要，一般来说你的着装能代表你对工作和你对这个职位的态度，也能决定面试官的‘考察深度’，相信如果你不是超级牛人，你应该不愿意面试官给你很有深度的问题。当然牛人例外，因为牛人一般是后面用他的技术和他的才华来征服面试官。建议面试的时候穿着比较正统，相对轻松的服装，最重要的是整洁。为什么这么说呢?因为技术面试一般来说都是改公司测试部门的人，一般来说都是搞技术的，在大多企业，技术部门的着装是很随便的，所以着装没必要太隆重，过于隆重可能会适得其反。

千万不要不懂装懂：

    上面说了，技术面试一般都是公司的工作人员，多多少少有点斤两，如果问你几个问题，你不会就不会，但是不用回答的太直接，你可以委婉的说你不太熟悉，虽然回答问题失败了，但是面试官会知道你是个诚实的测试人员。我之前面过一个测试，他自称在某游戏公司负责自动化测试，主要成果是开发机器人。恰好，我对这个也比较感兴趣，就顺便问了一下机器人和游戏服务器如何实现通信的，机器人和游戏客户端区别是什么？不过这个人很聪明，他的回答是：通过网络实现通信，机器人不需要人来操作，客户端需要人来操作。他的答案其实没错，只是如果自己做过这些东西，了解这些东西的话，相信他不会这么回答我，我也就只好请他等候通知了，呵呵！一般我们问问题的时候，自己心里是有底的，如果你试图忽悠面试官的话，我可以明确的说99%的情况下，你会失去资格。

其实我们也没标准答案：

    一般2种情况下，面试官会问你很深入的问题，这类问题其实面试官他们也没好的解决方案，呵呵！第一种情况就是你的态度或你的表现让面试官不满意了，另一种情况，就是你太让面试官满意了，这2种情况，其实在面试的时候，你自己应该是能区分出来的，如果你很谦虚，前面问题有回答的很有条理，思路也很清晰，那就是第二种，如果你什么都不清楚的话，那你多半是第一种了。如果是第二种，我恭喜你，这个时候其实面试官已经让你通过了。这个时候面试官一般问的问题都比较深入，或者是比较经典的问题，或者他自己都没解决这个问题，你只要放心大胆的说出你的想法以及分析思路和原因就行了，如果解决了面试官的问题，那offer差不多就是你的了，如果解决不了，也不用担心，你至少说出了你的想法，让面试官知道你思考问题的方式。

沟通很重要：

    测试的一个重要素质就是沟通能力，面试官不会直接考察这个能力，而是通过面试过程来给你这个能力评分。所以从头到尾，你都要表达清楚，大方，而且能抓住重点。很多应聘的同学，心理会有一点紧张，经常会出现答非所问，或者不知所云的情况。如果是这样，建议多问问面试官，你是问的这个问题吗？你是想问这个问题出现的原因还是解决的办法？这样，你可以更精确的定位面试官的意图，直接答到点子上去，面试官绝不会因为你问了问题而给你不好的评价。

思考方式也是一种能力：

    在面试的时候，我经常会遇到一些应聘者不知道如何回答一个问题.一般来说他们会选择说我不知道，或者欺骗的方式，这些我都不喜欢。只有很少的人，他会来分析这个问题，他在分析过程中，熟悉问题，切入问题，解决问题。在遇到这种问题的时候，不要怕，大胆想，不怕出错，但出错也要出得情有可原。实在解决不了，你表达出你思考方式就好了。这样我也会给你一个高分。你要什么都不说我只好不给分了，当然你要乱说的话，我就只能在前面给你扣分了。

做你擅长的事：

    面试的时候，一般会问到你最擅长的是什么？这个时候你可以放心大胆的说，而且一定要深入。首先你需要有信心，你擅长的，面试官不一定擅长，要尽可能展现你的能力，让面试官对你有一个清新的认识。只要你的观点，思路正确，面试官还是会认同的，虽然面试官他不知道为什么，但是他知道是什么。这个主要是为了让面试官欣赏你，觉得你能给他们带来帮助。

装b被雷劈：

   我遇到好几个应聘者，一来就说什么国内测试行业很落后，国外很先进，什么国外的做得多么好，微软的做得多么好，但我一问为什么？让他们分析一下原因，却没人说的上来！其实我也说不上来，所以我不说。经常遇到自称能力很强，一副我是救世主，来了可以拯救你们公司的模样。大家都是技术人员，都有几分傲气的，现在还是你的面试官，你就这么装b，那将来要是同事了，你让我怎么过啊？我还敢招你吗？如果你确实能力出众，那无可厚非，但是如果半灌水，那就......，其实我也遇到很多大牛，我发现一点，越大的牛，越低调，越谦虚。

细节决定成败：

   面试官其实大多很注重细节，比如坐姿啊，手势，眼神之类的，这些其实网上说得也多，就不多说了。一次，我面试一个学生，面试完了后，说完再见他轻轻的带上门，这一点让我很欣赏他。因为之前的学生要么就是不关门，要么就是砰的一下关上门，我直接让他b变成了a，我同事问我为什么，我跟他说，这么关注细节的人，能做不好测试吗？

好了，就说这么多了，看书去了！

广告一下哈：有兴趣的可加群17827576，主要是讨论游戏测试生活的

　　1. 精通性能测试的基本概念，过程，方法论，了解性能工程；

　　2. 精通1个商业性能测试工具+1个开源性能测试工具，知道工具可以做什么，不可以做什么，以及工具使用中常见的问题和解决思路；

　　3. 扎实的计算机专业基础知识，包括计算机组成原理、操作系统、数据库原理、计算机网络原理；

　　4. 熟悉至少1个常用的数据库产品，例如SQL Server或者 Oracle，能进行一般的数据库管理操作，熟悉SQL脚本的使用，熟悉常用的数据调优工具和常用的counter；

　　5. 熟悉至少一个操作系统的原理，Windows或者Linux都可以，熟悉操作系统的体系架构、操作系统的重要基础概念，以及内存管理、存储/文件系统、驱动/硬件的管理、网络协议的实现及构成、性能的监控方法和原理，熟悉常用的counter；

　　6. 熟悉至少一个web server 产品，例如apache，了解一般的配置和常用的counter；

　　7. 熟悉至少一个应用服务器产品，例如tomcat，了解一般的配置，熟悉常用的服务器性能监控方法和原理，熟悉常用的counter；

　　8. 至少熟悉TCP/IP协议，熟悉HTTP协议，至少见过并了解三层、四层交换或者路由器的使用和配置。了解常用的与网络性能相关的counter；9. 了解一般的大型企业应用的部署架构和应用架构；

　　10. 了解知名大型web应用、高并发量、高流量、实时响应要求高的超大规模网站的架构和优化历程；

　　11. 熟悉统计学的基础知识、常用分析方法以及实验设计方法，了解数学建模相关的知识；

　　12. 熟悉专属行业的业务知识和用户场景，例如电信行业的OSS系统所涉及的业务知识和用户场景，证券交易系统所涉及的业务知识和用户场景；

　　13. 大量的实际性能测试及优化经验；

　　14. 积极的参与到各类圈子、社团的讨论和交流、分享中

经验举例1

交易的响应时间如果很长，远远超过系统性能需求，表示耗费CPU的数据库操作，例如排序，执行aggregate functions（例如sum、min、max、count）等较多，可考虑是否有索引以及索引建立的是否合理；尽量使用简单的表联接；水平分割大表格等方法来降低该值。

 

经验举例2

分段排除错误。测试工具可以模拟不同的虚拟用户来单独访问Web服务器、应用服务器和数据库服务器，这样，就可以在Web端测出的响应时间减去以上各个分段测出的时间就可以知道瓶颈在哪并着手调优。

 

经验举例3

UNIX资源监控（NT操作系统同理）中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。“Swap in rate”和“Swap out rate”也有类似的解释。

 

经验举例4

UNIX资源监控（NT操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器 。合理使用的范围在60%至70%。

 

经验举例5

UNIX资源监控（NT操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统、重新部署业务逻辑等，另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。

 

经验举例6

Tuxedo资源监控中指标队列中的字节数（Bytes on queue），队列长度应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。

 

经验举例7

SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。

1、好好规划自己的路，不要跟着感觉走！根据个人的理想决策安排，绝大部分人并不指望成为什么院士或教授，而是希望活得滋润一些，爽一些。那么，就需要慎重安排自己的轨迹。从哪个行业入手，逐渐对该行业深入了解，不要频繁跳槽，特别是不要为了一点工资而转移阵地，从长远看，这点钱根本不算什么，当你对一个行业有那么几年的体会，以后钱根本不是问题。频繁地动荡不是上策，最后你对哪个行业都没有摸透，永远是新手！

2、可以做技术，切不可沉湎于技术。千万不可一门心思钻研技术！给自己很大压力，如果你的心思全部放在这上面，那么注定你将成为孔乙己一类的人物！适可而止为之，因为技术只不过是你今后前途的支柱之一，而且还不是最大的支柱，除非你只愿意到老还是个工程师！

3、不要去做技术高手，只去做综合素质高手！在企业里混，我们时常瞧不起某人，说他“什么都不懂，凭啥拿那么多钱，凭啥升官！”这是普遍的典型的工程师的迂腐之言。8051很牛吗？人家能上去必然有他的本事，而且是你没有的本事。你想想，老板搞经营那么多年，难道见识不如你这个新兵？人家或许善于管理，善于领会老板意图，善于部门协调等等。因此务必培养自己多方面的能力，包括管理，亲和力，察言观色能力，攻关能力等，要成为综合素质的高手，则前途无量，否则只能躲在角落看示波器！技术以外的技能才是更重要的本事！！从古到今，美国日本，一律如此！

4、多交社会三教九流的朋友！不要只和工程师交往，认为有共同语言，其实更重要的是和其他类人物交往，如果你希望有朝一日当老板或高层管理，那么你整日面对的就是这些人。了解他们的经历，思维习惯，爱好，学习他们处理问题的模式，了解社会各个角落的现象和问题，这是以后发展的巨大的本钱，没有这些以后就会笨手笨脚，跌跌撞撞，遇到重重困难，交不少学费，成功的概率大大降低！

5、知识涉猎不一定专，但一定要广！多看看其他方面的书，金融，财会，进出口，税务，法律等等，为以后做一些积累，以后的用处会更大！会少交许多学费！！

6、抓住时机向技术管理或市场销售方面的转变！要想有前途就不能一直搞开发，适当时候要转变为管理或销售，前途会更大，以前搞技术也没有白搞，以后还用得着。搞管理可以培养自己的领导能力，搞销售可以培养自己的市场概念和思维，同时为自己以后发展积累庞大的人脉！应该说这才是前途的真正支柱！！！

7、逐渐克服自己的心里弱点和性格缺陷！多疑，敏感，天真（贬义，并不可爱），犹豫不决，胆怯，多虑，脸皮太薄，心不够黑，教条式思维。。。这些工程师普遍存在的性格弱点必须改变！很难吗？只在床上想一想当然不可能，去帮朋友守一个月地摊，包准有效果，去实践，而不要只想！不克服这些缺点，一切不可能，甚至连项目经理都当不好--尽管你可能技术不错！

8、工作的同时要为以后做准备！建立自己的工作环境！及早为自己配置一个工作环境，装备电脑，示波器（可以买个二手的），仿真器，编程器等，业余可以接点活，一方面接触市场，培养市场感觉，同时也积累资金，更重要的是准备自己的产品，咱搞技术的没有钱，只有技术，技术的代表不是学历和证书，而是产品，拿出象样的产品，就可技术转让或与人合作搞企业！先把东西准备好，等待机会，否则，有了机会也抓不住！

9、要学会善于推销自己！不仅要能干，还要能说，能写，善于利用一切机会推销自己，树立自己的品牌形象，很必要！要创造条件让别人了解自己，不然老板怎么知道你能干？外面的投资人怎么相信你？提早把自己推销出去，机会自然会来找你！搞个个人主页是个好注意！！特别是培养自己在行业的名气，有了名气，高薪机会自不在话下，更重要的是有合作的机会...　

10、该出手时便出手！永远不可能有100%把握！！！条件差不多就要大胆去干，去闯出自己的事业，不要犹豫，不要彷徨，干了不一定成功，但至少为下一次冲击积累了经验，不干永远没出息，而且要干成必然要经历失败。不经历风雨，怎么见彩虹，没有人能随随便便成功！

测试项目：杯子

需求测试：查看杯子使用说明书

界面测试：查看杯子外观

功能度：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌

可*性：杯子从不同高度落下的损坏程度

可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

跌落测试：杯子加包装(有填充物),在多高的情况摔下不破损

震动测试：杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输

测试数据：测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法

期望输出：该期望输出需查阅国标、行标以及使用用户的需求

说明书测试：检查说明书书写准确性

     

在面临人生的选择时，我们都想要选一条最短的路，最快获得幸福。可是，陈彤却掷地有声地说："这是关于幸福人生一个最经典的误解。"很早的时候，看过一本书，名叫《亨利八世和他的六个妻子》。当时不明白，在他杀了第一个妻子时，为什么还有女人肯赴汤蹈火嫁给他？

　　现在我不会问这种问题了--他杀了一个老婆，后面一定还会有很多女人排着队自荐枕席，因为他是亨利八世，嫁给他，自己就是王后，自己生的孩子就可以继承王位。毕竟这是最短的一条路--虽然从结果看，是通向死亡最短的路，但在最终结果降临之前，很多女人都会认为这是通向幸福最短的路吧？

　　我们每个人都想找到一条通往山顶的捷径，就像每个人到股市买进卖出都是为了赚到钱，而不是为了血本无归。如果有人事先告诉我们某只股票是垃圾股，我们一定不会轻易买进，同样道理，假如一支正在大涨大红的股票即使已经涨得很高，高到千钧一发，我们还是会奋不顾身地买下，以为它还会涨。人生就是充满这么多不确定性--有的路，看上去很容易，很平坦，可一旦上了路，就是一条不归路。

　　一个女朋友失恋了，我们说，天下男人又没有死绝，你那个男友也很一般，赶紧再找一个更好的补回来。于是，我们把认识的所有"钻贵"都往她那里推，因为这是一条捷径--在千百万成功富有的男人中，只需要有一个对她说"Yes"，那她这辈子的幸福就到手了。这事儿难吗？从理论上说，不难。她美丽、年轻、单纯，而且很温柔，多才多艺，应该不是什么难事吧？但偏偏就等了很久很久--不是没有人追求她，但总在谈婚论嫁的一瞬间，那些她中意的男人们，却全身而退。也不是没有男人肯娶她，但那些肯娶她的男人，她又不满意--因为他们显然是一条太远的路，她说，要跟他们吃多少苦，才能享受到丰收的喜悦？

　　很喜欢阿加莎．克里斯蒂的故事。她生于1890年，那个时代，女人大部分是没有工作的，尤其是贵族妇女。可惜阿加莎没有那么好的命，她爱上了一个没有多少钱的穷男人，嫁给了他，为他生了一个可爱的女儿。他们同甘共苦，曾经有过相当拮据的日子。后来，男人发迹了，他们买了大房子，以及只有富人才拥有的轿车。然后，男人爱上另一个女人。阿加莎的小女儿对自己的母亲说："父亲喜欢我，他只是不喜欢你。"阿加莎伤透了心，但她承认女儿说得对。

　　她等了一年，期待丈夫回心转意，当然，她的期待落空了。于是，她同意离婚。她说："再没有什么可以忧虑的，剩下就是为自己打算了。"她为自己打算得很好，不仅以写神秘谋杀案闻名于世，而且还嫁给了比自己小14岁的年轻考古学家--她在39岁那年遇见了25岁的他，人们劝她不要接受这个年轻人的爱情，她回答："为什么不呢？他热爱考古，所以我不用害怕变老--我年纪越大，他越爱我。"

　　事实确实如此，她活到很老，受到女王接见，被封了爵号，再不必为金钱、名望、荣誉、地位、爱而发愁。看上去，她走了一条漫长的道路--写侦探小说，在她之前，还没有女人通过写侦探小说而成功呢。

　　我想说，有的路看上去很短，实际上走起来很难；有的路看起来很难，实际上走下去却越走越宽。可是，如果不是被逼到悬崖边上，谁肯跳下去呢？即使跳下去可能是一个更美好的世界。人，尤其是女人，总是喜欢安逸，喜欢四平八稳，喜欢不费什么力气就可以全部得到。很多时候，我们并不羡慕那些奥运冠军，认为他们太苦了，我们吃不起那些苦。我们总说，干得好不如嫁得好。其实，这是关于幸福人生一个最经典的误解。

　　许多看上去很短的路，实际上是最艰难最没有可能性的。它们不过是看上去很容易，仿佛离成功只有一步之遥，但跨越那一步，需要的不只是运气。所以，还不如咬紧牙关，把人生当作一场长途旅行，也许，当我们最终达到光辉顶点的时候，会发现周围到处都是美丽风景，不需要去巴结谁、讨好谁、迎合谁，就已经得到了想要的一切。就像伊莎朵拉．邓肯在成名以后说的那样："我得感谢上苍，因为我们小的时候母亲很穷，既养不起仆人，又请不起家教。正因为如此，我才得以自然健康地成长。"所谓自然健康，在我理解就是无论生活怎样对待她，她都一直向自己的希望努力，即使希望落空，遭受打击，依然充满信心，这使她成为一个与众不同的人，并且即使在今天依然光芒四射--我想，她也是想过要走捷径的吧？但事实上，她选择了一条看起来更艰难的路，并因此得到了更多更丰富的爱，拥有了更丰富更传奇的人生。

　　所以，假如我们不幸没有生在豪门，不幸没有既拥有美貌又拥有财富同时还很年轻，那么我们并不是真的不幸。这个世界上幸福的女人有很多，但她们决不都是年轻漂亮又富有。一个女人真的不幸并不是她们没有找到通往幸福的捷径，而是她们以为自己找到了，但却走了一辈子以后才发现，原来这条路是最远的路，且不通往任何地方……

在Windows下安装软件时，只需运行软件的安装程序（setup、install等）或者用zip等解压缩软件解开即可安装，运行反安装程序（uninstall、unware、“卸载”等）就能将软件清除干净，完全图形化的操作界面，简单到只要用鼠标一直点击“下一步”就可以了。而 Linux好象就不一样了，很多的初学者都抱怨在Linux下安装和卸载软件非常地困难，没有像使用Windows时那么直观。其实在Linux下安装和卸载软件也非常简单，同样也有安装向导或解压安装的方式，不相同的只不过是除了二进制形式的软件分发外，还有许许多多以源代码形式分发的软件包，下面就来详细地讲一讲这些软件的安装与卸载：

一、二进制分发软件包的安装与卸载
Linux软件的二进制分发是指事先已经编译好二进制形式的软件包的发布形式，其优点是安装使用容易，缺点则是缺乏灵活性，如果该软件包是为特定的硬件/操作系统平台编译的，那它就不能在另外的平台或环境下正确执行。
1、*.rpm形式的二进制软件包
安装：rpm -ivh *.rpm
卸载：rpm -e packgename
说明：RPM（RedHat Packge Manager）是RedHat公司出的软件包管理器，使用它可以很容易地对rpm形式的软件包进行安装、升级、卸载、验证、查询等操作，安装简单，而卸载时也可以将软件安装在多处目录中的文件删除干净，因此推荐初学者尽可能使用rpm形式的软件包。rpm的参数中-i是安装，-v是校验，-h是用散列符显示安装进度，*.rpm是软件包的文件名（这里的*.rpm特指*.src.rpm以外的以rpm为后缀的文件）；参数-e是删除软件包， packgename是软件包名，与软件包的文件名有所区别，它往往是文件名中位于版本号前面的字符串，例如apache-3.1.12- i386.rpm和apache-devel-3.1.12-i386.rpm是软件包文件名，它们的软件包名称分别是apache和apache- devel。更多的rpm参数请自行参看手册页：man rpm。
如果你不喜欢在字符界面下安装或卸载这些软件包，完全可以在X-Window下使用图形界面的软件包管理程序，如glint、xrpm这样的图形接口，或者是KDE的kpackge等，这样对软件包的安装、升级、卸载、验证和查询就可以通过点击鼠标来轻松完成。
2、*.tar.gz/*.tgz、*.bz2形式的二进制软件包
安装：tar zxvf *.tar.gz 或 tar yxvf *.bz2
卸载：手动删除
说明：*.tar.gz/*.bz2形式的二进制软件包是用tar工具来打包、用gzip/bzip2压缩的，安装时直接解包即可。对于解压后只有单一目录的软件，卸载时用命令“rm -rf 软件目录名”；如果解压后文件分散在多处目录中，则必须一一手动删除（稍麻烦），想知道解压时向系统中安装了哪些文件，可以用命令“tar ztvf *.tar.gz”/“tar ytvf *.bz2”获取清单。tar的参数z是调用gzip解压，x是解包，v是校验，f是显示结果，y是调用bzip2解压，t是列出包的文件清单。更多的参数请参看手册页：man tar。
如果你更喜欢图形界面的操作，可以在X-Window下使用KDE的ArK压缩档案管理工具。
3、提供安装程序的软件包
这类软件包已经提供了安装脚本或二进制的安装向导程序（setup、install、install.sh等），只需运行它就可以完成软件的安装；而卸载时也相应地提供了反安装的脚本或程序。例如SUN公司的StarOffice办公软件套件就使用名为setup的安装程序，而且在软件安装后提供反安装的功能，目前这种类型的软件包还比较少，因其安装与卸载的方式与Windows软件一样，所以就无需多讲了。

二、源代码分发软件包的安装与卸载
Linux软件的源代码分发是指提供了该软件所有程序源代码的发布形式，需要用户自己编译成可执行的二进制代码并进行安装，其优点是配置灵活，可以随意去掉或保留某些功能/模块，适应多种硬件/操作系统平台及编译环境，缺点是难度较大，一般不适合初学者使用。
1、*.src.rpm形式的源代码软件包
安装：rpm -rebuild *.src.rpm
cd /usr/src/dist/RPMS
rpm -ivh *.rpm
卸载：rpm -e packgename
说明：rpm --rebuild *.src.rpm命令将源代码编译并在/usr/src/dist/RPMS下生成二进制的rpm包，然后再安装该二进制包即可。packgename如前所述。
2、*.tar.gz/*.tgz、*.bz2形式的源代码软件包
安装：tar zxvf *.tar.gz 或 tar yxvf *.bz2 先解压
然后进入解压后的目录：
./configure 配置
make 编译
make install 安装
卸载：make uninstall 或 手动删除
说明：建议解压后先阅读说明文件，可以了解安装有哪些需求，有必要时还需改动编译配置。有些软件包的源代码在编译安装后可以用make install命令来进行卸载，如果不提供此功能，则软件的卸载必须手动删除。由于软件可能将文件分散地安装在系统的多个目录中，往往很难把它删除干净，那你应该在编译前进行配置，指定软件将要安装到目标路径：./configure --prefix=目录名，这样可以使用“rm -rf 软件目录名”命令来进行干净彻底的卸载。与其它安装方式相比，需要用户自己编译安装是最难的，它适合于使用Linux已有一定经验的人，一般不推荐初学者使用。

关于Linux下软件的安装与卸载lanche已经讲了这么多，但可能还会有人问怎么知道一个tar.gz/bz2包是二进制文件包呢还是源代码包？如果你用过压缩工具就会明白，压缩包未必就是软件，它也可能是备份的许多图片，也可能是打包在一起的普通资料，要分辨它到底是什么最好的办法就是查看包里的文件清单，使用命令tar ztvf *.tar.gz / tar ytvf *.bz2或者在X-Window下使用图形化的ArK压缩档案管理工具都可以，源代码包里的文件往往会含有种种源代码文件，头文件*.h、c代码源文件 *.c、C++代码源文件*.cc/*.cpp等；而二进制包里的文件则会有可执行文件（与软件同名的往往是主执行文件），标志是其所在路径含有名为 bin的目录（仅有少数例外）。

Acceptance testing : 验收测试
Acceptance Testing：可接受性测试
Accessibility test : 软体适用性测试
actual outcome：实际结果       
Ad hoc testing     : 随机测试
Algorithm analysis : 算法分析
algorithm：算法       
Alpha testing      : α测试
analysis：分析       
anomaly：异常       
application software：应用软件       
Application under test (AUT) : 所测试的应用程序
Architecture       : 构架
Artifact           : 工件
ASQ：自动化软件质量（Automated Software Quality）
Assertion checking : 断言检查
Association        : 关联
Audit              : 审计
audit trail：审计跟踪       
Automated Testing：自动化测试       
Backus-Naur Form：BNF范式       
baseline：基线       
Basic Block：基本块       
basis test set：基本测试集       
Behaviour          : 行为
Bench test         : 基准测试
benchmark：标杆/指标/基准       
Best practise      : 最佳实践
Beta testing       : β测试
Black Box Testing：黑盒测试       
Blocking bug       : 阻碍性错误
Bottom-up testing  : 自底向上测试
boundary value coverage：边界值覆盖       
boundary value testing：边界值测试       
Boundary values    : 边界值
Boundry Value Analysis：边界值分析       
branch condition combination coverage：分支条件组合覆盖       
branch condition combination testing：分支条件组合测试       
branch condition coverage：分支条件覆盖       
branch condition testing：分支条件测试
branch condition：分支条件 
Branch coverage    : 分支覆盖
branch outcome：分支结果       
branch point：分支点       
branch testing：分支测试       
branch：分支       
Breadth Testing：广度测试       
Brute force testing: 强力测试
Buddy test         : 合伙测试
Buffer             : 缓冲
Bug                : 错误
Bug bash           : 错误大扫除
bug fix            :  错误修正
Bug report         : 错误报告
Bug tracking system: 错误跟踪系统
bug：缺陷
Build              : 工作版本（内部小版本）
Build Verfication tests(BVTs): 版本验证测试
Build-in           : 内置
Capability Maturity Model (CMM):   能力成熟度模型
Capability Maturity Model Integration (CMMI): 能力成熟度模型整合
capture/playback tool：捕获/回放工具       
Capture/Replay Tool：捕获/回放工具       
CASE：计算机辅助软件工程（computer aided software engineering）
CAST：计算机辅助测试       
cause-effect graph：因果图       
certification        ：证明       
change control：变更控制       
Change Management  :变更管理
Change Request     :变更请求
Character Set      : 字符集
Check In           :检入
Check Out          :检出
Closeout           : 收尾
code audit        ：代码审计       
Code coverage      : 代码覆盖
Code Inspection：代码检视       
Code page          : 代码页
Code rule          : 编码规范
Code sytle         : 编码风格
Code Walkthrough：代码走读       
code-based testing：基于代码的测试       
coding standards：编程规范       
Common sense       : 常识
Compatibility Testing：兼容性测试       
complete path testing        ：完全路径测试       
completeness：完整性       
complexity        ：复杂性       
Component testing     : 组件测试
Component：组件       
computation data use：计算数据使用       
computer system security：计算机系统安全性       
Concurrency user      : 并发用户
Condition coverage    : 条件覆盖
condition coverage：条件覆盖       
condition outcome：条件结果       
condition：条件       
configuration control：配置控制       
Configuration item    : 配置项
configuration management：配置管理       
Configuration testing : 配置测试
conformance criterion： 一致性标准       
Conformance Testing： 一致性测试       
consistency        ： 一致性       
consistency checker： 一致性检查器       
Control flow graph    : 控制流程图
control flow graph：控制流图       
control flow：控制流       
conversion testing：转换测试       
Core team             : 核心小组
corrective maintenance：故障检修       
correctness        ：正确性       
coverage        ：覆盖率       
coverage item：覆盖项       
crash：崩溃       
criticality analysis：关键性分析       
criticality：关键性       
CRM(change request management): 变更需求管理
Customer-focused mindset : 客户为中心的理念体系
Cyclomatic complexity : 圈复杂度
data corruption：数据污染       
data definition C-use pair：数据定义C-use使用对       
data definition P-use coverage：数据定义P-use覆盖       
data definition P-use pair：数据定义P-use使用对       
data definition：数据定义       
data definition-use coverage：数据定义使用覆盖       
data definition-use pair        ：数据定义使用对       
data definition-use testing：数据定义使用测试       
data dictionary：数据字典       
Data Flow Analysis    : 数据流分析
data flow analysis：数据流分析       
data flow coverage：数据流覆盖       
data flow diagram：数据流图       
data flow testing：数据流测试       
data integrity：数据完整性       
data use：数据使用       
data validation：数据确认       
dead code：死代码       
Debug                 : 调试
Debugging：调试       
Decision condition：判定条件       
Decision coverage     : 判定覆盖
decision coverage：判定覆盖       
decision outcome：判定结果       
decision table：判定表       
decision：判定       
Defect                : 缺陷
defect density        : 缺陷密度
Defect Tracking       :缺陷跟踪
Deployment            : 部署
Depth Testing：深度测试 
design for sustainability :可延续性的设计     
design of experiments：实验设计       
design-based testing：基于设计的测试       
Desk checking         : 桌前检查
desk checking：桌面检查   
Determine Usage Model : 确定应用模型  
Determine Potential Risks : 确定潜在风险
diagnostic：诊断       
DIF(decimation in frequency) : 按频率抽取
dirty testing：肮脏测试       
disaster recovery：灾难恢复       
DIT （decimation in time）: 按时间抽取 
documentation testing        ：文档测试       
domain testing：域测试       
domain：域       
DTP  DETAIL TEST PLAN详细确认测试计划
Dynamic analysis      : 动态分析
dynamic analysis：动态分析       
Dynamic Testing：动态测试       
embedded software：嵌入式软件       
emulator：仿真       
End-to-End testing：端到端测试       
Enhanced Request      :增强请求
entity relationship diagram：实体关系图  
Encryption Source Code Base： 加密算法源代码库    
Entry criteria        : 准入条件
entry point        ：入口点       
Envisioning Phase     :  构想阶段
Equivalence class     : 等价类
Equivalence Class：等价类       
equivalence partition coverage：等价划分覆盖       
Equivalence partition testing : 等价划分测试
equivalence partition testing:参考等价划分测试
equivalence partition testing：等价划分测试       
Equivalence Partitioning：等价划分       
Error                 :  错误
Error guessing        :  错误猜测
error seeding：错误播种/错误插值       
error：错误       
Event-driven          :  事件驱动
Exception handlers    :  异常处理器
exception：异常/例外       
executable statement：可执行语句       
Exhaustive Testing：穷尽测试       
exit point：出口点       
expected outcome：期望结果       
Exploratory testing   :  探索性测试
Failure              : 失效
Fault                : 故障
fault：故障       
feasible path：可达路径       
feature testing：特性测试       
Field testing        : 现场测试
FMEA：失效模型效果分析（Failure Modes and Effects Analysis）
FMECA：失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis)
Framework            : 框架
FTA：故障树分析(Fault Tree Analysis)
functional decomposition：功能分解       
Functional Specification        ：功能规格说明书       
Functional testing   : 功能测试
Functional Testing：功能测试       
G11N(Globalization)  : 全球化
Gap analysis         : 差距分析
Garbage characters   : 乱码字符
glass box testing：玻璃盒测试       
Glass-box testing    : 白箱测试或白盒测试
Glossary             : 术语表
GUI(Graphical User Interface): 图形用户界面
Hard-coding          : 硬编码
Hotfix               : 热补丁
I18N(Internationalization): 国际化
Identify Exploratory Tests – 识别探索性测试
IEEE：美国电子与电器工程师学会（Institute of Electrical and Electronic Engineers）
Incident      事故    
Incremental testing  : 渐增测试
incremental testing：渐增测试       
infeasible path：不可达路径       
input domain：输入域       
Inspection           : 审查
inspection：检视       
installability testing：可安装性测试       
Installing testing   : 安装测试
instrumentation：插装       
instrumenter：插装器       
Integration          :集成
Integration testing  : 集成测试
interface            : 接口
interface analysis：接口分析       
interface testing：接口测试       
interface：接口       
invalid inputs：无效输入       
isolation testing：孤立测试       
Issue                : 问题
Iteration            : 迭代
Iterative development: 迭代开发
job control language：工作控制语言       
Job：工作       
Key concepts         : 关键概念
Key Process Area     : 关键过程区域
Keyword driven testing : 关键字驱动测试
Kick-off meeting     : 动会议
L10N(Localization)   : 本地化
Lag time             : 延迟时间
LCSAJ：线性代码顺序和跳转（Linear Code Sequence And Jump）
LCSAJ coverage：LCSAJ覆盖       
LCSAJ testing：LCSAJ测试       
Lead time            : 前置时间
Load testing         : 负载测试
Load Testing：负载测试       
Localizability testing: 本地化能力测试
Localization testing : 本地化测试
logic analysis：逻辑分析       
logic-coverage testing：逻辑覆盖测试       
Maintainability      : 可维护性
maintainability testing：可维护性测试       
Maintenance          : 维护
Master project schedule :总体项目方案
Measurement          : 度量
Memory leak          : 内存泄漏
Migration testing    : 迁移测试
Milestone            : 里程碑
Mock up              : 模型，原型
modified condition/decision coverage：修改条件/判定覆盖       
modified condition/decision testing        ：修改条件/判定测试       
modular decomposition:参考模块分解
Module testing       : 模块测试
Monkey testing       : 跳跃式测试
Monkey Testing：跳跃式测试  
mouse over：鼠标在对象之上
mouse leave：鼠标离开对象    
MTBF：平均失效间隔实际（mean time between failures）
MTP    MAIN TEST PLAN主确认计划
MTTF：平均失效时间        （mean time to failure）
MTTR：平均修复时间（mean time to repair）
multiple condition coverage：多条件覆盖       
mutation analysis：变体分析       
N/A(Not applicable)  : 不适用的
Negative Testing     : 逆向测试, 反向测试, 负面测试
negative testing:参考负面测试
Negative Testing：逆向测试/反向测试/负面测试  
off by one：缓冲溢出错误    
non-functional requirements testing:非功能需求测试
nominal load:额定负载
N-switch coverage：N切换覆盖       
N-switch testing：N切换测试       
N-transitions：N转换       
Off-the-shelf software : 套装软件
operational testing：可操作性测试       
output domain：输出域
paper audit:书面审计      
Pair Programming     :  成对编程
partition testing：分类测试       
Path coverage        :  路径覆盖
path coverage：路径覆盖       
path sensitizing：路径敏感性       
path testing：路径测试       
path：路径       
Peer review          :  同行评审
Performance          :  性能
Performance indicator:  性能（绩效）指标
Performance testing  :  性能测试
Pilot                :  试验
Pilot testing        :  引导测试
Portability          :  可移植性
portability testing：可移植性测试      
Positive testing     :  正向测试
Postcondition        :  后置条件
Precondition         :  前提条件
precondition：预置条件       
predicate data use：谓词数据使用       
predicate：谓词       
Priority             :  优先权
program instrumenter：程序插装       
progressive testing：递进测试       
Prototype            :  原型
Pseudo code          :  伪代码
pseudo-localization testing：伪本地化测试
pseudo-random：伪随机       
QC：质量控制（quality control）
Quality assurance(QA):  质量保证
Quality Control(QC)  :  质量控制
Race Condition：竞争状态       
Rational Unified Process(以下简称RUP):瑞理统一工艺
Recovery testing     :  恢复测试
recovery testing：恢复性测试       
Refactoring          :  重构
regression analysis and testing：回归分析和测试       
Regression testing   :  回归测试
Release              :  发布
Release note         :  版本说明
release：发布       
Reliability          :  可靠性
reliability assessment：可靠性评价       
reliability：可靠性       
Requirements management tool: 需求管理工具
Requirements-based testing : 基于需求的测试
Return of Investment（ROI）: 投资回报率
review：评审       
Risk assessment      :  风险评估
risk：风险       
Robustness           :   强健性
Root Cause Analysis(RCA): 根本原因分析
safety critical：严格的安全性       
safety：（生命）安全性       
Sanity testing       :   健全测试
Sanity Testing：理智测试       
Schema Repository    :   模式库
Screen shot          :   抓屏、截图
SDP：软件开发计划（software development plan）
Security testing     :   安全性测试
security testing：安全性测试       
security.：（信息）安全性       
serviceability testing：可服务性测试       
Severity             :   严重性
Shipment             :   发布
simple subpath：简单子路径       
Simulation           :  模拟
Simulator            :  模拟器
SLA(Service level agreement): 服务级别协议
SLA：服务级别协议（service level agreement）
Smoke testing        :   冒烟测试
Software development plan(SDP): 软件开发计划
Software development process: 软件开发过程
software development process：软件开发过程       
software diversity：软件多样性       
software element：软件元素       
software engineering environment：软件工程环境       
software engineering：软件工程       
Software life cycle  :   软件生命周期
source code：源代码       
source statement：源语句       
Specification        : 规格说明书
specified input：指定的输入       
spiral model        ：螺旋模型       
SQAP   SOFTWARE QUALITY ASSURENCE PLAN 软件质量保证计划
SQL：结构化查询语句（structured query language）
Staged Delivery：分布交付方法
state diagram：状态图       
state transition testing        ：状态转换测试       
state transition：状态转换       
state：状态       
Statement coverage   : 语句覆盖
statement testing：语句测试       
statement：语句       
Static Analysis：静态分析       
Static Analyzer：静态分析器       
Static Testing：静态测试       
statistical testing：统计测试       
Stepwise refinement  : 逐步优化
storage testing：存储测试       
Stress Testing       : 压力测试
structural coverage：结构化覆盖       
structural test case design：结构化测试用例设计       
structural testing：结构化测试       
structured basis testing：结构化的基础测试       
structured design：结构化设计       
structured programming：结构化编程       
structured walkthrough：结构化走读       
stub：桩 
sub-area：子域     
Summary：  总结
SVVP  SOFTWARE Vevification&Validation  PLAN： 软件验证和确认计划
symbolic evaluation：符号评价       
symbolic execution:参考符号执行
symbolic execution：符号执行       
symbolic trace：符号轨迹       
Synchronization      : 同步
Syntax testing       : 语法分析
system analysis：系统分析       
System design        : 系统设计
system integration：系统集成       
System Testing       : 系统测试
TC   TEST CASE 测试用例
TCS  TEST CASE SPECIFICATION 测试用例规格说明
TDS   TEST DESIGN SPECIFICATION 测试设计规格说明书
technical requirements testing：技术需求测试       
Test                 : 测试
test automation：测试自动化       
Test case            : 测试用例
test case design technique：测试用例设计技术       
test case suite：测试用例套     
test comparator：测试比较器       
test completion criterion：测试完成标准       
test coverage:测试覆盖       
Test design          : 测试设计
Test driver          : 测试驱动
test environment:测试环境       
test execution technique:测试执行技术       
test execution:测试执行       
test generator:测试生成器       
test harness:测试用具       
Test infrastructure  : 测试基础建设
test log:测试日志       
test measurement technique:测试度量技术
Test Metrics :测试度量      
test procedure:测试规程       
test records:测试记录       
test report:测试报告       
Test scenario        : 测试场景
Test scrīpt.:测试脚本       
Test Specification:测试规格       
Test strategy        : 测试策略
test suite:测试套       
Test target          : 测试目标
Test ware             :  测试工具
Testability          : 可测试性
testability:可测试性       
Testing bed          : 测试平台
Testing coverage     : 测试覆盖
Testing environment  : 测试环境
Testing item         : 测试项
Testing plan         : 测试计划
Testing procedure    : 测试过程
Thread testing       : 线程测试
time sharing:时间共享       
time-boxed           : 固定时间
TIR    test incident report    测试事故报告
ToolTip:控件提示或说明
top-down testing:自顶向下测试       
TPS TEST PEOCESS SPECIFICATION 测试步骤规格说明
Traceability         : 可跟踪性
traceability analysis:跟踪性分析       
traceability matrix:跟踪矩阵       
Trade-off            : 平衡
transaction:事务/处理 
transaction volume：交易量   
transform. analysis:事务分析       
trojan horse:特洛伊木马       
truth table:真值表       
TST  TEST SUMMARY REPORT 测试总结报告
Tune System : 调试系统
TW TEST WARE :测试件
Unit Testing         :单元测试       
Usability Testing:可用性测试       
Usage scenario       : 使用场景
User acceptance Test : 用户验收测试
User database        :用户数据库
User interface(UI)   : 用户界面
User profile         : 用户信息
User scenario        : 用户场景
V&V (Verification & Validation) : 验证&确认
validation           :确认       
verification         :验证       
version              :版本       
Virtual user         : 虚拟用户
volume testing:容量测试  
VSS（visual source safe） ：
VTP   Verification  TEST PLAN验证测试计划
VTR  Verification TEST REPORT验证测试报告
Walkthrough          : 走读
Waterfall model      : 瀑布模型
Web testing          : 网站测试
White box testing    : 白盒测试
Work breakdown structure (WBS) : 任务分解结构
Zero bug bounce (ZBB) : 零错误反弹

      为什么不把面试看成是一场难得的对话？试着更多地把自己定位为一个前来学习人生和工作经验的学生，而面试官作为一个愿意与你分享关于工作、职业发展和 人生经验的前辈。你会发现，抱着这种心态，面试压抑的气氛在不知不觉中从一问一答，而慢慢地变成了一个双向的交流。事实上，甚至应该这么说，能够和杰出的 职场人士如此平等、轻易地交流（特别是想到这些人将来可能会是你好几个级别以上的老板时），面试真是再理想不过的一个机会了。
      对于那些平日忙于在商业世界里打拼的面试官们来说,有机会回想到自己的过去，见到一张张写满渴望、勇气的脸庞，为什么不和眼前的这个看上去聪明、可爱和善解人意的孩子聊聊自己的过去，指点一下他未来的发展，多获得一些崇敬的目光呢？他们当然会这样做，只要你给他们机会。
      对于任何一个富有远见的组织来说，招揽到出色的人才，无论对于公司还是其他机构，都是成功地完成自己的使命的基础。面试对于公司的意义在于，提供一个认识 候选人的机会，从而在此基础上判断，谁是更加适合公司需要的人才。尽管，每家公司的面试组织程序会有所不同，但是它们还是有基本相同的先后顺序。了解这些 基本的程序，能够帮助面试者减少对面试的神秘感，增加信心，更好地设计自己的面试策略。
通常面试程序可以被分成以下几个部分：
　　（1）确定所需要招聘的职位的工作描述、薪酬范围和应聘者所需要的资格。
　　（2）通过招聘会、海报、广告等形式，把招聘信息传达给潜在的应聘者。
　　（3）收集应聘者的简历，筛选简历得到可以进一步面试的合适数量的应聘者。
　　（4）电话面试。一般由人力资源部门或者资历比较浅的分析员或者咨询员打来，在面试中进一步确认应聘者的背景、语言表达能力等。通过筛选得到可以进一步面试的合适数量的应聘者。
　　（5）第一轮面试。
　　（6）第二轮面试。
　　（7）确定入选的候选人，人力资源部门和他们保持联系，推销公司，确保他们接受合同。同时，公司也可能继续和几个作为万一“正选”拒绝接受要约后的“后备”候选人保持“暧昧”的关系。
　　（8）人力资源部最后检查应聘者的背景、提供的材料无误。

　    你在申请公司的时候不一定会经历所有的程序。比方说，电话面试往往只是那些非常强调英语口语能力的外企才有的步骤，他们希望借此道程序排除一部分口语能力不强的应聘者，国企、私营企业或者政府机关，基本上不会有这道门槛。
        爱因斯坦曾经这样对年轻学生解释过相对论：当你和一个美丽的姑娘坐上两个小时，你会感到好像坐了1分钟；但要是在炽热的火炉边，哪怕只坐上1分钟，你却感到好像是坐了两小时。
　 　  同样，面试可能是世界上最漫长的30分钟，也可能是世界上最短暂的30分钟。当你和你的面试官都有一种频频想看表的冲动时，抱歉，你的这场面试看起来是 失败了。而当你走出面试间，一低头看表，发现不知不觉地已经超出了30分钟时，这往往是证明你刚才的面试进行得很顺利。
　　   一个面试官就曾经告诉我，当他在面试开始5分钟后，就决定不可能给这个应聘者任何机会的时候，他恨不得立刻就结束这场面试。但是，他不能，因此，他只好盯着手表，等到刚过25分钟的时候，立刻开始问应聘者：你还有什么问题吗？
       对你而言，控制时间和节奏成为了和给出好的答案同样重要的任务，如果前者不是更重要的话。有几个重要的原则你必须记住：
（1）你必须努力掌握对节奏的控制权，而不要把它交给你的面试官。
　　 如果你回答问题总是拖沓冗长、毫无逻辑也看不出什么时候能结束，面试官会不得不总是打断你的回答：“我明白你的意思了，那么，下一个问题是……”这种被打断回答的情况往往会带来紧张，出现几次，你就会发现清晰的思维和顺畅的表达就这样被打断了。
　　 所以，千万不要给面试官这种机会。通常情况下，只要你把握得当，他们也并不会主动地抢。
　 　 然而也有这样的面试，面试官无意或者故意地不断打断你的回答，试图获得面试节奏的控制权。那么，在这种情况下，你必须保持冷静，努力地把节奏感再抢回 来。你可以在面试官突然打断你的回答，插入一个问题时，有意识地保持10秒钟的沉默，装作在思索这个问题，实际上是在冷静，找回自信和节奏，然后用一种和 刚才回答问题不同的语速重新开始。还有的时候，当你觉得你是在回答到关键时刻被打断的话，不要就此罢休，你应该在回答被打断之后的新问题前，有礼貌地说： “在我回答这个问题之前，我觉得我应该对刚才那个问题的回答补充一点……”然后尽快完成你刚才没有机会完成的观点。

（2）永远不要在一个问题上纠缠太久。
　 　 这15分钟，或者说整个面试，就是一张你无法先看到整张试卷的试题，有点像GRE的机考，更糟糕的是，你实际上连每道题的分值都不知道。在面试的时候， 你不知道你在努力地向面试官说清楚的那个复杂的问题究竟能给你增加多少分，而你花了七八分钟在这个问题上，也可能下一个问题对你来说既简单、分数又多。所 以，当一个问题开始出现你很难说清的情况时，不要纠缠太久，简单地说：“关于这个问题，我想我现在只能说出这么多了。”让面试向你的下个机会走去。

（3）在15分钟内取得尽量多的共识。
　　 在一般情况下，面试官不是来寻找一个永远的“持异议者”的。当你在回答一些关于观点、价值、方法方面的问题时，你会发现，也许经常会出现面试官频频点头，或者他面无表情，甚至摇头的情况。点头很大程度上说明你们的共识，而通常，共识比异议更容易给你的表现加分。
　　 熬过了这15分钟后，接下来是你最后的机会了。面试官通常会问你有没有任何问题问他。永远别说没有，除非他之前告诉你他已经决定录用你了。最后的问题可能毁了你之前的所有的努力，也可能把你从一场失败的面试中挽救回来。
　　 然而想出一个好的、最后的问题往往比准备一个好的自我介绍还要难。有的时候，你希望通过一个好的问题，让人对你刮目相看。但是通常你会发现，更容易的是问一个面试官有话可回答的问题，然后你加上几句评价，把这个面试画上句号。
　 　 如果你之前的面试进行得都很顺利的话，在最后一个问题上应该保守一些，只要不犯错误就行。所以你可以问问面试官怎么走进这一行的，怎么看待这一行等等。 如果你之前的面试感觉不佳，你希望通过最后一个问题来绝地反击的话，你不妨问面试官一个让他给你出主意的问题，顺带着你可以说出一个你没有来得及在面试中 提起的卖点，加深面试官对你正面的评价。
　　 比方说，我知道的一个聪明的问题，我的一个好朋友明白自己在面试中的英语口语能力令面试官一 直表现得对她缺乏兴趣，于是她最后问道：“您知道，我在高中的时候一直是学俄语的，进入大学后我才从ABC开始学英语，现在刚刚学了3年。虽然我已经可以 在托福考试中取得630分的成绩，但我知道我的英语口语还需要很大的提高，您能在这方面给我一些好的指点吗？”
　　 那位香港长大、哈佛毕业的面试官立刻有些羞涩地说：“不、不，你的英语已经很让人满意了。我是中国人，我的中文说得还没有你的英文好。你只学了3年就已经这么好了，应该是你给我一些指点。”
　　 结果，这个只学了3年英语的女孩子击败了其他学了十几年英文、口语比她好得多的竞争者——我觉得她就只用了这最后一个问题即确定胜势。

本文出自zte_boy的51Testing软件测试博客，转载请保留出处及链接：http://www.51testing.com/?161787

从事了几年测试工作，也着实见证了测试的发展，如今测试行业对从业者的要求是越来越高，不再仅仅局限于要求会写测试用例、会细致的执行测试、能有效的发现系统缺陷等；越来越多的企业对应聘者本身的技能要求也越来越高，招聘信息中诸如“精通VBscrīpt、Perl/Rbuy等至少一门脚本语言”、“至少熟悉一门开发语言”、“精通QTP、LR等自动化测试工具”、“有大型项目自动化实施成功经验”此类的字眼也逐渐增多。目前看来，除白盒测试内容和测试管理外，主流的方向有两个：功能自动化测试和性能测试。这就要求从业人员能够在短时间内快速的掌握这些知识，才能获取到更好的工作机会。本人是名功能自动化测试的工程师，以自己学习、工作的过程结合QTP讲讲该如何学习自动化测试

首先，想从事自动化测试，必须先了解What/Why/How，也就是常说的去了解什么是自动化测试、为什么要进行自动化测试、该如何进行自动化测试，这类的资料在网上有很多，这里就不做重复了

其次，需要根据项目的特点，选择合适的自动化测试工具，并了解工具的特性。以QTP为例，该如何去掌握它呢？对于初学者，大多数都是通过录制的方式来生成脚本，这个阶段应该掌握的基础知识有

1)      QTP是如何去识别对象的，对于新手经常会出现录制的脚本回放的时候报错的现象，这个时候就应该考虑为什么呢？如果很了解QTP识别对象的原理啊，我想就能很快定位到原因了

2)      去掌握一些QTP对象的方法，如GetROPreperty、GetTOPreperty、ChildObjects等等，对于相似的方法应该去搞清楚到底区别在哪？像GetROPreperty、GetTOPreperty有什么区别等

3)      什么是Action参数、什么又是Test参数？两者有什么区别，又有什么联系，在同一Test和不同Test间这些参数如何工作

4)     什么是环境变量？环境变量是如何建立和使用的，环境变量在参数传递中和action参数、test参数有什么不同

5)     了解检查点的知识，明白什么是内置检查点，什么又是自定义检查点。并搞清楚在什么时候该如何使用检查点

6)     掌握对象库的操作，了解对象库对于测试的意义，象是否启用智能识别对测试脚本有何影响、为什么同一对象识别起来会有_1、_2之类的后缀等都是需要去研究清楚的问题

这几个问题都搞清楚的话，那基本就能够利用QTP生成正确的脚本了，当然以上只是部分必须掌握的内容，其实还是很多细节的设置，就需要在实际运用中去掌握了

接下来，就可以进一步提升自己的QTP运用水平了，这个阶段就需要去学习vbs知识和如何运用描述性编程实现脚本了，同时在这个过程中还需要去学习html知识、DOM、XML、以及像excel、word等的API知识了，总的来说，这个阶段应该掌握的内容大体上包括

1)     VBscrīpt的基础知识，熟悉常用的方法和函数，掌握文件对象的操作等

2)     熟练掌握XML技术；excel、word等API对象，可以根据需要创建日志等

3)     熟练掌握DOM和HTML知识，能够结合这些技术对Web页面进行解析

4)     掌握数据库的基本操作语句，能够利用ADO对象进行数据操纵

5)     熟练掌握正则表达式，很多时候处理对象问题相当方便

6)     掌握如何调用dll进行工作

7)     能够利用QTP的自动化对象模型创建出需要的运行模式

8)     掌握WMI知识

以上只是我考虑到的部分，并不全面，呵呵，供大家参考，当然这些技术主要是针对Web系统运行，因为我们的系统就是B/S的，呵呵。如果这些知识都能够扎实的掌握的话，个人认为，基本上能够处理自动化过程中的绝大多数问题了，这个时候你对自动化测试的技术应该是有一定积累了

接下来就需要考虑自动化测试框架问题了。当脚本规模到了一定的程度，就会面临一些问题，如：

1)       如何有效的管理并调度脚本

2)     如何实现脚本运行的无人值守，测试过程中能够自动进行错误处理并进行日志记录

3)     如何生成简介明确的测试报告

4)     如何能够更加高效的维护测试脚本

5)     实现框架代码和业务代码的分层、业务脚本和业务数据的分离

这个阶段主要体现的是测试人员的测试思想，是可以脱离工具独立存在的过程。当然各个公司项目的实际情况不同，导致设计出来的思想不同，但总体上来说一般包括数据驱动和关键字驱动两种模式。后者实现的技术难度大于前者，大多数公司目前都采用的数据驱动模式。这个阶段不应局限于技术运用上，而需要从测试全局考虑，进行分层设计、模块化实现，减少代码之间的耦合

如果以上三个方面都能够做的很好的话，那么恭喜你，你已经可以独立负责项目的自动化测试建立工作了，呵呵！

总之，学习自动化测试需要在实际项目中进行，这样提高的会比较快，项目中运用了很多种技术，自动化实施过程会碰见各种各样的问题，是很好的学习机会，关键要善于总结、积累经验，只要能够把各个细节做好，那么你一定能够成为一名优秀的自动化测试工程师

Linux下常用网络配置命令

2007-12-29 15:44:10 / 个人分类：开发路上拾贝

看到许多媒体都在争相炒作测试工程师—这一“黄金”职业，我有些不同的看法。以下的内容是从网站上摘录的一段信息：

随着国内IT企业对软件测试的重要性的日益了解，软件测试人才岗位的薪资待遇也稳步提升。据了解，刚入门的软件测试工程师薪水一般在3000-5000元左右，工作2-3年年薪普遍在10-15万之间。即便如此，很多企业仍然难以招到适合的人才。“我现在要是公布招聘10个软件开发人员，会来几百人投简历；如果我说招聘一名软件测试工程师，应聘者就会少很多。” 北京红旗中文贰仟软件技术有限公司总经理胡才勇不由感慨。智联招聘等招聘网站甚至撰文称“从入门级的初级测试工程师到高级测试工程师及项目负责人全线短缺。” 套用狄更斯那句话说：对于急需软测人员的企业来说，这是一个最坏的时代，但对软件测试人才来说，这是一个最好的时代。

之所以摘录以上信息，不是针对这段信息本身有什么不同的观点，而是想要说明一位想从事软件测试行业的人或正在从事初级测试岗位的人员如何月薪可以拿到年薪１０－２０万。

无论是你想升职还是想要加薪，首先必须要分析一下公司给员工升职和加薪的原因。我想这方面大家都是清楚的，但是好像操作起来又非常的模糊。谁都知道要升职或加薪就是要干的比别人好，要为公司创造比别人更多的价值，节约更多的资金和成本......但是如何做到这些呢，恐怕就没有什么特别行之有效的方法了。其实这个问题以前也困扰了我许久。

记得当时最开始从事开发工作时，薪水才1.2k，现在虽然听起来少的可怜，但是十几年前自己还是挺满足的。所以工作的时候也就特别卖力，总是老板或主管要求的事情，一定要尽全力做好，老板和主管没有要求的，如果觉得对公司有帮助，也会主动去做。所以很快我就被提为小组长，当然薪水也涨到了2K。当时其实我的技术并不是我们组里最好的，所以有好多人都不服气，我也知道自己的不足，所以就二话不说，赶紧补呗，没过两个月就奠定了巩固的地位。 由此我获得了升职和加薪的第一个方法：那就是不仅要做好你该做的事情，还要尽量去做对公司有益的事情！这样在公司做了快两年的时间，后来因为老板要移民所以只能关掉公司，不过老板对我们还是不错的，都提前和我们员工打好了招呼，让我们先去找工作，然后等我们都安顿好了，他才把公司关掉的。

后来就去了一家美国公司，这是加薪的第二种方法—“成功”跳槽！请注意不是每一次普通的跳槽都可以使你的工资翻倍的，只有你在前一家企业确实为公司做出过真正的贡献，那么以后的跳槽才会被新的东家所欣赏。所以我强烈建议目前在公司工作的兄弟姐妹们一定要随时留心，随时积累工作心得，最好有一些真实客观的数据（比如目前您所测试的项目中，您个人所发现的缺陷占到整个团队发现缺陷的比率是多少？您个人发现的对公司最有价值的缺陷是什么？.......）说明您为上家公司所作的贡献是什么，无论是技术上的，还是管理上的，都最好有一些客观的数据证明。所以工作过程中处处积累，处处留心才能为您以后的成功跳槽打好基础，而不是等到新东家面试您的时候，您才拼命的“回忆”自己的光辉业绩，那不容易让人家信服的！

在这家美国公司里，技术的长进不是特别大，但是毕竟是外企，所以对自己“英语”能力的锻炼可就提供了非常好的机会。虽说是六级，但是没进这家公司之前，根本就没说过外语。所以刚进去的时候，我和老外主管沟通真是挺费劲的，不过没关系，还是老办法—补呗！二话不说，没过一个月，我的经理就夸我有很大的进步。过了英语关，我的工作也更如鱼得水了，而且公司让我负责与美国那边的客户沟通，尤其是针对客户提出的问题进行一些软件功能检查。由于客户评价很好，所以我又一次得到了升职和加薪的机会，这使我又获得了一个新的方法—想尽一切办法为公司的“客户”提供最好的服务！

就这样一路走来，从开发转到测试再到负责公司的过程改进，做了不少的角色，但是等到薪资想要超越更多一些的时候，发现没有什么好的方法可以让我迈过这个坎，因为在公司工作的过程中，总是自己在指导别人如何做事，但其实自己做事的过程中，尤其是技术方面，也有许多不到位的地方，但是总也是找不到特别有效的解决方案。总是一个项目接一个项目的忙碌，有一次同时负责4个项目，真觉得分身乏力！郁闷了好久，不知道下一步该怎么走，一个项目一个项目的做，同样的问题反复出现，丝毫没有好的解决方案.....当时我曾经有想法改行，不做技术了，想去做销售！因为无法突破自己的瓶颈。

直到“撞”到了51tesing，（之所以说是撞到了51tesing，是因为当时其实只是打算做一名兼职老师，挣点外快就行了，并没有打算留下来。）。遇到了我测试生涯中的三个贵人，也是我现在的老板和上司—周峰老师、王威老师和朴老师，但是我们都尊敬的称他们为老师（这也是我们51testing的一种文化吧，无论是领导还是同事之间，大家都以老师相称）。他们给了我许多指导，让我看到了自己在技术上的不足，也通过教学的环节，让我把自己的所得与大家共同分享，使我终于明确了自己的发展方向，突破自己的瓶颈的同时又获得最重要的一个法宝—适时地停下来，总结自己，与更多的人分享，才能更快的提高自己！

就像我们说宝马车和普通车的区别，其实不在于宝马车比普通车跑得更快，最大的区别是当时速过百时，宝马车可以随时稳定的“叫停”，但是其他的车就完全不听指挥了。

所以如果大家想要获得更好的加薪和升职的机会，首先要脚踏实地的认真高效做事，无论老板有没有盯着你，记着这是为“自己工作！”，绝不是为老板工作，只有自己的能力提高了，为公司创造了真正的价值，才会有更多更好的机会迎接你！同时别忘记在工作过程中一定要不断地充电学习，找一个优秀、无私的“教练”是成功的关键，否则自己很难突破的，起码短时间内是绝对不可能的！最后就是要适时地停一停，对以前的自己好好总结一下，才能为第二次腾飞作好充分的准备！

-------------原创-------

测试人员设计测试用例首先得了解什么是测试用例，测试用例在测试工作中是干什么用的，怎么根据需求采用怎样的测试方法设计测试用例。

 

一、测试用例的定义

对测试用例的概念大家都很清楚，我把定义写出来放在这里好像是多余的请别笑话，毕竟多温习一下以前的知识比什么都好。

测试用例(test case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求（测试用例的定义）。

比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容/要素包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。根据我在网上查找的资料了解到测试用例可分为正面测试用例和负面测试用例：

一个测试用例用于证明该需求已经满足，通常称作正面测试用例(个人理解是直接可以验证需求的测试用例，不需要任何外界测试环境/条件所支配)；

另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例（在现实测试中这样的负面测试用例好像用的多些）。

 

二、测试用例的作用

       在我们测试工作中，当拿到一个CQ，首先得明白需求提交人提交这个需求的目的是让我们测试人员测试哪些功能点、测试源在哪？然后我们才能根据测试需求准备测试环境/数据，编写测试计划/测试用例、执行测试用例、测试风险评估、提交测试报告和结论单等。而在这些测试工作流程中最重要的就是设计测试用例拉，因为测试用例的数量与测试的“深度”成比例，也与软件的质量保障成正比；设计好的测试用例也是衡量一位测试工程师测试水平的重要依据，不管是功能黑盒测试还是自动化测试（也包括性能测试），上次开会苑海林讲的就很清楚了。因此我们可以这么说设计测试用例是软件测试的核心工作，更是软件测试质量保障的根本。

 

三、设计（黑盒测试）测试用例的方法

       我们都知道黑盒测试的方法主要有等价类划分、边值值分析、因果图、错误推测等(正交试验法、场景法)，其中最重要的就是等价类划分和边界值分析。当我们拿到一个需求怎么才能利用这样的测试方法设计测试用例呢？

1.等价类划分

       使用等价类划分方法时完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。比如有一次国航开发小组提交过来的需求中提到“旅客提前15天（含）订票的可以享受2.5折的优惠；提前30天（含）订票的旅客可以享受2折的优惠”。

 

————根据此需求我列了一个关于设计该测试用例的等价类列表：

X代表旅客订票所提前天数

 

 

根据列出的等价类列表，重点分析等价类情况3和情况4。

1.      针对情况3，然后选取有代表性的提前天数进行订票测试：比如提前16天订票、提前25天订票、提前26天订票；

2.      针对情况4，选取有代表性的天数进行订票测试：比如提前45天订票、提前60天订票、提前75天订票、提前100天订票等等数据输入；

设计这样的测试用例是很不完整的，因为它还没有使用边界值分析法对等价类/需求进行分析。由测试工作经验得知，大量的BUG是在输入范围的边界上被发现的，而不是在输入范围的内部。

 

2.边界值分析法

边界值分析法是对等价类划分方法的补充。它不是从一个等价类中任选一个例子作为代表，而是将等价类的边界作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。

还是使用上面的等价类列表利用边界值分析方法继续设计没有完成的测试用例：

3.      针对情况3（15天<=X<30天），找出此等价类的边界值为提前15天、29天、30天，和无效输入边界值提前14天的情况设计测试用例。使用有效边界值提前天数订票，是否能订到折扣为2.5折的机票；

4.      针对情况4（X>=30天），找出此等价类的边界值为提前30天，和无效输入边界值提前29天的情况设计测试用例。使用有效边界值提前天数订票，是否能订到折扣为3折的机票；

分析到这里，设计出来的测试用例才算是一个完整的用例，但是这只仅仅覆盖了测试需求，还需要我们做其他兼容性测试充实测试用例。

 

我们有时候设计测试用例时只考虑边界值的情况，不考虑等价类的情况，或者只考虑等价类的情况，不考虑边界值的情况，这都是不对的，设计的测试用例也是不完整的，这是对产品质量不负责任的表现，同时也说明了测试人员的水平。

11.专业词语解释

α测试:

Alpha测试（α测试）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。

β测试

Beta测试（β测试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是 在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。

驱动模块:

驱动模块在大多数场合称为"主程序"，它接收测试数据并将这些数据传递到被测试模块.单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此  写驱动

驱动模块主要完成以下事情：
1、接受测试输入；
2、对输入进行判断；
3、将输入传给被测单元，驱动被测单元执行；
4、接受被测单元执行结果，并对结果进行判断；
5、将判断结果作为用例执行结果输出测试报告。

桩模块

比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的错误，定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。

白盒测试

白盒测试(White-box Testing，又称逻辑驱动测试,结构测试),它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。

静态测试

动态通过评审文档、阅读代码等方式测试软件称为静态测试,通过运行程序测试软件称为测试.在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.

12、 回归测试

回归测试的目的是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。
说白了就是，我们测试人员在对程序进行测试时发现bug，然后返还程序员修改，程序员修改后发布新的软件包或新的软件补丁包给我们测试人员，我们就要重新对这个程序测试，已保证程序在修正了以前bug的情况下，正常运行，且不会带来新的错误的这样一个过程。  一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。

13、单元测试、集成测试、系统测试的侧重点是什么？

单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。

14、设计用例的方法、依据有那些？  

白盒测试用例设计有如下方法:基本路径测试\等价类划分\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构

黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。

转载了一篇，简洁明了，来自前辈“人月神话”的blog。谨致谢意！

************************************************************************************

 

01.为什么要在一个团队中开展软件测试工作？
保证软件质量的最后一道关口。

02.您是否了解以往所工作的企业的软件测试过程？如果了解，请试述在这个过程中都有哪些工作要做？分别由哪些不同的角色来完成这些工作？
测试计划->测试设计(测试用例，测试数据)->测试执行(单元测试，集成测试，系统测试，回归测试)

03. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
易用性测试-界面的友好性，操作方便性等。
功能测试-系统中功能性需求的满足
安全性测试-系统是否存在安全隐患和漏洞
性能测试-系统在大并发下的响应速度和健壮性

04.请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
黑盒/白盒:主要区别在是否了解系统或程序的内部结构和代码
单元测试:关注某一个单元，函数，模块的正确性，一般需要编写相关测试代码。
集成测试:模块或模块直接的集成接口测试，单个模块测试
系统测试:一个完整功能的完全测试。

05.测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
提前安排出测试工具选择，测试类型选择，人员需求，保证和项目开发协调一致，保证测试工作顺利进行。

06.您认为做好测试计划工作的关键是什么？
了解项目或系统的业务需求
和项目经理协调好，了解项目的进度计划安排情况

07.您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
边界值/等价类/业务流程图分析和状态转换分析/业务逻辑分析

08.您认为做好测试用例设计工作的关键是什么？
对业务和软件需求非常清楚，可以根据需求不同选择不同的测试用例设计

09.您以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述测试用例评审的过程和评审的内容。
评审计划->预审->评审;
评审内容主要是测试用例对软件需求的覆盖程度，对于相关边界是否考虑，是否针对复杂流程准备多套测试数据，是否有专门针对非功能性需求的测试。

10.您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。
制订计划->选择测试功能->选择测试工具->录制脚本->运行测试->分析结果

11.您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
微软WAS,LoadRunner

12.您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
关键是测试脚本的录制，测试时候测试环境的干净。

13.在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
缺陷名词/描述/缺陷等级/严重程度/发现模块/发现步骤和过程/是否可以重现

14.您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，请结合该工具描述软件缺陷（Bug）跟踪管理的流程。
CQ，也可以使用BugFree等免费工具。

15.您如何看待软件过程改进？在您曾经工作过的企业中，是否有一些需要改进的东西呢？您期望的理想的测试人员的工作环境是怎样的？
将先进的经验或思想固化到过程中，通过过程改进和能力提高来改进软件质量。

在LoadRunner中用web_reg_save_param()做关联

 

LoadRunner中有两种关联方式，一种是手动关联，一种是自动关联。一般情况下我都是如下做关联的。

1、  录制并调整好脚本以后直接回放脚本，用LoadRunner的Find Correlations查找需要关联的地方，根据情况点Correlation或Correlation All，进行关联即可。这种方式有时候不能全部找到需要关联的地方，所以还需要手动关联的支持。

2、  手动关联也可以用两种方法进行：

（1）一种方法是录制两份相同的脚本，用LoadRunner自带的Diff工具查找需要关联的地方，然后手动进行关联；

Tools --->Compare with Vuser，选择脚本进行比较，查找需要关联的地方，然后再手动关联。

（2）另一种方法是基于你对程序比较熟悉的情况下进行的，可根据查看录制的scrīpt脚本，结合源代码来进行查找，找到后用web_reg_save_param（）函数做关联即可。我一般采用这种方法。不太确定的就找开发人员询问，比用diff工具要方便的多，(*^__^*) 嘻嘻……

3、结合实例分析如何用用web_reg_save_param()做关联

最近在测试一个邮件系统，邮件系统中有一个FolderId是一个隐含变量，<input type=”hidden” name=”folderId” value=”PNKpUfAKVrgn”/> 这个Value值会在程序中被带入不同的页面，并且该值是根据登录用户的变化而变化的，所以这个Value值就需要关联。此时可以这样进行：

（1）     进入Tree View模式，在Server Response处选择该值，右键选择Create Parameter，弹出一个是否确认替代的对话框，选择【是】即可完成。

（2）       或者在scrīpt View模式下，自己手动写，不过因为web_reg_save_param()函数是一个注册型函数，所以需要写在需要关联的语句前面。

4、  关于web_reg_save_param()函数

函数原型：int web_reg_save_param (const char *ParamName, <List of Attributes>, LAST);举例：   web_reg_save_param("folderIdValue",

       "LB= value=￥"", "RB= ￥"", "Search=Body",

LAST);

LB:左边界

RB:右边界

Search：搜索范围：All 、Header、Body

关联应用：

web_submit_data("login.pl_2",

"Action=http:// {webUrl}/mercuryWebTours/login.pl",

"Method=POST",

"TargetFrame=",

     "RecContentType=text/html",       "Referer=http://{webUrl}/mercuryWebTours/nav.pl?folderId={folderIdValue }", 

LAST);

这样在运行的时候就可以根据不同用户改变folderId了。