软件测试基础

1. 引论

2. 为什么要进行软件测试？

产品质量的保证，控制成本的关键，软件可靠性确认，让企业具备国际竞争的实力

1. 测试方法

对于选题，使用黑盒测试技术，测试内容包括等价类划分测试、边界值分析测试、决策表方法使用。

使用白盒测试技术，测试内容包括语句覆盖测试、分支覆盖测试、条件覆盖测试、分支/条件覆盖测试、条件组合覆盖测试及基本路径测试。

1. 计 算 机 软 件的 测 试 目 的是：

a)、验证软件是否 满足软件开发合同或项目开发计划、系统/子系统设计文档、软件需求规格说明、

软件设计说明和软件产品说明等规定的 软 件 质量 要 求；

b)、通过测试， 发 现 软 件缺陷；

c)、为软件产品的质量测量和评价提供 依据

1. 软件测试的发展过程：

• 以功能验证为导向，测试是证明软件是正确的（正向思维）

• 以破坏性检测为导向，测试是为了找到软件中的错误（逆向思维）

• 以质量评估为导向，测试是提供产品的评估和质量度量

• 以缺陷预防为导向，测试是为了展示软件符合设计要求，发现缺陷、预防缺陷

1. 结束标准：用例全部测试；覆盖率达到标准；缺陷率达到标准；其他指标达到标准

2. 软件质量保证（SQA）活动是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用的信息，形成分析结果以指导软件过程

3. SQA与软件测试有什么关系和区别？

关系：

• SQA指导、监督软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程的改进

• 软件测试是SQA重要的手段之一，为SQA提供所需的数据，作为质量评价的客观依据

区别：

• SQA是一项管理工作，侧重于对流程的评审和监控

• 测试是一项技术性的工作，侧重对产品进行评估和验证

1. 软件测试的目的？

答：首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布

特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分

析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。

详细而严谨的可靠性增长模型可以证明这一点。

测试的目的是按照用户所需软件的质量，检查开发软件过程出现的 bug, 使得开发人员

及时修改，可以避免在开发结束的时候发现软件存在质量问题，避免公司不必要的损失。

赢得用户对公司产品的认可。

懒猪出品必属精品

测试的目的是以最少人力、物力和时间找出软件中潜在各种错误和缺陷，通过修正种

错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的

商业风险。

测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。

实施测试收集到的测试结果数据为可靠性分析提供了依据。

测试不能表明软件中不存在错误，它只能说明软件中存在错误。

1. 软件测试的原则

1. 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

2. 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。

3. 程序员应避免检查自己的程序。

4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。

5. 软件测试的原则

6. 充分注意测试中的群集现象。

经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。

7. 严格执行测试计划，排除测试的随意性。

8. 应当对每一个测试结果做全面检查。

9. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

1. 测试的主要方面

答：A、功能测试：a、链接测试 b、表单测试 c、Cookies 测试 d、设计语言测试 e、数

据库测试

B、性能测试：a、连接速度测试 b、负载测试 c、压力测试

C、接口测试：a、服务器接口 b、外部接口 c、错误处理

D、可用性测试: a、导航测试 b、图形测试 c、内容测试 d、整体界面测试

E、兼容性测试：a、平台测试 b、浏览器测试 c、视频测试 d、Modem/连接速率测试 f、

打印机测试 g、组合测试

F、安全测试：a、目录设置 b、登录 c、Session d、日志文件 e、加密 f、安全漏洞

G、代码合法性测试：a、程序代码合法性检查 b、显示代码合法性检查

H、文档测试：

测试结束的标准是什么？

答：1.用例全部执行。2.覆盖率达到标准。3.缺陷率达到标准。4.其他指标达到质量标准

软件的生命周期

答：软件生命周期是指一个计算机软件从功能确定、设计，到开发成功投入使用，并在使用中不断地修改、增补和完善，直到停止该软件的使用的全过程（从酝酿到废弃的过程）

什么是软件的生命周期？

生命周期从收到应用软件开始算起，到该软件不再使用为止。它有如下各方面的内容：

初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测

试、维护、升级、再测试、逐步淘汰 (phase-out)、等等。

软件测试的步骤是什么？

1. 测试过程按 4 个步骤进行，即单元测试（Unit Testing）、集成测试（Integrated

Testing）、确认测试（Validation Testing）和系统测试（System Testing）及发

版测试。

2. 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序

模块是否正确地实现了规定的功能。

3. 集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进

行测试。

4. 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，

以及软件配置是否完全、正确。

测试执行的问题

1. 自动化测试没有有效的利用，使得手工测试太多。

2. 测试结果的捕获没有系统性，而且没有查看或调查

3. 缺陷报告必须用手工加入缺陷跟踪系统

错误分类

1、 测试用例失败

正常错误

2、 脚本命令失败

当测试过程不能不能执行录制过程中的某个功能时，回产生这种错误，如鼠标单击按钮或选

择菜单项等。它也能指示是缺陷还是测试过程的设计问题。

3、 致命错误

导致测试停止，这种情况最好重起 Windows。

具体步骤：

1. 建立测试系统

2. 准备测试过程

3. 运行初始化过程

4. 执行测试

5. 从终止的测试恢复

6. 验证预期结果

7. 调查突发结果

8. 记录缺陷日记

如何提高测试？

提高测试需要从几个方面着手，其实只是自己的一些感觉，不一

定就需要按部就班，需要找自己适合的点。

制定完备的测试计划

清楚的认识测试计划，测试计划是一个文档，能够保证整个研

发过程中顺利执行的一个指导性文档，它描述了几个方面的问题。

1. 描述了项目的的

2. 描述了项目的开发周期

3. 描述了在测试中遇到的技术

4. 描述了测试案例的设计周期

5. 描述测试案例的执行周期

6. 描述了测试过程中用到的工具或者技术

7. 描述了测试过程中用到的资源情况

