敏捷开发测试规范V01.docx

《敏捷开发测试规范V01.docx》由会员分享，可在线阅读，更多相关《敏捷开发测试规范V01.docx（26页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、敏捷开发测试规范V01 灵敏 开发测试规范（试行）2 2012 年 年 9 9 月 版本记录版 本号日期修改人描述V0.1 2012/9 周本文 V0.1书目 1概述. 3 1.1 编写目的 . 3 1.2 读者对象 . 3 1.3 术语定义 . 3 2灵敏测试流程 . 3 2.1 需求验证 . 4 2.2 用例设计 . 4 2.3 用例审核与维护 . 错误! 未定义书签。2.4 测试安排 . 4 2.5 测试实施运行 . 4 2.6 版本限制 . 5 2.7 需求变更 . 6 2.8 迭代末期bug 大扫除 . 6 3灵敏测试方法与策略 . 7 3.1 持续测试、持续反馈 . 7 3.2 单

2、元测试方法策略 . 7 3.3 功能测试方法策略 . 7 3.4 性能测试方法 . 8 3.5 系统测试策略 . 9 3.6 测试驱动研发 . 9 3.7 持续集成测试 . 10 4终端移动互联网测试 . 11 4.1 用户体验测试 . 11 4.2 平台兼容性测试 . 12 4.3 不同网络环境下测试 . 12 4.4 多事务并发测试 . 12 4.5 安装、卸载测试 . 13 5测试工具和环境 . 13 5.1 单元测试工具 . 13 5.2 功能回来测试工具 . 14 5.3 性能测试工具 . 14 5.4 持续集成测试环境 . 14 6测试人员要求 . 14 6.1 人力需求 . 14

3、 6.2 测试人员实力要求 . 14 7附录. 16 1概述 1.1 编写目的ICT 自主开发产品拟采纳灵敏开发模式，为规范 ICT 支撑中心项目灵敏测试流程，明确灵敏开发模式下的术语定义，明确灵敏测试方法与策略，明确移动互联网测试特有的测试内容，确定灵敏开发模式下用到的测试工具以及测试环境，以及初步确定灵敏测试人力需求计算方式与对人员实力要求，特制定本规范。本规范适用于采纳灵敏开发模式下的全部自主开发移动互联网产品。1.2 读者 对象本规范读者对象为软件开发项目管理者、项目经理、测试经理、开发经理、开发组、测试组全部人员。1.3 术语定义 灵敏开发模式下的几种重要角色、产品文档及过程会议术语

4、如表 1-1：术语 中文 说明Product Owner （PO）产品全部者 相当于项目经理、产品经理、产品负责人。产品用户故事编写负责人。Scrum Master （SM）灵敏开发组织者 组织项目灵敏开发，负责协调、沟通、帮助解决团队内部非技术问题。Product Backlog 产品需求 产品待开发的功能项（用户需求）Sprint Backlog 迭代需求 每个迭代需实现的功能项（产品需求细化）User story 用户故事 从用户角度提出的需求 Burndown chart 燃尽图 产品需求、迭代需求完成的进度显示图 Plan Meeting 安排会 迭代安排会，组织探讨下个迭代开发内容

5、，PO需参与讲解产品需求。Standup Meeting 每日立会 每日立会，早上时间，主要探讨每人当天工作内容。Review Meeting 迭代评审会 每个迭代结束时召开，展示迭代成果，听取 PO看法、建议。表 1-12灵敏测试流程2.1 验证需求和设计灵敏测试强调问题暴露越早越好。需求和设计详细来说一般包括：（1）由项目经理依据需求文本而编写的产品用户故事或者是产品软件需求规格说明书；（2）由开发人员依据产品用户故事而编写的迭代用户故事，或者是具体设计、数据库设计、系统方案设计、概要设计（可裁剪，依据开发系统规模确定是否裁剪。）。作为测试人员，审核重点是检查产品用户故事、迭代用户故事对用

