录制包含附件上传功能的web页面操作时会遇到什么样的问题？且看

第6天 关于录制附件上传的问题

被测系统有一个业务模块带有附件上传功能。为了验证部分用户在上传附件的同时，另一部分用户能正常工作，所以在进行组合业务并发用户测试时，选取上传附件这一操作。附件大小限制是200M，录制时上传超过100M的附件，结束录制后LR不能生成相应的Vuser脚本，aciton事务中未生成任何脚本。

无论是重新录制，还是更改设置，始终无法录制出上传>100M附件的脚本。随后将附件大小改为100M以下，此时能够正常录制。导致该现象的原因不明，LR也无任何明显提示。

遗留问题：性能测试有一种是大数据量测试，目的是验证网络传输模块在传输超大文件时的性能以及在大规模数据库里查询时的性能。倘若上传超过100M的附件LR无法正常录制，那也就无法用LR做大数据量测试

事务响应时间(Transaction Response Time)是LR提供的最常见性能指标。通常录制者会将一系列操作定义为一个事务，这是从宏观的角度来说。而从微观来看，事务是若干个客户端请求的集合。那事务响应时间由哪些时间组成？今天我突然问自己，却发现这个看起来最熟悉的字眼，却还未真正了解它……

欲知详情，请看附件

   大多数基于.net平台的系统会有DropDownList控件（下拉选项列表），该组件有一个属性称为AutoPostBack，这是一种数据自动回发机制。当用户更改了下拉选项，系统会自动将新数据提交给服务器端处理，随后刷新客户端页面，显示服务器端回传的处理结果（从原理来说 ，更改下拉选项，会激发SelectedIndexchange事件，事件代码被执行）。

如何成功录制包含DropDownList控件的web程序……

欲知详情，请看图文并茂的附件

LR9.0的手动测试场景界面较前面的版本有所变化。其中测试场景运行模式有了更细的划分：Real-life Schedule  和  Run until complete .

如何根据实际需要选用测试场景的运行模式……

欲知详情，请看附件

在对B/S架构的系统进行性能测试时，为了让测试场景更接近真实的用户使用场景，往往在LR中设置“IP欺骗”。所谓IP欺骗，即每个虚拟用户使用自己的IP地址访问WEB服务器，但实际上这些虚拟用户只运行在一台主机上，共用一个IP地址。

本篇讨论的是在LR启用“IP欺骗”后可能引发的问题。欲知详情，请看附件。

前言

写手记的目的就是想把实施性能测试的过程中遇到的一切奇怪、棘手的问题都收录下来，已解决的就附带解决方案，以便保留这样一个学习历程与学习心得。

测试环境与开发环境分离的必要性

1、搭建独立的测试环境有利于重现开发环境无法重现的BUG。这样说也许会显得抽象，我们不妨举个简单的例子来说明：某个软件系统由模块A、B、C组成（对应开发人员A、B、C）。起初开发人员比较偷懒，不想重新搭建独立的测试环境（特别是搭建过程比较复杂的情况下），而是让测试人员连到他们各自的开发机器上分别测试他们各自负责的模块。各自的模块功能很正常，但一旦整合作为一个系统向用户提供功能时，就不一定正常了，有可能在模块A录入的数据在模块B查询不到，或是模块间的接口有问题等。除此以外，还可能有其他因素妨碍开发环境重现BUG。总之，搭建一个与典型用户环境配置一致的测试环境是有效测试的重要前提。

2、搭建独立的测试环境便于开发人员并行地修复BUG。如果对开发环境进行测试，开发人员要修复BUG必须先重现BUG，然后修改相关代码，并进行程序调试。而在测试人员还未测试完系统前，开发人员是不能对程序进行修改、更新。只有等测试人员测试完后才能进行BUG修复。现实中也有这样的情况：测试员还未测试完开发人员就更新修复部份BUG的程序。这种做法比较危险，开发人员若修复得不好可能会导致程序无法运行，势必影响测试进度。此外，有可能导致上一个版本发现的缺陷无法追溯。而串行的工作方式也很耗费时间，甚至影响进度。正确的做法应该搭建独立的测试环境，测试人员提出BUG后开发人员在开发机上重现并修复，并验证修复后的效果，两种环境互不干扰。

3、搭建独立的测试环境可以验证安装软件的全过程，即安装测试。用以检查安装文件是否有错漏，软件在指定的操作系统下能否都能正常安装，各种配置项是否有错漏等。

4、搭建独立的测试环境可以避免环境被破坏导致测试无法进行的意外。如果选择开发环境来进行测试，开发人员进行某项误操作后发生系统崩溃或者系统不能正常运行的意外，此时测试工作也不得不停止。

deferred-暂缓
open-打开

执行首次测试后，测试人员利用缺陷管理系统管理所有提交的缺陷，缺陷状态的转换是其中最需要关注的工作。本文讨论的是被项目经理标记为暂缓处理的BUG ，该由谁将暂缓状转变为open状？

