软件测试基础培训

软件测试基础培训刘陆豹---2016.6.10>>>湛腾科技

软件测试基本介绍

软件测试流程讲解

优秀软件测试工程师的成长之路目录1.

软件测试基本介绍湛腾科技第一章节介绍目录软件测试的背景什么是软件测试软件测试的对象软件测试的目的软件测试的原则软件测试的分类软件测试的背景（1）你以前接触过软件测试吗？你认为软件测试人员是做什么的？世界上典型的软件缺陷案例：因特尔公司2000年奔腾III处理器可能导致运行程序被挂起，计算机生产商召回已经交付用户的PC机。1994年因特尔计算机芯片被发现有浮点除法软件缺陷，为此付出超过4亿美元的代价。爱国者导弹防御系统，1991年因一个小的系统时钟错误，导致在多哈袭击战中，系统被拖延100多个小时。在1999年美国航天局火星极地登陆，由于确定何时关闭推进器的程序中某一个数据位被以外修改，飞船在试图登陆火星表面失踪。“7·23”动车事故是由于温州南站信号设备在设计上存在严重缺陷，遭雷击发生故障后，导致本应显示为红灯的区间信号机错误显示为绿灯，进而造成重大人员财产损失。软件测试的背景（2）什么是软件缺陷？为什么会出现软件缺陷？软件未达到产品设计规范表明的功能；软件出现了产品设计规范指明不会出现的错误；软件功能超出产品设计规范指明的范围；软件未达到产品设计规范虽未指出但应达到的目标；软件测试人员认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。由上面的总结，可以将软件缺陷简单划分为：UI缺陷、语言质量缺陷（lqa）、功能缺陷、流程缺陷、接口缺陷、验证缺陷、规范缺陷、易用性缺陷（人机交互）等。

软件测试(英语：softwaretesting)，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程，换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。

软件测试有许多方法，但对复杂的产品运行有效测试不仅仅是研究过程，更是创造并严格遵守某些呆板步骤的大事。测试的其中一个定义：为了评估而质疑产品的过程;这里的

“质疑”是测试员试着对产品做的事，而产品以测试者脚本行为反应作为回答。虽然大部分测试的智力过程不外乎回顾、检查，然而“测试”这个词意味着产品动态分析──让产品流畅运行。程序质量可能，而且通常会，随系统不同而有差异;不过某些公认特性是共通的：可靠性、稳定性、轻便性、易于维护、以及实用性。什么是软件测试软件测试的对象软件测试不等于程序测试，软件测试贯穿于软件定义和开发的整个期间。需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象.12345

用户需求

用户：我要什么？理解正确性表达正确性

需求说明书

需求分析员：我可以提供什么？

设计说明书

设计员：我要软件做什么？

源程序

程序员：我要要

让计算机怎么做？

运行结果

计算机：程序运行得到的结果理解正确性设计正确性表达正确性理解正确性编码正确性运行正确性输入正确性相符合么？软件测试的目的测试的目的就是发现软件中的各种缺陷不能证明软件不存在缺陷，测试只能证明软件存在缺陷而不是彻底消灭，测试可以使软件中缺陷降低到一定程度以确保软件的质量，时间和人力找出软件中的各种错误和缺陷、以较少的用例基于不同的立场，存在着两种完全不同的测试目的：从用户（测试人员）的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。软件测试的原则Good-enough:一种权衡投入/产出比的原则但穷举测试是不可能的，保证测试的覆盖程度所有的测试都应追溯到用户需求测试过程与开发过程应是相结合的，越早测试越好从单元测试到系统测试，测试的规模由小而大应该由独立的第三方来测试，为了尽可能地发现错误不能为了便于测试擅自修改程序既应该测试软件该做什么也应该测试软件不该做什么软件测试的分类（1）按照测试方法分类：黑盒测试是针对软件的功能需求，又称功能测试或数据驱动测试/通过测试来检测每个，实现进行测试不考虑程序内部的逻辑结构，功能是否符合需求.常用方法：功能划分、等价类划分、边界值分析、因果图、错误推测等白盒测试必须知道软件内部，白盒测试也称结构测试或逻辑驱动测试(变量、逻辑路径、分支、语句)工设计正常运行、通过测试来检测软件内部是否按照需求，作过程.主要方法：语句覆盖法、分支覆盖法、逻辑覆盖法等按照测试阶段分类：单元测试集成测试系统测试依据系统设计文档，有开发人员执行对接口、路径的白盒测试依据设计/需求文档，有开发小组执行白盒和黑盒测试依据需求文档，由独立测试小组执行黑盒测试用户验收/确认测试

