总结是对某一特定时间段内的学习和工作生活等表现情况加以回顾和分析的一种书面材料，它能够使头脑更加清醒，目标更加明确，让我们一起来学习写总结吧。那么我们该如何写一篇较为完美的总结呢？下面是小编为大家带来的总结书优秀范文，希望大家可以喜欢。
软件测试总结与建议 软件测试总结自己的不足之处篇一
姓名：某某 学号：20090001 在大庆浦东软件平台有限公司经过一周的软件测试实训，从对软件测试没有什么经验的我初步掌握了软件测试的方法和技能，收获颇多。
我在大学期间的专业是信息与计算科学，原本打算从事网络方面的工作，对活动目录、数据库、操作系统等的知识比较感兴趣。经过这次理论学习，了解到要做好软件测试，要求掌握的知识并不仅仅是测试方面的，网络、数据库、操作系统等的知识对做好测试也是很有帮助的。这让我明确了以后学习的目标，在不断学习软件测试的同时，也应该继续其他相关知识的深入学习。通过此次学习，对整个软件测试行业的了解大大的加深。以前认为软件测试只是枯燥的反复的使用被测试软件来发现异常的问题，以为软件测试并不重要，低开发一等。现在认识到了软件测试的重要性，软件测试是软件产业向软件工业化生产时代迈进不可缺少的重要组成部分，是保证软件质量达到客户需求不可缺少的环节。软件测试在国内是一个新的职业，发展得比较晚，但它的重要性正在为行业所重视。
在学习过程中，我了解了作为一个合格的测试人员所应具备的素质与技能。其中个人素质在测试工作中起到了非常重要的作用，它包括你的信心、耐心、细心和与人交流沟通的能力，它将贯穿你工作生涯的整个过程。在测试理论上，我们系统学习了软件测试的流程，各种测试阶段和测试方法，以及测试工具的使用。通过这些课程的学习，让我们对软件工程也有了更深刻的理解，为以后的测试工作作了很好的理论储备和技能的提升。
软件测试作为软件开发过程中一个非常重要的环节，越来越成为软件开发商和用户关注的焦点。完善的测试是软件质量的保证，因此软件测试就成了一项重要而艰巨的工作，要做好这项工作当然也绝非易事，我在做软件测试工作中总结出了一些经验和技巧。1.功能点的细化
在进行测试前，先将所要测试的功能细分，填写《测试用例表》，有针对性的运行功能测试案例，逐个对每个功能细分点进行测试。在每次运行测试案例之前，明确此次运行的目的和预期的输出结果，并要做好记录。2.注意测试中的错误集中发生的现象
有一些错误是和程序开发人员的编程水平和习惯有很大关系的。例如程序中的拼写错误，习惯用法等。注意收集并记录这些现象，有助于更快、更多地发现类似的错误。
3.尽可能多的使用非常规的测试 充分考虑到各种合法的输入和不合法的输入以及各种边界条件。边界值往往是最容易出现异常的情况，特殊的情况下甚至要制造极端的状态和意外状态，比如网络突然中断，和电源突然断电等情况。
4.对测试错误结果一定要有一个确认的过程
一般有a测试出来的错误，一定要有一个b来确认。5.制定严格的测试计划
测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。6.回归测试的关联性一定要引起充分的注意
在开发人员刚修复bug之后的地方，再找一找，往往开发人员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。修改一个错误而引起更多的错误出现的现象并不少见。
7.测试文档要尽可能详细
《测试用例表》中的功能点可尽量的详细，如实、详细地记录每次运行测试案例的输入数据，输出数据，出错提示，进行测试的时间，完成测试的时间等，便于以后对测试工作的回溯。8.重视交流和沟通
包括和程序开发人员的交流，同是测试人员之间的交流，网上技术论坛和网友的交流，和客户的交流等。多思考，多交流，多提问，通过多种沟通交流的途径，可以少走很多弯路，同时可以学到很多东西。9.善于总结
在测试过程中发现的所有问题，异常情况，发现程序开发人员易犯，常犯的错误，各种有价值的经验教训，使用系统和操作数据库时发现或者学到的技巧，使用测试工具时的心得等等，都可以随手记录在笔记本或者电脑上。这些都将是今后工作中可以参照的珍贵资料，同时也会成为自己的宝贵经验。10.妥善保存一切测试过程文档。
这次软件测试实训为我们以后从事软件测试工作打下了良好的专业基础，为我们的进一步学习提高打下了扎实的理论基础。对测试过程有了初步的认识，测试计划、测试设计、测试开发、测试执行、测试评估、测试报告贯穿整个软件开发过程。单元测试、集成测试、系统测试、验证测试每个阶段都应以用户需求为依据。这些基本的概念虽然比较抽象，但对以后的实践是大有益处的。总的来说，这次培训效果不错，对自己有一定的提升，这完全不同与学校的学习，因为它更加贴近工作，针对以后工作的内容作了很多实例的练习与工具的使用，为我们更快的加入工作提供的很好的前提。接下来一段时间，我将利用假期进入相关测试部门进行实际项目的训练，我相信在我有了很好的理论基础后，会在工作中很好的加以应用，让测试工作做得更好。同时，我会更加努力的学习与工作，遇到问题会及时多渠道寻找解决方法，积极上进，希望早日成为一名优秀的测试人员。
软件测试总结与建议 软件测试总结自己的不足之处篇二
面向对象程序的软件测试方法
在软件生命周期过程中，软件测试是保证软件质量的关键环节之一。面向对象方法学在软件工程中的引入极大地方便了软件的设计、开发和维护，为创建高可靠性的软件系统提供了重要保证。但面向对象程序的封装、继承、多态和异常处理机制等新特性却给测试带来新的挑战。一方面需要调整、改进传统的测试策略和方法；另一方面探索出适应面向对象程序特征的测试理论与技术也尤为必要。
面向对象(object oriented,oo)是当前计算机界关心的重点，它是90年代软件开发方法的主流。面向对象的概念和应用已超越了程序设计和软件开发，扩展到很宽的范围。如数据库系统、交互式界面、应用结构、应用平台、分布式系统、网络管理结构、cad技术、人工智能等领域。
面向对象的定义或说明对象的定义的非常少。其初，“面向对象”是专指在程序设计中采用封装、继承、抽象等设计方法。可是，这个定义显然不能再适合现在情况。面向对象的思想已经涉及到软件开发的各个方面。如，面向对象的分析（ooa，object oriented analysis），面向对象的设计（ood，object oriented design）、以及我们经常说的面向对象的编程实现（oop，object oriented programming）。许多有关面向对象的文章都只是讲述在面向对象的开发中所需要注意的问题或所采用的比较好的设计方法。看这些文章只有真正懂得什么是对象，什么是面向对象，才能最大程度地对自己有所裨益。这一点，恐怕对初学者甚至是从事相关工作多年的人员也会对它们的概念模糊不清。
1、面向对象的基本概念
(1)对象。
对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。
(2)对象的状态和行为。
对象具有状态，一个对象用数据值来描述它的状态。
对象还有操作，用于改变对象的状态，对象及其操作就是对象的行为。
对象实现了数据和操作的结合，使数据和操作封装于对象的统一体中
(3)类。具有相同或相似性质的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。
类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。
类具有操作，它是对象的行为的抽象，用操作名和实现该操作的方法来描述。
(4)类的结构。
在客观世界中有若干类，这些类之间有一定的结构关系。通常有两种主要的结构关系，即一般--具体结构关系，整体--部分结构关系。
①一般——具体结构称为分类结构，也可以说是“或”关系，或者是“is a”关系。
②整体——部分结构称为组装结构，它们之间的关系是一种“与”关系，或者是“has a”关系。
(5)消息和方法。
对象之间进行通信的结构叫做消息。在对象的操作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种操作的信息。发送一条消息至少要包括说明接受消息的对象名、发送给该对象的消息名（即对象名、方法名）。一般还要对参数加以说明，参数可以是认识该消息的对象所知道的变量名，或者是所有对象都知道的全局变量名。
类中操作的实现过程叫做方法，一个方法有方法名、参数、方法体。消
2、面向对象的特征
(1)对象唯一性。
每个对象都有自身唯一的标识，通过这种标识，可找到相应的对象。在对象的整个生命期中，它的标识都不改变，不同的对象不能有相同的标识。
(2)分类性。
分类性是指将具有一致的数据结构(属性)和行为(操作)的对象抽象成类。一个类就是这样一种抽象，它反映了与应用有关的重要性质，而忽略其他一些无关内容。任何类的划分都是主观的，但必须与具体的应用有关。
(3)继承性。
继承性是子类自动共享父类数据结构和方法的机制，这是类之间的一种关系。在定义和实现一个类的时候，可以在一个已经存在的类的基础之上来进行，把这个已经存在的类所定义的内容作为自己的内容，并加入若干新的内容。继承性是面向对象程序设计语言不同于其它语言的最重要的特点，是其他语言所没有的。
在类层次中，子类只继承一个父类的数据结构和方法，则称为单重继承。
在类层次中，子类继承了多个父类的数据结构和方法，则称为多重继承。
在软件开发中，类的继承性使所建立的软件具有开放性、可扩充性，这是信息组织与分类的行之有效的方法，它简化了对象、类的创建工作量，增加了代码的可重性。
采用继承性，提供了类的规范的等级结构。通过类的继承关系，使公共的特性能够共享，提高了软件的重用性。
(4)多态性(多形性)多态性使指相同的操作或函数、过程可作用于多种类型的对象上并获得不同的结果。不同的对象，收到同一消息可以产生不同的结果，这种现象称为多态性。
多态性允许每个对象以适合自身的方式去响应共同的消息。
多态性增强了软件的灵活性和重用性。
面向对象方法的基本思想是一：面向对象方法是一种运用对象、类、封装、继承、多态和消息等概念来构造、测试、重构软件的方法。
二： 面向对象方法是以认识论为基础，用对象来理解和分析问题空间，并设计和开发出由对象构成的软件系统（解空间）的方法。由于问题空间和解空间都是由对象组成的，这样可以消除由于问题空间和求解空间结构上的不一致带来的问题。简言之，面向对象就是面向事情本身，面向对象的分析过程就是认识客观世界的过程。
面向对象方法从对象出发，发展出对象，类，消息，继承等概念。
面向对象方法的主要优点是：符合人们通常的思维方式；从分析到设计再到编码采用一致的模型表示具有高度连续性；软件重用性好。
面向对象软件测试的特点是: 1.掌握代码检查、走查与评审的基本方法和技术； 2.掌握白盒测试和黑盒测试的测试用例的设计原则和方法； 3.掌握单元测试和集成测试的基本策略和方法；
4.了解系统测试、性能测试和可靠性测试的基本概念和方法； 5.了解面向对象软件和web应用软件测试的基本概念和方法； 6.掌握软件测试过程管理的基本知识和管理方法； 7.熟悉软件测试的标准和文档；
8.掌握qesuite软件测试过程管理平台和qesat/c++软件分析和工具的使用方法。
软件测试总结与建议 软件测试总结自己的不足之处篇三
1.软件测试定义：由人工或自动方法来执行或评价系统或系统部分的过程，以验证它是否满足规定的需求，或识别出期望的结果和实际结果之间的差异。2.软件测试的分类：
测试对象或范围分类：需求评审、设计评审、单元测试、程序测试、系统
测试、文档测试、web应用测试、客户端测试、数据库测试等；
测试目的分类：集成测试、功能测试、压力测试、性能测试等等； 静态测试、动态测试； 白盒测试、黑盒测试。3.软件测试的基本流程与原则
基本流程：
测试用例设计-输入数据、预期结果； 测试执行-输入数据执行被测对象； 检查实际输出与预期结果。基本原则：
开始测试时认定软件有错，测试要证明有错； 测试应该由独立的测试团队来完成； 测试设计必须设计对应的预期输出；
要对合理、不合理（有效、无效）输入数据都进行测试； 检查软件的完备性、多余； 完整保留测试文档；
一个被测对象中有错误的概率与已发现错误的个数成正比。测试成熟度级别：
0级：没有区分测试与调试；
1级：测试的目的是证明软件能用； 2级：测试的目的是证明软件不能用；
3级：测试的目的不是为了证明什么，而是为了降低软件使用风险； 4级：测试是一种智能训练，能够帮助专业人员开发出更高质量的软件。5.软件测试与软件工程，软件过程的关系：
软件工程：在给定的条件下（成本、时间）开发出高质量的软件产品。软件生产过程的特性决定了软件产品中不可避免包含有错误。软件测试则是尽可能多地发现错误，从而保障软件产品的质量。的质量因素：
产品修改：
可维护性，灵活性，可测试性 产品转移：
可移植性，可复用性，互操作性 产品运行：
正确性，易用性，可靠性，效率，完整性 7.软件质量困境
软件质量必须足够好：存在价值
软件产品无法完美：需要消耗过多的资源、时间、成本
软件开发需要在两个极端之间进行平衡：软件足够好的同时又不完美。8.质量控制、质量保证和质量管理
软件质量控制其实是基本方法，通过一系列的技术来科学地测量过程的状态。如缺陷率、测试覆盖率等。
软件质量保证则是过程的参考、指南的集合，如iso9000、cmm/cmmi等，着重内部的检查，确保已获取认可的标准和步骤都已经遵循。
软件质量管理则是实际操作的思想，质量管理控制和协调组织的质量活动，包括质量控制、质量保证和质量改进。应用的属性：
网络密集型应用；并发性；大负载量；性能；高可靠性、高可用性；安全性-内容敏感；
10.软件评审的目的，评审度量及其应用
评审的目标在于：尽早发现软件过程中的错误，防止错误传递、蔓延至后续活动，防止错误转化为缺陷。
准备工作量ep-实际评审会之前所需工作量； 评估工作量ea-实际评审所花费的工作量 返工工作量er-修改评审所发现错误的工作量 工作产品规模wps-评审对象的规模
发现的主要错误数errmajor-多于预期的改错工作量的错误数目 发现的次要错误数errminor-少于预期的改错工作量的错误数目 总评审工作量ereview = ep+ea+er 错误总数errtot = errmajor+errminor 错误密度：评审的每单位工作产品发现的错误数ed = errtot / wps 错误密度数值的含义：较小（产品质量非常好或评审不够彻底）；较大（产品质量存在缺陷）
11.软件测试计划：描述对计算机软件配置项、子系统、系统进行测试的计划安排，内容包括测试的环境、测试工作的标识及测试工作的时间安排。
软件测试报告：是对计算机软件配置项、软件系统或子系统，或与软件相关项目执行合格性测试的记录 12.软件测试活动
制订测试计划（测试分析员）
测试设计（测试设计人员）－方案设计 测试及测试用例设计 测试过程
桩模块、驱动模块设计
测试实施（测试设计员）－实现测试设计 单元测试（测试员）集成测试（测试员）系统测试（测试员）
评估测试（测试设计人员）
13.无向图的相关定义：
连接性：节点ni、nj是连接的，当且仅当ni、nj在同一条路径上。组件：图的组件是相连节点的最大集合
图g的圈复杂度v（g)＝e－n＋2p，其中e为g的边数，n为节点数，p为组件数。14.图覆盖：给定一个关于图g的准则c的测试需求集合tr，测试集合t在图g上满足准则c当且仅当对tr中每个测试需求tr，path(t)中至少存在一条测试路径p满足tr。
简单路径：如果从ni到nj的一条路径中，除了始节点和终节点可以相同外，没有任何节点出现次数多于一次，则该路径为简单路径。
主路径：如果从ni到nj是一条简单路径，并且它不作为任何其他简单路径的子路径出现，则称之为主路径。
主路径覆盖（ppc）准则：tr包含图中每一条主路径。
指定路径覆盖（spc)：tr包含一个测试路径集s，s为指定参数。15.白盒测试方法
白盒测试：根据被测对象的内部结构和运行机制来设计测试用例的方法，又称为结构测试、逻辑驱动测试、覆盖测试
被测对象的独立路径至少覆盖一次； 所有逻辑取值测试[真、假]； 循环边界测试；
检查内部数据结构、边界条件。16.黑盒测试方法
黑盒测试方法又称功能测试方法、数据驱动测试方法，测试设计时不考虑被测对象的内部结构，以检查系统功能（功能的正确、完整、逻辑流程、人机界面、文档内容、系统安装/初始化）
以被测对象的外部特征为测试依据。17.模糊测试方法
模糊测试方法：构造大量的随机数据作为系统的输入，从而检验系统在各种数据情况下是否出现问题。
18.增量测试：单元测试、调用依赖的模块集成测试，逐步扩展直到形成整个软件系统。
19.突击测试：所有模块一次性集成为一个完整的系统，然后进行完全测试。20.等价类划分：
等价类划分基于对输入或输出数据情况的评估，划分成两个或多个子集（等价类），然后从每个子集中选取一定的代表进行测试的测试用例设计方法。21.极限测试
极限编程：利用轻量、敏捷的开发过程，使开发人员能够更快地完成应用程序的开发。强调频繁测试、测试驱动的方式保证软件质量。
极限测试：为满足极限编程思想和过程而设计的一套测试策略和流程，原来的测试技术、方法均可以使用 22.配置项测试的内容
功能: 适合性
准确性：功能的准确与精度要求 互操作性：与外部设备、系统的接口 安全保密性：数据访问的可控制性 可靠性: 成熟性：容错处理、平均无故障时间
容错性：边界条件、功能、性能的降级情况、误操作模式、故障模式 易恢复性：自动修复能力/时间、平均宕机时间、平均恢复时间、恢复能力等 易用性
易理解性：功能描述清晰、准确；界面含义精确
易学性：在线帮助、帮助定位、各类手册的易学、易用 易操作性：数据的有效检查、解释信息明确、界面切换 吸引性：人机界面定制 效率
时间特性：响应时间、平均响应时间、响应极限时间、吞吐量、平均吞吐量、极限吞吐量，多任务并行测试
资源利用：大量并发任务下i/o设备利用、极限负载下i/o设备的负载、大量并发任务下用户等待时间、内存使用情况、数据传输能力等
维护性
易分析性：运行状态数据易分析 易变更性：软件的可配置、修改能力 易测试性：变更之后的易测试情况 可移植性
适应性：不同软件、硬件环境的适应能力 易安装性：安装、配置的复杂程度、难以程度 共存性：与其他软件协同的能力 易替换性：版本的替换难以程度 依从性
以上所有特性遵循标准、规范的情况测试
23系统测试：系统非功能性测试，以检验系统在超常数据规模或负载下，线程、cpu、内存资源的利用和响应时间、数据传输等性能指标是否满足要求
24.测试计划
确定测试充分性要求：覆盖范围、覆盖程度 确定测试终止要求； 确定测试所需资源； 确定测试的软件特性； 确定测试技术、方法； 确定测试准出条件； 确定测试进度计划； 测试风险分析。
25.测试设计：测试设计人员、测试程序员
测试用例设计：依据测试特性； 获取测试数据；
确定测试顺序：资源、被测特性； 获取测试资源：软硬件、工具； 编写测试程序； 建立测试环境； 撰写测试设计说明。
26.测试总结：
测试分析员－测试报告
总结测试计划、测试说明的变化情况； 异常终止时测试未覆盖范围； 未能解决的测试问题； 总结测试结果（发现问题）； 编写测试报告；
根据问题报告、测试记录，编写测试问题报告。
27.软件可靠性：在给定的运行时间内和给定的系统配置环境下，运行给定的软件功能时所 表现出来的质量能力 28.系统性能指标
系统资源利用率：分析性能指标，改善性能系统行为指标 请求响应时间：一次请求完成时间
事务响应时间：一个事务所有请求完成的总时间
数据吞吐量：单位时间内服务器接收、发送的数据量。
29.验收测试：用户执行的、使用真实数据进行的测试，依据需求规格中的确认标准进行测试。回归测试：验证已测试过的内容不受变更影响，确认变更没有引入新的错误。
30.α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操 作环境下进行的测试。
beta测试由软件的最终用户在一个或多个客户场所进行，开发者通常不在beta测试的现场。
测试关注的主要内容 web内容测试 界面 构件
导航测试 安全性 性能
32.测试用例（test case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
33.软件生存期定义：从软件产品设计到软件被淘汰的时间段。又称软件生命周期、生存周期。进一步划分为两个阶段：开发阶段和维护阶段（40%+60%）。
34.软件安全定义：一种软件质量保证活动，他主要用来识别和评估可能对软件产生负面影响并促使整个系统失效的潜在灾难。
35.软件评审的目标在于：尽早发现软件过程中的错误，防止错误传递、蔓延至后续活动，防止错误转化为缺陷。36.v模型
优点：既有底层测试又有高层测试。底层：单元测试。高层：系统测试。
将开发阶段清楚的表现出来，便于控制开发的过程。当所有阶段都结束时，软件开发就结束了。
缺点：容易让人误解为测试是在开发完成之后的一个阶段。
由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源。
实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试，返工量大。37.w模型：
优点：
将测试贯穿到整个软件生命周期中，且除了代码要测试，需求、设计等都要测试。更早介入软件开发中，能尽早发现缺陷并修复。
测试与开发独立起来，并与开发并行。缺点：
对有些项目，开发过程中根本没有文档产生，故w模型无法使用。
对于需求和设计的测试技术要求很高，实践起来很困难。
从n0中某节点开始到nf中某节点结束的一条路径称为一条测试路径。
1.软件缺陷：（符合下列规则的叫软件缺陷)：
１）．软件未达到产品说明书的功能
２）．软件出现了产品说明书指明不会出现的错误
３）．软件功能超出产品说明书指明范围
４）．软件未达到产品说明书虽未指出但应达到的目标
５）．软件测试员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好
2.单元测试：单元测试是对软件设计的最小单元——模块进行正确性检验的测试工作，主要测试模块在语法、格式和逻辑上的错误。3.回归测试
指软件系统被修改或扩充（如系统功能增强或升级）后重新进行的测试，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。
4.等价类：指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。
软件测试总结与建议 软件测试总结自己的不足之处篇四
软件测试的目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。
测试的目的就是为了保证软件质量
使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
软件缺陷
软件缺陷是对软件产品预期属性的偏离现象 1.对产品规格说明的偏离
2.对用户期望的偏离，即用户要求未体现在产品中（可能是规格说明有疏漏，也可能是实现中的问题）
注意：软件缺陷不可能完全避免
软件质量
软件需求是衡量软件质量的基础
规定了的标准是软件开发必须遵循的准则
如果已开发的软件已经满足了那些明文规定的需求，却没有满足隐含的需求，软件产品的质量仍然是有问题的
测试目的
测试是程序执行的过程，目的在于发现错误（缺陷）
好的测试用例能有效地发现别的测试用例未发现的错误（缺陷）成功的测试是发现了未曾发现的错误
确保软件的功能符合用户的需求，把尽可能多的问题在发布或交付前发现并改正： 确保软件完成了它所承诺或公布的功能 确保软件满足性能的要求
确保软件是健壮的和适应用户环境的
一些原则：
一个好的测试用例具有较高的发现过去未被发现过的错误的概率； 自己不能测试自己编写的程序；
对期望结果的描述是每个测试用例的必要组成部分； 杜绝不能重现或匆忙的测试；
既要编写使用有效输入条件的测试用例，也要编写使用非法输入条件的测试用例； 深入细致地审查测试结果 充分注意测试中的集群现象：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比；
让最优秀的人员去完成测试；
保证软件的可测试性是软件设计的一个重要目标； 不要为了测试方便而修改程序；
测试工作必须在任务建立之初就确定目标。good-enough: 一种权衡投入/产出比的原则； 保证测试的覆盖程度，但穷举测试是不可能的； 所有的测试都应该追朔到用户需求；
越早测试越好，测试过程与开发过程应该是相结合的； 测试的规模由小而大，从单元测试到系统测试；
为了尽可能多的发现错误，应该由独立的第三方来测试； 不能为了便于测试修改程序
既应该测试软件该做什么，也应该测试软件不该做什么
测试方法
（1）测试方法分类：
根据软件测试的策略分类：
黑盒测试与白盒测试（功能性测试和结构性测试）,静态测试与动态测试,手工测试与自动测试
根据测试的阶段分类: 单元测试,集成测试,系统测试
（2）功能性测试和结构性测试 a、功能性测试 基本观点：任何程序都可以看作是将从输入定义域取值映射到输出值域的函数（工程中的黑盒）。
测试在软件的接口处进行，测试人员完全不考虑程序内部的逻辑结构和内部特征，只根据程序的需求规格说明书，检查程序的功能是否符合它的功能说明（也称“数据驱动测试”）。
黑盒测试一般为了发现以下几类错误： 是否有不正确或遗漏的功能？
在接口上，输入能否正确地接受？能否输出正确的结果？ 是否有数据结构错误或外部信息（如数据文件）访问错误？ 性能上是否能够满足要求？ 是否有初始化或终止行错误？ „„
常用方法：边界值分析，健壮性分析，最坏情况分析，特殊值测试，输入（输出）等价类，基于决策树的测试„„
功能性测试的优点：
功能性测试与软件如何实现无关，所以如果实现发生变化，测试用例仍然有效； 测试用例开发可以与实现并行，可以压缩总的项目开发时间。缺点：
测试用例的冗余
b 结构性测试
对软件的过程性细节做细致的检查，对所有的逻辑路径进行测试（也称逻辑驱动测试）。结构性测试一般对程序模块做如下的检查：
对程序模块的所有独立的执行路径至少测试一次；
对所有的逻辑判定，取“真”与“假”的情况都能至少测试一次； 在循环的边界和运行界限内执行循环体； 测试内部数据的有效性 „„
（3）功能性测试与结构性测试的比较 测试用例的基础：
功能性测试：需求规格说明
结构性测试：程序源代码（实现）两种方法单独使用都是不充分的
如果所有已描述行为都没有被实现，结构性测试永远也发现不了； 如果程序实现了没有被描述的行为，功能性测试用也发现不了；
测试级别与功能性和结构性测试存在现实的关系： 结构性测试最适合在单元级别上进行； 功能性测试最适合在系统级别上进行；
完全测试程序是不可能的: 原因： 输入量太大 输出结果太多 软件实现途径太多
软件说明书没有客观标准
边界值分析 程序与函数: 程序的输入——定义域 程序的输出——值域 程序中变量的值域: 强类型语言 非强类型语言
边界值测试的基本原理: 错误更可能出现在输入变量的极值附近.单缺陷假设：失效极少由两个（或多个）缺陷的同时发生引起的。min、min＋、nom、max-和max。
次边界条件：
有些边界条件在软件内部，最终用户几乎看不到，但是软件测试仍有必要检查。这样的边界条件称为次边界条件或者内部边界条件。如2的乘方和ascⅱ。
边界值分析的特点和局限性
对于一n个变量函数，边界值分析会产生4n＋1个测试用例。边界值的取值取决于变量本身的性质。边界值分析对布尔变量没有什么意义。边界值分析假设变量是完全独立的。
边界值分析的问题 测试用例存在大量冗余 存在不完备现象 等价类测试
希望进行完备性测试 同时又希望避免冗余 等价类测试考虑的因素 单/多缺陷假设 健壮性
等价类划分：
把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。希望进行完备性测试 同时又希望避免冗余
等价类测试步骤
使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。（1）划分等价类
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。等价类的划分有两种不同的情况：
① 有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。② 无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。
在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。
(2）等价类测试--等价类划分原则 ①如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。
②如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。
③如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。④如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。
⑤如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
（3）等价类测试—选取测试用例 在确立了等价类之后，建立等价类表，列出所有划分出的等价类。再从划分出的等价类中按以下原则选择测试用例： ① 为每一个等价类规定一个唯一编号；
② 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；
③ 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
基于决策表的测试
在所有功能测试方法中，基于决策表的测试方法是最严格的，因为决策表具有逻辑严格性。
决策表很适合描述不同条件集合下采取行动的若干组合的情况。
决策表的组成
条件桩：列出了问题的所有条件。
动作桩：列出了问题规定可能采取的操作。
条件项：列出针对它所列条件的取值，在所有可能情况下的真假值。动作项：列出在条件项的各种取值情况下应该采取的动作。规则：任何一个条件组合的特定取值及其相应要执行的操作。在决策表中贯穿条件项和动作项的一列就是一条规则。
功能性测试的选择规则
如果变量引用的是物理量，可采用定义域测试和等价类测试。如果变量是独立的，可采用定义域测试和等价类测试。如果变量不是独立的，可以采用决策表测试。
如果可保证是单缺陷假设，可以采用边界值分析和健壮性测试。
如果可保证是多缺陷假设，可采用最坏情况测试、健壮最坏测试和决策表测试。如果程序包含大量例外处理，可采用健壮性测试和决策表测试。如果变量引用的是逻辑量，可以采用等价类测试用例和决策表测试。
结构性测试 静态测试: 括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
检查项： * 代码风格和规则审核 * 程序设计和结构的审核 * 业务逻辑的审核
静态白盒测试是在不执行的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。好处：
尽早发现软件缺陷。
dd路径测试
该测试方法的突出特点，是它们都基于被测程序的源代码，而不是基于定义。由于这种绝对化的基础，结构性测试方法支持严格定义、数据分析和精确度量。
程序图 定义
给定一个采用命令式程序设计语言编写的程序，其程序图是一种有向图，其中：节点是程序语句，边表示控制流。从节点i到节点j有一条边，当且仅当对应节点j的语句可以立即在节点i对应的语句之后执行。
dd路径
决策到决策的路径（dd-路径）是指语句的一个序列，从决策语句的“出路”开始，到下一个决策语句的“入路”结束。在这种序列中没有内部分支，因此对应的节点像排列起来的一行多米诺骨牌，当第一块牌推倒后，序列中的其他牌也会倒下。
链是一条起始节点和终止节点不同的路径，并且每个节点都满足内度＝１、外度＝１。初始节点与链中的所有其他节点有２－连接，不会存在１－连接或３－连接。(p55, 4.2.6)有一种长度为０的退化链情况，即链有一个节点和０条边组成。
dd路径测试定义 定义
dd-路径是程序图中的一条链，使得：
情况1：由一个节点组成，内度=0。
情况2：由一个节点组成，外度=0。
情况3：由一个节点组成，内度≥2或外度≥2。
情况4：由一个节点组成，内度=1并且外度=1。
情况5：长度≥1的最大链。
对于给定的程序，可以使用多种不同的程序图，所有这些程序图都可以简化为惟一的dd-路径。
dd-路径图定义
给定采用命令式语言编写的一段程序，其dd-路径图是有向图。其中，节点表示其程序图的dd-路径，边表示连续dd-路径之间的控制流。
实际上dd-路径图是一种压缩图，在这种压缩图中，2-连接组件被压缩为对应情况5 dd-路径的单节点。
如果每条dd-路径都被遍历（c1指标），则我们知道每个判断分支都被执行，这要求遍历dd-路径图中的每一条边。
较长的dd-路径一般代表复杂计算，可以合理地认为是单独的函数。对于这样的dd-路径，应用多个功能性测试可能比较合适，尤其是边界值和特殊值。
dd-路径的依赖对偶
dd-路径对偶之间的最常见得依赖关系是定义/引用关系，其中变量在一个dd-路径中定义（接受值），在另一个dd-路径中引用。这种依赖关系的重要性在于，它们与不可行路径问题有关。
定义/使用测试覆盖指标
t是拥有变量集合v的程序p的程序图g（p)中的一个路径集合。定义
集合t满足程序p的全定义准则，当且仅当所有变量v∈v，t包含从v的每个定义节点到v的一个使用的定义清除路径。定义
集合t满足程序p的全使用准则，当且仅当所有变量v∈v，t包含从v的每个定义节点到v的所有使用，以及到所有use（v,n）后续节点的定义清除路径。定义
集合t满足程序p全谓词使用/部分计算使用准则，当且仅当所有变量v∈v，t包含从v的每个定义节点到v的所有谓词使用的定义清除路径，并且如果v的一个定义没有谓词使用，则定义清除路径导致至少一个计算使用。定义
集合t满足程序p全计算使用/部分谓词使用准则，当且仅当所有变量v∈v，t包含从v的每个定义节点到v的所有计算使用的定义清除路径，并且如果v的一个定义没有计算使用，则定义清除路径导致至少一个谓词使用。定义
集合t满足程序p的全定义-使用路径准则，当且仅当所有变量v∈v，t包含从v的每个定义节点到v的所有使用，以及到所有use（v,n）后续节点的定义清除路径，并且这些路径要么有一次的环经过，要么没有环路。
单元测试
单元测试时对软件基本组成单元进行的测试，这里的基本单元不一定是指一个具体的函数或一个类的方法。
单元具有一些基本属性，如：明确的功能、规格定义，与其他部分明确的接口定义等，可以清晰地与同一程序的其他部分单元划分开来。
单元测试的目的
验证代码是与设计相符合的； 跟踪需求和设计的实现；
发现设计和需求中存在的错误； 发现在编码过程中引入的错误。
对单元测试的错误认识
单元测试浪费了太多的时间；
单元测试仅仅是证明这些代码做了什么； 很棒的编程人员的工作不需要单元测试； 不管怎样，集成测试将会抓住所有的bug； 单元测试的成本效率不高。
单元测试应坚持的原则
对全新的代码或修改过的代码进行单元测试； 对被测试单元需达到的一定的代码覆盖率要求； 当程序进行了修改，要进行回归测试。
集成测试
也叫做组装测试、联合测试、子系统测试和部件测试。是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，进行集成测试。
集成测试关注的重点
在把各个模块连接起来时，穿越模块接口的数据是否会丢失。各个子功能组合起来，能否达到预期要求的父功能。
一个模块的功能是否会对另一个模块的功能产生不利的影响。全局数据结构是否有问题，会不会被异常修改。
单个模块的误差积累起来，是否会放大，从而达到不可以接受的程度。
集成测试策略
功能分解法，调用图法，mm路径法
基于功能分解的集成测试：
自顶向下集成，自底向上集成，三明治集成，大爆炸集成
自顶向下集成
自顶向下集成从主程序（树根）开始。所有被主程序调用的下层单元都作为“桩”出现，桩就是模拟被调用单元的一次性代码。
自底向上集成
自底向上集成是自顶向下顺序的“镜像”，不同的是，桩由模拟功能分解树上一层单元的驱动器模块替代。需要编写驱动器。
三明治集成
三明治是自顶向下和自底向上集成的组合。
桩和驱动器的开发工作都比较小，不过代价是有大爆炸的后果。
大爆炸集成
这种方法最容易：这种集成将所有单元在一起编译并进行一次性测试。这种方法的缺点是，当发现缺陷时，没有多少线索能够用来帮助确定缺陷位置。
因果图是从用自然语言书写的程序规格说明的描述中找到因（输入条件）和果（输出或程序状态的改变），通过因果图转化为判别表。因果图方法最终生成的就是判定表。因果图的适用范围
如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
用因果图生成测试用例的基本步骤:(1)分析软件规格说明描述中，哪些是原因(即输入条件或输入条件的等价类)，哪些是结果(即输出条件)，并给每个原因和结果赋予一个标识符。
(2)分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系? 根据这些关系，画出因果图。
(3)由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。(4)把因果图转换成判定表。
(5)把判定表的每一列拿出来作为依据，设计测试用例。