qileilove

　　1、对于新产品和维护版的老产品设计的用例应该注意些什么呢？

　　专家分析：新项目和维护项目从本质上看没有区别，维护产品，无非就是新增功能和缺陷修复两大类，和新项目相比，唯一需要注意的就是新增\修复的功能是否对其他部分有影响，这里就涉及到一个回归策略的问题——老功能要测多少。一般来说，需要和开发讨论确定受影响的范围，然后制定测试范围。当然最理想的情况就是整个系统全测，因为一旦系统复杂了，没有哪个开发能说清楚影响范围。

　　专家建议：“新产品”在了解需求的情况下，先设计测试用例，再测试，避免发生遗漏。“老产品”维护，若改变了需求，依然先设计（修改）测试用例，再测试，避免发生遗漏；若项目紧急可先测试，再修改测试用例。

　　2、做手机应用，流程不像是WEB的那样清楚，感觉应用除了主功能还有很多零碎的小功能。设计用例时容易遗漏。需要怎么样做更好呢。

　　专家分析：手机应用端测试是最适合应用场景分析方法的，场景设计需要经验的累积，不是简单学习知识就行的，建议使用思维导图，做个有心人，把平时测试的经验都记录下来，形成最适合的场景设计方法。

　　专家建议：手机测试考虑有各种手机的牌子、型号（还有现在的太阳能手机情况下）、停机、没电、内存容量等等。

　　3、怎样用简短的测试用例达到高覆盖率的测试？并且写用例时候采用非常清楚的描述好还是采用测试点描述让测试执行人自行发散测试思维？

　　专家分析：我们一般不做这样的考虑，用例需要有合适的颗粒度，并不是说一条用例覆盖的越多越好，如果一条用例如果颗粒度很大，覆盖了很多测试点，当前看起来很好，但过几天你还看得懂这条用例吗？而往往测试用例数量往往大大超过测试数量。

　　用例存在的目的，一个是沟通交流，让其他人能看懂你的测试思路，帮你评审，另一方面也是经验的累积，最终形成用例库，所以一定要体现用例设计思路。自行发散测试思维是要不得的，这样几年做下来，一点积累都没有，久而久之在测试界会被淘汰。

　　4、如何能把黑盒测试做精，做好，对于一些对测试不是特别重视的公司又如何开展较为完善的测试工作？然后黑盒测试必须要向白盒与性能走吗？

　　专家分析：可以向公司商议有关测试的重要性。若公司不同意，也尽量采用专业些的测试方法（工具）及bug管理等，便于引起公司的重视和认可。测试人员也要适应这种情况。首先就是了解公司对质量的诉求，比如现阶段对性能没什么要求，那就集中于将功能测试做好，同时要考虑提升测试的效率，比如自动化测试。在需求确认环节，尽量参与，比如针对每个需求写验收标准，然后再和开发一起进行需求讨论，把测试工作融入到整个开发过程中，那么测试的重要性就会和开发并列到一起了。

　　黑盒测试很难精通，比白盒难得多，白盒测试是 测试中最简单最没有技术难度的一环。哪个价值大，应该清楚了吧。如果没有一定的代码基础，不建议你去做白盒。测试最有发展的还是黑盒测试。黑盒测试需要学 习的东西很多，比如需求环节的测试需求分析，场景分析，设计阶段的用例设计方法，实现阶段的测试自动化，DFX测试技术等等。性能测试是很重要的发展通道，其实性能测试也属于黑盒，性能分析和优化才有点偏白盒。

　　在国内，功能占用的比例确实很高，但现在大部分公司的入职要求是要会点性能工具或者自动化工具的。

　　5、针对做嵌入式开发的公司，作为测试人员，主要需要学习哪些内容？数据库，自动化测试是否能用到？

　　专家分析：嵌 入式来说，数据库可能不太会涉及，不过自动化依然很重要。嵌入式软件可以看做一个黑盒，测试最大的难度在于搭建测试环境，因为你要为这个黑盒搭建好输入、 输出环境。一般来说，必须掌握最底层的一些知识，像单片机原理啊，认识芯片那些引脚啊，数转模啊，还有一些基本的汇编。从我了解的嵌入式软件测试来看，它是最容易实现自动化测试的。

　　6、黑盒测试可以做多久，应该怎样规划黑盒测试的职业生涯？

　　专家分析：黑盒测试来说其实研究透了，你也非常厉害，像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。

　　7、怎样写好黑盒测试用例，在不出现冗余的情况下达到覆盖面广？

　　专家分析：为何会有等价类划分、边界值、判定表等等工程方法？就是为了帮助大家写好用例的。

　　出现冗余举个最简单的例子：0-100之间取值（整数），可取0、55、100；若再取-1、1、99、101就是冗余。