6、户需求定义的完整性、严密性和功能设计的可测性。在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思索需求的可实现性，将自身作为第一用户主动参加项目和系统的需求分析，设计和开发。更多的参加 DB Design（数据库设计），框架的评审中来。主动地参加前期工作，尽早的起先测试，并快速反馈给设计和开发其静态测试结果。需求和设计验证产出物:测试须要提交评审结果。2.2 用例设计与审核 开发人员依据产品用户故事、迭代用户故事，设计测试用例，测试人员负责测试用例审核。为保证测试用例的质量和可行性，确保测试工作的顺当进行，让开发人员、测试人员快速地了解测试的重点并给出

7、相应的看法和建议，用例设计人员在出输出测试用例的同时，应出一份用户故事与用例跟踪表（见附件：产品故事-燃尽图跟踪表），其中注明测试用例已覆盖了哪些用户故事，详细每个用户故事对应的测试用例编号，这样其他项目组成员对测试用例进行查看的时候，能够对测试用例的覆盖率一目了然，对覆盖率不足（如某个重点用户故事的测试用例覆盖不够）的地方能够刚好给出看法。测试人员负责用例审核。2.3 测试安排 灵敏测试的测试安排不须要困难的安排文档，写出一页纸的测试安排，将测试要点（包括策略、特定方法、重点范围等）列出来即可，模板见附件。2.4 测试实施运行 灵敏开发模式中，测试与研发紧密结合在一起。测试主要有两种：单元测

8、试和验证/接收测试。单元测试一般是由开发人员来完成的，接收测试是由客户代表来完成。 由于客户通常无法在现场，一般由测试人员做验证测试，最终由客户进行接收测试。在每个版本发布给客户之前必需由测试人员进行测试，发布版本之后由客户做接收测试，提出须要修改的地方。须要修改的地方将在下后面的迭代中完成。 单元测试 在每日构件版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。 做单元测试的好处是可以提高版本质量，减轻测试的工作量，削减浅层次的 bug 的发生率，使测试人员能够将更多的精力投入到找寻深层次的 bug 上面。 验证测试 测试人员的验证测试从总体上说就是将测

9、试用例按安排付诸实施的过程，以及验证故障修复是否会引入新的故障。这一阶段的测试必需在周密的安排下进行。这种安排性首先体现在开发和测试的相互协调协作，依据产品的架构和功能模块的依靠关系，根据项目的总体安排共同推动。从测试的过程来看，测试执行的一起先可以是针对部分用户故事的，之后可以逐步扩展。接着起先采纳迭代的过程完成测试任务，即将测试任务划分为多个周期，一起先可以做些关键的功能性/用户故事测试，可以对代码中的可复用部分（组件，构件）做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最终的几个迭代应当用于完整的回来测试，和关键的性能和稳定性测试。 每日构件版本测试 灵敏开发过程中除每个

10、迭代中持续集成版本以外，还会有每日构件版本，每日构件版本测试用以验证前天修复的故障，以及测试故障修复是否会引入新的故障。2.6 版本 限制灵敏开发强调快速开发，持续集成。版本包括每日构件版本、持续集成版本、验收测试版本三种类型。1）版本号约定 每日构件版本号约定：PXXV0.0.0D0823 (D 后面是日期) 持续集成测试版本号约定：PXXV0.1.0B01（从 B01 起先递增）验收测试版本号约定：PXXV1.0.0B01（从 B01 起先递增）说明：PXX 为项目名，V0.0.0 为每日构件版本，V0.1.0 为集成阶段，V1.0.0 为系统测试阶段。2）版本发布规则 每日构件版本。每日

11、发布每日构件版本，用于验证当天解决的故障，验证故障修改是否会引入新的故障。持续集成测试版本。每个迭代周期发布一个持续集成测试版本，如迭代周期为二周的，每个迭代周期可发布二个版本，由项目经理、测试经理协商确定。验收测试版本。项目开发后期迭代发布验收测试版本，每个迭代发布一个验收测试版本（项目经理和测试经理协商确定）。3）版本发布说明 版本每次发布必需供应发布说明（Release Note）使客户对发布的版本状况一目了然。Release Note 中主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比