有些测试团队的做法是不做限定，项目经理或开发人员均有暂缓->open状态转变的权限。但诸多项目实践告诉我们，极少会有开发人员再去关注标记为暂缓处理的BUG，最后均是不了了之，即使有些觉悟比较高的开发人员乐意去修复暂缓处理的BUG,但他也不清楚这些BUG修复的deadline。这个时候的“暂缓”状就等同于“拒绝修复”。这样的后果就可能致使一些缺陷遗漏处理。所以，规范的做法还是由项目经理处理“暂缓”状的缺陷，毕竟是项目经理最清楚这些缺陷应该在什么时候被处理。

   测试人员在缺陷管理工具新增缺陷报告后，开发人员修复缺陷时会被要求填写一个属性字段“预处理版本”，这个字段的含义是告诉测试人员缺陷即将被修复的软件版本，便于测试人员在相应的版本提交后验证缺陷是否修复。但有的开发人员提出疑问：此字段是否必须填写？版本提交前将缺陷状态标为fixed后，测试人员只需过滤出状态=fixed的缺陷就可以做验证了。这个不是没有道理，但从测试管理的角度来说，填写预处理版本是规范化的体现，这样做的必要性在于：

1、测试人员在缺陷管理工具里对状态标记为fixed的缺陷进行回归测试时，开发人员同时处理状态标记为oepn的缺陷，一旦完成修复的也会标记为fixed。但测试人员在现行版本不可能对开发人员刚刚标记为fixed状的缺陷进行回归测试。那这两类状态一样的缺陷如何区分开？只有通过预处理版本号来区分，后一类fixed状的缺陷会在后续版本提交。如果不做区分，测试人员去核对那些还未提交修复的缺陷，发现未修复就会将状态标记反复，打回给开发人员，如此误会太令人啼笑皆非。

2、利用缺陷管理工具进行度量时可充当过滤条件。比如统计某个版本有多少个缺陷不是一次性修复的，即缺陷反复率时，就可以设置过滤条件为：预先处理版本=XX & 实际修复版本<>XX，将过滤出的缺陷数/处理缺陷的总数就等于缺陷反复率。

但现实中会有一些开发团队采用较为特殊的缺陷处理方式，比如测试人员在缺陷管理工具提交了缺陷报告，而后项目经理标记出需要处理的缺陷，开发人员修复后提交新版本程序，并在提交说明文档里把需要验证的缺陷一一列举出来。此提交说明文档里更多的是用户反馈缺陷（来自用户反馈表），测试人员按此文档标明的BUG ID号和用户反馈缺陷来进行回归测试，而非在缺陷管理工具中先过滤出所有状态=fixed的缺陷再验证。

追溯导致这种做法的原因，就是软件在发布到用户现场之前遗漏了大量的缺陷未被发现或是未修改，所以用户在使用后会反馈大量意见，而如果把这些缺陷也输入到缺陷管理工具中是极其耗时的事（开发团队未设专门的实施人员，由开发人员身兼二职），一般用户反馈BUG会记在另外定制的表格里。提交修复时与缺陷管理工具里登记的一起写入提交说明文档。

而这样说法导致的现象又有哪些呢？经一段时间实践发现：
1、开发人员与测试人员无法在缺陷管理工具中实现交互。缺陷验证后开发人员只在提交说明文档里看验证结果，等于说这个提交说明文档已替代了缺陷管理工具成为交互平台。开发人员撰写提交说明文档会耗费更多时间，因为他们要把缺陷管理工具里的BUG ID号记录下来。
2、极有可能发生漏验。开发人员在撰写提交说明文档时有可能会漏写已修复的BUG，而由于测试人员只会验证文档里提到BUG，所以没写上但实际又修复的BUG是不会得到验证。

这样的缺陷管理流程在很大程度上脱离了工具，是一种耗时且不利于做缺陷度量统计的做法，同时也是软件在发布前未得到充分测试所导致的后果。

   统计是应用系统中十分常见的功能，统计列表往往由若干个数据列和计算列组成。数据列是指那些显示基础数据的列，通常引用表中现成的列数据。计算列则是指须通过一定公式运算得到的列。倘若表中的计算列是由表中的数据列计算而得，那验证统计功能的时候只需套用公式即可。但如果计算列是对数据表里的若干列数据（这些列不存在统计列表中）使用简单或复杂的select语句查询出，对于这种不直观的统计功能，如何验证统计是否正确？黑盒测试人员通常不关心程序代码的实现，不可能通过检查sql代码是否正确来实现功能验证，并且阅读他人编写的sql代码也很耗时，这样的方式是下下之策，往往耗时长且不容易发现BUG。是否有高效的测试方法吗？我在项目实践中总结出一些经验——借助查询功能来进行比对验证。由于效果直观，所以很容易发现BUG。

   本人手头上曾经历过这样一个项目：做电力设备故障相关的统计。统计表里有几个计算列：本月累计数、本月消缺数、本月消缺及时数。它们涉及的select语句中的where子句均比较复杂，其中，

   本月累计数=本月发现的故障数+本月以前发现的还未解决的故障数+本月以前发现的但在本月解决的故障数 ；
本月消障数=本月累计的紧急故障中已解决的故障数
本月消障及时数=处理期限在本月且已经消灭的紧急故障数

   由公式可见，要求出这3个计算列必须要编写复杂的select语句，设置层层过滤条件。测试人员要审查sql语句是否正确，不仅要看懂sql语句还要去弄清很多字段的含义，这已经超出黑盒测试的范围，而且非常不直观以及耗时。而该系统除了提供统计功能外还有查询功能，可通过对比查询结果和统计结果来验证统计的正确性。比如验证本月累计数，先在查询模块设置查询条件查出本月发现的故障数，再设置查询条件查出本月1号以前发现但还未解决的故障数，最后设置查询条件查出本月1号以前发现且解决日期落在本月的故障数，最后将各种查询结果进行加和运算，与统计值比对。其他统计值也同理验证。

   这种方式非常直观，事实证明，效果是很明显，有效地查出统计算法上的BUG。