依据需求文档，由用户执行黑盒测试回归测试 主要针对以上阶段出现的问题在新版本重新测试验证修复情况软件测试的分类（2）按照测试策略分类：I.功能测试I.安装测试II.性能测试II.配置测试III.压力测试III.异常测试IV.容量测试IV.备份测试V.安全性测试V.健壮性测试VI.界面测试VI.文档测试VII.可用性测试VII.在线帮助测试VIII.兼容性测试VIII.网络测试IX.负载测试IX.稳定性测试小疑问：性能测试与压力测试你能区别清楚吗？2.

软件测试过程讲解湛腾科技第二章节讲解目录软件开发流程说明软件测试流程图软件测试过程描述软件测试的文档测试用例的设计与编写软件缺陷的编写标准与管理测试报告的编写输出软件开发流程规范说明软件开发过程应遵循软件工程学中的软件生命周期顺序进行下去，按照工作流程顺序依次是：准备阶段问题定义可行性分析需求分析软件设计程序编程软件测试安装试运行软件验收软件的维护软件消亡从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历可行性研究、需求分析、软件设计、程序编码、软件测试后，软件将进入运行维护阶段，直到最后由于市场需求减少或者缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life

Cycle

Model）。典型的三种软件。迭代模型、快速原型模型、生命周期模型包括瀑布模型软件测试流程图介绍（1）按照软件处于生命周期的不同阶段：单元测试集成测试系统测试验收测试UserRequirementsoftwareRequirementDesignProgramUnit

DesignCodingUnitTestingIntegrationTestingSystemTestingAcceptanceTestingPrepare

planVerifyPrepare

planVerifyPrepare

planVerify软件测试流程图介绍（2）测试准备测试需求测试计划测试用例测试执行测试缺陷管理1234567测试报告总结软件测试流程描述（1）测试需求目的：从源头把握软件质量，并确保开发结果与实际需求相一致角色与职责：需求人员：《需求规格说明书》的编写，以及软件开发过程中《需求规格说明书》的修正；

评审人员：评审《需求规格说明书》，从全面性、完整性、正确性、一致性、可靠性方面检查《需求规格说明书》，将需求缺陷提交给需求人员，并跟踪需求缺陷直至需求缺陷验证关闭输出：需求缺陷软件测试流程描述（2）测试计划目的：明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试过程的顺畅，有效控制和跟踪测试进度，应对测试过程中的各种变更。角色与职责：测试负责人：根据《项目整体计划》、《需求规格说明书》编制《测试计划》，明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便测试工作正常开展，测试计划实际编写内容参见《项目测试计划模版》。输出：《测试计划》软件测试流程描述（3）测试用例设计目的：通过多种测试方法编写测试用例，以使最少的测试用例，实现最大的测试覆盖，保证软件功能的正确性以及性能的稳定性，从而提升软件质量。角色与职责：测试人员：采用多种测试方法编写有效的测试用例，并对遗漏/错误的测试用例进行修正。评审人员：对测试人员编写的测试用例进行评审，提出遗漏/错误的用例缺陷，并跟踪直至用例缺陷的验证关闭。输出：《测试用例》、测试用例评审缺陷用例设计与编写，作为测试人员必须掌握，后面章节会着重介绍软件测试流程描述（4）测试执行目的：依据测试计划，按照测试用例对软件进行测试，验证软件功能与需求的实际匹配程度，以及以整个软件为对象，按照集成测试测试用例对新功能、老功能、新老功能接口进行测试和性能测试，保证测试的全面性和完整性。角色与职责：测试人员：依据测试计划，按照测试用例对软件功能/性能进行测试。对于发现的缺陷必须记录，并且跟踪缺陷的状态，直至缺陷的验证关闭，同时在测试过程中不断完善测试用例。开发人员：对于测试人员提交的缺陷进行确认、修复。开发经理：对测试人员与实际开发人员意见不一的问题进行裁决。输出：测试缺陷记录软件测试流程描述（5）测试报告目的：真实、客观反映测试过程中各测试阶段、测试项的情况，并将结果进行数字化/图像化进行分析，真实反映软件质量实际情况。角色与职责：测试负责人：真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字/图像的形式对实际情况进行分析，真实反映软件实际测试状况。输出：《项目测试报告》软件测试流程描述（6）回归测试在测试中发现的任何问题和错误都必须有一个明确的解决方法。一半来说，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试。另一方面，对于版本更新后的软件也必须进行同样的测试过程。回归测试策略基本上有两种：全部回归：也就是把之前的所有的测试用例，无论是手动的，还是自动的，全部跑一遍部分回归：定性分析代码改动有哪些影响，代码改动的文件/模块和其他的文件/模块的依赖性，然后选择被影响到的文件/模块相应的测试用例来跑一遍输出：反馈回归测试结果、回归报告软件测试涉及的文档《需求规格说明书》《项目整体计划》《测试计划》《测试用例》《用户操作手册》《项目测试报告》《缺陷管理规范》《测试执行规范》《文档测试指南》测试用例设计与编写（1）什么是测试用例？为什么要编写测试用例？定义：测试用例（Test