　　SQL Server数据库用视图来处理复杂的数据查询关系是本文我们主要要介绍的内容，该内容是这样想到的：在辅助教务系统那块的时候，我做的一个页面是对单个老师和整个学院老师的工作量查询，这个操作设计到了三个本数据库中的表和一个不同数据库中的一个教师信息表，如果用普通的SQL语句是非常难实现的，由于我刚开始做的视频播放系统，数据库的表相对比较少，没有涉及到这么复杂的处理关系，刚开始感觉很难。

　　后来想到用视图可以解决多个表的复杂关系，但是另外一张表是不同数据库的，是否依然能进行操作，经过测试之 后，居然可以将不同数据库中的两张表进行建立视图关系，从而视图就是一个虚拟的表，我们将需要查询的不同数据库中的表或者相同数据库中的表，放到一起，然 后选择需要的字段，重新建立一个新的虚表，然后这个视图就可以作为一个新的表，进行操作。这样就为我们提供了很多方便。

　　视图是一个续表，是从一个或者多个表或视图倒出来的表，其结构和数据时建立在对表的查询基础上的。

　　视图的优点有：

　　1、视图可以让用户我们选择某些特定的数据和或者特定的任务，而那些不需要的或者无用的数据可以不再视图中显示。

　　2、视图大大的简化了对数据库的操作，可以通过视图操作进行对表的操作。

　　3、视图可以让不同的用户以不同的方式看到不同或者相同的数据集，相当方便

　　4、在某些情况下，由于表中数据量太大，因此在表的设计时常将表进行水平或者垂直分割，但是表的结构变化对应用程序的产生不良的影响，而使用视图可以重新组织数据，从而使外模式保持不变，原有的应用程序可以通过视图来重载数据。

　　5、视图提供了一个简单而有效的安全机制。

　　视图的缺点：

　　如果该视图处理的数据量非常大，那么就给sql数据库带来了很多压力，执行速度相对来说比较慢，不如存储过程，所以如果可以用存储过程实现的，优先用存储过程创建视图主要创建方式：

　　1、用sql server管理平台创建视图

　　2、用Transact-sql语句中的create view命令来创建视图

　　3、利用sql sever管理平台的视图模板来创建视图

　　创建视图的时候要注意：

　　1、只能在当前数据库中创建视图，在视图中最多只能引用1024例，视图中记录数目先知只有其基表中的记录数决定。

　　2、如果视图引用的基表或者视图被删除，该视图不能再被使用，知道创建新的基表或者视图

　　3、如果视图中某一列是函数、数学表达式、常量或者来自多个表中的列名相同，则必须为列定义名称。

　　4、不能再视图上创建索引，不能再规则、默认、触发器中引用视图

　　5、当通过视图查询数据时，sql server要检查以确保语句中涉及的所有数据库对象存在，每个数据库对象在语句的上下文中有效，而且数据修改语句不能违反数据完整性规则。

　　6、视图的名称必须遵循标示符的规则，且对每个用户必须是唯一的，此外，该名称不得与该用户有任何相同名称的表 这是建立的视图，其中TeacherInfo是从另外一个数据库中添加进来的。

　　以下是通过视图查询出来的数据表“select * from QueryWorkInfoByFaculty”

　　关于SQL Server数据库用视图来处理复杂的数据查询关系的相关知识就介绍到这里了，希望本次的介绍能够对您有所收获！

　　作为测试人员，编写测试用例是我们的核心，他最重要的作用就是让我们跟着测试用例测试，不会遗忘一个测试的功能点。在现实的设计用例环节来说，做到很好的测试用例对我个人来说是很难的。尤其是场景测试用例设计。

　　本文不以概念和一些教科书似的例子来讲解场景测试和业务测试的相互关系。以一个轻松交流的方式来总结场景测试的流程。当今很多产品不再是单一的互联网或者是独立产品作为测试的对象，往往跟多个模块进行配合测试。即使有严格的规格说明书，事件流的测试也是不能忽视。

　　为什么要用场景测试用例：

　　因为用等价，边界等设计方法对于一些流程较多或者对于没有需求规格书来说，是非常难做到的，尤其是逻辑性比较强的嵌入式产品。他的边界值往往都要到性能测试的性能kpi和压力2个测试点才能够观察到。

　　测试阶段中什么时候用场景测试：

　　在产品开发阶段和测试阶段同步进行时（说正规点是敏捷，说不正规点是赶工，个人意见），还有单元测试或者单个模块测试完毕后。

　　场景测试用例设计的困难点：

　 　1、需求不足和逻辑关系较多的时候。这里需要展开来讲。很多时候我是不得不用到场景测试法。因为需求规格书不足和该产品从等价，边界等测试用例方法是设 计不出有效的测试用例。流程和涉及产品较多，对比网上的场景用例实例，现实中使用场景用例的流程往往复杂很多，单单了解流程都很吃力。

　　2、设计事件流的过程中很容易设计出沉余的测试用例，因为就算每个流的条件不一样，但是你实际测试过程中使用的手法和观察点确是一样的。难就难在这用正交法是很难瘦身这类的用例，只能通过测试来慢慢优化该用例，流程关注点越多，重复的几率就更多。

