软件测试大全：基础知识.pdf

1 软件测试大全 卷 1：基础知识（第 1 版） 大傻 文档历史 日期 版本号 作者 修订历史 2010-10-18 0.1 大傻 创建 2010-11-24 1.0 大傻 第 1 版发布 前言 软件正进入测试时代，测试同仁我们的明天是光明j。 随着计算机的发展，产品功能越来越庞大，产品业务越来越复杂，用户对产品质量的要 求越来越高。产品质量的提高在做好需求分析，设计分析，编码实现的前提之下，软件测试 也是提高产品质量的重要手段之一。 本书的目的结合作者经验和网络收集的资料，对测试过程，规范，测试方法， 测试工 具，数据库等个个方面进行收集整理。供测试同仁参考学习之用。希望能各位测试工作带来 一定帮助。 整理编写测试大全一书是一项具有强烈挑战的创新工作，难度大，时间紧，加之编 者水平有限，书中难免有疏漏之处 ，敬情各位同事谅解。书中很多内容只能抛砖引玉，需 要大家从其它渠道如书本，网络，交流等获取更详细的内容。 如果有意见和建议请与大傻联系。email：ldjzj ，qq 交流群号：14926562 大傻 2010-11-23 晚上 23 点 17 分 版权声明：本文由 bstt 成员收集整理，只作相互交流学习使用，不能作为任何商业用途，转载时请 务必标识 bstt 统一 logo，并注明 bstt 宗旨（倡导测试开源，分享测试经验） 。 2 目录 1 了解我们 . 3 1.1 bstt . 3 1.2 成员介绍 . 3 2 工作常用 . 3 2.1 常用工具 . 错误！未定义书签。 3 名词解释 . 3 3.1 测试技术 . 3 3.2 测试工具 . 5 3.3 产品业务 . 6 3.4 数据库 . 8 3.5 其它业务 . 8 4 测试知识 . 8 4.1 测试过程 . 8 4.2 测试规范 . 9 4.3 常用测试文档 . 9 4.3.1 测试计划 . 9 4.3.2 测试用例 . 11 4.3.3 测试报告 . 11 4.4 测试技术 . 15 4.4.1 功能测试 . 15 4.4.2 自动化测试 . 19 4.4.3 性能测试 . 20 4.4.4 白盒测试 . 24 4.5 测试工具 . 24 4.5.1 qtp . 24 4.5.2 lr . 25 4.5.3 td . 27 5 数据库 . 28 5.1 常用数据库 . 28 5.2 sqlserver . 30 5.2.1 系统数据库 . 30 5.2.2 备份还原 . 31 5.3 oracle . 33 5.3.1 导入导出 . 33 5.3.2 常用 sql 语句 . 34 6 操作系统 . 35 6.1 windows . 35 6.1.1 dos 命令. 35 6.2 unix . 37 6.2.1 基本命令 . 37 3 1 了解我们 1.1 bstt 我和同事创建一个虚拟测试组织 bstestteam 简称 bstt，重点负责将日常碰到的问题 和解决方案用通俗的文字整理成文档大全， 并让摘入大全的内容都是通过验证和有效的， 并 免费提供大家下载。我们宗旨：倡导测试开源，分享测试经验。 1.2 成员介绍 大号 博客 擅长领域 大傻 测试管理，功能测试，性能测试 mihuxu 功能测试，性能测试，自动化测试 水石心鱼 功能测试，自动化测试 熊熊 功能测试 2 工作常用 51testing 软件测试： csdn 程序员: 3 名词解释 3.1 测试技术 software test（软件测试） ：执行软件以验证其满足指定的需求并检测错误的过程。 检测已有条件之间的不同， 并评价软件项的特性软件项的分析过程。 软件工程过程的一个活 动，它将软件在预定的条件下运行以判断软件是否符合预期结果。 black box testing（黑盒测试） ：指测试人员不关心程序具体如何实现的一种测试方 法。 根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测 试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。 white box testing（白盒测试） ：根据软件内部的工作原理分析来进行测试,基于代码 的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质 量，一般白盒测试由项目经理在程序员开发中来实现。 unit testing（单元测试） ：指一段代码的基本测试，其实际大小是未定的，通常是一 个函数或子程序，一般由开发者执行。 integration testing（集成测试） ：被测试系统的所有组件都集成在一起，找出被测试 系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。 system testing（系统测试） ：是将已经集成好的软件系统，作为整个计算机系统的一 个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在 实际运行使用的环境下，对计算机系统进行系列的测试活动 acceptance testing（验收测试） ：系统开发生命周期方法论的一个阶段，这时相关 4 的用户和或独立测试人员根据测试计划和结果对系统进行测试和接收。 它让系统用户决定 是否接收系统。 它是一项确定产品是否能够满足合同或用户所规定需求的测试。 这是管理性 和防御性控制。 automated testing（自动化测试） ：使用自动化测试工具来进行测试，这类测试一 般不需要人干预，通常在 gui、性能等测试中用得较多。 functional testing (功能测试)：也称为 behavoral testing（行为测试） ，根据产品 特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。 本地化软件的功能测试， 用于验证应用程序或网站对目标用户能正确工作。 使用适当的平台、 浏览器和测试脚本， 以保证目标用户的体验将足够好， 就像应用程序是专门为该市场开发的 一样。 load testing（负载测试） ：通过测试系统在资源超负荷情况下的表现，以发现设计上 的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和 评估测试对象在不同工作量条件下的性能行为， 以及持续正常运行的能力。 负载测试的目标 是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。 此外， 负载测试还要评估 性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。 performance testing （性能测试） ： 评价一个产品或组件与性能需求是否符合的测试。 包括负载测试、强度测试、数据库容量测试、基准测试等类型。 stability test（稳定性测试） ：测试系统的长期稳定运行能力。在系统运行过程中，对 系统施压，观察系统的各种性能指标，以及服务器的指标。 stress test（压力测试，也即强度测试） ：在强负载（大数据量、大量并发用户等）下 的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、 系统是否具有良好的容错能力和可恢复能力。 compatibility testing （兼容性测试） ： 也称“configuration testing （配置测试） ”， 测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验 证测试对象在不同的软件和硬件配置中的运行情况。 usability testing（易用性测试） ：针对应用程序和用户手册等系统文档的测试。主要 包括易理解性测试；易学性测试；易操作性测试；吸引性测试；易用的依从性测试。 installing testing（安装测试） ：确保该软件在正常情况和异常情况的不同条件下，例 如，进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不 足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码 以及安装手册。 安装手册提供如何进行安装， 安装代码提供安装一些程序能够运行的基础数 据。 adhoc testing (随机测试)：没有书面测试用例、记录期望结果、检查列表、脚本或 指令的测试。 主要是根据测试者的经验对软件进行功能和性能抽查。 随机测试是根据测试说 明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 smoke testing（冒烟测试） ：冒烟测试的对象是每一个新编译的需要正式测试的软件 版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是 版本编译人员。参考“sanity testing（健全测试）”。 5 regression testing（回归测试） ：在发生修改之后重新测试先前的测试以保证修改的 正确性。理论上，对软件的任何新版本，都需要进行回归测试，验证以前发现和修复的错误 是否在新软件版本上再现。 bug (错误)：有时称作 defect（缺陷）或 error（错误） ，软件程序中存在的编程错误， 可能会带来不必要的副作用，软件的功能和特性与设计规格说明书或用户需求不一致的方 面。软件缺陷表现特征为：软件未达到产品说明书标明的功能；软件出现产品说明书指明不 会出现的错误； 软件功能超出产品说明书指明的范围； 虽然产品说明书未指出但是软件应达 到的目标； 软件测试人员或用户认为软件难以理解， 不易使用， 运行速度缓慢等问题。 bug report（错误报告） ，也称为“bug record（错误记录）”，记录发现的软件错误信息的文 档，通常包括错误描述、复现步骤、抓取的错误图像和注释等。 priority（优先权） ：从商业角度出发是指错误的重要性，尤其是从客户和用户的角度 出发，是指错误对于系统的可行性和可接受性的影响。与“severity（严重性）”相对照。 severity（严重性） ：错误对被测系统的影响程度，在终端用户条件下发生的可能性， 软件错误妨碍系统使用的程度。 test case（测试用例） ：为特定目标而开发的一组测试输入、执行条件和预期结果，其 目标可以是测试某个程序路径或核实是否满足某个特定的需求。 testing coverage（测试覆盖） ：指测试系统覆盖被测试系统的程度，一项给定测试或 一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。 testing environment （测试环境） ：进行测试的环境，包括测试平台、 测试基础设施、 测试实验室和其他设施。 testing item（测试项） ：作为测试对象的工作版本。 testing plan（测试计划） ：描述了要进行的测试活动的范围、方法、资源和进度的文 档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。 test report(测试报告)：把测试的过程和结果写成文档，并对发现的问题和缺陷进行 分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。 testing procedure（测试过程） ：指设置、执行给定测试用例并对测试结果进行评估 的一系列详细步骤。 testing scrpt（测试脚本） ：一般指的是一个特定测试的一系列指令，这些指令可以 被自动化测试工具执行。 testing suite（测试包） ：一组测试用里的执行框架；一种组织测试用例的方法。在测 试包里，测试用例可以组合起来创造出独特的测试条件。 3.2 测试工具 loadrunner：mercury 公司性能与负载压力，loadrunner 是一种预测系统行为和 性能的工业标准级负载测试工具。 通过以模拟上千万用户实施并发负载及实时性能监测的方 式来确认和查找问题，loadrunner 能够对整个企业架构进行测试。通过使用 loadrunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。 loadrunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化 系统性能。loadrunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为 6 和实行实时性能监测， 来帮助您更快的查找和发现问题。 此外， 还能支持广泛的协议和技术， 为您的特殊环境提供特殊的解决方案。 quicktest pro：mercury 公司功能测试和回归测试，qtp 是一个 b/s 系统的自动化 功能测试的利器,软件程序测试工具。mercury 的自动化功能测试软件 quicktest professional ，可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的 特点。mercury quicktest pro 是一款先进的自动化测试解决方案，用于创建功能和回归 测试。它自动捕获、验证和重放用户的交互行为。 mercury quicktest pro 为每一个重要 软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。 testdirector：mercury 公司测试管理，基于 web 的测试管理工具，他能够让你系统 地控制整个测试过程， 并创建整个测试工作流的框架和基础， 使整个测试管理过程变得更为 简单和有组织。 他能够帮助你维护一个测试工程数据库， 并且能够覆盖你的应用程序功能性 的各个方面。t 并且还为你提供了直观和有效的方式来计划和执行测试集、收集测试结果并 分析数据。还专门提供了一个完善的缺陷跟踪系统。并可以同 mercury 公司的测试工具、 第三方或者自主开发的测试工具、需求和配置管理工具、建模工具的整合功能。你可以通过 他进行需求定义、测试计划、测试执行和缺陷跟踪，即整个测试过程的各个阶段。 jmeter：开源组织压力测试, 性能测试，它最初被设计用于 web 应用测试但后来扩展 到其他测试领域。apache jmeter 可以用于对静态的和动态的资源（文件，servlet，perl 脚本，java 对象，数据库和查询，ftp 服务器等等）的性能进行测试。它可以用于对服务 器，网络 或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你 可以 使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。apache jmeter 的特性包括：能够对 http 和 ftp 服务器进行压力和性能测试， 也可以对任何数 据库进行同样的测试（通过 jdbc） 。 完全的可移植性和 100 纯 java。 完全 swing 和 轻量组件支持（预编译的 jar 使用 javax.swing.*)包。 完全多线程 框架允许通过多个线 程并发取样和 通过单独的线程组对不同的功能同时取样。 精心的 gui 设计允许快速操作 和更精确的计时。 缓存和离线分析/回放测试结果。 高可扩展性： 可链接的取样器允许无 限制的测试能力。 各种负载统计表和可链接的计时器可供选择。 数据分析和可视化插件提 供了很好的可扩展性以及 以及个性化。 具有提供动态输入到测试的功能（包括 javascript） 。 支持脚本变成的取样器（在 1.9.2 及以上版本支持 beanshell） 。 junit：开源组织单元测试，回归测试，junit 是由 erich gamma 和 kent beck 编 写的一个单元测试框架（regression testing framework） 。junit 测试是程序员测试，即所 谓白盒测试，因为程序员知道被测试的软件如何（how）完成功能和完成什么样（what） 的功能。junit 是一套框架，继承 testcase 类，就可以用 junit 进行自动测试了。 jsunit： 开源组织单元测试， 回归测试， jsunit 是一个部件测试的结构为客户机边 java 语言在 xunit 结构的传统。 jsunit is a unit testing framework for client-side javascript in the tradition of the xunit frameworks. 3.3 产品业务 创业门户应用平台（bseap （b-soft enterprise application portal） ） ：企业门 户应用平台是企业内外部数据和信息资源的整合和发布工具， 是企业应用系统的集成平台和 7 单一访问入口，是基于商务协作的企业级应用的运行平台和开发管理工具。 hospital information system （his 即医院信息系统） ：美国该领域的著名教授 morris.collen 曾作如下定义：利用电子计算机和通讯设备，为医院所属各部门提供对病人 诊疗信息和行政管理信息的收集、存储、处理、提取及数据交换的能力，并满足所有授权用 户的功能需求。 laboratory information management system（lis 即实验信息系统） ：是专为医 院检验科设计的一套实验室信息管理系统， 能将实验仪器与计算机组成网络， 使病人样品登 录、实验数据存取、报告审核、打印分发，实验数据统计分析等繁杂的操作过程实现了智能 化、自动化和规范化管理。有助于提高实验室的整体管理水平，减少漏洞，提高检验质量。 electronic medical record（emr 即电子病历） ： 也叫计算机化的病案系统或称基于 计算机的病人记录（cpr,computer-based patient record） 。它是用电子设备（计算机、 健康卡等）保存、管理、传输和重现的数字化的病人的医疗记录，取代手写纸张病历。它的 内容包括纸张病历的所有信息。美国国立医学研究所将定义为：emr 是基于一个特定系统 的电子化病人记录， 该系统提供用户访问完整准确的数据、警示、提示和临床决策支持系 统的能力。 medical record quality control（(病历书写质量控制 mrqc)） ：对病历书写过程 及内容进行质控。 通过建立一套完整严密的消息反馈机制实现各临床诊疗工作站与本系统之 间实时互动，包括发送、传递、接收、处理、反馈等环节；本系统以建立病历书写质控标准 为基础， 实现环节质控、 终末质控两大系统功能； 创业各临床工作站系统这里指的架构在“创 业-门户平台” 基础之上的包括住院医生站、手术麻醉系统、病区护士站等系统，与本系统 之间存在内部接口； 外部病案统计管理系统这里指医疗机构已经实施或即将实施的非公司产 品,与本系统之间存在外部接口。环节质控包括“重点病人监控、病历书写时限质控、病历 书写部分内容质控、病历检查整改通知”四块内容；终末质控包括“系统自动扣分、专家手 工评分”两部分内容。 electronic nursing record（临床护理记录书写系统 enr） ：本系统主要是解决“住 院部临床护士的电子化书写护理记录”问题，通过电子化的手段，帮助临床护士及时、高效 的书写护理记录， 这样护士就能把这部分省出来的时间用于更重要的临床服务。 同时在书写 的过程中，加入一些质量控制方法，这样在整个环节过程中，就能自动发现存在的质量问题 并通知护士或管理部门及时采取应对措施。 ward doctors workstation(住院医生站系统 wdw） ： 住院医生工作站是指临床 医生在自己的电脑上实现给病人下诊断、开医嘱、写病历、开各种化验单、查看化验结果等 功能。从而提高工作效率和医疗质量。 radiology information system( ris 即放射信息管理)：是放射科的登记、分诊、 影像诊断报告以及放射科的各项信息查询、统计等工作的管理系统，ris 系统与 pacs 系统 紧密相连，构成医院数字医疗设备、影像及报告管理的解决方案。 clinical pathway（临床路径信息系统 cp） ：临床路径信息系统 指针对某一疾病建立 一套标准化治疗模式与治疗程序， 是一个有关临床治疗的综合模式， 以循证医学证据和指南 为指导来促进治疗组织和疾病管理的方法。 8 picture archiving and communication system（pacs 即影像归档和通信系统） ： pacs 是一个涉及放射医学、影像医学、数字图像技术(采集和处理)、计算机与通讯、c/s 体系结构的多媒体 dbms 系统，涉及软件工程、图形图像的综合及后处理等多种技术，是 一个技术含量高、实践性强的高技术复杂系统。 3.4 数据库 数据库（database） ：是按照数据结构来组织、存储和管理数据的仓库，它产生于距 今五十年前，随着信息技术和市场的发展，特别是二十世纪九十年代以后，数据管理不再仅 仅是存储和管理数据，而转变成用户所需要的各种数据管理的方式。数据库有很多种类型， 从最简单的存储有各种数据的表格到能够进行海量数据存储的大型数据库系统都在各个方 面得到了广泛的应用。 structured query language（结构化查询语句，sql） ：在一个关系数据库中查询和 处理数据的一种语言。 3.5 其它业务 review（评审） ：在产品开发过程中，把产品提交给项目成员、用户、管理者或其它 相关人员评价或批准的过程。 quality assurance（质量保证 qa） ：采取相关活动，以保证一个开发组织交付的产 品满足性能需求和已确立的标准和过程。 software life cycle（软件生命周期） ：开始于一个软件产品的构思，结束于该产品不 再被使用的这段期间。 software configuration management（软件配置管理 scm） ：是指通过执行版本 控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟 踪性。配置管理是对工作成果的一种有效保护。 4 测试知识 4.1 测试过程 请要查看创业知识库（ftp）中 02-过程模板库，重点查看过程模板库下 02-工程过程， 其它过程了解一下，大至工作流程如下： 9 4.2 测试规范 规范名称 说明 文档排版规范 word，excel，viso 等工具使用规范 测试用例书写规范 测试用例编写要求 工作产品检查列表 测试用例，测试报告，用户手册等文档检查项 testdirector 工具使用规范 td 工具使用规范 软件界面规范 测试时界面测试参照的规范 测试收标准 每个阶段测试接收的准则 4.3 常用测试文档 4.3.1 测试计划 包含的内容 1. 项目版本历史： 记录谁什么时候对这个测试计划做了哪些改动。 通常测试计划需要更改 好多遍，这就需要版本信息来跟踪测试计划的状态，是 draft，还是 approved。 2. 编写目的:对测试计划一个简单的介绍，说明这个测试计划的功效以及项目的背景介绍。 3. 术语和缩写词：项目中或测试中一些术语的说明。 4. 参考文档： 很多时候测试计划需要和其他的文档连接起来看， 或者测试计划还有一些子 计划文档，这些文档都需要加到测试计划的参考文档列表里。 5. 测试资源：包括硬件，软件，人力资源。硬件包括如服务器，客户端，网络设备等以及 其它测试需要的如打印机，扫描枪，设备等。软件资源包括测试用使用的工具。人力资 源包括测试资源，以及协助测试的开发人员，数据库管理员，用户等。 10 6. 测试范围：需要测试什么，包括测试类型比如、功能和性能测试，如果是升级产品，哪 些新功能，哪些受新功能影响的功能需要测试，都需要说明。不需要测试什么，如果这 个产品是继承了之前的产品，哪些原来的功能不受新功能的影响，不需要测试。 7. 测试进度：测试的时间安排，什么时候开始什么测试。做这个计划的前提是项目详细计 划已经做好了并通过计划评审。 8. 测试进入：测试进入要求如：代码是否做过走查，是否提安装配置文档，是否通过冒烟 测试。 9. 测试结束：测试结束的标准，如文档是否完整不，缺陷是否得到合理解决，缺陷趋势是 否到达标准点，系统是否已稳定。 10. 测试提交文档：测试提文档，作者和存放位置。 编写要求 1. 是否系统的安全要求以被澄清并做了文档化操作 2. 是否已经明确定以了测试工作的目标（及其范围） 3. 是否标明了所有待测项（及其版本） 4. 是否未列出重要的不测项 5. 是否定以了变动控制过程并标明了那些有权限批准测试范围变动的人 6. 是否标明了所有待测特性 7. 是否未列出重要的不测特性 8. 是否以对测试方法（策略）进行文档化操作 9. 是否以将把系统视为通过的标准（如果有）进行文档化操作 10. 是否以将测试终止（和恢复）的标准（如果有）进行文档化操作 11. 是否以将测试工作要产生的文档进行文档化操作 12. 是否研究过将测试工作所有的环境需要进行文档化操作 13. 是否将待测项的配置管理策略进行文档化操作 14. 是否以将测试脚本和测试数据（测试套件）的配置管理策略进行文档化操作 15. 是否以指派了所有测试工作的责任 16. 是否以指派了所有测试工作所依赖的责任 17. 是否标明了人事需要的来源 18. 是否标明了培训需要的来源 19. 是否创建了测试进度 20. 是否以考虑了项目圆满结束的必须步骤 21. 是否以标明了预计的最严重的风险 22. 是否以设计并通过了预计的最严重的风险的规避风险措施 23. 是否以将所有的问题、假设、约束和依赖进行文档化操作 24. 是否以定义了所有的不常见的简写和术语 25. 是否以标明并互相引用了支持文档 11 26. 是否以标明了负责批准计划的人 27. 是否以标明了负责接收测试结果的人 28. 是否以标明了需要通报测试工作进展的人 4.3.2 测试用例 包含的内容 1. 编号：每个测试用例的唯一编号，有且于其和测试结果、错误报告等其他文档的链接。 2. 测试模块：讲述此测试用例测试的大模块。 3. 标题：用简单的一句话来描述测试用例。 4. 测试目的：描述设计此测试用例的目的是什么。 5. 测试级别：按照测试用例的重要性来给不同的测试用例分级别。 6. 预置条件：执行此测试用例之前需要做的准备。 7. 操作步骤：测试人员执行测试所需的运作。 8. 预期结果：在检查点上待测功能应有的正常反应、运作或显示。 9. 实际结果：待测功能在操作后所表现的反应、运作或显示。 用例编写方法可以参见测试用例编写指南.pdf 编写要求 1、如何保证测试用例的覆盖率； 2、如何确保紧跟开发文档的变化； 3、如何把用例的重复性限定在适度的范围内； 4、如何实现测试用例的更新； 5、如何实现测试用例的重用性； 4.3.3 测试报告 包含的内容 一. 引言 1. 编写目的 本测试报告的具体编写目的，指出预期的读者范围。 实例：本测试报告为 xxx 项目的 测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达 到 xxx 功能目标） 。预期参考人员包括用户、测试人员、 、开发人员、项目管理者、其他质 量管理人员和需要阅读本报告的高层经理。 提示：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品 开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能 够阅读到简单的图表并且能够与其他项目进行同向比较。 此部分可以具体描述为什么类型的 人可参考本报告 xxx 页 xxx 章节，你的报告读者越多，你的工作越容易被人重视，前提是 必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。 2. 项目背景 12 对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从 需求或者招标文件中拷贝即可。 3. 系统简介 如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。 4. 术语和缩写词 列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定 要注明清楚，以便阅读时不会产生歧义。 5. 参考资料 1) 需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。 2) 测试使用的国家标准、行业指标、公司规范和质量手册等等 二. 测试概要 测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简 介。 （其他测试经理和质量人员关注部分） page 6. 测试用例设计 简要介绍测试用例的设计方法。例如：等价类划分、边界值、因果图，以及用这类 方法(3-4 句)。 提示：如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对 你的用例设计有个整体的概念， 顺便说一句， 在这里写上一些非常规的设计方法也是有利的， 至少在没有看到测试结论之前就可以了解到测试经理的设计技术， 重点测试部分一定要保证 有两种以上不同的用例设计方法。 7. 试环境与配置 简要介绍测试环境及其配置。提示：清单如下，如果系统/项目比较大，则用表格方式 列出数据库服务器配置，cpu，内存， 硬盘：可用空间大小，操作系统，应用软件，机器 网络名，局域网地址，应用服务器配置。对于网络设备和要求也可以使用相应的表格，对于 三层架构的，可以根据网络拓扑图，列出相关配置。 8. 测试方法(和工具) 简要介绍测试中采用的方法(和工具)。提示：主要是黑盒测试，测试方法可以写上测试 的重点和采用的测试模式， 这样可以一目了然的知道是否遗漏了重要的测试点和关键块。 工 具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明是自产还是厂商，版本 号多少，在测试报告发布后要避免大多工具的版权问题。 三. 测试结果及缺陷分析 整个测试报告中这是最激动人心的部分，这部分主要汇总各种数据并进行度量，度量包 括对测试过程的度量和能力