[活动]迎五一，庆周年，盖高楼(活动结束)

sn_asd520

解读二：
　　α   测试(alpha测试)：在开发小组内部进行，测试的方法也较多，黑盒、白盒、  压力、应力等等；   
　　β　测试（beta测试）：有选择地请一些最终用户实际使用，将发现的问题反馈回来再进行修改。

hjjlearning

安全测试并不只是测试安全方面的功能，比如确认加密功能是否正常运工作，安全测试必须用像扮演黑客这样的坏人角色的心态来窥探软件的运行过程。

sn_asd520

解读三：
　　简单扼要的说:   
　　alpha代表软件测试的第一个版本.(软件开发初期的版本,初具规模)   
　　beta代表软件测试的第二个版本.(象网上所提供的一些软件测试版本)   
　　final代表软件测试的第三个版本.(软件公司发布的版本)

sn_asd520

关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的 基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。
   
    至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。

    冒烟测试的说法据说是：

    就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。

    冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执 行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器 发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有 TCL，Perl，Python及功能弱弱的批处理。用这些可以完成系统的每日构建。

    简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费

    冒烟测试准则

    在软件中，“冒烟测试”这一术语描述的是在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

    注意：“冒烟测试”这一术语源自硬件行业。该术语源于此做法：对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。

    下面的准则描述了冒烟测试的最佳做法。遵循准则的效果会有很大的不同，从增强团队成员之间的交流，到形成特定的使用测试和调试工具的方式等。

    与开发人员协同工作
    由于冒烟测试特别关注更改过的代码，因此必须与编写代码的开发人员协同工作。必须了解以下内容：

    ·  代码中进行了什么更改。若要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。

    ·  更改对功能有何影响。

    ·  更改对各组件的依存关系有何影响。

    在进行冒烟测试前检查代码

    在运行冒烟测试前，进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。

    在干净的调试版本中安装私有二进制文件

    由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证，所以必须通过使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。

    注意

    在冒烟测试中，使用不匹配的二进制文件进行测试是一个常见错误。为了避免此错误，当两个或多个更新后的二进制文件之间存在依赖项时，请在测试版本中包括所有更新后的二进制文件。否则，测试的结果可能无效。

    创建每日构建 (Daily Build)

    每日构建要求团队成员协同工作，并鼓励开发人员彼此保持同步。如果新版本的迭代被延迟，则该延迟很容易导致具有多个依赖项的产品不同步。遵循每日构建和冒烟测试的过程，任何更改过的或新的二进制文件都可确保实现高质量。

    有关设置重复版本的更多信息，请参见在Team Foundation Build 中运行生成。有关验证产品版本的更多信息，请参见如何：配置和运行生成验证测试 (BVT)。

    注意

    将高质量的每日构建作为团队最重要的任务。如果由于签入代码未进行冒烟测试而导致版本中断，则需要开发人员和测试人员停止所有其他工作，直到问题被解决为止。对导致中断版本的人员的处罚不应该很重，但这个处罚一定要能强调这样一个道理：正确的每日构建是团队最重要的任务。

    不需要执行穷举测试。冒烟测试的目的不是确保二进制文件100% 没有错误。这样需要花费太多的时间。执行冒烟测试是为了在高级别验证版本。要确保二进制文件中的更改不会破坏常规版本的稳定性，也不会导致功能中出现严重错误。

    Web测试和负载测试

    生成Web测试和负载测试时，在运行任何时间长、工作量大的测试之前运行冒烟测试是一种很好的做法。在Web测试和负载测试中，冒烟测试时间短，工作量也小。使用冒烟测试是为了在运行性能测试或压力测试之前，确保一切都已正确配置并可按预期运行。

hjjlearning

游戏测试作为软件测试的一部分，具备了软件测试所有的共同特性：
1、测试的目的是发现软件中存在的缺陷；
2、测试需要测试人员按照产品需求描述来实施；
3、测试必须模拟真实环境；

hjjlearning