12、较大的 bug；New Features 部分写明此版本新增加了哪些功能；Known Problems 部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复看法，在下个版本中完成。2.7 需求变更采纳灵敏开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是非常必要和重要的工作。整个项目进行过程中，对不断改变的需求，肯定要作跟踪，每次的需求变更都要有相应的历史记录，便利后期的管理和维护工作。可将每次的变更整理记录到产品故事-燃尽图跟踪表（见附件），并使该文档始终保持最新更新的状态，与需求的改变保持同步。同时更新项目管理系统上面的产品用户

13、故事与测试用例。2.8 迭代末期bug 大扫除 在项目开发的迭代末期，可以开展bug 大扫除活动。划出一个特地的时间段，在这期间全部参加项目的人员，集中全部精力，搜寻项目的 Bug。留意以下要点：（1）尽管这是一个测试活动，但参加者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参与，犹如全民动员。目的是要集思广益；（2）要激励各部门，领域交叉搜寻，因为新的思路和视角通常有助于发觉更多的 Bug；（3）为调动主动性，增加趣味性，可以适当引入竞争机制，比如当活动结束时，评动身现 Bug 最多，发觉最严峻 Bug 的个人，给以物质和精神嘉奖。（4）可以分专题绽开，比如平安性、用户界面可

14、用性、国际化和本地化等等。 3灵敏测试方法与策略 3.1 持续测试、持续反馈 灵敏测试是持续测试、持续反馈的过程，测试人员扮演用户代表角色，确保产品满意客户的需求。测试报表，测试日志都能刚好得到反馈。3.2 单元 测试 方法策略 单元测试是对功能模块进行正确检验的测试工作，也是后续测试的基础。目的是在于发觉各模块内部可能存在的各种差错，因此须要从程序的内部结构动身设计测试用例，着重考虑以下五个方面：1）模块接口：对所测模块的数据流进行测试。2）局部数据结构：检查不正确或不一样的数据类型说明、运用尚未附值或尚未初始化的变量、错误的初始值或缺省值。3）路径：虽然不行能做到穷举测试，但要设计测试用例

15、查找由于不正确的计算（包括算法错、表达式符号表示不正确、运算精度不够等）、不正确的比较或不正常的限制流（包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不行能的循环终止条件等）而导致的错误。4）错误处理：检查模块有没有对预见错误的条件设计比较完善的错误处理功能，保证其逻辑上的正确性。5）边界：留意设计数据流、限制流中刚好等于、大于或小于确定的比较值的用例。单元测试除代码走查外，灵敏团队成员要能娴熟单元测试工具开展单元测试，确保代码质量。 3.3 功能测试 方法策略功能测试的目标主要包括： 是否有遗漏需求； 是否正确的实现全部功能/用户故事； 隐示需求在系统是否实现； 输入、输出是

16、否正确； 移动互联网应用的功能测试侧重于全部可干脆追踪到用例（用户故事）、业务功能和业务规则的测试需求，这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。功能测试基于黑盒技术，通过图形用户界面（GUI）与应用程序进行交互，并对交到的输出或结果进行分析，以此来核实好用程序及其内部进程正确与否。灵敏模式下的功能测试方法策略：已经实现功能的自动化测试。对前期迭代中已经实现的功能，采纳工具进行自动化测试，即功能回来自动化测试。新实现功能的手工测试。主要验证用户故事是否正的确现，与用例是否相符。新实现功能的探究性测试。针对新实现的功能，除验证用户故事是否实现以外，还须要拓展

17、测试内容。测试系统是否会有其他意想不到的异样或者缺陷。探究性测试说明：探究性测试是一种测试风格，不是详细的某种测试技术，强调个人自由与职责，将测试相关学习、测试设计、测试执行与结果分析三者相互支持和并行执行。3.4 性能测试方法 性能测试一般包括负载测试、强度测试/压力测试、稳定性测试/牢靠性。负载测试是在肯定的硬件、软件及网络环境下，通过模拟不同的用户，执行一种或多种业务，视察系统在不同负载下的性能表现。在这种测试中，将使测试对象担当不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的实力。负载测试的目标是确定并确保系统在走出最大预期工作量的状况下仍能正常运行。

