-
什么是冒烟测试(转)
2008-03-31 08:41:36
[摘要] 关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。[关键字] 软件测试 冒烟测试 验收测试
关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的 基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。
至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。
冒烟测试的说法据说是：
就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。
冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执 行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器 发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有 TCL，Perl，Python及功能弱弱的批处理。用这些可以完成系统的每日构建。
简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费
冒烟测试准则
在软件中，“冒烟测试”这一术语描述的是在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
注意：“冒烟测试”这一术语源自硬件行业。该术语源于此做法：对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。
下面的准则描述了冒烟测试的最佳做法。遵循准则的效果会有很大的不同，从增强团队成员之间的交流，到形成特定的使用测试和调试工具的方式等。
与开发人员协同工作
由于冒烟测试特别关注更改过的代码，因此必须与编写代码的开发人员协同工作。必须了解以下内容：· 代码中进行了什么更改。若要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。
· 更改对功能有何影响。
· 更改对各组件的依存关系有何影响。
在进行冒烟测试前检查代码
在运行冒烟测试前，进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。
在干净的调试版本中安装私有二进制文件
由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证，所以必须通过使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。
注意
在冒烟测试中，使用不匹配的二进制文件进行测试是一个常见错误。为了避免此错误，当两个或多个更新后的二进制文件之间存在依赖项时，请在测试版本中包括所有更新后的二进制文件。否则，测试的结果可能无效。
创建每日构建 (Daily Build)
每日构建要求团队成员协同工作，并鼓励开发人员彼此保持同步。如果新版本的迭代被延迟，则该延迟很容易导致具有多个依赖项的产品不同步。遵循每日构建和冒烟测试的过程，任何更改过的或新的二进制文件都可确保实现高质量。
有关设置重复版本的更多信息，请参见 在 Team Foundation Build 中运行生成。有关验证产品版本的更多信息，请参见如何：配置和运行生成验证测试 (BVT)。
注意
将高质量的每日构建作为团队最重要的任务。如果由于签入代码未进行冒烟测试而导致版本中断，则需要开发人员和测试人员停止所有其他工作，直到问题被解决为止。对导致中断版本的人员的处罚不应该很重，但这个处罚一定要能强调这样一个道理：正确的每日构建是团队最重要的任务。
不需要执行穷举测试。冒烟测试的目的不是确保二进制文件 100% 没有错误。这样需要花费太多的时间。执行冒烟测试是为了在高级别验证版本。要确保二进制文件中的更改不会破坏常规版本的稳定性，也不会导致功能中出现严重错误。
Web 测试和负载测试
生成 Web 测试和负载测试时，在运行任何时间长、工作量大的测试之前运行冒烟测试是一种很好的做法。在 Web 测试和负载测试中，冒烟测试时间短，工作量也小。使用冒烟测试是为了在运行性能测试或压力测试之前，确保一切都已正确配置并可按预期运行。
-
HTTP错误大全
2007-05-31 12:54:44
HTTP 400 - 请求无效
HTTP 401.1 - 未授权：登录失败
HTTP 401.2 - 未授权：服务器配置问题导致登录失败
HTTP 401.3 - ACL 禁止访问资源
HTTP 401.4 - 未授权：授权被筛选器拒绝
HTTP 401.5 - 未授权：ISAPI 或 CGI 授权失败
HTTP 403 - 禁止访问
HTTP 403 - 对 Internet 服务管理器 的访问仅限于 Localhost
HTTP 403.1 禁止访问：禁止可执行访问
HTTP 403.2 - 禁止访问：禁止读访问
HTTP 403.3 - 禁止访问：禁止写访问
HTTP 403.4 - 禁止访问：要求 SSL
HTTP 403.5 - 禁止访问：要求 SSL 128
HTTP 403.6 - 禁止访问：IP 地址被拒绝
HTTP 403.7 - 禁止访问：要求客户证书
HTTP 403.8 - 禁止访问：禁止站点访问
HTTP 403.9 - 禁止访问：连接的用户过多
HTTP 403.10 - 禁止访问：配置无效
HTTP 403.11 - 禁止访问：密码更改
HTTP 403.12 - 禁止访问：映射器拒绝访问
HTTP 403.13 - 禁止访问：客户证书已被吊销
HTTP 403.15 - 禁止访问：客户访问许可过多
HTTP 403.16 - 禁止访问：客户证书不可信或者无效
HTTP 403.17 - 禁止访问：客户证书已经到期或者尚未生效 HTTP 404.1 -
无法找到 Web 站点
HTTP 404- 无法找到文件
HTTP 405 - 资源被禁止
HTTP 406 - 无法接受
HTTP 407 - 要求代理身份验证
HTTP 410 - 永远不可用
HTTP 412 - 先决条件失败
HTTP 414 - 请求 - URI 太长
HTTP 500 - 内部服务器错误
HTTP 500.100 - 内部服务器错误 - ASP 错误
HTTP 500-11 服务器关闭
HTTP 500-12 应用程序重新启动
HTTP 500-13 - 服务器太忙
HTTP 500-14 - 应用程序无效
HTTP 500-15 - 不允许请求 global.asa
Error 501 - 未实现
HTTP 502 - 网关错误用户试图通过 HTTP 或文件传输协议 (FTP) 访问一台正在运行 Internet 信息服务 (IIS) 的服务器上的内容时，IIS 返回一个表示该请求的状态的数字代码。该状态代码记录在 IIS 日志中，同时也可能在 Web 浏览器或 FTP 客户端显示。状态代码可以指明具体请求是否已成功，还可以揭示请求失败的确切原因。
日志文件的位置
在默认状态下，IIS 把它的日志文件放在 %WINDIRSystem32Logfiles 文件夹中。每个万维网 (WWW) 站点和 FTP 站点在该目录下都有一个单独的目录。在默认状态下，每天都会在这些目录下创建日志文件，并用日期给日志文件命名（例如，exYYMMDD.log）。
HTTP
1xx - 信息提示
这些状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。 • 100 - 继续。
• 101 - 切换协议。
2xx - 成功
这类状态代码表明服务器成功地接受了客户端请求。 • 200 - 确定。客户端请求已成功。
• 201 - 已创建。
• 202 - 已接受。
• 203 - 非权威性信息。
• 204 - 无内容。
• 205 - 重置内容。
• 206 - 部分内容。
3xx - 重定向
客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。 • 302 - 对象已移动。
• 304 - 未修改。
• 307 - 临时重定向。
4xx - 客户端错误
发生错误，客户端似乎有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。 • 400 - 错误的请求。
• 401 - 访问被拒绝。IIS 定义了许多不同的 401 错误，它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在 IIS 日志中显示： • 401.1 - 登录失败。
• 401.2 - 服务器配置导致登录失败。
• 401.3 - 由于 ACL 对资源的限制而未获得授权。
• 401.4 - 筛选器授权失败。
• 401.5 - ISAPI/CGI 应用程序授权失败。
• 401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
• 403 - 禁止访问：IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因： • 403.1 - 执行访问被禁止。
• 403.2 - 读访问被禁止。
• 403.3 - 写访问被禁止。
• 403.4 - 要求 SSL。
• 403.5 - 要求 SSL 128。
• 403.6 - IP 地址被拒绝。
• 403.7 - 要求客户端证书。
• 403.8 - 站点访问被拒绝。
• 403.9 - 用户数过多。
• 403.10 - 配置无效。
• 403.11 - 密码更改。
• 403.12 - 拒绝访问映射表。
• 403.13 - 客户端证书被吊销。
• 403.14 - 拒绝目录列表。
• 403.15 - 超出客户端访问许可。
• 403.16 - 客户端证书不受信任或无效。
• 403.17 - 客户端证书已过期或尚未生效。
• 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
• 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
• 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。
• 404 - 未找到。 • 404.0 -（无） – 没有找到文件或目录。
• 404.1 - 无法在所请求的端口上访问 Web 站点。
• 404.2 - Web 服务扩展锁定策略阻止本请求。
• 404.3 - MIME 映射策略阻止本请求。
• 405 - 用来访问本页面的 HTTP 谓词不被允许（方法不被允许）
• 406 - 客户端浏览器不接受所请求页面的 MIME 类型。
• 407 - 要求进行代理身份验证。
• 412 - 前提条件失败。
• 413 – 请求实体太大。
• 414 - 请求 URI 太长。
• 415 – 不支持的媒体类型。
• 416 – 所请求的范围无法满足。
• 417 – 执行失败。
• 423 – 锁定的错误。
5xx - 服务器错误
服务器由于遇到错误而不能完成该请求。 • 500 - 内部服务器错误。 • 500.12 - 应用程序正忙于在 Web 服务器上重新启动。
• 500.13 - Web 服务器太忙。
• 500.15 - 不允许直接请求 Global.asa。
• 500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。
• 500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。
• 500.100 - 内部 ASP 错误。
• 501 - 页眉值指定了未实现的配置。
• 502 - Web 服务器用作网关或代理服务器时收到了无效响应。 • 502.1 - CGI 应用程序超时。
• 502.2 - CGI 应用程序出错。application.
• 503 - 服务不可用。这个错误代码为 IIS 6.0 所专用。
• 504 - 网关超时。
• 505 - HTTP 版本不受支持。
常见的 HTTP 状态代码及其原因
• 200 - 成功。 此状态代码表示 IIS 已成功处理请求。
• 304 - 未修改。 客户端请求的文档已在其缓存中，文档自缓存以来尚未被修改过。客户端使用文档的缓存副本，而不从服务器下载文档。
• 401.1 - 登录失败。 登录尝试不成功，可能因为用户名或密码无效。
• 401.3 - 由于 ACL 对资源的限制而未获得授权。 这表示存在 NTFS 权限问题。即使您对试图访问的文件具备相应的权限，也可能发生此错误。例如，如果 IUSR 帐户无权访问 C:WinntSystem32Inetsrv 目录，您会看到这个错误。 有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
187506 INFO: IIS 4.0 的基础 NTFS 权限
• 403.1 - 执行访问被禁止。 下面是导致此错误信息的两个常见原因： • 您没有足够的执行许可。例如，如果试图访问的 ASP 页所在的目录权限设为“无”，或者，试图执行的 CGI 脚本所在的目录权限为“只允许脚本”，将出现此错误信息。若要修改执行权限，请在 Microsoft 管理控制台 (MMC) 中右击目录，然后依次单击属性和目录选项卡，确保为试图访问的内容设置适当的执行权限。
• 您没有将试图执行的文件类型的脚本映射设置为识别所使用的谓词（例如，GET 或 POST）。若要验证这一点，请在 MMC 中右击目录，依次单击属性、目录选项卡和配置，然后验证相应文件类型的脚本映射是否设置为允许所使用的谓词。
• 403.2 - 读访问被禁止。验证是否已将 IIS 设置为允许对目录进行读访问。另外，如果您正在使用默认文件，请验证该文件是否存在。 有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
247677 错误信息：403.2 Forbidden:Read Access Forbidden（403.2 禁止访问：读访问被禁止）
• 403.3 - 写访问被禁止。 验证 IIS 权限和 NTFS 权限是否已设置以便向该目录授予写访问权。有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
248072 错误信息：403.3 Forbidden:Write Access Forbidden（403.3 禁止访问：写访问被禁止）
• 403.4 - 要求 SSL。禁用要求安全通道选项，或使用 HTTPS 代替 HTTP 来访问该页面。如果没有安装证书的 Web 站点出现此错误，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
224389 错误信息：HTTP 错误 403、403.4、403.5 禁止访问：要求 SSL
• 403.5 - 要求 SSL 128。禁用要求 128 位加密选项，或使用支持 128 位加密的浏览器以查看该页面。如果没有安装证书的 Web 站点出现此错误，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
224389 错误信息：HTTP 错误 403、403.4、403.5 禁止访问：要求 SSL
• 403.6 - IP 地址被拒绝。您已把您的服务器配置为拒绝访问您目前的 IP 地址。 有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
248043 错误信息：403.6 - Forbidden:IP Address Rejected（403.6 - 不可用：IP 地址被拒绝）
• 403.7 - 要求客户端证书。您已把您的服务器配置为要求客户端身份验证证书，但您未安装有效的客户端证书。 有关其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
190004 错误 403.7 或“Connection to Server Could Not Be Established”（无法建立与服务器的连接）
186812 PRB：错误信息：403.7 Forbidden:Client Certificate Required（403.7 禁止访问：要求客户端证书）
• 403.8 - 站点访问被拒绝。您已为您用来访问服务器的域设置了域名限制。有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
248032 错误信息：Forbidden:Site Access Denied 403.8（禁止访问：站点访问被拒绝 403.8）
• 403.9 - 用户数过多。与该服务器连接的用户数量超过了您设置的连接限制。 有关如何更改此限制的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
248074 错误信息：Access Forbidden:Too Many Users Are Connected 403.9（禁止访问：连接的用户太多 403.9）
注意：Microsoft Windows 2000 Professional 和 Microsoft Windows XP Professional 自动设置了在 IIS 上最多 10 个连接的限制。您无法更改此限制。
• 403.12 - 拒绝访问映射表。 您要访问的页面要求提供客户端证书，但映射到您的客户端证书的用户 ID 已被拒绝访问该文件。 有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
248075 错误信息：HTTP 403.12 - Access Forbidden:Mapper Denied Access（HTTP 403.12 - 禁止访问：映射表拒绝访问）
• 404 - 未找到。 发生此错误的原因是您试图访问的文件已被移走或删除。如果在安装 URLScan 工具之后，试图访问带有有限扩展名的文件，也会发生此错误。这种情况下，该请求的日志文件项中将出现“Rejected by URLScan”的字样。
• 500 - 内部服务器错误。 很多服务器端的错误都可能导致该错误信息。事件查看器日志包含更详细的错误原因。此外，您可以禁用友好 HTTP 错误信息以便收到详细的错误说明。 有关如何禁用友好 HTTP 错误信息的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
294807 如何在服务器端禁用 Internet Explorer 5 的“显示友好 HTTP 错误信息”功能
• 500.12 - 应用程序正在重新启动。 这表示您在 IIS 重新启动应用程序的过程中试图加载 ASP 页。刷新页面后，此信息即会消失。如果刷新页面后，此信息再次出现，可能是防病毒软件正在扫描 Global.asa 文件。 有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
248013 错误信息：HTTP Error 500-12 Application Restarting（HTTP 错误 500-12 应用程序正在重新启动）
• 500-100.ASP - ASP 错误。 如果试图加载的 ASP 页中含有错误代码，将出现此错误信息。若要获得更确切的错误信息，请禁用友好 HTTP 错误信息。默认情况下，只会在默认 Web 站点上启用此错误信息。有关如何在非默认的 Web 站点上看到此错误信息的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
261200 显示 HTTP 500 错误信息，而不显示 500-100.asp 的 ASP 错误信息
• 502 - 网关错误。 如果试图运行的 CGI 脚本不返回有效的 HTTP 标头集，将出现此错误信息。
FTP
1xx - 肯定的初步答复
这些状态代码指示一项操作已经成功开始，但客户端希望在继续操作新命令前得到另一个答复。 • 110 重新启动标记答复。
• 120 服务已就绪，在 nnn 分钟后开始。
• 125 数据连接已打开，正在开始传输。
• 150 文件状态正常，准备打开数据连接。
2xx - 肯定的完成答复
一项操作已经成功完成。客户端可以执行新命令。 • 200 命令确定。
• 202 未执行命令，站点上的命令过多。
• 211 系统状态，或系统帮助答复。
• 212 目录状态。
• 213 文件状态。
• 214 帮助消息。
• 215 NAME 系统类型，其中，NAME 是 Assigned Numbers 文档中所列的正式系统名称。
• 220 服务就绪，可以执行新用户的请求。
• 221 服务关闭控制连接。如果适当，请注销。
• 225 数据连接打开，没有进行中的传输。
• 226 关闭数据连接。请求的文件操作已成功（例如，传输文件或放弃文件）。
• 227 进入被动模式 (h1,h2,h3,h4,p1,p2)。
• 230 用户已登录，继续进行。
• 250 请求的文件操作正确，已完成。
• 257 已创建“PATHNAME”。
3xx - 肯定的中间答复
该命令已成功，但服务器需要更多来自客户端的信息以完成对请求的处理。 • 331 用户名正确，需要密码。
• 332 需要登录帐户。
• 350 请求的文件操作正在等待进一步的信息。
4xx - 瞬态否定的完成答复
该命令不成功，但错误是暂时的。如果客户端重试命令，可能会执行成功。 • 421 服务不可用，正在关闭控制连接。如果服务确定它必须关闭，将向任何命令发送这一应答。
• 425 无法打开数据连接。
• 426 Connection closed; transfer aborted.
• 450 未执行请求的文件操作。文件不可用（例如，文件繁忙）。
• 451 请求的操作异常终止：正在处理本地错误。
• 452 未执行请求的操作。系统存储空间不够。
5xx - 永久性否定的完成答复
该命令不成功，错误是永久性的。如果客户端重试命令，将再次出现同样的错误。 • 500 语法错误，命令无法识别。这可能包括诸如命令行太长之类的错误。
• 501 在参数中有语法错误。
• 502 未执行命令。
• 503 错误的命令序列。
• 504 未执行该参数的命令。
• 530 未登录。
• 532 存储文件需要帐户。
• 550 未执行请求的操作。文件不可用（例如，未找到文件，没有访问权限）。
• 551 请求的操作异常终止：未知的页面类型。
• 552 请求的文件操作异常终止：超出存储分配（对于当前目录或数据集）。
• 553 未执行请求的操作。不允许的文件名。
常见的 FTP 状态代码及其原因
• 150 - FTP 使用两个端口：21 用于发送命令，20 用于发送数据。状态代码 150 表示服务器准备在端口 20 上打开新连接，发送一些数据。
• 226 - 命令在端口 20 上打开数据连接以执行操作，如传输文件。该操作成功完成，数据连接已关闭。
• 230 - 客户端发送正确的密码后，显示该状态代码。它表示用户已成功登录。
• 331 - 客户端发送用户名后，显示该状态代码。无论所提供的用户名是否为系统中的有效帐户，都将显示该状态代码。
• 426 - 命令打开数据连接以执行操作，但该操作已被取消，数据连接已关闭。
• 530 - 该状态代码表示用户无法登录，因为用户名和密码组合无效。如果使用某个用户帐户登录，可能键入错误的用户名或密码，也可能选择只允许匿名访问。如果使用匿名帐户登录，IIS 的配置可能拒绝匿名访问。
• 550 - 命令未被执行，因为指定的文件不可用。例如，要 GET 的文件并不存在，或试图将文件 PUT 到您没有写入权限的目录。 -
谈谈软件测试面试问题(转)
2007-05-26 12:33:01
前段时间公司招聘软件测试人员，虽然基本上都是招的应届毕业生，但我还是从现实以及网络上找到了一些应聘软件测试/QA的面试问题集，当然这个也都不会有标准答案的，现在只是以偶的一点理解加上网上的一些内容列举出来供有需要的XDJM们作一下参考：
1. 首先一般都是比较老套点的问题：介绍一下你的经历。
HOHO......这个问题我想谁都被问过吧，注意一下重点，不要紧张慢慢说就OK了。
快速软件测试网为各位软件测试爱好者提供的一个免费的测试交流平台！2. 老套话说了就可以马上切入正题了。根据你的经验说说你对软件测试/质量保证的理解？
这个就要仁者见仁、智者见智了，也基本上都是书上的东东，如果能有一些自己独特的想法那就最好啦，呵呵3. 理解完了那当然就要问一下是不是对软件测试了解啰。这就轮到问软件测试的流程是什么，你原先的公司又是怎么的流程了？
前面个问题也还是书本上的东西，一般介绍软测的书上都有，实际上国内一般的中小公司根本就达不到书上所说的那些个测试规范，测试流程也是如此，没办法，这就是现在我们整个大的测试环境，这个问题照着书上说的办就行了，后面那个知道该怎么做了吧，尽量把原来公司的测试流程言简意赅的表达出来。4. 接着问题就可以有一大堆了，这些问题很多都是要看自己的测试经验以及对测试的理解来作答了，如：
(1) 你对SQA的职责和工作活动(如软件度量)的理解：
SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程（如果有相应的CMM规程），对于不符合项及时提出建议和改进方案，必要是可以要高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。ＳＱＡ主要的工作活动包括制定SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等;(2) 说说你对软件配置管理的理解
项目在开发的过程中要用相应的配置管理工具对配置项（包括各个阶段的产物）进行变更控制，配置管理的使用取决于项目规模和复杂性能及风险的水平。软件的规模越大，配置管理就显得越重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并且只有经过授权后才能变更这个标准。配置管理工具主要有CC,VSS,CVS等，偶只用过CVS，对其它的不熟悉
(3) 怎样写测试计划和测试用例：
简单点，测试计划里应有详细的测试策略（测试方法等），合理详尽的资源安排等，至于测试用例，那是依赖于需求（包括功能与非功能需求）是否细化到功能点，是否可测试等。
(4) 说说主流的软件工程思想(如CMM，CMMI，RUP，XP，PSP，TSP等)的大致情况以及你对它们的理解：
CMM:SW Capability Maturity Model 软件能力成熟度模型,其作用是用于软件过程的改进、评估及软件能力的评鉴
CMMI:Capability Maturity Model Integration 能力成熟度模型集成 CMMI融入了大部分最新的软件管理实践，同时弥补了SW-CMM模型中的缺陷
RUP:rational unified process 是软件工程化过程。它提供了在开发机构中分派任务和责任的纪律化方法.它的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品,个人认为：它的核心观念是开发的迭代，每个公司可以根据自身的软件开发的流程和待开发项目的特点对RUP进行适当的剪裁，制定出符合自己的软件开发流程。
ＸＰ：extreme program，即极限编程的意思，适用于小型团队的软件开发，想上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性，强调测试（重点是单元测试）先行的理念。编程可以明显提高代码的质量，持续集成对于快速定位问题很有好处。
PSP ,TSP 分别是个体软件过程（Personal Software Process），群组软件过程（Team Software Process）大家都知道，CMM只是告诉你怎么做但并没有告诉你如何做，所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做，PSP强调建立个人技能（如何制定计划、控制质量及如何与其他人相互协作等等）而TSP着重于生产并交付高质量的软件产品（如何有效地规划和管理所面临的项目焖偃砑馐酝发任务等等）
总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。(5) 对项目管理、白盒测试、单元测试、自动测试、性能测试、压力测试工具的了解程度和实际使用经验。(其实基本上也就是MI和Rational工具)：这个就要看个人的了，没法说了
5. 还有问一下你是怎样保证软件质量的，也就是说你觉得怎样才能最大限度地保证软件质量？
测试并不能够最大限度的保证软件的质量，软件的高质量是开发和设计出来的，而不是测试出来的，它不仅要通过对软件开发流程的监控，使得软件开发的各个阶段都要按照指定的规程进行，通过对各个阶段产物的评审，QA对流程的监控，对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方式，是软件质量保证工程的一个重要组成部分。6. 然后紧接着就基于目前中国的国情，大多数公司的软件项目进度紧张、人员较少、需求文档根本没有或者很不规范，你认为在这种情况下怎样保证软件的质量？(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量，因为这些公司一般就是这种情况-----既不想投入过多又想保证质量，faint )出现以上的情况，如果仅仅想通过测试来提高软件质量，那几乎是不可能，原因是没有足够的时间让你去测试，少而不规范的文档导致测试需求无法细化何谈足够且有针对性进行测试。所以，作为公司质量保证的你应该先后项目经理确定符合项目本身最适合的软件生命周期模型（比如RUP的剪裁，原型法）,明确项目的开发流程并督促项目组按照此流程开展工作，所有项目组成员（项目经理更加重要）都要制定出合理的工作计划，加强代码的单元测试，在客户既定的产品交付日期范围之内，进行产品的持续集成等等，如果时间允许可以再配合客户进行必要的系统功能测试。
7. 差不多了就该问一些只和软件测试相关的问题了，如：
(1) 你觉得怎样才能做一个(或者，怎样才能算一个)优秀的测试工程师？(faint，这个问题好像是必问的，答案也无非是什么要求全面的技术能力、缜密的逻辑思维、出色的沟通能力、还要有怀疑精神、幽默感、洞察力等等。啥叫优秀啊？该有的能力都有，不该有的也有，而且个个能力还都是出色的，这就是优秀，呵呵，开玩笑的，反正这个问题差不多就这样，具体的什么要求网络上也到处都有。
(2) 还有其它的如对自己优缺点的评价、自己的职业理想、为何离开上一家公司、自己在职业生涯中印象最深的事情、能否出差和加班、能否承受压力和挑战、薪水要求、何时能到岗等等这些啥面试都要回答的问题，这个就只能自己斟琢着办了。
(3) 另外还有一个重要的问题就是语言能力啦，尤其是英语水平，这个的话每个具体的公司都有不同的要求，也就没啥好说的了。 -
软件工程师角色定位
2007-05-11 09:07:12
角色不明，责任不清，行为就失去了参照目标，结果就可能很不理想了。轻则降低了工作质量和效率，重则被视为工作能力低下，可能要退出软将项目组的舞台了。
51Testing软件测试网-q;@ jltCr#G
软件测试工程师承担的任务角色决定工作内容和承担的任务。测试工程师的角色应该承担什么任务呢？这没有统一的答案。因为，这与软件公司的规模，软件项目管理制度，公司领导和项目经理的管理风格，以及具体软件项目自身的特点有很大关系。而且，测试工程师也有普通和高级之分。
笼统的答案列举如下：
设置软件测试环境，安装必要的软件工具。
cX:`.z-@[!PM38208运行软件，发现和报告软件缺陷或错误。尤其需要快速定位软件中的严重的错误。 51Testing软件测试网9O4T;g0v,_ V
对软件整体质量提出评估
VId"? }38208确认软件达到某种具体标准 51Testing软件测试网(EVP _6[2L*F ul^
以最低的成本，最短的时间，完成高质量的测试任务 51Testing软件测试网*]cUh~;[M
...... 51Testing软件测试网,|5TP"~ bg
在这其中，最重要的是要明确，程序员的责任和目标。在执行任何具体测试任务前，都要在项目组内对于责任和目标达成共识，以免带来后续工作的相互推诿。
8X1f B$I yF~ Z$k38208提高测试质量的要诀另外一个值得注意的方面就是工作效率和质量，或许高级测试工程师与普通测试工程师的主要区别在于高级测试工程师可以更快地发现更多软件中的严重错误。对此，有什么可以借鉴的诀窍吗？请尝试以下方法，保证不会是您失望。
首先测试程序的核心功能，然后测试辅助功能。
$Mj0P5i6uW)w38208首先测试功能，然后测试性能。
UH5n&p-J!~t38208首先测试常见情况，然后测试异常情况。
BYa h&ly38208首先测试经过变更的部分，然后测试没有变更的部分。
"D3u0C q+}czK3`38208首先测试影响大的问题，然后测试影响小的问题。 51Testing软件测试网o W L(Y8S/Y
首先测试必须测试的部分，然后测试可选或没有要求测试的部分51Testing软件测试网| u y8Lt&X
软件测试工程师避免犯的几个错误前文已经指出测试工程师应该明确角色，明确任务和责任。知道哪些是自己份内的事，哪些是不属于自己的事。一定要尽最大努力完成份内的事，不要做不属于自己的事情，以免弄巧成拙。
为了更好的扮演软件测试工程师的角色，尽量避免犯下面的错误：
承诺完成测试的软件没有质量问题 51Testing软件测试网rzwa P-x]
软件测试只是保证质量的一种方法，软件测试工程师的工作不会直接提高软件质量，因为绝大多数软件错误都需要程序员修复。软件测试只能证明软件存在错误，不能保证软件没有错误，不可能找出全部软件错误。个人的能力和对质量的影响范围很小，软件质量的提高要靠软件项目团队全体成员的共同努力。承担软件的发布权利
u2Z H M K7Ch38208 不要因为软件中存在还没有修复的错误，而试图提出更改软件发布的计划。也不要认为已经完成了测试计划，自己决定可以发布软件。因为，改变软件发布计划可能要失去进入市场的良机和很多客户，对此造成的经济和公司市场的损失将不是测试工程师能够承担的。另外，软件发布后，如果用户发现了新的软件错误，公司领导或项目经理可能将过错加在软件测试人员的头上，因为他们同意发布软件。通常软件发布的权利由产品经理、项目经理、测试经理、市场经理共同集体讨论决定。扮演过程改进成员的角色 51Testing软件测试网.an R;ALpJ"_
软件测试工程师必须报告错误，有时也要分析错误的类型、特征和产生错误的原因。但是，不要主动提出改进软件过程的具体改进措施，更不要直接干涉程序员的工作方式，以免出力不讨好，影响今后的愉快合作。软件过程改进的方法是软件质量控制部门的事情，这是他们的本职工作。 -
ERP功能测试最佳实践：10个步骤确保ERP系统的可靠性
2007-05-08 09:07:38
介绍
企业资源规划（ERP）软件应用为企业提供管理大规模关键业务功能的能力，包括产品规划、部件采购、库存维护、和供应商的互动交流、提供客户服务，以及订单跟踪等。有些ERP解决方案还可能包括一些财政和人力资源方面的应用模块。尽管这些应用通常不会直接生成效益，但是它们能让企业以一种有效的、切合实际的方式使用现有的客户数据，帮助合理化企业的业务活动，为企业新的和当前的客户提供高质量的服务。
ERP应用通常使用一个单一的、中央数据存储器来服务于所有的模块。因此，当这些应用产生了性能问题时，很有可能影响到使用同一存储器的所有业务领域。ERP和共享数据结构间的这种关系决定了它必须实施稳固的测试和监测程序才能确保企业关键应用的健康运行。
目录
介绍
步骤1：初始规划和收集需求
步骤2：定义测试目标和选择合适的测试
步骤3：定义目的，以满足测试目标
步骤4：发现功能测试案例
步骤5：文档记录关键的业务流程
步骤6：开发模块化的测试组件
步骤7：建立测试实验室
步骤8：掌握和利用“冒烟测试”
步骤9：执行回归测试
步骤10：分析缺陷和创建测试报告
Mercury QuickTest Professional
ERP应用的功能测试
更多信息
由于业务流程交易跨越企业中的多个部门和区域，并且涉及ERP应用本身的多个模块，因此测试ERP应用应该采用一种整体的方式。当验证这些业务流程的功能时，关键在于捕获自动化测试解决方案中的业务流程测试，用于实现快速的测试重复。由于ERP应用跨越多个业务领域，存在不可避免的复杂性，因此，对每个ERP应用以及每个应用发布版本展开功能测试是非常重要的。
每个ERP实施中都会面临的主要挑战之一就是确保应用在上线之前能满足所有的业务需求。关键在于测试和验证这些应用的运作情况是否符合设计要求。在数千个客户实施基础上，美科利已经编纂了一套最佳实践，来确保关键业务应用的功能。在下文中将详细描述10个关键步骤，使用这些步骤能为企业的关键ERP应用来设计和实施有效的功能测试程序。
步骤1：初始规划和收集需求
在任何一个环境中，功能测试的最重要阶段之一就是规划。对于ERP应用来说，这个步骤就更为重要了，因为其中涉及环境的复杂性以及推动这些应用实施的错综复杂的业务需求。不完善的规划可能导致失望的结果和不完整的测试覆盖面。经过深思熟虑的规划使您能避免一种“垃圾进，垃圾出（garbage in, garbage out）”的局面，使企业能衡量和最大化他们的测试工作，获取更多的投资回报（ROI）。
许多公司购买预先打包的ERP解决方案，希望能实现业务管理各个领域的快速整合。然而，这种被称之为“vanilla”的ERP打包方案必须经过客户定制，才能部署到它所要支持的业务中去。从逻辑上来说，收集需求是规划阶段的起点，因为开发人员通常根据需求来定制ERP应用；测试人员使用它来测试系统和客户定制项目；而最终用户使用它进行用户接受测试和终结测试。通过提前仔细地定义需求，测试人员可以规划和管理那些更加注重业务需要的测试。接着，需求可以同测试和实际测试结果（被识别的缺陷）相结合，以全面覆盖所有的功能测试。
步骤2：定义测试目的和选择合适的测试
测试人员通过创建主要的测试目的，将决定所需的特定测试类型。 测试目的、项目计划和团队结构也将从这些测试目标中形成。当功能测试一个ERP实施时，有多种不同的验证测试需要执行：
l 数据映射：由于许多ERP实施和后端大机系统紧密地集成在一起，因此测试ERP应用所显示的数据和在大机系统中被发现的数据之间的数据映射是十分关键的。很可能在大机系统中隐藏着一些陈旧的或无效的数据，这些数据会引起应用当中的问题。
l 业务流程测试：应该使用测试来验证各种业务流程是否正确运作。由于工作流对强化业务规则来说是非常重要的，因此测试应该覆盖整个整合系统中的所有导航项目和直接功能。应用的业务规则和启动项必须通过全面地测试，确保所有规则能被正确地执行。
l 权限控制系统：ERP权限控制系统决定了用户可以使用哪些信息，用户在这些信息中可以看到哪些数据。当涉及到供应链和合作伙伴入口时，将会增加安全方面的考虑。从用户界面的角度出发测试安全性可以确保严格执行验证规则。数据驱动的测试使IT人员能使用具有不同登录凭证的相同脚本去验证安全规则。
l 回归测试：每次部署一个“Code Drop”时，对位于这些程序的每个对象的功能进行回归测试是非常重要的。这其中包括测试它的存在、功能、值等等。“code drop”指的是任何一次新的ERP应用、补丁程序和/或hot fix的发布。
步骤3：定义目标，以满足测试目的
当完成所有的目的定义，选择好测试类型，接下去就要创建一系列的阶段目标来实现所定义的目的。一套最普通的初始阶段目标包括：
l 分析应用功能，并识别关键业务流程。在一个ERP应用中的关键业务流程实例就是“服务请求”的创建。
l 建立“冒烟测试”，在开发周期中快速执行该类测试。冒烟测试不应深入被测试应用的功能，而是应该测试关键的业务功能。例如，用户是否能够创建可以和“Trouble Ticket”相应的活动。
l 在每次正式发布形成后运行冒烟测试。
l 着手创建自动化测试来降低手动运行冒烟测试的成本。
实现了这些初始阶段目标之后，应该建立一套后续阶段目标。
l 分析应用，展开功能识别，这将扩大测试范围，涵盖超过75％的总的应用功能数量。（取得100％的脚本自动化测试是非常困难的，因为自动化测试工具无法进行如可用性测试这样的事宜。）
l 建立可持续运作的自动化测试，从而降低测试的工作量。
步骤4：区分功能测试案例
在区分测试案例时，关键要记住，重要的业务功能必须在应用中才能发挥作用。由于每个企业具有独特的业务需求，大多数企业即使完成了基本的或标准的实施，也无法上线。因为那些客户定制的区域必须经过彻底地测试才能保证上线时功能的稳定。ERP应用的主要优势之一就是能和现有的大机系统集成，来满足必要的业务需求。再者，因为这些集成不是标准（非客户定制）实施，它们必须经过严格地测试。
最初，要避免用各种不同的方法去测试相同的功能。开发团队经常会强调一个应用应具有完美架构，可以灵活地让用户通过不同的方式来完成他们的日常任务。关键在于要经常部署测试案例，确保需求驱动、user-path的覆盖面。初期测试应该具有一些共有的特性：
l 它们应该测试关键的业务功能。
l 它们应该测试应用的关键业务流程。
l 它们应该识别出经客户定制过的ERP应用的测试区域。
l 应用功能应该稳定，不在主要开发范围之内。
l 初期测试应该是冒烟测试的候选方式。
一旦初期自动化测试创建完成，并成功地运行后，测试目标通常会改变，测试包会扩张。这种扩张通常表现为在功能成熟之后，增加更多的测试到测试包中。还可以在应用问题区域，如和大机系统的界面中增加测试，从而对该区域展开持续地检查。
步骤5：文档记录关键的业务流程
当记录那些将要成为测试脚本的业务流程时，收集所有和测试案例相关的信息是非常重要的。每个测试案例需要具备一份和被测业务区域相关的目的说明。测试案例的目的应该是和满足一个需求或一系列需求有关。关键之处还在于，要文档记录下逻辑步骤，在整个系统中执行这些步骤可以实现测试的需求。由于使用测试案例可以衡量业务流程的成功与否，因此，文档中应该指出，需要验证哪些内容才能保证测试的成功。
除了为测试案例而展开的执行和验证操作外，还需要在测试案例中成功地执行适用的数据值。这种数据可以是来自数据库的主数据（master data）、或是能够凭空增加的用户创建输入数据、或者在脚本创建之前被置入数据库的准备数据。
步骤6：开发模块化的测试组件
创建模块化测试脚本是非常重要的。测试的模块化能够使开发人员创建单元测试（unit test），在整个系统完成之前，测试ERP应用模块和模块的定制项目。接着，被用于单元测试的模块测试会移交给QA测试人员，他们会将模块测试和测试包结合在一起，来满足特定的测试目标。美科利提供一款最新的功能测试解决方案（即“业务流程测试”），它能帮助企业管理与业务组件和端到端流程验证有关的所有测试案例。
步骤7：建立测试实验室
建议建立一个QA测试实验室，作为ERP应用的测试和调优整体战略的一个组成部分。在一个独立的测试实验室中运行测试的主要优势在于，机器配置可以达到一种理想的状态，因而减少了由于机器配置不完善而引起的各类问题。此外，当模块定制完成之后，开发人员和测试人员可以在新代码发布之前，使用该实验室来运行单元测试。
步骤8：掌握和利用“冒烟测试”
在大多数ERP应用中，不完善的发布浪费了大量的测试工作。通常，当开发团队完成一个发布版本后将移交给测试团队，接着展开为期数天的测试过程。而测试结果往往是软件的发布版本存在重大的和根本的问题，不值得再进行深入地测试。不幸地是，当开发人员着手为该发布版本增加新的功能时，测试团队已经浪费了几天的时间去发现其薄弱之处。
改变这种情况的捷径就是建立一种“冒烟测试”，它可以覆盖关键的业务功能。冒烟测试结合了手动测试和自动化测试，可以在短时间内被创建和运行（通常在1个小时之内）。运行冒烟测试可以为开发团队提供发布版本质量方面的快速信息反馈，帮助他们集中力量解决严重阻滞的问题，而不是一些新的特性。冒烟测试所利用的脚本可以从开发人员已经创建的单元测试中获取。
步骤9：执行回归测试
回归测试包应该覆盖关键的业务流程，应该在每个新的ERP应用版本发布时运行。回归测试不同于冒烟测试注重测试核心的业务功能，它能更加深入地测试应用的功能。正如前文所提到的，由供应商和任何定制所带来的应用更新都可能对应用功能和性能产生负面影响，必须在每次发布版本之后进行测试。
步骤10：分析缺陷和创建测试报告
ERP应用准备就绪的重要指标之一就是被识别的系统缺陷数量。在执行测试时，测试中产生的失误必须被跟踪和分析。一种稳固的功能测试解决方案应该能跟踪和汇报所有存在于业务流程中的缺陷。测试团队可以利用这类信息来衡量和管理缺陷是如何被优先级划分、修复、重复测试和关闭的。
用全面的报告来完整记录所有的测试流程和结果，这也是非常重要的一项工作，可以使测试团队能正确分析测试结果，同时在未来测试中重复使用测试案例和脚本。
美科利QuickTest Professional
Mercury QuickTest Professional™提供功能和回归测试自动化方面的业界最佳解决方案――可覆盖每个主要的软件应用和环境，包括来自Oracle、PeopleSoft、SAP和Sieble的ERP应用。这种新款的自动化测试解决方案采用一种关键词驱动测试的理念，能够完全简化测试的创建和维护。有了美科利QuickTest Professional的关键词驱动方式，测试自动化专家就能通过一种和关键词视图（Keyword View）相互同步的、集成的脚本和纠错环境，进入到基层测试和目标领域中去。
美科利QuickTest Professional同时满足了技术和非技术用户的需要。它使高质量应用部署的过程变得更为快捷和经济，同时风险也更小。它和Mercury Business Process Testing™（美科利业务流程测试）协同工作，使非技术型的对象专家（subject matter expert）也能参与到质量流程中。
美科利业务流程测试使对象专家无需任何编程知识，就能创建、数据驱动和执行测试自动化。它降低了自动化测试维护的经常性费用，将测试自动化和文档记录两个流程合并为一。它使对象专家和业务分析人员可以根据业务流程测试框架中所定义的业务概念来衡量应用实施的质量。
ERP应用的功能测试
通过使用美科利QuickTest Professional和美科利业务流程测试，QA团队可以开发和利用统一的、可重复的测试流程，更快、更经济和更便捷地对ERP应用就绪情况提前作出决策。当初期功能测试计划完成之后，测试团队可以使用美科利解决方案来自动验证ERP应用中所有业务交易的完整性。美科利解决方案从业务流程的角度出发，展开ERP应用测试。这些解决方案通过执行分步操作――如更新库存信息，或从供应商处定购某部分商品，就像在实际生产操作中一样来测试ERP应用。
当在测试创建阶段捕获了业务流程后，美科利QuickTest Professional和美科利业务流程测试将ERP业务相关信息与输入数据相互分离。测试人员可以根据选择列表，改变选择项和数据条目。使用同一数据对应用展开反复测试通常不会取得实际结果。要真实地验证应用的功能，测试人员需要不同的数据包来模拟多个用户的实际操作行为。美科利产品允许用户直接输入测试数据，或从一个数据库中导入数据，从而创建一个实际的、数据驱动的测试方案。通过这种方式，测试人员就能使用可变的输入数据，分析实际的ERP业务流程。
打包的ERP应用通常具有很高的复杂性。创建一个简单的记录定制可能会对其它记录或整体性能产生无法预料的影响。当更新发布（甚至是简单的定制更新），都需要对所有业务流程展开全面彻底地测试，而不仅仅是测试变更所发生的区域。这样，测试人员就能衡量更新会对应用产生的影响，确保不会引起缺陷的产生。
更多信息
美科利解决方案使机构能采用稳固的功能测试程序来展开他们所有的ERP解决方案。解决方案让整个测试团队能够以最少的培训，创建成熟的测试系列；确保在整个环境、数据包和业务流程中应用功能的正确运作；并为开发人员提供全面记录和复制缺陷的能力――帮助团队尽快修复缺陷，跟上苛刻的生产进度。
想获取更多有关美科利QuickTest Professional、美科利业务流程测试，或其它美科利服务和解决方案的信息，请联系当地的美科利销售代表或访问www.mercury.com。
-
正确使用内存（转载）
2007-05-08 09:01:07
对于初学者来说，内存是个神秘的空间。程序的绝大部分错误，也是在于内存的使用不当造成的，而且这些错误有些都是隐藏很深的。所以，如何掌握内存的使用，通晓系统对内存的管理手段，将是软件成功的一个非常关键的因素。
首先我们要了解内存的分配方式。一般来说，内存的分配方式有三种：1．从静态存储区域分配。内存在程序编译的时候就已经分配好，这块内存在程序的整个运行期间都存在。例如全局变量，static变量。2．在栈上创建。在执行函数时，函数内局部变量的存储单元都可以在栈上创建，函数执行结束时这些存储单元自动被释放。栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限。3．从堆上分配，亦称动态内存分配。程序在运行的时候用malloc或new申请任意多少的内存，程序员自己负责在何时用free或delete释放内存。动态内存的生存期由我们决定，使用非常灵活，但问题也最多。以上三种分配方式，我们要注意内存生命期的问题：1．静态分配的区域的生命期是整个软件运行期，就是说从软件运行开始到软件终止退出。只有软件终止运行后，这块内存才会被系统回收2．在栈中分配的空间的生命期与这个变量所在的函数和类相关。如果是函数中定义的局部变量，那么它的生命期就是函数被调用时，如果函数运行结束，那么这块内存就会被回收。如果是类中的成员变量，则它的生命期与类实例的生命期相同3．在堆上分配的内存，生命期是从调用new或者malloc开始，到调用delete或者free结束。如果不掉用delete或者free。则这块空间必须到软件运行结束后才能被系统回收。下面我们再看看，在使用内存的过程中，我们经常发生一些什么样的错误。以及我们应该采取哪些对策。发生内存错误是件非常麻烦的事情。编译器不能自动发现这些错误，通常是在程序运行时才能捕捉到。而这些错误大多没有明显的症状，时隐时现，增加了改错的难度。有时用户怒气冲冲地把你找来，程序却没有发生任何问题，你一走，错误又发作了。常见的内存错误及其对策如下：1 内存分配未成功，却使用了它。编程新手常犯这种错误，因为他们没有意识到内存分配会不成功。常用解决办法是，在使用内存之前检查指针是否为NULL。如果指针p是函数的参数，那么在函数的入口处用assert(p!=NULL)进行检查。如果是用malloc或new来申请内存，应该用if(p==NULL) 或if(p!=NULL)进行防错处理。2 内存分配虽然成功，但是尚未初始化就引用它。犯这种错误主要有两个起因：一是没有初始化的观念；二是误以为内存的缺省初值全为零，导致引用初值错误（例如数组）。内存的缺省初值究竟是什么并没有统一的标准，尽管有些时候为零值，我们宁可信其无不可信其有。所以无论用何种方式创建数组，都别忘了赋初值，即便是赋零值也不可省略，不要嫌麻烦。3 内存分配成功并且已经初始化，但操作越过了内存的边界。例如在使用数组时经常发生下标“多1”或者“少1”的操作。特别是在for循环语句中，循环次数很容易搞错，导致数组操作越界。4 忘记了释放内存，造成内存泄露。含有这种错误的函数每被调用一次就丢失一块内存。刚开始时系统的内存充足，你看不到错误。终有一次程序突然死掉，系统出现提示：内存耗尽。动态内存的申请与释放必须配对，程序中malloc与free的使用次数一定要相同，否则肯定有错误（new/delete同理）。5 释放了内存却继续使用它。有三种情况：（1）程序中的对象调用关系过于复杂，实在难以搞清楚某个对象究竟是否已经释放了内存，此时应该重新设计数据结构，从根本上解决对象管理的混乱局面。（2）函数的return语句写错了，注意不要返回指向“栈内存”的“指针”或者“引用”，因为该内存在函数体结束时被自动销毁。（3）使用free或delete释放了内存后，没有将指针设置为NULL。导致产生“野指针”。综上所述，我们应该注意：1．用malloc或new申请内存之后，应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存。2．不要忘记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用。3．避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”操作。4．动态内存的申请与释放必须配对，防止内存泄漏。5．用free或delete释放了内存之后，立即将指针设置为NULL，防止产生“野指针”。下面举几个经典的错误例子，大家不要犯同样的错误：1． 返回栈内存指针char *GetString(void){char a[]="hello world";char *p =a;return p;}char* pGet = GetString();这段程序编译时没有错误，运行也没有错误，但是你却无法使得返回的pGet指针指向的数据是你想要的“hello world”,因为指针p的生命期是函数GetString内，运行完函数GetString后，p分配的栈空间马上被系统回收了。虽然pGet指向了p当初分配的内存地址，但是那块地址已经没有内容了。2．这是一个出现频率非常高的错误char* pChar = new char;……int a ;pChar = &a;……delete pChar;当然这是一个例子，具体的程序各有不同。这段程序有两个问题。一是pChar = &a；将导致pChar原先分配的空间无法再被获取，就象我们的丢失了朋友的电话号码一样，无法再联系这个朋友了。这就造成了内存泄漏。如果内存泄漏多了，可能导致系统的崩溃，因为可用的资源将越来越少，直到枯竭为止。第二个问题是delete pChar将导致异常发生，因为这时的pChar已经不是指向动态分配的内存了，而是指向了a分配的栈空间，而栈空间是不能使用delete来回收的，因此将导致内存异常。 -
智力题及答案
2007-04-30 09:50:30
1. 有两根不均匀分布的香，香烧完的时间是一个小时，你能用什么方法来确定一段15分钟的时间？
2. 一个经理有三个女儿，三个女儿的年龄加起来等于13，三个女儿的年龄乘起来等于经理自己的年龄，有一个下属已知道经理的年龄，但仍不能确定经理三个女儿的年龄，这时经理说只有一个女儿的头发是黑的，然后这个下属就知道了经理三个女儿的年龄。请问三个女儿的年龄分别是多少？为什么？
3. 有三个人去住旅馆，住三间房，每一间房$10元，于是他们一共付给老板$30，
第二天，老板觉得三间房只需要$25元就够了于是叫小弟退回$5给三位客人，
谁知小弟贪心,只退回每人$1，自己偷偷拿了$2，这样一来便等于那三位客人每人各花了九元，
于是三个人一共花了$27，再加上小弟独吞了不$2，总共是$29。可是当初他们三个人一共付出$30那么还有$1呢？4. 有两位盲人，他们都各自买了两对黑袜和两对白袜，八对袜了的布质、大小完全相同，
而每对袜了都有一张商标纸连着。两位盲人不小心将八对袜了混在一起。他们每人怎样才能取回黑袜和白袜各两对呢？5. 有一辆火车以每小时15公里的速度离开洛杉矶直奔纽约，另一辆火车以每小时20公里的速度从纽约开往洛杉矶。如果有一只鸟，以
6. 你有两个罐子，50个红色弹球，50个蓝色弹球，随机选出一个罐子，随机选取出一个弹球放入罐子，怎么给红色弹球最大的选中机会？在你的计划中，得到红球的准确几率是多少？
7. 你有四个装药丸的罐子，每个药丸都有一定的重量，被污染的药丸是没被污染的重量＋1.只称量一次，如何判断哪个罐子的药被污染了？
8. 你有一桶果冻，其中有％％，绿色，红色三种，闭上眼睛，抓取两个同种颜色的果冻。抓取多少个就可以确定你肯定有两个同一颜色的果冻？
9. 对一批编号为1～100，全部开关朝上(开)的灯进行以下*作：凡是1的倍数反方向拨一次开关；2的倍数反方向又拨一次开关；3的倍数反方向又拨一次开关……问：最后为关熄状态的灯的编号。
10. 想象你在镜子前，请问，为什么镜子中的影像可以颠倒左右，却不能颠倒上下？
11. 一群人开舞会，每人头上都戴着一顶帽子。帽子只有黑白两种，黑的至少有一顶。每个人都能看到其它人帽子的颜色，却看不到自己的。主持人先让大家看看别人头上戴的是什幺帽子，然后关灯，如果有人认为自己戴的是黑帽子，就打自己一个耳光。第一次关灯，没有声音。于是再开灯，大家再看一遍，关灯时仍然鸦雀无声。一直到第三次关灯，才有劈劈啪啪打耳光的声音响起。问有多少人戴着黑帽子？
12. 两个圆环，半径分别是1和2，小圆在大圆内部绕大圆圆周一周，问小圆自身转了几周？如果在大圆的外部，小圆自身转几周呢？
13. 1元钱一瓶汽水，喝完后两个空瓶换一瓶汽水，问：你有20元钱，最多可以喝到几瓶汽水？
参考答案
1. 一只两头点燃，另一只一头点燃，当第一只烧完后，第二只丙再头点燃，就可以得到15`
2. 2,2,9，因为只有36 = 6*6*1 36 = 9 * 2 * 2
3. 怎么会是每人第天九元呢,每人每天 (25/3) + 1，那一元差在25 - 24 = 1
4. 每人取每双中的一只就可以了
5. (D / 35 ) * 30 = D
6. 自己睁着眼睛挑一个红色的啊，这样是给红色最大的机会了，除了你是色盲，呵呵 ,当然他们的几率都是1/2。
7. 一个中取一个编号，然后称一下就知道
8. 4个
9. 当该数的方根为整数时超下，其它的超上。这样 1、4、9、16、25、36、49、64、81、100号超下
10. 因为照镜子时，镜子是与你垂直平行的，但在水平方向刚好转了180度。
11. 应该是三个人：
1，若是两个人，设A、B是黑帽子,第二次关灯就会有人打耳光。原因是A看到B第一次没打耳光，就知道B也一定看到了有带黑帽子的人，可A除了知道B带黑帽子外，其他人都是白帽子，就可推出他自己是带黑帽子的人！同理B也是这么想的，这样第二次熄灯会有两个耳光的声音。
2，如果是三个人，A,B,C. A第一次没打耳光，因为他看到B,C都是带黑帽子的；而且假设自己带的是白帽子，这样只有BC戴的是黑帽子；按照只有两个人带黑帽子的推论，第二次应该有人打耳光；可第二次却没有。。。于是他知道B和C一定看到了除BC之外的其他人带了黑帽子，于是他知道BC看到的那个人一定是他，所以第三次有三个人打了自己一个耳光！
3，若是第三次也没有人打耳光，而是第四次有人打了耳光，那么应该有几个人带了黑猫子呢？大家给个结果看看^_^12. 可以把圆看成一根绳子，大绳是小绳的2倍长，所以应该是2圈吧。
13. 一开始20瓶没有问题，随后的10瓶和5瓶也都没有问题，接着把5瓶分成4瓶和1瓶，前4个空瓶再换2瓶，喝完后2瓶再换1瓶，此时喝完后手头上剩余的空瓶数为2个，把这2个瓶换1瓶继续喝，喝完后把这1个空瓶换1瓶汽水，喝完换来的那瓶再把瓶子还给人家即可，所以最多可以喝的汽水数为：20＋10＋5＋2＋1＋1＋1＝40
-
性能测试工具LoadRunner的面试问题(E文)
2007-04-30 09:39:18
LoadRunner interview questions
1. What is load testing? - Load testing is to test that if the application works fine with the loads that result from large number of simultaneous users, transactions and to determine weather it can handle peak usage periods.
2. What is Performance testing? - Timing for both read and update transactions should be gathered to determine whether system functions are being performed in an acceptable timeframe. This should be done standalone and then in a multi user environment to determine the effect of multiple transactions on the timing of a single transaction.
3. Did u use LoadRunner? What version? - Yes. Version 7.2.
4. Explain the Load testing process? -
Step 1: Planning the test. Here, we develop a clearly defined test plan to ensure the test scenarios we develop will accomplish load-testing objectives. Step 2: Creating Vusers. Here, we create Vuser scrīpts that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions. Step 3: Creating the scenario. A scenario describes the events that occur during a testing session. It includes a list of machines, scrīpts, and Vusers that run during the scenario. We create scenarios using LoadRunner Controller. We can create manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers, the load generator machines, and percentage of Vusers to be assigned to each scrīpt. For web tests, we may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner automatically builds a scenario for us. Step 4: Running the scenario.
We emulate load on the server by instructing multiple Vusers to perform tasks simultaneously. Before the testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or individual Vusers. Step 5: Monitoring the scenario.
We monitor scenario execution using the LoadRunner online runtime, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors. Step 6: Analyzing test results. During scenario execution, LoadRunner records the performance of the application under different loads. We use LoadRunner’s graphs and reports to analyze the application’s performance.5. When do you do load and performance Testing? - We perform load testing once we are done with interface (GUI) testing. Modern system architectures are large and complex. Whereas single user testing primarily on functionality and user interface of a system component, application testing focuses on performance and reliability of an entire system. For example, a typical application-testing scenario might depict 1000 users logging in simultaneously to a system. This gives rise to issues such as what is the response time of the system, does it crash, will it go with different software applications and platforms, can it hold so many hundreds and thousands of users, etc. This is when we set do load and performance testing.
6. What are the components of LoadRunner? - The components of LoadRunner are The Virtual User Generator, Controller, and the Agent process, LoadRunner Analysis and Monitoring, LoadRunner Books Online.
7. What Component of LoadRunner would you use to record a scrīpt? - The Virtual User Generator (VuGen) component is used to record a scrīpt. It enables you to develop Vuser scrīpts for a variety of application types and communication protocols.
8. What Component of LoadRunner would you use to play Back the scrīpt in multi user mode? - The Controller component is used to playback the scrīpt in multi-user mode. This is done during a scenario run where a vuser scrīpt is executed by a number of vusers in a group.
9. What is a rendezvous point? - You insert rendezvous points into Vuser scrīpts to emulate heavy user load on the server. Rendezvous points instruct Vusers to wait during test execution for multiple Vusers to arrive at a certain point, in order that they may simultaneously perform a task. For example, to emulate peak load on the bank server, you can insert a rendezvous point instructing 100 Vusers to deposit cash into their accounts at the same time.
10. What is a scenario? - A scenario defines the events that occur during each testing session. For example, a scenario defines and controls the number of users to emulate, the actions to be performed, and the machines on which the virtual users run their emulations.
11. Explain the recording mode for web Vuser scrīpt? - We use VuGen to develop a Vuser scrīpt by recording a user performing typical business processes on a client application. VuGen creates the scrīpt by recording the activity between the client and the server. For example, in web based applications, VuGen monitors the client end of the database and traces all the requests sent to, and received from, the database server. We use VuGen to: Monitor the communication between the application and the server; Generate the required function calls; and Insert the generated function calls into a Vuser scrīpt.
12. Why do you create parameters? - Parameters are like scrīpt variables. They are used to vary input to the server and to emulate real users. Different sets of data are sent to the server each time the scrīpt is run. Better simulate the usage model for more accurate testing from the Controller; one scrīpt can emulate many different users on the system.
13. What is correlation? Explain the difference between automatic correlation and manual correlation? - Correlation is used to obtain data which are unique for each run of the scrīpt and which are generated by nested queries. Correlation provides the value to avoid errors arising out of duplicate values and also optimizing the code (to avoid nested queries). Automatic correlation is where we set some rules for correlation. It can be application server specific. Here values are replaced by data which are created by these rules. In manual correlation, the value we want to correlate is scanned and create correlation is used to correlate.
14. How do you find out where correlation is required? Give few examples from your projects? - Two ways: First we can scan for correlations, and see the list of values which can be correlated. From this we can pick a value to be correlated. Secondly, we can record two scrīpts and compare them. We can look up the difference file to see for the values which needed to be correlated. In my project, there was a unique id developed for each customer, it was nothing but Insurance Number, it was generated automatically and it was sequential and this value was unique. I had to correlate this value, in order to avoid errors while running my scrīpt. I did using scan for correlation.
15. Where do you set automatic correlation options? - Automatic correlation from web point of view can be set in recording options and correlation tab. Here we can enable correlation for the entire scrīpt and choose either issue online messages or offline actions, where we can define rules for that correlation. Automatic correlation for database can be done using show output window and scan for correlation and picking the correlate query tab and choose which query value we want to correlate. If we know the specific value to be correlated, we just do create correlation for the value and specify how the value to be created.
16. What is a function to capture dynamic values in the web Vuser scrīpt? - Web_reg_save_param function saves dynamic data information to a parameter.
17. When do you disable log in Virtual User Generator, When do you choose standard and extended logs? - Once we debug our scrīpt and verify that it is functional, we can enable logging for errors only. When we add a scrīpt to a scenario, logging is automatically disabled. Standard Log Option: When you select
Standard log, it creates a standard log of functions and messages sent during scrīpt execution to use for debugging. Disable this option for large load testing scenarios. When you copy a scrīpt to a scenario, logging is automatically disabled Extended Log Option: Select
extended log to create an extended log, including warnings and other messages. Disable this option for large load testing scenarios. When you copy a scrīpt to a scenario, logging is automatically disabled. We can specify which additional information should be added to the extended log using the Extended log options.18. How do you debug a LoadRunner scrīpt? - VuGen contains two options to help debug Vuser scrīpts-the Run Step by Step command and breakpoints. The Debug settings in the Options dialog box allow us to determine the extent of the trace to be performed during scenario execution. The debug information is written to the Output window. We can manually set the message class within your scrīpt using the lr_set_debug_message function. This is useful if we want to receive debug information about a small section of the scrīpt only.
19. How do you write user defined functions in LR? Give me few functions you wrote in your previous project? - Before we create the User Defined functions we need to create the external
library (DLL) with the function. We add this library to VuGen bin directory. Once the library is added then we assign user defined function as a parameter. The function should have the following format: __declspec (dllexport) char* <function name>(char*, char*)Examples of user defined functions are as follows:GetVersion, GetCurrentTime, GetPltform are some of the user defined functions used in my earlier project.20. What are the changes you can make in run-time settings? - The Run Time Settings that we make are: a) Pacing - It has iteration count. b) Log - Under this we have Disable Logging Standard Log and c) Extended Think Time - In think time we have two options like Ignore think time and Replay think time. d) General - Under general tab we can set the vusers as process or as multithreading and whether each step as a transaction.
21. Where do you set Iteration for Vuser testing? - We set Iterations in the Run Time Settings of the VuGen. The navigation for this is Run time settings, Pacing tab, set number of iterations.
22. How do you perform functional testing under load? - Functionality under load can be tested by running several Vusers concurrently. By increasing the amount of Vusers, we can determine how much load the server can sustain.
23. What is Ramp up? How do you set this? - This option is used to gradually increase the amount of Vusers/load on the server. An initial value is set and a value to wait between intervals can be
specified. To set Ramp Up, go to ‘Scenario Scheduling Options’24. What is the advantage of running the Vuser as thread? - VuGen provides the facility to use multithreading. This enables more Vusers to be run per
generator. If the Vuser is run as a process, the same driver program is loaded into memory for each Vuser, thus taking up a large amount of memory. This limits the number of Vusers that can be run on a single
generator. If the Vuser is run as a thread, only one instance of the driver program is loaded into memory for the given number of
Vusers (say 100). Each thread shares the memory of the parent driver program, thus enabling more Vusers to be run per generator.25. If you want to stop the execution of your scrīpt on error, how do you do that? - The lr_abort function aborts the execution of a Vuser scrīpt. It instructs the Vuser to stop executing the Actions section, execute the vuser_end section and end the execution. This function is useful when you need to manually abort a scrīpt execution as a result of a specific error condition. When you end a scrīpt using this function, the Vuser is assigned the status "Stopped". For this to take effect, we have to first uncheck the “Continue on error” option in Run-Time Settings.
26. What is the relation between Response Time and Throughput? - The Throughput graph shows the amount of data in bytes that the Vusers received from the server in a second. When we compare this with the transaction response time, we will notice that as throughput decreased, the response time also decreased. Similarly, the peak throughput and highest response time would occur approximately at the same time.
27. Explain the Configuration of your systems? - The configuration of our systems refers to that of the client machines on which we run the Vusers. The configuration of any client machine includes its hardware settings, memory, operating system, software applications, development tools, etc. This system component configuration should match with the overall system configuration that would include the network infrastructure, the web server, the database server, and any other components that go with this larger system so as to achieve the load testing objectives.
28. How do you identify the performance bottlenecks? - Performance Bottlenecks can be detected by using monitors. These monitors might be application server monitors, web server monitors, database server monitors and network monitors. They help in finding out the troubled area in our scenario which causes increased response time. The measurements made are usually performance response time, throughput, hits/sec, network delay graphs, etc.
29. If web server, database and Network are all fine where could be the problem? - The problem could be in the system itself or in the application server or in the code written for the application.
30. How did you find web server related issues? - Using Web resource monitors we can find the performance of web servers. Using these monitors we can analyze throughput on the web server, number of hits per second that
occurred during scenario, the number of http responses per second, the number of downloaded pages per second.31. How did you find database related issues? - By running “Database” monitor and help of “Data Resource Graph” we can find database related issues. E.g. You can specify the resource you want to measure on before running the controller and than you can see database related issues
32. Explain all the web recording options?
33. What is the difference between Overlay graph and Correlate graph? - Overlay Graph: It overlay the content of two graphs that shares a common x-axis. Left Y-axis on the merged graph show’s the current graph’s value & Right Y-axis show the value of Y-axis of the graph that was merged. Correlate Graph: Plot the Y-axis of two graphs against each other. The active graph’s Y-axis becomes X-axis of merged graph. Y-axis of the graph that was merged becomes merged graph’s Y-axis.
34. How did you plan the Load? What are the Criteria? - Load test is planned to decide the number of users, what kind of machines we are going to use and from where they are run. It is based on 2 important documents, Task Distribution Diagram and Transaction profile. Task Distribution Diagram gives us the information on number of users for a particular transaction and the time of the load. The peak usage and off-usage are decided from this Diagram. Transaction profile gives us the information about the transactions name and their priority levels with regard to the scenario we are deciding.
35. What does vuser_init action contain? - Vuser_init action contains procedures to login to a server.
36. What does vuser_end action contain? - Vuser_end section contains log off procedures.
37. What is think time? How do you change the threshold? - Think time is the time that a real user waits between actions. Example: When a user receives data from a server, the user may wait several seconds to review the data before responding. This delay is known as the think time. Changing the Threshold: Threshold level is the level below which the recorded think time will be ignored. The default value is five (5) seconds. We can change the think time threshold in the Recording options of the Vugen.
38. What is the difference between standard log and extended log? - The standard log sends a subset of functions and messages sent during scrīpt execution to a log. The subset depends on the Vuser type Extended log sends a detailed scrīpt execution messages to the output log. This is mainly used during debugging when we want information about: Parameter substitution. Data returned by the server. Advanced trace.
39. Explain the following functions: - lr_debug_message - The lr_debug_message function sends a debug message to the output log when the specified message class is set. lr_output_message - The lr_output_message function sends notifications to the Controller Output window and the Vuser log file. lr_error_message - The lr_error_message function sends an error message to the LoadRunner Output window. lrd_stmt - The lrd_stmt function associates a character string (usually a SQL statement) with a cursor. This function sets a SQL statement to be processed. lrd_fetch - The lrd_fetch function fetches the next row from the result set.
40. Throughput - If the throughput scales upward as time progresses and the number of Vusers increase, this indicates that the bandwidth is sufficient. If the graph were to remain relatively flat as the number of Vusers increased, it would
be reasonable to conclude that the bandwidth is constraining the volume of
data delivered.41. Types of Goals in Goal-Oriented Scenario - Load Runner provides you with five different types of goals in a goal oriented scenario:
o The number of concurrent Vusers
o The number of hits per second
o The number of transactions per second
o The number of pages per minute
o The transaction response time that you want your scenario
42. Analysis Scenario (Bottlenecks): In Running Vuser graph correlated with the response time graph you can see that as the number of Vusers increases, the average response time of the check itinerary transaction very gradually increases. In other words, the average response time steadily increases as the load
increases. At 56 Vusers, there is a sudden, sharp increase in the average response
time. We say that the test broke the server. That is the mean time before failure (MTBF). The response time clearly began to degrade when there were more than 56 Vusers running simultaneously.43. What is correlation? Explain the difference between automatic correlation and manual correlation? - Correlation is used to obtain data which are unique for each run of the scrīpt and which are generated by nested queries. Correlation provides the value to avoid errors arising out of duplicate values and also optimizing the code (to avoid nested queries). Automatic correlation is where we set some rules for correlation. It can be application server specific. Here values are replaced by data which are created by these rules. In manual correlation, the value we want to correlate is scanned and create correlation is used to correlate.
44. Where do you set automatic correlation options? - Automatic correlation from web point of view, can be set in recording options and correlation tab. Here we can enable correlation for the entire scrīpt and choose either issue online messages or offline actions, where we can define rules for that correlation. Automatic correlation for database, can be done using show output window and scan for correlation and picking the correlate query tab and choose which query value we want to correlate. If we know the specific value to be correlated, we just do create correlation for the value and specify how the value to be created.
45. What is a function to capture dynamic values in the web vuser scrīpt? - Web_reg_save_param function saves dynamic data information to a parameter.
-
Loadrunner中参数设置详细分析
2007-04-30 09:35:32
Loadrunner中参数设置详细分析
相信对大家会有用的，这个版本是基于7.8的。
做负载或者压力测试时，很多人选择使用了Loadrunner测试工具。该工具的基本流程是先将用户的实际操作录制成脚本，然后产生数千个虚拟用户运行脚本（虚拟用户可以分布在局域网中不同的PC机上），最后生成相关的报告以及分析图。但是在录制脚本的过程中会遇到很多实际的问题，比如不同的用户有不同的使用数据，这就牵涉到参数的设置问题。本文就Loadrunner中参数的设置进行说明，希望对大家有所帮助。
在录制程序运行的过程中，VuGen（脚本生成器） 自动生成了包含录制过程中实际用到的数值的脚本。如果你企图在录制的脚本中使用不同的数值执行脚本的活动（如查询、提交等等），那么你必须用参数值取代录制的数值。这个过程称为参数化脚本。
本文主要包括如下内容：理解参数的局限性、建立参数、定义参数的属性、理解参数的类型、为局部数据类型设置参数的属性、为数据文件设置参数的属性、从已经存在的数据库中引入数据。
除了GUI，以下的内容适合于各种类型的用户脚本。
一、关于参数的定义
在你录制程序运行的过程中，脚本生成器自动生成由函数组成的用户脚本。函数中参数的值就是在录制过程中输入的实际值。
例如，你录制了一个Web应用程序的脚本。脚本生成器生成了一个声明，该声明搜索名称为“UNIX”的图书的数据库。当你用多个虚拟用户和迭代回放脚本时，也许你不想重复使用相同的值“UNIX”。那么，你就可以用参数来取代这个常量。结果就是你可以用指定的数据源的数值来取代参数值。数据源可以是一个文件，也可以是内部产生的变量。
用参数表示用户的脚本有两个优点：
① 可以使脚本的长度变短。
② 可以使用不同的数值来测试你的脚本。例如，如果你企图搜索不同名称的图书，你仅仅需要写提交函数一次。在回放的过程中，你可以使用不同的参数值，而不只搜索一个特定名称的值。
参数化包含以下两项任务：
① 在脚本中用参数取代常量值。
② 设置参数的属性以及数据源。
参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。另外，不是所有的函数都可以参数化的。二、参数的创建
可以指定名称和类型来创建参数。不存在对脚本中参数个数的限制。在Web程序的用户脚本中，你可以使用如下过程在基于文本的脚本视图中创建参数。或者，也可以在基于图标的树形视图中创建参数。
在基于文本的脚本视图中创建一个参数：
1、 将光标定位在要参数化的字符上，点击右键。打开弹出菜单。
2、 在弹出菜单中，选择“Replace with a Parameter”。选择或者创建参数的对话框弹出。
3、 在“Parameter name”中输入参数的名称，或者选择一个在参数列表中已经存在的参数。
4、 在“Parameter type”下拉列表中选择参数类型。
5、 点击“OK”，关闭该对话框。脚本生成器便会用参数中的值来取代脚本中被参数化的字符，参数用一对“{}”括住。
注意：在参数化CORBA或者General-Java 用户脚本的时候，必须参数化整个字符串，而不是其中的部分。另外注意：除了Web或者WAP，缺省的参数括号对于任何脚本都是 “{}”。你可以在“General Options”对话框中的“Parameterization”标签（Tools>General Options）中定义参数括号种类。
6、 用同样的参数替换字符的其余情况，选中参数，点击右键，弹出菜单。从弹出的菜单中，选择“Replace More Occurrences”。搜索和替换对话框弹出。“Find What”中显示了你企图替换的值。“Replace With”中显示了括号中参数的名称。选择适当的检验框来匹配整个字符或者大小写。如果要搜索规则的表达式（.，!，?等等），选中“Regular Expression”检验框，然后点击“Replace”或者“Replace All”。
注意：小心使用“Replace All”，尤其替换数字字符串的时候。脚本生成器将会替换字符出现的所有情况。
7、 如果想用以前定义过的参数来替换常量字符串的话，选中该字符串，点击右键，然后选择“Use Existing Parameter”，子菜单“Use Existing Parameters”弹出。从子菜单“Use Existing Parameters”选择参数，或者用“Select from Parameter List”来打开参数列表对话框。
注意：如果用以前定义过的参数来替换常量字符串的话，那么，使用“Parameter List”非常方便。同时，还可以查看和修改该参数的属性。
8、 对于已经用参数替换过的地方，如果想取回原来的值，那么，就在参数上点击右键，然后选择“Restore Original value”。
在Web用户脚本的树形视图中创建参数：
1、将光标定位在企图参数化的地方，点击右键，从弹出的菜单中选择“Properties”。则相关的属性对话框打开。
2、点击在要参数化的参量的旁边的“ABC”形状的图标。“Select or Create Parameter”对话框打开。
3、在“Parameter name”中输入参数的名称，或者从列表中选择一个已经存在的参数。
4、在“Parameter type”中输入参数的类型。
5、点击“OK”关闭该对话框。用户脚本生成器会用参数来替换最初的字符串常量，并用一个表格形状的图标替换“ABC”形状的图标。
6、要恢复参数化以前的值，点击图标，然后从弹出的菜单中选择“Undo Parameter”，则以前的值便会重现。三、定义参数的属性
创建参数完成后，就可以定义其属性了。参数的属性定义就是定义在脚本执行过程中，参数使用的数据源。在Web用户脚本中，你既可以在基于文本的脚本视图中定义参数属性，也可以在基于图标的树形视图中定义参数属性。下面的过程将教你如何在基于本文的脚本视图中定义参数属性。
在基于文本的脚本视图中定义参数属性步骤：
1、 在参数上点击右键，有菜单弹出。
2、 在弹出的菜单中，选择“Parameter Properties”。参数属性对话框打开，显示和当前参数类型相关的属性。
3、 输入参数的属性值。
4、 点击“Close”关闭参数属性对话框。
在Web用户脚本的树形视图中定义参数的属性：
1、 将关标定位在参数上，然后点击右键，选择“Properties”。属性对话框打开。
2、 点击要定义属性的参数旁边的表格形状按钮，点击右键，选择“Parameter Properties”。参数属性对话框打开，和参数类型相关的属性显示出来。
3、 输入参数的属性。
4、 点击“Close”关闭参数属性对话框。
使用参数列表：
使用参数列表可以在任意时刻查看所有的参数，创建新的参数、删除参数，或者修改已经存在参数的属性。
1、 点击参数列表按钮或者用“Vuser>Parameter List”。参数列表对话框打开。
2、 要创建新的参数，点击“New”按钮。新的参数则被添加在参数树中，该参数有一个临时的名字，你可以给它重新命名，然后回车。设置参数的类型和属性，点击“OK”，关闭参数列表对话框。
注意：不要将一个参数命名为“unique”，因为这个名称是用户脚本生成器本身的。用户脚本生成器创建新的参数，但是不会自动用该参数在脚本中替换任意选中的字符串。
3、 要删除已有的参数，那么，要先从参数树中选择该参数，点击“Delete”，然后确认你的行为即可。
4、 要修改已有参数，那么，要先从参数树中选择该参数，然后编辑参数的类型和属性。四、理解参数的类型
在你定义参数属性的时候，要指定参数值的数据源。你可以指定下列数据源类型的任何一种：
Internal Data―― 虚拟用户内部产生的数据。
Data Files ――存在于文件中的数据。可能是已存在的文件或者是用脚本生成器新创建的。
User-Defined Functions―― 调用外部DLL函数生成的数据
Internal Data包括以下几种：
1、 Date/Time
Date/Time用当前的日期/时间替换参数。要指定一个Date/Time格式，你可以从菜单列表中选择格式，或者指定你自己的格式。这个格式应该和你脚本中录制的Date/Time格式保持一致。
2、 Group Name
Group Name 用虚拟用户组名称替换参数。在创建scenario的时候，你可以指定虚拟用户组的名称。当从用户脚本生成器运行脚本的时候，虚拟用户组名称总是None。
3、 Load Generator Name
Load Generator Name用脚本负载生成器的名称替换参数。负载生成器是虚拟用户在运行的计算机。
4. Iteration Number
Iteration Number用当前的迭代数目替换参数。
5、 Random Number
Random Number用一个随机数替换参数。通过指定最大值和最小值来设置随机数的范围。
6、 Unique Number
Unique Number用一个唯一的数字来替换参数。你可以指定一个起始数字和一个块的大小。
7、 Vuser ID
Vuser ID用分配给虚拟用户的ID替换参数，ID是由Loadrunner的控制器在scenario运行时生成的。如果你从脚本生成器运行脚本的话，虚拟用户的ID总是-1。五、数据文件
数据文件包含着脚本执行过程中虚拟用户访问的数据。局部和全局文件中都可以存储数据。可以指定现有的ASCII文件、用脚本生成器创建一个新的文件或者引入一个数据库。在参数有很多已知值的时候数据文件非常有用。数据文件中的数据是以表的形式存储的。一个文件中可以包含很多参数值。每一列包含一个参数的数据。列之间用分隔符隔开，比如说，用逗号。
对数据文件设置参数属性
如果使用文件作为参数的数据源，必须指定以下内容：文件的名称和位置、包含数据的列、文件格式，包括列的分隔符、更新方法。
如果参数的类型是“File”，打开参数属性（Parameter Properties）对话框，设置文件属性如下：
1、 在“File path”中输入文件的位置，或者点击“Browse”指定一个已有文件的位置。缺省情况下，所有新的数据文件名都是“parameter_name.dat”，注意，已有的数据文件的后缀必须是.dat。
2、 点击“Edit”。记事本打开，里面第一行是参数的名称，第二行是参数的初始值。使用诸如逗号之类的分隔符将列隔开。对于每一新的表行开始一行新的数据。
注意：在没有启动记事本的情况下如果想添加列，就在参数属性对话框中点击“Add Col”，那么“Add new column”对话框就会弹出。输入新列的名称，点击“OK”。脚本生成器就会添加该列到表中，并显示该列的初始值。
3、 在“Select Column”部分，指明包含当前参数数据的列。你可以指定列名或者列号。列号是包含你所需要数据的列的索引。列名显示在每列的第一行（row 0）。
4、 在“Column delimiter”中输入列分隔符，你可以指定逗号、空格符等等。
5、 在“First data line”中，在脚本执行的时候选择第一行数据使用。列标题是第0行。若从列标题后面的第一行开始的话，那就在“First data line”中输入1。如果没有列标题，就输入0。
6、 在“Select next row”中输入更新方法，以说明虚拟用户在脚本执行的过程中如何选择表中的数据。方法可以是：连续的、随机的、唯一的、或者与其它参数表的相同行。
6.1、 查看(712) 评论(0) 收藏 分享 管理转载之报表测试
2007-04-30 09:09:19
本文适合有过MIS系统报表测试经验，或者有关进销存系统测试经验的朋友参考。
报表功能的基本要求，就是通过查询/统计/分析，提供用户所需的准确的数据。如果无法实现这个基本功能，则报表完全失去意义。
对于用户来说，报表可以直接影响到他们的决策，例如可能因为报表对销售和库存情况反映的不准确，导致错误的大量进货；或者因为报表对应收应付金额计算的不准确，而导致企业对资金占用情况做出错误的估计，
从而导致错误的决策，最终造成用户在经营上的损失。诸如此类，相信只要大家留心，还可以找出很多这样的例子。
进销存系统中的报表多如牛毛，而且各种不同行业的进销存系统中的业务有区别，报表也有些区别，因此不太可能对各种报表逐个讲解，而主要是把一些报表测试的经验总结成了十几条可以在各种行业的报表测试中应用的“最佳实践”，来跟大家一起分享。希望下面的这十几条像一招招简单实用的“擒拿手”，可以供正在进行报表测试或者准备开始作报表测试的朋友随手拈来，见招拆招，轻松应对这项工作。
<!--[if !supportLists]-->（1） 提高对业务的熟悉程度<!--[endif]-->
其实对任何一个软件进行测试，都必须要熟悉它的业务，包括业务流程和业务规则。但是报表同一般的业务功能还是有些区别的。例如对于单据的增、删、改，通过对界面的浏览和探索性的操作，大概都可以弄明白它的业务流程和业务规则，因为这些内容比较直观，而且在不同的行业中也差不了太多。但是在报表中，是很难直观的看到我们所需要了解的内容的。例如报表中的某个数据项，它的算法或者说数据来源，恐怕是比较难看出来的——即使是很类似的一个数据项，在不同行业的实际业务中，它的算法和数据来源也可以能完全不同的。
所以对于报表业务的熟悉，主要是两个方面：数据项的算法和数据来源，也就是说要明白一个数据项同具体的业务有什么关系，单据的增、删、改或者状态的变化，对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些，那么就无法验证报表中的数据是否准确，也无法通过报表去检查业务系统的正确与否。
<!--[if !supportLists]-->（2） 覆盖所有可能的查询统计方式，而不是以自己的使用习惯为准<!--[endif]-->
对于报表的使用者来说——一般是企业的中层或高层领导，他们对于报表的要求可能会是多方面的，例如在进销存系统中，可能需要按不同商品进行分类统计，也可能是按供应商分类统计，这些都是由用户在实际工作中的需要来决定的，所以假如一个报表提供了多种查询统计的方法，那么在测试时，只要时间充分，就应该覆盖这些所有可能被用到的查询统计方法，而不是以自己的使用习惯为测试的依据。
<!--[if !supportLists]-->（3） 使用或构造受控的数据环境<!--[endif]-->
数据对于报表测试来说是一个非常非常重要的问题。因为上面说到，报表的基本功能就是通过各种查询统计分析的方法，为用户提供准确的数据，帮助用户做出决策。那么那些用来进行测试的数据从哪里来呢？
首先，应该保证准备足够多的有效的数据。前面一条也提到了，在实际测试报表时，应当尽可能的覆盖到报表所提供的各种查询统计方法，因此至少应该保证每一种查询统计方法都应该有对应的数据，得到的结果都不会是0，否则等于没有覆盖到这个被测的查询统计算法。当然数据也不是越多越好，能保证全部覆盖，并且刚好够用就可以了，因为数据的准备和生成也是很花时间的。
其次，要保证数据的可控。数据并不是随意生成的，如果使用通过自动化工具或者通过业务测试时随意的输入的数据来进行报表测试，一般来说是不太可能的。因为如果无法控制数据来源，那么即使知道报表中每个数据项的算法，也无法最终验证报表的查询统计结果是否正确。例如，系统的会有不同类型的单据，每种单据又会有不同的状态，某个报表的统计中，可能会涉及到多种类型和状态的单据，那么在准备数据时，就要充分考虑到这一点，准备各种不同的单据来满足测试的要求。又比如，如果整个系统中只有一个供应商，一个商品，那么测试按供应商分类统计或者按商品分类统计的报表时，意义也就不大了。
所以如果希望高有效、更高质量的完成报表的测试，那么就要重视并增加对于数据准备工作的关注：用于验证报表功能的数据，一定是专门为报表准备的，并且是经过精心设计，要分析影响数据项算法的各种因素，以及每个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法；同时，才能保证无论使用哪个数据项的算法进行计算，其结果都是可以预知的——因为数据来源已经被我们控制了。
特别是对于算法比较复杂，又提供了多种查询统计方式的报表，如果想完整的测试，就需要准备大量的数据。而如果想高效、高质量的完成这项功能，就一定要理解数据准备工作的重要性。
经过精心设计的数据还有一个好处，就是当在进行业务功能的测试时，不再需要使用一些随意的数据，而是可以通过业务测试的过程，把报表测试所需要的数据输入到系统中。并根据报表对单据类型和状态的需要，进行相应的操作。
如果留心，你也会发现报表测试同其他业务功能测试的有个区别。业务功能（例如单据的新增、审核等）的测试用例设计，通常需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖；而对于报表功能，虽然没有太复杂的业务流程和规则，但是算法更加复杂，同时报表功能本身就是一种对数据的加工处理，因此会更偏重于对于各种数据来源和算法的遍历或覆盖，也就是要准备各种正常的、异常的数据，来验证报表是否取到的该取的数据、没有取不该取的数据，并且最后计算出了正确的结果。
<!--[if !supportLists]-->（4） 特征性数据的准备<!--[endif]-->
这又是一个同数据准备有关的问题，也是一个解决实际问题的经验。如果由多人同时对一个系统进行测试，虽然大家各自使用的数据都是经过精心设计的，但是在实际进行报表测试时，还是很难保证其他人的数据不会对自己的测试结果产生影响，最明显的一个问题就是原来自己对结果是可以预知的——因为数据是经过精心设计的，是可控的，但是现在掺杂了别人的数据，就需要花时间去区分这种“假”的错误和真的错误。
有一个经验是可以借鉴的，就是在初期，团队内对数据的准备达成一直，使数据中的某一项具有特征性，例如分别使用不同的供应商，或者使用不同的商品。最后测试报表时，通过限定选取的数据来源，来保证相互之间尽可能的没有影响。
<!--[if !supportLists]-->（5） 做好数据环境的备份和维护<!--[endif]-->
虽然数据是经过精心准备的，但是难免在操作过程中因为误操作导致环境的变化，例如不小心把一张单据变成了另外一种状态，或者某个类型的单据多做了一张。对于这种情况，一个简单的方法就是去维护你的数据文档——一般我们都可以用EXCEL表来保存我们事先准备的数据，可以一个文件保存一个类型的单据，例如采购单、入库单、出库单等等，文件中的每张表用来保存不同状态的单据，例如已经审核过的入库单，没有审核过的入库单，全部入库的入库单和部分入库的入库单，等等。假如你一不小心，把一张本来准备入一半的入库单全入了，那也不要惊慌，去重新调整一下你的数据文档，在相应的类型相应的状态的单据列表中新增一张就行了。
而如果想减少回归测试的工作量，那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础单据已经输入完成，但是还都没有开始审核或者出入库，那么可以备份一下，下次再测的时候可以直接在数据库中恢复这部分原始数据。
<!--[if !supportLists]-->（6） 在业务功能测试通过之后才开始<!--[endif]-->
这一点相信应该不难理解，如果业务功能本身存在缺陷，导致的数据不准，那么最后进行报表测试也就没有什么意义了。所以，应该在保证各项同报表有关的业务的功能测试通过之后，才开始考虑对报表进行测试。
<!--[if !supportLists]-->（7） 寻求开发人员的协助<!--[endif]-->
在报表测试中很常见的一个问题，是需求文档中可能没有定义报表的各个数据项的算法，这时候你需要找开发人员帮忙，向他们了解准确的算法和相应的公式。
<!--[if !supportLists]-->（8） 多个报表相互对照<!--[endif]-->
这是一项“高级”的报表测试技能，需要对整个系统中的各种业务的熟悉程度达到一种炉火纯青的地步。除了可以准确的说出各个业务的处理过程对每张报表的影响之外，还能够进行横向的联系，知道不同报表之间存在的关系。例如，一个简单的例子，库存报表中，你可以看到商品的出入库情况，而在销售报表中，你可以看到商品的销售金额和销售成本金额，在应收应付报表中，你又可以看到不同供应商或客商之间的应收应付金额。那么这几张报表之间，是否存在一些关联呢？是否会存在一些可以相互验证的地方呢？这个问题，留给大家来思考 ^_^
<!--[if !supportLists]-->（9） 着重对那些算法复杂、与业务功能关联较多的报表的测试<!--[endif]-->
如果只是简单的把某个日期范围内的所有入库情况统计出来，可能不会出错；但是如果还要考虑按照供应商或商品汇总，同时要选取特定的类型或状态的单据，再进行一些响应的计算，恐怕就很难保证开发人员永远不会出错了。这就像业务功能的测试一样，越是复杂的业务，越有可能出错。
<!--[if !supportLists]-->（10） 留意四舍五入对报表数据的影响<!--[endif]-->
从这一条开始，后面的内容可以说也是一些在实际测试时要注意的事项。
这也是一个常见的问题。在一般的进销存系统中，都会存在这种情况，无论小数点后保留几位，总是难以避免明细和汇总之间的差别。原因可能是因为采购和销售的包装不一致，因为拆零引起的，例如10/30*30≠10；或者由于毛利率、税率等因素导致的不一致。我们曾经试过在保留4位小数的情况下还是无法避免这种情况。
<!--[if !supportLists]-->（11） 留意进/存/销时使用不同单位对报表数据的影响<!--[endif]-->
例如采购时是5箱，每箱有100盒，而销售单位是盒，入库之后，可能会要求按照销售单位来统计，这时要注意开发人员是否会选择了错误的单位，把500盒弄成5盒。
<!--[if !supportLists]-->（12） 留意业务单据中存在多个日期字段时对报表数据的影响<!--[endif]-->
一般来说，一张单据上都会有多个日期字段，比如采购单就有采购日期、单据日期、审核日期，而入库单也会有单据日期、入库日期，诸如此类。那么在测试时，一定要留意，开发人员是否按照要求选择了正确的日期，包括日期选取的一致性——是否存在这边取采购日期，那边取审核日期的情况。
<!--[if !supportLists]-->（13） 留意是否存在遗漏的单据类型<!--[endif]-->
例如像出入库的报表，入库方向的，除了最主要的采购入库外，可能还会包括退货入库、盘盈入库、报溢入库；出库方向的，除了最常见的销售出库，还会包括盘亏出库、报损出库。那么在具体测试时，一定要准备充分这些相应类型的单据，并且要留意开发人员是否遗漏了相应的单据类型。
<!--[if !supportLists]-->（14） 留意不同状态的单据对报表数据的影响<!--[endif]-->
例如采购单，当采购单发出后，供应商会开始送货，可能第一批之送来了一半的商品，那么这时采购单的收货状态是“未完成” ；当供应商把商品送齐了以后，采购数量＝收货数量，则采购单的收货状态变为“已完成”。那这时留意，开发人员在采购报表中，是包含所需要的状态的单据，还是只包含了一部分？
<!--[if !supportLists]-->（15） 留意那些被当做默认规则的因素<!--[endif]-->
有些规则——例如单据类型或者单据状态——是作为默认规则写死在SQL语句或者数据库的存储过程里面，这些规则不会体现在界面，也不会由用户选择决定。但是这些规则恰恰是最容易被忽略的部分。所以，一定要同开发人员反复确认，保证自己已经了解了同报表各数据项计算有关的各个因素。
<!--[if !supportLists]-->（16） 保证测试人员可以通过UI 找到自己所需的所有原始数据<!--[endif]-->
在进行系统测试时，无论是报表，还是一般的业务功能测试，都不要去直接通过SQL语句查询数据库中的内容，而是通过UI来输入，再通过UI体现处理的结果进行验证——因为这是系统测试，不是集成测试，将来用户是决不会去直接查数据库的。因此，如果需要对报表的结果进行验证，应该通过其他的功能模块，去查询业务单据，或者其他报表，根据UI体现的结果，来进行确认。
<!--[if !supportLists]-->（17） 检查大数据量对报表的影响<!--[endif]-->
报表测试也会涉及到性能测试，主要是在大数据量查询统计的测试。大数据量一是说原始数据多，二是被操作、计算的数据多，三是某个数据项被是经过多次计算得出的。特别是对于一些算法比较复杂的报表，10万条数据和100万条数据时的响应时间将表现出巨大的差别。
<!--[if !supportLists]-->（18） 不要遗漏权限控制和访问安全性的测试<!--[endif]-->
这里说的权限控制不是谁可以访问某个模块，谁不可以访问某个模块，而且数据的计算也没有直接的关系，而是侧重于报表设计的测试。我们都知道不同的报表是设计给不同的人看的，例如出入库报表是给仓库管理人员看的，里面不会包含商品的价格，而只会包含数量；而财务报表中，只会包含采购、销售的金额，而不会包含数量，这样才能保证可以相互对照，不会出现营私舞弊的行为。那么在测试时，应当考虑报表是否泄漏了不该泄漏的信息。当然，这里对业务的熟悉程度就是更高的要求了。
又如，不同的业务员只能看到同自己有关的业务，但是领导可以看到所有业务员的业务——例如不同的业务员分管不同的客户或者地域，他们之间的销售情况是互相保密的。
还有一种情况，系统的用户可能会为他的供应商提供一个专门的程序或者Web页面，供其对其供应的商品的销售、库存情况进行查看。那么对于这种情况，一方面是要保证某个供应商只能看到他所供应的商品的销售、库存情况，如果某个商品由多个供应商同时提供，那么其中一个供应商应该只能看到他提供的那部分，而看不到其他供应商提供的同一商品的情况。当然，这种功能一般都是通过外网（internet）来访问的，所以也还要考虑相应的访问安全性测试，以免泄漏重要的商业信息。
偶然性不可重现BUG怎么处理（转自CSDN.net ）
2007-04-30 08:52:41
偶然性不可重现BUG怎么处理
转自CSDN.net一、一定要提交！！
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。
二、程序不是测试人员写的，出问题也不是测试人员的原因。至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现！！
三、下次再遇到的时候，拉他们来看就可以了。因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。
而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )
四、你可以告诉程序员，测试过程是没有错误的。测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
客户那里发现问题比测试员发现问题结果要严重的多。
五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。
至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现（仅仅出现一次）。
这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有bug，是否可以说程序员工作不到位的呀）。
六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。
其实只要自己尽到心就可以了，管别人怎么说呢。
七、我们使用的状态有：程序员处理的状态（由测试员提交的Action）：等待处理的，再次出现的。
测试员处理的状态（由程序员提交的Action）：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。
经理处理的状态（由测试员提交Action）：管理员处理的。经理还可以删除记录。
按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。
最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”（由测试员或经理确认）和“暂不修改的”（比如下一个版本处理等）。
呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。
八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：
关于“无法重现”我看是有这么个问题存在。首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。
不清楚你是否是测试人员。“计划外”这个词，对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例（说白了，只要一个长手识字的人，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了）。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。
说说我现在测试的一个项目，有一个业务，首先查询出人员，有个“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”，至今为止一切都正常，但是这个时候再次点选人员进行业务处理，仍然会提示“没有选择人员”，这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到吧，因为发生的条件很苛刻：不用“全选”按钮的时候不会发生；全选后点击“取消全选”按钮再办理业务不会发生；全选全消后，先点击人员再办理业务也不会发生。
其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。
呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。
最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.
测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议！！测试人员的任务是发现问题，解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路；而且测试人员做的多了，程序员不但不感激，可能反而会反感（好像程序员对测试人员有好印象的不多）。再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现（但是我不可能遇到问题就拉程序员来看吧），后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox（必填）再进行Edit的录入，但一次操作我没有选择 ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现（不够成熟呀），我就放弃了，也没有提交记录（为了避免麻烦）。
测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间验证“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就当不知道。
下面是其它一些人的观点：
doublefalse(散诸怀抱)：如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试！！！我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了。
liuxiaoyuzhou(蟀哥)：遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!在我们这里不能从现的BUG,是测试人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀!
ericzhangali(另一个空间)：首先一定要提交bug；其次不要企图RD一定去解这个bug；某些时候还得关闭这个bug。如果RD认为是测试错误，（不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，）那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。
darkcat_c(错了重来)：没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test case步骤做的话不太可能出现此类bug。作为测试人员一定要具备良好的记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。（编者按：这种话，不愿意去辩驳，标准开发人员的看法，也许应该让他们也来做做测试）
liyan_1014(雁子)：我觉得应该是这么处理：
1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚；这样对于再次重现也有一定的参考性。
2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。
3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受C#命名规则和开发习惯
2007-04-28 13:18:39
一、命名
1.用pascal规则来命名方法和类型.
public class TextBox
{
public void DataBind()
{
}
}
2.用camel规则来命名局部变量和方法的参数.
string userName;
public AddUser(string userId, byte[] password);
3.所有的成员变量前加前缀 m_
public class Database
{
public string m_connectionString;
}
4.接口的名称加前缀 I.
interface ICompare
{
int compare();
}
5.自定义的属性以Attribute结尾
public class AuthorAttribute : Attribute
{
}
6.自定义的异常以Exception结尾
public class AppException : Exception
{
}
7.方法的命名.一般将其命名为动宾短语.
ShowDialog()
CreateFile()
GetPath()
8.代码的缩进.要用Tab，而不要用space.
9.局部变量的名称要有意义.不要用x，y，z等等.
string userName
10.所有的成员变量声明在类的顶端，用一个换行把它和方法分开.
11.用有意义的名字命名namespace，如：产品名、公司名.
12.建议局部变量在最接近使用它时再声明.
13.使用某个控件的值时，尽量命名局部变量.
14.把引用的系统的namespace和自定义或第三方的分开.
15.文件名要能反应类的内容，最好是和类同名，一个文件中一个类.
16.目录结构中要反应出namespace的层次.
17.大括号"{"要新起一行.
public class AuthorAttribute : Attribute
{
}
二、编码习惯.
1.用C#预定义的类名，而不要用别名.
string userName; 而不是 System.String userName;
int number; 而不是 System.Int32;
2.一行不要超过80个字符.
3.尽量不要手工更改机器生成的代码，若必须更改，一定要改成和机器生成的代码风格一样.
4.关键的语句(包括声明关键的变量)必须要写注释.
5.文字常量和数字常量不要硬编码，应该用常量类或枚举代替.
6.不要用goto系列语句.
7.不要声明public和protected的成员变量，应用property.
8.不要声明public的event，应用事件访问器.
public class Source
{
private EventHandler m_NumberChangeEvent;
public event EventHandler NumberChangeEvent
{
add
{
m_NumberChangeEvent += value;
}
remove
{
m_NumberChangeEvent -= value;
}
}
}
9.类型转换的使用规则.
Animal animal = new Dog();
Dog dog = animal as Dog;
if (dog != null)
{
}
10.生成和构建一个长的字符串时，一定要使用StringBuilder，而不用string.</P< p>
11.始终使用"{ }"包含if下的语句，即使只有一条语句.
12.switch语句一定要有default来处理意外情况.
13.尽量不要使用三目运算符 ? : ，而要使用if语句.
14.尽量不用使用this引用，除非是要调用类中的另一个Constructor.
public class Person
{
public Person(string name)
{
}
public Person() : this("Jim")
{
}
}
.net控件命名规则
1 、命名方法
控件名简写+英文描述，英文描述首字母大写
2、主要控件名简写对照表
控件名 简写 控件名 简写Label lbl TextBox txt
Button btn LinkButton lnkbtn
ImageButton imgbtn DropDownList ddl
ListBox lst DataGrid &a
Oracle SQL 性能优化技巧
2007-04-28 13:06:46
选用适合的ORACLE优化器
ORACLE的优化器共有3种
A、RULE (基于规则) b、COST (基于成本) c、CHOOSE (选择性)
设置缺省的优化器，可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明，如RULE，COST，CHOOSE，ALL_ROWS，FIRST_ROWS 。 你当然也在SQL句级或是会话(session)级对其进行覆盖。
为了使用基于成本的优化器(CBO， Cost-Based Optimizer) ， 你必须经常运行analyze 命令，以增加数据库中的对象统计信息(object statistics)的准确性。
如果数据库的优化器模式设置为选择性(CHOOSE)，那么实际的优化器模式将和是否运行过analyze命令有关。 如果table已经被analyze过， 优化器模式将自动成为CBO ， 反之，数据库将采用RULE形式的优化器。
在缺省情况下，ORACLE采用CHOOSE优化器， 为了避免那些不必要的全表扫描(full table scan) ， 你必须尽量避免使用CHOOSE优化器，而直接采用基于规则或者基于成本的优化器。
2.访问Table的方式
ORACLE 采用两种访问表中记录的方式：
A、 全表扫描
全表扫描就是顺序地访问表中每条记录。ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描。
B、 通过ROWID访问表
你可以采用基于ROWID的访问方式情况，提高访问表的效率， ROWID包含了表中记录的物理位置信息。ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系。通常索引提供了快速访问ROWID的方法，因此那些基于索引列的查询就可以得到性能上的提高。
3.共享SQL语句
为了不重复解析相同的SQL语句，在第一次解析之后，ORACLE将SQL语句存放在内存中。这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享。 因此，当你执行一个SQL语句(有时被称为一个游标)时，如果它和之前的执行过的语句完全相同， ORACLE就能很快获得已经被解析的语句以及最好的执行路径。ORACLE的这个功能大大地提高了SQL的执行性能并节省了内存的使用。
可惜的是ORACLE只对简单的表提供高速缓冲(cache buffering)，这个功能并不适用于多表连接查询。
数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就可以保留更多的语句，当然被共享的可能性也就越大了。
当你向ORACLE提交一个SQL语句，ORACLE会首先在这块内存中查找相同的语句。这里需要注明的是，ORACLE对两者采取的是一种严格匹配，要达成共享，SQL语句必须完全相同(包括空格，换行等)。
数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就可以保留更多的语句，当然被共享的可能性也就越大了。
共享的语句必须满足三个条件：
A、 字符级的比较： 当前被执行的语句和共享池中的语句必须完全相同。
B、 两个语句所指的对象必须完全相同：
C、 两个SQL语句中必须使用相同的名字的绑定变量(bind variables)。
4.选择最有效率的表名顺序(只在基于规则的优化器中有效)
ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表(基础表 driving table)将被最先处理。在FROM子句中包含多个表的情况下，你必须选择记录条数最少的表作为基础表。当ORACLE处理多个表时， 会运用排序及合并的方式连接它们。首先，扫描第一个表(FROM子句中最后的那个表)并对记录进行派序，然后扫描第二个表(FROM子句中最后第二个表)，最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并。
如果有3个以上的表连接查询， 那就需要选择交叉表(intersection table)作为基础表， 交叉表是指那个被其他表所引用的表。
5.WHERE子句中的连接顺序
ORACLE采用自下而上的顺序解析WHERE子句，根据这个原理，表之间的连接必须写在其他WHERE条件之前， 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。
6.SELECT子句中避免使用 ' * '
当你想在SELECT子句中列出所有的COLUMN时，使用动态SQL列引用 '*' 是一个方便的方法。不幸的是，这是一个非常低效的方法。实际上，ORACLE在解析的过程中， 会将'*' 依次转换成所有的列名， 这个工作是通过查询数据字典完成的， 这意味着将耗费更多的时间。
7.减少访问数据库的次数
当执行每条SQL语句时，ORACLE在内部执行了许多工作：解析SQL语句，估算索引的利用率，绑定变量，读数据块等等。由此可见，减少访问数据库的次数，就能实际上减少ORACLE的工作量。
8.使用DECODE函数来减少处理时间
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表。
9.整合简单，无关联的数据库访问
如果你有几个简单的数据库查询语句，你可以把它们整合到一个查询中(即使它们之间没有关系)
10.删除重复记录
11.用TRUNCATE替代DELETE
当删除表中的记录时，在通常情况下， 回滚段(rollback segments ) 用来存放可以被恢复的信息。 如果你没有COMMIT事务，ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况)。
而当运用TRUNCATE时， 回滚段不再存放任何可被恢复的信息。当命令运行后，数据不能被恢复。因此很少的资源被调用，执行时间也会很短。
12.尽量多使用COMMIT
只要有可能，在程序中尽量多使用COMMIT，这样程序的性能得到提高，需求也会因为COMMIT所释放的资源而减少
COMMIT所释放的资源：
A、 回滚段上用于恢复数据的信息。
B、被程序语句获得的锁。
C、 redo log buffer 中的空间。
D、ORACLE为管理上述3种资源中的内部花费。
13.计算记录条数
和一般的观点相反，count(*) 比count(1)稍快，当然如果可以通过索引检索，对索引列的计数仍旧是最快的。例如 COUNT(EMPNO)
14.用Where子句替换HAVING子句
避免使用HAVING子句，HAVING 只会在检索出所有记录之后才对结果集进行过滤。 这个处理需要排序，总计等操作。如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销。
15.减少对表的查询
在含有子查询的SQL语句中，要特别注意减少对表的查询。
16.通过内部函数提高SQL效率。
17.使用表的别名(Alias)
当在SQL语句中连接多个表时， 请使用表的别名并把别名前缀于每个Column上。这样一来，就可以减少解析的时间并减少那些由Column歧义引起的语法错误。
18.用EXISTS替代IN
在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接。在这种情况下，使用EXISTS(或NOT EXISTS)通常将提高查询的效率。
19.用NOT EXISTS替代NOT IN
在子查询中，NOT IN子句将执行一个内部的排序和合并。 无论在哪种情况下，NOT IN都是最低效的 (因为它对子查询中的表执行了一个全表遍历)。为了避免使用NOT IN ，我们可以把它改写成外连接(Outer Joins)或NOT EXISTS。
20.用表连接替换EXISTS
通常来说，采用表连接的方式比EXISTS更有效率
21.用EXISTS替换DISTINCT
当提交一个包含一对多表信息(比如部门表和雇员表)的查询时，避免在SELECT子句中使用DISTINCT。 一般可以考虑用EXIST替换