Case）通俗一点来讲就是编写（编制）一组前提条件、输入、执行条件、预期结果以完成对某个特定需求或目标测试的数据，体现测试方案、方法、技术和策略的文档。目的：测试用例是将整个测试的执行过程作一个科学有效的合理组织规划。主要目的是将软件测试的执行过程形成那个一个可管理的模式；同时测试用例也是将测试详细具体化的有效手段之一。作用：★作为实施测试的指导★作为测试数据规划的前提★作为测试脚本编写说明书★作为评判基准★作为分析缺陷的基准测试用例设计与编写（2）设计测试用例所需的文档资料与原则所需资料：★软件需求说明书；★软件设计说明书；★软件测试需求说明书；★成熟的测试用例（案例库或财富库）。设计原则：★利用成熟的测试用例设计方法来指导设计；★测试用例的正确性；★测试用例的代表性；★测试结果的刻判定性；★测试结果的可重现性；★足够详细、准确和清晰的步骤；★利用测试用例文档编写测试用例时必须符合内部的规范要求。测试用例设计与编写（3）通用测试用例构成八素用例编号测试项目测试标题重要级别预置条件测试输入操作步骤预期输出范例一：范例二：范例三：项目编号项目名称测试目的预置条件执行步骤预期结果判定要求结果备注SubjectTestNameTest

TitleInitialConditionsStepNameActionExpectedResultsTest