18、此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。强度测试是性能测试一种，实施和执行此类测试的目的是找出因资源不足或资源急用而导致的错误。如内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。稳定性测试评价系统在肯定负荷状况下，长时间的运行状况。在肯定的软硬件及网络环境中，通过模拟大量的用户执行多种业务处理大量数据，使系统在极限环境下长时间运行，目的在于找寻系统的失效点。性能测试一般在系统版本稳定后即可开展。移动互联网产品的性

19、能测试，可借助以下测试工具：LoadRunner，Monkey 工具。3.5 系统测试策略 灵敏开发模式下的系统测试也就是迭代末期的bug 大扫除，这种测试是由项目团队内部开展，系统测试目的是在于验证软件的功能和性能及其他特性是否与用户的要求一样，主要包括类型的测试：1）用户界面测试：测试用户界面是否具有导航性、美观性、行业或公司的规范性、是否满意设计中要求的执行功能。2）性能测试：测试相应时间、事务处理效率和其他时间敏感的问题。3）强度测试：测试资源（内存、硬盘）敏感的问题。4）容量测试：测试大量数据对系统的影响。5）容错测试：测试软件系统克服软件、硬件故障的实力。6）平安性测试：测试软件系

20、统对非法侵入的防范实力。7）配置测试：测试在不同网络、服务器、工作站的不同软硬件配置条件下，软件系统的质量。9) 安装测试：确保软件系统在全部可能状况下的安装效果和一旦安装之后必需保证正确运行的质量。3.6 测试驱动研发 测试驱动开发（英文全称 Test-Driven Development，简称 TDD），以用户故事为基准，包括产品用户故事与迭代用户故事，驱动研发逐步实现全部产品用户故事以及每个迭代中的用户故事。它要求在编写某个功能的代码之前先编写根据用户故障编写出测试用例，然后通过测试用例验证来推动整个开发的进行。测试驱动研发总体分为二大步：1测试用例设计。开发、测试人员从设计文档、用户故

21、事着手，参考客户需求看看用户故事是否已经覆盖客户的要求，对有疑问的地方与文档设计人员、PO 沟通清晰。当搞清晰整个设计思路以及全部用户故事以后，再来进行测试用例设计。测试用例设计由开发人员完成，测试人员审核。测试用例需共享给项目组其他成员，因为其他成员开发的时候须要参照到这些测试用例，避开出现未考虑到的地方。2测试用例执行。当某个用户故事开发完成后，测试人员起先测试，验证用户故事是否实现，是否满意用例预期结果。测试前或者测试中，测试人员刚好与开发需随时进行探讨，探讨这个用户故事测试覆盖点。之前测试用例已经写完了，但是这个测试用例是基于原有设计用户故事的，实际的功能怎么样子，并不特别清晰。而现在

22、实际功能做出来了，对于一个测试人员而言，就能得到基本的测试点。而探讨的目的就是尽可能全的把测试点覆盖全。开发依据探讨结果，更新测试用例，测试人员审核通过后作为后期测试验收用户故事的依据。3.7 持续集成测试 持续集成测试是指开发团队中的每个成员都尽量频繁地把他们所做的工作更改合入到源码库中，并且还要验证新合入的改变没有造成任何破坏。这里的源码库指的是版本限制工具（比如：CVS 或者 SVN）管理的软件源代码储存地。这里的频繁程度和团队所开发的软件类型有关，但是一般来说频度应当不大于 1 个小时。 实现持续集成测试的几部分的工作：1、将全部的源代码保存在单一的地点，让全部人都能从这里获得最新的源

23、代码（以及以前的版本）； 2、支持自动化创建脚本，使创建过程完全自动化，让任何人都可以只输入一条吩咐就完成系统的创建；3、测试完全自动化，要求开发人员供应自测试的代码，让任何人都可以只输入一条吩咐就运行一套完整的系统测试； 4、确保全部人都可以得到最新、最好的可执行文件。 持续集成测试最基本的优点就是：它完全避开了开发者们的除虫会议-以前开发者们常常须要开这样的会，因为某个人在工作的时候踩进了别人的领域、影响了别人的代码，而被影响的人还不知道发生了什么，于是 bug 就出现了。这种 bug 是最难查的，因为问题不是出在某一个人的领域里，而是出在两个人的沟通上面。随着时间的推移，问题会渐渐恶化。

