概述
软件产品测试
编辑
软件工程：采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能得到的最后的技术方法结合起来。,2、基准配置又称为
基线配置，是经过阶段评审后的
软件配置成分，3、
软件工程强调生命周期方法学和各种
结构分析及结构设计技术
目录
1复习资料编辑
1、
软件工程：采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能得到的最后的技术方法结合起来。
2、基准配置又称为
基线配置，是经过阶段评审后的
软件配置成分
3、
软件工程强调生命周期方法学和各种
结构分析及结构设计技术
4、
软件工程的七条基本原理（1983年，由B.W.BOEHM提出）：
(1)用分阶段的生命周期计划严格管理。(2).坚持阶段评审。(3).实行严格的产品控制。(4).采用现代程序设计技术。(5).结果应能清楚的审查。(6).开发小组人员应少而精。(7).承认不断改进
软件工程实践的必要性。
5生命周期应该知道严格的六类计划：
（1）.项目概要计划。（2）.里程碑计划。（3）.项目
控制计划。（4）.产品
控制计划。（5）.验证计划。（6）.运行维护计划。
6、
软件生命周期由软件定义（细分三个阶段问题定义、可行性研究、
需求分析）、
软件开发（细分
总体设计、
详细设计、编码、
单元测试、综合测试）和
软件维护三个时期组成。
7、
软件维护通常有四类维护活动：a.
改正性维护。b.适应性维护。c.完善性维护。d.预防性维护。
8、
软件设计文档包含：构架、数据流示意图、状态变化示意图、
流程图、注释代码。
9、软件测试文档：
测试计划、
测试用例、
软件缺陷报告、归纳、统计和总结。
10、开发进度表：Gantt图表
11、软件产品组成：帮助文件、用户手册、样本和示例、标签、产品支持信息、图标和标志、
错误信息、广告和宣传材料、软件的安装说明、软件说明文件、测试错误提示信息。
12、软件是计算机系统中硬件相互依存的另一部分，它包括程序、相关数据及其说明文档。
13、测试人员在
软件开发过程中的任务：寻找BUG；避免软件开发过程中的缺陷；
衡量软件的品质；关注用户的需求。
14软件测试的目的：第一是确认软件的质量，第二提供信息，第三软件测试包括软件产品的测试还有软件开发过程。
15、软件与工业产品相比具有的特性：软件是一种逻辑实体，具有抽象性；软件没有明显的制作过程；软件在实用过程中没有磨损，老化的问题；软件对硬件和环境有着不同程度的依赖性；软件的开发至今尚未完全摆脱手工式的开发方式生产效率低；软件是复杂的，以后会更加复杂；软件的成本相当贵软件工作的牵涉到很多社会因素
16、
软件危机是
计算机软件在它的开发和维护过程中所遇到的一系列严重问题，概括地说，主要包含主要包含两个方面：如何开发软件，怎么满足日益发展的需求；如何维护数量不断膨胀的已有软件。
17、
软件危机的主要表现：
对软件开发成本和进度的估计常常不准确；用户对已完成的
软件系统不满意的现象经常发生；软件产品的质量靠不住；软件常常是不能维护；软件通常没有适当的文档资料；软件成本在
计算机系统总成本中所占比例在上升；软件开发生产率提高的速度跟不上计算机应用迅速普及深入的趋势。
18、
软件危机的内在原因：软件生产本身存在着复杂性；
软件开发使用的方法和技术
19、符合下面任一个就是
软件错误：软件未达到产品说明书中已经标明的功能；软件出现了产品说明书中指明不会出现的错误；软件功能超出了产品说明书指明的范围；软件未达到产品说明书虽未指出但应达到的目标；
软件测试员认为软件难以理解不易使用或者用户认为软件使用效果不好
20、软件测试使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求，或弄清预期结果与实际结果之间的差别。
21、
软件质量的衡量：在正确的时间用正确的方式把一个工作做正确 ；符合一些应用标准的要求；质量本身是软件达到最开始所设定的要求；质量代表它符合客户的需要。
22、软件测试的总目标是确保软件的质量
23、TMM测试成成熟度的5个级别：
Phase 0:.测试和调试没有区别
Phase 1:测试的目的是为了表明软件能工作
Phase2:测试的目的是为了表明软件不能正常工作
Phase3:测试的目的不是为了证明什么，而是为了把软件不能正常工作的预知风险减低到能够接受的程度
Phase4:测试不是行为，而是一种自觉的约束 不用太多的测试投入到产生风险的软件上
23、
测试工程师服务对象有四类人：软件用户、项目经理、
程序员、
技术文档工程师市场开发人员和
技术支持工程师
24、软件测试能做好的三件事：
（1）证明
获取系统在可接受风险范围内可用的信心
尝试在非正常情况和条件下的功能和特性
保证产品的完整性
（2） 检测
发现错误和系统不足
定义系统的能力和局限性
提供组件、工作产品和系统的质量信息
（ 3 ）预防
澄清系统的规格和性能
尽可能减少错误的信息
在过程中尽早坚持错误
确认问题和风险，并提前发现解决问题
25、软件测试的原则：从用户角度是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品。从开发者的角度是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件的信心。
26、达到原则需注意的地方：
（1）应当把“尽早和不断地测试”作为开发者的座右铭
（2）程序员应该避免检测自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
（3）设计
测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况要制造极端状态和意外状态。
（4）一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大关系。
（5）对测试错误结果一定要有一个确认的过程，一般由A测试出来的错误，一定要由一个B来确认，严重的错误可以召开评审会进行讨论和分析。
（6）制定严格的
测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
（7）
回归测试的关系性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
（8）妥善保存一切
测试过程文档，
27、软件测试的对象：
需求分析、
概要设计、
详细设计以及程序编码等各段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及
源程序。所以软件测试贯穿整个软件定义与开发期间。
28、软件测试过程模型
（1）
V模型，单元和
集成测试应检测程序的执行是否满足
软件设计者的要求；
系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
验收测试确定软件的实现是否满足用户的要求。局限：他仅仅把测试作为爱编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽略了测试活动对
需求分析、
系统设计等活动的验证和确认的功能。
（2）W模型，测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。有利于今早的、全面的发现问题。局限：无法支持
迭代的开发模型。对与当前软件开发复杂多变的情况，W模型并不能解决管理面临的困惑。
（3）
H模型，软件测试是一个独立的流程，贯穿产品的整个周期，与其他流程并发的进行。
29、
黑盒测试的定义：黑盒测试又称
功能测试、
数据驱动测试或基于规格说明的测试，是一种从用户观点出发的测试，把测试对象看做一个黑盒子在不考虑程序内部结构和内部特性，测试者只知道该程序输入和输出之间的关系或程序功能的情况下，依靠能够反映这一关系和程序功能需求规格的说明书，来确定
测试用例和推断测试结果的正确性。
30、
白盒测试定义：白盒测试又称结构测试、逻辑驱动测试或基于程序的测试。它依赖于程序细节的严密检验，针对特定条件和循环设计
测试用例，对软件的逻辑
路径进行测试。在程序的不同点检验程序的状态，来判定其实际情况是否与预期的状态相一致。
31、最常见的程序覆盖有：
（1）
语句覆盖。它要求被
测试程序的每一条可执行语句在测试中至少执行一次，这是最弱的
逻辑覆盖准则。（2）
分支覆盖或
判定覆盖。要求程序中所有判断的分支至少执行一次。（3）
条件覆盖。当判断式中含有多个条件时，要求每个条件的取值至少一次为真。一次为假（4）判定/
条件覆盖。设计足够的
测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。（5）
路径覆盖。设计
测试用例，覆盖程序中所有可能的路径 （6）条件组合。设计
测试用例，使得每个判定条件结果的所有可能组合至少出现一次。
32、
黑盒测试主要发现的错误：是否有不正确或遗漏的功能、在接口上输入是否能正确地接受能否输出正确的结果、是否有
数据结构错误或外部信息访问错误、性能上是否能够满足要求、是否有初始化或终止性错误。
33、
白盒测试主要检查的地方：对
程序模块的所有独立的执行路径至少测试一遍、对所有的逻辑判定真假取值各至少测一遍、在循环的边界和运行的界限内执行循环体、测试内部
数据结构的有效性。
34、两都比较
|
比较内容
|
黑盒测试
|
白盒测试
|
|
规划方面
|
针对功能的测试
|
针对结构的测试
|
|
优势方面
|
能确保从用户的角度出发进行测试
|
能够对程序内部的特定部位进行覆盖测试
|
|
欠缺方面
|
无法测试程序内部特定部位如果规划说明有误，则无法发现问题
|
无法检验程序的外部特性，无法对未来实现规格说明的程序内部欠缺部分进行测试
|
|
应用举例
|
边界值分析、等价值划分、
错误推断法、因果图法
|
语句覆盖、判断覆盖、条件覆盖、判断/条件覆盖、路经覆盖
|
35、
静态分析技术：是一种不通过执行程序而进行测试的技术。功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。工具有：
语法分析器、符号执行器
2软件检视编辑
36、 动态分析技术：动态分析技术的主要特征是计算机必须真正运行被测试的程序，通过输入
测试用例对其运行情况进行分析。
在动态分析技术中，最重要的是路径和分支测试。
路径测试度量程序的最主要的质量特性是复杂度。分支测试需要程序中的每个分支至少被经过一次
37、软件测试的过程：单元（模块）测试、集成（组装或联调）测试、确认（合格性）测试、
系统测试和
验收测试。
38、
软件质量是与软件产品满足明确或隐含需求的能力有关的特征和特性的总和。
软件质量可用六个特性来评价：功能性、可靠性、易用性、效率、可维护性和可一致性
39、全面质量管理含义：是一个组织以质量为中心，以全员参与为基础，目的在于通过顾客满意和本组织所有成员及社会受益而达到长期成功的管理途径。
40、全面质量管理特点：全员参加；全过程；全面运用一切有效方法；全面控制质量因素。（三全：全员、全过程、全方位）
41、全面质量管理活的科学程序——PDCA（plan计划,do实施,check检查,action处理）
42、
单元测试是软件开发过程中要进行的最低级的测试活动，在
单元测试活动中，软件的独立单元将在与程序的其他部分像个的情况下进行测试。
在
结构化语言编程中，要测试的单元是函数或子过程。面向对像语言中要测试的基本单元是类。
第四代语言中测试的基本单元它被典型划分一个菜单或显示界面。
43．静态分析：是对软件的
源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。
44、动态分析：是通过观察软件运行时的动作，来提供执行跟踪、时间分析以及
测试覆盖度方面的信息。
45.对
单元测试认识的误区
1）.它浪费了太多的时间。
2）.它仅仅证明了这些代码做了什么。
3）.一个很优秀的程序员是不是可以不进行
单元测试。
4）.不管怎么样，
集成测试将会被抓住对方的Bug。
5）.它的成本效率不高。
46、
单元测试的目的
1）.保证局部代码质量。
2）.保证代码整体结构良好。
3）
单元测试使排除代码错误的成本最小化。
4）.
单元测试大幅度降低了后期测试和升级维护的时间成本。
5）.
单元测试自然的使开发流程变得“敏捷”，可以适应频繁变动的需求，因为整体结构良好的代码具有较好的可扩展性，自动
回归测试又能保证修改不会引入新的错误。
47、
单元测试工具分类：代码
检查工具、覆盖率测试工具、.内存检查 、性能检查、质量分析工具
48、Visual Unit,简称VU，新一代
单元测试工具，功能强大，使用简单，完全可视化，不需要写测试代码。
49、
单元测试的内容
1）.模块接口、；测试模块的
数据流。
测试项目有：
（1）调用所测模块时的输入参数与模块的
形式参数在个数、属性、顺序上是否匹配；
(2) 所测模块调用子模块时，它输入给子模块的参数与子模块中的
形式参数在个数、属性、顺序上是否匹配。
（3）.是否修改了只做输入用的
形式参数。
（4）输出给标准的参数在个数、属性、顺序上是否正确。
（5）.全局量的定义在各模块中是否一致。
（6）.限制是否通过
形式参数来传送。
2）.局部数据结构测试：模块的局部数据结构是最常见的错误来源，应设计
测试用例以坚持以下错误：
（1）.检查不正确或不一致的
数据类型说明
（2）.使用的未赋值或尚未初始化的
变量
（3）。错误的初始值或错误的默认值
（4）.变量名拼写错误或书写错误
（5）.不一致的
数据类型
3）
路径测试；对基本执行路径和循环进行测试会发现大量的错误。根据
白盒测试和
黑盒测试用例设计方法设计
测试用例。
（1）常见的不正确计算.
（2）.常见的比较和
控制流错误
4）错误处理测试
（1）.出错的描述难以理解
（2）.出错的描述不足以对错误定位和确定出错的原因
（3）.显示的错误与实际的错误不符
（4）.对错误的条件处理不正确
（5）.在对错进行处理之前，错误条件已经引起系统的干预等
5）边界测试
50、进行
单元测试的必要性
（1）.即使在没有工具支持的情况下，
单元测试能够节约时间
（2）.有效的
单元测试同时也是在审查软件的规格说明
（3）.最优秀的程序员也会犯错误，也得惊醒
单元测试（4）.
集成测试不可能解决所有的缺陷
（5）.
单元测试的成本效率高
51、
单元测试和
集成测试的区别
（1）测试对象有所区别。
集成测试的被测对象是在
概要设计中规划的模块及这些模块间的组合。
单元测试的测试对象是这些模块下实现具体功能的单元，一般是对应
详细设计中所描述的设计单位。
（2）
集成测试关注的是模块间的接口，接口之间的数据传递关系，以及单元组合后是否实现预计的功能，
集成测试组装的对象比
单元测试的对象级别高。
52、
单元测试和
系统测试的区别
两者比较明显，一般来说
单元测试属于
白盒测试，关注的是单元的具体实现、内聚的
逻辑结构、数据流向等，
系统测试属于黑盒测试，是站在用户角度上面看待系统，对系统进行测试，证明系统是否已经满足用户要求，其测试是基于需求规格说明书。
53、
单元测试的用例设计思路
一个完整的
单元测试不仅仅要进行正向测试，即测试被测单元是否做了它应该做的事情，同时还应该做逆向测试，即被测单元有没有做并不希望它做的事情。
（1）.为系统运行设计用例
（2）.为正向测试设计用例
（3）.为逆向测试设计用例
（4）.为满足特殊需求设计用例
（5）.代码覆盖设计用例
（6）.覆盖率指标完整设计用例
可使用的测试分析技术:分支测试、条件测试、数据定义使用测试和状态
转换测试
54、
白盒测试的目的：通过检查软件内部的
逻辑结构，对软件中的逻辑
路径进行覆盖测试;再程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
55、
白盒测试的特点：依据软件说明书进行测试，对程序内部细节惊醒严密检验，针对特定条件设计
测试用例，对软件逻辑
路径进行覆盖测试。
56、
白盒测试实施步骤：
测试计划阶段、测试设计阶段、设计执行阶段、测试总结阶段。
57、
白盒测试方法：静态分析法和动态分析法。
58、VU特点
使用VU，黑盒方面，可以轻松完成
功能测试、边界测试、速度测试：白盒方面，可以轻松完成
语句覆盖、
条件覆盖、
分支覆盖、
路径覆盖、使用VU随时可以用
回归测试检验修改是否引入新的错误
59、单元
测试用例设计方法
（1）规范导出法
规范导出的测试是根据相关的规范描述来设计
测试用例的，每一个
测试用例用来测试一个或多个规范陈述语句。
（2）等价类划分
等价类划分是一种正式的
测试用例设计方法，它基于被测单元的输入，输出所做的划分，对每一个划分中的所有输入、被测单元有等价的行为，划分也可以根据软件所存取的数据确定，包括时间、输入输出顺序、状态。
（3）边界值分析法
边界值分析使用与等价类测试方法相同的等价类划分，只是边界值分析假定错误更多地存在于两个划分的边界上，相应地为边界上及其两侧的情况设计
测试用例。
（4）状态转移测试法
对于以
状态机为模型或设计为状态机的软件，该测试是合适的测试方法。
测试用例通过能导致状态迁移的事件来测试状态之间的转换。用这种方法可设计逆向的
测试用例，如状态和事件的非法组合。
（5）分支测试法
在分支测试中，根据单元中的
控制流分支或判断点来设计
测试用例，通常用来达到一定的
判定覆盖率
（6）条件测试法
条件测试中包含了许多
测试用例设计技术，它们都致力于弥补在遇到复杂逻辑条件时分支测试的弱点
（7）数据定义-使用测试法
（8）错误猜测法
它是基于经验和其他一些测试技术的方法。
60、六种覆盖方法
:
语句覆盖、
判定覆盖、
条件覆盖、
判定条件覆盖、
条件组合覆盖、
路径覆盖。
（1）语句覆盖
主要特点：
语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的
测试用例，使得程序中每条语句至少被执行一次。
（2.）
判定覆盖
主要特点、；判定覆盖又称
分支覆盖，它要求设计足够多的
测试用例，使得程序每个判定至少执行有一次为真值，有一次为假值，即：程序中每个分支至少执行一次，每个判断的取真、假至少执行一次。
（3）.
条件覆盖
主要特点：
条件覆盖要求设计足够多的
测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，一次为假值、
（4. ）
判定条件覆盖
主要特点：设计足够多的
测试用例，使得判定中每个条件的所有可能结果至少出现一次次。每个判定本身设计有可能结果至少出现一次。
（5）.组合覆盖
主要特点：要求设计足够多的测试用列，使得每个判定中的条件结果的梭鱼哦肯能组合至少出现一次。
（6.）
路径覆盖
主要特点： 设计足够多的
测试用例，覆盖程序中所有可能的路径
61
集成测试（
组装测试）其测试对象包括单元间的接口以及集成后的功能和性能，依据软件
概要设计说明书。
62
集成测试的含义（
组装测试）：在单元测试的基础上，应根据
概要设计的要求将软件中的各单元组装成子系统或系统，在单元的组装过程中，应对单元进行整体上测试，发现并清除各单元中出现的问题，确保集成到一起的各单元能作为一个整体完成预期的功能。
63
集成测试应考虑：a将各模块组装起来的过程中穿越模块接口的数据是否会丢失b各子功能组合起来能否达到预期的父功能c某模块的功能是否会对另一个模块的功能产生不利的影响d全局
数据结构是否存在问题e单个模块的误差累积起来是否会放大到不可接受的程度。
64接口的分类：函数接口，消息接口，其它接口。
65
集成测试的优点：a针对性强，较易发现错误并找出错误的原因和位置。b能有效的模拟几乎所有的实际执行的流程故能更有效的发现软件中的错误c 发现错误的修复成本要远远小于
系统测试阶段的错误修复成本。
66、
集成测试和
系统测试区别：
集成测试的的集成过程中对功能和性能的测试，它主要依据是软件的
概要设计说明书。
系统测试是对全部模块集成完毕的软件进行功能、性能及其他特性的测试，检测其与系统中其他元素能否
协同工作，以满足用户的各种需求，它主要依据
软件需求规格说明书和相关行业标准。
67
灰盒测试：一种介于
黑盒测试和
白盒测试之间的测试策略，它基于程序运行的外部表现，同时又结合程序内部
逻辑结构来设计测试用例。
68
灰盒测试的优点：a能够进行基于需求的测试和基于
路径的覆盖测试。B可深入被测对象的内部，便于错误的识别分析和解决c能够保证设计的黑盒测试用例的完整性 防止功能或功能组合的遗漏d能够减小需求或设计不详细或不完整性对测试有效性造成影响。
69
集成测试的策略：a一次性集成（大爆炸集成）b自顶向下集成c自底向上集成d混合式集成e核心系统先行集成f高频集成g基于消息的集成h基于使用的集成、、
70一次性集成：又称大爆炸集成，是一种非增值式集成方式；
71一次性集成策略：首先对每个单元进行
单元测试然后一次性的将所有单元集成在一起，对它们进行测试，发现并清除在单元连接过程中出现的问题，得到最终要求的
软件系统.
72自顶向下集成方式：根据软件的模块结构图按控制层次从高到低的顺序对模块进行集成，也就是从高到低向下逐步集成，并在集成过程中进行测试，直至组装成符合要求的的最终
软件系统。
73自顶向下集成的步骤：a以主模块为被测模块，主模块的下属模块则用
桩模块代替。b采用深度优先或宽度优先的策略，用实际模块代替相应的
桩模块，它们的直接下属模块则又用装模块代替与一侧模块或子系统集成为新的子系统。C对新形成的子系统进行测试。发现和排除模块集成过程中引起的错误，并做
回归测试d若所有的模块都已集成到系统中，则结束,否则转b.
74.自顶向下集成方式的优点：可以及早地发现和修复模块结构图中的主要控制点存在的问题，以减少以后的返工；能较早地验证功能或行性；最多只需一个
驱动模块，减少了驱动模块的开发成本；支持故障隔离。
75、自顶向下集成方式的缺点：需要开发和维护大量的
桩模块;由于桩模块很难模拟实际子模块的功能，到组装后期易出错，会导致大量的
回归测试;为了在效性地进行集成测试，
软件系统的控制结构应具有较高的
可测试性；易导致底层模块的测试不够充分。
76高频集成方式：指同步于
软件开发过程，每隔一段时间开发人员的现有代码进行一次
集成测试。
77自底向上集成方式：根据软件的模块结构图按控制层次从低到高的顺序对模块进行集成，也就是从最底层模块向最高层逐步集成，并在集成过程中进行测试，直至组装成符合要求的的最终
软件系统。
78自底向上集成方式的步骤：a为最底层模块开发
驱动模块对最底层模块进行测试。B用实际模块代替
驱动模块，与直属其子模块集成一个子系统。C为新形成的子系统开发驱动模块，对该子系统进行测试。D若该子系统以对应为主控模块，即最高层模块，则测试结束。否则转B。
79自底向上集成方式的优点：a大大减少的
驱动模块的开发，虽然需要开发大量的驱动模块，但其开发成本毕竟比装模块的成本小。B设计复杂算法和真正输入输出的模块往往在底层，它们是最容易出现问题的的模块，最先对底层模块进行测试，减少了
回归测试的成本。C在集成的早期很可能实现对模块的并行测试，这提高了
集成测试的效率。D支持故障隔离。
80、自底向上集成方式的缺点：需开发大量的
驱动模块，帮带来了一定的测试成本；不能及早地发现和修复模块结构图中的主要控制点存在的问题；对底层模块的异常很难测试到。
81混合式集成方式：结合了自顶向下集成方式和自底向上集成方式的优点，在对一个软件的集成测试过程中，综合使用了此两种集成方案。
82核心系统先行集成方式：先对核心软件部件进行测试，在此基础上在按各外部软件部件的重要程度逐个集成到核心系统中
83基于消息的集成方式：对于许多基于
状态机的系统如
嵌入式系统
面向对象方式开发系统，模块间的接口主要通过消息来实现因而验证消息路径的正确性在这类
软件系统的集成测试中具有重要意义。
84、基于使用的集成方式：先对各个类间的依赖关系进行分析，测试独立的类再测试使用一些服务器类的类，逐步测试具有依赖性的类，直至整个系统构造完成，从而验证类间接口的正确性。
85、
集成测试策略的选取：一次性集成多用于系统规模小的测试项目；自顶向下集成、自底向上集成、混合式集成多用于采用
结构化方法开发的软件项目；基于消息的集成方式用于
嵌入式系统、
面向对象系统；基于使用的集成方式用于面向对象系统中；核心系统先行集成和高频集成方式用于许多复杂软件项目。
86、按以下思路可确定集成模块：确定当前主要希望测试的模块：确定与该模块关系密切的模块；将该模块与关系最紧密的模块进行集成；再依次考虑集成模块的外围模块。
87、在
集成测试中合理的模块划分的特点：被集成的模块关系紧密，共同完成某功能：外围模块便于屏弊；外围模块发给被集成模块的消息能模拟大部分情况；模拟外围模块发给被集成模块的消息便于构造、修改。
88、关键模块具有的特征：完成需求规格说明中的关键功能：中软件模块结构图中处于较高层次；较复杂，易出错；有明确的性能要求；被频繁使用。
89
集成测试的的步骤：a计划集成测试b设计集成测试c执行集成测试d分析测试结果并提交
测试报告
90制定集成
测试计划应考虑的因素：a测试的类容b集成测试策略c模块代码编制和测试进度是否于集成测试的顺序一致d
测试过程中需要的
软件工具及硬件设备。
91
集成测试完成的标志：a成功执行了集成测试计划中所规定的多有测试内容b修正了集成测试中发现的错误c测试结果通过了专门小组的审评。
92.
确认测试又称为有效性测试。它的任务是验证软件的功能和性能，以及其特性是否与用户
的要求一致。
93.
系统测试是将已集成好的
软件系统，作为计算机系统的一个元素，与
计算机硬件、
外设、
支持软件、数据和操作人员等其他系统元素结合在一起，在实际使用环境下，对
计算机系统
进行一系列的组装和
确认测试。
系统测试实际上包含
确认测试
94.
系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合与之矛盾
的地方，以验证
软件系统的功能和性能等满足其规约所指定的要求。
测试用例依照需求规格说明书设计。 95、
系统测试的种类：
功能测试、
性能测试、GUI测试
96、
功能测试是
系统测试中最基本的测试，它不管软件内部的实现逻辑，主要根据产品的规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格。
97、
功能测试内容：是否有不正确或遗漏的功能：功能实现是否满足用户需求和系统设计的隐藏需求；能否正确地接受输入；能否正确地输出结果；
98、
黑盒测试试图发现一下类型的错误：功能错误或遗漏；界面错误；
数据结构或
外部数据访问错误；性能错误；初始化和终止错误
99、
黑盒测试的测试用例设计方法：
（1）等价类划分是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一个子集中选取少数具有代表性的数据作为
测试用例。
划分等价类：等价类是指某个输入域的子集合。
有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合
无效等价类：和有效等价类的定义恰巧相反
（2）边界值分析法
（3）错误推测法：列举程序中所有可能有的错误和容易发生错误的特殊情况，来设计
测试用例。
（4）因果图方法：因果图生成
测试用例步骤：
A分析软件规格说明描述中，确定原因和结果，并给每个原因和结果赋予一个
标识符
B分析软件规格说明描述中的语义，找出原因与结果间，原因与原因间的关系，画出因果图
C由于语法和环境限制，在图上用一些记号表明约束或限制条件
D把因果图转换为判定表
E把
判定表的每一列拿出来作为依据，设计
测试用例。
（5）判定驱动分析方法
判定表的组成：
条件桩、动作桩、条件项、动作项
规则：是指任何一个条件组合的特定取值及其相应要执行的操作
判定表的建立步骤：
确定规则的个数；列出所有的条件桩和动作桩；填入条件项；入动作项，等到初始
判定表；简化。
100.WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。
101、WinRunner的特点在于：与传统的
手工测试相比，它能快捷、批量地完成功能点测试；能针对相同
测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差；
102.WinRunner的工作流程大致可以分为六个步骤
①识别应用程序的GUI ②建立测试脚本 ③对测试脚本出错 ④在新版应用程序执行测试脚本 ⑤分析测试结果 ⑥回报缺陷
103.GUI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，
文字、图片组合是否完美，背景是否美观，操作是否友好等等。
104、
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件按来对系统的
各项性能指标进行测试。
105
性能测试目的是验证
软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，
优化软件，最后起到优化系统的目的。主要包括以下几个方面：
。评估系统的能力
。识别体系中的弱点
。系统调优
。检测软件中的问题
。验证稳定性和可靠性
106.
性能测试主要测试软件的性能，包括
负载测试，
强度测试，数据库
容量测试，
基准测试
以及竞争测试等。
107、
负载测试指数据在超负荷中运行，查程序是否能承担
108、
强度测试指在
系统资源特别低的情况下
软件系统运行情况
18、数据库
容量测试指通过
存储过程往数据库表中插入一定数量的数据，看相关页面的显示。
109、
基准测试与现有系统比较，检验是否与类似的产品有竞争性
110、竞争测试指使用各种资源，看其与其他相关系统对资源的争夺能力
111、
系统测试的过程
（1）完成系统测试计划
（2）完成系统测试用例的设计
（3）
评审/审批系统测试计划
系统测试计划的目的是对系统测试全过程的组织、资源、原则等进行描述和约束，并制
定系统测试过程的各个阶段的确认和验证任务以及时间进度安排，并提出对各项任务的评
估、风险分析和管理需求。
为了保证
系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。这就需要
我们在测试设计中，从多方面来综合考虑系统规格的实现情况。通常需要从以下几个层次
来进行设计：
用户层、
应用层、功能层、子系统层、协议层。
112、WinRunner是功能测试工具
113.WinRunner的测试过程分六个步骤
①教WinRunner识别被测软件中的对象 ②录制脚本 ③调试测试 ④执行测试
⑤查看测试结果 ⑥报告发现的错误
114、软件测试文档就是为将软件测试当作一个项目一样实施计划和管理而引入的，它为测试项目的组织、规划和管理提供了一个规范化的架构。
115、软件测试文档主要包括
测试计划、测试用例、测试规程、测试事件报告、测试总结报告等。测试文档总所规定的内容可以作为对
测试过程完备性的对照检查表，有助于提高测试工程每个阶段的能见度，极大地提高了测试工作的可管理性。
为了统一测试文档的书写标准，IEEE/ANSI制定了829-1983标准，还有其他的一些也用于指导软件测试文档的编写，如我国制定的《计算机软件测试文件百年之规范（GB/T 9386-1988）》
116、 测试文档编写规范（GB/T 9386-1988）简介
（1）.引用标准
该规范的引用标准为：
GB/T 11457
软件工程术语
GB 8566 计算机软件开发规范
GB 8567
计算机软件产品开发文件编制指南
（2）.关键术语定义
设计层：软件项的设计分解（如系统，子系统，程序，模块）
通过准则：一个软件项或软件特性的测试是否通过的判别依据
软件特性：软件项的显著特性（如功能，性能或可移植性）
软件项：源代码，
目标代码，
作业控制代码，控制数据或这些项的集合。
测试项：作为测试对象的软件项
（3）.规范的主要内容
该规范确定了各个测试文件的格式和内容，所提出的文件类型包括
测试计划，测试说明和
测试报告。
测试计划免除测试活动的范围，方法，资源和进度，他规定被测试的项，被测试的特性，应完成的测试任务，担任各项工作的人员职责及与本计划有关的风险等。
117、测试说明包括三类文件
测试设计说明：详细描述测试方法，规定该设计及其有关测试所包括的特性，还规定完成测试所需的
测试用例和测试规程，并规定特性的通过准则。
测试用例说明：列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试用例时，对测试规程的各种限制。将
测试用例与测试设计封开，可以使它们用于多个设计并能在其它情形下重复使用。
测试规程说明：规定对于运行系统和执行指定的
测试用例来实现有关测试设计所要求的所有步骤。
118、
测试报告则包括四类文件：
测试项传递包括：指明在开发组和测试组独立工作的情况下或者在希望正式开始测试的情况下为进行测试而传递的测试项。
测试日志：测试组用于记录测试执行过程中发生的情况。
测试事件报告：描述在测试执行期间发生并需进一步调查的一切事件。
测试总结报告：总结与测试设计说明有关的测试活动。
119.对规范的实施
使用该规范的每个单位，要规定测试阶段所应有的特性文件，并在
测试计划中规定测试完成后所能提交的全部文件。
使用该规范的每个单位应该补充规定对内容的要求和约定，及便反映总结在测试，文件控制，
配置管理和质量保证方面所用的特定方法，设备工具。
一下是规范中的文件编制实施及使用指南
（1） 实施指南
在实施测试
文件编制的初始阶段可先编写测试计划于
测试报告文件。
测试计划将为整个
测试过程提供基础。
测试报告将鼓励测试单位以良好的方式记录整个
测试过程的情况。
（2） 用法指南
在项目计划及单位标准中，指明在那些测试活动中需要那些测试文件，并可在文件中加入一些内容，使各个文件适应一个特定的
测试项及一个特定的
测试环境。
120《软件测试文件编制规范》中的内容要求
以下是规范中各个测试文件的书写格式及内容。
a
测试计划
(1)
测试计划名称（该计划的第1章）
(2) 引言（该计划的第2章）
(3)
测试项
(4) 被测试的特性
(5) 不被测试的特性
(6) 方法
(7) 项通过的准则
(8) 暂停标准和再启动要求
(9) 应提供的测试文件
(10) 测试任务
(11) 环境要求
(12) 职责
(13) 人员和训练要求
(14) 进度
(15) 风险和应急
(16) 批准
b测试设计说明
（1） 测试设计说明名称
（2） 被测试的特性
（3） 方法详述
（4）
测试用例名称
（5） 特性通过准则
c测试用例说明
（1）
测试用例说明名称
（2）
测试项
（3） 输入说明
（4） 输出说明
（5） 环境要求
（6） 特殊的规程要求 （7）用例间的依赖关系
d测试规程说明
（1） 测试规程说明名称
（2） 目的
（3） 特殊要求
（4） 规程步骤
e测试项传递报告
(1) 传递报告名称
(2) 传递项
(3) 位置
(4) 状态
(5) 批准
f测试日志
（1） 测试日志名称
（2） 描述
（3） 活动和事件条目
g测试事件报告名称
（1） 测试事件报告取一个专用名称
（2） 摘要
（3） 事件描述
（4） 影响
h测试总结报告
1. 规定该报告必须由哪些人（姓名和职务）审批，并为签名和日期留出位置。
121、
自动化测试就是通过自动化测试工具或其他手段，按照
测试工程师的预定计划进行自动的测试，其目的是减轻
手工测试的的劳动量，并且提高
软件质量 。
自动化的5个级别
|
级别
|
说明
|
优点
|
缺点
|
用法
|
|
一级
|
录制和回放
|
自动化的测试脚本能够被
自动的生成，而不需要有
任何编程知识。
|
需要大量的脚本，当需求
和应用发生变化相应的脚
本也需要重新录制
|
当测试的系统部会发生变化时
实现小规模的自动化。
|
|
二级
|
录制，编辑
回放
|
减少了脚本的数量和维护
的工作量
|
需要一定的编程知识，频繁
的变化难于维护
|
回归测试时，用于被测试的应
用有很小的变化。
|
|
三级
|
编程和回放
|
确定了测试脚本的设计，
在项目的早期就可以开
始自动化的测试
|
要求测试人员具有很好的软
件技能，包过设计开发
|
大规模的测试套件用于开发，
执行和维护的专业自动化测
试
|
|
四级
|
数据驱动的
测试
|
能够维护和使用良好的并
且有效的模拟生活中真实
逐句的测试
|
软件开发的技能是基础，并
且需要访问相关的测试数据
|
大规模的测试套件用于开发，
执行和维护的专业自动化测试
|
|
五级
|
使用动作词
的自动化
|
测试用例的设计被从测试
工具中分离出来。
|
需要一个具有使用工具技能
和开发技能的测试团队
|
专业的测试自动化将技能的使
用最优化的结合起来
|
122、软件测试自动化的优点：
（1） 提高软件测试的工作效率
（2） 对新版本执行
回归测试
（3） 解决测试的沉闷，耗时的问题
（4） 替代
手工测试的困难
（5） 具有一致性和可重复性
（6） 更好的利用资源 （7）解决测试与开发之间的矛盾 （8）增加软件的信任度
123、RPT是IBM公司基于Eclipse平台及开源的测试和监控框架Hyades,开发的
性能测试解决方案，它可以帮助测试人员和性能工程师验证系统的性能，识别和解决各种性能问题。
RPT对系统的
性能测试进行分析的过程包括四个步骤：测试记录，测试调度，测试运行，测试结果分析。
124、软件测试自动化的局限性：
（1） 不能期望自动测试能取代人工测试
（2）
自动化测试部能发现新缺陷
（3） 自动化测试工具本身不具有想象力
（4） 技术问题，组织问题，脚本维护的阻力
（5）
自动化测试并不适合于所有公司，所有项目
125、测试自动化要关注的几个问题：
（1） 测试个例的生成
（2） 测试的执行和控制
（3） 测试结果与标准的输出的对比
（4） 不吻合的测试结果的分析，分类，记录和通报
（5） 总测试状况的统计报表的产生
（6） 自动测试与开发中产品
每日构建的配合
126、自动测试工具简介：
功能测试工具：Winner QuickTest Pro Rational XDE Tester QARun Slik Test e-tester
WebFT PureTest
性能测试工具:LoadRuner Astra LoadTest Rational Robot( 性能和功能测试) QAload
SilkPerformer e-Load Web Applivation Stress Tool Webload
测试管理工具:Test Diorector QAdirector SlikCentral Test/Issue Manger e-Monitor
白盒测试工具：Rational Purifyplus Jtest(JAVA白盒) C++(C++白盒)
Test（NET白盒）
127、RFT是一款先进的，自动化的功能和回归测试工具，它适用于测试人员和GUI开发人员。
最后
以上就是激情书本为你收集整理的软件产品测试概览 软件产品测试 编辑的全部内容，希望文章能够帮你解决软件产品测试概览 软件产品测试 编辑所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复