游戏测试具备了所有特性，也有游戏的特殊性，分为2部分：
1、传统的功能性方面测试，包括功能是否正常，美术是符合标准，程序是否会崩溃等，，，
2、游戏代表着现实世界的虚拟性，包含了现实社会的一部分特性，如涉及到娱乐性，可玩性等，称为游戏世界测试，包含下面特性：
游戏情感世界测试，包括任务系统等；
游戏世界平衡性测试，包括经济平衡，技能平衡，职业平衡等；
游戏主题风格测试，比如整个游戏世界的风格，是中国文化主导，还是日韩风格等等，大到游戏整体，小到NPC（游戏世界人物）对话，比如一个书生，他的对话就必需斯文，不可以用江湖语言。

sn_asd520

谈到自动化测试，一般就会提到测试工具。许多人觉得使用了一、两个测试工具就是实现了测试自动化，这种理解是不对的，至少是片面的。的确，测试工具的使用是自动化测试的一部分工作，但“用测试工具进行测试”不等于“自动化测试”。那什么是“自动化测试”？ 半自动化测试过程，算不算自动化测试？是否可以为“自动化测试”给出如下定义？

　　以自动化的方式完成测试？

　　测试过程的自动化?

　　将手工测试的过程变成了自动化测试的过程？

　　摆脱手工测试的各种途径和方法？

　　自动化为测试而存在的，所以自动化测试的真正含义可以理解为“一切可以由测试是相对手计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”。它包含了下列3层含义：

　　“一切”，不仅仅指测试执行的工作——对被测试的对象进行验证，还包括测试的其它工作，如缺陷管理、测试管理、环境安装、设置和维护等。

　　“可以”，意味着某些工作无法由系统自动完成，如脚本的开发、测试用例的设计，需要创造性，其工作需要手工处理。

　　即使由系统进行自动化测试，还少不了人的干预，包括事先安排自动化测试任务、测试结果分析、调试测试脚本等。

　　严格意义上，“自动化测试（Automated Testing）”不等于“测试自动化（Test Automation）”。自动化测试，模拟手工测试步骤，通过执行程序语言编制的测试脚本自动地测试软件，自动地实施软件的单元测试、功能测试、负载测试或性能测试等。自动化测试集中体现在实际测试执行（test execution）的过程，也就是由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。自动化测试，强调借助工具（不仅仅是工具，有时包括策略和工件）来完成测试的执行，也就是用工具来帮助或辅助测试，这个执行过程可能是全自动的，也可能是半自动的。

　　测试自动化的要求高得多，侧重说明将测试用自动化设计和实现的过程，即所有的测试工作都能有计算机系统自动完成，包括：

　　测试环境的搭建和设置，如上载安装包到服务器；

　　脚本自动生成，如根据UML状态图、时序图等生成可运行的测试脚本；

　　测试数据的自动产生，例如自动产生数据负载测试所需要的大量数据；

　　测试操作步骤的自动执行，包括测试执行过程的控制；

　　测试结果分析，实际输出和预期输出的自动对比分析；

　　测试流程的自动处理，即测试工作流的自动实现，包括测试计划复审和批准、测试任务安排和执行、缺陷生命周期等流程的自动化处理。

　　测试报告自动生成功能等。

　　这样，测试自动化意味着测试全过程的自动化和测试管理工作的完全自动化，是测试工程师所追求的一种理想境界，但是很难实现的。往往不能完全通过全自动化过程来完成一个完整的测试任务，自动化到不需要人工参与的程度是不现实的。虽然不能完全实现那种理想境界，但是我们每时每刻可以向这个方向去思考，优化每项工作，一切可以由计算机系统自动完成的测试任务都已经由计算机系统或工具来承担并自动执行。

　　在一般情况下，人们并不严格区分“自动化测试”和“测试自动化”，就是通过工具或程序来对软件进行测试，一般不需要大量的手工操作来完成测试，而只要很少的人工干预。自动化测试，理应从工作效率和产品质量的目的出发，而不是为了自动化而自动化，在某些时刻，也可能得不偿失，即投入过大，产出远远小于投入。脱离了目的，测试人员可能会变成自动化测试的奴隶。奢想做到百分之百地实现自动化测试，不仅不现实，所引起的代价可能会非常大，而且可能引起负面性，造成质量水平的降低。

