软件测试理论总结

一、原则问题

软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。
为了达到上述的原则，那么需要注意以下几点：

• 应当把“尽早和不断的测试”作为开发者的座右铭
• 程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完。
• 设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
• 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
• 对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
• 制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
• 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
• 妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档

二、软件测试策略

1. 软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。一般在测试实现阶段完成。通常情况下，需求评审通过后进行测试计划编写，测试计划中包含测试策略，以及环境需求，资源需求， 人员组织架构，工作量预估，风险预估，测试通过标准，测试失败/挂起标准，测试完成后交付的产品等。
2. 软件测试策略基础
   2.1 策略与软件测试策略
   • 策略：在一定的政治路线指导下，根据具体条件而规定的斗争原则、方式和方法。
   • 软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。
     2.2 软件测试策略的重要性
   • 任何一个完全测试或穷举测试的工作量都是巨大的，在实践上是行不通的，因此任何实际测试都不能保证被测程序中不遗漏错误或缺陷；
   • 为了最大程度较少这种遗漏，同时最大限度发现可能存在的错误，在实施测试前必须确定合适的测试方法和测试策略，并以此为依据制定详细的测试案例。

2.3 软件测试策略的影响因素

软件测试策略随着软件生命周期的变化、软件测试方法、技术与工具的不同发生的变化。这就要求我们在制定测试策略时候，应该综合考虑测试策略的影响因素及其依赖关系。这些影响因素可能包括：测试项目资源因素、项目的约束和测试项目的特殊需要等。

2.4 软件测试策略的制定过程
(1) 输入需要的软硬件资源的详细说明;

• 针对测试和进度约束而需要的人力资源的角色和职责；
• 测试方法、测试标准和完成标准；
• 目标系统的功能性和技术性需求；
• 系统局限（即系统不能够提供的需求）等等。
  (2) 输出已批准和签署的测试策略文档、测试用例、测试计划；需要解决方案的测试项目；
  (3) 过程

2.4.1 确定测试的需求

• 测试需求所确定的是测试内容，即测试的具体对象。在分析测试需求时，可应用以下几条一般规则：
• 测试需求必须是可观测、可测评的行为。如果不能观测或测评测试需求，就无法对其进行评估，以确定需求是否已经满足。
• 在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求；有些补充需求将派生一个或多个测试需求，而其他补充需求（如市场需求或包装需求）将不派生任何测试需求。
• 测试需求可能有许多来源，其中包括用例模型、补充需求、设计需求、业务用例、与最终用户的访谈和软件构架文档等。应该对所有这些来源进行检查，以收集可用于确定测试需求的信息。

2.4.2 评估风险并确定测试优先级

• 成功的测试需要在测试工作中成功地权衡资源约束和风险等因素。为此，应该确定测试工作的优先级，以便先测试最重要、最有意义或风险最高的用例或构件。为了确定测试工作的优先级，需执行风险评估和实施概要，并将其作为确定测试优先级的基础。
  2.4.3 确定测试策略
• 一个好的测试策略应该包括：实施的测试类型和测试的目标、实施测试的阶段、技术、用于评估测试结果和测试是否完成的评测和标准、对测试策略所述的测试工作存在影响的特殊事项等内容。
  如何才能确定一个好的测试策略呢？我们可以从基于测试技术的测试策略、基于测试方案的测试策略两个方面来回答这个问题。
  ①基于测试技术的测试策略的要点
  著名测试专家给出了使用各种测试方法的综合策略：任何情况下都必须使用边界值测试方法；必要时使用等价类划分方法补充一定数量的测试用例；对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，看是否达到了要求；如果程序功能规格说明中含有输入条的组合情况，则已开始可以选择因果图方法。
  ②基于测试方案的测试策略
  对于基于测试方法的测试策略，一般来说应该考虑如下方面：根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点；认真研究，使用尽可能少的测试用例发现尽可能多的程序错误，避免测试过度和测试不足!
  2.4.4 测试策略的方法