　　为什么我既爱又恨场景测试法：

　　对于我来说，场景测试法既是我用最多的测试法也是我最不想用的设计方法。作为测试人员在长期的测试过程中，你会慢慢变得很懂内部原理，尤其是你转化为自动化测试后，甚至做到一个确定键报错都会联想到这是数据库和web的存储过程入参不一致导致的境界。好处是你可以测试出很多底层的东西，坏处是经过你测试的产品，功能很多，但是却不好用。因为我忽略了我是一个用户的角度去测试，而是一个开发测试开发的东西。

　 　场景测试让我找到了平衡点，我知道了这东西的流程，可以在了解中提出改进建议，对产品有了很深的了解。让我从自动化测试中拉回来一点点。为什么我会不想 用的此种设计方法。他很考你的经验和总结能力，同上面所说你缺乏需求规格书的时候，你就是用想来写用例。所以当别人表扬我测试不少用例以外的关键Bug的时候，我是高兴我的有好的测试经验还是我写出了差的测试用例。

　 　对于做测试有一定年头的人，项目组对你的要求不再是了解普通的测试流程，还有很多里面的原理，设计，方案，进度。场景测试设计的时候你就要把关，我设计 的是多深入的测试用例？能否根据你项目的期望来测试出关键的bug。好比我测试的是web的流程，但是项目关注的后台的处理流程。实际情况中，你设计场景 用例的时候不再是培训那套理论和”真理”。

　　通过以上可以看出，为什么有些业务测试工程师比自动化，性能，甚至开发的地位都要高。例如银行，无线通信业务中，手工的测试手法非常多，同样的产品不同的人测出的效果不一样。体现出现的就是业务流程的能力，部分情况下就是场景测试设计的功力。

　　总结，作为一个测试人员的我的目标测试周期，第一了解产品的应用架构，第二了解产品使用的业务流程，第三总结业务流，第四根据业务流跟各个开发组了解设计流程，第五写出按需求的自动化测试的架构，第六写出场景测试用例，第七进行系统测试，第八进行细节的自动化用例编写，第九进行自动化测试，第十出测试报告和测试周期的自我”性能调优”总结文档。

　　这篇就是我的场景测试总结文档。

　　不同于“颠覆式”创新，作者提出的创新“渐进式”是依靠精准定位、从小做起、局部发展、快速迭代、持续渐进等理念，推动互联网产品的演化。

　　我在IT行业从业十余年，只待过两家公司：金山和腾讯。在谈创新之前，我想先从我所观察到的两家公司的节奏谈起。

　　大家知道，在十年前，传统IT企业如金山或金蝶，软件开发常 以年为单位。年初由产品经理写好一份大需求，各方评估完后启动项目。设计、开发各做几个月后进行提测，之后缓慢迭代。虽然现在听来，一年的时间很长，但到 最后项目Deadline时，所有人仍喊时间不够用。最终项目经理卡死时间、编版本、压盘，所有残念在压盘的一瞬间烟消云散。这样，一个历经了一年开发出 的、被我们称为软件的东西，夹杂着未竟的feature、待解决的Bug、需调整的UI，被压入盘中大规模生产，包装起来送到消费者手里。

　　而互联网企业的生产，则是完全不同的一番景象。2003年进入腾讯之初，我就被这家公司的敏捷震惊了—一个月一个版本！我只有1～2周的时间做界面设计，并且大部分进度是与开发重合的。产品经理（如果有的话）根据用户反馈和竞争对手的情况做需求，界面设计和开发同步进行，测试时间更是若有若无。就这样，一个历经了一个月开发出的，被我们称为互联网软件的东西，夹杂着更多未竟的feature、待解决的Bug、需调整的UI，被打包放在服务器上，在Web上提供链接，开始供用户下载。

　　两家公司的开发过程都包含程度不一的慌乱，最大的差别是节奏。相较之下，一个月一个版本，更能抓住用户需求的变化，有更大机会在不断开火中瞄准，也有更多机会尝试创新。

　　创新是企业保持竞争力的保证，近年来，互联网人都讲“微创新”，这个词虽然道出了创新的“形”，但未道出“势”。我更喜欢用“渐进式创新”来描述我们在产品上做的循序渐进式的创新改良。

　 　请允许我打一个比方：上帝按照他自己的样子造出了亚当，如果你愿意说他山寨的话，这个说法也可行，但特别的是，他还根据亚当的需要造出了女人。从男人到 女人，还是有那么一些渐进式的意思。我们转换一个频道到达尔文这里：在广袤的非洲大草原，春天到了，动物们又到了交配的季节……这时，一只猿猴忙碌之余， 兴之所至忽然站立起来行走。与其他猿猴相比，当时的它也许并没有显示出划时代的高明，但它做了创新，而这一创新，可以说是以后划时代变革的开始。请大家主 意，这只猿猴并没有突然从猿猴1.0升级到猿猴2.0，而是猿猴1.01，因为它只是渐进式地做了变革—站立起来，并未具备可以思考云计算的大脑和足以操作键盘的灵活双手。