TypeIterationsTestLevelProduct测试编号测试名称预设环境测试强度用例描述期望结果用例类型结果描述是否通过测试用例设计与编写（4）通用测试用例八要素具体分析【1.用例编号】一般是数字和字符组合成的字符串，可以包括（下划线、单词缩写、数字等等），但是需要注意的是，尽量不要写汉语拼音，因为拼音的意义可能有好几种，有可能会导致乱码；用例编号具有唯一性和易识别性。（比如说我们唯一标识一个人：中国-上海市-xx区xx号-xx楼--xx室-xxx.这样标识的话就具有唯一性了。)不同阶段的测试用例的用例编号有不同的规则：系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX集成测试用例：产品编号-IT-系统测试项名-系统测试子项名-XXX单元测试用例：产品编号-UT-系统测试项名-系统测试子项名-XXX**其中产品编号也叫项目标识，每个公司都有若干不同的项目或者产品，如何来区分它们呢？这就需要有产品编号了，每个公司都有自己的一套定义产品编号的规则，并且每个现有产品的编号已经制定好了，直接拿过来用就可以了。**产品编号后的ST、IT、UT分别对应系统测试阶段、集成测试阶段、单元测试阶段。实际工作中有些公司会将产品编号以及测试阶段省略。**测试阶段后面就是测试项目名了，对应的是较大较系统的测试点。**测试项目名后面就是测试子项目名，有些测试是没有子项目名的，只有当测试项力度比较大的时候才会有成都市子项（比如说：我们要测试用户能否成功登录这个功能，那我们就可以分为很多个子项，qq登录、邮箱登录等等）。**测试子项名后面就是具体的用例编号了，可以是数字：01、001、002等等。测试用例设计与编写（5）通用测试用例八要素具体分析【2.测试项目】测试项目对应的就是测试用例中的子项名。系统测试用例：对应一个功能点（功能测试）、性能指标（性能测试）、界面中控件（GUI测试）等等。集成测试用例：对应集成后的模块功能或者接口功能。单元测试用例：对应函数名。通用测试用例八要素具体分析【3.测试标题】测试标题考虑的是如何来完成测试项目，或者说从哪个角度来对测试项目进行测试，有的公司也取名为测试目的。测试标题一定要简单、概要；体现测试的出发点和关注点。测试用例设计与编写（6）通用测试用例八要素具体分析【4.重要级别】用例的重要级别一般分成三个级别：高、中、低。高级别：对应保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例；中级别：对应重要程度介于高和低之间的测试用例；低级别：对应实际使用频率不高，对系统业务功能影响比较大的模块或功能的测试用例。**举个手机的例子：**高级别需求：正常通话功能、短信功能；中级别需求：拍照、联系人、MP3；低级别需求：计步、收音机等等。还需注意的是：针对**正常情况**的测试用例的重要级别比针对**异常情况**的测试用例的重要级别要高。测试用例设计与编写（7）通用测试用例八要素具体分析【5.预置条件】测试用例在执行前需要满足一些前提条件，否则测试用例是无法执行的，这些前提条件就是预置条件。预置条件分为两种情况：环境的设置。例如：测试word打开文件的功能，预置条件就是：需要提前准备被打开的文件；例如：登录成功的预置条件就是：该用户名已经注册过了。例如：购买商品成功的预置条件就是：后台已经配置好商品、发货区域、以及支付方式了。先要运行的其他用例，有些操作系统会比较复杂，如果都是从最开始的操作开始会导致用例写起来比较麻烦，这样可以在预置条件中设定要先运行的测试用例，后面的用例只需要写后续的操作就可以了。例如：对自动取款机进行测试，有针对的输入账户信息的测试，有对输入取钱金额的测试，后者的预置条件就可以写成输入正确账户信息的测试用例。注：具体预置条件的设置不同的公司会有自己的规定，比如有的公司不允许第二种情况出现的。测试用例设计与编写（8）通用测试用例八要素具体分析【6.测试输入】用例执行过程中需要加工的外部信息，根据软件测试用例的具体情况，有手工输入、文件、数据库记录等。禁止过多描述性语言，若为文件，会有提示选择路径，最好写具体，让别人易懂易操作。通用测试用例八要素具体分析【7.操作步骤】明确描述测试执行过程中具体的操作步骤，以方便测试执行人员可以根据该操作步骤完成测试用例执行。测试用例设计与编写（9）通用测试用例八要素具体分析【8.测试输出】预期输出是测试用例中非常重要的一部分，预期输出可以检验被测对象是否正常工作，如果我们的预期输出写的不完整不全面，整个测试用例就会受到影响。我们在写预期输出的时候可以从以下三个方面来考虑：界面显示：在操作步骤完成之后，界面会有显示；比如说我们测试用户登录功能，界面可能会显示登录成功或者登录失败。数据库的变化：在操作步骤完成之后，数据库中的记录会发生相应的变化，比如删除功能的测试，点击删除后，数据库中该记录会被删除。相关信息的变化：在操作步骤执行完成后，一些和被测对象相关的信息会发生变化，比如：注销功能的测试，点击注销后，以前能访问的页面将无法再访问。测试用例设计与编写（10）测试用例实例常用测试用例设计方法总结4）状态转换图方法1）等价类划分、边界值2）因果图、判定表3）正交排列方法、场景法5）测试大纲方法可以参考51testing上总结：编号项目名称测试目的预置条件执行步骤预期结果备注结果4.1.1开机选网、联合位置

更新验证CSFB终端优先选网能力.无线环境：TD-LTE、TD-SCDMA和GSM连续覆盖测试路线；2.测试终端：一部

TD-LTE被测终端.测试方式：动态路测1.被测终端开启飞行模式，按照既定测试路线移动；

