软件测试与质量控制教程18.docx
《软件测试与质量控制教程18.docx》由会员分享，可在线阅读，更多相关《软件测试与质量控制教程18.docx（47页珍藏版）》请在冰点文库上搜索。
软件测试与质量控制教程18
软件工程
软件测试与质量控制
教程1-8全集
舒文静
[选取日期]
[在此处键入文档摘要。
摘要通常为文档内容的简短概括。
在此处键入文档摘要。
摘要通常为文档内容的简短概括。
]
软件测试与质量控制教程1
概述
软件测试是IT行业的一项职业性活动。
对应的工作岗位有软件测试工程师、测试经理等岗位，另外软件开发工程师也需要掌握单元测试的有关内容。
软件测试过程伴随软件开发过程始终。
作为一名职业软件测试人员，有必要对软件测试的基础知识有所了解。
什么是软件测试
软件测试就是发现并指出软件中存在缺陷的过程。
这里所说的软件既包括运行程序也包括软件设计开发过程中产生的需求、设计等相关文档以及编码过程中产生的源程序代码。
为什么要做软件测试
传统行业都有质量检查环节，对生产出来的产品进行质量检验，以确保生产出的产品是合格的。
软件产品的质量检验是通过软件测试来完成的。
软件设计开发过程中可能会出现很多问题，需要通过软件测试手段来发现软件缺陷，保证软件质量。
软件测试人员做什么
软件测试人员的目标就是尽可能早的找出软件缺陷，并确保其得到修复。
软件测试人员的主要工作包括制定测试计划、设计测试用例、执行测试、对发现的缺陷进行跟踪管理、对测试结果进行分析总结等内容。
软件测试环境
软件测试环境就是软件运行的平台，包括软件、硬件和网络。
硬件主要包括PC机、笔记本、服务器、各种PDA终端设备等。
软件主要是指软件运行的操作系统，数据库管理系统，Web服务器、浏览器等。
网络主要针对的是C/S结构和B/S结构的软件所使用的网络设备情况（类型、速度等）。
软件缺陷有哪些
软件出现的故障我们一般叫软件缺陷，符合以下5条规则的情况都可以称为软件缺陷：
1.软件未达到产品说明书标明的功能；
2.软件出现了产品说明书指明不会出现的错误；
3.软件功能超出产品说明书指明范围；
4.软件未达到产品说明书虽未指明但应达到的目标；
5.软件测试人员认为软件难以理解、不易使用、运行速度缓慢或者最终用户认为不好。
什么是测试用例
测试用例是测试执行的依据，是指在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和期望结果。
软件测试分类
人们根据测试目的和测试角度的不同将软件测试分成众多的类别。
我们经常听到诸如静态测试、动态测试、黑盒测试、白盒测试、单元测试、集成测试等名词。
作为一名软件测试人员，我们有必要了解这些软件测试分类的具体内容。
静态测试和动态测试
软件测试按照是否需要运行程序可以分为静态测试和动态测试。
静态测试是指不实际运行被测软件，只是静态地检查程序界面、文档和源程序代码中可能存在的错误的过程。
其中代码测试主要测试源代码是否符合相应的标准和规范；界面测试主要测试软件的实际界面与需求中的说明是否相符；文档测试主要测试用户使用手册和需求说明是否真正符合用户的实际需求。
动态测试是指实际运行被测软件，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
黑盒测试和白盒测试
软件测试按照是否需要了解程序内部结构可以分为黑盒测试和白盒测试。
黑盒测试是指把被测软件当作是一个黑盒子，测试人员不需要知道盒子里面的结构，只关心软件的输入数据和输出结果，设计相应测试用例测试软件的过程。
白盒测试是相对黑盒测试来说的。
是指把被测软件当作是一个透明盒子，测试人员需要知道被测软件的程序结构，然后设计相应测试用例测试软件的过程。
黑盒测试和白盒测试都有相应的测试用例设计方法，后续我们将进行详细介绍。
单元测试、集成测试、系统测试和验收测试
软件测试按测试阶段可以分为单元测试、集成测试、系统测试和验收测试。
单元测试是指对软件中的最小可测试单元进行检查和验证。
最小可测试单元可以是函数（面向过程程序），也可以是类（面向对象程序），需要根据实际情况具体分析。
单元测试在编码完成程序编译之后执行，一般由软件开发人员完成。
单元测试依据程序的源代码和详细设计文档，主要采用白盒测试方法，先检查代码编写规范性（静态测试），然后运行代码，检查实际运行结果（动态测试）。
单元测试一般需要编写测试程序对程序模块进行测试。
集成测试是单元测试的下一阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，主要测试不同模块的接口部分。
集成测试的目的是检查各个单元模块集成在一起后是否能正常运行。
集成测试在单元测试完成后执行，一般由软件开发人员和软件测试人员共同完成。
集成测试依据单元测试的模块和概要设计文档，采用白盒和黑盒测试方法。
集成测试可以采用增量和非增量两种方式进行。
增量式集成是指按照一定次序（自顶至下或自底向上）逐步集成程序，这种测试方式需要编写测试程序。
非增量式集成是指一次性把所有程序模块集成为一个完整系统，这种测试方式不需要编写测试程序。
系统测试是集成测试的下一阶段，是指将整个软件系统看作一个整体进行测试，包括功能测试、性能测试以及软件所运行的软硬件环境兼容性测试等内容。
系统测试在集成测试完成后执行，由软件测试人员完成。
系统测试主要依据软件需求文档，采用黑盒测试方法。
先测试系统的功能是否满足需求，然后测试系统的性能是否满足需求，最后测试系统在不同软硬件环境中的兼容性。
验收测试在系统测试完成后执行，测试内容包含系统测试的内容，另外还包括对用户文档的测试。
验收测试的测试人员以用户为主。
功能测试和性能测试
软件测试按测试内容可以分为功能测试和性能测试。
功能测试是黑盒测试的一个方面，主要检查待测软件的功能是否满足用户的需求。
功能测试可以细分为逻辑功能测试、界面测试、易用性测试、安装测试和兼容性测试等内容。
功能测试可以使用自动化测试工具进行。
后续第13章将介绍WinRunner功能测试开发内容。
性能测试是黑盒测试的另一个方面，主要检查待测软件的性能是否满足用户的需求。
性能测试可以细分为一般性能测试、稳定性测试、负载测试和压力测试等内容。
性能测试一般使用自动化测试工具进行。
回归测试和冒烟测试
回归测试和冒烟测试是两个不相干的概念，我们单独描述。
回归测试是指测试过程中对软件的新版本进行测试时，重复执行上一个版本测试时的测试用例。
回归测试在集成测试阶段进行。
冒烟测试是指在对一个软件新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
冒烟测试一般在系统测试之前进行。
软件测试分类关系
前面我们对常见的软件测试分类进行了简单介绍。
这么多的测试分类，看上去很复杂，实际上只是分类角度有所不同。
同一种测试，按照不同角度划分，可以属于不同的测试分类。
下图描述了这些测试分类之间的关系。
软件配置管理
在一个实际的软件开发项目中，软件开发过程产生的各种产品必须纳入软件配置管理范围。
软件测试人员在测试过程中往往需要对各种开发测试产品（文档、代码等）进行各种配置管理操作，例如从配置库获取配置项，将创建的测试产品添加到配置库等操作。
软件测试管理
软件测试管理就是以测试项目为管理对象，通过一个临时性的专门的测试组织，运用专门的软件测试知识、技能、工具和方法，对测试项目进行计划、组织、执行和控制，并在时间成本、软件测试质量等方面进行分析和管理活动。
软件测试管理贯穿整个测试项目的生命周期，是对测试项目的全过程进行管理。
组织管理
测试项目成功完成的关键因素之一就是要有高素质的软件测试人员，并将他们有效地组织起来，分工合作，形成一支精干的队伍，使他们发挥出最大的工作效率。
测试的组织与人员管理就是对测试项目相关人员在组织形式、人员组成与职责方面所做的规划和安排。
组织结构是指用一定的模式对责任、权威和关系进行安排，直至通过这种结构发挥功能。
进行软件测试的测试组织结构形式很多，目前常见的测试组织结构有独立的测试小组和集成的测试小组两种形式。
1.独立测试小组
2.集成测试小组
独立的测试小组，即主要工作是进行测试的小组，他们专门从事软件的测试工作。
测试组设组长一名，负责整个测试的计划、组织工作。
测试组的其他成员由具有一定的分析、设计和测试经验的专业人员组成，人数根据具体情况可多可少，一般3～5人为宜。
测试组长与开发组长在项目中的地位是同级、平等的关系。
集成测试小组是将测试与基本设计因素组合起来，构成的测试组织结构。
这是与独立测试有关的一种集成测试组织形式，即集成测试小组是由需要向同一个项目经理汇报工作的测试人员和开发人员组成。
计划管理
测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。
测试计划制定及管理的主要工作内容如下：
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
年份范围
在2013~2113之间
5
小于2013
6
大于2113
7
月份范围
在01~12之间
8
等于00
9
大于12
10
（2） 设计测试用例， 以便覆盖所有的有效等价类在表中列出了3个有效等价类， 编号分别为1、5、8，设计的测试用例如下：
表3.2 有效等价类测试用例
测试数据
期望结果
覆盖的有效等价类
201309
输入有效
1、5、8
（3） 为每一个无效等价类设计一个测试用例，设计结果如下：
表3.3 无效等价类测试用例
测试数据
期望结果
覆盖的无效等价类
13June
无效输入
2
2013
无效输入
3
无效输入
4
201212
无效输入
6
211401
无效输入
7
201500
无效输入
9
201314
无效输入
10
边界值分析法
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。
因此针对各种边界情况设计测试用例，可以查出更多的错误。
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
确定边界
使用边界值分析方法设计测试用例，首先应确定边界情况。
通常输入和输出等价类的边界，就是应着重测试的边界情况。
应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
常见的边界值有以下几种情况：
（1） 对16-bit 的整数而言 32767 和 -3276
升级会员 