8. 描述了测试过程中可能遇到的风险以及规避方法

9） 提高案例设计水平

测试过程

1. 制定系统测试计划

2. 编写系统测试用例

3. 执行系统测试用例

4. 跟踪管理缺陷

5. 总结测试

软件测试与调试的关系

1. 测试条件已知，规程可定义，结果可预知

2. 测试可以计划，过程可控

3. 测试是检验，调试是推理过程

4. 测试表明程序失败，调试表明正确

5. 测试可不了解设计细节

6. 测试由非设计人员完成

7. 测试有理论依据

8. 测试可自动化

质量的八大特性是什么？各种特性的定义？

1）功能性：软件所实现的功能达到它的设计规范和满足用户需求的程度

2）性能：在规定条件下,实现软件功能所需的响应时间和计算机资源(CPU、内存、磁盘空间和数据吞吐量)的使用程度

3）可靠性：在满足一定条件的应用环境中，软件能够正常维持其工作的能

力，在出现一些错误操作时，软件可以具有容错性，如果软件意外退出，重新启动后可以恢复最近的软件数据

4）安全性：为了防止意外或人为的破坏，软件应具备的自身保护能力

5）使用性：用户在理解、学习和操作软件的过程中的付出的努力的难易程度

6）维护性：

软件在运行维护过程中，如果出现了运行故障或者扩展新功能和性能，软件系统是否具有可分析性和良好的扩展性，重新设计后的软件的稳定性和可测试性

7）移植性：软件从现有

运行平台向另一个运行平台过度的适应程度和平台可替换性

8）重用性：整个软件或其中一部分能作为软件包而被再利用的程度

什么是 UML？

答：Unified Modeling Language 它是一种用于描述，构造软件系统以及商业建模的语

言。简单的理解就是它可以以一种直观的方式表示出一个系统的各项内容

什么是 CMM？

CMM：Capability Maturity Model，即“能力成熟度模型”。它是一个分 5 级的、可

以描述结构完善程度的模型，用它来说明所交付的软件的效能。

比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系？

黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性，

只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。

白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及

相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。

单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。

集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。

系统测试：在所有都考虑的情况下，对系统进行测试。

验收测试：第三方进行的确认软件满足需求的测试。

需求人员需要何时参加需求分析？

答：如果条件循序 原则上来说 是越早介入需求分析越好 因为测试人员对需求理解越深刻 对测试工作的开展越有利 可以尽早的确定测试思路 减少与开发人员的交互 减少对需求理解上的偏差原则上，测试人员对需求了解得越深入对测试工作越有利，所以最好一开始就应该参加需求分析工作。这样做可以带来如下好处：

1. 测试人员全程参与需求分析，对需求了解得很深入，减少了很多与开发人员的交互，节省了时间。测试人员参与前期开发讨论，直接掌握了不清晰的需求点。

2. 早期确定测试用例的编写思路，为测试打好基础

3. 可以获取一些测试数据，为测试用例设计提供帮助

4. 可以发现需求不合理的地方，降低了测试成本。

5. 测试人员主要的工作之一就是确认系统是否正确实现了需求。

如果需求一直在变化怎么办？

答：这是一个常见的令人头疼的问题。

1. 如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

2. 如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

3. 好的代码注释和好的文档有助于开发人员作出相应的改变。

4. 只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

5. 在项目的时间表中应当留出余量，以应付可能出现的变更。

6. 尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

7. 通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

8. 要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

9. 在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

10. 在设计自动测试剧本时，试图使其有一些灵活性。

11. 在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

12. 对变更进行适当的风险分析，以减少回归测试的要求。

13. 在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

14. 少注意详细的测试计划和测试案例，要把重点放在专门的测试 (adhoc testing) 上。

怎样做好测试计划？

答：1.理解系统。从整个系统的高度了解被测系统必须满足的功能和非功能性需求。利用涉及整个系统的文档，形成对系统的整体了解。

2.及早介入。为了深入了解项目，测试人员应该在系统的开始阶段介入，可以增加对客户需求，客户问题，潜在风险，以及最重要的功能方面的理解

3.测试期望。程序员的期望是什么？客户的期望是什么？销售对测试的期望又是什么？测试目标必须是绝对的，以免说不清楚是否达到目标。

4.吸取教训。把以前工作中学习到的经验教训运用过来，对确定测试策略很有作用。

5.工作量大小。完成测试需要多少工作量？需要多少人员？

6.技术选择。系统会采取什么技术？系统会采用什么架构？这些信息有助于确定测试策略和测试工具。

7.时间表。系统开发和测试分配的时间有多长？截止日期是什么时候？

什么是“测试策略”？

答： 测试策略描述测试工程的总体方法和目标 主要包括以下三个方面：

1 确定的测试技术和工具

2 制定测试启动 停止 完成标准

3 风险分析和应对方案

其目的 是为我们更好的写出高质量的用例 提供支撑

测试策略包括哪些？

答：测试策略包括:

1、要使用的测试技术和工具；

2、测试完成标准；

3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。

什么时候编写测试用例？依据是什么？如何保证测试用例与需求的一致性？需要同行评审吗？

答：在测试计划完成之后，按照计划进度编写测试用例。依据是软件需求规格说明书通过同行评审来对用例进行评审，需要同行评审

缺陷报告包括哪些项？

答：缺陷报告包括：软件名称、版本号、功能模块、缺陷编号、对应的用例编号、编

写时间、编写人、测试员、预期结果、实际结果、缺陷描述、严重级别、优先级别

缺陷处理流程

答：测试人员提交新的 Bug 入库，错误状态为 New。

高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为 Open。

如果不是错误，则拒绝，设置为Declined(拒绝)状态。 开发人员查询状态为 Open 的 Bug，

如果不是错误，则置状态为Declined；

如果是 Bug 则修复并置状态为 Fixed。不能解决的 Bug，要留下文字说明及保持Bug 为 Open 状态。对于不能解决和延期解决的 Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