2.关闭飞行模式，检查终端是否优选TD-LTE网络成功驻留，发起语音呼叫（10086），挂断后开启飞行模式；3.并按照步骤1-2连续执行50次；TD-LTE优选成功率≧98%测试用例的设计方法总结软件缺陷的编写标准与管理（1）概述在第一章节，我们简单介绍了什么是缺陷、为什么出现缺陷以及对缺陷的分类等，因为测试的直接目的是寻找软件存在的缺陷，那么，找到后如何管理缺陷对于测试和开发人员都必须了解掌握的。BUG的编写标准的规范，主要为是为了规范测试人员提交BUG的格式；可以使开发人员快速根据BUG进行定位，根据BUG现象迅速定位问题的本质，同时也方便测试人员对BUG进行重现，在回归版本发布后能够根据BUG描述有效的进行回归测试。BUG的跟踪管理，测试人员针对测试过程中出现的问题，需要提交到对应的研发进行缺陷修复，然后对修复后的版本再进行回归测试，直到BUG解决关闭，才算完成BUG的生命周期。由于这一过程中涉及的人员、流程等的复杂性，有效规范的BUG跟踪管理，对于确保软件质量以及尽早实现软件的发布必不可少。常见的BUG管理跟踪方法有:excel表格管理、word管理与BUG系统工具的管理等。软件测试中缺陷的管理（2）BUG编写标准及方法产品名称：每个测试的软件项目都有唯一的名称，在bug管理工具中添加测试的项目，在录入bug时先选择所测试的项目。缺陷ID：bug的唯一标识，由bug管理工具自动生成，方便跟踪管理bug解决进度。测试版本：报告错误时，一定要正确填写产生错误的软件版本号，录入bug时可选择相应的版本号。基本信息：bug的类型、严重程度以及处理的优先级；bug所属模块；测试者名称；测试时间；指派的开发人员；这些项都在bug录入时进行选择。缺陷标题：简明扼要地对bug进行概要描述。详细描述：A、预置条件：因为在某种特定的情景下，才能重现缺陷，所以预置条件在bug描述中必须详细准确，可能需要包括:测试所处的环境、产品所处的状态以及其他配置条件等。B、操作步骤：测试人员需要详细描述BUG产生的步骤，因为有些缺陷是在特殊的操作下才会出现，所以以便开发人员能够根据你的操作查找导致缺陷出现的关键因素，同时让其他测试人员在进行回归测试时方便复现，操作步骤必须清晰详细，要做到让即使不懂测试的人也能很容易看得懂。C、实际结果：描述实际测试后得到的输出结果。

D、预期结果：描述满足设计要求的期望输出结果。E、文字注释与附图：测试者的建议或者对问题的补充说明（比如错误出现的频率、对比信息等）与必要的附图，附加的现象图便于确认错误的表现形式和错误的位置，同时也可以作为缺陷的证据。软件测试中缺陷的管理（3）缺陷类型（本文按照目前web应用测试软件缺陷的特征进行分类，结合部门产品，简要描述各类缺陷的情况）缺陷分类描述说明用户界面缺陷控件的文字被截断控件或文字没有对齐控件位置重叠不一样的控件布局多余的文字丢失的文字文字的字体、字号错误多余的空格打印内容、格式错误语言质量缺陷字符未本地化字符不完整本体化错误的本体化字符不一致的本地化字符过度本地化标点符号、版本、商标符号错误功能缺陷功能不起作用菜单、超链接、按钮等不起作用功能错误菜单、超链接、按钮等和需求不一致功能缺失流程缺陷流程不能流转流程分支判断错误流程错误结束流程中特殊功能未处理接口缺陷与其他组件间的缺陷调用参数、控制块等相互影响的缺陷验证缺陷错误的提示信息、不适当的数据验证规范缺陷不符合标准的要求开发规范、设计元素易用性人机交互操作屏幕格式，确认用户输入，排版格式等方面软件测试中缺陷的管理（4）缺陷严重等级基于项目验收标准中的关键功能和性能要求，理论上CR的严重等级分为5个级别：CR等级CR定义定义说明1级Critical致命问题造成整个系统崩溃或死机的问题2级Major严重问题造成主要功能失效的问题，如不能打电话等3级Average一般问题不影响主要功能的缺陷。如：电话本不能使用等，但可以打电话。4级Minor提示性问题影响系统外观，但不影响系统功能。如:写信息中的错别字，界面颜色等。5级Improved改进建议不影响系统功能，满足需求，但可考虑改进以更好的满足用户需求备注：实际测试过程中，还可能按照A>B>C…等级这样分类，同时研发人员一般也会按照问题的严重等级，优先解决最严重的问题。软件测试中缺陷的管理（5）Excel管理缺陷实例软件测试中缺陷的管理（6）Bugzilla管理缺陷实例---展讯手机芯片测试bug管理系统软件测试中缺陷的管理（7）Bug管理的一般流程测试人员提交新的Bug入库，错误状态为New。高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为

Open。如果不是错误，则拒绝，设置为

Declined状态。开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。软件测试中缺陷的管理（8）常用bug管理工具比较----1当前企业常用bug管理工具有：Bugzilla、Jira、CQ、Quality

Center以及Bug

