软件测试与质量控制 教程1-8.doc

软件工程软件测试与质量控制教程1-8全集键入作者姓名选取日期在此处键入文档摘要。摘要通常为文档内容的简短概括。在此处键入文档摘要。摘要通常为文档内容的简短概括。目录软件测试与质量控制 教程14概述4什么是软件测试4为什么要做软件测试4软件测试人员做什么4软件测试环境4软件缺陷有哪些4什么是测试用例5软件测试分类5静态测试和动态测试5黑盒测试和白盒测试5单元测试、集成测试、系统测试和验收测试5功能测试和性能测试6回归测试和冒烟测试6软件测试分类关系6软件配置管理7软件测试管理7组织管理8计划管理8用例管理9文档管理10软件测试与质量控制 教程210概述10测试需求概念10测试需求分析工作步骤10小结11项目说明11软件测试与质量控制 教程311概述11测试计划主要内容11项目说明13软件测试与质量控制 教程413概述13黑盒测试方法13等价类划分法14划分步骤14划分方法14等价类划分法测试用例设计原则14实例分析15边界值分析法16确定边界16边界值分析法测试用例设计原则16实例分析16因果图法17为什么要用因果图18因果图符号和概念18实例分析19错误推测法22不同测试方法选择原则22项目说明23软件测试与质量控制 教程523概述23缺陷分类23缺陷描述24缺陷处理流程26项目说明27软件测试与质量控制 教程627概述27自动化测试工具分类27自动化测试工具一览28WinRunner功能测试工具30项目说明30软件测试与质量控制 教程731概述31代码检查31白盒测试方法31逻辑覆盖法31语句覆盖32判定覆盖32条件覆盖32判定条件覆盖32条件组合覆盖32路径覆盖32各种逻辑覆盖之间关系32基本路径法33控制流图33复合条件分解34环形复杂度34基本路径法测试用例设计步骤35实例分析35软件测试与质量控制 教程837概述37测试报告主要内容37项目说明38软件测试与质量控制 教程1概述软件测试是IT行业的一项职业性活动。对应的工作岗位有软件测试工程师、测试经理等岗位，另外软件开发工程师也需要掌握单元测试的有关内容。软件测试过程伴随软件开发过程始终。作为一名职业软件测试人员，有必要对软件测试的基础知识有所了解。什么是软件测试软件测试就是发现并指出软件中存在缺陷的过程。这里所说的软件既包括运行程序也包括软件设计开发过程中产生的需求、设计等相关文档以及编码过程中产生的源程序代码。为什么要做软件测试传统行业都有质量检查环节，对生产出来的产品进行质量检验，以确保生产出的产品是合格的。软件产品的质量检验是通过软件测试来完成的。软件设计开发过程中可能会出现很多问题，需要通过软件测试手段来发现软件缺陷，保证软件质量。软件测试人员做什么软件测试人员的目标就是尽可能早的找出软件缺陷，并确保其得到修复。软件测试人员的主要工作包括制定测试计划、设计测试用例、执行测试、对发现的缺陷进行跟踪管理、对测试结果进行分析总结等内容。软件测试环境软件测试环境就是软件运行的平台，包括软件、硬件和网络。硬件主要包括PC机、笔记本、服务器、各种PDA终端设备等。软件主要是指软件运行的操作系统，数据库管理系统，Web服务器、浏览器等。网络主要针对的是C/S结构和B/S结构的软件所使用的网络设备情况(类型、速度等)。软件缺陷有哪些软件出现的故障我们一般叫软件缺陷，符合以下5条规则的情况都可以称为软件缺陷：1. 软件未达到产品说明书标明的功能；2. 软件出现了产品说明书指明不会出现的错误；3. 软件功能超出产品说明书指明范围；4. 软件未达到产品说明书虽未指明但应达到的目标；5. 软件测试人员认为软件难以理解、不易使用、运行速度缓慢或者最终用户认为不好。什么是测试用例测试用例是测试执行的依据，是指在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和期望结果。软件测试分类人们根据测试目的和测试角度的不同将软件测试分成众多的类别。我们经常听到诸如静态测试、动态测试、黑盒测试、白盒测试、单元测试、集成测试等名词。作为一名软件测试人员，我们有必要了解这些软件测试分类的具体内容。静态测试和动态测试软件测试按照是否需要运行程序可以分为静态测试和动态测试。静态测试是指不实际运行被测软件，只是静态地检查程序界面、文档和源程序代码中可能存在的错误的过程。其中代码测试主要测试源代码是否符合相应的标准和规范；界面测试主要测试软件的实际界面与需求中的说明是否相符；文档测试主要测试用户使用手册和需求说明是否真正符合用户的实际需求。动态测试是指实际运行被测软件，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。黑盒测试和白盒测试软件测试按照是否需要了解程序内部结构可以分为黑盒测试和白盒测试。黑盒测试是指把被测软件当作是一个黑盒子，测试人员不需要知道盒子里面的结构，只关心软件的输入数据和输出结果，设计相应测试用例测试软件的过程。白盒测试是相对黑盒测试来说的。是指把被测软件当作是一个透明盒子，测试人员需要知道被测软件的程序结构，然后设计相应测试用例测试软件的过程。黑盒测试和白盒测试都有相应的测试用例设计方法，后续我们将进行详细介绍。单元测试、集成测试、系统测试和验收测试软件测试按测试阶段可以分为单元测试、集成测试、系统测试和验收测试。单元测试是指对软件中的最小可测试单元进行检查和验证。最小可测试单元可以是函数(面向过程程序)，也可以是类(面向对象程序) ，需要根据实际情况具体分析。单元测试在编码完成程序编译之后执行，一般由软件开发人员完成。单元测试依据程序的源代码和详细设计文档，主要采用白盒测试方法，先检查代码编写规范性(静态测试)，然后运行代码，检查实际运行结果(动态测试)。单元测试一般需要编写测试程序对程序模块进行测试。集成测试是单元测试的下一阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，主要测试不同模块的接口部分。集成测试的目的是检查各个单元模块集成在一起后是否能正常运行。集成测试在单元测试完成后执行，一般由软件开发人员和软件测试人员共同完成。集成测试依据单元测试的模块和概要设计文档，采用白盒和黑盒测试方法。集成测试可以采用增量和非增量两种方式进行。增量式集成是指按照一定次序(自顶至下或自底向上)逐步集成程序，这种测试方式需要编写测试程序。非增量式集成是指一次性把所有程序模块集成为一个完整系统，这种测试方式不需要编写测试程序。系统测试是集成测试的下一阶段，是指将整个软件系统看作一个整体进行测试，包括功能测试、性能测试以及软件所运行的软硬件环境兼容性测试等内容。系统测试在集成测试完成后执行，由软件测试人员完成。系统测试主要依据软件需求文档，采用黑盒测试方法。先测试系统的功能是否满足需求，然后测试系统的性能是否满足需求，最后测试系统在不同软硬件环境中的兼容性。验收测试在系统测试完成后执行，测试内容包含系统测试的内容，另外还包括对用户文档的测试。验收测试的测试人员以用户为主。功能测试和性能测试软件测试按测试内容可以分为功能测试和性能测试。功能测试是黑盒测试的一个方面，主要检查待测软件的功能是否满足用户的需求。功能测试可以细分为逻辑功能测试、界面测试、易用性测试、安装测试和兼容性测试等内容。功能测试可以使用自动化测试工具进行。后续第13章将介绍WinRunner功能测试开发内容。性能测试是黑盒测试的另一个方面，主要检查待测软件的性能是否满足用户的需求。性能测试可以细分为一般性能测试、稳定性测试、负载测试和压力测试等内容。性能测试一般使用自动化测试工具进行。回归测试和冒烟测试回归测试和冒烟测试是两个不相干的概念，我们单独描述。回归测试是指测试过程中对软件的新版本进行测试时，重复执行上一个版本测试时的测试用例。回归测试在集成测试阶段进行。冒烟测试是指在对一个软件新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。冒烟测试一般在系统测试之前进行。软件测试分类关系前面我们对常见的软件测试分类进行了简单介绍。这么多的测试分类，看上去很复杂，实际上只是分类角度有所不同。同一种测试，按照不同角度划分，可以属于不同的测试分类。下图描述了这些测试分类之间的关系。软件配置管理在一个实际的软件开发项目中，软件开发过程产生的各种产品必须纳入软件配置管理范围。软件测试人员在测试过程中往往需要对各种开发测试产品(文档、代码等)进行各种配置管理操作，例如从配置库获取配置项，将创建的测试产品添加到配置库等操作。软件配置管理(测试相关)项目主要教学生使用微软公司的配置管理工具Microsoft Visual SourceSafe(VSS)，要求学生完成以下工作任务：使用VSS建立项目配置库和各个配置项，对新建配置库进行用户权限管理，对新建配置库进行配置项出入库操作。项目的工作场景一般是企业的各个项目组或者独立的测试部门。项目目的主要是培养学生使用配置管理工具执行与软件测试相关的操作能力。该项目能为测试员、测试工程师、测试经理、SCM以及软件开发这些岗位的相关工作提供帮助。软件测试管理软件测试管理就是以测试项目为管理对象，通过一个临时性的专门的测试组织，运用专门的软件测试知识、技能、工具和方法，对测试项目进行计划、组织、执行和控制，并在时间成本、软件测试质量等方面进行分析和管理活动。软件测试管理贯穿整个测试项目的生命周期，是对测试项目的全过程进行管理。组织管理测试项目成功完成的关键因素之一就是要有高素质的软件测试人员，并将他们有效地组织起来，分工合作，形成一支精干的队伍，使他们发挥出最大的工作效率。测试的组织与人员管理就是对测试项目相关人员在组织形式、人员组成与职责方面所做的规划和安排。组织结构是指用一定的模式对责任、权威和关系进行安排，直至通过这种结构发挥功能。进行软件测试的测试组织结构形式很多，目前常见的测试组织结构有独立的测试小组和集成的测试小组两种形式。1. 独立测试小组2. 集成测试小组独立的测试小组，即主要工作是进行测试的小组，他们专门从事软件的测试工作。测试组设组长一名，负责整个测试的计划、组织工作。测试组的其他成员由具有一定的分析、设计和测试经验的专业人员组成，人数根据具体情况可多可少，一般35人为宜。测试组长与开发组长在项目中的地位是同级、平等的关系。集成测试小组是将测试与基本设计因素组合起来，构成的测试组织结构。这是与独立测试有关的一种集成测试组织形式，即集成测试小组是由需要向同一个项目经理汇报工作的测试人员和开发人员组成。计划管理测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。测试计划制定及管理的主要工作内容如下：1. 结合已批准的软件系统测试需求及所使用的测试工具，测试负责人与项目经理协商，逐步确定测试项目的测试目标、范围、粒度(覆盖标准)以及测试方案(包括各个测试阶段的出入口准则的协商)，在初步估计测试项目规模及工作量的基础上，协助测试项目开发计划书的可行性；2. 基于项目的系统功能集成方案及系统版本发布计划，配合项目经理逐步细化项目计划中的阶段小版本创建和发布里程碑点，并逐步细化测试方案及测试规模估计；3. 策划测试实施前准备内容、资源安排(包括人员分配，进度安排等，尤其要留有合理的测试Bug、用例管理时间)，细化项目测试计划相关内容；4. 测试负责人必要时还须与项目经理根据项目特性，确定系统冒烟测试的范围，粒度以及入口接受标准等内容，细化项目测试方案相关内容；5. 形成系统测试计划书(可包括单元、集成、系统阶段)并提交评审，按项目评审规程执行；6. 当项目开发计划或测试需求发生变更时，按配置管理过程执行。用例管理测试用例及管理的工作任务是根据批准的测试需求及方案，策划测试过程执行依据，确保测试范围有效并正确。测试用例设计及管理的主要工作内容如下：用例设计：1. 参与需求评审，正确理解系统需求并确认需求的可测性，获取测试项目需求；2. 根据批准的测试项目需求，测试目标的逻辑实现和约束，测试工具及其测试环境等限制条件，确定系统的测试中自动和手动测试的范围，并分别编写系统测试用例；3. 参与系统设计，协助验证系统体系结构及其逻辑实现层次的合理性，功能模块间的内部及其接口的正确性，结合系统功能集成方案，编写集成测试用例；4. 测试负责人或项目经理需针对系统体系结构设计方案、系统功能集成方案、系统版本发布计划以及项目开发计划等内容，组织编写创建脚本和冒烟测试用例；5. 测试负责人或项目经理负责基于系统的详细设计，确定单元测试范围和粒度，有效路径和值域等，组织单元测试中自动和手动测试用例的编写；6. 测试负责人或项目经理负责按测试用例编写要求、需求跟踪矩阵表完成编写符合性和需求覆盖性、有效性、完整性检查，并参照项目评审规程实施评审活动；7. 当项目测试需求发生变更时，按配置管理过程执行。用例管理：1. 测试负责人或项目经理负责进行阶段测试用例的实施、跟踪及用例统计分析工作，及时改进测试用例管理活动；2. 测试负责人或项目经理实时或定期根据Bug数据、状态和测试用例执行情况进行分析，以确定是否需要对目前测试的模块新增设计新的测试用例：a) 对不稳定的模块，测试负责人负责与项目经理多次讨论确定测试范围、粒度和执行方案等，并制定测试人员完成新增测试用例的编写；b) 对极其不稳定或未能达到测试入口标准的模块，则要求退回开发部重新开发；3. 由测试负责人和项目经理负责进行测试用例的完整性和有效性检查后，组织讨论新增测试用例，批准后由测试人员或开发人员执行；文档管理测试文档是对要执行的软件测试及测试的结果进行描述、定义、规定和报告的任何书面或图示信息。由于软件测试是一个很复杂的过程，同时也涉及到软件开发中其他一些阶段的工作，因此，必须把对软件测试的要求、规划、测试过程等有关信息和测试的结果，以及对测试结果的分析、评价，以正式的文档形式给出。测试文档对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时还会用到测试文档。测试文档的编写是测试管理的一个重要组成部分。根据测试文档所起的不同作用，通常把它分成两类，即前置作业文档和后置作业文档。测试计划及测试用例的文档属于前置作业文档。 后置作业文档是在测试完成后提交的，主要包括软件缺陷报告和分析总结报告。软件测试与质量控制 教程2概述测试需求分析是软件测试工作的首要工作任务，该项工作任务在项目开发阶段需求分析基本完成时切入。测试组人员需要参与开发项目的需求评审，确定项目的测试需求。测试需求分析的工作产品是测试需求文档。测试需求概念确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。 就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。测试需求，简单理解就是测试人员要对哪些点进行测试。测试需求的内容由软件测试人员根据用户需求说明书和开发设计说明书整理编写。依据软件需求规格说明书中相关内容，将系统要实现的功能点罗列出来，测试需求就是这些罗列出来的功能点。测试需求分析工作步骤我们来总结一下测试需求分析的一般步骤：1. 阅读需求规格说明书，找出与指定功能相关的描述内容。2. 列出描述内容中所有直接提及要实现的功能点3. 根据说明书内容，查找是否存在文档中未提及但是需要达到的功能点，有则列出来4. 将列出的内容整理成测试需求文档小结测试需求分析工作是一个细致活，需要测试人员有足够的耐心和细心，对功能点的罗列不能太粗，要尽量具体、完整。根据罗列的功能点整理测试需求列表时，一般来说功能点与测试点是一对一的关系。但是可以根据实际情况进行适当的归纳合并或整理细化。总的来说测试需求列表不能太笼统，要具体、详细、可测试。这是测试需求分析工作中要重点注意的。项目说明测试需求分析项目主要教学生理解分析软件需求说明文档，整理获得测试需求，编写测试需求文档，为制定测试计划做好准备。学生要求完成以下工作任务：分析ATM模拟系统软件需求说明书，整理系统的功能测试需求，编写测试需求文档。项目的工作场景一般是企业的各个项目组或者独立的测试部门。项目目的主要是培养学生准确获取测试需求的能力。该项目能为测试员、测试工程师、测试经理这些岗位的相关工作提供帮助。软件测试与质量控制 教程3概述测试计划制定就是根据之前确认的测试需求，确定项目测试阶段的目标和策略，确保测试工作有序、有效进行。测试计划的制定工作一般由测试经理牵头执行，一般测试人员只是协助工作。测试计划主要内容(1)测试环境确保项目测试环境符合测试要求，减少严重影响测试结果的真实性和正确性风险。包括：硬件环境：指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境：指被测软件运行时的操作系统、数据库及其他应用软件构成的环境，包括版本及补丁号。在实际测试中，可遵循下列原则：1) 符合软件运行的最低要求，首先要保证能支撑软件正常运行；2) 选用比较普及的操作系统和软件平台。3) 营造相对简单、独立的测试环境。4) 无毒的环境。利用有效的正版杀毒软件检测测试环境以确保其没有病毒。测试工具：指测试过程使用的所有测试工具、测试管理工具等，包括工具名、版本、生产厂商、用途。(2)测试方案对测试阶段进行划分，说明各测试阶段的目标、工作内容、管理方法、采用的样式、出口标准、停止标准、选取测试用例的原则等。(3)测试需求列出每一项测试需求名称、内容、目的。(4)测试优先级说明测试阶段或测试项的优先顺序和测试的重点内容。(5)测试机构及人员测试机构名称、测试组成员和职责。(6)进度 说明各测试阶段活动的详细时间、人员、工作量安排，包括计划、管理、测试、熟悉环境和工具、准备输入数据、校验输出结果等时间。测试阶段测试活动计划开始时间计划开始时间测试人员预计工作量（人天数）备注(7)问题响应要求问题分类问题严重程度响应时间立即解决程序错误，影响继续测试高度关注问题严重普通排队一般问题低优先级建议性问题(8)测试风险预估序号风险内容描述优先级影像度（I）概率（P）缓解策略(9)测试风险管理说明风险管理的责任人，风险跟踪与管理的周期、方法等。(10)评价说明所选择的测试用例能检查的范围及局限性。说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型，量值范围等。描述测试完成后应提交的文档。如：测试计划书、测试用例、测试问题报告、测试分析报告等。项目说明制定测试计划项目主要教学生修改整理已有的测试计划草稿文档，对完成的测试计划文档进行评审，形成基线，纳入软件配置管理。整个项目分成两个模块完成，模块一为编写测试计划书，模块二为测试计划评审。要求学生完成以下工作任务：按要求修改补充已有的测试计划草稿文档内容，为测试计划评审准备评审文档，分角色参与测试计划评审工作，将评审后的文档形成基线，纳入配置库管理。项目的工作场景一般是企业的各个项目组或者独立的测试部门。项目目的主要是培养学生对测试过程的整体把握能力，让学生熟悉项目评审环节的各项工作。该项目能为测试经理、测试员、测试工程师、SQA和SCM这些岗位的相关工作提供帮助。软件测试与质量控制 教程4概述在测试执行之前，测试人员需要设计一套详细的测试方案，测试方案的核心内容就是测试用例，测试用例是测试执行的最小单位，一般包括测试环境、测试步骤、测试数据和预期结果几部分的内容。测试用例设计是软件测试活动最重要的工作之一。根据测试阶段的不同，测试用例设计又分为单元测试用例设计、集成测试用例设计以及系统测试用例设计等多项内容。本课程主要关注的是集成测试用例设计和系统测试用例设计中的功能测试用例设计内容。其他测试用例设计内容会放在后续的软件综合项目开发课程中学习。黑盒测试方法黑盒测试方法用来设计系统测试用例。常用的黑盒测试方法有等价类划分法、边界值分析法、因果图法、决策表法、正交实验法、错误推测法等等价类划分法我们都知道，最理想的测试方法是穷举测试，即测试所有可能的情况。但是在实际工作中由于数据量较大或者数据域本身就是无穷的而无法进行穷举测试。这时候我们一般考虑对输入数据的范围进行有限划分，从每个划分类别中选取一个有代表性的测试数据进行测试，就等同于对这个划分类别的其他数据进行测试。等价类划分法是一种黑盒测试方法。等价类是指某个输入域的子集，在该子集中，各个输入数据对于揭露软件中的错误都是等效的。等价类可以分为有效等价类和无效等价类。其中有效等价类是符合需求规格说明书的合理输入数据集合，无效等价类是不符合需求规格说明书的无意义的输入数据集合。划分步骤等价类划分可以按以下步骤进行：(1)先考虑输入数据的数据类型(合法类型和非法类型)；(2)再考虑数据范围(合法类型中的有效区间和无效区间)；(3)用表格方法列举所有的等价类，为每一个等价类编号。划分方法常见的等价类划分方法有以下几种情况：(1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。(2)在输入条件规定了输入值的集合或者规定了必须如何的条件的情况下,可确立一个有效等价类和一个无效等价类。(3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。(4)在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。(5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。(6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。等价类划分法测试用例设计原则用等价类划分法设计测试用例应该遵循以下原则：(1)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；(2)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。实例分析设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在2013年1月2113年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的日期检查功能。(1)划分等价类并编号,等价类划分的结果如表3.1所示。表3.1等价类列表输入条件有效等价类编号无效等价类编号日期的类型及长度6位数字字符1有非数字字符2少于6位数字字符3多于6位数字字符4年份范围在20132113之间5小于20136大于21137月份范围在0112之间8等于009大于1210(2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为1、5、8，设计的测试用例如下：表3.2有效等价类测试用例测试数据期望结果覆盖的有效等价类201309输入有效1、5、8(3)为每一个无效等价类设计一个测试用例，设计结果如下：表3.3无效等价类测试用例测试数据期望结果覆盖的无效等价类13June无效输入22013无效输入320130102无效输入4201212无效输入6211401无效输入7201500无效输入9201314无效输入10边界值分析法长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。确定边界使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。常见的边界值有以下几种情况：(1)对16-bit的整数而言32767和-32768是边界。(2)屏幕上光标在最左上、最右下位置。(3)报表的第一行和最后一行。(4)数组元素的第一个和最后一个。(5)循环的第0次、第1次和倒数第2次、最后一次。边界值分析法测试用例设计原则用边界值分析法设计测试用例应遵循以下原则：对于一个含有n个变量的程序，应保留其中一个变量，其余的变量取正常值，被保留的变量取边界和边界附近的值，对每个变量重复进行上述取值方法，设计测试用例。实例分析NextDate函数包含三个变量：month、day和year，函数的输出为输入日期后一天的日期。例如，输入为2013年9月9日，则函数的输出为2013年9月10日。要求输入变量month、day和year均为整数值，并且满足下列条件：(1)1month12(2)1day31(3)1920year2050下面我们用边界值分析法来设计测试用例。在NextDate函数中，规定了变量mouth和变量day的取值范围为1mouth12和1day31，并设定变量year的取值范围为1920year2050。这些就是边界条件。根据这些边界条件设计的测试用例如表3.4所示。表3.4 NextDate函数边界值测试用例编号mouthdayyear预期输出Test1Test2Test3Test4Test5Test6Test76666666151515151515151919192019211975204920502051year超出范围1920.6.161921.6.161975.6.162049.6.162050.6.16year超出范围Test8Test9Test10Test11Test12Test13666666-112303132200120012001200120012001day超出1312001.6.22001.6.32001.7.1输入日期超界day超出131Test14Test15Test16Test17Test18Test19-112111213151515151515200120012001200120012001Mouth超出1122001.1.162001.2.162001.11.162001.12.16Mouth超出112因果图法因果图是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。为什么要用因果图我们前面介绍的等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。但是如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图。因果图符号和概念(1) 以下4种符号分别表示了现实世界中的4种因果关系(图3.1)。图3.1因果关系(2)因果图使用上图的简单符号表示因果关系，用圆圈表示节点，以直线连接左右节点。左边节点点表示输入状态(原因)，右边节点表示输出状态(结果)。(3)一般用Ci表示原因，ei表示结果，Ci和ei的取值都是0或者1，0表示某种状态不出现，1表示某种状态出现。因果图概念(1)关系：原因和结果之间存在如下关系(图3.1)。(a)表示恒等，若Ci=1，则ei=1，否则ei=0；(b)表示非，若Ci=1，则ei=0，否则ei=1；(c)表示或，若C1或C2或C3是1，则ei是1，否则ei是0，或可以有任意个输入；(d)表示与，若C1且C2是1，则ei是1，否则ei是0，与可以有任意个输入。(2)约束：输入状态(原因)之间或输出状态(结果)之间存在的某种依赖关系(图3.2)。E约束(异)：原因a和b中最多有一个可能为1，即a和b不能同时为1。I约束(或)：原因a、b和c中至少有一个必须是1，即a、b和c不能同时为0。O约束(唯一)：原因a和b必须有一个，且仅有一个为1。R约束(要求)：原因a是1时，b必须是1，即不可能a是1时b是0。图3.2约束关系实例分析假设有一个中国象棋的软件程序，我们需要测试棋子【马】的走法。下面我们采用因果图来设计测试用例。(1)首先我们分析一下中国象棋中的走马规则：a)如果落点在棋盘外，则不移动棋子；b)如果落点与起点不构成日字型，则不移动棋子；c)如果落点处有自己方棋子，则不移动棋子；d)如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子；e)如果不属于a-d条，且落点处无棋子，则移动棋子；f)如果不属于a-d条，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子；g)如果不属于a-d条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。根据分析情况，我们得到以下原因和结果，如表3.5所示。表3.5中国象棋走马程序分析编号原因编号结果C1落点在棋盘上e1不移动棋子C2落点与起点构成日字e2移动棋子C3落点方向的邻近交叉点无棋子e3移动棋子，并除去对方棋子C4落点处为自己方棋子e4移动棋子，并提示战胜对方，结束游戏C5落点处无棋子C6落点处为对方棋子（非老将）C7落点处为对方老将(2) 接下来我们画出中国象棋走马规则因果图。图3.3因果图，其中10表示中间节点(3)然后根据因果图得到判断表(分成两个表)表3.6决策表(1)序号12345678910111213141516原因C10101010101010101C20011001100110011C30000111100001111C40000000011111111结果100000000100000000e11111111011111111表3.7决策表(2)序号1234567890111213141516原因100101010101010101C50011001100110011C60000111100001111C70000000011111111结果e20010000e30000100e40000001注：1、第2表中部分列被合并表示不可能发生的现象；2、通过中间节点将用例的判定表简化为两个小表。减少工作量。(4)根据判定表写测试用例表表3.8中国象棋走马测试用例编号输入条件操作步骤期望输出Test1条件a-d不成立，移动马，落点是对方老将1、点击自方马；2、点击对方老将。移动棋子并提示战胜对方。Test2条件a-d不成立，移动马，落点是对方棋子（非老将）1、点击自方马；2、点击对方棋子。移动棋子并除去对方棋子。Test3条件a-d不成立，移动马，落点无棋子1、点击自方马；2、点击无棋子的落点。移动棋子。Test4绊马腿，落点为对方老将1、点击自方马；2、点击对方老将。不移动棋子。Test5绊马腿，落点为对方棋子（非老将）1、点击自方马；2、点击对方棋子。不移动棋子。Test6绊马腿，落点无棋子1、点击自方马；2、点击无棋子落点。不移动棋子。Test7落点为自方棋子1、点击自方马；2、点击自方棋子。不移动棋子。Test8不构成日字，落点为对方老将1、点击自方马；2、点击对方老将。不移动棋子。Test9不构成日字，落点为对方棋子（非老将）1、点击自方马；2、点击对方棋子。不移动棋子。Test10不构成日字，落点无棋子1、点击自方马；2、点击无棋子落点。不移动棋子。Test11落点在棋盘外1、点击自方马；2、点击棋盘外。不移动棋子。错误推测法错误推测法是指在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。不同测试方法选择原则除了上述几种常用的黑盒测试方法外，还有一些黑盒测试方法，如决策表法、正交试验法、流程分析法和状态迁移图法等，这里就不一一介绍了。通常，在确定测试方法时，应遵循以下原则：1.根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。2.认真选择测试策略，以便能尽可能少的使用测试用例，发现尽可能多的程序错误。因为一次完整的软件测试过后，如果程序中遗留的错误过多并且严重，则表明该次测试是不足的，而测试不足则意味着让用户承担隐藏错误带来的危险，但测试过度又会带来资源的浪费。因此测试需要找到一个平衡点。3.通常在确定测试策略时，有以下5条参考原则：(1)在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。(2)必要时采用等价类划分法补充测试用例。(3)采用错误推断法再追加测试用例。(4)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例。(5)如果程序的功能说明中含有输入条件的组合情况，则应一开始就选用因果图法。项目说明测试用例设计项目主要教学生运用黑盒测试方法对待测试项目进行功能测试用例设计，编写测试用例文档，对测试用例进行评审，形成基线，纳入软件配置管理。整个项目分为四个模块完成，模块一为黑盒测试方法，模块二为功能测试用例设计，模块三为编写测试用例文档，模块四为测试用例评审。学生要求完成以下工作任务：运用黑盒测试方法设计ATM模拟系统的功能测试用例，编写测试用例文档，为测试用例评审准备评审文档，分角色参与测试用例评审工作，将评审后的文档形成基线，纳入配置库管理。项目的工作场景一般是企业的各个项目组或者独立的测试部门。该项目能为测试员、测试工程师、测试经理、SQA和SCM这些岗位的相关工作提供帮助。软件测试与质量控制 教程5概述缺陷跟踪管理是软件测试工作的一个重要部分，软件测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是软件测试工作的一项重要内容。缺陷分类软件缺陷分类的原因在于给出Bug的严重级别，判定修复的优先级。可以按照Bug的严重级别分类。表4.1缺陷分类表级别说明1类Bug：致命错误(1)需求说明书中的功能未实现；(2)由于系统崩溃、死机、非法退出、死循环、数据库异常、通讯异常、文件操作异常等原因造成功能不能实现，并且不能通过其他方法实现。2类Bug：严重错误(1)重要功能基本能实现，但系统不稳定、会导致数据破坏丢失、run-time error错误等；(2)重要功能不能按正常操作实现，但通过其他方法可以实现。3类Bug：一般错误(1)次要功能不能正常实现；(2)操作界面错误(包括数据窗口内列名定义、含义不一致)；(3)打印内容、格式错误；(4)简单的输入限制未放在前台进行控制；(5)删除操作未给出提示；(6)数据库表中有过多的空字段；(7)因错误操作迫使程序中断；(8)系统找不到规律的时好时坏；(9)数据库的表、业务规则、缺省值未加完整性等约束条件。4类Bug：细微错误最好能改进的：(1)界面不规范；(2)辅助说明描述不清楚；(3)输入输出不规范；(4)长操作未给用户提示；(5)提示窗口文字未采用行业术语；(6)可输入区域和只读区域没有明显的区分标志。5类Bug：改进建议(1)可以作为下一个版本的改进；(2)暂不作为修订内容。缺陷描述对缺陷的描述应该包含以下的内容：表4.2缺陷描述内容说明内容描述项说明是否必填可追踪信息缺陷ID唯一的缺陷ID，可以根据该ID追踪缺陷，一般就是测试用例的编号是缺陷基本信息缺陷状态缺陷的状态，分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭”是缺陷标题描述缺陷的标题是缺陷严重程度描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“建议”四种是缺陷紧急程度描述缺陷的紧急程度，从14，1是优先级最高的等级，4是优先级最低的等级是缺陷提交人缺陷提交人的名字(邮件地址)是缺陷提交时间缺陷提交的时间是缺陷所属项目/模块缺陷所属的项目和模块，最好能较精确的定位至模块是缺陷指定解决人缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改是缺陷指定解决时间项目经理指定的开发人员修改此缺陷的deadline是缺陷处理人最终处理缺陷的处理人是缺陷处理结果描述对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改是缺陷处理时间缺陷处理的时间是缺陷验证人对被处理缺陷验证的验证人是缺陷验证结果描述对验证结果的描述（通过、不通过）是缺陷验证时间对缺陷验证的时间是缺陷详细描述缺陷详细描述对缺陷的详细描述；之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细。是测试环境说明测试环境说明对测试环境的描述是必要的附件必要的附件对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的否缺陷处理流程缺陷处理流程中的角色分工如下：(1)测试人员：进行测试的人员，缺陷的发