测试人员查询状态为 Fixed 的 Bug，然后验证 Bug是否已解决，如解决置 Bug 的状态为 Closed，如没有解决置状态为 Reopen。

完整的开发流程

第二章 软件测试的基本概念

1. 软件质量：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和

2. 软件质量的特征：

• 功能：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。

• 可靠：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。

• 易用：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。

• 效率：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。

• 可维护：与进行指定的修改所需的努力有关的一组属性。

• 可移植：与软件从一个环境转移到另一个环境的能力有关的一组属性。

其中每一个质量特征都分别与若干子特征相对应

1. 软件质量分为内部质量、外部质量、使用质量

2. 软件缺陷的定义：任何程序、系统中的问题，和产品设计书的不一致性，不能满足用户的需求

• 从产品内部看：软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题

• 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背

1. 软件缺陷的产生：技术问题、团队工作、软件本身

2. 修复软件缺陷的代价：越到后期，修改所付出的代价越大，修正错误的代价不是随时间线性增长，而几乎是呈指数增长的

1. 软件测试的分类：

压力测试：也称负载测试，用来检查系统在不同负载条件下的系统运行情况，特别是高负载、极限负载的系统运行情况，以发现系统不稳定性、系统性能瓶颈、内存泄漏、CPU使用率过高等问题

回归测试：为保证软件中新的变化不会对原有功能的正常使用有影响而进行的测试。也就是，满足用户需求的原有功能不应该因为代码变化而出现任何新的问题

静态测试和动态测试：

• 静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等

• 静态分析的查错和分析功能是其他方法所不能替代的

• 动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证

1. 白盒测试的概念

白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作

黒盒测试的概念：

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试

1. 软件测试级别：

2. 单元测试：针对程序系统中的最小单元---模块或组件进行测试，一般和编码同步进行。主要采用白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。通常要编写驱动模块和桩模块

单元测试一般由编程人员和测试人员共同完成，而以开发人员为主

单元测试包括代码评审

1. 集成测试：也称组装测试、联合测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试

主要目标是发现与接口有关的模块之间问题。

两种集成方式：一次性集成方式和增殖式（渐增式）集成方式。

1. 系统测试：分为功能测试和非功能测试

• 功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用

• 系统非功能性测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括：恢复测试、强度测试、安全测试、性能测试

1. 验收测试：目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样

α 测试：指软件开发公司内部人员开始试用新产品，在实际运行环境和真实应用过程中发现测试阶段所没有发现的缺陷

β 测试：指公司外部的典型用户试用，并要求用户报告异常情况、提出批评意见，然后对Beta版本进行修正和完善

Beta版本：经过α 测试和修正的软件产品称为Beta版本

1. 什么是测试用例？

为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档

1. 为什么要设计测试用例？

• 测试用例构成了设计和制定测试过程的基础

• 测试的“深度”与测试用例的数量成比例

• 测试工作量与测试用例的数量成比例

• 测试设计和开发的类型以及所需的资源主要都受控于测试用例

• 测试用例是软件测试的核心

第三章 软件测试方法

1. 白盒方法：语句覆盖、条件覆盖、判定覆盖、判定条件覆盖、条件组合覆盖、基本路径覆盖

黑盒方法：判定表方法、因果图法、正交试验法、功能图法、等价类划分法、边界值分析法、错误推断法

1. 错误推测法是测试者根据经验、知识和直觉来发现软件错误，来推测程序中可能存在的各种错误，从而有针对性的进行测试

2. 等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的

3. 等价类划分法：

1）建立等价类表，列出所有划分出的等价类：

2）为每个等价类规定一个唯一的编号；

3）设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类

4）重复3)，最后使得所有有效等价类均被测试用例所覆盖；

5）设计一个新的测试用例，使其只覆盖一个无效等价类。

6）重复5)使所有无效等价类均被覆盖。

1. 边界值分析法：

设计方法：

• 确定边界情况（输入或输出等价类的边界）

• 选取正好等于、刚刚大于或小于边界值作为测试数据

1. 判定表方法：

条件桩：列出问题的所有条件

动作桩：列出可能针对问题所采取的操作

条件项：针对所列条件的具体赋值

动作项：列出在条件项（各种取值）组合情况下应该采取的动作

规则：任何一个条件组合的特定取值及其相应要执行的操作

判定表方法步骤：

1. 列出条件桩

2. 列出动作桩

3. 填入条件项及其组合

4. 填入动作项，制定初始判定表

5. 简化、合并相似规则或者相同动作

6. 因果图法：

1. 正交试验法：

• 确定影响功能的因子与状态

• 选择一个合适的正交表

• 利用正交表构造测试数据集

1. 逻辑覆盖：以程序或系统的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖

2. 语句覆盖的基本思想是设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次

1. 判定覆盖：设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足

M：{a >0，b >0}

N：{a >1 or c >0}

1. 条件覆盖：设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次

判定条件M：

条件a>0： 取.T.时为T1 取.F.时为F1

条件b>0： 取.T.时为T2 取.F.时为F2；

判定条件N：

条件a>1： 取.T.时为T3 取.F.时为F3

条件c>1： 取.T.时为T4 取.F.时为F4

1. 判定-条件覆盖：是判定和条件覆盖设计方法的交集，即设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次

1. 条件组合覆盖：设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次（即所有组合至少出现一次）

1. 条件组合效率不高，有些测试是不必要的，判定/条件还不够强

2. 基本路径覆盖：设计所有的测试用例，来覆盖程序中的所有可能的执行路径

步骤：

1. 程序的流程图：

1. 计算程序圈复杂度

圈复杂度：代码逻辑复杂度的度量，提供了被测代码的路径数量。复杂度越高，出错的概率越大

• V(G) = 区域数量(由节点、连线包围的区域，包括图形外部区域)

• V(G) = 连线数量 - 节点数量 + 2

