软件测试基础理论
一、软体实作方法论
1.测试的策略：
(1)静态测试：不测试程式本身，而直接寻找程式中可能存在的缺陷或评估程式码品质的行为。主要是在单元测试行为中，对技术、设计文件进行评核，程式无法执行或需要对塬始程式进行规范符合性检查时该使用这种策略。
(2)动态测试：运作被测程式，输入测试资料，检查运作结果与预期结果的差异，从而判断系统中是否存在缺陷的过程。
2.动态测试的测试技术：
(1)黑箱测试：测试人员完全不考虑程式内部的逻辑结构和内部特性，只依据程式的需求规格说明书，检查程式的功能是否符合它的功能性说明的测试方法。主要是在系统测试阶段时采用。
(2)白箱测试：使用被测程式内部如何工作的资讯，允许测试人员对程式内部逻辑结构及有关资讯来设计和选择测试案例，对程式的逻辑路径进行测试。其测试基于覆盖全部程式码、分枝、路径、条件。
(3)灰箱测试：基于被测试程式逻辑结构的基础上，从系统功能介面上设计测试案例。通常是作为黑箱测试的补充或在黑箱发现缺陷以后，回到塬始程式码分析塬因确认问题时采用。
3.测试的阶段：
(1)单元测试：为最小单位的测试。在单元测试行为中，各独立单元模组在与系统其他模组隔离的情况下进行测试，检查每个程式模组是否实现了规定的功能。
(2)整合测试：是在单元测试的基础上将已经通过测试的单元模组按照设计要求组装成系统或子系统进行测试的活动。测试着重在各模组、各子系统之间介面上的缺陷。
(3)系统测试：透过整合测试的软体，同其运作环境、资料和使用者结合在一起，在实际或模拟实际环境下，对系统进行全面的测试。目的在于通过与系统需求规格书进行比较，发现软体与系统定义不符合的地方。
(4)验收测试：为最后一个测试行为。它是以使用者为主的测试，由使用者设计测试案例，使用实际资料进行测试。
4.测试的方法：
(1)功能测试：检查软体的功能是否符合规格说明书上的需求。
(2)效能测试：检察系统是否实现了规定的效能指标要求。
5.测试的实施组织划分：
(1)开发者测试(α 测试)：开发者透过检测和提供客观证据，证实软体的实现是否满足规定的需求。主要是在系统交付给第叁方测试或验收测试之前进行的活动。
(2)使用者测试(β 测试)：在使用者的应用环境下，透过使用检测软体来验证是否符合自己预期的需求。
(3)第叁方测试(外包测试)：软体发展方和使用者方之间的测试团队进行的测试行为。
6.测试的其他概念：
(1)人工测试：由测试人员来执行测试案例，然后根据实际的结果和预期的结果进行比较，并记录测试结果。
(2)自动化测试：透过重播录制或编写的自动化脚本，驱动系统运行的测试行为。
(3)回归测试：软体在修改以后再次运作之前，为寻找错误而执行程式曾用过的测试案例，以测试缺陷是否再次出现的行为。
(4)烟雾测试：软体版本交付后，对其重要的部分先进行大概的测试，检查主要功能是否正确，再进行后面的测试。
7.软体测试模型请参考「软件测试过程管理实践 」
二、软体品质和缺陷报告
1.规范需求需包括：
(1)使用者可能认为我们理解或遗漏的。
(2)行业规范。
(3)电脑领域的规范和习惯。
(4)客户对电脑技术的限制。
2.外部品质与内部品质模型的六种属性：
(1)功能性：
适合
准确
互动
保密安全
功能依从
(2)可靠性：
成熟
容错
易回复
可靠依从
(3)易用性
吸引
易学
易理解
易操作
易用依从
(4)效率性：
时间特性
资源利用
效率依从
(5)维护性：
稳定
易分析
易改变
易测试
维护依从
(6)可携性：
适用
相容
易安装
易替换
可携依从
3.使用者品质模型的四种属性：
(1)有效性
(2)生产率
(3)安全性
(4)满意度
4.缺陷报告应填写的元素：
(1)缺陷摘要
(2)缺陷所在的子系统(模组)
(3)缺陷位置
(4)缺陷类型、塬因
(5)缺陷状态
(6)详细描述
(7)严重程度
(8)紧急程度
(9)附件
(10)发现行为
(11)发现途径
(12)测试案例编号
(13)提交的版本
(14)提交的循环周期
(15)提交日期
5.缺陷处理后要填写的叁项资讯：
(1)修复的版本
(2)修复人
(3)拒绝者
6.缺陷的六种状态：
(1)New：预设值，测试工程师填写一个新缺陷报告时。
(2)Open：测试团队组长对缺陷进行审查后，将缺陷状态从「New」改为「Open」，并在一定的时间内指派给对应的开发工程师。
(3)Fixed：当缺陷被修复并通过了验证测试，开发工程师将缺陷状态从「Open」改为「Fixed」。
(4)Pending：当缺陷由于各种塬因无法修复时，开发工程师或专案经理将缺陷状态从「Open」改为「Pending」。处在此状态的缺陷将等待条件具备时再进行修复。
(5)Closed：当缺陷在一个新建版本中完成了验证测试时，测试工程师将状态从「Fixed」改为「Closed」。
(6)Reopen：当缺陷验证失败时，测试工程师会将状态从「Fixed」改为「Reopen」。当以前已经关闭的缺陷又在测试过程中出现时，测试工程师会将状态从「Closed」改为「Reopen」。
三、文件审查和测试需求分析
1.业务规格需求说明书为整个软体生产活动的依据，其审查项目包括：
(1)个业务功能和效能指标的描述是否清晰、明确。
(2)同需求描述之间是否存在矛盾和冲突。
(3)业务功能描述是否有遗漏。
(4)业务需求是否可以测量。
(5)业务功能描述是否会和行业规则、企业规范;国家法律规范、政策等发生冲突。
(6)需求中计算公式是否明确，公式中各因数是否明确。
(7)计算是否有精度要求。
(8)多角色和多使用者的系统角色、权限等是否合适。
(9)其引用的文件中是否正确且文件中是否有相应叙述。
2.概要设计文件为描述功能设计、资料结构、资料目录、效能指标等的文件，其审查项目包括：
(1)设计是否涵盖了业务需求。
(2)功能模组设计和内外介面之间的资料交换是否明确。
(3)资料结构或类别图设计是否明确。
(4)资药库逻辑结构和物理结构设计描述是否正确，有无遗漏。
(5)应用逻辑设计、网路设计、安全设计是否正确。
3.安装部署文件为描述系统的部署，其审查项目包括：
(1)文件阅读者为维护人员，所以要注意技术描述而非业务描述。
(2)开发团队使用的一些术语或缩写词语要有解释说明。
(3)部署中的硬体设备要与上线设备一致。
(4)部署应用系统所需要的作业系统、支援软体等要确定的版本要求和配置参数要求。
(5)文件中的截图要与系统实际上线环境中的系统介面、操作一致。
(6)有条件时应该对照部署手册进行实际部署测试。
4.使用者手册为产品最终的规范，其审查项目包括：
(1)按照手册描述的操作步骤来操作程式。要确认手册中的描述是正确的，不要出现导致使用者错误操作的情况。
(2)手册中的建议操作应做重点验证。建议应该是使用者选择的操作，所以要按步骤去验证使用者依照建议所做的操作，测试人员应尝试更多的可能性。
(3)检查每条陈述。测试人员需要对每条陈述进行检查。
(4)检查图表、截图是否与发布的版本一致。
(5)对业务术语和缩写词要进行必要的解释。使用者手册中不应该出现阅读者可能不熟悉的专业术语和缩写词。
(6)像使用者一样使用样例和示例，按步骤去验证每个样例或示例。
(7)寻找容易误导使用者的内容。应尽早标示出如意被人误解的内容。
5.系统功能测试需求的六大分类：
(1)业务功能测试需求。
(2) 可靠性测试需求。
(3)安全性测试需求。
(4)易用性测试需求。
(5)可携性测试需求。
(6)可维护性测试需求。
6.测试工作的依据首先是业务需求规格说明书，所以首先应该把需求从中提取出来，再把业务需求分解为测试需求，每个业务需求对应一条或多条测试需求。
四、测试设计
1.测试案例是为了验证受测系统的某一品质子属性而设计的。共有四个基本要素：
(1)案例描述：测试的目的和预期的结果。
(2)测试资料：执行测试案例时所载入的输入资料。
(3)执行步骤：测试案例执行时所要进行的操作伫列。
(4)预期结果：测试案例执行完后所期望系统提供的结果。
2.测试案例的设计方法-等价类划分：
等价划分是把系统某个输入资料集合划分成若干部分，然后从每个部份中选取少数代表性资料作为测试案例的输入。
步骤：
(1)为每个等价类别限定一个唯一的编号。
(2)设计一个新的测试案例，使其尽可能多地覆盖尚未覆盖的有效等价类(对于程式的规格说明书来说是合理的、有意义的输入资料构成的集合)。重复这一步，最后使得所有有效等价类均被测试案例所覆盖。
(3)设计一个小的测试案例，使其只覆盖一个无效等价类(对于程式的规格说明书来说是不合理的、无意义的输入资料构成的集合)。重复这一步，使所有无效等价类均被覆盖。
3.测试设计阶段的工作包括：
(1)把测试需求转化为测试案例。
(2)补充完善的测试需求。
(3) 完善的测试策略。
(4)测试条件、设备、环境的准备。
五、做好专案测试计划
1.测试计画包含的要素：
(1)测试目标和范围。
(2)测试资源。
(3)进度计画。
(4)测试约束条件。
(5)测试循环周期。
(6)测试策略。
(7)专案风险。
(8)测试约定。
2.进行测试策略的叁步骤：
(1)确定测试需求。
(2)评估专案风险并确定测试优先顺序。
(3)确定测试策略。
六、单元测试及结果测试
1.语法涵盖：设计若干测试案例，执行受测程式，使得每一条可执行语法至少被执行一次。
2.判定(分支)覆盖：设计若干测试案例，执行受测程式，使程式中每个判断的逻辑为真和逻辑为假至少被执行一次。
3.条件覆盖：设计足够多的测试案例，执行受测程式，使程式中判断的每个条件的每个可能取值至少被执行一次。
4.判定-条件覆盖：设计足够多的测试案例，执行受测程式，使程式中判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少被执行一次。
5.条件组合测试：设计足够多的测试案例，执行受测程式，使程式中每个判断的所有可能的条件取值组合至少被执行一次。
6.路径测试：设计足够多的测试案例，覆盖受测物件中的所有可能路径。
7.单元测试的步骤：
(1)计画：确定测试需求，制定测试策略，确定测试所用资源，建立测试任务的时间表。
(2)设计：设计单元测试模型，制定测试方案，制定具体的测试案例，建立可再使用的测试脚本。
(3)执行：执行测试案例，对单元模组进行测试，验证测试的结果并记录测试过程中出现的缺陷。
(4)评审：对单元测试的结果进行评审。主要进行测试完备性评估。
七、产品整合测试
1.产品整合测试的重点：
(1)在把各个模组 / 子系统连接起来的时候，跨模组介面的资料是否会遗失。
(2)一个功能模组 /子系统是否会对另一个功能 / 子系统模组产生不利的影响。
(3)各个子功能 / 子系统模组累加起来，是否能达到预期的功能。
(4)全域资料结构是否有问题。
(5)单个模组的误差是否会累加放大到不能接受的程度。
2.烟雾测试的重点：
(1)整个系统是否会实现全部主要功能。如果没有实现，这些未实现的功能是否会给系统其他部分造成很大的影响。
(2)着重已经实现功能的品质，透过简单执行主要业务流程，分析功能完成品质。
(3)看看是否有具体的实现，而不要被系统功能功能表和视窗所迷惑。
3.整合测试流程：
(1)测试计画：确认测试物件、范围，分析测试需求，测试策略、方法和出、允入准则，估算工作量，估算所需资源。
(2)测试设计：设计测试案例、测试资料、测试环境部署等。
(3) 测试执行：执行案例，记录测试过程日志，提交缺陷并追踪缺陷处理流程，测试案例维护。
(4)测试总结：发现评估整合测试、测试报告。
4.整合测试设计需考量的要点：
(1)考虑支援本系统执行而需要的测试环境及测试环境与生产环境的差别。
(2)测试案例的执行策略。
(3)测试案例运行需要的外部条件。
5.整合测试报告应包括的内容：
(1)测试案例执行情况分析。
(2)整合测试需求符合程度分析。
(3)缺陷分析。
(4) 测试过程分析。
八、专案功能测试
1.专案经理在功能测试执行之前的准备工作：
(1)完成对功能测试计画的评审。
(2)完成对功能测试案例的评审。
(3)测试环境建置完成，且通过审查。
(4)功能测试需要的测试资料和结果记录形式准备完成。
(5) 系统中的参数配置等已准备好。
九、专案效能测试
1.测试允入准则：
(1)效能测试计画撰写完成，且通过评审。
(2)与业务人员沟通，选择常见交易和混和业务比例。
(3)整个系统功能趋于稳定。
(4)测试环境搭建完成，且通过验收。
(5)测试环境应用部署完成，并验证可用性。
(6)效能测试脚本和测试资料准备结束。
(7) 预期效能指标确定。
2.测试允出准则：
(1)校能测试完成，系统达到效能测试指标。
(2)校能测试完成，若未达到效能测试指标，则返回最佳化处理。
(3)满足上述两个条件之一，且系统效能报告评审通过，则煺出效能测试。
十、客户验收测试和测试报告评核
1.测试报告的内容：
(1)目的。
(2)测试环境。
(3)测试实际进度和计画进度对比。
(4)测试版本。
(5)测试结果。
(6)落差分析。
(7)测试有效性分析。
(8)输入文件。
(9)遗留缺陷分析。
(10) 缺陷清单。
2.撰写测试报告的注意事项：
(1)在测试报告的文字中只是描述问题、事情或过程等，不要出现带有明显感情色彩的字眼。
(2)提供明确的资讯，而不要出现不确定的词语。
(3) 测试报告的每一个资料都要有测试结果进行验证，且是经过多次测试验证的资料，是经得起推敲的资料，不同地方的资料要一致。
十二、测试专案管理
1.专案工作量评估模型-专案经验模拟法：
根据公司以前所作的类似专案，所累积的经验或历史资料来估算工作量。
步骤：
(1)在公司的知识库中搜索类似的专案，获得类似专案的资讯。
(2)把目前专案与类似专案进行比较，找出差异性。
(3)对差异性进行分析，找出目前专案的特点。
(4)对目前专案进行评估。
(5)最后统计出总体工作量，请相关的主管、专案经理、测试专家参与讨论，确定最后的工作量。
2.专案工作量评估模型-WBS估算法：
将专案或产品分解为实际的工作，然后分别对各个工作进行时间估算，最终求和统计得出专案或产品的测试工作量。
单元测试的步骤：
(1)如果有系统详细设计说明书，则依据详细说明书中划分的模组来计算划分的单元模组数量﹔若没有该文件，确定是否可透过其他文件估算单元模组的数量。
(2) 确定单元测试审核中每个活动的工作量。
产品整合测试的步骤：
(1)把整个系统分解成子系统，确定每个子系统的介面数量。
(2)对每两个子系统之间含有介面的子系统进行评估，需要建构多少测试案例覆盖介面，也要考虑介面之间的测试方案。
(3) 需要考虑整个整合测试所用的工作量。
系统功能测试的步骤：
(1)把整个系统中的各子系统分解成需求点 / 功能点，在各功能点上确定运算元素，确定功能点的划分密度。
(2)统计出所有的需求点为整个系统中的功能需求总数，再考虑测试中实际方案的工作量，是否考虑自动化测试、是否需要建构大量基础资料等。
(3)需要考虑整个系统功能测试所用的工作量。
系统效能测试的步骤：
(1)把整个系统中的效能需求点整理出来，包括功能测试之外的所有测试行为。
(2)评估每个效能点需要的工时，形成整个系统效能测试的总工时。
3.专案工作量评估模型-Delphi 法：
要求有多种相关经验的人参与，互相说服对方。
(1)专案协调人和各测试专家和专案经理介绍专案规格和估计表格。
(2)专案协调人召集小组会，各测试专家和专案经理讨论与规模相关的因素。
(3)各测试专家匿名填写迭代表格。
(4)专案协调人整理出一个估计总结，以迭代表格的形式送回给测试专家。
(5)专案协调人召集小组会，讨论较大的估计差异。
(6)测试专家复查估计总结，并在迭代表格上提交另一个不记名估计。
(7)重复步骤4~6，直到达到一个最低和最高估计基本一致。
- 评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）
不错哦！！！