计算机专业技能
计算机专业技能

计算机领域的专业技能是测试工程师应该必备的一项素质，是做好测试工作的前提条件。尽管没有任何IT背景的人也可以从事测试工作，但是一名要想获得更大发展空间或者持久竞争力的测试工程师，则计算机专业技能是必不可少的。计算机专业技能主要包含三个方面：
1. 测试专业技能
测试专业知识很多，本书内容主要以测试人员应该掌握的基础专业技能为主。测试专业技能涉及的范围很广：既包括黑盒测试、白盒测试、测试用例设计等基础测试技术，也包括单元测试、功能测试、集成测试、系统测试、性能测试等测试方法，还包括基础的测试流程管理、缺陷管理、自动化测试技术等知识。
2. 软件编程技能
“软件编程技能实际应该是测试人员的必备技能之一，在微软，很多测试人员都拥有多年的开发经验。因此，测试人员要想得到较好的职业发展，必须能够编写程序。只有能给编写程序，才可以胜任诸如单元测试、集成测试、性能测试等难度较大的测试工作。
此外，对软件测试人员的编程技能要求也有别于开发人员：测试人员编写的程序应着眼于运行正确，同时兼顾高效率，尤其体现在与性能测试相关的测试代码编写上。因此测试人员要具备一定的算法设计能力。依据资深测试工程师的经验，测试工程师至少应该掌握 Java、C#、C++之类的一门语言以及相应的开发工具。
3. 网络、操作系统、数据库、中间件等知识
与开发人员相比，测试人员掌握的知识具有“博而不精”的特点，“艺多不压身”是个非常形象的比喻。由于测试中经常需要配置、调试各种测试环境，而且在性能测试中还要对各种系统平台进行分析与调优，因此测试人员需要掌握更多网络、操作系统、数据库等知识。
在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理，尤其要掌握一些网络环境的配置，这些都是测试工作中经常遇到的知识。
操作系统和中间件方面，应该掌握基本的使用以及安装、配置等。例如很多应用系统都是基于Unix、linux来运行的，这就要求测试人员掌握基本的操作命令以及相关的工具软件。而WebLogic、Websphere等中间件的安装、配置很多时候也需要掌握一些。
数据库知识则是更应该掌握技能，现在的应用系统几乎离不开数据库。因此不但要掌握基本的安装、配置，还要掌握SQL。测试人员至少应该掌握Mysql、MS Sqlserver、Oracle等常见数据库的使用。
行业知识
行业主要指测试人员所在企业涉及的行业领域，例如很多IT企业从事石油、电信、银行、电子政务、电子商务等行业领域的产品开发。行业知识即业务知识，是测试人员做好测试工作的又一个前提条件，只有深入地了解了产品的业务流程，才可以判断出开发人员实现的产品功能是否正确。
很多时候，软件运行起来没有异常，但是功能不一定正确。只有掌握了相关的行业知识，才可以判断出用户的业务需求是否得到了实现。
行业知识与工作经验有一定关系，通过时间即可以完成积累。
个人素养
作为一名优秀的测试工程师，首先要对测试工作有兴趣：测试工作很多时候都是显得有些枯燥的，因此热爱测试工作，才更容易做好测试工作。因此，除了具有前面的专业技能和行业知识外，测试人员应该具有一些基本的个人素养，即下面的“五心”。
1.专心：主要指测试人员在执行测试任务的时候要专心，不可一心二用。经验表明，高度集中精神不但能够提高效率，还能发现更多的软件缺陷，业绩最棒的往往是团队中做事精力最集中的那些成员。
2.细心：主要指执行测试工作时候要细心，认真执行测试，不可以忽略一些细节。某些缺陷如果不细心很难发现，例如一些界面的样式、文字等。
3.耐心：很多测试工作有时候显得非常枯燥，需要很大的耐心才可以做好。如果比较浮躁，就不会做到“专心”和“细心”，这将让很多软件缺陷从你眼前逃过。
4.责任心：责任心是做好工作必备的素质之一，测试工程师更应该将其发扬光大。如果测试中没有尽到责任，甚至敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果。
5.自信心：自信心是现在多数测试工程师都缺少的一项素质，尤其在面对需要编写测试代码等工作的时候，往往认为自己做不到。要想获得更好的职业发展，测试工程师们应该努力学习，建立能“解决一切测试问题”的信心。
“五心”只是做好测试工作的基本要求，测试人员应该具有的素质还很多。例如测试人员不但要具有团队合作精神，而且应该学会宽容待人，学会去理解“开发人员”，同时要尊重开发人员的劳动成果——开发出来的产品。 17 楼 next_sun 2012-03-27 4.3 脚本完善
完善测试脚本常用的方法有修改脚本程序，设置参数，设置事务，插入集合点，插入检查点，插入注释等方法。
先解释一下这些完善方法的含义：
4.3.1 修改脚本程序
由于LoadRunner中脚本可以使用C语言中的标准函数和数据类型，所以可以在录制完的脚本中使用C语言来对脚本进行修改。C语言中的if 、for、while等循环控制语句可以用来改变脚本的执行过程，结合LoadRunner中很多固定的函数(参考LoadRunner自带的帮助)，可以加强脚本的功能。
3.3.2 设置参数
参数的含义表示可以把脚本中某些数据进行参数化设置，使该数据可以使用参数化后的参数表中的多个数值来代替。比如某个系统的登陆用户名就可以用一个参数来代替，这样就可以使多个用户在运行同一个脚本时能使用不同的用户名登陆，这样在创造负载的时候就更接近实际的负载情况。