• V(G) = 简单可预测节点数量（判断节点数目） + 1

1. 确定基本路径

2. 准备测试用例，确保基本路径组中每一条路径被执行一次

3. 形式化方法实际上就是基于数学的方法来描述目标软件系统属性的一种技术

4. 有限状态机（ Finite State      Machine ，FSM）是对象行为建模的工具，主要作用是描述对象在其生命周期内所经历的状态序列，以及如何响应来自外界的各种事件

FSM模型包含5个元素：输入符号、输出符号、状态集合、状态转移函数和输出函数

1. 扩展有限状态机（EFSM）模型是在FSM模型基础上增加了动作和转移条件，以处理系统的数据流问题，而FSM模型只能处理系统的控制流问题。所以，EFSM包含6个元素，增加了一个初始状态，并将FSM中的“状态转换函数和输出函数”变为“变量集合和转移集合”

1. 状态图

状态表：

(1)--push [height < max-1] (3)--pop [height = 1]

(2)--push [height = max-1] (4)--pop [height > 1]

状态树：

第四章 软件测试流程和规范

1. W模型：由两个V字型模型组成，分别代表测试与开发过程，测试与开 发并行，测试伴随着整个软件开发周期，而且测试的对象不仅是程序，还包括需求定义文档、设计文档等

2. TMap（测试管理方法）：是一种结构化的、基于风险策略的测试方法体系，目的能更早地发现缺陷，以最小的成本、有效地、彻底地完成测试任务，以减少软件发布后的支持成本

TMap所定义的测试生命周期由计划和控制、准备、说明、执行和完成等阶段组成

TMap通过三项基石：坚实的组织融合（O）、正确的基础设施和工具（I）、可用的技术（T），支持整个生命周期（L），从而构成其稳固的方法体系

1. 软件测试5大学派：

2. 分析学派：认为软件是逻辑性的，将测试看作计算机科学和数学的一部分，测试工作是技术性很强的工作

3. 标准学派：把测试看作侧重成本控制并具有可重复标准的、旨在衡量项目进度的工作

4. 质量学派：测试是过程的质量控制、揭示项目质量风险的活动，测试人员扮演产品质量的守门员角色

5. 上下文驱动学派：强调人，测试所发现的每个缺陷都和相关利益者密切相关

6. 敏捷学派：测试就是验证开发是否完成，强调自动化测试

第五章 单元测试和集成测试

1. 单元测试：对软件基本的组成单元的测试

时机：一般在代码完成后由开发人员完成，QA人员辅助

概念：模块、组件、单元

单元测试的测试人员：程序开发人员和测试人员共同完成，以程序开发人员为主

1. 为什么进行单元测试：

• 尽早发现错误

• 检查代码是否符合设计和规范，有利于将来代码的维护

1. 单元测试的目标

• 单元模块被正确编码

• 信息能否正确地流入和流出单元

• 在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，全局变量在单元中的处理和影响

• 为限制数据加工而设置的边界处，能否正确工作

• 单元的运行能否做到满足特定的逻辑覆盖

1. 单元测试的任务：

2. 单元独立执行路径的测试：检查每一条独立执行路径的测试，并保证每条语句被至少执行一次

3. 单元局部数据结构的测试：检查局部数据结果完整性

4. 模块接口测试：检查模块接口是否正确

5. 单元边界条件测试：检查临界数据处理的正确性

6. 单元容错测试：预设的各种出错处理是否正确有效

7. 静态测试技术：不运行被测试程序，对代码通过检查、阅读进行分析

三步曲：互查、走查、评审

1. 单元测试的测试依据

单元测试的依据是:详细设计和概要设计

• 单元测试是对软件基本组成单元进行测试。依据是：软件详细说明书。

• 单元测试测试的不仅仅是代码，有：接口测试、局部数据结构测试、独立路径测试、独立路径测试、边界条件测试、错误处理测试、功能测试、性能测试、内存使用测试等。

1. 编码的标准：建立起来必须遵守的规则

编码的规范：建议最佳做法，推荐更好方式

实施代码规范的原因：

• 可靠性

• 可读性和可维护性

• 可移植性

1. 走查：采用讲解、讨论和模拟运行的方式进行的查找错误的活动

2. 动态测试：需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性

3. 驱动模块：对底层或子层模块进行测试所编写的调用这些模块的程序

桩模块：对顶层或上层模块进行测试时所编写的替代下层模块的程序

1. 空指针保护、格式化数字错误、字符串或数组越界错误、资源不合理使用、不当使用synchronized导致系统性能下降

2. 单元测试常用工具：JUnit、CppUnit、NUnit….

3. 单元测试工具种类：

• 代码规则/风格检查工具

• 内存资源泄露检查工具

• 代码覆盖率检查工具

• 代码性能检查工具

1. 集成测试：集成测试是将软件集成起来，对模块之间的接口进行测试

• 模块内的集成，主要是测试模块内各个接口间的交互集成关系

• 子系统内的集成，测试子系统内各个模块间的交互关系

• 系统内的集成，测试系统内各个子系统和模块间的集成关系

集成测试的测试人员：有经验的测试人员和开发者共同

1. 集成测试的模式：

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式

渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合起来测试

比较：

• 渐增式需要编写的软件较多，工作量较大

• 渐增式发现模块间接口错误较早

• 非渐增式发现错误，较难诊断，而使用渐增式，如果发生错误，则往往和最近加进来的那个模块有关

• 渐增式比非渐增式更彻底

• 渐增式需要较多的机器时间

• 非渐增式可以并行测试

1. 自顶向下集成法：从主控模块开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。

策略：深度优先或宽度优先

1. 自底向下集成法：从“原子模块”开始集成以进行测试

第六章 系统测试

1. 系统测试（特征测试）：检验系统所有元素之间协作是否合适，整个系统的性能和功能是否达到要求。其测试内容包括：功能测试，非功能测试与回归测试等。