　　还有一个案例：iPhone。在这个时代谈创新，始终绕不开苹果。 iPhone是如何出现的？看iPod的演化史，你会发现每一个iPod版本的进化：屏幕更大了、机身更纤薄了、性能和容量变化了、可以声控了……这些渐 进式优化一步步发生，终于有一天，当秘密研发iPad的工程师把多点触摸技术也准备好后，乔布斯一拍大腿说：“为什么不做个手机呢？！”【注：关于iPad在苹果内部研发早于iPhone的信息，详见乔布斯访谈】。

　　鉴于此，我想提出一个观点：其实没有所谓一步到位的划时代的创新，任何一个创新都是建立在已经存在的事物的基础上渐进发生的。

　　下面，我将以腾讯的案例阐述我的观点。腾讯发布了数以百计个版本的QQ，这其中当然有大的重构和功能的革新，但更多的是遍布在小版本中的渐进式创新。

用户头像下的Tips

　　关键路径上的创新影响力巨大

　　如果你碰巧是QQ的付费用户，购买了绿钻，那么你头像的Tip底端会显示一个绿钻图标，作为已经购买该项服务的印记。在最初的版本里，我们只做了已购买服务的图标标记，直到某个版本的需求讨论会上，业务部门提出：如何增加业务的开通量？

截图功能

　　如何增加业务的开通量？

　 　提升业务开通量的方法有很多，比如打广告。当时设计的思路是：有些增值服务用户甚至都不知道，打广告虽然能增加业务曝光度，但从用户看到广告到开通业 务，路径很长，而Tip本身确实是一个很好的接触点。于是我们灵光一闪，把未开通的业务图标，以灰色未开通的形式展示在Tip上，而用户鼠标移过灰色图标 时，就显示对该项业务的说明，点击则会进入这个业务的详细介绍和开通页面。这个小小的改进对QQ增值业务的开通拉动是非常巨大的，至今我们仍无法估算这个 小改进带来的直接经济价值。

　　创新来自对使用场景的细微观察

　　在即时通信软件中，人和人沟通最初的方式只有文字。虽然文字传情更有意境，但多媒体、全方位互联网沟通时代早已浩浩荡荡地到来了。在视频、音频多方位沟通的背景下，截图功能是这个历史进程中的一朵奇葩。

　　两个人在现实中沟通，往往以眼见之实物辅助，而在网络上沟通，往往以眼见屏幕中之物辅助，但首先要能截取并给对方看到。在UI设计师和程序员的 合作联调过程中，这样的使用场景太常见了，既然QQ已具备传送图片的功能，为什么不做个截图功能，作为图片来源直接发送给好友呢？

　　第一个版本的截图只是简单的截屏、发送给好友。在之后的版本中，我们渐进的在截图功能中加入了标记、文字说明等功能。现在，截图功能这个貌似和即时通信软件不相关的功能，已成了QQ的重要特性之一，甚至是某些用户坚持登录QQ的唯一动力。

　　大创新可拆解成小创新逐步实现

　　做产品的人一定很熟悉一句话：资源永远是不够用的。特别是在互联网行业快速迭代的产品节奏下，任何一个功能特性的开发资源都很有限。在有限的资 源下，想说服所有人放下其他事情安心实现你的创新大计划几乎是不可能的。这么多年的斗争经验积累下来，在腾讯内部形成了一句话叫“小步快跑”，这句话本用 以形容功能迭代，但在创新上其实一样适用。

　　如果你有一个大的创新计划，需要动员巨大的资源来实现，那么不妨先把它拆解，逐步制作、逐步发布。发布后依据用户反应进行下一步计划：如果反应 不好，幸好这时的资源投入还不多，那就偃旗息鼓，还来得及反悔；但如果反应是正向的，提供给你资源的人也会有信心，这时就可以继续推进，逐步地把创新点的 最终面貌呈现出来。

　　保持创新的方向感，做局部创新

　　中国互联网正处于产品过剩时期。任何一个产品形态在市场上都有上十款免费产品可供选择。虽然份额各有大小，但大家往往都很默契的遵循该形态的一 些基本标准。比如：即时通信、邮箱、微博、新闻门户，基本都有已成型的产品形态，用户也习惯了这些产品形态。在这种情况下，全面创新是一种既费力又不符合 用户预期的做法。

　　QQ“主面板”+“聊天窗口”的设计模式，经过十几年的沉淀和发展已经定形，已成为互联网即时通信软件的标准。后来者很少在这个聊天基础体验上做颠覆，但各厂家结合自身业务和资源优势对产品做出创新是常见的。

　　我们对QQ的基础体验也做过颠覆性的创新尝试，比如主界面摒弃窄面板形式，采用更大的、可容纳更多内容的大界面，但通过用户研究发现市场接受度非常不乐观。