• 静态方法与动态方法
• 所谓静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
• 动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。
  2.4.5 功能测试与结构测试
  (1)功能测试
  功能测试是指在对程序进行的功能抽象的基础上，将程序划分成功能单元，然后在数据抽象的基础上，对每个功能单元生成测试数据进行测试。用这种方法进行测试时，被测程序被当作打不开的黑盒，因而无法了解其内部构造，因此又称为黑盒测试。
  a. 等价类划分
  所谓等价类，就是指某个输入域的集合，集合中的每个输入对揭露程序错误来说是等效的，把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例，这就是等价类划分方法。它是功能测试的基本方法。
  b. 因果图法
  因果图是一种形式语言，由自然语言写成的规范转换而成，这种形式语言实际上是一种使用简化记号表示数字逻辑图。因果图法是帮助人们系统地选择一组高效测试用例的方法，此外，它还能指出程序规范中的不完全性和二义性。
  c. 边值分析
  实践证明，软件在输入、输出域的边界附近容易出现差错，边值分析是考虑边界条件而选取测试用例的一种功能测试方法。所谓边界条件，是相对于输入和输出等价类直接在其边缘上，稍高于和稍低于其边界的这些状态条件。边值分析是对等价类划分的有效补充。
  (2)结构测试
  结构测试是根据被测程序的内部结构设计测试用例的一类测试，又称为白盒测试。白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。其主要方法有逻辑驱动、基路测试等，主要用于软件验证。白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。白盒法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。
  第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身错误的程序。
  第二，穷举路径测试不可能查出程序中因遗漏路径而出错。
  第三，穷举路径测试可能发现不了一些与数据相关的错误。
  与功能测试不同的是，结构测试涉及程序内部结构。尽管用户更倾向于基于程序规格说明的功能测试，但是结构测试能发现潜在的逻辑错误，而这种错误往往是功能测试发现不了的。它们各有利弊，常常结合使用。

三、 软件测试的的重点

• 测试用例的设计
  测试用例的设计是整个软件测试工作的核心
  测试用例反映对被测对象的质量要求，决定对测试对象的质量评估
• 测试工作的管理
  尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提
• 测试环境的建立
  测试环境应该与实际测试环境一致

四、 黑盒测试

• 什么是黑盒测试
  又称功能测试或数据驱动测试，是针对软件的功能需求/实现进行测试，通过测试来检测每个功能是否符合需求，不考虑程序内部的逻辑结构
• 黑盒测试方法
  功能划分
  等价类划分
  边界值分析
  因果图
  错误推测等

五、 白盒测试

• 白盒测试也称结构测试或逻辑驱动测试，必须知道软件内部工作过程，通过测试来检测软件内部是否按照需求、设计正常运行
• 白盒测试的主要方法
  对应于程序的一些主要结构：语句、分支、逻辑路径、变量；白盒测试的主要方法是：
  语句覆盖方法
  分支覆盖方法
  逻辑覆盖方法

六、 手工测试和自动测试

a.手工测试缺点在于测试工作量大，重复多，回归测试难以实现
b.自动测试利用软件测试工具自动实现全部或部分测试工作：管理、设计、执行和报告；节省大量的测试开销，并能够完成一些手工测试无法实现的测试

• 手工完成测试的全部过程无法保证测试的科学性与严密性:
• 修改的缺陷越多，回归测试越困难
• 没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率
• 反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一
• 测试花费的时间越长，测试的严格性也就越低
• 自动测试将测试人员从反复、烦杂的测试执行中解放出来，用更多的时间进行测试设计和结果分析
• 软件测试不可能完全自动化
• 不能完成所有手工测试任务
• 无创造性且灵活性差，不能改进测试的有效性
• 过程中可能会遇到许多意想不到的问题，特别是当软件不稳定时
• 测试脚本的维护高

七、 测试流程

• 单元测试
• 集成测试
• 系统测试
• 用户验收测试

• 回归测试

  
  测试流程