2. 系统测试的测试人员，软件测试工程师

3. 系统测试的内容：功能测试，回归测试，非功能性试；

4. 非功能性测试（特征测试）包含哪些内容：性能测试 压力测试      容量测试 安全性测试 可靠性测试 容错性测试

5. 系统测试的测试依据：需求说明书、概要说明书、详细设计说明书，最重要的是需求说明书

6. 回归测试的目的：在程序有修改的情况下保证原有的功能正常

7. 软件修改的正确性：

• 所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；

• 不影响软件原有功能的正确性

1. 回归测试的策略及其方法：

• 再测试全部用例

• 基于风险选择测试

• 基于操作剖面选择测试

• 再测试修改的部分

1. 性能测试：为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况

2. 性能测试目标：

• 获取系统性能某些指标数据

• 为了验证系统是否达到用户提出的性能指标

• 发现系统中存在的性能瓶颈，优化系统的性能

1. 什么是测试用例 什么是测试脚本 两者的关系是什么？

为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。

测试脚本是为了进行自动化测试而编写的脚本。

测试脚本的编写必须对应相应的测试用例，

1. 简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试

静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。

动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。

黑盒测试一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。

白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般白盒测试由项目经理在程序员开发中来实现。

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。

β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

1. 软件质量保证体系是什么 国家标准中与质量保证管理相关的几个标准是什么?他们的

编号和全称是什么?

来自Wikipedia对SQA的定义，软件质量保证（SQA）：

Software Quality Assurance (SQA) consists of the software engineering processes and methods used to ensure quality. SQA encompasses the entire software development process, which may include processes such as reviewing requirements documents, source code control, code reviews, change management, configuration management, release management and of course, software testing.

SQA由一套软件工程过程和方法组成，以保证（软件的）质量。SQA贯穿整个软件开发过程，(它)应包括需求文档评审、代码控制、代码评审、变更管理、配置管理、版本管理和软件测试。

国家标准：

GB/T 8567-2006 计算机软件文档编制规范

GB/T 11457-2006 信息技术 软件工程术语

GB/T 16260.1-2006 软件工程 产品质量 第1部分：质量模型

GB/T 16260.2-2006 软件工程 产品质量 第2部分：外部度量

GB/T 16260.3-2006 软件工程 产品质量 第3部分：内部度量

GB/T 16260.4-2006 软件工程 产品质量 第4部分：使用质量的度量

GB/Z 20156-2006 软件工程 软件生成周期过程 用于项目管理的指南

GB/T 20157-2006 信息技术 软件维护

GB/T 20158-2006 信息技术 软件生成周期过程 配置管理

1. 软件产品质量特性是什么?

功能性：适应性、准确性、互操作性、依从性、安全性。

可靠性：成熟性、容错性、以恢复性。

可使用性：易理解性、易学习性、易操作性。

效率：时间特性、资源特性。

可维护性：易分析性、易变更性、稳定性、易测试性。

可移植性： 适应性、易安装性、遵循性、易替换性。

1. 软件测试的原则与策略是什么?

软件测试的原则：

教材的说法：

软件测试应尽早执行，并贯穿于整个软件生命周期

软件测试应追溯需求

测试应由第三方来构造

穷举测试是不可能的,要遵循Good-enough原则

必须确定预期输出（或结果）

必须彻底检查每个测试结果

充分注意测试中的群集现象

缺陷的二八定理

严格执行测试计划，排除测试的随意性

注意合法合理的输入，也要注意非法的非预期的输入

检查程序是否是否做了不该做的

测试应从“小规模”开始，逐步转向“大规模”

反复使用同样的测试会使软件具有抵抗力

关注缺陷的修复

另一种说法：

应当把“尽早和不断地测试”作为开发者的座右铭。

程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

另外一种回答：

答：测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该

选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误

或某类错误的测试数据，测试用例应覆盖方面：

1、 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；

测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

2、 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）

的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提

示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。

3、 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统

能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。

4、 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一

致性和正确性。

5、 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其

之间的数据调用关系进行测试。

6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边

界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附

近选取。

7、 压力测试：输入 10 条记录运行各个功能，输入 30 条记录运行，输入 50 条记录运

行。。。进行测试。

8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

懒猪出品必属精品

9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。

10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。

11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。

12、可移植性：在不同操作系统及硬件配置情况下的运行性。

13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员 已

经解决，进行下一轮的测试。

14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与

已往的测试结果比较 。

1. 结构化系统测试和功能性系统测试分别采用了哪些方法和技术?

软件测试的原则：

教材的说法：

软件测试应尽早执行，并贯穿于整个软件生命周期

软件测试应追溯需求

测试应由第三方来构造

穷举测试是不可能的,要遵循Good-enough原则

必须确定预期输出（或结果）

必须彻底检查每个测试结果

充分注意测试中的群集现象

缺陷的二八定理

严格执行测试计划，排除测试的随意性

注意合法合理的输入，也要注意非法的非预期的输入

检查程序是否是否做了不该做的

测试应从“小规模”开始，逐步转向“大规模”

反复使用同样的测试会使软件具有抵抗力

关注缺陷的修复

另一种说法：

应当把“尽早和不断地测试”作为开发者的座右铭。

程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

答案如下：

结构化系统测试技术：用于验证所开发的系统及程序的运行情况。目标是要确保产品设计在结构上合理，功能上正确。为确定实现的配置及其各功能共同作用以完成特定任务提供了一种机制。结构化测试技术由以下几种：

1）压力测试：确定系统以期望的容量执行。

压力测试技术用于检查系统面对意外情况下的大数据量时是否可以正常运行。所涉及的方面包括输入事务、内部表、磁盘空间、输出、通信、计算机容量以及人机交互等。

当应用系统所能正常处理的工作量并不确定时需要使用压力测试。压力测试意图通过对系统施加超负载事务量来达到破坏系统的目的。弱点在于准备测试的时间与在测试的实际执行过程中所消耗的资源数量都非常之大，通常在应用程序投入使用之前这种技术是无法进行的。