　　但当我们聚焦到局部创新时，我们发现即使是最基础的“信息输入”体验，可做渐进式创新的点就非常多。我们聚焦在“信息输入”这个小局部，结合用户输入困难，设计和开发出了手写输入、语音输入等功能，很受用户欢迎。

　　持续渐进创新，为后来者设立门槛

　　产品体验被模仿的门槛较低。大家都不差钱、不差技术时，一个好的体验创新点，总是很快被竞争对手模仿。但模仿一个点容易，模仿整个思路很难。清晰自己产品的方向，按照思路有节奏的不断创新，始终领跑对手1～2个月，是为后来者设立的最有效的门槛。

手写输入，语音输入

　　“找朋友”是微信最核心的功能点之一，每个版本创新出新的“找朋友”、“加朋友”的方式，让微信在和竞争对手的赛跑中始终领跑。

　　在腾讯，渐进式创新的案例数不胜数，维持快速迭代的渐进式创新，是腾讯产品持续成功的重要因素之一。

　　人类的进步是在不断螺旋重复中上升的。在某些时间点，当渐进式创新进行到一定阶段，会有人进行整合和再创造，量变引发质变，但凭空出现一个划时代创新产品是不可能的。如果你发现了这样的产品，那么很有可能是你对它之前的历史并不了解。

大界面QQ的概念图

　　从现在起，凝视你手上的产品，承认它的不完美，并发现可进行渐进式创新的方向吧，脚踏实地进行改进，你的产品会在互联网的进化史上，拥有属于自己的位置。

　　做为一名测试人员，我们也许会问我们自己很多问题：

　　● 我们可以立即执行的最好的测试是什么？

　　● 我将要使用的测试方法是什么？

　　● 这是一个Bug吗？

　　● 我已经测试完成了吗？

　　但是我们之中会有多少人提出以下的这些问题呢？

　　● 这个组件需要一直被测试到吗？

　　● 需要由我来测试它吗？

　　● 如果它不工作，谁会去在意它呢？

　 　在我看来，我们提出的问题中和以上三个问题类似的还远远不够。可能这是因为我们已经被告知要测试一切东西。甚至我们的一部分人会在其质量团队中有一个流 程，要求某个人把每一个组件都贴上“已测试”的标签。我们对待测试就像一个常规的工厂程序，我们甚至有时候引以自豪的说…

　　“我是测试工程师。因此，所有的东西都需要被测试…由我来做…即使非测试人员已经测试过了…即使我已经知道它将会通过测试…即使需要一个程序员告诉我怎么去测试…我必须测试它，没有例外！”

　　这类想法可能会让测试人员有一个坏名声。由于欠缺思考的过程导致它强调了测试的重要性，而不是给一些人提供最有价值信息的服务。

　　James Bach 带着以下的测试观点出现：

　　基本的观点：“如果它存在，我就要去测试它”

　　正如前面内容和我经常发布的文章中，我不同意这个观点。尽管如此，我完全同意James 在2006年8月7日，他在博客发布的完整版本中关于这部分的介绍：

　　“如果它存在，我就要去测试它（唯一的例外是我有更重要的事情要做）”

　 　第二句话是可以有很多的理解方式！为什么呢？因为我们经常会有更重要的事情去做，通常是另外的测试工作！不幸的是，重要性往往不是区分的很明显。所以与 其衡量重要性，我更喜欢提出上面的三个问题，去寻找那些可能不值得浪费我的时间去测试的东西。下面八个例子是我讨论的内容：

　　1、不会在产品中出现的组件- 我的团队中在每次迭代中都有这些内容。例如增强功能中的错误记录表或者跟踪生产活动中的审查报告。在敏捷开发的团队中这些被归入开发者用户故事（Developer User Stories）。这些内容不会随便的在产品中出现并且由于其本质不会直接影响到用户。

　　2、关键产品问题的补丁不会很糟糕– 一天下午客户给我们的技术支持打电话，由于我们的产品的一个阻塞性质的bug导致他们处于错过一个关键最后期限（DeadLine）的边缘。我们只有一个 小时交付修复的产品。程序员很快的修复了问题，由于当前的产品是无效的，所以对修复之后进一步的产品存在的风险来说这是微不足道的。想要当英雄吗？不要让 事情慢下来。快速的让产品通过测试。如果需要以后再去测试。

　　3、界面问题修复要有适度的准备时间– 我们修复了一个在屏幕上出现的用户错误消息中的拼写错误。用户并没有察觉到拼写错误但是我们无论如何修复了问题。很快而且简单。触发这个错误消息需要30分钟的准备时间，值得吗？

　　4、直接了当的配置改变– 去年我们产品开始偶尔出现很大的作业不能处理的问题。一个程序员尝试改变通用配置修复问题。但在QA的环境中没有一个简单的方法去创建一个足够大的作业超过这个临界值，很难去测试。我们在产品中修改了配置然后用户很高兴的为我们做了测试。