用参数表示用户的脚本有两个优点：
?可以使脚本的长度变短。
? 可以使用不同的数值来测试你的脚本。
座席登录系统脚本中需要把登录用户名、登录密码、登录地址做参数化，如图4-15所示。
18 楼 next_sun 2012-03-27 参数化设置方法为：选中要参数化的常量，点击鼠标右键->选择Replace with a Parameter，弹出Select or Create Parameter 对话框，如图4-16所示。

图4-16 参数化命名
在Parameter name里面输入想要定义的参数名字，比如user，然后在Parameter type里选择参数的类型。这里的参数类型有很多种，一般的参数替代个人推荐使用File类型，File类型适用的范围很广，而且可以灵活的修改。Original value表示要参数化的数值。
选择工具栏-> 按钮，进入参数详细设置页面，如图4-17所示。

1）Edit With Notepad设置
推荐直接点击Edit with Notepad，可以直接编辑一个文本的参数文件，把要设置到参数表里的数值都直接写到文本文件里，每行只能写一个参数值，如图4-18所示。这里我们可以把要设置的用户名都复制到该文本文件里面保存就可以了。注意如果数据超过100个，在参数显示区只能显示100个，其他的只能在文本中看见。
19 楼 next_sun 2012-03-27 2）Select next row 设置
值的注意的是Select next row属性选择是针对所有虚拟用户来说的，是针对Controller设置的，在调试脚本的过程中是看不出来的，决定虚拟用户选择参数的过程。
?Sequential（顺序）：虚拟用户Vuser按照行顺序读取参数文件中的数据，如果参数文件的数据都执行了一遍，则返回第一行，继续执行。
?Random（随机）：在每次循环里随机的读取一个，但是在循环中一直保持不变。
?Unique（唯一）：分配一个唯一的有顺序的值给每个虚拟用户作为参数。
（注意：使用该类型必须注意数据表有足够多的数。比如Controller 中设定20 个虚拟用户进行5 次循环，那么编号为1 的虚拟用户取前5个数，编号为2 的虚拟用户取6-10 的数，依次类推，这样数据表中至少要有100个数据，否则Controller 运行过程中会返回一个错误。如果数据长度不够，就需要看When Out of values里面设置的值了。如果设置Abord The Vuser表示取消该用户的运行；如果设置为Continue in a cyclic manner表示继续运行，重新从头开始循环取数；如果设置为Continue with last value表示用户在以后所有的循环中都取参数表里最后的一个数值。）
?Some line as user：表示参数读取和user的方式一样。
3）Update value on 设置
设置脚本迭代过程中取值的策略。
?Each iteration：脚本每迭代一次都访问数据表中的下一个值。即在运行时，在同一次迭代都取相同的值。
?Each Occurrence：在运行时，每遇到一次该参数，便会取一个新的值。即使在同一次迭代中可能碰到多次该参数，那么每碰一次就换一次。
?Once：在同一个Vuser中一直取同一个参数，以后的迭代中都保持不变
20 楼 next_sun 2012-03-27 4.3.3 关联
创建脚本后，可以通过VuGen运行该脚本来对其进行验证。有时候，尽管操作的录制已成功，但相同操作的播放却会失败。因为许多应用程序使用动态值，每次使用该应用程序时这些值都会更改。例如，某些服务器为每个新会话分配唯一的会话ID。尝试回放录制的会话时，应用程序将创建与已录制的会话 ID不同的新会话ID。LoadRunner 通过关联解决此问题。关联将把会更改的值保存为参数。运行仿真时，Vuser 并不是使用录制的值，而是使用服务器为其分配的新会话ID。
举例：座席登录系统脚本中需要把JSESSIONID做关联，即特殊形式的一种参数化。找到服务器返回JSESSIONID，如图4-10所示。
一般在脚本开始位置，插入关联。把脚本以View Tree的方式来显示，选择要设定为关联的步骤，点击右键，选择Insert Before，如图4-11 所示。
弹出选择框，选择web_reg_save_param函数，如图4-12所示。
进入关联参数设置，如图4-13所示。
JSESSIONID参数化后，再把实际的JSESSIONID值替换为变量{SessionID}，所有的代码中都需要替换，替换后在代码中呈现为如图4-14所示。 21 楼 next_sun 2012-03-27 4.3.4 设置事务
为了衡量服务器对某个动作处理的响应时间我们需要定义事务（Transaction）。比如：我们在脚本中有一个登录的动作，为了衡量多用户同时执行登录服务器的响应时间，我们把这个操作定义为一个事务。LoadRunner 运行到该事务的开始计时，直到运行到该事务的结束点计时结束。这个事务的运行时间在结果中会有反映。我们可以自定义某些操作为一个事务或几个事务，定义了的事务会在测试过程中被作为测试的点来加以统计，分析其成功和失败的次数，响应的时间等。
插入事务有两种办法：一是在脚本录制过程中插入开始和结束事务点；二是在录制脚本完成后，编辑脚本时插入开始和结束事务点。对与新手推荐使用第一种，可以准确地找到插入事务点的位置。现在简单介绍第二种插入事务的办法。
在生成的脚本中找到要插入开始事务点的地方，选择菜单Insert->Start Transaction，如图4-19所示。在弹出的“开始事务“对话框中输入开始事务的名称（注意：事务的名称最好要有意义，能够清楚的说明该事务完成的动作），如图4-20所示。
插入结束事务点的过程与插入开始事务点的步骤是一致的，如图4-21和图4-22所示。