执行测试：系统能达到期望的熟练性。

举例：事务轮转时间充分；软硬件使用良好。

执行测试技术用于检查系统是否达到了预期在产品状态下的成熟度。执行测试可以验证系统的响应时间、轮转时间及设计性能。

在开发过程的早期就应该进行执行测试，尽早制定已经完成的系统没有达到性能指标是非常有价值的。在关键时间点进行。关键时间点指的是当前的结果会影响甚至改变系统结构的时间点。

恢复测试：系统失效之后可以恢复到可操作状态。

举例：引入失败；评估备份数据的充分性。

恢复测试技术用于确保系统在经历灾难后可以继续正常运行，它不仅可以验证恢复过程，而且可以验证过程各组件的有效性。

当用户认为系统操作的连续性对于其所涉及领域的某些功能至关重要时，需要进行恢复测试。

操作测试：系统以正常操作状态执行。

举例：确定系统可以依据文档进行运行；JCL（工作控制语言）充分。

操作测试技术主要用于检查系统在正常的操作状态下是否可以执行。操作测试可以与其它测试联合执行。

任何应用程序在成为产品之前都应进行操作测试。

（与过程的）一致性测试：系统的开发与标准和规程相一致。

举例：按标准执行；文档完整。

一致性测试技术用于验证应用程序的开发是否与信息技术指标、过程及准则相一致。一致性测试最有效的方法是过程审查。

系统开发标准和过程的一致性程度依赖于管理层对于所需遵循的特定过程和执行标准的重视程度。

安全性测试：根据组织的重要性对系统进行保护。

举例：访问拒绝；规程适当。

安全性测试技术用于评价保护性程序及安全对策的充分性。安全性缺陷不如其它类型的缺陷那么明显。安全性测试是测试过程中高度专业化的部分。分物理安全性（针对利用物理方法收集信息的手段）和逻辑安全性（针对使用计算机处理和通信能力进行非法活动信息的手段）。

当系统保护信息和资产对于组织来说意义重大时，需要进行安全性测试。

功能性系统测试用于确保系统需求与定义都得到了满足。该过程通常包含创建用于评价应用程序正确性的测试条件。用于执行功能测试的几种测试技术包括：

需求测试：系统按制定方式执行。

举例：证明系统需求；与政策、规则相一致。

需求测试技术验证系统是否正确执行其功能，并且能保证在相当长的一段时间内保持其正确性。需求测试的执行主要通过执行创建的测试条件以及功能检查单来完成，通过需求得到测试条件，然后以类似于SDLC这种特定的方式表现，生成用于评价实现的应用系统的测试数据。

任何应用程序都应该对需求进行测试，此过程应该开始于需求阶段，并一直持续到系统运行和维护阶段。

回归测试：验证系统中没有改变的部分仍能正确运行。

举例：未变更的部分正常运行；未变更的人工规程正确。

回归测试技术对已经测试过的部分进行重新测试，以保证它们在应用程序其它部分发生变更之后仍能正常运行。

当变更会对应用程序中没有变更的部分产生高风险的影响时需要进行回归测试。

错误处理测试：错误可以得到防止或检测，并被修复。

举例：将错误引入测试；错误的再次注入。

人工系统与自动系统之间差别的特点之一就是预定义的错误处理特性。错误处理测试技术用于检查应用系统正确处理发生异常的能力。错误处理测试需要一组知识丰富的人员来预见应用系统可能发生的错误。它是测试错误的引入、错误的处理，控制条件以及条件的再次正确输入。

在系统整个生命周期中都应该进行错误测试。在开发过程中，应该识别错误带来的问题并且采取相应的措施将错误减少到可以接受的程度。

人工支持测试：人机交互有效。

举例：具备人工规程；人员接受过培训。

人工支持测试技术主要包括人员在准备数据以及使用来源于自动程序数据的过程中执行所有功能。

在生命周期的全过程都应该验证人工系统功能的正确性。

系统间测试：数据可以正确地在系统间传递。

举例：系统间参数变化；系统间文档更新。

系统间测试技术用于保证应用程序间相互管理的正确性。系统间测试的一个最好的工具是集成测试工具，它允许在产品环境下进行测试，可以以最小的代价测试系统间的耦合性。

在应用系统间的参数发生变更时需要进行系统间的测试。测试的程度和类型依赖于与出错的参数相关联的风险情况。

控制测试：将系统风险控制降低到可以接受的级别。

举例：文件一致性规程正常；人工控制正确。

控制测试技术包括数据确认、文件完整性控制、评审追踪、备份和恢复、文档，以及与系统完整性相关的其它方面。主要用于确保对系统特定功能的检查。可以用于控制测试的一个方法是生成风险矩阵。

控制测试是系统测试中的一个完整的部分，占测试时间的很大比例。

平行测试：发现原系统与新系统之间的意外差异。

举例：原系统与新系统一致；原系统仍然可以工作。

平行测试技术用于检查新应用程序的结果是否与原来的应用程序或者上一版本应用程序的处理相一致。它执行冗余处理以保证新版本或者新应用程序执行的正确性；给出同一应用程序不同版本之间一致的和不一致的地方。平行测试可以对整个应用程序进行，也可对应用程序的一部分进行。

当不能确定新应用程序处理的正确性，或者当新旧版本的应用程序非常类似时，需要进行平行测试。

1. 软件测试分为几个阶段      各阶段的测试策略和要求是什么?

软件测试按阶段划分可以分为单元测试、集成测试、系统测试和<验收测试>（不一定有）几个阶段

单元测试测试策略：

自顶向下的单元测试策略

方法：先对最顶层的基本单元进行测试，把所有调用的单元做成桩模块。然后再对第二层的基本单元进行测试，使用上面已测试的单元做驱动模块。依此类推直到测试完所有基本单元。