　　5、技术性的需要非程序员的测试– 测试部分功能时需要实施某种行为而在代码中设置断点来复现竞态条件.有时测试人员与工具和程序员精通产品代码的知识并不匹配。讨论这个测试但是回避它。

　　6、非测试人员借用– 如果团队中一个非测试人员帮忙去做测试工作，或者更重要的，想帮忙测试某一组件，让他去做吧。跟他分享测试的思路并且跟他要测试报告。如果你觉得满意，不需要再去测试它了。

　　7、没有复现步骤- 程序员偶尔会尝试某些东西。经常会出现一些错误报告，但是没有人能对这些错误给出确切的重现步骤。我们也许想对修改的区域做回归测试，但是我们发布的时候不会阻止这种明显的修复，因为我们不知道它管不管用。

　　8、不足的测试数据或硬件– 让我们面对它吧。在我们QA的环境中，根据产品中所需要，大部分情况我们没有足够多负载平衡服务器。当一个有效的测试需要的资源在产品使用环境之外不可用时，我们可能无法对其进行测试。

　　很多人也许尝试想像上面这些如果不去测试会导致的问题。我也会做这些。记住，这些事情也许不值得花费我们的时间去测试。再次权衡你所做的事情，如果在不是很清楚的时候，去问问利益相关者。

　　如果你选择不去测试某些东西，很重要的是，不能被我误导。这是在我的团队中使用到方法。在我们进行组件审查时，我们 的（测试人员）说，“我们将不会去测试这些”。如果有人反对，我们会改变我们的想法并且测试它。如果没有人反对，我们就“未经审查即批准（rubber stamping）”。即表明没有被测试就让它通过这样可以让他进入到最终产品。

　　所以下次你发现你自己正在着手做的测试，感觉比其他你应该做的事情更不重要时，你应该需要考虑…不去测试它。逐渐的，你的团队将会尊重你的决定并受益于更少的瓶颈，以及在你实际增加的价值的地方增长的覆盖率。

　　1、手工测试用例和自动化测试用例功能定位的区别。

　　a）手工测试用例
　　　　i.较好的异常处理能力，能通过人为的逻辑判断校验当前步骤的功能实现正确与否。
　　　　ii.人工执行用例具有一定的步骤跳跃性。
　　　　iii.人工测试步步跟踪，能够细致的定位问题。
　　　　iv.主要用来发现功能缺陷

　　b）自动化测试用例
　　　　i.执行对象是脚本，任何一个判断都需要编码定义。
　　　　ii.用例步骤之间关联性强。
　　　　iii.主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。
　　　　iv.目前自动化测试阶段定位在冒烟测试和回归测试。

　　2、自动化测试用例设计管理不善可以直接导致自动化测试开展的失败。

　　误区：

　　1、不编写测试用例直接投入测试脚本编写。

　　2、直接拿手工测试用例来编写自动化测试脚本。

　　自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。

　　目前咱们TD中对用例加入了自动化测试的标签。

　　目前自动化测试定位在冒烟测试和回归测试。

　　冒烟测试执行的是主体功能点的用例。

　　回归测试执行全部或部分的测试用例。

　　怎么编写自动化测试用例，如何将自动化测试用例和手工测试用例相辅相成。

　　用例选型注意事项：

　　1、不是所有的手工用例都要转为自动化测试用例。

　　2、考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。

　　3、选择的用例最好可以构建成场景。例如一个功能模块，分n个用例，这n个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。

　　4、选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。

　　5、选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。

　　6、选取的用例可以是主体流程，这部分适用冒烟测试。

　　7、自动化测试也可以用来做配置检查，数据库检查哦。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。

　　8、如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了。

　　用例转型注意事项：

　　1、首先测试人员应该了解脚本是怎么替代人工来执行用例。

　　2、当你写自动化测试用例时，你需要意识到你的用例是写给一个“智障人士”执行，执行对象是脚本。

　　3、当前的测试用例前置配置信息要写清楚。

　　4、每一个步骤都要衔接好，错了，脚本要报异常，我要去烦你。

　　5、每一个步骤要做什么，验证什么要写清楚，写具体。有时一个检查点，你只需看一眼，但是脚本要写一堆代码去验证，这样的做法是不可行的。

　　6、用例之间不要有关联性，自动化测试开发同样是软件开发工程，脚本编写同样提倡高内聚低耦合的理念。

　　7、不是每一个步骤都需要验证点，让子弹飞一会儿。

　　8、别在多个地方重复相同的验证。脚本很忙！我没空。当然，除非有必要。

　　9、开门记得要关门，配置信息要回归原点，否则脚本要迷路。

　　10、当你设计自动化测试用例时，难免对一个用例的功能点加加减减。不要因此而剪掉了一些验证点。因为手工用例+自动化用例=1。

　　写给项目测试负责人的一些话：

　　1、项目加入了自动化测试平台，负责人要有全局的把握。因为你的用例被拆分成自动化测试和手工执行用例，原来一些被打入冷宫的用例因自动化测试而重生，重生的用例需要你的维护。

