测试培训教材

测试管理与QualityCenter培训手册 1、测试流程管理、测试度量方法 按照尽早进行测试的原则，测试人员应该在需求阶段就介入，并贯穿软件开发的全过程。就测试过程本身而言，应该包含以s下几个阶段。  -测试需求的分析和确定。  -测试计划。  -测试设计。  -测试执行。  -测试记录和缺陷跟踪。  -回归测试。  -测试总结和报告。 一个好的测试管理工具应该能把以上几个阶段都管理起来。 测试人员每时每刻都在度量别人的工作成果，而测试人员的工作成果又由谁来度量呢？度量的标准和依据是什么呢？软件测试的度量是测试管理必须仔细思考的问题。缺乏尺度会让测试失去平衡，缺乏标准会让测试工作难以衡量。 2、如何搭建测试管理平台？ 首要问题是流程的规范化。 （1） 测试进入和退出标准。 （2） 协作流程。 （3） 缺陷跟踪管理流程。 （4） 工具平台的引入。 目前主流测试管理平台与缺陷跟踪工具： 3、QC（Quality Center）介绍 QC标准测试管理流程 QC支持的应用服务器：Jboss、WebLogic、WebSphere QC支持的数据库：Oracle、SQLServer QC支持的操作系统：Windows、Linux、Solaris 支持群集： 服务器端硬件和数据库要求： Windows： Linux： Solaris： 客户端系统要求： 练习1：安装QC 详见《Mercury Quality Center 9.0 Installation Guide》 Win2003+SQLServerSp4+QC9.0安装示例 1、安装Windows Server 2003 Enterprise Edition、安装IIS邮件服务器 2、安装SQL Server 2000、打上补丁Sp4 安装好SQL Server 2000后注意启动SQLServer服务器 3、安装QC9.0 服务器名称也可以是IP地址 4、启动QC9.0 5、QC9.0安装问题解决 - JBOSS启动不了 原因：8080端口被其他应用程序占用。 用netstat查看谁占用了8080端口 netstat -ano 解决办法1：修改其他程序的端口使用 解决办法2：修改JBOSS的启动端口 JBOSS_HOME\server\default\deploy\jbossweb-tomcat55.sar\server.xml 6、修改IP地址后不能登录QC 解决办法： 在C:\Program Files\Mercury\Quality Center\jboss\server\default\deploy目录下找到10sabin.war 进入10sabin.war\WEB-INF，修改siteadmin.xml中的IP地址： 修改数据库中的数据： 修改后可以登陆 但是还需要修改以前Project的数据库连接属性 否则会提示错误 然后还要修改 C:\Program Files\Mercury\Quality Center\repository\qc中的dbcon.txt： qcsiteadmin_db@192.168.1.12.1433. 还有 C:\Program Files\Mercury\Quality Center\repository\qc\Default\QualityCenter_Demo_db中的dbid.xml <DBSERVER_NAME>192.168.1.12</DBSERVER_NAME> 7、Mercury Tours 样例程序 启动：http://192.168.1.2:8080/mtours 注意安装JVM才能“View Calendar” 4、创建和定义测试需求、测试需求管理、跟踪 定义需求 1、查看需求 视图->需求树 2、添加需求 需求->新建需求 输入以下内容 3、添加子需求项 查看需求 ZooIn : CTRL + I ZooOut : CTRL + O 视图->编号 视图->需求网格 视图->筛选/排序->设置筛选器/排序 设置排序字段 设置过滤条件 修改需求 拷贝需求项Cruise Reservation 重命名需求项Cruise Reservation_Copy_1为Hotel Reservation 移动需求项到Reservations Management下 删除Hotel Reservation 把需求项转换成测试计划 选中Cruise Reservation 选择菜单“需求->转换为测试->转换选定需求” 将最底层的子要求转换为测试 把Cruise Seatch转换为步骤、再次转换为测试 选择主题路径： 查看转换结果： 练习2：从Office导入需求到QC 参考 QCMSWordAddin.pdf 和 QCMSExcelAddin.pdf 项目管理员可以使用QC的Excel插件工具来执行需求的批量导入，进行导入之前请先确认已经访问过MQC主页，并安装了QCMSExcelAddin.exe插件。 插件下载地址： http://updates.merc-int.com/qual ... /msexcel/index.html 在页面中选择最后一项“下载用于 Mercury Quality Center 9.0 的插件”进行下载。 下载完成后请按如下步骤进行需求导入： 1.安装QC9.0需求案例Excel导入软件QCMSExcelAddin.exe。执行安装前请先确保你的系统已经安装了Office Excel软件。 2.安装成功后，打开编制好的文件，选中所有要导入的需求记录，注意：只选数据. Export To Quality 3.点击“工具” Center 4.输入QC的URL地址 5.输入项目管理员的名称和密码 6.选择要导入需求的域和项目 7.选择第一项,导入需求。请注意:此工具可以同时支持案例导入和缺陷导入，如果需要导入的是案例，应选择Tests；如果需要导入的是缺陷，则选择Defects。 8.选择标准模板字段映射(一般默认选择) 9. 把QC中的需求字段和需求模版的列名所对应的字母标号进行关联映射。 从Excel导入 选Demo项目，提示错误： 改成用alice_qc用户登录即可！ Author全改成Admin 从Word导入 激活宏 无层次的： 有层次的： 5、测试计划管理、跟踪 定义测试计划树 在Cruises主题下添加“Cruise Cancellation” 在“Cruise Cancellation”下添加QTP自动化测试 Versions supported: o QuickTest Professional 8.2 SP1, 8.2 SP2, 9.0, 9.1, 9.2, 9.5, and 10.00 with Mercury Quality Center 9.0. o QuickTest Professional 9.0, 9.1, 9.2, 9.5, 10.00 with HP Quality Center 9.2. QuickTest Add-in for Quality Center： QTP9.5：QuickTest_Add-in_9.5_for_Quality_Center.msi 测试类型： Test Type Description MANUAL A Quality Center manual test. WR-AUTOMATED A test that is executed by WinRunner, Mercury's functional testing tool for Microsoft Windows applications. LR-SCENARIO A scenario that is executed by LoadRunner, Mercury's load testing tool. QUICKTEST_TEST A test that is executed by QuickTest Professional, Mercury's functional enterprise testing tool. VAPI-XP-TEST A test that is created using Visual API-XP, the Quality Center open test architecture API testing tool. For more information, see Working with VAPI-XP. SYSTEM-TEST A test that instructs Quality Center to provide system information, capture a desktop image, or restart a machine. For more information, see Working with System Tests. BUSINESS-PROCESS A business process test. For more information, refer to the Mercury Business Process Testing User's Guide: Creating Business Process Tests. About Working with VAPI-XP The VAPI-XP testing tool enables you to create new testing scripts using Microsoft VBScript, Microsoft JavaScript (JScript version), PerlScript, and PythonScript, and integrate these scripts into your testing process. Using VAPI-XP test scripts, you can test COM/DCOM servers, SOAP-based Web services, Java APIs (such as Java classes and EJBs), and console applications. You can also use VAPI-XP to create a LoadRunner virtual user. In addition, VAPI-XP is fully integrated with Quality Center, enabling you to design your VAPI-XP test script to call any Quality Center test or test set, and execute it as part of your own script. This allows you to build a more advanced test set execution flow, in which you can filter tests in a test set during execution, based on the status or type of each test. VAPI-XP is also fully integrated with the Quality Center open test architecture API. All open test architecture API classes and methods can be referenced from the VAPI-XP user interface so that you can easily include them in your test script. About Working with System Tests You can run a system test in order to retrieve a machine's system information, view a captured desktop image of a test run on a machine, or restart a machine. For example, you can run a system cleanup test that will restart the machine on which an automated test failed. Alternatively, you can create a system test to retrieve information about a machine's resource usage before or after a test run. You create a system test by adding a system test to the test plan tree, defining the test, and adding the test to a test set. Note: To run a system test, you must install the System Test Remote Agent Add-in and the Mercury Quality Center Connectivity Add-in on the machine where the test is to be run. For more information on Mercury Quality Center add-ins, refer to the Mercury Quality Center Installation Guide. When running a system test, the following steps are created: • For System Information: "SysInfo" • For Capturing a Desktop Image: "Snapshot" • For Restarting a Machine: "Reboot Start" and "Reboot Finish" You can view details for each of these steps after your system test has finished running. You can also view the system information that has been retrieved—such as CPU, memory, and processes running on the machine—and an image of the machine executing the system test. 6、测试用例设计、用例管理、测试覆盖率分析 设计测试步骤 为Cruises Reservation主题中的Cruise Booking测试用例添加测试步骤 新建测试步骤 拷贝测试步骤 把“Cruise Booking”的测试步骤拷贝到“Cruise Search”中 按住CTRL键逐一选择所有步骤 复制步骤（CTRL+C） 选择“Cruise Search”测试，打开“设计步骤”界面 粘贴步骤（CTRL+V） 调用测试 重用：测试用例设计模块化、参数化 选择测试“Cruise Booking” 在设计步骤界面中选择“调用测试” 查找“Connect”，选择“Connect And Sign-On” 把“调用<Connect And Sign-On>”的测试步骤调整到第一步 查看需求覆盖率 -- Linking Requiremnets to a Test 将需求链接到测试Cruise Booking 注：由于Cruise Booking的测试是由Cruise Booking的需求转化而成的，所以需求覆盖中默认就覆盖了Cruise Booking的需求项 添加对“View Reservations”需求项的覆盖 -- Linking Tests to a Requiremnet 将测试链接到需求 在需求模块，选择菜单“视图->需求范围” 将测试用例“Cruise Search”链接到需求项“Cruise Booking”： -- Analyzing Tests Coverage 分析测试覆盖率 视图->范围分析 右键选择“Mercury Tours Application”，选择“覆盖范围分析” 查看处于失败状态的测试覆盖： 显示测试覆盖率饼图： 7、生成自动化测试脚本、BPT模型 产生自动化测试脚本 是否需要实现自动化： 自动化实现“Cruise Search”测试用例： 定位到“Cruise Search”测试用例，在“设计步骤”界面中选择“生成脚本->QUICKTEST_TEST” 需要“Launching Quick Test Professional”来进一步地编辑和修改自动化测试脚本。 什么是BPT？ 业务组件测试 用户参与、尽早测试： 基于角色和工作流的BPT模型 角色定义应该灵活、根据能力、时间资源等决定。 Automation Engineer Subject Matter Expert Workflow 业务组件模块 测试计划模块 8、测试任务定义、测试任务分配 定义测试集 测试集的例子： 创建“Mercury Tours Site”测试集 Mercury Tours 1.0.1 新建测试集： 本测试集包含用于测试Mercury Tours网站的功能正确性的测试用例。 设置测试集属性中的详细信息： In ITG Request Id, add the IT Governance request ID. Note that this is relevant only when integrating with an IT Governance tool. 设置自动化测试失败时采取的措施： 设置测试失败时邮件通知相关人员： 为测试集添加测试用例 把测试计划树中的“Cruises”包含的所有测试用例以及“Airline Preference”、“Number of Passengers”添加到测试集中： 9、测试过程监控 计划测试的运行 在“Mercury Tours 1.0.1”中新建一个测试集： 把“Sign-On/Sign-Off”中的测试用例“Sign-On Page”添加到测试集中： 切换到“执行流”界面，添加“Sign-On Password”和“Sign-On User Name”两个测试用例： 右键选择“Sign-On User Name”，选择“测试运行计划” 新建执行条件： 设置“Sign-On User Name”的时间依赖性： 为“Sign-On Password”设置执行条件： 执行布局： 练习3：手工和自动两种方式执行一个测试用例 手工执行测试 手工执行Cruise Booking测试 选择测试集中的Cruise Booking 运行->手工运行： 开始运行： 输入password参数 一步步执行 在“Actual”中输入实际测试结果，标记测试步骤是否通过 自动执行测试 注意在QTP中设置“Allow other Mercury products to run tests and components”,否则会提示错误： 调用QTP执行“Number Of Passengers”测试用例中的脚本： 10、缺陷登记、如何录入一个合格的BUG Bug的质量衡量 某些测试人员认为录入的Bug描述不清晰不要紧，如果导致开发人员误解的话，开发人员应该主动来找测试人员问个明白。 这话有一定的道理，这确实有一部分沟通上的问题。但是测试人员如果尽量清晰地描述缺陷，尽量让开发人员一看就明白是什么问题，甚至是什么原因引起的错误。这样岂不是节省了更多沟通上的时间？ 因此需要引起测试人员注意的是，Bug的质量除了缺陷本身外，描述这个Bug的形式载体也是其中一个衡量的标准。如果把测试人员发现的一个目前为止尚未出现的高严重级别的Bug称之为一个好Bug的话，那么如果录入的Bug描述不清晰，令人误解，难以按照描述的步骤重现的话，则会大大地有损这个好Bug的“光辉形象”。 如何录入一个合格的Bug？ 那么如何录入一个大家认为好的，尤其是开发人员认为好的Bug呢？撰写缺陷报告的一个基本原则是：客观地陈述所有相关事实。 一个合格的Bug报告应该包括完整的内容，至少包括如图所示的方面。 合格的缺陷报告需要包括的方面 报告发现问题的版本 开发人员需要知道问题出现的版本，才能获取一个相同的版本进行问题的重现。并且版本的标识有助于分析和总结问题出现的集中程度，例如版本1.1出现了大量的Bug，则需要分析是什么原因导致这个版本出现了大量的问题。 需要注意的是，有些Bug在不同的版本出现，例如，某个Bug在版本1.1的时候出现了，测试人员录入了Bug，ID为101，开发人员也进行了修改，经验证关闭了。但是到了版本1.4时又出现了，这时候，有些测试人员回去把Bug101的状态改成Reopen，这是错误的，因为这个Bug是在新的版本出现的，即使是同一个现象，甚至是同一个原因造成的，也不应该Reopen，而是新加一个，因为这代表了一个质量回归问题，这个缺陷确实又出现了，大家因为这个缺陷造成了损失，测试人员需要重新测试和验证、报告，开发人员需要再次修改程序、编译；如果Reopen,则可能造成质量统计时漏算了一个缺陷。 报告问题出现的环境 包括操作系统环境、软件配置环境、有时候还需要包括系统资源的情况，因为有些错误只有在资源不足时才出现。 由于开发环境与测试环境存在差异，往往导致有些问题只有在测试环境下才能出现，例如开发环境中使用的某些第三方组件在测试环境没有注册。这时候，测试人员应该把这些差异写清楚，以便开发人员在重现问题和进入调试之前把环境设置好。 报告问题重现的操作步骤 应该描述重现问题所必须执行的最少的一组操作步骤。 有些测试人员往往一发现问题就把重现步骤录入，报告Bug。这些重现步骤可能是非常冗长的一个操作，而实际上可能仅仅是其中的一两个关键步骤的组合才会出现这样的错误。那么需要开发人员重新执行这些多余的步骤其实是在谋杀开发人员的宝贵时间，因为调试的周期会因此加长。 技巧：正确的做法是，录入之前再多做几次尝试，尽量把操作步骤缩减到必须要执行才能重现错误的几个步骤。 应该尽量地简化问题，例如一个100行的SQL语句执行时出错，可能仅仅是其中的某几行语句有问题导致的，如果能把SQL语句简化到3行，而问题依然存在，这样的报告更容易受到开发人员的欢迎。 描述预期的行为 要让开发人员知道什么才是正确的。尤其是要从用户的角度来描述程序的行为应该是怎样的。例如：程序应该自动把文档同步到浏览界面。 经常见到一些测试人员描述的Bug模棱两可，例如：“编辑单据时，列表中不出现日期信息。” 让人一眼看上去不能知道，列表中应该出现日期信息还是不要出现日期信息。尤其对于一些不熟悉需求的开发人员来说，不清楚测试人员是要求要这样做，还是指出这样做的错误。 技巧：明确地说明程序的预期行为才能更好地表达需求。 描述观察到的错误行为 描述问题的现象，例如：“程序抛出异常信息如下…”。 技巧：记住在描述这些错误的行为时要客观地反映事实，不要认为夸大、更不要讽刺。 除了上面说的Bug的版本、出现的环境、重现的步骤、预期的行为、错误的行为这些必须录入的缺陷信息外，还有一些是需要及时登记，以备将来统计和报告用的。例如，缺陷的严重程度、出现的功能模块、缺陷的类型、发现的日期等信息。 Bug报告应该注意的几个问题 Bug的报告是测试人员辛勤劳动的结晶，也是测试人员价值的体现。同时也是与开发人员交流的基础，Bug报告是否正确、清晰、完整直接影响了开发人员修改Bug的效率和质量。因此，在报告Bug时，需要注意以下几个问题： （1）不要出现错别字。 测试人员经常找出开发人员关于界面上的错别字、用词不当、提示信息不明确等的问题，可笑的是，测试人员在录入Bug的时候却同样是一大堆的错别字，描述不完整、不清晰，测试人员应该要停止这样的无聊游戏了，所谓“己所不欲，勿施于人”。 （2）不要把几个Bug录入到同一个ID。 即使这些Bug的表面现象类似，或者是在同一个区域出现，或者是同一类问题，也应该一个缺陷对应录入一个Bug。因为这样才能清晰地跟踪所有Bug的状态，并且有利于缺陷的统计和质量的衡量。 （3）附加必要的截图和文件。 所谓“一图胜千言”，把错误的界面屏幕截取下来，附加到Bug报告中，可以让开发人员清楚地看到Bug出现时的情形。并且最好能在截图中用画笔圈出需要注意的地方。 技巧：必要的异常信息文件、日志文件、输入的数据文件也可作为附件加到Bug报告中，方便开发人员定位和重现错误。 （4）录入完一个Bug后自己读一遍。 就像要求程序员在写完代码要自己编译并做初步的测试一样，应该要求测试人员在录入完一个Bug后自己读一遍，看语义是否通顺，表达是否清晰。 添加新缺陷 新建缺陷 附加URL： 避免冗余缺陷 查找与ID为37的缺陷类似的缺陷 查找类似缺陷 更新缺陷 直接在表格列表中更新 打开缺陷详细信息对话框进行更新 添加注释 11、BUG生命周期 如何跟踪一个Bug的生命周期？ 测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。通常一个典型的缺陷状态转换流程如图所示。 缺陷状态转换图  New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。  Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。  Fixed ：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。  Rejected：如果认为不是Bug，则拒绝修改。  Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。  Closed：修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。  Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。 上图也是一个基本的缺陷状态变更流程，每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。 例如，测试人员新发现的Bug，必须由测试组长评审后，才决定是否Open并分派给开发人员。测试人员Open的Bug可以直接分派给Bug对应的程序模块的负责人，也可以要求都先统一提交给开发主管，由开发主管审核后再决定是否分派给开发人员进行修改。 Bug的跟踪以及状态变更应该遵循一些基本原则，例如：  测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。  对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。 如何与开发人员沟通一个Bug 能让开发人员解决最多Bug的测试人员是最优秀的测试人员。如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是总有“书难达意”的时候，这时候就需要测试人员主动与开发人员进行沟通了。 如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者是很难用书面语言表达出来时，则应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思。而不要等待开发人员找自己了解更多的信息。 注意：在表述一个Bug的时候应该始终抱着公正客观的态度来描述事实。 另外，应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。 12、缺陷跟踪管理 创建收藏夹 设置筛选器/排序 Detected By：alex_qc Status：Not Closed 收藏夹->添加到收藏夹 把缺陷链接到测试 打开测试计划树，选择Cruise Booking测试用例 链接现有缺陷->选择 在缺陷的“链接的实体”界面中可以看到所连接的测试用例 练习4：通过Email发送缺陷 通过电子邮件发送 13、生成图表、测试报告编写 生成报告 分析->报告->标准需求报告 配置报告与子报告 设置过滤条件 自定义字段（布局） 清除附件和历史记录选项 添加到收藏夹 生成图表 分析->图-><摘要> - 按“状态”分组 设置过滤条件 Piority Status X轴设置为Priority 刷新 查看详细信息 饼图 数据表格： 生成活动分析图表 添加图 摘要 分组方式：Designer X轴：Execution Status 14、测试报告分析 测试人员的工作通常不能像开发人员那样能直接体现出来，被大家直观地看到。开发人员做的是建设性的工作，开发了哪些功能，写了几行代码，设计了几个类，都能直观地看到，最重要的是软件能很鲜活地演示开发人员的工作。 但是测试人员的工作相对隐蔽一点，测试人员做的是破坏性的工作，并且没有很多可以直观地体现测试人员的贡献的东西。笔者曾经听到公司的人事部的一位同事说：“你们做测试的真好，整天坐在那。”当然这是外行人看内行说的话。但是给笔者的一个启示是：测试人员需要更多地表现自己，展现自己的工作。 说明：测试报告是一个很多的展示自己工作的机会。缺陷列表太细了太多了，测试用例有点过于专业，很多人对其不感兴趣。但是测试报告是很多人会看的一份文档。 下面是某个项目的测试报告的纲要： 1 简介 1.1 编写目的 1.2 项目背景 1.3 术语和缩略词 1.4 参考资料 2 目标及范围 2.1 测试目的及标准 2.2 测试范围 3 测试过程 3.1 测试内容 3.2 测试时间 3.3 测试环境 3.4 测试方法及测试用例设计 4 测试情况分析 4.1 测试概要情况 4.2 测试用例执行情况 4.3 缺陷情况 4.4 测试覆盖率分析 4.5 产品质量情况分析 5 测试总结 5.1 测试资源消耗情况 5.2 测试经验总结 6 附件 附件1 测试用例清单 附件2 缺陷清单 缺陷类型分布报告 缺陷类型分布报告主要描述缺陷的类型分布情况，看缺陷主要是哪些类型的错误，这些信息有助于引起开发人员的注意，并分析为什么集中在这种类型。例如，如果缺陷主要是界面类型的，例如界面提示信息不规范、界面布局凌乱等问题，那么就要讨论看是否需要制定相应的界面规范，让开发人员遵循，从而防止类似问题的出现。 缺陷类型分布报告一般用饼图或柱形图画出。如图所示，用饼图表示几种类型的缺陷各占了多少百分比。 缺陷分布报告 缺陷区域分布报告 缺陷区域分布报告主要描述缺陷在不同功能模块出现的情况，这些信息有助于开发人员分析为什么缺陷集中出现在某个功能模块，例如，如果缺陷主要集中在单据的审批过程，那么就要分析是否是审批流程调用的工作流接口设计不合理。 缺陷区域分布报告一般使用饼图或柱形图表示，如图所示，用柱形图表示缺陷分布在不同的功能模块的个数。 缺陷区域分布报告 缺陷状态分布报告 缺陷状态分布报告主要描述缺陷的各种状态的比例情况，例如Open、Fixed、Closed、Reopen、Rejected、Delay的Bug分别占了百分之多少。这些信息有助于评估测试和产品的现状。  如果Open的Bug比例过高，则可能要考虑让开发人员先停止开发新功能，先集中精力修改Bug。  如果Fixed状态的Bug很多，则要考虑让测试人员先停止测试新功能，先集中精力做一次回归测试把修改的Bug验证完。  如果Closed的Bug居多，则可能意味着功能模块趋于稳定。  如果Reopen的Bug比较多，则需要分析开发人员的开发状态，是什么原因造成缺陷修改不彻底。  如果Rejected的Bug比例过高，则要看开发人员与测试人员是否对需求存在理解上的分歧。  如果Delay的Bug比例过高，则要考虑这个版本是否满足用户的要求，是否缺少了太多应该在这个版本出现的功能特性。 缺陷状态分布报告一般使用饼图或柱形图表示，如图所示，用饼图表示各种状态的缺陷个数以及所占的百分比。 缺陷状态分布报告 注意：还有其他的缺陷分类报告可以写到测试报告中，例如：严重级别分类报告、优先级别分类报告、负责人分类报告、发现人分类报告、版本分类报告等。但是要注意用这些分类报告来说明问题，而不要用来指责别人，例如使用负责人分类报告来嘲笑某个开发人员是“Bug大王”。 缺陷趋势报告 缺陷趋势报告主要描述一段时间内的缺陷情况，如果项目管理比较规范，缺陷管理和测试流程比较正常的话，从缺陷趋势报告还可以估算出软件可发布的日期。 例如，下图的缺陷趋势图，表示在2001年9月3号到2001年9月24号之间的Bug状态变化。 缺陷趋势图 从图中可以看出，Open状态的Bug在不断地增加，Fixed状态的Bug在2001年9月16号后开始骤然下降，有可能是这段时间开发人员在几种开发新的功能，忽略了Bug的修改工作。 发现并录入Bug，与修改并关闭Bug是一对互相对冲的两个变量，软件产品就是在这样的此消彼涨的过程中不断完善和改进质量的。有经验的项目经理和测试人员会非常关注这样的发展曲线，从而判断项目产品的质量状态和发展趋势。笔者曾经在某个项目中与一位项目经理在项目的待发布阶段每天都在观察缺陷趋势图，这位项目经理甚至把它笑称为软件产品的“股市”技术图。 但是确实能从这些图中看出一个产品的质量趋势，如果项目管理得比较规范的话，甚至可以从这些图的某些关键点推算出可发布版本的日期。在微软的项目管理中，把这种关键点称为零Bug反弹点。例如，下图中就有几个零Bug反弹点（用圆圈圈住的地方）。 图7.34 零Bug反弹 项目在第一次达到零缺陷，即所有Bug（或者大部分Bug）都基本处理掉了，没有发现新的Bug时，还不能就马上发布版本。因为Bug会反弹，由于缺陷的“隐蔽特性”和“免疫特性”，第一个零缺陷点是一个质量安全的假象，测试人员很快就会在新版本中发现更多的Bug，有些项目甚至要到了第三个或第四个零Bug点才能安全地发布。这取决于项目的实际控制方式。 典型缺陷与Bug模式 软件开发有设计模式，测试其实也有模式存在，需要测试人员进行总结和归纳。从经常重复出现的Bug中学习，总结出Bug模式，用于指导测试，如果开发人员能关注这些Bug模式，还能起到预防错误的效果。 要成为典型缺陷，必须满足以下条件：  重复出现、经常出现。  能代表某种类型的错误。  能通过相对固定的测试方法或手段来发现这些错误。 总结这些典型缺陷出现的现象，出现的原因，以及测试的方法，就成为一个Bug模式。 说明：Bug模式根据不同的开发平台、开发工具、开发语言、产品类型、采用的架构等，可以总结出不同的模式，某种模式可能在某些平台、语言、产品类型才会出现。测试人员应该总结适合自己项目产品特点的Bug模式。 提炼Bug模式的一般步骤如下： （1）分析缺陷报告，找出经常出现的Bug类型。 （2）分析Bug的根源，找出Bug产生的深层次原因。 （3）分析找到Bug的方法，总结如何才能每次都发现这种类型的Bug。 下面举一个例子来说明这个过程。 首先，测试人员在分析缺陷报告时发现，有一类Bug经常出现，并且错误现象一致：执行某功能时提示Time Out。 测试人员跟程序员一起分析原因，发现这些错误都是发生在操作数据库时，发送的SQL语句被数据库长时间执行未返回，因此提示Time Out，再进一步的分析表明，.NET的SqlCommand的CommandTimeOut属性是用于获取或设置在终止执行命令的尝试并生成错误之前的等待时间。等待命令执行的时间（以秒为单位）默认为30秒。而数据库操作在较大的数据量的情况下一般都需要超过这个时间，因此会提示超时的错误信息。 这样就可以把这类型的Bug归纳为 数据库操作超时Bug模式 。 那么如何才能找出这样的Bug呢？一般情况下，这类Bug基本上不会出现，只有数据量达到一定的程度才会出现，因此需要设置大批数据，结合性能测试或压力测试来发现此类问题。当然也可以通过白盒的方式，查找程序在使用SqlCommand的时候是否合理地设置了CommandTimeOut的属性，这样更有针对性地揭露上述的错误。 这样就完成了一个Bug模式的归纳、提炼和总结了，如果程序员积极地参与到这个总结和分析的过程中来，则可形成一个良性的反馈，下次程序员在写相同的程序时就会避免类似的错误了。 练习5：编写一份图文并茂的测试报告 15、测试项目管理 包括：流程管理、人员管理、权限管理 定制项目 工具->自定义 16、添加项目组成员、分配角色、设置访问权限 添加新项目组成员 设置项目用户 添加用户 分配用户到指定组 QC默认定义的用户组权限： 17、自定义QC字段和列表 用户自定义字段 自定义项目实体 缺陷->用户字段->新建字段 字段标签：Database 创建列表项 把列表项绑定到指定字段 18、测试项目备份和还原 导出项目 否则： 停用项目 导出项目 TEST.qcp 导入项目 从QC项目文件导入项目 备份项目 1、备份SQLServer数据库 2、如果项目库是存储在文件系统中的，还要通过拷贝方式备份项目库所在目录的文件 恢复项目 1、还原SQLServer数据库 2、如果项目库是存储在文件系统中的，还需要把备份下来的库文件拷贝到QC库的文件夹中。 3、在Site Administrator中，还原项目。 注意：如果备份与还原的库是在不同的文件路径，或者重命名了Schema，那么还需要更新dbid.xml文件的相应内容。 <?xml version="1.0" encoding="UTF-8" ?> - <ProjectDescription> <PROJECT_NAME>MyTest</PROJECT_NAME> <DB_TYPE>2</DB_TYPE> <DESCRIPTION>Created on 2009-04-08 20:45:05</DESCRIPTION> <DB_CONNSTR_FORMAT>jdbc:mercury:sqlserver://192.168.1.12:1433</DB_CONNSTR_FORMAT> <DB_NATIVE_AUTHENTICATION>N</DB_NATIVE_AUTHENTICATION> <DB_NAME>default_mytest_db</DB_NAME> <DBSERVER_NAME>192.168.1.12</DBSERVER_NAME> <DB_USER_PASS>TWO:59-132-191-0-59-132</DB_USER_PASS> <PR_HAS_VCSDB>N</PR_HAS_VCSDB> <PHYSICAL_DIRECTORY>C:\Program Files\Mercury\Quality Center\repository\qc\Default\MyTest\</PHYSICAL_DIRECTORY> <USERS_QUOTA>-1</USERS_QUOTA> <PR_IS_ACTIVE>Y</PR_IS_ACTIVE> <SAQ_IS_ACTIVE>N</SAQ_IS_ACTIVE> <VM_REPOSITORY /> <PR_REPOSITORY_IN_DB>Y</PR_REPOSITORY_IN_DB> <PR_LANGUAGE>English</PR_LANGUAGE> </ProjectDescription> 还原时提示错误： 服务器用户 'td' 不是数据库 'default_mytest_file_db' 中的有效用户。 需要在SQLServer中恢复td用户： exec sp_change_users_login 'Update_One','td','td' 练习6：QC项目自动备份 19、使用Site Admin管理和配置项目 QC项目结构图 把项目数据存储在项目的数据库中 把项目数据存储在文件中 创建空项目 将项目的库存储在数据库中 通过拷贝已有项目创建 通过导入项目文件来创建 20、配置跟踪提醒规则 在SiteAdmin中为项目配置自动发送邮件 为用户设置邮件地址 设置发送邮件间隔 配置AutoMail 设置条件 设置可追溯性通知规则 触发跟踪警告 换一个用户alice_qc登录QC Cruise Booking原本是由alex_qc设计的，当Cruise Booking相关的需求发生改变时，alex_qc将得到通知 修改需求项“Cruise Booking”的优先级为“Urgent” 注销alice_qc，用alex_qc登录 查看可跟踪性警报 工具->跟踪所有更改 清除警报 创建后续提醒 为某个缺陷添加后续标记： 21、定义工作流 脚本生成器 – “缺陷模块”列表自定义 应用并查看： 脚本生成器 – 添加缺陷字段自定义 应用并查看 脚本生成器 – 缺陷详细信息字段自定义 与 脚本生成器 – 添加缺陷字段自定义 基本一样 脚本编辑器 可触发的事件参考《Mercury Quality Center 9.0 Administrator’s Guide》P223：Reference for Quality Center Events 练习7：自定义BUG状态修改规则 Sub Defects_Bug_FieldChange(FieldName) 'added by upgrade process Fields = Bug_Fields '******************************************** 'Sub Bug_FieldChange (FieldName) 'Enter code to be executed after a bug field is changed ' Set lists for version fields ' (Detected In Version, Planned Closing Version and Closed In Version) ' according to the value in Project field If FieldName = "BG_PROJECT" Then SetVersionList ' Set RDComments_IsChanged flag if the R&D Comments field was changed ElseIf FieldName = "BG_DEV_COMMENTS" Then RDComments_IsChanged = True ' Set Status_IsChanged flag if the Status was changed to 'Rejected' or 'Reopen' ElseIf FieldName = "BG_STATUS" Then If Fields("BG_STATUS").Value = "Rejected" Or Fields("BG_STATUS").Value = "Reopen" Then Status_IsChanged = True Else Status_IsChanged = False End If End If 'cnjadd IF FieldName = "BG_STATUS" THEN IF Fields("BG_STATUS").Value = "Rejected" Then Msgbox "请注意填写Rejected的原因。" END IF End IF 'End Sub '******************************************** WizardListCust ' 由向导添加 End Sub