【2017年整理】软件测试的理论和实践.doc

软件测试的理论和实践 题记：测试是交付成功的优质的产品的保证 我们每个人，不会都是软件测试人员，但都是某些软件的用户。缺省或默认情况 下，用户都会觉得买到的软件是没有问题的，一般不会去想这样的软件可能会有 问题，用户只要使用这些软件来解决他们需要解决的问题就可以了。当他们发现 问题的时候，甚至会感到震惊。存在的问题很多都和测试的成效有关系，一般的 软件产品存在的问题确实比较少，但我觉得即使是以前买的正版的金山快译2000 都有着一些显而易见的bug。如果测试不充分，那么这些问题会潜伏在软件中， 等到用户发现以后，再有开发人员进行维护，改正错误的费用一般是开发阶段的 40倍到60倍。 人们对测试存在着一些误区，例如： 1 测试是想象到可能出现的问题，然后试图验证这些问题。 实际上能想象到的只是一部分的情况，随意性太大，还要取决于开发人员的经 验，对业务的熟悉程度和他想象到的程度。 2 让时间有富裕的员工去做一些测试 表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻 视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学 习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工 作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他 是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者 工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行 业的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个 问题就觉得满意了，这在任何其它工作中都是不行的。 3 测试是相对简单的工作。 实际上并非如此，要真正做好一件事都不容易。测试也有很多相关技术和工具。 而对测试的轻视问题，也许要通过痛苦的经历和结果才可能确切体会到。很多专 家都在对测试的理论进行深入的探讨和研究。 测试的基本知识 让我们一起快速过一遍： 什么是软件测试：在软件投入运行前，对软件需求分析、设计规格说明和编码的 最终复审，是软件质量保证的关键步骤。 测试的目标：以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷，以 确保系统的质量。 从测试的类型来看，测试分为2种：黑盒测试和白盒测试。 黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序 的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能 说明。 白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及 有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。 测试用例由测试输入数据以及与之对应的输出结果组成。测试用例设计的好坏直 接决定了测试的效果和结果。 从测试实际的前后过程来看，软件测试上是由一系列的不同测试所组成，这些软 件测试的步骤分为：单元测试、组装测试（集成测试）、确认测试和系统测试。 软件开发的过程是自顶向下的，测试则正好相反，以上这些过程就是自底向上， 逐步集成的。 单元测试（模块测试）：针对每个模块进行的测试，可从程序的内部结构出发设 计测试用例，多个模块可以平行地对立地测试。通常在编码阶段进行，必要的时 候要制作驱动模块和桩模块。 集成测试：在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须 精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。 确认测试：验证软件的功能和性能及其它特性是否与用户的要求一致。 系统测试：将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数 据和人员等，在实际运行环境下进行一系列的测试。 测试工作的文档主要有：测试计划、测试模型和用例设计或规格说明、测试分析 报告等。从软件工程上说，这是属于软件配置的一部分。（我不知道，如果什么 报告都没有，只是不断地摆弄执行程序，看到错误和问题就记下来，算不算真正 的测试？） 测试需要一定的技术和工具 在用例设计过程中，可以考虑到很多方面，并且也有很多的指导方法和技术。 黑盒测试用例设计包括： 等价类划分：划分等价类--确立测试用例--设计用例 边界值分析：通过分析，考虑如何确立边界情况 错误推测法：靠经验和直觉来推测程序中可能存在的各种错误，从而有针对性地 编写用例。可以列举出可能的错误和可能发生错误的地方，然后选择用例。 因果图：通过画因果图，在图上标明约束和限制，转换成判定表，然后设计测试 用例。这适合于检查程序输入条件的各种组合情况。 功能图FD：通过形式化地表示程序的功能说明，并机械地生成功能图的测试用 例。 白盒测试用例设计包括： 1 逻辑覆盖，以程序内在逻辑结构为基础的测试，包括以下5种类型： 1.1 语句覆盖：每一条可执行语句至少覆盖一次； 1.2 判定覆盖（分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每 个