　　2、当你迎来项目新立项，拿到需求文档，开始设计新用例，此时，别忘了该如何统筹安排你的用例。是的，这很像排兵布阵，有了自动化测试这把利剑，还得看你会不会用。

　　3、不要永远做自动化测试的门外汉。可能你的职业规划是测试经理，产品经理，或者其他，又可能你对其感到畏惧或厌倦，认为自己无法跨越对编码的恐惧。但是，无论如何，今天你是这个项目的测试负责人（一个资深的测试工程师），你要负起这个责任，挑起大梁。

　　4、如果以后你看到自动化测试报告单，没有发现一个bug，请不要抱怨，自动化脚本主要不是来帮你找缺陷，而是告诉你没有缺陷。

　　5、如果将来你参与了自动化测试脚本编写工作，请做好面对一大堆错误的心理准备。在前期，测试结果往往会夹杂着一大堆的各种错误，可能是框架机制问题，可能是脚本编写问题，可能是用例问题，还有可能是需求自身的问题。

　　6、咱们部门刚刚开展自动化测试，需要大伙的支持和理解。它的发展需要一个渐进的过程，从无序到有序，从困惑到豁然开朗。这个过程难免曲折艰 辛，甚至会引来非议，但是从一些成功案例中，还是坚定了我继续走下去的信心。我渴望和大家一起分享这份成果，尽管现在连花儿都未曾开放。

　　7、会自动化测试和会QTP是两回事，学习自动化测试不一定要会QTP，你也可以通过Selenium入门。

　　8、请考虑下你负责的项目是否需要实施自动化测试，我们可以一起坐下来讨论，圈定一个范围和实施的计划。我们都是产品线上的一颗螺丝钉，我这颗螺丝钉很乐意为你的项目提供自动化测试的帮助。

　　9、不要过度信任自动化测试，它也是个撒谎高手。所以，自动化用例需要测试，框架需要测试，脚本函数需要测试，脚本过程需要测试，驱动数据需要测试。

　　10、看到这里，你一定觉得开展自动化测试很累人。没错，这本不是一件立竿见影的利索活。它的发光，需要一定时间的沉淀，我们现在讨论的，和接下来要做的工作就是为了如何来缩短这部分的时间。

　　总结：今天讨论的仅仅是自动化测试开展实施的一部分，这部分很关键，需要大家的支持，因为用例是整个自动化 测试的灵魂，没了灵魂，框架搞得再好，也仅仅是个躯壳，行尸走肉。我自己写测试用例的水平远不如咱们部门的测试负责人，这是真话。讨论自动化测试用例的选 型和转型难免有些力不从心，尽管这样，我还是憋着喊出来，希望能得到大家的更好见解，俗称：抛砖引玉。

由于公司需要测试系统的最大用户承受能力，所以需要学习使用loadrunner。在安装的时候碰到了不少问题，所以写下此文章总结遇到的问题以及解决方案，希望能帮到大家。也希望大家转载注明出处。

Winsows 的Loadrunner 安装就不多讲了，这个太容易了。

以下是Linux 中安装 Load Generator 说明：

Linux 系统版本：CentOS5.4

Load Generator 版本 ： Load Generator 11

安装步骤如下：

1. 到HP官网下载Load Generator 安装文件 Software,_Load_Generator_11.00_T7330-15010.iso

2.确保系统安装了c++ ， gclib 相关工具（我的系统在安装前已经安装了gclib ，所以还不知道没装这个会发生什么问题）

3. 在Windows 系统下将Software,_Load_Generator_11.00_T7330-15010.iso 解压出来会有三个文件夹（HP ， Linux ， Solaris），这三个文件夹是相关系统的安装包。请根据你的系统选择对应的文件夹copy到 要安装的Linux 系统中。为什么要使用这种解压后copy的原因是因为我根据网上的方法copy iso 文件到Linux 系统中并使用挂载的方式进行安装，碰到了很多问题，所以使用这种方式，这可是我原创的哦。我是copy到/home/LoadRunner/目录下

4. 紧跟着就是安装了，只需要执行指令/home/LoadRunner/Linux/installer.sh 会出现如下图中的安装向导欢迎界面，选择Next [n] 即可。

5. 出现下图许可协议界面，也只需点击Agree [a]，当然你可以选择View Agreement [v] 查看协议的详细内容

6. 出现确认安装界面，选择Install [i] 即可

7. 出现安装界面如下图

8. 完成安装，选择Finish [f] 即可，恭喜你安装成功

9. 紧跟着就是配制环境了，网上有说要配置env.csh 的，但我安装后env.csh 已经默认配置好了，这里也将的默认配置文件分享一下

setenv PRODUCT_DIR /opt/HP/HP_LoadGenerator
setenv M_LROOT $PRODUCT_DIR

if ( `uname` == SunOS ) then
    setenv LD_LIBRARY_PATH ${M_LROOT}/bin