Free等工具名综述优点缺点TestManagerRational测试解决方案中推荐的测试用例管理工具。1.功能强大。1.本地化支持不好。汉字显示太小。2.文件夹形式的管理，可以对测试用例无限分级。2.测试用例很多时不太稳定。有时会造成测试用例的丢失。3.可以和Rational的测试工具robot、functional相结合。3.必须安装客户端才可使用。和开发人员交流不方便。4.有测试用例执行的功能，但必须先生成对应的手工或自动化脚本。4.测试用例的展示形式单一。Quality

CenterQualityCenter是一个基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。通过Quality

Center还可以创建报告和图来监控测试流程。确保支持所有环境，包括J2EE、.NET、Oracle和SAP。付费BugfreeBugFree是借鉴微软的研发流程和Bug管理理念，使用PHP+MySQL独立写出的一个Bug管理系统xx。1.BugFree是基于浏览器的。基于此，Raid有很强大的编辑展示功能，而BugFree简单、方便、易用；

2.当一个Bug被指派给你的时候，系统会自动给你发一封邮件，告诉

你有个Bug需要你处理，这样结合Email，BugFree被完美使用起来BugFree的查询功能相对弱一些Wiki使用wiki做测试用例的管理工具。1.Web界面形式，交流方便。2.测试用例的展示形式多样，可以贴图。可以进行格式化的编辑。Wiki提供测试用例的版本控制、版本比较功能。Wiki提供测试用例的添加注释（评论）功能，方便测试用例评审。Wiki本身强大的全文索引功能。6.可以任意为测试用例添加标签。Wiki并不是专业的测试用例管理工具。

2.无法和其他测试工具集成。3.测试用例的统计不方便。需要编写专门的程序。

4.没有测试用例的执行跟踪功能。5.有一些wiki本身的限制，如不同产品的测试用例名也不能重复。6.目前还没有定制统一的模板软件测试中缺陷的管理（9）常用bug管理工具比较----2Bugzilla+Test

Runner开源的测试管理解决方案，有很多开源软件使用此方式管理。1.开源免费。2.

Web方式的管理界面。3.自动邮件提醒。4.和缺陷管理系统Bugzilla结合紧密。有测试用例执行管理。5.测试用例可以分优先级。6.测试用例可以有评审的功能。（测试用例有不同的状态）1.安装设置较繁琐。2.没有配置过的经验。3.测试用例的编写上必须按照一个步骤对应一个验证点的形式来编写。TestDirector1.和Rational测试系列其名的测试管理工具，功能强大。2.

Web方式的界面。3.有测试用例执行跟踪的功能。4.有灵活的缺陷定制。5.和自身的缺陷管理工具紧密集成。6.界面较友好。1、每个项目库同时在线人数有限制2、可能存在部分不稳定性，但是基本功能没有问题新版CQ新版本的CQ中增加了测试用例管理的功能。1.和cq的缺陷管理紧密结合。2.可以使用cq强大的查询和图表功能。Eclipse的界面，较为笨重，需要安装TestLink1.

Web方式的界面。

2.和bugzilla缺陷管理工具的整合

3.可以自定义和其他缺陷管理工具的整合。4.同时具有需求管理的功能。Excel形式适合小型项目,如果充分利用excel的功能也可适合大型项目依托Excel本身的强大功能；很灵活，易于扩展。将来的维护等较麻烦；统计、度量等也不方便。Word形式依托Word本身的强大功能。很灵活，易于扩展。不如excel格式统一；不如excel容易统计。测试报告的编写输出测试报告作为测试输出的最后阶段，是对测试过程的总结，按照测试阶段，一般有测试日报与总结报告。测试日报内容：当天测试情况概述软件测试缺陷反馈测试整体进度汇报第二天测试计划安排测试基本信息（硬件与软件版本信息、测试人员及联系方式、其他需要关注信息）测试日报中需要包括测试结果与缺陷列表信息（以附件形式发送）例：Day

2

Report

-

15wk31_4G_GCF_Sumire_Gina_2A_full_SW_32.0.A.1.73.msg测试总结报告：当完成一个版本的测试或者结束一个项目后，都需要对整个测试进行分析总结，同时提出下一阶段修改完善建议。ZTS

Field

Test

For

H3A.pdf3.优秀软件测试工程师的成长之路湛腾科技第三章节内容说明优秀的软件测试人员应该具备的素质软件测试职业发展规划软件测试人员的发展阶段和机会如何成为一个优秀的软件测试工程师优秀的软件测试人员应该具备的素质软件测试员的一个基本素质是：打破沙锅问到底