测试基础三
提高案例设计水平 明确了解现在目前流行切实用的几种案例设计的方法，因为在不同的产品不同的要求有不同的设计手段，我们需要不断的学习和总结，在为了测试领域中，许多新鲜的词语都会出现。
这种方法类似与工业领域的随即抽取统计分析法，但是工业性质牵扯到损坏或者人为原因，统计出来存在这偏差，但是应用与软件方面，虽然存在着偏差，但是不可能象硬件那么偏差很高。
等效法 明确测试的目标，一般适合用到的范围是，制定被测试的对象是在满足某个条件的区间内的所有的所有数据。
案例设计方法：从其中区间数据段中选择任意一个或者两个数据，只要这个数据满足了，那么其他的数据就是满足的。
我现在举一些例子，来说明等效法在测试过程中如何应用的。
范例1：在登陆某系统需要验证用户名，要求是长度是最小是6位，最长是14位，名字中可以包含数字，但是不能以数字开头，可以包含各种符号，不能包含中文。
1、随意字母组合成一个12位的姓名，测试是否可以通过验证。
2.、随意生成一个长度12位的姓名，测试是否可以通过验证
3、测试以任意一个数字打头12位的姓名，测试是否可以通过验证
4、测试姓名长度位12位且包含中文情况，测试是否可以通过验证
5、测试长度不满足条件情况下，是否通过验证
6、如果长度不满足，是以数字开头的，提示信息验证
7、如果长度不满足，姓名中包含中文的，提示信息验证
………….
(注：)这个可能比较简单，但是说明一个问题：为什么随意生成一个12位姓名的,其实你选择8位姓名长度或者10位姓名长度是一样的，所以这种情况下考虑采用等效方法比较合适。
范例2:有这么一个需求，要求选择1~12之间进行调整，手机的背光就会随着数值的变化而变化。总体的是数值越大越暗。
以上需求是大家经常可以看到的。
测试案例设计：清晰记忆1的情况，然后随意调整一个数值，因为要求是变化了，至于变化成什么样子，变暗到什么程度才正确，没有明确的指标数值，所以只需要记住临街点1的情况，然后随意调整一个数据，然后和当前调整后的数据进行比较。
（注：）没有明确的说明，只是含糊的结果，但是总体的结果是在变化，那么这个时候比较适合使用等效法。
因果分析法 需要有一定的程序基础，了解程序的架构，就是当问题发生以后，能够有效的补充相关的案例或者筛选相关的案例。因果分析的核心是从自己的理解去分析问题所在的真正原因。
范例1：删除磁盘上某个文件失败，分析原因：如果是管理员权限，那么可以随意删除，无论这个文件的属性是只读的还是存档的，那么如果不能删除磁盘文件，除非是坏道上的文件。分析完成以后，使得测试案例设计有针对性，而不是盲目的将所有的文件格式都去尝试一次。
范例2：假设我们用Excel作一个计算，结果和我们用计算器计算的结果不同。
分析：Excel的计算函数单独运算没有错误，然后插入一行，结果错误了，说明插入行导致计算错误，那么插入一行怎么会引起函数计算错误呢？原因是由于插入行后，导致传给计算函数的区域没有更新，所以造成计算结果错误，那么这个Bug就很明确了。
范例3:假设我们平常在做讲座的时候发现在某台机器上就会死机。这是一种现象。
分析：为什么在这台机器上死，在其他机器上不死。原因有两个，第一个先找系统原因，是否是我们的产品在当前这个系统下有Bug,经过验证没有，那问题出在那里？
其实演示产品需要的是硬件的支持，那就是显卡，如果显卡内存不够大，可能导致某些演示文件死。
（注）因果分析需要有广泛的知识面，使得我们在分析的时候能够拓宽面积，模糊的定位问题。
范例4:用户给我发送一个文件，打印的时候发现是乱码。后来逼迫无奈，就让用户将这个文件传真给我。这是现象。
分析：为什么打印出现乱码？问题基本定位，系统字库不够，系统下打印驱动问题，打印虚拟内存问题，操作系统问题，软件本身问题？最后问题经过验证，最终归结为在此操作系统下，打印驱动程序有问题，使得文件不能正常打印。
（注：问题需要先框定范围，不要乱了套路。）
逻辑分析法 在逻辑分析方面，也需要有一定的程序理解能力。从程序逻辑和日常常识去判断问题。逻辑分析法其实就一堆假设的罗列，推论出系列结果的假设，然后将假设反推翻，问题就可以暴露出来。无论那种方法都是通过表现去分析问题的实质的。
范例1:我们在做MP3播放器快进和快退测试中，要考虑的同步问题，就是我们液晶显示屏上出现的歌词进度，时间进度和我们耳朵听到的进度不同。我们分析一下，为什么出现不同步现象，为什么其他的能同步，就某一个或者某几个不能同步。
首先我们了解同步的算法：快进和快退是按照当前歌曲的数据流来计算应该到那里，它是以当前歌曲的数据流为系数，然后进行的一些调整，那么出现不同步的原因是由于系数不同造成的，所以考虑到同步问题，我们需要找不同格式不同数据流的歌曲，这样问题容易暴露，容易清楚的定位问题的真正原因。
范例2
我们来分析网络游戏中的交易系统，就是在游戏两个人进行物品和金钱的交易。
怎么设计这里的案例呢？我们先梳理一下交易的逻辑关系图。
我们一起来分析下面的逻辑关系图，在玩家进行交易之前，数据库中记录了两个玩家各自的数据，然后玩家A向玩家B发送请求，当玩家B不同意的情况下，检查各自的物品个数就可以了，这种测试相对比较简单。下面我们分析当玩家B同意的情况下的测试重点在那里？
第一.当B同意和A进行交易的情况下，Ａ从自己的物品箱中拿出物品，拖放到B的物品箱中，那么A和Ｂ在还没有确定的情况下，需要确信两点（A,和Ｂ相同，只不过一个提供金钱，一个提供物品）
１、 Ａ当前的物品是可以更换的
２、 Ａ拖放到交易物品栏中的物品是不能被其他人产看的
３、 在A放弃交易的情况下，此物品还应该回到物品栏
第二. 点击确定后测试设计的重点
１、 点击确定后，双方的交易请求就会到服务器处理的队列中，等待服务器重新计算
２、 当A或者Ｂ断线情况下，怎么处理？
３、 当服务器宕机怎么处理？
４、 当请求队列中等待的时间超过了心跳的时间，怎么处理？
第三. 正常交易后的测试设计重点
１、 物品数据（金钱数据的检查）
２、 物品属性检查
３、 物品是否能够正常交易和使用
第四. 交易过程可能出现的情况
１、 不是一对一的交易
２、 在没有确认的情况下把一个物品托动到箱子后，等对方付钱后，故意断线或者更换物品
３、 锁定物品后，不和Ｂ交易，同时也不关闭交易对话框，角色的交易标志是否被清除
边界数值分析法 在测试案例执行的过程中，所有调节的数据都需要考虑到边界数值的测试方法，这里我就不在赘述。但是需要注意，边界数值的测试不是枚举，只是抽样的方法。
逃避测试的误区 市场需求引导产品质量测试是为了验证需求，保证产品质量，无论如何你都不可能做成100%的测试，不可能做成No Errors。所以我们针对不同的产品，不同的市场定位，确定不同的测试方针。
因为企业面对的是客户，面对是企业长远利益，那么我们不可能仓促的推出产品为了迎合市场，而是需要研究，调查市场的真正需求，把用户所关心的功能提供给用户，使得其更加完善，更加稳定。
我们从企业来分析，首先任何一家企业要生存，必须需要市场空间的支撑，目的是为了盈利，我觉得没有必要说的那么冠冕堂皇，这是事实，但是在把握产品质量和市场需求的时候，我相信很多企业会选择市场需求的，因为这是机会，是把握企业生存的机会，特别是对于发展性企业来说。（企业原因）
我们从开发来分析，因为在开发的过程中，由于软件行业的高流动行和知识更新快的特点，风险加大，使得开发周期很难把握，这样使得产品测试时间很难控制。因为开发的进度包括市场提出需求的技术风险都很难把握。（开发的原因）
我们从测试来分析，测试在很多企业中是没有的，那么开发人员自己来做，如果有测试人员，那测试也是随意性非常强，造成产品上市后预留很多无法预估的风险，为企业的形象蒙上了面纱（测试模式）
合理利用2/8原则测试是列举，不是枚举，所以设计案例的时候全面是不可能的，那么需要灵活的运用2/8原则，使得测试重点清楚，容易控制。
基于产品在开发过程中的种种风险，我们在有限的人力和资源的情况下，合理的利用2/8原则，如何把握2/8原则？首先需要了解产品的特点，让所有参与测试的人员能够了解产品的特点，这样使得工作具有针对性，至于产品的噱头，我们可以进行充足的测试，因为只是我们的产品立足市场的点。
在时间有限的情况下，把常用的功能测试保证了，不要摊全，摊宽，这样到最后都无法总计产品的质量概念了。
以上这么说，是一种概况，在实际的工作中大家需要总结，把进度，时间，质量等进行权衡，以保证产品的顺利发布。
回归测试的概念测试次数不是轮回，测试的不同次数不是轮回，而是为了验证问题，那么什么时候适合安排一轮测试，需要定义标准，否则耗时耗力。
回归测试是不可缺少的环节，在一个产品测试完成后，直接到用户手头的时候，需要千万小心，需要进行一次彻底的回归测试，这个时候包括所有的功能以及所有已经修正的问题。避免版本出现问题。
其实在不同的资料中对回归测试有不同的解释，我就不在这里赘述。我想表明我的观点是，依照不同的开发模式，回归测试所在的时间段也不相同；当前的开发模式有瀑布型和迭代型，例如，在瀑布型的开发模式中，所有的测试活动（手工测试，系统测试，部分集成测试）都在最后进行的，而切所理解的回顾测试是为了保证在新的版本中测试修改后的问题，其实这个测试只是保证了其中一部分工作
测试的概念测试不是为了验证问题，而是为了发现以前设计中没有发现的问题。
自动测试只是测试的一种手段，目的是为了提高工作效率
测试工具只是利用，不能依靠，因为工具本身没有智能的判断是否会有问题发生，自动测试不是利于测试工具，而是需要编写或者利于测试平台，编写适合自己的测试工作进展。
如何调整团队的作战能力建议性质：因为曾经带过四个团队，而且这个经验最少在我身上是成功的。
形式分析测试团队，测试团队在现在国内来说在慢慢的得到重视，之所以原来不重视是因为整个行业处于摸索期，不知道采用什么方法，什么技术，作什么事情等的情况下，使得测试员好像是一些没有能力人的集合（宣讲，不听的宣讲）。
目标计划引导测试技术和未来发展规划，因为任何人的发展需要目标，那么一个人的发展目标假如它和这个行业相关，那么它会付出一切，努力的工作，所以需要大家认可一个目标，并且让大家认为是可行的，然后我们分步骤一步步的去实现它。让他或者大家能够看到自己所喜欢或者从事行业的发展方向。
过过老师瘾因为在做任何事情的时候，每个人都有自己的想法或者步骤，讲出来就好，这就需要开始的时候我们以任务的形式下达，我相信，到后来大家愿意自己站出来讲了，我告诉你原因。因为人本身有羞怯感，怕几个方面，怕讲错，怕人多，怕提问。
那么如果把这几个问题都解决了，是否羞怯感就没有了呢？
如何解决个人怕的问题：引导，因为一个人如果不能把自己的想法和思路讲出来，那么不可能把事情做的很好，其二，就是如果你把你的想法说出来，别人可能会指出你思路中走弯路的地方，对个人来说可以跳高工作效率，使得思路更加完善。
其三，如果大家都把自己的思路说出来了，你不就节省的很多学习时间吗，另外你想过没有，当别人形成这个想法的时候，需要一定的积累，那是他的心血，这不就轻轻松松让你学到了吗？如果固步自封，那么你的思路有可能是错的，有可能是对的，但是你的知识面就只能局限在你所考虑的范围内，对个人发展不利。
定学习目标在软件行业里面，要有发展，就需要不停的学习，不停的进步，不停的总结，才可能有长远发展，所以需要定义在这个行业阶段行的学习目标，让人感觉这个行业现有的水平只是维持，要发展，需要学习。
在工作中学习的方法，除了自学以外，就是“偷”了，所谓偷，就是要学会问问题，把你想知道的东西刨根问底，当别人回答你问题的时候，他一定是用他知道的东西的精华来总结，那么这样你在很短的时间内，把他总结的精华全给你了。
在学习的过程中，需要学会总结，把能总结的都整理出来，第一是经验的积累，第二呢能够做到分门别类，逐类旁通，使得相同或者类似的错误不要重范。
兴趣和爱好 一个人工作有两种情况，第一中是真正的工作，完成就算完成了，自己也在不断的学习，不断的总结，但是缺乏激情。第二中是把工作当成自己的事业，渴望自己在这个方面成为权威或者说业界能够说话的人，也是在不断学习，不断的总结，培养职业性，培养和引导大家的兴趣和爱好，因为只有你了解了兴趣和爱好，才能更融洽的调和整个工作组的气氛，这对测试行业的领导者来说是个挑战。
歪曲理论推理 “测试人员是由于技术不过硬，才去做测试的。”针对这个观点，我说说自己的看法。好，我给测试说几句，测试水平不过硬成立，假设成立，那么这是相对的，相对开发来说的，而且这种论调都是从开发那里扩散或传播出来的，测试在后期发现问题后，开发也许心理很痛苦，但是他不愿意暴露在脸上，使得有些问题越发变的严重，不得不修改。那么在产品后期暴露那么多问题，说明了什么呢？这么低水平的测试都能考虑到你程序设计的种种漏洞，那么说明了程序水平开发有待提高。
在IT现在的行业中，开发的流程，模式，以及各种约定成俗
的东西越来越多，而且相对稳定，而测试是一个全新的行业，它需要大家摸索支持，需要大家共同建立起来。
其实，在原来的开发模式中，商家为了适应市场，为了保证利润的最大化，为了使得产品能够顺利的适应市场，那么采用各种方法，使得产品质量的定位淡薄，而现在随着人们的要求越来越高，商家的意识越来越强，各个公司或者组织渴望成立测试部门，保证产品的质量，使得测试这个行业在最近几年才发展起来。
正确理解自动测试 首先，自动化测试是测试行业是技术，但是不是说用了自动化测试了就能发现更多的问题,它只是提高了工作效率而已.
自动化的概念是人们在工业生产的过程中，为了提高工作效率，不断的对操作方法或者技术或者工具进行改进，减少人们普遍的手工劳动，节省时间和成本。
而软件行业的自动化测试同样也有节约成本，提高效率的需求。所以所有的改进需要考虑到成本的问题。
自动化测试的大前提:
第五. 产品本身特征具有长期可维护性
第六. 产品本身非紧迫的大项目
第七. 产品结构相对复杂
第八. 资源投入相对充裕
那么作为成本，需要从几个方面去考虑，第一实现成本，第二，人力成本，第三，新技术的风险，第四，节省的成本，第五，被自动化的功能是否需要大量的手工劳动。
所以我们理解自动化一定从成本的概念上考虑， 最少从自动化测试概念的起步应该从这个方面考虑。那么自动化测试的重点就在于他节省人力，节省时间，得到的数据更精确些，而且操作的可重复性和Bug的可重现性更强一些。
下面我就对自动化测试做一个详细的解释，跟大家分享。
1. 简介
本文关注于一个实施自动化测试框架的组织的主要方面和影响。本文的意图是提供一些能够成功的实施自动化测试的指导方针。
2. 测试自动化的神话
有很多关于自动化测试的神话。其中的一些是真实的，而其他的一些是不正确的设想，这些不正确的设想会严重的威胁到实施自动化测试的成功。
2.1. 我们在时间上是紧迫的 － 项目已经落后了 － 让我们使用自动化测试吧！这种情况将不能成为现实。实际上，正确的思想应该是 － 我们时间急迫 － 我们决不应该使用自动化测试。
如果项目已经陷入到了麻烦之中，不建议实施自动化的功能测试。项目很可能因为需要大量的测试框架的准备和实施会被托跨。我饿建议将重点放在以下的事情上：
优化测试的过程。调查并建议在目前工作基础上的测试方法和过程。建议借鉴 RUP的相关思想和过程。引进或者使单元/组件测试正式化。这是我们能够快速获得受益的很好的方法。如果正式的组件测试被使用，我建议可以使用 Rational PurifyPlus 进行单元或者组件测试。根据我的经验尽早的使用 Rational PurifyPlus 是非常值得的。在一个引入和 Rational PurifyPlus 的项目中，通常会在组件的级别得到 百分之三十的性能提升。仅仅在项目团队能够对 下列问题的回答是"Yes"时：项目能够被适当的推延。存在能够通过实施自动化测试被达到的精确的目标。项目具备建立适当的测试框架的必要条件。
那么，你可以在一个时间紧迫的项目中适当的实施测试自动化。但是根据经验这种情况是很难发生的。总而言之，我只能说"对不起，银弹根本不存在"。
2.2. 测试自动化就是捕获和回放
在过去的日子中，自动化的测试工具只是被看作是一种捕获和回放的工具。当前这个神话仍然在很多测试人员的思想中。而事实上自动化测试已经远不止捕获和回放这么简单了。按照成熟度自动化的测试可以被划分为 5 个级别。
2.2.1. 级别 1：捕获和回放
这是使用自动化测试的最低的级别，同时这并不是自动化测试最有用的使用方式。优点：自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识。缺点：你会拥有大量的测试脚本，同时当需求胡子和应用发生变化时相应的测试脚本也必须被重新录制。用法：当测试的系统不会发生变化时 － 小规模的自动化。
2.2.2. 级别 2：捕获、编辑和回放
在这个级别中，你使用自动化的测试工具来捕获你想要测试的功能。将测试脚本中的任何写死的测试数据，比如名字、帐号等等，从测试脚本的代码中完全删除，并将他们转换成为变量。优点：测试脚本开始变得更加的完善和灵活，并且可以大大的减少脚本的数量和维护的
工作。缺点：需要一定的编知识。频繁的变化可能会引起"意大利面条式的代码"，并且变更和维护几乎是不可能的。用法：当进行回归测试时，被测试的应用有很小的变化，比如仅仅是针对计算的代码变
化，但是没有关于 GUI 界面的变化。你能够使用这种技术通过快速的编制一些测试脚本以检验你的想法来探索你的预定的测试设计。当我在没有任何象需求或者设计模型这样的文档的情况下第一次操作一个产品时和我需要获得一系列内部构建版本的稳定性的第一印象时，我使用过这种技术。通常如果适当的软件配置管理（SCM）与良好的内建设计相结合时，使用级别 2 的技术已经足够了。
2.2.3. 级别 3：编程和回放
这个级别是面对多个构建版本的有效使用测试自动化的第一个级别。你需要在实际的投资开始显现之前确保团队和客户对项目的安全感。如果没有对测试自动化工具的适当的培训测试人员将不具备到达这个级别的能力。在自动化测试工具中的所有测试功能都必须被很好的理解，并且要掌握测试脚本语言的知识。好处：你确定了测试脚本的设计。适当的设计是必要的。编码的习惯必须是适当的。使用与开发中相同的编码习惯是非常好的。这将开始搭建起测试和开发之间的桥梁。在项目的早期就可以开始自动化的测试。你能够在项目的早期就开始进行测试脚本的设计。与开发人员交并调查他们认为可能会存在问题的区域。确保了开发人员关注在获得能够被测试的方案上。缺点： 要求测试人员具有很好的软件技能，包括设计、开发等。用法：大规模的测试套件被开发、执行和维护的专业自动化测试。级别 3 使你能够使用自动化测试并构建不同的回归测试（重用已有的自动化测试
用例）。根据我的经验在看到更多切实的回报之前，为了达到这个级别，有大量的工作和影响项目的活动必须被做。因此快速的建立和证明自动化测试的价值是至关重要的。找到乏味的测试（例如，边缘测试和特定的功能测试用例是首先进行自动化测试的良好候选者）。首先创建少量的能够测试一些基本功能（比如，登陆和创建用户等）的测自动化测试用例。
2.2.4. 级别 4：数据驱动的测试
对于自动化测试来说这是一个专业的测试级别。你现在要利用测试工具提供的所有的测试功能。你拥有一个强大的测试框架，这个测试框架是基于能够使你根据被测试系统的变化快速创建一个测试脚本的测试功能库的。维护的成本相对是比较低的。你在你的测试中会使用到大量真实的数据。优点：你能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据。缺点：软件开发的技能是基础，并且需要访问相关的测试数据。用法：大规模的测试套件被开发、执行和维护的专业自动化测试。级别 4 要求一些非常良好的测试数据。一个测试人员必须要花费一些时间来识别在哪里收集数据和收集哪些数据。使用现实生活中的数据是最基本的以从测试中得到完全的回报。使用适当的数据将为你提供通常仅仅在项目的后期才会发现的或者是有客户发现的错误的能力。现在你能够通过使用现实的数据开运行大量的测试。
2.2.5. 级别 5：使用动作词的测试自动化
这是自动化测试的最高级别。主要的思想是将测试用例从测试工具中分离出来。这个级别要求有一个具有高技能测试人员测小的团队，这些测试人员能够将测试工具的非常深层次的知识与他们具备的较深的编程能力结合起来。这个团队负责在测试工具中生成并维护测试的功能性，能够使测试工具从外部的来源，比如 excel 表或者数据库中执行测试用例。这种测试概念最初是由 CMG 开发的。与 CMG 方案相比，其他的可能的开放源码的方案有被 Carl Nagle 和SAS Institute 开发的DDE。使用 DDE 的概念，关注点是当在Excel表中创建测试用例的时候，放置使用包括被使用的特定动作词语的一些类型的模板。执行的过程是从 Excel 表中读取测试用例，并将测试用例转换成为测试工具能够理解的形式，然后使用不同的测试功能来执行测试。这个概念变得越来越流，因为测试与用例一起使用是非常有用的。优点：测试用例的设计被从测试工具中分离了出来 － 关注在设计良好的测试用例上。允许快速的测试用例的执行和基于用例的更好的估计。缺点：需要一个具有工具技能和开发技能的测试团队，以提供并维护测试工程（框架）。用法：专业的测试自动化将技能的使用最优化的结合起来如果工具不具备使用内建的对象映射的可能性，那么这个方案对于消除与 GUI 相关的大部分维护成本是优秀的。在一些组织中已经创建了这种方案，并且他们其中的一些已经实现了高度的自动化（60%），并且他们都得到了巨大的回报。如果测试框架是适当的，我们能够使用 excel 来生成实际的测试用例。这个级别对于那些按照正规基础使用用例的组织或者项目来说是非常优秀的。有多少测试用的估计是被需要的，并且当用例适当时需要做的工作也是非常简单的。你可以集中时间来生成第一个包含被需要的"对象映射"的测试用例（主流程）。依靠被测试应用的复杂程度，通常这会花费大约半天到一天的时间。后续的被需要的每一个测试用例大概会花费 15 到 20 分钟的时间，因为通常多数的测试用例可以复制已有的测试用例，并对其进行必要的修改，通常这种修改是有限的。动作词语框架能够通过使用用例使紧密的并行测试用例的开发变得可能。
2.3. 我们不需要培训！
我们所有的人都在某一些方面具有一定的经验，我们没有时间能够花费在使用新工具的培训上。当一个对自动化工具还不是很熟悉的组织或者项目团队开始实施自动化测试时，培训和指导是至关重要的。如果我们允许组织或者项目团队在没有关于应该如何做的任何知识的情况下实施自动化的测试，那将肯定会以失败告终。用于实施自动化测试方案的预算会被超出，测试会被延误并且更坏的情况是自动化测试将被放弃。组织和项目团队需要尽量避免一些认识上的缺陷，尤其是自动化测试的维护成本和当测试人员尝试和确认工具如何工作时产生的挫败感。你需要确保你的测试过程是适当的 － 如果测试过程是不合理的，引入自动化测试只会给软件组织或者项目团队带来更大的混乱。因此，我建议希望实施自动化测试方案的组织或者项目团队应该在实施之前建立"训练营"，并将重点放在培训测试团队能够很好的利用一个原型的项目上。为第一个原型项目制定一个实施计划，下面包括原型项目的最小化的描述：当先状态我们希望实现什么 － 建立成功的因素期待的回报（第一次自动化测试工作被期望验证什么）找到一个"简单的"测试的痛处并尽力的通过自动化测试解决它，这可以被作为在同一时间上使测试运行在多个平台上的样例说明被需要的资源和时间......
一开始你就要大声的说出成功的信心 － 让人们了解你所展示的进展。这将吸引更多的关注和资源。
2.4. 我们必须 100% 的自动化
从管理的角度来说，100% 的自动化目标只是一个从理论上可能达到的，但是实际上达到 100% 的自动化的代价是十分昂贵的。一个 40-60% 的利用自动化的程度已经是非常好的了。达到这个级别以上将增加测试相关的维护成本。由于对每一个构建版本的需求变化的复杂度，你将花费更多的时间在变更测试用例上以使他们能够正确的运行。在这种情况下，通过告知管理层100% 的自动化目标是相当昂贵的来确立一个合理的期望值才是明智之举。对于决定自动化一个测试用例的一般规则是这个测试用例必须被运行 4 次以上。这个数字是基于用户对测试工具有良好的技能并且有一个良好的测试框架的。如果情况不是这样的化，整个数字能够是 10-20次或者更高。一个例子，在一个项目中测试人员花费和两周的时间将手工测试的 23天的任务转换成了自动化测试的用例。在完成使，项目能够在 4 个小时在多个平台上运行相同数量的测试用例。
2.5. 测试框架
测试框架对于产生成功的测试自动化的适当基础是重要的。很多考虑必须被解决以使测试自动化更加有效地被使用。重点必须在：维护成本维护成本是成功的使用自动化测试的最重要的问题之一。维护成本直接联系到前面已经提到过的自动化测试的成熟度。组织或者项目必须至少要在成熟度的 3 级使用高度的测试库才能使维护和更新测试功能变得容易。
测试数据
什么样类型的数据将被使用？要为每一个测试用例生成测试数据还是使用在被测试应用中已有的数据。在很多的情况下一个测试数据被创建了，删除他们是不可能的。
可测试性
自动化测试方案能够有效的测试吗？例如，被适当命名的对象（不仅仅是索引Id）。一个简单的例子是所有的对话框都有相同的 ＃id 和相同的标题，所不同的仅仅是显示的文字信息。当测试应该覆盖多种语言的方案时，对话框的测试就是一个挑战。
测试人员的技能
被包括在自动化测试的创建中的人员应该具有什么样的技能呢？如果他们具有良好的开发背景，那么成熟度 3 级是足够了。如果他们有很少的或者根本没有开发的经验，我们被迫使找到或者培训一个自动化测试专家的小组，并直接到达成熟度 5级，在成熟度 5 级测试的创建与实际的测试执行被分离开。
一个好的构建过程
自动化测试的引入在"构建团队"上加入了一些约束。为了实现自动化测试的高利用率（回归测试），要求具有一个高的构建频率。每周仅仅运行自动化的测试不是好的自动化测试的使用率。将回归测试增加到每天一次将帮助快速的发现新的问题并使开发人员更加容易的发现问题的根源，因为对测试的反馈时间是比较短的（开发人员能够记住他们昨天做了什么）。所有权不同的测试库的所有权的定义是重要的。一个好的方案会将测试库的组织划分为三个级别：
级别 1 － 全局的
这个一个通常的级别。被存储在这个级别的测试功能能够被所有的项目访问。通用的和通常的功能象登陆、创建一个用户都是这个级别很好的候选者。
级别 2 － 项目
在这个级别的测试功能是与特定的测试项目相关的，但是通常在项目中有用的比一定在项目外是有用的。通常级别 2 是级别 1 的功能的提供者。
级别 3 － 脚本
功能被直接关联到特定的测试脚本。 I在这个级别中，通常一个测试功能的第一个版本是被开发的。在新的测试脚本的创建期间已有测试功能的重用性被发现，并被移到了级别 2 中。在这个级别上尽量最小化功能的数量，因为它将增加维护工作量。还有很多有关测试框架的问题，但是这里所提及的是一些基本的要被解决的问题。
3. 在哪里使用自动化测试
有很多的情况下使用自动化的测试可以降低测试成本。我将尽量的突出在自动化测试中的不同的测试技术技术 描述 备注单元测试/组件测试 这个测试工作通常是开发人员的职责，很多不同的方法能够被使用，比如"测试先行"，它是一个测试框架，开发人员在编写代码前编写不同的单元测试。当测试通过时，代码也被完成了。 通过使用正式的单元测试，不仅能够帮助开发人员产出更加稳定的代码而且能够是软件的整体质量更加的好。冒烟测试 冒烟测试是一般验证别测试系统的功能性测试用例的集合。冒烟测试背后的思想是确保基础是可以工作的，以便"大的"测试工作能够开始。 在构建过程能够确保构建已经为测试准备好时，冒烟测试通常是自动化的运行。功能/集成测试 这里测试的工作关注在验证在不同的组件之间的集成上。 这些类型的测试通常是被测试系统的更加复杂测试的基础，大量的边缘测试被合并以制造出不同的错误处理测试。系统测试 － 用例测试 这种测试是通过执行用户场景模拟真实用户使用系统以证明系统具有被期望的功能的测试。 这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的，因为系统的环境是恒定不变的。回归测试 回归测试实际上是重复已经存在的测试。通常如果是手工完成的化，这种测试只在项目的结尾执行执行一到两次。 这里完全有潜力应用自动化的测试。你能够在每次构建完成后执行自动化的回归测试，以验证被测试系统的改变是否影响了系统的其他功能。性能测试 性能测试包括以下不同测试形式：
- 负载测试
- 压力测试
- 并发测试
-.....
如果没有自动化的测试工具，你将不能执行通过模拟用户的负载实现的高密集度的性能测试。
4. 什么时候使用自动化测试
我对什么时候应该使用自动化测试和什么时候应该使用手工测试进行了一个概要的总结：使用自动化测试 使用手工测试项目没有严格的时间压力具有良好定义的测试策略和测试计划你直到要测试什么
你知道什么时候测试对于自动化测试你拥有一个能够被识别的测试框架和候选者能够确保多个测试运行的构建策略多平台环境需要被测试你拥有运行测试的硬件你拥有关注在自动化过程上的资源
被测试系统是可自动化测试的 没有适当的测试过程没有一个测试什么，什么时候测试的清晰的蓝图在一个项目中，你是一个新人，并且还不是完全的理解方案的功能性和或者设计你或者整个项目在时间的压力下在团队中没有资源或者具有自动化测试技能的人没有硬件如果你正在从事自动化测试，那么一定要记住要关注将自动化测试与手工测试结合起来使用。首先，对于自动化测试率的目标是 10/90 （10% 的自动化测试和 90%的手工测试）。当这些目标都实现了，可以将自动化测试的使用率提高。记住创建自动化测试的测试用例要比创建手工测试的测试用例花费更多的时间。不要将你所有的测试时间都用在自动化的测试用例上。同时也要记住在测试期间对每一个被发现的错误都要花费一定的时间去处理。
5. 自动化测试的好处如果你正在你的组织中引入自动化测试，记住有很多不同的方面被包含了进了。今天在测试工作如何被进行上有很多不同的视图。为了能够成功的实施自动化测试你应该提出这些问题：
测试覆盖什么？－ 我们没有覆盖什么？
由于遗漏的测试我们没有发现的"bug"会带来什么样的成本？由于不好的测试，破坏已有功能性的成本是多少？如果"琐碎的"测试被每天的运行，对于你的项目意味着什么？如果我们能够每天向开发人员提供他们最近代码变更相关的反馈，对项目有怎样的影响？这些问题都能够被自动化测试满足。你必须从自动化测试成熟度的级别 1 或者 级别 2 开始，并开始测量结果。根据我的经验快速的向开发人员反馈并每天运行测试对于向自动化测试成熟度的级别 4或者 级别 5 是非常有好处的。
自动化测试有以下的贡献：
降低风险 － 你知道你测试了什么和没测试什么测试能在项目的早期开始并随着时间一直扩展快速的反馈 － 自动化测试用例能够随时的运行在多个平台上的测试能够同时进行
更好的估计 － 你能够对测试进度和被使用的时间有更好的了解优秀人员的集中 － 你能够得到一个专家的团队，并将他们的知识传播给其他的项目喜悦 -你和你的团队正获得着成功
测试工具介绍下面我介绍市面上相对比较广泛的测试软件，Rational中的Robot和MI公司的WinRunner的具体的用法。
Robot，俗称机器人。它有几个特点，第一，Robot它的语法相对简单，是一种类似于VB的语法，所以上手快；第二，Robot的脚本组织结构类似于C的结构，相对容易理解；第三，Robot运行环境和可参数化，所以容易维护；第四，要求的机器配置相对较低；第五，Rantional系统集成的很多产品很优秀，而且适合面很广；第六，相对价格比较低廉。
WinRunner的功能相对Robot相对来说有一下几个特点。
第一， WinRunner的语法结构是类似于C的语法，理解相对容易；
第二， WinRunner的脚本组织形式是以目录的形式组织的，所以相对来说比较好管理；
第三， WinRunner支持当前市面上的很多系统；
第四， 可以随时Update检查点的内容，使得脚本的维护量减少
第五， 机器配置相对要求高些；
第六， 集成了很多优秀的组件。
下面我就尝试写一个Robot的脚本。
题目：请检查各种我们规定的字符是否过滤掉了，如果那些词语没有过滤掉请记录下来。我们先看测试这个功能的逻辑关系图应该如下：
测试脚本：
Function T_OpenTestFile(Filename as string)as integer
{
。。。。。。。。。。。。。
}
Funciton T_FilterWord(getword as string)as integer
{
。。。。。。。。。。。。
}
以上是两个SBL文件，相当于C中的函数实体
那么我们要建立一个SBH，相当于C中的头文件，红色的部分类似于一个类库，我们把相关的或者具有相似属性的操作或者函数定义在同一个类库中。
Declare Function T_OpenTestFile Basiclib T_FileOpertion(filename as string) as integer
Declare Function T_FilterWord Basiclib T_FileOpertion(getword as string) as integer
我们现在建立一个脚本文件REC
＃include T_FileOpertion.sbh
Main()
{
。。。。。。。
}
在此脚本中就可以调用上面那两个函数了。在以后的测试中，我们只需要维护过滤词文件库就可以了。这样提高了工作效率，保证了测试的正常进行。
下面我就举个例子，来尝试用WinRunner的使用方法，其实例子相对很简单，主要是想告诉大家这种语言脚本的组织方法是怎么样的？
压力测试工具的功能挖掘使用。
一、为什么采用插件脚本开发
性能测试过程中，最耗费经历的就是编写性能测试脚本的过程，在大部分的测试工具中都是采用录制的方式，通过录制产生脚本，然后根据需要进行修改，以及参数化。有些时候为了能够完成某一个功能的脚本，需要将录制下来的脚本进行大手术，例如将一些逻辑以脚本的形式写在LR里面，给编写脚本的人带来了很大的麻烦。目前部门的大部分业务在性能测试过程中都是采用录取请求信息包的模式来模拟请求。
其实LoadRunner是提供了COM组件的调用的（图一），你甚至可以在引用了LoadRunner的组件，继承相应的接口后，重写LoadRunner的很多方法，比如我们熟悉的lr_start_transaction、lr_rendezvous等方法。
（图一 LoadRunner提供的COM组件）
这样有什么好处呢？
能够更有效的、更灵活的构建可被LoadRunner调用的脚本或者压力测试程序
我们可以定义自己的调用类及方法、比如自己封装好的socket类、而对于不同的业务只需要传送不同的调用参数而已，避免了每次的测试过程都要去录取烦琐的脚本再在脚本中更改，而且执行效率要高于录制的脚本（直接录制的脚本是解释执行）
生成的脚本可以突破LoadRunner本身的很多限制
我们知道的LoadRunner在应用的时候是有很多限制的，比如：C/S 协议的license的个数限制、负载生成机器单台最大只能运行1000个虚拟用户，而采用插件脚本开发的形式可以突破这些限制
可以抛开第三方的工具、自己实现压力测试工具
插件开发脚本实际上是生成了Virtual User Generator的功能，但只要增加并发调用的程序，就可以实现了Controller的功能，如果是采用.net(C#)开发语言就可以构建线程安全的并发生成工具
二、插件在IED环境中的使用
利用Loadrunner Add_In的方式进行脚本的开发，如果想采用这种方式是需要有几个前提条件的：
􀁺要有被测试程序的源代码
􀁺被测试程序的架构要清晰，对于一些分层不够好的产品，不太适宜用这种方法。
􀁺编写脚本的人员要了解Loadrunner的使用
使用：…\Additional Components\IDE Add-ins\MS Visual Studio .NET ，安装文件：
LRDotNetIDEAddInSetup.exe
在开发环境中会产生新的菜单项 如图二
（图二 IDE中的Vuser）
菜单中会多出一项【Vuser】的菜单。这个菜单就是我们主要使用的内容。另外，在对象库中也会增加loadrunner相应的对象。这些对象的使用和软件中其他对象的使用没有什么分别。这些对应都是可以被loadrunner所识别的，同时也是可以并发安全的
这样就可以新建LoadRunner工程了
增加必要的内容：
框架生成后，我们就需要根据测试的内容增加相关的代码了，下面介绍的函数都是以c#为例进行介绍的，其他的语言与此差不太多。
我们假设一个场景：要测试100个用户同时登录系统的情况。后面都将围绕着这个主题进行。
首先，无论使用什么内容都要先进行对象的创建：
LoadRunner.LrApi lr;
lr = new LoadRunner.LrApi();
1、 事务
事务是测试最核心的单元，所以事务的创建非常重要，下面是一个事务的定义过程。
LoadRunner.LrApi lr;
lr = new LoadRunner.LrApi();
lr.start_transaction("syslogin"); //事务开始,事务名称为syslogin
//×××××此处添加事务syslogin的程序，例如：××
Client_syslogin(“servername”,”Username”,”userpassword”,”2005-1-12”);
lr.end_transaction("syslogin", lr.PASS);// 事务结束
事务的开始和结束与VU Generator工具的脚本基本上是一样的。
具体的使用不做详细阐述了，网上也有相关的教程
三、举个实际测试的例子
InSoket类是封装好的SOCKET请求类 包括异步连接、异步发送请求以及异步接收数据等
Vuser类 是具体的请求调用 包括一些请求方法及重载、事件委托
以上只是对方法可行性做了研究 具体业务的封装要复杂些。
示例代码如下：
还有一个实际例子，就是针对一个业务我们进行的测试，分享给大家。
某金融服务器性能测试方案
测试说明
模块说明tcpsvrd
客户端统一通讯接入前置机，根据server type和server id来识别接入的客户端，如果type是Client则id为uin，如果是内部server则同一个type和id只能建立一条TCP连接，若有多余连接则会拒绝其接入。
financesvrd
目前暂时只测试3条消息，Deposit（存款）、Consume（消费）、Query（查询）。Deposit和Consume会直写DB，Query则先会查询Cache，再查DB。
Test Server
可以是LoadRunner的Controller，也可以是自行开发的TestServer，主要负责控制各个TestClient启停。
Test Client
可以是LoadRunner的VUser，也可以是自行开发的TestClient，主要负责开多线程快速发送消息。
工具说明
LoadRunner
两种方案：
用Web协议加载DLL
License有10000个，并发时每50个VUser启动1个进程50个线程建立一条TCP连接共同向一个端口发包，运行时必定会采用同步机制来竞争资源（这种方式和单线程+延时+循环发包的压力效果是否类似？是否做到了真正的并发？）因此最多只能建立10000/50=200条TCP连接。如果要测试向tcpsvrd建立大量连接显然是不行的，只能测试向tcpsvrd发送大量请求。
用Windows Socket加载DLL
受100个License限制，并发时每个VUser均会启动1个线程建立一条TCP连接发包。在License数量无法增加的情况下，很难做压力测试。
从目前的调试结果来看，用LoadRunner加载DLL的方法来测试C/S架构不太乐观，存在着一定风险。
ethereal/sniffer
测试准备阶段用于调试脚本、测试程序
测试执行阶段通过在服务器端抓包，来分析整个加压过程。（如果测试时间长时，抓包文件会很大，增加数据分析的难度）。
另外，也可以用于协议测试。（不知道开发做了没有，做到什么程度？我们是否可以介入？）
统计工具和脚本
服务器统计工具sonicmao已经提供financetool –s0/s1 (复位/统计)，能够统计客户端发送消息数目，Cache命中率，数据库的处理时间等性能指标。
服务器性能指标分析工具，沿用joeqiu提供的rstatd
目前缺少数据库的记录插入/复位工具（由开发完成？还是自己解决），后台日志的查看只能通过人工分析日志文件，是否提供相应日志分析工具？（此需求重要级别：低）
测试程序
首先要开发一个TClient作消息发送器（难度不大，容易实现），要想加入控制功能还需要开发一个TServer的控制器，用于控制各个TClient的启/停，接收各TClient的上报消息。（关键是如何设计，做到最大限度的复用，此需求重要级别：中）。
最好是服务器为TServer定义service type和service id，直接允许其接入，由我们来定义测试消息，通过发送查询消息直接搜集服务器的当前信息（取代后台统计工具financetool），这样就可实时监控服务器当前的业务处理性能。（此需求重要级别：低）
测试内容
tcpsvrd
单台服务器最大承受接入连接数
目的：测试不同硬件配置下tcpsvrd的接入能力，得出结论XX配置下可以承受XX个接入
方法：用测试程序模拟n个Client接入tcpsvrd，按正常使用频率（需要和开发协商做一个大致的估算，如果不能确认，则只统计结果）在10-30分钟内定时向financesvrd发送固定消息（消息类型个人觉得应该是查询消息）。
数据记录表格（参考）
测试通过条件：CPU占用率Max<70%，LoadBalanceMax<2，MemUser<1G (需讨论或查找相关资料)
单台服务器最大承受消息数（峰值压力）
目的：测试tcpsvrd在业务高峰期转发消息的能力，得出结论tcpsvrd当消息速度达到XX个请求/秒（或流量达到XXkbps）时，需要进行在网络设备上进行流量控制。
方法：用多台机器向tcpsvrd连续发包，持续时间5-20分钟（服务端的峰值压力如何计算？如果用tcpdump抓包可能会影响服务器的业务处理能力）
数据记录表格（参考）
测试通过条件：与2.1.1类似
单台服务器长时间承受消息数
目的：测试tcpsvr长时间运行所能承受的消息数，得出结论给出tcpsvrd的推荐处理速度，tcpsvrd当消息速度达到XX个请求/秒（或流量达到XXkbps）时，需要在软件上进行流量控制。
方法：用多台机器向tcpsvrd连续发包，发包速度可以参考2.1.2给出，持续时间2小时以上
数据记录表格：与2.1.2类似
测试通过条件：与2.1.2类似
financesvrd
服务器的业务处理能力
在对tcpsvrd进行测试的同时，可以顺便得到。时间允许的话需要对deposit、consume、query全部进行测试。否则只测试query消息。
DB
目的1：测试Cache命中率对其进行调优，得出结论命中率为100%时应该配置多大的Cache，命中率为90%时应该配置多大……
目的2：测试直写数据库时是否会有I/O瓶颈，CPU占用过高？
方法：数据库事先要插入一定数量的记录（具体数量是多少？10w,100w），先配置较小的Cache用多台机器连续发查询包来得到命中率和发包速度的关系，再逐渐调大Cache找到两者的映射关系。
在发写DB请求时，最好能建立请求速度和CPU占用率/内存使用/负载的经验匹配值。
以下内容在相关技术问题未解决之前先暂时不考虑
测试工具在实际工作中的应用 现在在测试行业说的最多的有两个问题，第一个问题是测试的待遇和地位，第二个问题是自动化问题。我这里不谈测试的地位，只谈自动化测试。
如何做好自动化测试？这里给出几个分析方法，第一，被测试产品是否有延续性？第二，被测试产品的维护频繁度？第三，被测试产品自动化的难度如何？
其次，如何选择自动化工具，选择容易上手的，测试脚本和测试数据容易维护的，价格低廉的。
正确的理解测试工具需要我们去引导，我们应该清楚的知道那些应该自动化，那么能自动化，那些自动化程度会更高等。
工作中的自动化测试的几中方法 数据驱动法 数据驱动是测试中最常用的一种方法，它是在不修改测试程序的情况下或者稍微修改测试程序的情况下，不段的增加测试案例来进行自动测试的一种方法。
举一个具体的例子：例如我们检查登陆验证（用户名称），
如果我们采用自动化测试，我们只需要在测试配置文件中增加或者删除修改配置文件就可以达到测试的效果了。
只要将两个文件进行比较，就可以得到被测试程序的处理能力和结果了。
桩驱动桩驱动也是一种常见的测试方法。这种测试方法是把某个模块假设是正确的，然后把这个模块作为主核心，然后测试他传出的参数和数据给其他模块来处理，查看处理的结果。
我那EXCEL中数据举一个现实的例子，大家都知道，当你输入等号的时候，Excel认为你需要计算，那么处理流程就应该是接受键盘消息，然后处理。如果我们把输入做为一个桩，那么来查看计算结果的话，就可以知道那些信息处理了，那些信息没有处理。
桩驱动的核心其实很简单,就是首先对桩模块做一个假设和详细测试,认为桩模块是足够健壮的;第二,桩模块是驱动机,能够和很多模块发生调用关系,是核心部件.
关键字驱动 关键字驱动和桩驱动有些相似的地方，关键字驱动的核心是
网络方面的测试方法 数据库测试要点网络游戏测试要点 下面我和大家探讨网络游戏的测试方法。网络游戏是一个信息相对集中的一个网络产品，它牵扯到客户端和服务端以及客户端之间的通讯。下面我们就结合具体的例子来分析
我举一个Mmog的例子（注：mmog是大型网络游戏的缩写），大型网络游戏主要是即时战略性质的，所以通讯上采用TCP协议来发送数据包。TCP协议发送数据包的优点是尽量能够减少数据包的丢失，他是对数据包的一个精包装，一般的发送数据包采用实时处理的形式，即采用堵塞式的处理模式，而不是等到一定空间的数据包满了以后才一起发送（非堵塞式的处理模式）。
上面我们只是简单的讲了mmog游戏数据包发送的形式。下面我们分析网络游戏服务端测试的重点。
网络游戏服务端的主要作用：下发玩家信息，仲裁胜负信息，仲裁装备信息，服务器之间中转信息，状态存盘，玩家信息存盘等。我们来一个个的分析，服务端要处理这么多的事情，在处理什么事情的时候压力最大呢？那肯定是下发玩家信息最大，为什么这么说呢？因为在下发玩家信息的时候，服务端会把每个人的信息和地图上的所有的信息，而且这个信息是当地图上的玩家和元素的增多而增多，当地图上的人越多的情况下，服务器的处理信息的量就很大。那么分析这么多，我们主要测试什么？测试同步消息的传递。就是在很多玩家的情况下，信息能否顺利的通知给各个玩家。
如果做这样的事情呢？根据经验（可以另外想办法），建议编写一个机器人，我们能够操作机器人，这个机器人需要处理什么事情呢？希望机器人能够在以玩家为中心的地方随意走动，能够跟随玩家跨地图，能够按照设定施放技能，能够聊天。通过机器人的每一个动作我们来观察服务的各个性能表现。关心那些性能表现？大家可以参考LoadRunner提供的业界比较官方的指标进行核对。
网络游戏服务端的测试相对比较复杂，对测试人员的要求比较高，测试人员必须了解用什么协议通讯的，怎么通讯的，服务器都处理了那些事情才能具体的分析测试重点和测试方法怎么做。
对于客户端的测试应该相对简单些，我这里说的客户端的测试不包含数据平衡部分。客户端主要是验证功能逻辑。例如我举个例子，任务系统，现在每个游戏都有任务系统。如果测试任务系统，我们应该怎么测试？首先完成任务的条件是什么？完成任务需要什么道具？玩家能得到什么道具？道具是否可以交易，拾捡？道具是否可以买卖？玩家跟NPC交付任务断线处理？NPC在不同的状态下所说话的内容？是公共任务还是门派任务？在得到道具过程中储物箱满了会怎么处理？在负重超出了本身能力的情况下怎么处理？等等，把细节的问题考虑清楚了，这样设计案例执行就是了，没有自动化的必要（但是可以在组件测试中进行自动化，系统测试没有必要自动化）。
客户端还有一个测试点就是地图，因为地图是游戏的门面，所以地图的检查点：绚丽度，整个地图的亮度，不同分辨率下的地图显示，地图的拼接，地图上NPC或者怪物的分布等等。网络游戏的测试是积极具有挑战性，包括能力，耐力，创造力的人奋斗。
我们把平常大型网络游戏容易出错的地方整理几个跟大家分享。
举例1
大家都知道在游戏中，每个玩家都有自己的背包和储物箱，如果知道网络游戏的人应该都了解，这个是玩家存放自己装备或者基础材料的。这个储物箱在游戏中应用非常广泛，所以玩家也在寻求办法，钻设计的漏洞，以便刷物品，使得自己的虚拟物品和价值持续走高。
关于背包，我们有一款游戏中是这么设计的，收集材料同类的可以叠加，武器类的不可以叠加。
我们来看这个问题，如果可以叠加，意味着只要有同类的物品，就当你存放的时候叠加到一起。但是
还有一种是休息类游戏，例如盛大网络的泡泡，客户端之间主要是通过UDP进行通讯。关于UDP通讯的检查和测试我在这里先不做详细描述，以后进行补充。
网络游戏的核心是什么？网络游戏的核心是构造一个虚拟的社会，让这个社会上的各种职业的人能够生存并附带一定的社会矛盾。那么在这么庞大的项目中，我们测试需要关注的点是什么呢？
C/S结构测试要点 网络游戏现在是C/S架构的一种，但是我们平常所说的C/S是一种类似于银行系统，购物系统等，这种系统要求：服务器处理能力强，反馈及时，但是有一个特点，这种服务器压力是出现在业务繁忙的时候，所以在测试这种软件的时候，需要完全弄清楚业务逻辑，业务点在那里？信息同步在那些方面需要关注？服务端数据处理流程是什么？如果把以上问题搞清楚了，测试的重点也就出来了，这里我不再举具体的例子，因为C/S架构的软件是相通的。
下面我就举个例子,给大家看看,关于C/S架构的mmog类型的游戏测试,服务器的压力那里,测试的重点在那里?
请大家看下面的图形,这个图是目前市面上90%以上mmog类型游戏采用的结构.
我把上述的图形描述一次:
当客户端要求登陆服务器的时候,通过账号数据库验证,然后取出该账号对应的角色,然后告诉客户端你是我们的用户,然后由网关(我在图上没有体现)把该玩家连接到响应的GameSvr上.
我们来分析这个图:客户端向服务器发送登陆请求,如果采用非阻塞式,使得各个客户端的请求形成非队列式,那么服务器压力不会很大,如果采用阻塞式,那么客户端感觉服务器处理速度就会很慢,玩家不答应,所以大多采用非阻塞式,处理速度快.而且玩家和账号数据库不是长期保持连接,只是保持一个心跳而已.这样就得出一个结论,用户在登陆的时候,对服务器不会造成多少压力.
那么什么时候会造成压力呢?
玩家走路,大家都知道,网络最主要的特点是同步信息,也就是说,当一个玩家走动以后,服务器首先要计算一次,当前玩家指的坐标是否正确,其次,服务器要下发消息,告诉周围的玩家,他现在在那里,怎么样的姿态存在.因为服务器会给一定范围内的玩家通知这些信息,造成服务器压力增多,因为服务器(GaemSvr)和玩家保持的是一个TCP的长连接,如果当前服务器或者一屏(或者说一定范围内的玩家相对比较多)的情况下,服务器要处理当前服务器上类似于上面描述的若干个这样的情况,造成服务器压力巨大.
除了走路,还有什么会造成服务器压力大呢?
聊天,为什么说聊天会造成服务器压力比较大呢?因为当A对B说话,服务器需要寻找,当前B在那里,然后通知A,B在,你可以说话给他,这个时候A才可能和B说话.如果人相对比较多的话,可能造成服务器压力大.
跨服务器行走,也会造成服务器压力巨大?
因为当你从一个服务器跨到另外一个服务器的时候,服务器需要把第一个服务器上玩家的数据拷贝的另外一个服务器,然后初始化一个实体,然后再告诉DB,把这个人的数据存盘一次,然后再尝试跨服务器,如果跨不成功,如果成功,则把该数据初始化给本玩家,如果不可以,则另外处理,这样造成服务器的压力大.
总上所述,不是所有的C/S结构的产品,我们以上来就模拟人多的情况怎么样,而是要分析,那块的压力真正的大,压力大的情况下会影响到游戏逻辑和数据在那里?需要冷静的分析这些情况,才可能有效的执行测试.
综上所述,我们知道网络的测试重点是相同通讯,数据同步和存储,那么在进行测试的时候,需要熟悉的了解各个部分相互通讯的模式是TCP还是UDP模式,那么各个模式有各个模式的特点.
TCP是通讯协议是把数据包进行精包装,然后在网络链路中进行发送,它需要进行三次握手才可以确定数据包的发送与否,丢包的几率很小,但是自身有补偿机制,使得包数据传输的过程中可靠性大大加强但是缺点是速度相对很慢.
UDP通讯是另外一种数据包传送模式,这种方式的特点是传送速度快,但是容易造成数据包丢弃.
所以除了了解各个部分的通讯协议之外还需要了解,当丢包了以后,对数据包进行补偿的两种方法,第一种方法是把从丢失的第一个包到当前包作为一个整体的包,进行包的重播,这样的方法会使得从客户端看到通常我们在游戏中所出现的”卡”现象,还有另外一种补偿机制,就是把前面的数据包丢弃,然后播放最后一个数据包信息,这样就会在其他的客户端看到一些莫名其妙的现象.
网络游戏还有一个测试点，任务系统的测试，在网络游戏中，任务系统是贯穿整个世界的，他反映了玩家在各个时期所能面临的挑战。任务系统的测试要点
Ø 任务逻辑
Ø 任务性价比
Ø 任务系统奖励的条件
Ø 任务系统放弃的条件
Ø 任务系统接收物品的条件
Ø 跨等级交接任务
Ø 满足接或者交的任务的条件中其中的一个
Ø 任务描述，任务记事本的描述和状态，任务道具的各种操作
为什么把任务系统单独提出来说，是因为在游戏中任务和交易是游戏中最容易出错的地方，而且最容易导致整个游戏中所谓刷钱的地方，如果游戏中通货膨胀，就可能造成整个游戏数据无法跟踪或者跟踪没有意义。
箱子也是重点测试之一，所谓箱子，主要是指玩家的储物想，交易时候玩家的背包，为什么把这两个单独提出来，这两个在几中情况下最容易出错。
Ø 给箱子存东西，然后断线（考虑存储速度）
Ø 给箱子存东西后，然后不关闭箱子，背着箱子跑（触发存储状态的条件）
Ø 交易的时候，来回切换server，在两个server之间进行（寻找数据同步的错误）
Ø 在存储物品以后，马上断线，然后在server和client保持ping的过程中，重新连上（考虑TCP/IP的特点）
Ø 在存储物品的时候，不关闭储物箱，可以背着箱子乱跑（箱子其实计算到了玩家的负重了）
以上是存储和交易时候必须测试的点，这是每一款网络游戏都容易犯错误的地方。
在做压力测试的时候大家都知道很多概念，但是在实际的工作中怎么分解，了解得人还不是很多。我下面给大家做一个简单的介绍，因为我们在做压力测试的时候，如果在公司内部构建和我们产品运营时候相同的网络环境，相同的硬件支持的话，开销非常大，有些开销是无谓的，所以就出现了现在有的作压力测试的时候，得出结论是现在环境是否可以承受或者说能够承受到什么程度，关于压力测试的分解工作几乎没有，为什么做这些压力，这些数据对你以后有什么分析价值等我们做过透彻分析。
很多人在使用诸如"容量评估"，"容量计划"，"趋势分析"和"预测" 等术语时，并没有真正理解这些词汇的含义。当有人提起"容量计划"时，通常是指他们的应用不能满足解决方案，而将被迫购买更多的硬件。
我们需要针对具体业务做一个实际的例子，可能大家能够看的更加明白。
业务描述：
硬件基本情况（服务器和未来上线的不同）
我们就分析一个业务，它是一个标准的C/S结构，我们从他的业务逻辑上分析它的压力点在哪里？然后结合实际情况，我们总结分析设计这些压力测试的点的方案。
那么根据业务本身，看来登陆的压力肯定是最大的，因为当登陆上去以后，玩家根据业务和本身需求，可以把各个服务器的压力减少进行调整，那么如何做和登陆服务器的压力测试呢，我们在开始工作之前需要获得几个数据：
第一， 按照原来服务器的设计，最多能容纳多少用户并发请求
第二， 对服务器性能占有率多少是能够接受的
第三， 对信息的处理方式是采用什么方式的（阻塞还是非阻塞）
第四， 单台服务器的处理能力和效率
接下来我们要做的事情就是：
第一， 准备测试数据
第二， 设计测试方案
第三， 总结测试数据进行分析
如何准备测试数据才能使得本次测试的有效性呢，主要分析我们的业务类型，以上图这个例子，我们只要发送一个合理的登陆请求，只要是一个合法的帐号就可以了，我们按照协议类型，开始制造测试数据，制造完成后我们来分析我们如何加压，假如我们的按照目前的规模服务器的处理能力是20000，按照5台来计算，那么单台服务器的处理能力是4000,那我们就开始利用单线程多进程的方法或者利用多台单客户端的形式伪造数据，然后让这些请求数据按照阻塞模式同时发送，可以制造同等压力，在这个过程中我们需要做的事情
第一， 我们需要观察服务器的I/O,内存，CPU
第二， 我们需要观察服务器对信息的处理能力（需要通过客户端对发出信息后得到服务端信息的反馈进行累积统计），长时间观察这个数据的变化，例如1个小时
第三， 慢慢减少压力，看看效率情况
如果在我们加压过程中服务器的cpu和内存持续增高，说明有漏内存，如果我们请求响应速度持续变慢，说明server队信息的处理能力可能有问题，如果在减少压力的过程中仍然表现不出来server的处理效率提高，说明server没有释放资源。
其实服务器的压力测试，在我看来，无非要做两个事情，你需要清楚的了解此类业务的服务请求，其次，你需要清楚地了解各个数据分析的过程。
WEB测试要点 Web测试的要点其实很多，但是Web测试的着力点其实不多，因为基于Web现在有两个重点，一种是基于平面的静态的，只是更新新闻，那么这个的测试点相对简单，主要是各个链接正确性，服务器浏览量等，还有另外一种就是基于Web的P To P的通讯，需要注册，牵扯到用户信息，那么这些测试重点在于P To P通讯的顺畅性，数据的可靠性。
我还是举例子说明问题。1999年网络在中国起步并风靡，它丰富了人们的生活，提供了更多的咨询信息。各种基于互联网的业务也相继展开。那么这些业务上线面临着什么?
就web测试点来说，有一些特别需要注意的，url地址，看似一个连接地址，非常重要，重要在那里，因为URL是包含了用户请求的信息的跳转，所以URL包含了部分用户的信息。
测试的时候需要注意几个问题
² URL所有包含用户信息的牵扯到用户隐私的需要加密
² URL中包含用户信息切牵扯到双方数据交互的需要完全信赖的确认信息
² URL需要过滤一些通用的字符，例如”.”,”.\”等，以免对服务端目录造成伤害
² 在页面中需要检查的内容：页面中所有的编辑框中需要跟内容匹配，有人恶意在里面输入SQL的语句，使得其他的信息就暴露在外面
² 删除server系统下的bak文件，原因是商家一般会做一些市场活动，那么会暂时的生成一些页面，到活动结束后，把正式文件删除掉了，但是备份文件没有删除，所以就会造成用户还可以访问被废除的活动页面。
² 有关验证的内容，建议服务断和客户断双重检查，以免有些伪装数据欺骗客户端代码，造成server不经过验证的情况下提供数据
² 需要对Cookie中的数据加以包含，一般的用户对这个数据不注意，也无法意识到他的重要性，所以经常被别人利用，所以商家需要保护消费者的数据安全。
² 在接收传递过来的服务端程序对数据类型需要进行判断，包括长度和类型，以免出现“string overflow”。
我下面就说几条：
第一， 性能，性能测试什么呢？
性能主要是指网络吞吐量，响应时间（单用户单独和单服务器能承载用户上满情况下单用户相应），IO量的大小，数据库查询速度。
包括一下几个方面：
第一， 单个用户发送单步请求到处理完成所花费的时间；
第二， 单个用户发送请求整个流程所需要的时间
第三， 在服务器负荷达到单个服务器处理能力情况下单步请求响应时间
第四， 在服务器负荷达到最高的情况下，整个流程处理请求处理的响应时间
第五， 在请求达到负荷的情况下IO量的大小，知道输入输出量的大小，以及写磁盘的频率
第二， 安全性
安全性主要包括当前用户的安全性，总体用户的安全性，提交过程数据的安全性，用户数据的死锁现象等。
现在我们分析基于Web形式，用户发送请求，在发送过程中有可能出现什么问题呢？用户的数据在以网络包传输的过程中和在队列中等待处理出现问题？基于web的特性，我们平常所能触到的就几种做法（普通，非高手），第一，分析和修改URL地址，导致真正的请求被修改；第二，拦截数据包，修改数据包信息，导致真正的请求被修改；第三，攻击服务器，使得等待队列中的请求信息被修改。
第三， 操作合理性
² 操作过程是否合理，包括操作流程，操作的易用性等多多考虑。
² 人性化，包括页面的层次重要信息页面的引导，页面的跳转
² 内容链接，内容的更新频率包括排版
这种方法类似与工业领域的随即抽取统计分析法，但是工业性质牵扯到损坏或者人为原因，统计出来存在这偏差，但是应用与软件方面，虽然存在着偏差，但是不可能象硬件那么偏差很高。
等效法 明确测试的目标，一般适合用到的范围是，制定被测试的对象是在满足某个条件的区间内的所有的所有数据。
案例设计方法：从其中区间数据段中选择任意一个或者两个数据，只要这个数据满足了，那么其他的数据就是满足的。
我现在举一些例子，来说明等效法在测试过程中如何应用的。
范例1：在登陆某系统需要验证用户名，要求是长度是最小是6位，最长是14位，名字中可以包含数字，但是不能以数字开头，可以包含各种符号，不能包含中文。
1、随意字母组合成一个12位的姓名，测试是否可以通过验证。
2.、随意生成一个长度12位的姓名，测试是否可以通过验证
3、测试以任意一个数字打头12位的姓名，测试是否可以通过验证
4、测试姓名长度位12位且包含中文情况，测试是否可以通过验证
5、测试长度不满足条件情况下，是否通过验证
6、如果长度不满足，是以数字开头的，提示信息验证
7、如果长度不满足，姓名中包含中文的，提示信息验证
………….
(注：)这个可能比较简单，但是说明一个问题：为什么随意生成一个12位姓名的,其实你选择8位姓名长度或者10位姓名长度是一样的，所以这种情况下考虑采用等效方法比较合适。
范例2:有这么一个需求，要求选择1~12之间进行调整，手机的背光就会随着数值的变化而变化。总体的是数值越大越暗。
以上需求是大家经常可以看到的。
测试案例设计：清晰记忆1的情况，然后随意调整一个数值，因为要求是变化了，至于变化成什么样子，变暗到什么程度才正确，没有明确的指标数值，所以只需要记住临街点1的情况，然后随意调整一个数据，然后和当前调整后的数据进行比较。
（注：）没有明确的说明，只是含糊的结果，但是总体的结果是在变化，那么这个时候比较适合使用等效法。
因果分析法 需要有一定的程序基础，了解程序的架构，就是当问题发生以后，能够有效的补充相关的案例或者筛选相关的案例。因果分析的核心是从自己的理解去分析问题所在的真正原因。
范例1：删除磁盘上某个文件失败，分析原因：如果是管理员权限，那么可以随意删除，无论这个文件的属性是只读的还是存档的，那么如果不能删除磁盘文件，除非是坏道上的文件。分析完成以后，使得测试案例设计有针对性，而不是盲目的将所有的文件格式都去尝试一次。
范例2：假设我们用Excel作一个计算，结果和我们用计算器计算的结果不同。
分析：Excel的计算函数单独运算没有错误，然后插入一行，结果错误了，说明插入行导致计算错误，那么插入一行怎么会引起函数计算错误呢？原因是由于插入行后，导致传给计算函数的区域没有更新，所以造成计算结果错误，那么这个Bug就很明确了。
范例3:假设我们平常在做讲座的时候发现在某台机器上就会死机。这是一种现象。
分析：为什么在这台机器上死，在其他机器上不死。原因有两个，第一个先找系统原因，是否是我们的产品在当前这个系统下有Bug,经过验证没有，那问题出在那里？
其实演示产品需要的是硬件的支持，那就是显卡，如果显卡内存不够大，可能导致某些演示文件死。
（注）因果分析需要有广泛的知识面，使得我们在分析的时候能够拓宽面积，模糊的定位问题。
范例4:用户给我发送一个文件，打印的时候发现是乱码。后来逼迫无奈，就让用户将这个文件传真给我。这是现象。
分析：为什么打印出现乱码？问题基本定位，系统字库不够，系统下打印驱动问题，打印虚拟内存问题，操作系统问题，软件本身问题？最后问题经过验证，最终归结为在此操作系统下，打印驱动程序有问题，使得文件不能正常打印。
（注：问题需要先框定范围，不要乱了套路。）
逻辑分析法 在逻辑分析方面，也需要有一定的程序理解能力。从程序逻辑和日常常识去判断问题。逻辑分析法其实就一堆假设的罗列，推论出系列结果的假设，然后将假设反推翻，问题就可以暴露出来。无论那种方法都是通过表现去分析问题的实质的。
范例1:我们在做MP3播放器快进和快退测试中，要考虑的同步问题，就是我们液晶显示屏上出现的歌词进度，时间进度和我们耳朵听到的进度不同。我们分析一下，为什么出现不同步现象，为什么其他的能同步，就某一个或者某几个不能同步。
首先我们了解同步的算法：快进和快退是按照当前歌曲的数据流来计算应该到那里，它是以当前歌曲的数据流为系数，然后进行的一些调整，那么出现不同步的原因是由于系数不同造成的，所以考虑到同步问题，我们需要找不同格式不同数据流的歌曲，这样问题容易暴露，容易清楚的定位问题的真正原因。
范例2
我们来分析网络游戏中的交易系统，就是在游戏两个人进行物品和金钱的交易。
怎么设计这里的案例呢？我们先梳理一下交易的逻辑关系图。
我们一起来分析下面的逻辑关系图，在玩家进行交易之前，数据库中记录了两个玩家各自的数据，然后玩家A向玩家B发送请求，当玩家B不同意的情况下，检查各自的物品个数就可以了，这种测试相对比较简单。下面我们分析当玩家B同意的情况下的测试重点在那里？
第一.当B同意和A进行交易的情况下，Ａ从自己的物品箱中拿出物品，拖放到B的物品箱中，那么A和Ｂ在还没有确定的情况下，需要确信两点（A,和Ｂ相同，只不过一个提供金钱，一个提供物品）
１、 Ａ当前的物品是可以更换的
２、 Ａ拖放到交易物品栏中的物品是不能被其他人产看的
３、 在A放弃交易的情况下，此物品还应该回到物品栏
第二. 点击确定后测试设计的重点
１、 点击确定后，双方的交易请求就会到服务器处理的队列中，等待服务器重新计算
２、 当A或者Ｂ断线情况下，怎么处理？
３、 当服务器宕机怎么处理？
４、 当请求队列中等待的时间超过了心跳的时间，怎么处理？
第三. 正常交易后的测试设计重点
１、 物品数据（金钱数据的检查）
２、 物品属性检查
３、 物品是否能够正常交易和使用
第四. 交易过程可能出现的情况
１、 不是一对一的交易
２、 在没有确认的情况下把一个物品托动到箱子后，等对方付钱后，故意断线或者更换物品
３、 锁定物品后，不和Ｂ交易，同时也不关闭交易对话框，角色的交易标志是否被清除
| A玩家 |
| B玩家 |
| 请求交易 |
| ＤＢ数据库记录玩家的数据 |
边界数值分析法 在测试案例执行的过程中，所有调节的数据都需要考虑到边界数值的测试方法，这里我就不在赘述。但是需要注意，边界数值的测试不是枚举，只是抽样的方法。
逃避测试的误区 市场需求引导产品质量测试是为了验证需求，保证产品质量，无论如何你都不可能做成100%的测试，不可能做成No Errors。所以我们针对不同的产品，不同的市场定位，确定不同的测试方针。
因为企业面对的是客户，面对是企业长远利益，那么我们不可能仓促的推出产品为了迎合市场，而是需要研究，调查市场的真正需求，把用户所关心的功能提供给用户，使得其更加完善，更加稳定。
我们从企业来分析，首先任何一家企业要生存，必须需要市场空间的支撑，目的是为了盈利，我觉得没有必要说的那么冠冕堂皇，这是事实，但是在把握产品质量和市场需求的时候，我相信很多企业会选择市场需求的，因为这是机会，是把握企业生存的机会，特别是对于发展性企业来说。（企业原因）
我们从开发来分析，因为在开发的过程中，由于软件行业的高流动行和知识更新快的特点，风险加大，使得开发周期很难把握，这样使得产品测试时间很难控制。因为开发的进度包括市场提出需求的技术风险都很难把握。（开发的原因）
我们从测试来分析，测试在很多企业中是没有的，那么开发人员自己来做，如果有测试人员，那测试也是随意性非常强，造成产品上市后预留很多无法预估的风险，为企业的形象蒙上了面纱（测试模式）
合理利用2/8原则测试是列举，不是枚举，所以设计案例的时候全面是不可能的，那么需要灵活的运用2/8原则，使得测试重点清楚，容易控制。
基于产品在开发过程中的种种风险，我们在有限的人力和资源的情况下，合理的利用2/8原则，如何把握2/8原则？首先需要了解产品的特点，让所有参与测试的人员能够了解产品的特点，这样使得工作具有针对性，至于产品的噱头，我们可以进行充足的测试，因为只是我们的产品立足市场的点。
在时间有限的情况下，把常用的功能测试保证了，不要摊全，摊宽，这样到最后都无法总计产品的质量概念了。
以上这么说，是一种概况，在实际的工作中大家需要总结，把进度，时间，质量等进行权衡，以保证产品的顺利发布。
回归测试的概念测试次数不是轮回，测试的不同次数不是轮回，而是为了验证问题，那么什么时候适合安排一轮测试，需要定义标准，否则耗时耗力。
回归测试是不可缺少的环节，在一个产品测试完成后，直接到用户手头的时候，需要千万小心，需要进行一次彻底的回归测试，这个时候包括所有的功能以及所有已经修正的问题。避免版本出现问题。
其实在不同的资料中对回归测试有不同的解释，我就不在这里赘述。我想表明我的观点是，依照不同的开发模式，回归测试所在的时间段也不相同；当前的开发模式有瀑布型和迭代型，例如，在瀑布型的开发模式中，所有的测试活动（手工测试，系统测试，部分集成测试）都在最后进行的，而切所理解的回顾测试是为了保证在新的版本中测试修改后的问题，其实这个测试只是保证了其中一部分工作
测试的概念测试不是为了验证问题，而是为了发现以前设计中没有发现的问题。
自动测试只是测试的一种手段，目的是为了提高工作效率
测试工具只是利用，不能依靠，因为工具本身没有智能的判断是否会有问题发生，自动测试不是利于测试工具，而是需要编写或者利于测试平台，编写适合自己的测试工作进展。
如何调整团队的作战能力建议性质：因为曾经带过四个团队，而且这个经验最少在我身上是成功的。
形式分析测试团队，测试团队在现在国内来说在慢慢的得到重视，之所以原来不重视是因为整个行业处于摸索期，不知道采用什么方法，什么技术，作什么事情等的情况下，使得测试员好像是一些没有能力人的集合（宣讲，不听的宣讲）。
目标计划引导测试技术和未来发展规划，因为任何人的发展需要目标，那么一个人的发展目标假如它和这个行业相关，那么它会付出一切，努力的工作，所以需要大家认可一个目标，并且让大家认为是可行的，然后我们分步骤一步步的去实现它。让他或者大家能够看到自己所喜欢或者从事行业的发展方向。
过过老师瘾因为在做任何事情的时候，每个人都有自己的想法或者步骤，讲出来就好，这就需要开始的时候我们以任务的形式下达，我相信，到后来大家愿意自己站出来讲了，我告诉你原因。因为人本身有羞怯感，怕几个方面，怕讲错，怕人多，怕提问。
那么如果把这几个问题都解决了，是否羞怯感就没有了呢？
如何解决个人怕的问题：引导，因为一个人如果不能把自己的想法和思路讲出来，那么不可能把事情做的很好，其二，就是如果你把你的想法说出来，别人可能会指出你思路中走弯路的地方，对个人来说可以跳高工作效率，使得思路更加完善。
其三，如果大家都把自己的思路说出来了，你不就节省的很多学习时间吗，另外你想过没有，当别人形成这个想法的时候，需要一定的积累，那是他的心血，这不就轻轻松松让你学到了吗？如果固步自封，那么你的思路有可能是错的，有可能是对的，但是你的知识面就只能局限在你所考虑的范围内，对个人发展不利。
定学习目标在软件行业里面，要有发展，就需要不停的学习，不停的进步，不停的总结，才可能有长远发展，所以需要定义在这个行业阶段行的学习目标，让人感觉这个行业现有的水平只是维持，要发展，需要学习。
在工作中学习的方法，除了自学以外，就是“偷”了，所谓偷，就是要学会问问题，把你想知道的东西刨根问底，当别人回答你问题的时候，他一定是用他知道的东西的精华来总结，那么这样你在很短的时间内，把他总结的精华全给你了。
在学习的过程中，需要学会总结，把能总结的都整理出来，第一是经验的积累，第二呢能够做到分门别类，逐类旁通，使得相同或者类似的错误不要重范。
兴趣和爱好 一个人工作有两种情况，第一中是真正的工作，完成就算完成了，自己也在不断的学习，不断的总结，但是缺乏激情。第二中是把工作当成自己的事业，渴望自己在这个方面成为权威或者说业界能够说话的人，也是在不断学习，不断的总结，培养职业性，培养和引导大家的兴趣和爱好，因为只有你了解了兴趣和爱好，才能更融洽的调和整个工作组的气氛，这对测试行业的领导者来说是个挑战。
歪曲理论推理 “测试人员是由于技术不过硬，才去做测试的。”针对这个观点，我说说自己的看法。好，我给测试说几句，测试水平不过硬成立，假设成立，那么这是相对的，相对开发来说的，而且这种论调都是从开发那里扩散或传播出来的，测试在后期发现问题后，开发也许心理很痛苦，但是他不愿意暴露在脸上，使得有些问题越发变的严重，不得不修改。那么在产品后期暴露那么多问题，说明了什么呢？这么低水平的测试都能考虑到你程序设计的种种漏洞，那么说明了程序水平开发有待提高。
在IT现在的行业中，开发的流程，模式，以及各种约定成俗
的东西越来越多，而且相对稳定，而测试是一个全新的行业，它需要大家摸索支持，需要大家共同建立起来。
其实，在原来的开发模式中，商家为了适应市场，为了保证利润的最大化，为了使得产品能够顺利的适应市场，那么采用各种方法，使得产品质量的定位淡薄，而现在随着人们的要求越来越高，商家的意识越来越强，各个公司或者组织渴望成立测试部门，保证产品的质量，使得测试这个行业在最近几年才发展起来。
正确理解自动测试 首先，自动化测试是测试行业是技术，但是不是说用了自动化测试了就能发现更多的问题,它只是提高了工作效率而已.
自动化的概念是人们在工业生产的过程中，为了提高工作效率，不断的对操作方法或者技术或者工具进行改进，减少人们普遍的手工劳动，节省时间和成本。
而软件行业的自动化测试同样也有节约成本，提高效率的需求。所以所有的改进需要考虑到成本的问题。
自动化测试的大前提:
第五. 产品本身特征具有长期可维护性
第六. 产品本身非紧迫的大项目
第七. 产品结构相对复杂
第八. 资源投入相对充裕
那么作为成本，需要从几个方面去考虑，第一实现成本，第二，人力成本，第三，新技术的风险，第四，节省的成本，第五，被自动化的功能是否需要大量的手工劳动。
所以我们理解自动化一定从成本的概念上考虑， 最少从自动化测试概念的起步应该从这个方面考虑。那么自动化测试的重点就在于他节省人力，节省时间，得到的数据更精确些，而且操作的可重复性和Bug的可重现性更强一些。
下面我就对自动化测试做一个详细的解释，跟大家分享。
1. 简介
本文关注于一个实施自动化测试框架的组织的主要方面和影响。本文的意图是提供一些能够成功的实施自动化测试的指导方针。
2. 测试自动化的神话
有很多关于自动化测试的神话。其中的一些是真实的，而其他的一些是不正确的设想，这些不正确的设想会严重的威胁到实施自动化测试的成功。
2.1. 我们在时间上是紧迫的 － 项目已经落后了 － 让我们使用自动化测试吧！这种情况将不能成为现实。实际上，正确的思想应该是 － 我们时间急迫 － 我们决不应该使用自动化测试。
如果项目已经陷入到了麻烦之中，不建议实施自动化的功能测试。项目很可能因为需要大量的测试框架的准备和实施会被托跨。我饿建议将重点放在以下的事情上：
优化测试的过程。调查并建议在目前工作基础上的测试方法和过程。建议借鉴 RUP的相关思想和过程。引进或者使单元/组件测试正式化。这是我们能够快速获得受益的很好的方法。如果正式的组件测试被使用，我建议可以使用 Rational PurifyPlus 进行单元或者组件测试。根据我的经验尽早的使用 Rational PurifyPlus 是非常值得的。在一个引入和 Rational PurifyPlus 的项目中，通常会在组件的级别得到 百分之三十的性能提升。仅仅在项目团队能够对 下列问题的回答是"Yes"时：项目能够被适当的推延。存在能够通过实施自动化测试被达到的精确的目标。项目具备建立适当的测试框架的必要条件。
那么，你可以在一个时间紧迫的项目中适当的实施测试自动化。但是根据经验这种情况是很难发生的。总而言之，我只能说"对不起，银弹根本不存在"。
2.2. 测试自动化就是捕获和回放
在过去的日子中，自动化的测试工具只是被看作是一种捕获和回放的工具。当前这个神话仍然在很多测试人员的思想中。而事实上自动化测试已经远不止捕获和回放这么简单了。按照成熟度自动化的测试可以被划分为 5 个级别。
2.2.1. 级别 1：捕获和回放
这是使用自动化测试的最低的级别，同时这并不是自动化测试最有用的使用方式。优点：自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识。缺点：你会拥有大量的测试脚本，同时当需求胡子和应用发生变化时相应的测试脚本也必须被重新录制。用法：当测试的系统不会发生变化时 － 小规模的自动化。
2.2.2. 级别 2：捕获、编辑和回放
在这个级别中，你使用自动化的测试工具来捕获你想要测试的功能。将测试脚本中的任何写死的测试数据，比如名字、帐号等等，从测试脚本的代码中完全删除，并将他们转换成为变量。优点：测试脚本开始变得更加的完善和灵活，并且可以大大的减少脚本的数量和维护的
工作。缺点：需要一定的编知识。频繁的变化可能会引起"意大利面条式的代码"，并且变更和维护几乎是不可能的。用法：当进行回归测试时，被测试的应用有很小的变化，比如仅仅是针对计算的代码变
化，但是没有关于 GUI 界面的变化。你能够使用这种技术通过快速的编制一些测试脚本以检验你的想法来探索你的预定的测试设计。当我在没有任何象需求或者设计模型这样的文档的情况下第一次操作一个产品时和我需要获得一系列内部构建版本的稳定性的第一印象时，我使用过这种技术。通常如果适当的软件配置管理（SCM）与良好的内建设计相结合时，使用级别 2 的技术已经足够了。
2.2.3. 级别 3：编程和回放
这个级别是面对多个构建版本的有效使用测试自动化的第一个级别。你需要在实际的投资开始显现之前确保团队和客户对项目的安全感。如果没有对测试自动化工具的适当的培训测试人员将不具备到达这个级别的能力。在自动化测试工具中的所有测试功能都必须被很好的理解，并且要掌握测试脚本语言的知识。好处：你确定了测试脚本的设计。适当的设计是必要的。编码的习惯必须是适当的。使用与开发中相同的编码习惯是非常好的。这将开始搭建起测试和开发之间的桥梁。在项目的早期就可以开始自动化的测试。你能够在项目的早期就开始进行测试脚本的设计。与开发人员交并调查他们认为可能会存在问题的区域。确保了开发人员关注在获得能够被测试的方案上。缺点： 要求测试人员具有很好的软件技能，包括设计、开发等。用法：大规模的测试套件被开发、执行和维护的专业自动化测试。级别 3 使你能够使用自动化测试并构建不同的回归测试（重用已有的自动化测试
用例）。根据我的经验在看到更多切实的回报之前，为了达到这个级别，有大量的工作和影响项目的活动必须被做。因此快速的建立和证明自动化测试的价值是至关重要的。找到乏味的测试（例如，边缘测试和特定的功能测试用例是首先进行自动化测试的良好候选者）。首先创建少量的能够测试一些基本功能（比如，登陆和创建用户等）的测自动化测试用例。
2.2.4. 级别 4：数据驱动的测试
对于自动化测试来说这是一个专业的测试级别。你现在要利用测试工具提供的所有的测试功能。你拥有一个强大的测试框架，这个测试框架是基于能够使你根据被测试系统的变化快速创建一个测试脚本的测试功能库的。维护的成本相对是比较低的。你在你的测试中会使用到大量真实的数据。优点：你能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据。缺点：软件开发的技能是基础，并且需要访问相关的测试数据。用法：大规模的测试套件被开发、执行和维护的专业自动化测试。级别 4 要求一些非常良好的测试数据。一个测试人员必须要花费一些时间来识别在哪里收集数据和收集哪些数据。使用现实生活中的数据是最基本的以从测试中得到完全的回报。使用适当的数据将为你提供通常仅仅在项目的后期才会发现的或者是有客户发现的错误的能力。现在你能够通过使用现实的数据开运行大量的测试。
2.2.5. 级别 5：使用动作词的测试自动化
这是自动化测试的最高级别。主要的思想是将测试用例从测试工具中分离出来。这个级别要求有一个具有高技能测试人员测小的团队，这些测试人员能够将测试工具的非常深层次的知识与他们具备的较深的编程能力结合起来。这个团队负责在测试工具中生成并维护测试的功能性，能够使测试工具从外部的来源，比如 excel 表或者数据库中执行测试用例。这种测试概念最初是由 CMG 开发的。与 CMG 方案相比，其他的可能的开放源码的方案有被 Carl Nagle 和SAS Institute 开发的DDE。使用 DDE 的概念，关注点是当在Excel表中创建测试用例的时候，放置使用包括被使用的特定动作词语的一些类型的模板。执行的过程是从 Excel 表中读取测试用例，并将测试用例转换成为测试工具能够理解的形式，然后使用不同的测试功能来执行测试。这个概念变得越来越流，因为测试与用例一起使用是非常有用的。优点：测试用例的设计被从测试工具中分离了出来 － 关注在设计良好的测试用例上。允许快速的测试用例的执行和基于用例的更好的估计。缺点：需要一个具有工具技能和开发技能的测试团队，以提供并维护测试工程（框架）。用法：专业的测试自动化将技能的使用最优化的结合起来如果工具不具备使用内建的对象映射的可能性，那么这个方案对于消除与 GUI 相关的大部分维护成本是优秀的。在一些组织中已经创建了这种方案，并且他们其中的一些已经实现了高度的自动化（60%），并且他们都得到了巨大的回报。如果测试框架是适当的，我们能够使用 excel 来生成实际的测试用例。这个级别对于那些按照正规基础使用用例的组织或者项目来说是非常优秀的。有多少测试用的估计是被需要的，并且当用例适当时需要做的工作也是非常简单的。你可以集中时间来生成第一个包含被需要的"对象映射"的测试用例（主流程）。依靠被测试应用的复杂程度，通常这会花费大约半天到一天的时间。后续的被需要的每一个测试用例大概会花费 15 到 20 分钟的时间，因为通常多数的测试用例可以复制已有的测试用例，并对其进行必要的修改，通常这种修改是有限的。动作词语框架能够通过使用用例使紧密的并行测试用例的开发变得可能。
2.3. 我们不需要培训！
我们所有的人都在某一些方面具有一定的经验，我们没有时间能够花费在使用新工具的培训上。当一个对自动化工具还不是很熟悉的组织或者项目团队开始实施自动化测试时，培训和指导是至关重要的。如果我们允许组织或者项目团队在没有关于应该如何做的任何知识的情况下实施自动化的测试，那将肯定会以失败告终。用于实施自动化测试方案的预算会被超出，测试会被延误并且更坏的情况是自动化测试将被放弃。组织和项目团队需要尽量避免一些认识上的缺陷，尤其是自动化测试的维护成本和当测试人员尝试和确认工具如何工作时产生的挫败感。你需要确保你的测试过程是适当的 － 如果测试过程是不合理的，引入自动化测试只会给软件组织或者项目团队带来更大的混乱。因此，我建议希望实施自动化测试方案的组织或者项目团队应该在实施之前建立"训练营"，并将重点放在培训测试团队能够很好的利用一个原型的项目上。为第一个原型项目制定一个实施计划，下面包括原型项目的最小化的描述：当先状态我们希望实现什么 － 建立成功的因素期待的回报（第一次自动化测试工作被期望验证什么）找到一个"简单的"测试的痛处并尽力的通过自动化测试解决它，这可以被作为在同一时间上使测试运行在多个平台上的样例说明被需要的资源和时间......
一开始你就要大声的说出成功的信心 － 让人们了解你所展示的进展。这将吸引更多的关注和资源。
2.4. 我们必须 100% 的自动化
从管理的角度来说，100% 的自动化目标只是一个从理论上可能达到的，但是实际上达到 100% 的自动化的代价是十分昂贵的。一个 40-60% 的利用自动化的程度已经是非常好的了。达到这个级别以上将增加测试相关的维护成本。由于对每一个构建版本的需求变化的复杂度，你将花费更多的时间在变更测试用例上以使他们能够正确的运行。在这种情况下，通过告知管理层100% 的自动化目标是相当昂贵的来确立一个合理的期望值才是明智之举。对于决定自动化一个测试用例的一般规则是这个测试用例必须被运行 4 次以上。这个数字是基于用户对测试工具有良好的技能并且有一个良好的测试框架的。如果情况不是这样的化，整个数字能够是 10-20次或者更高。一个例子，在一个项目中测试人员花费和两周的时间将手工测试的 23天的任务转换成了自动化测试的用例。在完成使，项目能够在 4 个小时在多个平台上运行相同数量的测试用例。
2.5. 测试框架
测试框架对于产生成功的测试自动化的适当基础是重要的。很多考虑必须被解决以使测试自动化更加有效地被使用。重点必须在：维护成本维护成本是成功的使用自动化测试的最重要的问题之一。维护成本直接联系到前面已经提到过的自动化测试的成熟度。组织或者项目必须至少要在成熟度的 3 级使用高度的测试库才能使维护和更新测试功能变得容易。
测试数据
什么样类型的数据将被使用？要为每一个测试用例生成测试数据还是使用在被测试应用中已有的数据。在很多的情况下一个测试数据被创建了，删除他们是不可能的。
可测试性
自动化测试方案能够有效的测试吗？例如，被适当命名的对象（不仅仅是索引Id）。一个简单的例子是所有的对话框都有相同的 ＃id 和相同的标题，所不同的仅仅是显示的文字信息。当测试应该覆盖多种语言的方案时，对话框的测试就是一个挑战。
测试人员的技能
被包括在自动化测试的创建中的人员应该具有什么样的技能呢？如果他们具有良好的开发背景，那么成熟度 3 级是足够了。如果他们有很少的或者根本没有开发的经验，我们被迫使找到或者培训一个自动化测试专家的小组，并直接到达成熟度 5级，在成熟度 5 级测试的创建与实际的测试执行被分离开。
一个好的构建过程
自动化测试的引入在"构建团队"上加入了一些约束。为了实现自动化测试的高利用率（回归测试），要求具有一个高的构建频率。每周仅仅运行自动化的测试不是好的自动化测试的使用率。将回归测试增加到每天一次将帮助快速的发现新的问题并使开发人员更加容易的发现问题的根源，因为对测试的反馈时间是比较短的（开发人员能够记住他们昨天做了什么）。所有权不同的测试库的所有权的定义是重要的。一个好的方案会将测试库的组织划分为三个级别：
级别 1 － 全局的
这个一个通常的级别。被存储在这个级别的测试功能能够被所有的项目访问。通用的和通常的功能象登陆、创建一个用户都是这个级别很好的候选者。
级别 2 － 项目
在这个级别的测试功能是与特定的测试项目相关的，但是通常在项目中有用的比一定在项目外是有用的。通常级别 2 是级别 1 的功能的提供者。
级别 3 － 脚本
功能被直接关联到特定的测试脚本。 I在这个级别中，通常一个测试功能的第一个版本是被开发的。在新的测试脚本的创建期间已有测试功能的重用性被发现，并被移到了级别 2 中。在这个级别上尽量最小化功能的数量，因为它将增加维护工作量。还有很多有关测试框架的问题，但是这里所提及的是一些基本的要被解决的问题。
3. 在哪里使用自动化测试
有很多的情况下使用自动化的测试可以降低测试成本。我将尽量的突出在自动化测试中的不同的测试技术技术 描述 备注单元测试/组件测试 这个测试工作通常是开发人员的职责，很多不同的方法能够被使用，比如"测试先行"，它是一个测试框架，开发人员在编写代码前编写不同的单元测试。当测试通过时，代码也被完成了。 通过使用正式的单元测试，不仅能够帮助开发人员产出更加稳定的代码而且能够是软件的整体质量更加的好。冒烟测试 冒烟测试是一般验证别测试系统的功能性测试用例的集合。冒烟测试背后的思想是确保基础是可以工作的，以便"大的"测试工作能够开始。 在构建过程能够确保构建已经为测试准备好时，冒烟测试通常是自动化的运行。功能/集成测试 这里测试的工作关注在验证在不同的组件之间的集成上。 这些类型的测试通常是被测试系统的更加复杂测试的基础，大量的边缘测试被合并以制造出不同的错误处理测试。系统测试 － 用例测试 这种测试是通过执行用户场景模拟真实用户使用系统以证明系统具有被期望的功能的测试。 这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的，因为系统的环境是恒定不变的。回归测试 回归测试实际上是重复已经存在的测试。通常如果是手工完成的化，这种测试只在项目的结尾执行执行一到两次。 这里完全有潜力应用自动化的测试。你能够在每次构建完成后执行自动化的回归测试，以验证被测试系统的改变是否影响了系统的其他功能。性能测试 性能测试包括以下不同测试形式：
- 负载测试
- 压力测试
- 并发测试
-.....
如果没有自动化的测试工具，你将不能执行通过模拟用户的负载实现的高密集度的性能测试。
4. 什么时候使用自动化测试
我对什么时候应该使用自动化测试和什么时候应该使用手工测试进行了一个概要的总结：使用自动化测试 使用手工测试项目没有严格的时间压力具有良好定义的测试策略和测试计划你直到要测试什么
你知道什么时候测试对于自动化测试你拥有一个能够被识别的测试框架和候选者能够确保多个测试运行的构建策略多平台环境需要被测试你拥有运行测试的硬件你拥有关注在自动化过程上的资源
被测试系统是可自动化测试的 没有适当的测试过程没有一个测试什么，什么时候测试的清晰的蓝图在一个项目中，你是一个新人，并且还不是完全的理解方案的功能性和或者设计你或者整个项目在时间的压力下在团队中没有资源或者具有自动化测试技能的人没有硬件如果你正在从事自动化测试，那么一定要记住要关注将自动化测试与手工测试结合起来使用。首先，对于自动化测试率的目标是 10/90 （10% 的自动化测试和 90%的手工测试）。当这些目标都实现了，可以将自动化测试的使用率提高。记住创建自动化测试的测试用例要比创建手工测试的测试用例花费更多的时间。不要将你所有的测试时间都用在自动化的测试用例上。同时也要记住在测试期间对每一个被发现的错误都要花费一定的时间去处理。
5. 自动化测试的好处如果你正在你的组织中引入自动化测试，记住有很多不同的方面被包含了进了。今天在测试工作如何被进行上有很多不同的视图。为了能够成功的实施自动化测试你应该提出这些问题：
测试覆盖什么？－ 我们没有覆盖什么？
由于遗漏的测试我们没有发现的"bug"会带来什么样的成本？由于不好的测试，破坏已有功能性的成本是多少？如果"琐碎的"测试被每天的运行，对于你的项目意味着什么？如果我们能够每天向开发人员提供他们最近代码变更相关的反馈，对项目有怎样的影响？这些问题都能够被自动化测试满足。你必须从自动化测试成熟度的级别 1 或者 级别 2 开始，并开始测量结果。根据我的经验快速的向开发人员反馈并每天运行测试对于向自动化测试成熟度的级别 4或者 级别 5 是非常有好处的。
自动化测试有以下的贡献：
降低风险 － 你知道你测试了什么和没测试什么测试能在项目的早期开始并随着时间一直扩展快速的反馈 － 自动化测试用例能够随时的运行在多个平台上的测试能够同时进行
更好的估计 － 你能够对测试进度和被使用的时间有更好的了解优秀人员的集中 － 你能够得到一个专家的团队，并将他们的知识传播给其他的项目喜悦 -你和你的团队正获得着成功
测试工具介绍下面我介绍市面上相对比较广泛的测试软件，Rational中的Robot和MI公司的WinRunner的具体的用法。
Robot，俗称机器人。它有几个特点，第一，Robot它的语法相对简单，是一种类似于VB的语法，所以上手快；第二，Robot的脚本组织结构类似于C的结构，相对容易理解；第三，Robot运行环境和可参数化，所以容易维护；第四，要求的机器配置相对较低；第五，Rantional系统集成的很多产品很优秀，而且适合面很广；第六，相对价格比较低廉。
WinRunner的功能相对Robot相对来说有一下几个特点。
第一， WinRunner的语法结构是类似于C的语法，理解相对容易；
第二， WinRunner的脚本组织形式是以目录的形式组织的，所以相对来说比较好管理；
第三， WinRunner支持当前市面上的很多系统；
第四， 可以随时Update检查点的内容，使得脚本的维护量减少
第五， 机器配置相对要求高些；
第六， 集成了很多优秀的组件。
下面我就尝试写一个Robot的脚本。
题目：请检查各种我们规定的字符是否过滤掉了，如果那些词语没有过滤掉请记录下来。我们先看测试这个功能的逻辑关系图应该如下：
| 我们创建的测试案例：准备很多需要过滤的词语 |
| 程序处理模块 |
| 输出处理结果T_FilterWord |
| 打开过滤词文件 T_OpenTestFile |
测试脚本：
Function T_OpenTestFile(Filename as string)as integer
{
。。。。。。。。。。。。。
}
Funciton T_FilterWord(getword as string)as integer
{
。。。。。。。。。。。。
}
以上是两个SBL文件，相当于C中的函数实体
那么我们要建立一个SBH，相当于C中的头文件，红色的部分类似于一个类库，我们把相关的或者具有相似属性的操作或者函数定义在同一个类库中。
Declare Function T_OpenTestFile Basiclib T_FileOpertion(filename as string) as integer
Declare Function T_FilterWord Basiclib T_FileOpertion(getword as string) as integer
我们现在建立一个脚本文件REC
＃include T_FileOpertion.sbh
Main()
{
。。。。。。。
}
在此脚本中就可以调用上面那两个函数了。在以后的测试中，我们只需要维护过滤词文件库就可以了。这样提高了工作效率，保证了测试的正常进行。
下面我就举个例子，来尝试用WinRunner的使用方法，其实例子相对很简单，主要是想告诉大家这种语言脚本的组织方法是怎么样的？
压力测试工具的功能挖掘使用。
一、为什么采用插件脚本开发
性能测试过程中，最耗费经历的就是编写性能测试脚本的过程，在大部分的测试工具中都是采用录制的方式，通过录制产生脚本，然后根据需要进行修改，以及参数化。有些时候为了能够完成某一个功能的脚本，需要将录制下来的脚本进行大手术，例如将一些逻辑以脚本的形式写在LR里面，给编写脚本的人带来了很大的麻烦。目前部门的大部分业务在性能测试过程中都是采用录取请求信息包的模式来模拟请求。
其实LoadRunner是提供了COM组件的调用的（图一），你甚至可以在引用了LoadRunner的组件，继承相应的接口后，重写LoadRunner的很多方法，比如我们熟悉的lr_start_transaction、lr_rendezvous等方法。
（图一 LoadRunner提供的COM组件）
这样有什么好处呢？
能够更有效的、更灵活的构建可被LoadRunner调用的脚本或者压力测试程序
我们可以定义自己的调用类及方法、比如自己封装好的socket类、而对于不同的业务只需要传送不同的调用参数而已，避免了每次的测试过程都要去录取烦琐的脚本再在脚本中更改，而且执行效率要高于录制的脚本（直接录制的脚本是解释执行）
生成的脚本可以突破LoadRunner本身的很多限制
我们知道的LoadRunner在应用的时候是有很多限制的，比如：C/S 协议的license的个数限制、负载生成机器单台最大只能运行1000个虚拟用户，而采用插件脚本开发的形式可以突破这些限制
可以抛开第三方的工具、自己实现压力测试工具
插件开发脚本实际上是生成了Virtual User Generator的功能，但只要增加并发调用的程序，就可以实现了Controller的功能，如果是采用.net(C#)开发语言就可以构建线程安全的并发生成工具
二、插件在IED环境中的使用
利用Loadrunner Add_In的方式进行脚本的开发，如果想采用这种方式是需要有几个前提条件的：
􀁺要有被测试程序的源代码
􀁺被测试程序的架构要清晰，对于一些分层不够好的产品，不太适宜用这种方法。
􀁺编写脚本的人员要了解Loadrunner的使用
使用：…\Additional Components\IDE Add-ins\MS Visual Studio .NET ，安装文件：
LRDotNetIDEAddInSetup.exe
在开发环境中会产生新的菜单项 如图二
（图二 IDE中的Vuser）
菜单中会多出一项【Vuser】的菜单。这个菜单就是我们主要使用的内容。另外，在对象库中也会增加loadrunner相应的对象。这些对象的使用和软件中其他对象的使用没有什么分别。这些对应都是可以被loadrunner所识别的，同时也是可以并发安全的
这样就可以新建LoadRunner工程了
增加必要的内容：
框架生成后，我们就需要根据测试的内容增加相关的代码了，下面介绍的函数都是以c#为例进行介绍的，其他的语言与此差不太多。
我们假设一个场景：要测试100个用户同时登录系统的情况。后面都将围绕着这个主题进行。
首先，无论使用什么内容都要先进行对象的创建：
LoadRunner.LrApi lr;
lr = new LoadRunner.LrApi();
1、 事务
事务是测试最核心的单元，所以事务的创建非常重要，下面是一个事务的定义过程。
LoadRunner.LrApi lr;
lr = new LoadRunner.LrApi();
lr.start_transaction("syslogin"); //事务开始,事务名称为syslogin
//×××××此处添加事务syslogin的程序，例如：××
Client_syslogin(“servername”,”Username”,”userpassword”,”2005-1-12”);
lr.end_transaction("syslogin", lr.PASS);// 事务结束
事务的开始和结束与VU Generator工具的脚本基本上是一样的。
具体的使用不做详细阐述了，网上也有相关的教程
三、举个实际测试的例子
InSoket类是封装好的SOCKET请求类 包括异步连接、异步发送请求以及异步接收数据等
Vuser类 是具体的请求调用 包括一些请求方法及重载、事件委托
以上只是对方法可行性做了研究 具体业务的封装要复杂些。
示例代码如下：
还有一个实际例子，就是针对一个业务我们进行的测试，分享给大家。
某金融服务器性能测试方案
测试说明
模块说明tcpsvrd
客户端统一通讯接入前置机，根据server type和server id来识别接入的客户端，如果type是Client则id为uin，如果是内部server则同一个type和id只能建立一条TCP连接，若有多余连接则会拒绝其接入。
financesvrd
目前暂时只测试3条消息，Deposit（存款）、Consume（消费）、Query（查询）。Deposit和Consume会直写DB，Query则先会查询Cache，再查DB。
Test Server
可以是LoadRunner的Controller，也可以是自行开发的TestServer，主要负责控制各个TestClient启停。
Test Client
可以是LoadRunner的VUser，也可以是自行开发的TestClient，主要负责开多线程快速发送消息。
工具说明
LoadRunner
两种方案：
用Web协议加载DLL
License有10000个，并发时每50个VUser启动1个进程50个线程建立一条TCP连接共同向一个端口发包，运行时必定会采用同步机制来竞争资源（这种方式和单线程+延时+循环发包的压力效果是否类似？是否做到了真正的并发？）因此最多只能建立10000/50=200条TCP连接。如果要测试向tcpsvrd建立大量连接显然是不行的，只能测试向tcpsvrd发送大量请求。
用Windows Socket加载DLL
受100个License限制，并发时每个VUser均会启动1个线程建立一条TCP连接发包。在License数量无法增加的情况下，很难做压力测试。
从目前的调试结果来看，用LoadRunner加载DLL的方法来测试C/S架构不太乐观，存在着一定风险。
ethereal/sniffer
测试准备阶段用于调试脚本、测试程序
测试执行阶段通过在服务器端抓包，来分析整个加压过程。（如果测试时间长时，抓包文件会很大，增加数据分析的难度）。
另外，也可以用于协议测试。（不知道开发做了没有，做到什么程度？我们是否可以介入？）
统计工具和脚本
服务器统计工具sonicmao已经提供financetool –s0/s1 (复位/统计)，能够统计客户端发送消息数目，Cache命中率，数据库的处理时间等性能指标。
服务器性能指标分析工具，沿用joeqiu提供的rstatd
目前缺少数据库的记录插入/复位工具（由开发完成？还是自己解决），后台日志的查看只能通过人工分析日志文件，是否提供相应日志分析工具？（此需求重要级别：低）
测试程序
首先要开发一个TClient作消息发送器（难度不大，容易实现），要想加入控制功能还需要开发一个TServer的控制器，用于控制各个TClient的启/停，接收各TClient的上报消息。（关键是如何设计，做到最大限度的复用，此需求重要级别：中）。
最好是服务器为TServer定义service type和service id，直接允许其接入，由我们来定义测试消息，通过发送查询消息直接搜集服务器的当前信息（取代后台统计工具financetool），这样就可实时监控服务器当前的业务处理性能。（此需求重要级别：低）
测试内容
tcpsvrd
单台服务器最大承受接入连接数
目的：测试不同硬件配置下tcpsvrd的接入能力，得出结论XX配置下可以承受XX个接入
方法：用测试程序模拟n个Client接入tcpsvrd，按正常使用频率（需要和开发协商做一个大致的估算，如果不能确认，则只统计结果）在10-30分钟内定时向financesvrd发送固定消息（消息类型个人觉得应该是查询消息）。
数据记录表格（参考）
| No. | 测试时长 | 消息类型 | 接入客户端数目 | 消息发送频率(次/秒) | 发送消息总数 | 转发消息总数 | 处理消息总数 | 业务处理成功率（%） | CPU占用率Max/Min/Avg（每n分钟查看一次） | Load BalanceMax（每n分钟查看一次） | Mem Use （每n分钟查看一次） | 其它异常记录 |
| 1 | ||||||||||||
| 2 | ||||||||||||
| 机器配置：… | ||||||||||||
单台服务器最大承受消息数（峰值压力）
目的：测试tcpsvrd在业务高峰期转发消息的能力，得出结论tcpsvrd当消息速度达到XX个请求/秒（或流量达到XXkbps）时，需要进行在网络设备上进行流量控制。
方法：用多台机器向tcpsvrd连续发包，持续时间5-20分钟（服务端的峰值压力如何计算？如果用tcpdump抓包可能会影响服务器的业务处理能力）
数据记录表格（参考）
| No. | 测试时长 | 消息类型 | 发送消息总数 | 转发消息总数 | 处理消息总数 | 业务处理成功率（%） | CPU占用率Max/Min/Avg（每n分钟查看一次） | 峰值压力（TPS或kbps） | Load Balance Max（每n分钟查看一次） | Mem Use （每n分钟查看一次） | 其它异常记录 |
| 1 | |||||||||||
| 2 | |||||||||||
| 机器配置：… | |||||||||||
单台服务器长时间承受消息数
目的：测试tcpsvr长时间运行所能承受的消息数，得出结论给出tcpsvrd的推荐处理速度，tcpsvrd当消息速度达到XX个请求/秒（或流量达到XXkbps）时，需要在软件上进行流量控制。
方法：用多台机器向tcpsvrd连续发包，发包速度可以参考2.1.2给出，持续时间2小时以上
数据记录表格：与2.1.2类似
测试通过条件：与2.1.2类似
financesvrd
服务器的业务处理能力
在对tcpsvrd进行测试的同时，可以顺便得到。时间允许的话需要对deposit、consume、query全部进行测试。否则只测试query消息。
DB
目的1：测试Cache命中率对其进行调优，得出结论命中率为100%时应该配置多大的Cache，命中率为90%时应该配置多大……
目的2：测试直写数据库时是否会有I/O瓶颈，CPU占用过高？
方法：数据库事先要插入一定数量的记录（具体数量是多少？10w,100w），先配置较小的Cache用多台机器连续发查询包来得到命中率和发包速度的关系，再逐渐调大Cache找到两者的映射关系。
在发写DB请求时，最好能建立请求速度和CPU占用率/内存使用/负载的经验匹配值。
以下内容在相关技术问题未解决之前先暂时不考虑
测试工具在实际工作中的应用 现在在测试行业说的最多的有两个问题，第一个问题是测试的待遇和地位，第二个问题是自动化问题。我这里不谈测试的地位，只谈自动化测试。
如何做好自动化测试？这里给出几个分析方法，第一，被测试产品是否有延续性？第二，被测试产品的维护频繁度？第三，被测试产品自动化的难度如何？
其次，如何选择自动化工具，选择容易上手的，测试脚本和测试数据容易维护的，价格低廉的。
正确的理解测试工具需要我们去引导，我们应该清楚的知道那些应该自动化，那么能自动化，那些自动化程度会更高等。
工作中的自动化测试的几中方法 数据驱动法 数据驱动是测试中最常用的一种方法，它是在不修改测试程序的情况下或者稍微修改测试程序的情况下，不段的增加测试案例来进行自动测试的一种方法。
举一个具体的例子：例如我们检查登陆验证（用户名称），
如果我们采用自动化测试，我们只需要在测试配置文件中增加或者删除修改配置文件就可以达到测试的效果了。
| 测试程序 |
| 测试配置文件 |
| 被测试程序 |
| 输出反馈结果，实际处理结果 |
| 预期处理结果 |
只要将两个文件进行比较，就可以得到被测试程序的处理能力和结果了。
桩驱动桩驱动也是一种常见的测试方法。这种测试方法是把某个模块假设是正确的，然后把这个模块作为主核心，然后测试他传出的参数和数据给其他模块来处理，查看处理的结果。
我那EXCEL中数据举一个现实的例子，大家都知道，当你输入等号的时候，Excel认为你需要计算，那么处理流程就应该是接受键盘消息，然后处理。如果我们把输入做为一个桩，那么来查看计算结果的话，就可以知道那些信息处理了，那些信息没有处理。
桩驱动的核心其实很简单,就是首先对桩模块做一个假设和详细测试,认为桩模块是足够健壮的;第二,桩模块是驱动机,能够和很多模块发生调用关系,是核心部件.
关键字驱动 关键字驱动和桩驱动有些相似的地方，关键字驱动的核心是
网络方面的测试方法 数据库测试要点网络游戏测试要点 下面我和大家探讨网络游戏的测试方法。网络游戏是一个信息相对集中的一个网络产品，它牵扯到客户端和服务端以及客户端之间的通讯。下面我们就结合具体的例子来分析
我举一个Mmog的例子（注：mmog是大型网络游戏的缩写），大型网络游戏主要是即时战略性质的，所以通讯上采用TCP协议来发送数据包。TCP协议发送数据包的优点是尽量能够减少数据包的丢失，他是对数据包的一个精包装，一般的发送数据包采用实时处理的形式，即采用堵塞式的处理模式，而不是等到一定空间的数据包满了以后才一起发送（非堵塞式的处理模式）。
上面我们只是简单的讲了mmog游戏数据包发送的形式。下面我们分析网络游戏服务端测试的重点。
网络游戏服务端的主要作用：下发玩家信息，仲裁胜负信息，仲裁装备信息，服务器之间中转信息，状态存盘，玩家信息存盘等。我们来一个个的分析，服务端要处理这么多的事情，在处理什么事情的时候压力最大呢？那肯定是下发玩家信息最大，为什么这么说呢？因为在下发玩家信息的时候，服务端会把每个人的信息和地图上的所有的信息，而且这个信息是当地图上的玩家和元素的增多而增多，当地图上的人越多的情况下，服务器的处理信息的量就很大。那么分析这么多，我们主要测试什么？测试同步消息的传递。就是在很多玩家的情况下，信息能否顺利的通知给各个玩家。
如果做这样的事情呢？根据经验（可以另外想办法），建议编写一个机器人，我们能够操作机器人，这个机器人需要处理什么事情呢？希望机器人能够在以玩家为中心的地方随意走动，能够跟随玩家跨地图，能够按照设定施放技能，能够聊天。通过机器人的每一个动作我们来观察服务的各个性能表现。关心那些性能表现？大家可以参考LoadRunner提供的业界比较官方的指标进行核对。
网络游戏服务端的测试相对比较复杂，对测试人员的要求比较高，测试人员必须了解用什么协议通讯的，怎么通讯的，服务器都处理了那些事情才能具体的分析测试重点和测试方法怎么做。
对于客户端的测试应该相对简单些，我这里说的客户端的测试不包含数据平衡部分。客户端主要是验证功能逻辑。例如我举个例子，任务系统，现在每个游戏都有任务系统。如果测试任务系统，我们应该怎么测试？首先完成任务的条件是什么？完成任务需要什么道具？玩家能得到什么道具？道具是否可以交易，拾捡？道具是否可以买卖？玩家跟NPC交付任务断线处理？NPC在不同的状态下所说话的内容？是公共任务还是门派任务？在得到道具过程中储物箱满了会怎么处理？在负重超出了本身能力的情况下怎么处理？等等，把细节的问题考虑清楚了，这样设计案例执行就是了，没有自动化的必要（但是可以在组件测试中进行自动化，系统测试没有必要自动化）。
客户端还有一个测试点就是地图，因为地图是游戏的门面，所以地图的检查点：绚丽度，整个地图的亮度，不同分辨率下的地图显示，地图的拼接，地图上NPC或者怪物的分布等等。网络游戏的测试是积极具有挑战性，包括能力，耐力，创造力的人奋斗。
| GameServer |
| DB帐号数据库 |
| 角色数据库 |
| GameServer |
| GameServer |
| 网关2 |
| Client客户端2 |
我们把平常大型网络游戏容易出错的地方整理几个跟大家分享。
举例1
大家都知道在游戏中，每个玩家都有自己的背包和储物箱，如果知道网络游戏的人应该都了解，这个是玩家存放自己装备或者基础材料的。这个储物箱在游戏中应用非常广泛，所以玩家也在寻求办法，钻设计的漏洞，以便刷物品，使得自己的虚拟物品和价值持续走高。
关于背包，我们有一款游戏中是这么设计的，收集材料同类的可以叠加，武器类的不可以叠加。
我们来看这个问题，如果可以叠加，意味着只要有同类的物品，就当你存放的时候叠加到一起。但是
还有一种是休息类游戏，例如盛大网络的泡泡，客户端之间主要是通过UDP进行通讯。关于UDP通讯的检查和测试我在这里先不做详细描述，以后进行补充。
网络游戏的核心是什么？网络游戏的核心是构造一个虚拟的社会，让这个社会上的各种职业的人能够生存并附带一定的社会矛盾。那么在这么庞大的项目中，我们测试需要关注的点是什么呢？
C/S结构测试要点 网络游戏现在是C/S架构的一种，但是我们平常所说的C/S是一种类似于银行系统，购物系统等，这种系统要求：服务器处理能力强，反馈及时，但是有一个特点，这种服务器压力是出现在业务繁忙的时候，所以在测试这种软件的时候，需要完全弄清楚业务逻辑，业务点在那里？信息同步在那些方面需要关注？服务端数据处理流程是什么？如果把以上问题搞清楚了，测试的重点也就出来了，这里我不再举具体的例子，因为C/S架构的软件是相通的。
下面我就举个例子,给大家看看,关于C/S架构的mmog类型的游戏测试,服务器的压力那里,测试的重点在那里?
请大家看下面的图形,这个图是目前市面上90%以上mmog类型游戏采用的结构.
| GameSvr3(游戏服务器) |
| 账号数据库 |
| 角色数据库 |
| GameSvr1(游戏服务器) |
| GameSvr2(游戏服务器) |
| 客户端 |
| 客户端 |
| 客户端 |
| 客户端 |
我把上述的图形描述一次:
当客户端要求登陆服务器的时候,通过账号数据库验证,然后取出该账号对应的角色,然后告诉客户端你是我们的用户,然后由网关(我在图上没有体现)把该玩家连接到响应的GameSvr上.
我们来分析这个图:客户端向服务器发送登陆请求,如果采用非阻塞式,使得各个客户端的请求形成非队列式,那么服务器压力不会很大,如果采用阻塞式,那么客户端感觉服务器处理速度就会很慢,玩家不答应,所以大多采用非阻塞式,处理速度快.而且玩家和账号数据库不是长期保持连接,只是保持一个心跳而已.这样就得出一个结论,用户在登陆的时候,对服务器不会造成多少压力.
那么什么时候会造成压力呢?
玩家走路,大家都知道,网络最主要的特点是同步信息,也就是说,当一个玩家走动以后,服务器首先要计算一次,当前玩家指的坐标是否正确,其次,服务器要下发消息,告诉周围的玩家,他现在在那里,怎么样的姿态存在.因为服务器会给一定范围内的玩家通知这些信息,造成服务器压力增多,因为服务器(GaemSvr)和玩家保持的是一个TCP的长连接,如果当前服务器或者一屏(或者说一定范围内的玩家相对比较多)的情况下,服务器要处理当前服务器上类似于上面描述的若干个这样的情况,造成服务器压力巨大.
除了走路,还有什么会造成服务器压力大呢?
聊天,为什么说聊天会造成服务器压力比较大呢?因为当A对B说话,服务器需要寻找,当前B在那里,然后通知A,B在,你可以说话给他,这个时候A才可能和B说话.如果人相对比较多的话,可能造成服务器压力大.
跨服务器行走,也会造成服务器压力巨大?
因为当你从一个服务器跨到另外一个服务器的时候,服务器需要把第一个服务器上玩家的数据拷贝的另外一个服务器,然后初始化一个实体,然后再告诉DB,把这个人的数据存盘一次,然后再尝试跨服务器,如果跨不成功,如果成功,则把该数据初始化给本玩家,如果不可以,则另外处理,这样造成服务器的压力大.
总上所述,不是所有的C/S结构的产品,我们以上来就模拟人多的情况怎么样,而是要分析,那块的压力真正的大,压力大的情况下会影响到游戏逻辑和数据在那里?需要冷静的分析这些情况,才可能有效的执行测试.
综上所述,我们知道网络的测试重点是相同通讯,数据同步和存储,那么在进行测试的时候,需要熟悉的了解各个部分相互通讯的模式是TCP还是UDP模式,那么各个模式有各个模式的特点.
TCP是通讯协议是把数据包进行精包装,然后在网络链路中进行发送,它需要进行三次握手才可以确定数据包的发送与否,丢包的几率很小,但是自身有补偿机制,使得包数据传输的过程中可靠性大大加强但是缺点是速度相对很慢.
UDP通讯是另外一种数据包传送模式,这种方式的特点是传送速度快,但是容易造成数据包丢弃.
所以除了了解各个部分的通讯协议之外还需要了解,当丢包了以后,对数据包进行补偿的两种方法,第一种方法是把从丢失的第一个包到当前包作为一个整体的包,进行包的重播,这样的方法会使得从客户端看到通常我们在游戏中所出现的”卡”现象,还有另外一种补偿机制,就是把前面的数据包丢弃,然后播放最后一个数据包信息,这样就会在其他的客户端看到一些莫名其妙的现象.
网络游戏还有一个测试点，任务系统的测试，在网络游戏中，任务系统是贯穿整个世界的，他反映了玩家在各个时期所能面临的挑战。任务系统的测试要点
Ø 任务逻辑
Ø 任务性价比
Ø 任务系统奖励的条件
Ø 任务系统放弃的条件
Ø 任务系统接收物品的条件
Ø 跨等级交接任务
Ø 满足接或者交的任务的条件中其中的一个
Ø 任务描述，任务记事本的描述和状态，任务道具的各种操作
为什么把任务系统单独提出来说，是因为在游戏中任务和交易是游戏中最容易出错的地方，而且最容易导致整个游戏中所谓刷钱的地方，如果游戏中通货膨胀，就可能造成整个游戏数据无法跟踪或者跟踪没有意义。
箱子也是重点测试之一，所谓箱子，主要是指玩家的储物想，交易时候玩家的背包，为什么把这两个单独提出来，这两个在几中情况下最容易出错。
Ø 给箱子存东西，然后断线（考虑存储速度）
Ø 给箱子存东西后，然后不关闭箱子，背着箱子跑（触发存储状态的条件）
Ø 交易的时候，来回切换server，在两个server之间进行（寻找数据同步的错误）
Ø 在存储物品以后，马上断线，然后在server和client保持ping的过程中，重新连上（考虑TCP/IP的特点）
Ø 在存储物品的时候，不关闭储物箱，可以背着箱子乱跑（箱子其实计算到了玩家的负重了）
以上是存储和交易时候必须测试的点，这是每一款网络游戏都容易犯错误的地方。
在做压力测试的时候大家都知道很多概念，但是在实际的工作中怎么分解，了解得人还不是很多。我下面给大家做一个简单的介绍，因为我们在做压力测试的时候，如果在公司内部构建和我们产品运营时候相同的网络环境，相同的硬件支持的话，开销非常大，有些开销是无谓的，所以就出现了现在有的作压力测试的时候，得出结论是现在环境是否可以承受或者说能够承受到什么程度，关于压力测试的分解工作几乎没有，为什么做这些压力，这些数据对你以后有什么分析价值等我们做过透彻分析。
很多人在使用诸如"容量评估"，"容量计划"，"趋势分析"和"预测" 等术语时，并没有真正理解这些词汇的含义。当有人提起"容量计划"时，通常是指他们的应用不能满足解决方案，而将被迫购买更多的硬件。
我们需要针对具体业务做一个实际的例子，可能大家能够看的更加明白。
业务描述：
硬件基本情况（服务器和未来上线的不同）
我们就分析一个业务，它是一个标准的C/S结构，我们从他的业务逻辑上分析它的压力点在哪里？然后结合实际情况，我们总结分析设计这些压力测试的点的方案。
那么根据业务本身，看来登陆的压力肯定是最大的，因为当登陆上去以后，玩家根据业务和本身需求，可以把各个服务器的压力减少进行调整，那么如何做和登陆服务器的压力测试呢，我们在开始工作之前需要获得几个数据：
第一， 按照原来服务器的设计，最多能容纳多少用户并发请求
第二， 对服务器性能占有率多少是能够接受的
第三， 对信息的处理方式是采用什么方式的（阻塞还是非阻塞）
第四， 单台服务器的处理能力和效率
接下来我们要做的事情就是：
第一， 准备测试数据
第二， 设计测试方案
第三， 总结测试数据进行分析
如何准备测试数据才能使得本次测试的有效性呢，主要分析我们的业务类型，以上图这个例子，我们只要发送一个合理的登陆请求，只要是一个合法的帐号就可以了，我们按照协议类型，开始制造测试数据，制造完成后我们来分析我们如何加压，假如我们的按照目前的规模服务器的处理能力是20000，按照5台来计算，那么单台服务器的处理能力是4000,那我们就开始利用单线程多进程的方法或者利用多台单客户端的形式伪造数据，然后让这些请求数据按照阻塞模式同时发送，可以制造同等压力，在这个过程中我们需要做的事情
第一， 我们需要观察服务器的I/O,内存，CPU
第二， 我们需要观察服务器对信息的处理能力（需要通过客户端对发出信息后得到服务端信息的反馈进行累积统计），长时间观察这个数据的变化，例如1个小时
第三， 慢慢减少压力，看看效率情况
如果在我们加压过程中服务器的cpu和内存持续增高，说明有漏内存，如果我们请求响应速度持续变慢，说明server队信息的处理能力可能有问题，如果在减少压力的过程中仍然表现不出来server的处理效率提高，说明server没有释放资源。
其实服务器的压力测试，在我看来，无非要做两个事情，你需要清楚的了解此类业务的服务请求，其次，你需要清楚地了解各个数据分析的过程。
WEB测试要点 Web测试的要点其实很多，但是Web测试的着力点其实不多，因为基于Web现在有两个重点，一种是基于平面的静态的，只是更新新闻，那么这个的测试点相对简单，主要是各个链接正确性，服务器浏览量等，还有另外一种就是基于Web的P To P的通讯，需要注册，牵扯到用户信息，那么这些测试重点在于P To P通讯的顺畅性，数据的可靠性。
我还是举例子说明问题。1999年网络在中国起步并风靡，它丰富了人们的生活，提供了更多的咨询信息。各种基于互联网的业务也相继展开。那么这些业务上线面临着什么?
就web测试点来说，有一些特别需要注意的，url地址，看似一个连接地址，非常重要，重要在那里，因为URL是包含了用户请求的信息的跳转，所以URL包含了部分用户的信息。
测试的时候需要注意几个问题
² URL所有包含用户信息的牵扯到用户隐私的需要加密
² URL中包含用户信息切牵扯到双方数据交互的需要完全信赖的确认信息
² URL需要过滤一些通用的字符，例如”.”,”.\”等，以免对服务端目录造成伤害
² 在页面中需要检查的内容：页面中所有的编辑框中需要跟内容匹配，有人恶意在里面输入SQL的语句，使得其他的信息就暴露在外面
² 删除server系统下的bak文件，原因是商家一般会做一些市场活动，那么会暂时的生成一些页面，到活动结束后，把正式文件删除掉了，但是备份文件没有删除，所以就会造成用户还可以访问被废除的活动页面。
² 有关验证的内容，建议服务断和客户断双重检查，以免有些伪装数据欺骗客户端代码，造成server不经过验证的情况下提供数据
² 需要对Cookie中的数据加以包含，一般的用户对这个数据不注意，也无法意识到他的重要性，所以经常被别人利用，所以商家需要保护消费者的数据安全。
² 在接收传递过来的服务端程序对数据类型需要进行判断，包括长度和类型，以免出现“string overflow”。
我下面就说几条：
第一， 性能，性能测试什么呢？
性能主要是指网络吞吐量，响应时间（单用户单独和单服务器能承载用户上满情况下单用户相应），IO量的大小，数据库查询速度。
包括一下几个方面：
第一， 单个用户发送单步请求到处理完成所花费的时间；
第二， 单个用户发送请求整个流程所需要的时间
第三， 在服务器负荷达到单个服务器处理能力情况下单步请求响应时间
第四， 在服务器负荷达到最高的情况下，整个流程处理请求处理的响应时间
第五， 在请求达到负荷的情况下IO量的大小，知道输入输出量的大小，以及写磁盘的频率
| 修改产品构思 |
| 创建/修改场景 |
| 修正性能指标 |
| 验证和确认模型 |
| 评估性能风险 |
| 确定关键案例 |
| 选择关键性能场景 |
| 建立性能目标 |
| 构造性能模型 |
| 增加软件资源需求 |
| 增加硬件资源需求 |
| 性能评估模型 |
第二， 安全性
安全性主要包括当前用户的安全性，总体用户的安全性，提交过程数据的安全性，用户数据的死锁现象等。
现在我们分析基于Web形式，用户发送请求，在发送过程中有可能出现什么问题呢？用户的数据在以网络包传输的过程中和在队列中等待处理出现问题？基于web的特性，我们平常所能触到的就几种做法（普通，非高手），第一，分析和修改URL地址，导致真正的请求被修改；第二，拦截数据包，修改数据包信息，导致真正的请求被修改；第三，攻击服务器，使得等待队列中的请求信息被修改。
| 用户请求 |
| 形成服务器处理队列 |
| 服务器处理业务 |
第三， 操作合理性
² 操作过程是否合理，包括操作流程，操作的易用性等多多考虑。
² 人性化，包括页面的层次重要信息页面的引导，页面的跳转
² 内容链接，内容的更新频率包括排版
相关阅读:
- 编码人员和测试人员经常争论 (aaliujing, 2007-9-26)
- 如何避免遗漏bug (aaliujing, 2007-9-26)
- 如何提高软件测试的水平 (aaliujing, 2007-9-26)
- 压力测试和性能测试的区别 (aaliujing, 2007-9-26)
- 测试计划编写策略 (aaliujing, 2007-9-26)
- Bug报告编写模板 (aaliujing, 2007-9-26)
- 测试用例模板 (aaliujing, 2007-9-26)
- 软件测试计划模板 (aaliujing, 2007-9-26)
- 测试基础一 (aaliujing, 2007-9-29)
- 测试基础二 (aaliujing, 2007-9-29)
TAG: 软件测试基础