优点：在集成测试前提供早期的集成途径。在执行上和详细设计的顺序一致。不需要开发驱动模块。

缺点：随着测试的进行，测试过程越来越复杂，开发和维护成本增加。

总结：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。

自底向上的单元测试策略

方法：先对最底层的基本单元进行测试，模拟调用该单元的单元做驱动模块。然后再对上面一层进行测试，用下面已被测试过的单元做桩模块。依此类推，直到测试完所有单元。

优点：在集成测试前提供系统早期的集成途径。不需要开发桩模块。

缺点：随着测试的进行，测试过程越来越复杂。

总结：比较合理的单元测试策略，但测试周期较长。

孤立单元测试策略

方法：不考虑每个单元与其它单元之间的关系，为每个单元设计桩模块或驱动模块。每个模块进行独立的单元测试。

优点：简单、容易操作，可达到高的结构覆盖率。

缺点：不提供一种系统早期的集成途径。

总结：最好的单元测试策略。

集成测试的测试策略：

大爆炸集成

优点：可以迅速完成集成测试；并且只要极少数的驱动和桩模块；用例也是最少的；简单；资源利用率高

缺点：一次试运行成功的可能性不大，问题定位和修改比较困难，许多接口错误很容易躲过测试。

适应于一个维护型项目或被测试系统较小

自顶向下集成

优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。

缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。

适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。

自底向上集成

优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。

缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。

适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。

三明治集成

优点：集合了自顶向下和自底向上两种策略的优点

缺点：中间层测试不充分

适应于大部分软件开发项目

基干集成

优点：具有三明治集成的优点，更适合于大型复杂项目的集成。

缺点：必须对系统的结构和相互依存性进行仔细的分析；驱动和桩开发量大；局部采用了大爆炸的策略，有些接口可能测试不充分。

嵌入式系统中常用

分层集成

适应于有明显层次关系的系统

基于功能的集成

优点：优先验证关键功能的正确性；减少驱动的开发；进度要快。

缺点：对接口测试不充分；有较大的冗余测试。

基于消息的集成

优点：优先验证关键消息的正确性；减少驱动的开发；进度要快。

缺点：对接口测试不充分；有较大的冗余测试。

基于风险的集成

优点：最具有风险的组件最早进地验证，有助于系统的快速稳定。

缺点：需要对各组件的风险有一个清晰的分析。

基于进度的集成

优点：具有较高的并行度；能够有效缩短项目的开发进度。

缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。

系统测试的测试策略：

数据和数据库完整性测试

功能测试

用户界面测试

性能评测

负载测试

强度测试

容量测试

安全性和访问控制测试

故障转移和恢复测试

配置测试

安装测试

加密测试

可用性测试

版本验证测试

文档测试

1. 面向对象的测试用例设计有几种方法？如何实现?

Berard提出了一些测试用例的设计方法，主要原则包括:

每个测试用例应当给予特殊的标识，并且还应当与测试的类有明确的联系。

测试目的应当明确。

应当为每个测试用例开发一个测试步骤列表。这个列表应包含以下一些内容：

列出所要测试对象的专门说明。

列出将要作为测试结果运行的消息和操作。

列出测试对象可能发生的例外情况。

列出外部条件（即为了正确对软件进行测试所必须有的外部环境的变化）。

列出为了帮助理解和实现测试所需要的附加信息。

主要方法：

基于故障的测试

基于故障测试也可以用于组装测试，组装测试可以发现消息联系中“可能的故障”。

“可能的故障”一般为意料之外的结果、错误地使用了操作/消息、不正确引用等。为了确定由操作（功能）引起的可能故障必须检查操作的行为。

这种方法除用于操作测试外，还可用于属性测试，用以确定其对于不同类型的对象行为是否赋予了正确的属性值。因为一个对象的“属性”是由其赋予属性的值定义的。

基于脚本的测试

基于脚本的测试主要关注用户需要做什么，而不是产品能做什么，即从用户任务（使用用例）中找出用户要做什么及去执行。

这种基于脚本的测试有助于在一个单元测试情况下检查多重系统。所以基于脚本测试用例测试比基于故障测试不仅更实际（接近用户），而且更复杂一点。

OO类的随机测试

如果一个类有多个操作（功能），这些操作（功能）序列有多种排列。而这种不变化的操作序列可随机产生，用这种可随机排列的序列来检查不同类实例的生存史，就叫随机测试。

类层次的分割测试

这种测试可以减少用完全相同的方式检查类测试用例的数目。这很像传统软件测试中的等价类划分测试。分割测试又可分三种。

基于状态的分割。按类操作是否改变类的状态来分割（归类）。

基于属性的分割。按类操作所用到的属性来分割（归类）。

基于类型的分割。按完成的功能分割（归类）。

由行为模型（状态、活动、顺序和合作图）导出的测试

状态转换图（STD）可以用来帮助导出类的动态行为的测试序列，以及这些类与之合作的类的动态行为测试序列。

1. 在软件测试各个阶段通常完成什么工作？各个阶段的结果文件是什么？包括什么内容？

单元测试阶段。各独立单元模块在与系统地其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷报告。

集成测试阶段。集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。该阶段生成集成测试报告，提交缺陷报告。

系统测试阶段。将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。

1. 你以前工作时的测试流程是什么？

公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

1. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

1．等价类划分

划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

2．边界值分析法

边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3．错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4．因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

1. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

5、是否有初始化或终止性错误？

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

1. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

1. 您认为做好测试计划工作的关键是什么？

1. 明确测试的目标，增强测试计划的实用性

编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确

2．坚持“5W”规则，明确内容与过程

“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。

3．采用评审和更新机制，保证测试计划满足实际需求

测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。

4. 分别创建测试计划与测试详细规格、测试用例

应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

1. 性能测试的基本过程

2. 确定性能测试需求

3. 根据测试需求，选择测试工具和开发相应的测试脚本