　　最后，我们还不得不承认，自动化测试和手工测试往往交织在一起，相互补充，工具执行过程往往需要人工分析，手工测试时也可以借助工具处理某些数据、日志或显示某些信息。也就是说，不是试图用自动化测试来代替所有的手工测试，而应该在尊重手工测试的同时，尽量采用自动化测试，根据各自的特点充分发挥各自的优势，使手工测试和自动化测试实现完美结合。

fei.ge

覆盖评测


　　覆盖指标提供了"测试的完全程度如何？"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。


　　系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。


　　如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 75% 的性能测试需求。


　　如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。


　　两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。

sn_asd520

白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：

　　1）保证一个模块中的所有独立路径至少被使用一次；

　　2）对所有逻辑值均需测试true和false；

　　3）在上下边界及可操作范围内运行所有循环；

　　4）检查内部数据结构以确保其有效性。

　　“我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？”答案在于软件自身的缺陷：

　　· 逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。

　　· 我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。

　　· 笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。

　　正如Beizer所说的：“错误潜伏在角落里，聚集在边界上”，而白盒测试更可能发现它

　　国内很少公司花很大的精力去做白盒测试，一般在单元测试过程中，白盒测试全是由开发人员来完成，商业软件所使用到的技术主要是黑盒测试技术，这是其特点所决定的。还有少量的白盒技术，但在实际中很少有公司愿意投入人力来作。

　　白盒测试的方法：

　　1.确定软件中的模块（数据计算、校验模块、功能模块）

　　2.在每一个模块中用常用的覆盖率覆盖方法计算所有满足的路径（覆盖率方法有很多，看软件要求程度，比如航空、医疗软件要求严格，使用Do-178B的MC/DC覆盖率标准）

　　3.设计测试用例，满足覆盖要求（注：想满足所有路径都覆盖是不可能的，花费也随之上升，没有公司愿意这么做，不现实）。

　　在经费和时间不足的情况下，应采取对关键点的白盒测试，就是针对重要环节的测试，然后用黑盒测试做补充，目前国内大多数公司采用：先对软件进行黑盒测试，然后查看覆盖率再对未覆盖的代码进行白盒测试，这样做可以节省时间和花费，当然缺点也有，毕竟黑盒测试不能代替白盒测试，即使在正确的输入下得到正确的输出也未必是所设想的路径。

　　来看一个实际案例：有两个产品形态接近的项目，A项目正式实施单元测试与集成测试，另一个项目B项目没正式做白盒测试（简单的拿调试当测试）。最后项目结束时对研发全过程的全部问题进行缺陷分析。

　　A. 项目的缺陷类型分析

　　B. 项目的缺陷类型分析

　　A项目的所有问题中，应该发现问题的阶段是白盒测试（单元测试与集成测试）的占50%，而B项目所有问题中，应在白盒测试阶段发现的仅占33%，另外，A项目发现逻辑错误占13%，而B项目只占8%。由这个统计数据表明，不做白盒测试必然导致大量问题漏测。

　　白盒测试要做到什么程度才算合适

　　既然白盒测试不可或缺，那么，白盒测试应做到什么程度才算合适呢？具体来说，白盒测试与黑盒测试应维持什么样的比例才算合适？

　　一般而言，白盒测试做多做少与产品形态有关，如果产品更多的具备软件平台特性，白盒测试应占总测试的80%以上，甚至接近100%，而如果产品具备复杂的业务操作，有大量GUI界面，黑盒测试的份量应该更重些。根据经验，对于大多数嵌入式产品，白盒方式展开测试（包括代码走读）应占总测试投入的一半以上，白盒测试发现的问题数也应超过总问题数的一半。

　　由于产品的形态不一样，很难定一个标准说某产品必须做百分之多少白盒测试，但依据历史经验，我们还可以进行定量分析的。比如，收集某产品的某历史版本在开发与维护中发生的所有问题，对这些问题进行正交缺陷分析（Orthogonal Defect Classification，ODC），把“问题根源对象”属于概要设计、详细设计与编码的问题整理出来，这些都是属于白盒测试应发现的问题，统计这些问题占总问题数的比例，大致就是白盒测试应投入的比例。

　　通过正交缺陷分析，还能推论历史版本各阶段测试的遗留缺陷率，根据“发现问题的活动”，能统计出与“问题根源对象”不相匹配的问题数，这些各阶段不匹配问题的比例就是该阶段的漏测率。