事务的脚本函数为：
lr_start_transaction("事务名字");
/*中间是事务操作*/
lr_end_transaction("事务名字", LR_AUTO);
22 楼 next_sun 2012-03-27 4.3.5 插入集合点
集合点主要是用在进行压力测试时使用，比如系统能同时支持1000个用户提交数据，要测试时就可以使用集合点，在要提交数据的操作前面设置一个集合点，让1000个用户在提交数据之前先聚集一下，等待所有用户到达该点以后就可以一起提交数据，对系统造成压力，可以检查系统在该压力下是否能正常的工作。注意，集合点只能插入到Action部分的脚本里，不能插入到vuser_init和vuser_end部分的脚本中。
插入集合点的方法很简单，在脚本录制完成后，以树形结果显示，用鼠标右键选择要设置的操作的前面Insert Before或Insert After来设置集合点，在Add Step中选择Rendezvous，如图4-22所示。
在集合点对话框中输入集合点的名称，最好选择有代表性的名字，如图4-23所示。
集合点的函数为：lr_rendezvous("集合点的名称"); 23 楼 next_sun 2012-03-27 4.3.6 插入检查点
检查点是指在脚本中可以插入检查网页中的Text（文本）或image（图片）的函数，用来检查服务器返回的网页是否正确或着检查网页是否是指定的网页。
插入检查点的方法和前面类似，只是在Add Step里面选择Web Checks，如图4-24所示。如果要设置检查图片，就选择Image Check，如果要设置检查文本，就选择Text Check。以文本检查为例，选择Text Check，如图4-25所示。
图4-24 选择检查点类型和检查点函数
图4-25 检查点属性设置
然后切换到“General”标签页，如图4-26所示。
图4-26 设置检查点的名称