else if ( `uname` == Linux ) then
    setenv LD_LIBRARY_PATH ${M_LROOT}/bin
else if ( `uname` == AIX ) then
    setenv LIBPATH ${M_LROOT}/bin
else if ( `uname` == HP-UX ) then
    setenv SHLIB_PATH ${M_LROOT}/bin
endif

setenv PATH ${M_LROOT}/bin:$PATH

10 .除了上文中讲到的还需要在/root/.bashrc文件中添加如下配制，保存修改后注销用户重用登录
export PRODUCT_DIR=/opt/HP/HP_LoadGenerator 
export M_LROOT=$PRODUCT_DIR 
export LD_LIBRARY_PATH=${M_LROOT}/bin 
export PATH=${M_LROOT}/bin:$PATH

11 . Load Generator会安装到/opt/HP/HP_LoadGenerator目录下，我也是使用默认的。进行/opt/HP /HP_LoadGenerator/bin 目录执行./verify_generator （不能使用root用户，至于为什么还不清楚）  检查安装是否成功，如果成功会有以下信息，

===================================================
              HP
     Vuser Environment Verification Utility
===================================================


Product: LoadRunner 11.0 
Version: 11.0.0.8866 
Build: 8866  

localhost.localdomain: 

verify_generator...OK
verify_generator...OK
verify_generator...OK 
Don't forget to make sure that the name of the controller machine 
is also in .rhosts 
Verify $M_LROOT ...Failed 
_____It was not possible to set the $M_LROOT from 
_____the shell dot files. One of several things might be happening: 
_____1) $M_LROOT is not set at all in the shell dot files. 
_____2) There is some error in the shell dot files which stops their execution 
_____   before it sets $M_LROOT. 
_____3) There is conditional code in the shell dot files (most likely related to 
_____   interactive and non interactive shells) and $M_LROOT is set 
_____   only in one of the sections. 
_____Aborting virtual user tests on host localhost.localdomain 
verify_generator...OK 
_______________________________________________


Summary:
________
Vuser Host localhost.localdomain: Failed

这些Failed 我都忽略了，因为这些Failed并不影响运行。我很希望哪位大虾看过此文章后能在此回复解释一下这些Failed可以解决吗？

上面是正确的信息，我刚开始的时候遇到了下面这些提示，注意其实这些提示都很直观，缺少了 libstdc++.so.5 ， 安装就可以了。调用 yum install  libstdc++.so.5 .安装后再调用 ./verify_generator 就可以看到上面的信息了。

===================================================
              HP
     Vuser Environment Verification Utility
===================================================


Product: LoadRunner 11.0
Version: 11.0.0.8866
Build: 8866




localhost.localdomain:


/opt/HP/HP_LoadGenerator/bin/lrv/chk_thread_lmt: error while loading shared libraries: libstdc++.so.5: cannot open 


shared object file: No such file or
 directory
/opt/HP/HP_LoadGenerator/bin/lrv/limithost: line 134: [: : integer expression expected
/opt/HP/HP_LoadGenerator/bin/lrv/chk_sems_lmt: error while loading shared libraries: libstdc++.so.5: cannot open 


shared object file: No such file or d
irectory
/opt/HP/HP_LoadGenerator/bin/lrv/limithost: line 154: [: : integer expression expected
verify_generator...OK
verify_generator...OK
verify_generator...OK
Warning: The file .rhosts does not exist in the home directory of the user.
Verify $M_LROOT ...Failed
_____It was not possible to set the $M_LROOT from
_____the shell dot files. One of several things might be happening:
_____1) $M_LROOT is not set at all in the shell dot files.
_____2) There is some error in the shell dot files which stops their execution
_____   before it sets $M_LROOT.
_____3) There is conditional code in the shell dot files (most likely related to
_____   interactive and non interactive shells) and $M_LROOT is set
_____   only in one of the sections.
_____Aborting virtual user tests on host localhost.localdomain
verify_generator...OK
_______________________________________________


Summary:
________
Vuser Host localhost.localdomain: Failed

12 . 启动 Load Generator  ，在安装的bin目录下输入 ./m_daemon_setup start 即可开户服务了 （不能使用root 用户启动）

13 . 修改防火墙策略，对54345端口开放，或者直接关闭防火墙（不建议直接关闭）

讲到这里安装步骤就完，现在讲如何在Windows 系统下启用 刚才安装的Load Generator

1. 打开Controller 的Load Generator 。 点击 场景--> Load Generator

2. 添加一个Load Generator 。点击 添加--> 输入名称（名称即ip）--> 选择平台 --> 点击更多 --> 点击 Unix 环境 --> 勾选“不使用RSH” --> 确定

3. 添加后测试连接，如果显示连接成功就功造成了，连接时如果有其它问题建议大家多思考，注意那些连接不成功的提前。我个人觉得LoadRunner 在提示之方面做的比较好，出了问题基本上看提示就知道问题在哪里。祝大家一切顺利。