4. 建立性能测试负载模型

5. 执行性能测试

6. 提交性能测试报告

第七章 验收测试

1. 验收测试：在软件产品完成了系统功能和非系统功能测试之后、产品发布之前所进行的软件测试活动， 检查软件是否符合合同要求，包括需求规格说明、设计规格说明和用户手册等

前提：系统或软件产品已通过了系统测试的软件系统

1. 验收测试的内容：

• 易用性测试（用户界面和可用性测试）

• 兼容性测试（软件兼容性测试、数据共享兼容性测试、硬件兼容性测试）

• 安装测试和可恢复性测试、文档测试等（安装与卸载测试、可恢复性测试）

• 验收测试的内容（正确性、完备性、易理解性、一致性）

1. 验收测试的测试人员：用户和测试部门共同完成

2. 验收测试的测试依据：国家规范、行业标准、合同条款、用户确认的需求规格说明书

3. 验收测试完成标准：

• 完全执行了验收测试计划中的每个测试用例

• 在验收测试中发现的错误已经得到修改并且通过了测试、或经过评估留待下一版本中修改

• 完成软件验收测试报告

1. α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。

2. 经过α测试调整的软件产品称为β版本。

3. β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

第八章 软件测试本地化

1. 软件国际化（I18N）：借助功能设计和代码实现中软件系统有能力处理多种语言和不同文化，使创建不同语言版本时，不需要重新编写代码的软件工程方法

2. 软件本地化（L10N）：将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动

3. I18N VS L10N：

• I18N是L10N的基础和前提，为L10N做准备

• L10N是I18N向特定本地语言环境的转换

• I18N 是软件产品源语言开发的一部分，属于Engineering

• L10N 可以独立于Engineering，可由第三方完成

1. 软件本地化测试：

• 功能性测试：所有基本功能、安装、升级等测试

• 翻译测试：包括语言完整性、术语准确性等的检查

• 可用性测试：包括用户界面、度量衡和时区等

• 兼容性调试：包括硬件兼容性、版本兼容性等测试

• 文化、宗教、喜好等适用性测试

• 手册验证：包括联机文件、在线帮助、PDF文件等测试

第九章 测试自动化及其概念

1. 自动化测试是相对于手工测试而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替

2. 测试工具的使用是自动化测试的主要特征

3. 测试自动化：测试全过程的自动化，测试管理工作的自动化（尽量不需人工参与）

4. 自动化测试VS测试自动化

• 自动化测试焦点集中在测试执行，主要由测试工具自动地完成测试

• 测试自动化：测试全过程的自动化，测试管理工作的自动化（尽量不需人工参与）

• 测试自动化：指”一切可以由计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行“

1. 测试自动化的好处：

• 测试周期缩短

• 更高质量的产品

• 软件过程更规范

• 提高团队士气

• 节省人力资源，降低企业成本

• 充分利用硬件资源，降低企业成本。

1. 自动化测试框架：

Harness/IDE：TA框架的核心

TA脚本的管理

代理负责Harness与工具的通信，控制测试工具的运行

测试工具

任务安排：安排和提交定时任务、事件触发任务等，以便实现无人值守的自动化测试执行

报告呈现，任何一个人都能以Web方式及时查到测试结果

软件测试过程

单元测试：针对每个单元的测试， 以确保每个模块能正常工作为目标。

集成测试：对已测试过的模块进行组装，进行集成测试。目的在于检验与软件设计相关的程序结构问题。

确认（有效性）测试：是检验所开发的软件能否满足所有功能和性能需求的最后手段。

系统测试：检验软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作。

验收（用户）测试：检验软件产品质量的最后一道工序。主要突出用户的作用，同时软件开发人员也应有一定程度的参与。

软件测试模型：

软件测试过程模型－V模型

是软件开发瀑布模型的变种，主要反映测试活动与分析和设计的关系；

局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现

软件测试过程模型－W模型

在V模型的基础上，增加千开发阶段的同步测试，形成W模型；测试与开发同步进行，有利用尽早的发现问题

局限性：仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整

软件测试过程模型－H模型

在H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；软件测试可以进行尽早的进行；软件测试可以根据被测物的不同而分层次进行

测试模型使用

在实际工作中应灵活地运用各种模型的优点

V模型	强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试
W模型	补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明
H模型	强调测试是独立的，只要测试准备完成，就可以执行测试

单元测试

定义	又称模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作；可以从程序的内部结构出发设计测试用例，多个模块测试可以平行地独立进行测试
目的	发现模块内部可能存在的各种差错
内容	模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
步骤	利用设计文档设计测试用例；创建被测模块的桩模块或驱动模块；利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试

集成测试

定义	又称组装测试或联合测试，在单元测试基础上，将所有模块按概要设计和详细设计进行组装
目的	发现模块连接中的接口可能存在的各种差错
内容	穿越模块之间的数据是否会丢失；一个模块组装后是否会对另一模块或其他模块存在影响；各个子功能组装在一起是否会达到预期的父功能；全局数据结构是否有问题；单个模块的错误累积起来是否会放在
组装方法	一次性组装方式，非增殖式方式也叫整体拼装，对模块分别测试然后将所有模块组装；第二种增殖式组装方式，可以是自顶向下或自底向上
完成标志	成功地执行了测试计划中规定的所有测试用例；修正了所发现的错误；测试结果通过专门小组的评审

确认测试

目的	验证软件的功能和性能及其他特性是否与用户的要求一致
测试内容	有效性测试   运行黑盒测试方法验证所测软件是否满足需求规格说明书列出的需求；所有文档正确且便于使用；软件可移植性、易用性、兼容性进行测试；软件配置复查   保证软件配置的所有成分都齐全

系统测试

目的	验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试
测试内容	在真实或模拟系统运行环境下，检查完整的程序系统能否和系统（硬件设备、网络、系统软件）正确配置、连接，满足用户需求

本文使用 文章同步助手 同步