4.3.7 插入注释
插入注释是为了在脚本中对一些特殊步骤来加以说明的方法。也可以在脚本程序里直接加“/*..*/“来表示，和C语言里面的注释方法一样。
也可以通过点击菜单栏里面Insert中的Comment来在光标所在处添加注释。
4.3.8 脚本完善
座席登录系统的脚本为login_taobao，该脚本定义了一个事务，一个集合点，两个检查点，四个参数。
?登陆事务：T_login
?集合点：R_login
?四个参数为：登陆用户名，定义为user；登陆密码，定义为pwd；登录地址，定义为url；用户绑定的电话，定义为phone
?两个检查点：登录成功检查点，登录失败检查点
24 楼 next_sun 2012-03-27 4.3.9 设置Run-Time Settings
当完善了测试脚本后，需要对VuGen 的Run-Time Setting 进行配置。下面对经常需要设置的几个标签页进行说明。
首先打开 Run-Time Setting 窗口，可以通过菜单或者工具栏进行，如图4-27所示。以下简单介绍下需要注意的选项。

1）Run Logic选项卡
主要用来设置运行是脚本迭代的次数，可以通过更改Number of interations的值来设置迭代的次数，如图4-28所示。

图4-27 Run Logic选项卡
2）Pacing选项卡：主要用来设置脚本迭代过程中脚本之间的时间间隔。
3）Log选项卡：主要设置日志的内容。
4）Think Time选项卡：主要是设置是否需要思考时间，如果不需要，就选择Ignore think time，否则推荐使用Reply think time配合As recorded来使用，即是使用录制的思考时间来进行测试。
5）Miscellaneous选项卡
是一个复合选项，涉及到的功能比较复杂，如图4-28所示。

图4-27 Miscellaneous选项卡
6）Speed Simulation选项卡：主要设置带宽的使用，有些时候可以进行扼杀带宽来进行测试。
7）Preference选项卡：这里仅仅对两个经常需要改动的选项进行说明，如图4-28所示。
25 楼 next_sun 2012-03-27 4.4 单机测试运行脚本
脚本完善之后，可以先运行一下，看完善后的脚本是否能正常的运行，也可以检查脚本中是否有语法错误。
可以使用菜单栏中的Vuser下面的Run指令来运行一个脚本，如果在General Options里面选择了Show browser during reply，那么在运行时可以从Run-Time Viewer中浏览到实际在浏览器里操作的行为。运行结束后会有一个报告,如图4-29所示。

5 测试过程
5.1 创建场景
创建场景需要运行Controller，在开始/程序/Mercury LoadRunner/Applications下运行Controller，如图5-1所示。

图5-1 新建场景
点击OK按钮，进入场景设计页面，如图5-2所示。

1）Load Generator Machines设置
添加Load Generator Machines，点击工具栏上 按钮，出现Load Generators 窗口，如图5-2所示。由于这里的负载用户全部由本地计算机来产生，所以这里只有localhost，执行“Connect”操作，使Status 为Ready，表示该机器联接正常，如果为Failed，表示该机器不能联接，请检查原因。
26 楼 next_sun 2012-03-27 图5-2 Load Generator
2）Global Schedule设置
双击“Start Vusers“，添加虚拟用户总数，设置同时加载负载还是每隔一段时间加载一定负载，按图5-3设定好（500个虚拟用户，每隔1秒加载五个虚拟用户）。

图5-3 虚拟用户开始场景
双击“Duration“，设置场景持续时间，按图5-4所示。

图5-4 持续时间设定
双击“Stop Vusers“，设置虚拟用户退出场景，按图5-5设定好（每隔1秒退出五个虚拟用户）。