hjjlearning

测试用例的作用：
        1、指导测试实施
                测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。       
                根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。
        2、保证测试有效性
                保证软件被测有效性，通过测试用例验证产品功能是否与需求一致，测试用例能使测试人员知道那些功能已被测，那些功能还需要测试，从而避免漏测，重复测，随机测试，提高测试效率。
        3、积累测试知识财富       
                影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

sn_asd520

对于集成测试，初学者往往比较模糊，到底怎么测？是不是把两个模块连在一起，然后采用单元测试的技术，测试这个更大的模块？

　　我们都知道，集成测试关注的是模块之间的接口。那么可以将“接口”作为切入点。纵观模块之间的接口，我们可以归纳为以下几种类型，下面一一介绍一下。

　　1、通信协议：两个模块之间通信采用的是标准的或者自定义的（网络）协议；
　　协议中即包含数据部分，又包含控制部分；有些实现将数据与控制分离，如FTP；而大部分实现将数据与控制通过一条链路来传递，往往通过不同的消息包进行分离。

　　2、调用关系：模块A调用模块B，实际上是由模块A向模块B发出了一条控制指令，这里数据传递体现的不是很明显，往往体现为参数与返回值，它们可以认为是控制的副本。

　　3、文件、数据库、队列、第三方中间件等：表现的主要是数据的传递，其中的控制体现的不明显。

　　4、共享资源：比如共享一段“存储区域”，其中涉及的关键资源主要是“锁”了；这样的两个模块在运行时往往分布到不同的进程或者线程中，表现为对资源的竞争，以及数据的共享。

　　5、同步：一个模块的运行需要另外一个模块的触发，双方往往存在“信号”等通知机制，也可以理解为一种特殊的控制方式。

　　OK，现在切入点有了，我们可以将被测系统归类（以上的分类），找出其中的数据接口与控制接口。

　　接下来的做法与一般的测试思路没有什么不同。
　　首先，将数据接口与控制接口分解——需要传递哪些数据？存在哪些控制指令？
　　然后，找出数据与指令中的变数所在；如数据（协议包）中的字段的取值，指令的参数变化等；
　　接下来，将变数划分等价类，找出每类的代表，就是我们的测试数据了——我们的目标是：让每类数据流与控制流均通过接口一次，从而实现接口测试的完全性；
　　最后，就是考虑如何生成这些测试数据了。往往需要对应到集成后“大模块”的输入与输出。

　　谈了很多，上面的内容更多的关注了实现。下面我们要考虑另外一个侧面——业务。
　　模块之间的联系（接口）往往是为了体现业务上的关联。大家都知道，关联本身也是有很多属性的。如关联点（每个模块）都存在一个角色，关联有多重性（multiplicity）——即模块A在运行时可能对应多个模块B的实例。

　　我们找到了测试的另外一个切入点，模块的集成能否准确体现业务上的关联？各个模块是否具备其角色的全部属性和接口，模块之间的关联关系如何打破？关联的多重性是否有效？

　　当然，集成测试不会太关心业务或者需求，那是系统测试的事了。但此时想想，往往能够得到意外的收获。

　　太多的关注功能，往往忽略其他。有时我们不得不考虑接口的性能，尤其对于系统关键接口。接口的性能测试越早进行越好。如果等到系统测试时做，可能接口外面封装了太多的代码，影响性能问题的精确定位。

hjjlearning

4、评估测试结果的基准
        完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试用例合格率是多少、重要测试用例合格率是多少，等等。以前统计可能都比较粗糙，没什么量化统计标准，采用测试用例作度量基准更加准确、有效。
5、分析软件缺陷的标准
        通过收集缺陷，对比测试用例和缺陷管理平台数据，分析缺陷产生的原因，是漏测还是缺陷复现。漏测则反应了测试用例的不完整，应补充相关测试用例，逐步完善测试用例库，完善产品质量。而已有相应测试用例，则反映实施测试或变更处理存在问题

sn_asd520

目前流行的软件测试有八项基本原则，这八项基本原则可以指导我们更有效的执行软件测试。

　　1、应当把“尽早和不断的测试”作为开发者的座右铭

