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

shadowlan

loadrunner的内部编译器采用ANSI C,它有三种类型的变量：

1、基于堆栈的变量
这类变量的定义如下：
int intSample；
char charSample[5];
这类变量作用范围就是某个action或者你定义的函数。

2、基于heap的变量
这类变量的定义如下：
int *intSample；
char *charSample;
它们必须被明确的分配内存，也需要用free（）函数释放。

3、参数（lr自己管理的变量）
这类变量可以用web_reg类的函数定义，也可以用lr_save_string定义，用lr_eval_string获取它的值，它的作用范围为整个脚本（类似全局变量）。

贝贝酷

GB 18030 testing（GB 18030测试）：
软件支持GB 18030字符集标准能力的测试，包括GB 18030字符的输入、输出、显示、存储的支持程度。

水上飘

划分等价类：
  等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类

水上飘

软件的易理解程度和可维护程度是衡量软件质量的重要指标，对于程序是否容易修改有重要影响。为使得软件更加容易理解和维护，需要从多方面做出努力。首先，要有详细且正确的软件文档，同时文档应始终与软件代码保持一致；其次，编写的代码应该具有良好的编程风格，如采用较好的程序结构，增加必要的程序注释，尽量使用行业或项目规定的标准等。

贝贝酷

Priority（优先权）：
从商业角度出发是指错误的重要性，尤其是从客户和用户的角度出发，是指错误对于系统的可行性和可接受性的影响。与“Severity（严重性）”相对照。

贝贝酷

Severity（严重性）：
错误对被测系统的影响程度，在终端用户条件下发生的可能性，软件错误妨碍系统使用的程度。

水上飘

测试计划是对针对将要执行的测试过程进行整体进行规划安排说明的，测试计划中要对测试任务进行描述，譬如测试时间、测试范围、测试内容、测试人员安排、测试目标、测试环境等等，同时测试计划中还要注明测试工作阶段里程碑及阶段任务的输出。

水上飘

灰盒测试，介于白盒测试与黑盒测试之间，灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
　　灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

AJan1000

在性能测试结果分析当中，在性能测试结果分析当中，分析系统日志是分析定位错误的有效手段之一。
那系统日志包含哪些了，如何找到？
列举如下，大家参考。
目前web系统很多都要求程序员在程序当中写入log，一旦发生异常现象，就将异常的内容写到系统指定的存放log的文件当中。
该log文件可以用来作为性能测试工具运行完测试后，分析测试过程的依据。
另外大家可能最常用到的就是widows当中的系统日志，双击“我的电脑”－控制面板-管理工具－事件查看器，在事件查看器当中
左边的树目录当中选择“应用”节点，就可以看到当应用程序发生错误或者异常时，系统会捕获该异常，并将其写到事件查看器当中去，
测试当中是否导致了系统错误，就可以在这里面找着啦～！

walker1020

风险通常可以用来决定从什么地方开始测试，什么地方需要更多的测试。测试可以用来降低风险或可以减少负面事件的影响。

walker1020

产品风险对于项目的成功来讲是一种特殊类型的风险。作为一种风险控制活动，测试通过评估修复严重缺陷的能力和应急计划的有效性来提供关于残留风险的反馈信息。

mvjh13

同行评审是业界公认的最有效的排错手段之一。我们在需求测试过程当中，使用最多的也是同行评审（ Peer Review ），尤其是正规检视（ Inspection ）。正规检视是由 Michael Fagan 在 I B M 制定出来的一种非常严格的评审过程。
    需求评审的参与者当中，必须要有用户或用户代表参与，同时还需要包括项目的管理者，系统工程师和相关开发人员、测试人员、市场人员、维护人员等。在项目开始之初就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏掉某些人员的意见，导致今后不同程度的返工。

水上飘

恢复测试是通过各种手段，让软件强制性地发生故障，然后来验证恢复是否能正常进行的一种系统测试方法。如果恢复是自动的（由系统本身来进行的），重新初始化、检查点机制、数据恢复和重启动都要进行正确验证。如果恢复是需要人工干预的，那么要估算修复的平均时间是否在可以接受的范围之内。

如夏之晴

测试大体上可分为手工测试和自动化测试。根据敏捷原则，要确保能用自动化测试的事情决不要用手工测试。同时要做到适合手工测试的内容决不要花高昂地成本做成自动化测试。另外，不要因为某方面不能自动化测试而不做测试。

贝贝酷

Quality assurance（质量保证QA）：
采取相关活动，以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

贝贝酷

Review（评审）：
在产品开发过程中，把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

水上飘

灰盒测试，介于白盒测试与黑盒测试之间，灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。

水上飘

等价类中的元素的共同点：如果用等价类中的一个元素进行测试不能发现故障，那么使用等价类中其他元素进行测试液不可能发现故障。也就是说：对揭露软件中的故障来说，等价类中的每个元素是等效的

walker1020

迭代-增量开发模型(iterative-incremental development model)由需求建立、设计、构建和测试等一系列相对较短的开发周期构成。比如：原型开发、快速应用开发（RAD）、统一软件开发过程（RUP）和敏捷开发模型等。作为其开发的一部分，迭代产生的系统需在不同的测试级别上进行测试。通过将增量模块加入到以前开发的模块中，形成一个渐渐增大的系统，这个系统同样需要进行测试。在完成第一次迭代后，对所有的迭代进行回归测试会变得越来越重要。验证和确认可以在每个增量模块中进行。

水上飘

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

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

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

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

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

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

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

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

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

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