图5-5 虚拟用户结束场景
3)设置集合点
如果在脚本中设置了集合点，还需要在Controller 中设置集合点策略。在菜单中调出设置集合点策略的窗口，如图5-6所示。

图5-6 集合点设置
点击 按钮，进入集合点策略设置窗口，如图5-7所示。
图5-7 集合点策略窗口 27 楼 next_sun 2012-03-27 5.2 运行场景
当场景创建完成以后，我们就可以运行场景进行实际测试了。切换到Run选项卡，运行场景只需要点击一下 就可以了。场景运行过程中要关注场景的运行情况，如图5-8所示。
“运行”视图包含五个主要部分：
?场景组：位于左上窗格中，使您可以查看场景组中的 Vuser 的状态。使用该窗格右侧的按钮可以启动、停止和重置场景，查看单个 Vuser 的状态，并且可以手动添加更多的 Vuser，从而增加场景运行期间应用程序上的负载。
?场景状态：位于右上窗格中，使您可以查看负载测试的概要，其中包括正在运行的 Vuser 数以及每个 Vuser 操作的状态
?可用图树：位于中部左侧窗格中，使您可以查看 LoadRunner 图列表。要打开图，请在该树中选择一个图，然后将其拖动到图查看区域中。
?图查看区域：位于中部右侧窗格中，使您可以自定义显示以查看一至八个图（“视图” > “查看图”）。
? 图例：位于底部窗格中，使您可以查看选定图中的数据。
图5-8 场景运行界面 28 楼 next_sun 2012-03-27 5.2 分析实时监视图表
Q1 事务响应时间是否在可接受的时间内？哪个事务用的时间最长？
看 Transaction Response Time 图，可以判断每个事务完成用的时间，从而可以判断出那个事务用的时间最长，那些事务用的时间超出预定的可接受时间。
如图5-9可以看出，随着用户数的不断增加，login 事务的响应时间增长的最快！

图5-9 Transaction Response Time 图
Q2 网络带宽是否足够?
“Throughput”图显示在场景运行期间的每一秒钟，从Web Server 上接受到的数据量的值。拿这个值和网络带宽比较，可以确定目前的网络带宽是否是瓶颈。如果该图的曲线随着用户数的增加，没有随着增加，而是呈比较平的直线，说明目前的网络速度不能够满足目前的系统流量。

图5-10 T Throughput 图
Q3 硬件和操作系统能否处理高负载?
“Windows Resources”图实时地显示了Web Server 系统资源的使用情况。利用该图提供的数据，可以把瓶颈定位到特定机器的某个部件。
图5-10 Windows Resources 图 29 楼 next_sun 2012-03-27 6 测试结果分析
6.1 Analysis 窗口概述
场景运行结合后，点击 按钮，可以打开Analysis 窗口，生成测试报告。
Analysis 报告主要包括四大部分：概要、统计、事务统计和HTTP响应。
?概要部分，如图6-1所示。
?HTTP 响应统计，如图6-3所示
?事务统计，具体如图6-4所示。
6.2分析窗口数据
因为由于每个人的电脑配置不同，场景也不一样，生成的Analysis 会话文件也不一样，所以下面说的各项作为参考。实际运行的数据可能不一样，但是每项的含义一致。
6.2.1查看事务平均响应时间
图6-4 事务统计图
如图6-4所示的事务统计中，我们来关注一下T_login事务，90%的响应时间是 1.674秒，小于性能指标3秒。该数值和事务平均响应时间比较接近，说明发生的大多数登录事务的响应时间比较平稳，还能看到该事务失败了 0 次。
点击该事务的名称，打开平均事务响应时间图，如图6-5所示。可以观察到T_login 事务的平均响应时间比较平稳，说明该服务器性能比较稳定。同时观察到，登出、注销、事务的平均响应时间也都比较平稳。
图6-5 平均事务响应时间
6.2.2 研究Vuser的行为
1）在图树中单击 ，将在图查看区域中打开正在运行的 Vuser 图，如图6-3所示。可以看到在场景运行的开始，正在运行的 Vuser 处于逐渐加压状态。接着，500 个 Vuser 同时运行了 30秒，之后开始逐渐减压。