24、通常，在集成阶段出现的 bug 早在几周甚至几个月之前就已经存在了。结果，开发者须要在集成阶段耗费大量的时间和精力来找寻这些 bug 的根源。假如运用持续集成测试，这样的 bug 绝大多数都可以在引入的同一天就被发觉。而且，由于一天之中发生变动的部分并不多，所以可以很快找到出错的位置。假如找不到 bug 原委在哪里，你也可以不把这些错误的代码集成到产品中去。即使在最坏的状况下，你也只是不添加引起 bug 的特性而已。所以，持续集成可以削减集成阶段捉虫消耗的时间，从而最终提高生产力。4移动互联网终端测试4.1 用户体验测试移动互联网终端应用用户体验测试从视、听、触、反应速度、可用性、易用性几个方

25、面动身，来测试终端应用的用户体验。视是指应用界面 UI 布局是否合理、视效是否美观、颜色搭配是否协调、不同辨别率下是否可以正常运行。听是针对具有音频播放功能的应用，应用运用的各种音频听起来感觉是否悦耳、使人安逸，有没有杂音、电流音、刺耳的高音等。触是指应用的运用触感，与终端屏幕、键盘有肯定相关性。应用中的各种窗口控件、对话框触击运用时触感是否运用愉悦。反应速度是指终端应用运用过程中，点击某个功能按钮、菜单后，应用的反应速度有多快，是否满意用户运用习惯。通常一个操作反应时间超过 2 秒，用户便能够感知到慢。假如超过 3 秒，简单运用户感到不满。超过 4 秒，用户则不情愿接受。可用性测试是指终端应

26、用功能是否可用，有无缺陷。除基本功能实现以外，是否有其他明显影响运用的缺陷，是否满意正常操作习惯。用户体验易用性测试主要是检测用户在理解和运用系统方面究竟有多好，是否存在障碍或难以理解的部分。用户体验易用性的测试方法，一般是通过用户访谈，或邀请内测、小范围公测等方式进行，通过不同试验组的运营结果来推断是否存在易用性缺陷。留意用户体验易用性测试由于缺乏有效的测试工具，必需大量的测试样本才能获得比较真实的测试数据，投入资源较多，测试周期较长。4.2 平台兼容性 测试 兼容性测试是核实测试对象在不同的软件系统、硬件配置中的运行状况，测试系统在各种软硬件配置，不同的参数配置下系统具有的功能、功耗、性能

27、和用户体验。移动互联网终端应用的兼容性测试包含内容：操作的兼容性：覆盖智能机三个主流操作系统，iOS, Android 和 Windows Mobile。硬件兼容性：不同辨别率下的兼容性测试。4.3 不同网络环境下 测试 验证不同网络环境下，终端应用功能与性能方面是否正常(数据业务是否会中断，业务模块是否出现异样)。网络环境包含：3G 强信号 3G 中强信号 2G 强信号 2G 中强信号4.4 多事务并发 测试 移动互联网终端应用有自身的特别性，终端上支持的应用许多，很多应用事务会并发产生（同一时间产生或者某一应用运用过程并发其他应用事务）。终端应用运用过程通常会有以下一些并发事务：短信并发

28、彩信并发 来电并发 闹钟、日程并发 蓝牙事务并发 传感器事务并发 其他第三方应用事务并发（如天气预报） 4.5 安装、卸载测试 安装测试验证应用程序安装包/APK 安装包能否胜利安装到移动终端上，以及安装后能否正常打开运用。卸载测试验证已经安装的应用程序/APK 包是否能胜利地卸载。Android 终端应用程序安装、卸载测试可借助 MonkeyRunner 工具来开展。4.6 平安性、接口测试 平安性测试侧重于平安性的两个关键方面：1应用程序级别的平安性，包括对数据或业务功能的访问。应用程序级别的平安性可确保：在预期的平安性状况下，不同权限用户只能访问特定的功能或用例，或者只能访问有限的数据。