　　测试应该尽早进行，最好在需求阶段就开始介入，不要等到软件产品做完了才开始。

　　2、程序员应该避免检查自己的程序，软件测试应该由第三方构造。程序员对自己的程序已经产生抗体，所以测试自己的程序无法测试深层次的缺陷。

　　3、设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断，电源断电等。

　　4、一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。测试中存在群集现象，错误喜欢发现在相同的模块以及相关的开发人员编写的程序。

　　5、对测试错误结果一定要有一个确认过程。一般由A测试出来的错误，一定要有一个B来确认。严重的错误可以召开评审会议进行讨论和分析，对测试的结果要进行严格的确认，是否真的存在这个问题，问题的严重程度是否正确等。

　　6、制定严格的测试计划，并把测试时间安排的尽量宽松。不要希望在极短的时间内完成一个高水平的测试。一定要制定测试计划，但不要为了做测试计划文档而制定测试计划，测试计划一定要有指导性。

　　7、回归测试的关联性一定要引起充分注意。修改一个错误而引起更多错误出现的现象并不少见。

　　8、妥善保存一切测试过程文档。测试的重现性往往要靠测试文档来体现。软件测试过程中产生的文档要纳入配置管理库，进行严格的版本控制，不能随意的修改测试文档，需要制定变更测试文档的流程。

sn_asd520

一套完整的测试应该由五个阶段组成：

　　1．测试计划

　　首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。

　　2．测试设计

　　将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。

　　3．测试开发

　　建立可重复使用的自动测试过程。

　　4．测试执行

　　执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。

　　5．测试评估

　　结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

　　显然，黑盒测试只有严格按照步骤进行，才可能对应用程序的质量进行把关。然而，如果没有一种优秀的测试工具的帮助，单纯凭借手工测试，不但将耗费大量的人力、物力和财力，而且有很多测试工作是难以实现甚至是无法实现的。

fei.ge

好了，不抢楼位了。

基于代码的测试覆盖


　　基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。

sn_asd520

吞吐量（throughput）

吞吐量，是指单位时间内流经被测系统的数据流量，一般单位为b/s,即每秒钟流经的字节数。
吞吐量是大型门户网站以及各种电子商务网站衡量自身负载能力的一个很重要的指标，一般吞吐量越大，系统单位时间内处理的数据越多，系统的负载能力也越强。
吞吐量和很多因素有关，比如服务器的硬件配置，网络的拓扑结构，软件的技术架构等。实际工作中，我们往往对升级客户的硬件配置无能为力，大多数情况下，我们还是在软件的技术架构上做文章：
比如后台数据库装oracle还是装sql server,显然前者的处理能力更强；
web服务器是用weblogic还是iis，要看服务器端的语言是jsp还是asp…
测试的时候多跟项目经理，系统架构师以及用户沟通，来获取系统架构的第一手材料。

sn_asd520

并发（concurrency）

并发，是指多个同时发生的操作。比如有10个用户同时点击“登录”按钮（注意是同时），来登录163邮箱，我们就说此次登录163邮箱的并发数为10。
需要注意的是，并发和并行不是一个概念，并发是同时发生，并行是同步运行。10个用户并发登录163邮箱，只是在点击“登录”按钮那一瞬间是并行的，而登录后各个用户的操作则不同步。

Gray

Stress Testing:
在高负载的情况下来对系统的稳定性进行测试，更有效发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患。
特点：极限

sn_asd520

压力测试（stress testing）

压力测试，是性能测试的一种，通常是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。
比如我们不断增加并发的登录用户数，20，30，50…比如，当增加到70个用户并发登录时，系统崩溃了，我们就可以知道163邮箱所能承载的最大登录并发数为70个左右。

sn_asd520

超级并发用户

对于一个网站来讲,可能存在WEB服务器、应用服务器、数据库服务器三个层次，而用户所使用的浏览器是在最外面的客户端层面。如果某个时间点或时间段内，共有1000个用户同时在线，他们进行着各种各样的操作，而某个时间点上可能存在10个左右的用户同时进行了一个或多个操作，导致WEB服务器同时接收到了10个左右的交易请求，我们称这个10个左右的用户为超级并发用户。当进行性能测试时，如果你使用的是超级并发用户，则可以称之为超级并发负载。