30 楼 next_sun 2012-03-27 图6-6 正在运行的Vuser图
2）筛选该图，观察所有 Vuser 同时运行的时间片。右键单击该图并选择 “Set Filter/Groud By”，弹出筛选窗口。点击“Scenario Elapsed Time”这一项的“Value”中的向下箭头，选择时间范围为从 1:30（分钟: 秒）至 3:45 （分钟: 秒）。现在，正在运行的 Vuser 图仅显示场景运行中 1:30（分钟: 秒）和 3:45 （分钟: 秒）之间运行的 Vuser。所有其他的 Vuser 已全被筛选出去。
2）关联两个图，把两个图放在一起，以查看一个图的数据对另一个图的数据所产生的影响。这称为将两个图关联。将正在运行的 Vuser 图和平均事务响应时间图相关联以比较其数据，以查看大量的 Vuser 对事务的平均响应时间产生的影响。右键单击正在运行的 Vuser 图并选择“Merge Graphs”，弹出窗口，如图6-4所示，设置好之后确定。现在，正在运行的 Vuser 图和平均事务响应时间图在图查看区域中表示为一个图，即“Running Vusers-Average Transaction Response Time”，如图6-7所示。
图6-7 Merge Graphs

图6-8 关联图
分析图6-8，在该图中可以看到随着 Vuser 数量的增加， login 事务的平均响应时间趋于平稳。换句话说，随着负载的增加平均响应时间没有随之变化。
31 楼 next_sun 2012-03-27 1.1.2 响应时间
响应时间是指应用系统从发出请求开始到客户端接收到所有数据所消耗的时间。从图1-2可以看到，页面响应时间可以分解为“网络响应时间”和“应用程序与系统响应时间”之和，即（N1 + N2 + N3 + N4 ) + ( Al + A2+ A3 ）。
32 楼 NEXT_MOON 2012-04-01 阶段检测项内容自检结论备注
版本测试前是否召开版本测试开工会/版本测试协调会？
是否已经明确本版本的测试策略/验收测试策略？
是否已研读自己负责特性的测试方案、测试经验总结以及特性测试报告等文档？
是否已通过配套的规格清单文档或设计规格文档，熟悉测试特性的规格？
是否参照对应的版本配套表，将测试使用的UAP、CTI、DB、JDK、客户端浏览器等配套部件升级到最新的正式发布版本？
是否检查业务软件与OS的配套关系(如业务软件对外只宣称部署在suse 10操作系统上、业务软件可部署在suse 10/suse 11/windwos操作系统上等)？
是否检查业务软件与服务器型号配套关系(如部署在HP、IBM、RH等)？
是否检查服务器硬件配置与业务软件需要的满足程度(如业务软件需要在4C8G的硬件配置上运行等)？
是否检查业务软件与tomcat、JDK配套关系(如配套tomcat 5.5.26版本、JDK 1.6版本等)？
是否检查业务软件与浏览器客户端的配套关系以及分辨率要求(如客户端配套IE6/IE7/IE8/IE9/火狐等，客户端PC的分辨率要求是1280*1024等)？
客户端浏览器是否已经根据产品要求或者产品文档进行设置？
版本加载后，是否已确认加载的版本和版本配套表中的信息一致（包括硬件、软件等）？ 33 楼 NEXT_MOON 2012-04-01
是否确认了测试环境、数据配置和组网方案，模拟客户实际的使用场景进行验证？实验室测试环境和现网环境不一致的地方，是否已经和开发、SE一起进行评估与确认？
测试用例是否已经覆盖特性清单中所有特性？
是否认真阅读和理解了需要执行的用例，是否搞清楚每一个用例的测试方法、观察点、测试预期输出？
如果测试的新增特性没有用例，是否已梳理测试点并提交其他人评审，然后基于测试点进行测试？
是否明确版本新增、修改、删除的特性，如果版本特性有所修改，是否对测试用例做相应增加或修改？
在转测电子流启动后，是否已检查转测的入口条件(包括问题单解决率是否达到转测标准、转测前需解决的问题是否已经解决、遗留DI值是否满足转测规定等)？
确认web应用是否只能单独部署在独立的服务器上，一台服务器上不能部署多个web应用？
web性能测试前，是否已经确定了web应用服务器、数据库服务器测试时的通用指标(比如服务器CPU占用率一般达到70%时，服务就接近饱和；可用内存数)？
web性能测试前，是否已经确定了web应用的指标(比如响应时间，吞吐量，连接数，呼损率等)？
是否已经准备性能测试脚本？
34 楼 NEXT_MOON 2012-04-01 版本测试中是否从VMP上获取测试版本和测试资料？
是否仔细研读发布版本的配套文档，包括版本说明书、特性说明书和版本配套表等？
在正式测试前，是否开展预测试活动，评估转测试版本的质量？
是否严格按照测试用例中的预置条件、测试步骤和预期结果进行测试？
在测试期间，是否及时置上用例执行结果？
在测试期间，对发现有问题的用例、测试点遗漏是否及时记录？
在测试期间，是否将日志信息开启？(包括开启drwtsn32、Wireshark、ICDDebug、服务端开启到debug级别)
测试期间，是否可以正常下载ActiveX控件？
测试期间，是否可以正常运行ActiveX控件？
测试期间，是否在多个浏览器上验证过数字证书？
测试期间，web用户是否可以长期不登出？
测试发现的问题是否都已提单跟踪，包括无法复现的问题以及非本人负责测试的特性问题？
35 楼 NEXT_MOON 2012-04-01 是否对问题单填写规范程度进行检查(如问题单级别，问题发现步骤，开发确认人，复现难度、日志文件等)？
回归问题单时是否关注了测试经理及开发人员的测试建议，对于以问题单方式合入但又没有相关文档的小特性，是否已反馈给测试经理？
回归问题单时是否关注了版本配套，以及兼容性等？(如在不同的IE上进行回归)
测试过程中，是否对测试进展、计划、问题、风险等发日报跟踪？
在版本特性测试或问题单回归时，如果命令行或特性使用方法发生变化，是否同步验证资料的修改情况？
根据测试过程中的质量情况，对于高风险的问题是否及时通知开发/PM等？
是否已进行资料全量测试或资料的增量测试？
是否已进行性能测试？
是否已进行兼容性测试(不同操作系统配套不同浏览器，windows xp/win 7+IE6/IE7/IE8/IE9/火狐等)?
是否不同浏览器覆盖了所有特性，而不是不同浏览器分别覆盖部分特性(如共两个特性，特性1和特性2在IE6-IE8上都覆盖测试了，而不是特性1仅在IE6上测试，特性2在IE7-IE8上测试)？
在版本发布前或TR5前，是否已完成DFX测试？(包括可靠性、安全性、可服务性)
36 楼 NEXT_MOON 2012-04-01 版本测试结束后版本测试结束后，是否已将所有的用例都置上结果，Failed用例附上或关联相关的问题单，Block / Unavailable的用例都写上原因？
版本测试结束后，是否已经和用例作者确认及更新所测试特性的用例（包括添加、修改、删除），并知会特性责任人或测试经理？
版本测试结束后，是否已经输出或更新相关特性的测试经验总结文档？
版本测试结束后，是否将发现问题都和开发确认并提单跟踪？
版本测试结束后，是否对发现问题进行问题单分析(包括是否漏测、开发修改引入等，详见问题单分析模板)？根据问题单是否在TMSS上补充相关用例？
如果存在漏测，在补充漏测用例后，是否检查相似功能存在类似问题？
版本测试结束后，是否对版本质量进行分析？(包括回归不通过问题数、开发修改引入问题数、本次发现问题单数量、遗留缺陷密度等，详见版本质量分析模板)
缺陷分析后，是否明确各个特性的稳定情况，以为下个版本的测试策略写作提供指导？
版本测试结束后，是否已经完成版本测试报告/自动化测试报告/性能测试报告、测试执行CheckList自检等文档并归档？
版本结束后是否进行版本总结会？