29、例如，可能会允许全部人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。假如具有数据级别的平安性，测试就可确保用户类型一 能够看到全部客户消息（包括财务数据），而用户二只能望见同一客户的统计数据。2. 系统级别的平安性，包括对系统的登录或远程访问。系统级别的平安性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。接口测试指测试应用与终端本地其他应用的接口，主要测试接口功能是否实现，是否会引起本地其他应用异样。本地其他应用主要包括：音频模块，视频模块，蓝牙模块，联系人，短信，彩信，通话记录等。5测试工具和环境 5.1 单元测试工具 工具名称：Junit（ja

30、va），Qunit(JSP)，Visual Unit(C/C+)。适用测试类型：单元编码完成输出物：单元测试报告5.2 功能回来测试工具 工具名称：QTP，MonkeyRunner。适用测试类型：稳定模块功能回来测试，适用每日构件版本，持续集成版本。输出物：测试报告 5.3 性能 测试 工具 工具名称：LoadRunner，Monkey 适用测试类型：迭代持续集成版本（选择性执行），最终验收版本。输出物：测试报告 5.4 持续集成 测试 环境 工具名称：CruiseControl，Eclipse，SVN，Junit （依据项目特点，可选择其他持续集成工具）适用测试类型：每个迭代持续集成版本，每

31、日构件版本，最终验收版本。输出物：测试报告6测试 人员要求 6.1 人力需求依据 ICT 自主研发产品的特点及目前现状，采纳灵敏开发模式，开发人员与测试人员总体根据 1.5 ：1 的比例，来配置测试人。配置比例计算如下：一个典型的灵敏开发团队人员共 7 人：PO 1 人，Scrum Master 1 人，开发人员 3 人，测试人员 2 人。其中测试开发人员 1 名，主要工作内容包括单元测试，负责单元测试及帮助研发修改单元测试发觉的故障，测试工具开发、测试用例设计以及测试环境搭建。工具运用、测试执行人员 1 名。备注：采纳灵敏开发模式，测试与研发是紧密结合的一个团队，无界限划分，测试与研发有时可

32、以相互调换、替补。测试人员行政管理上面属于测试团队。6.2 测试 人员实力要求 灵敏测试对测试人员实力要求特别高。要有很强的编码功底，丰富的项目阅历与编码阅历，开发过程中既能帮助开发人员发觉故障，又能帮助开发人员修复故障，甚至替补开发人员修改故障。1）测试开发人员实力要求 驾驭常的用例设计方法，如等价类划分，边界值分析，错误推想法，场景设计方发等。有 2 年以上的测试阅历，2 年以上用例设计阅历。熟识至少一种数据库基本操作。有 2 年以上 Java/C+/网页编码阅历，测试工具开发阅历，驾驭一种以上单元测试工具，能娴熟搭建持续集成测试环境。2）执行人员实力要求 有 1 年以上 Java 开发阅

33、历，熟识主流开发工具，2 年以上测试阅历，有用例设计阅历。熟识数据库基本操作。娴熟运用常用的功能回来、性能测试自动化工具，如 QTP，LoadRunner，Monkey 等。熟识项目应用程序工作流程，有移动互联网产品测试阅历。 7附录 灵敏开发测试项目输出物模板及工具运用说明。产品故事-燃尽图跟踪表：产品故事-燃尽图跟踪表_V0.2.xlsx测试用例设计与执行模板： 测试安排模板： 测试报告（节点版本测试报告，迭代周期最终一个迭代结束时的版本报告）： 测试报告（每个迭代完成时的测试报告）： 工具简介及运用方法：Junit（Java）：Qunit(JSP) ： Visual Unit(C/C+)：LoadRunner 工具 ： QTP 工具：CruiseControl：CruiseControl运用说明.docMonkey 工具：Monkey运用说明.docMonkeyRunner 工具: MonkeyRunner运用说明.doc