软件测试必备1、软件测试基本概念和方法三个重要的测试原则：1. 软件测试是为发现错误而执行程序的过程；2. 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性；3. 一个成功的测试用例能够发现某个尚未发现的错误。

1.测试的过程具有一定的破坏性2.测试用例包括：输入数据的详细描述和正确输出结果的精确描述3.检查程序是否‘没有做它应该做的’仅仅是测试一半，另一半是检查‘是否做了它不应该做的’4.全面测试目标：验证是否做了应该做的事情，确保可靠性验证程序是否做了不应该做的事情，确保安全性5.任何多余的功能都应视为安全隐患6.Boehm给出的度量中的头10个表示软件现象遵守Pareto分布：20％的模块消耗80％的资源（人力、经费等）；20％的模块包含80％的错误；20％的错误消耗80％的修改成本；20％的改进包含了80％的适应性为主的成本；20％的模块占用了80％的执行时间；20％的软件工具使用占80％的整个工具使用时间。

补充：20%的软件缺陷造成80%的软件故障20%的软件开发和管理人员（骨干），决定了80%软件开发质量：Pareto原理强调了精力集中在少数重要的事情上（vital few），而不是多数琐碎的事情上(trivial many)。

6.软件测试是一种作为主体的人通过各种手段对客体软件的某种固有属性进行的一种以8.审查的终极目标——确认缺陷9.人工审查包括：文档审查代码审查10. 软件缺陷的类型：可追溯性、逻辑、赋值顺序、控制、数据、接口、文档、注释、例外情况处理、内存等。

11. 只要简单地使用静态代码分析来增强输入验证的正确性就能够避免OWASP（业界领袖的安全性协会）所列出的约70%的安全性问题。

12. 圈度复杂度（独立路径的最大数量=程序控制流图中的区域数）=控制流图边数—控制流图的节点数+2二、测试框架的表述13. 测试框架（Test Framework）:一组相互协作的组件的集合，能够实现一个或多个测试域中的一系列问题的解决方案。

14. 框架最大的好处就是重用。

还能重用分析。

必须具有易用性（简洁易懂），具有良好的可扩展性。

15. 细节层（组件的具体实现）16. 侧面17. 结构层（测试框架的体系结构）18. 槽19. 原则层（测试域、测试原理等）20. 固定概念21. 原则层在测试框架中抽象级别最高，由一组基本原则构成，是建立框架的基础。

22. 结构层：是原则层中基本原则的结构化实现，也是对测试解决方案的具体表述。

是框架进行复用和扩展的核心。

细节层：定义了结构层中组件的属性以及属性取值的范围和规律。

是对结构层组件的附加说明，每个组件都需要通过一些属性来进行详细描述。

组件的属性是进行框架实例化（根据具体的被测软件以及测试的目标对测试框架中组件属性的直接操作）的基础。

测试框架的优势：1) 利用面向对象技术2) 更大的应用领域3) 测试组件的复用4) 提高了测试的有效性5) 良好的可扩展性和易用性23. 测试框架功能性体现在以下2个方面：1) 测试框架所表述的测试解决方案的测试能力。

2) 测试框架对解决方案的表述能力。

24. 测试框架可维护性体现在：1) 测试框架的组件化和模块化（基础）2) 测试框架体系结构的合理性（良好的可修改和可扩展性，准确表述解决方案）25.基于测试框架的软件测试过程：1) 对测试框架的选择1 确定测试目标2 选择框架2) 使用框架进行测试1 测试框架学习2 测试框架扩展（根据测试对象和目标考察框架与测试需求之间的符合程度，决定是否来扩展）3 框架实例化4 进行软件测试确定测试目标选择测试框架选择测试框架测试框架实例化否是进行软件测试测试框架扩展是否扩展测试框架学习使用测试框架26. 测试框架适配1) 测试框架扩展（遵守框架基本原则的前提下载结构层中对框架体结构进行的扩展）1 识别可扩展点2 进行更改2) 测试框架实例化（实质是对测试框架的细节层中描述的组件属性进行具体的赋值过程）27. 应用框架可分为冷点 Frozen Spot（实例化过程中始终保持不变的部分）热点 Hot Spot (=可扩展点 extension point，描述了应用框架中那些具体应用需求而不同的部分)28. 测试框架的设计原则1) 提供准确而完整的功能2) 实现合理而适度的易用性（主要来衡量测试框架在使用中满足需要的能力。

设计过程中主要考虑2方面：普适性【能够在多大范围内得到复用】和可操作性【是否能够有效地针对具体的测试领域进行具有专门性的测试】）3) 尽量采用组件化和模块化设计测试框架的设计过程1) 测试问题的泛化（是类元的一般描述和具体描述之间的关系，具体描述建立在一般描述的基础之上，并对其进行了扩展。

）和测试解决方案的抽象（重点解决的问题：测试域中是否还有具体的概念可以进一步泛化，测试方法是否可以进一步进行抽象以及测试解决方案和测试域之间的符合程度）2) 测试框架的设计（重点解决的问题：测试框架中哪些部分是可以改变的？组件的属性设置是否合适，测试解决方案的抽象程度是否适度）二、软件测试过程29.瀑布模型(将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动规定了各个软件过程自上而下，相互衔接的固定次序，如同瀑布逐级下落)缺点：缺乏灵活性，特别是软件开发初期，在软件需求开发尚不明确或不准确地情况下30. V模型将瀑布模型中的测试部分做了细化，其最大特点(可能也是最大的缺点)就是“线性执行”，测试的工作在编码完成后才开始进行，显然不符合软件测试的“3早”原则.缺点：V模型失败的原因是它把系统开发过程划分为具有固定边界的不同阶段，这使得人们很难跨过这些边界来采集测试所需要的信息。

有些测试应该执行得更早些，有些测试则需要延后进行。

而且，它也阻碍了你从系统描述的不同阶段中取得信息进行综合。

例如，某些组织有时执行这样的做法，即对完成的工作进行签署。

这样的规定也扩展到系统测试的设计。

签署表示已经过评估，该测试设计工作已经完成，除非对应的设计文档改变，否则就不会被修订。

如果同这些测试相关的信息后来被重新挖掘和认识，例如，架构设计表明有些测试是多余的，或者，详细设计表明有一个内部的边界可以和已存在的系统测试组合在一起进行测试的话，那么实际上还需要继续调整原来的系统测试设计。

31.螺旋模型（将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； （2）风险分析：分析评估所选方案，考虑如何识别和消除风险； （3）实施工程：实施软件开发和验证； （4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

优点 1）设计上的灵活性,可以在项目的各个阶段进行变更。

2）以小的分段来构建大型系统,使成本计算变得简单容易。

3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。

4）随着项目推进,客户始终掌握项目的最新信息, 从而他或她能够和管理层有效地交互。

5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点 很难让用户确信这种演化方法的结果是可以控制的。

建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

螺旋模型的项目适用： 对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更！核心：　“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。

您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。

如此不断轮回重复，直到得到您满意的最终产品。

每轮循环包含如下六个步骤： 1. 确定目标，可选项，以及强制条件。

2. 识别并化解风险。

3. 评估可选项。

4. 开发并测试当前阶段。

5. 规划下一阶段。

6. 确定进入下一阶段的方法步骤。

31. 统一的软件开发过程UML:三个关键思想：（使用用例驱动（use-case driver）、以结构体系为中心(architecature-centric)、迭代与增量开发(iterative andeRUP中定义了一些核心概念， 角色：描述某个人或者一个小组的行为与职责。

RUP预先定义了很多角色。

活动：是一个有明确目的的独立工作单元。

工件：是活动生成、创建或修改的一段信息。

32. 统一的开发过程是在重复一系列的组成系统生存期的循环，每次循环都要经历一定的时间（4个阶段：初始(inception)、细化(elaboration)、构造(construction)、移交(transition)）33.模块（单元）测试定义上：单元测试是对程序中的单个子程序、子程序或过程进行测试的过程，即：一开始并不是对整个程序进行测试，而是首先将注意力集中在对构成程序的较小模块的测试上面；必要性上：它是一种管理组合的测试元素的方法手段；以减轻调试（准确定位并纠正某个已知错误的过程）的难度；并提供同时测试多个模块的可能，将并行工程引入软件测试中。

目的上：它是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。

文尾，需指明：单元测试的目标不是为了说明模块符合其规格说明，而是为了揭示模块与其规格说明存在着的矛盾。

　单元测试用例的设计，需先明确两点：单元测试设计测试用例时，需两种类型的信息，即：模块的规格说明、模块的源代码。

虽单元测试总体上是采用面向白盒测试的，但是其设计主导思想是：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。

须明确两个观点：其一、多重条件覆盖准则要优于其他准则；其二、任何逻辑覆盖准则尚不足以胜任作为生成模块测试用例的惟一手段。

同样，无论在白盒测试中判定状态或生成测试用例时都需要利用这样一个辅助手段：列表；即，状态判定表。

执行单元测试过程中，有两点需考虑：其一、如何设计一个有效的测试用例集；其二、将模块组装成工作程序的方式【有两种具体实现方法：增量测试（自顶向下和自底向上的开发或测试过程】）、非增量测试。

增量测试：将测试的模块组装到测试完成的模块集合中，再进行测试。

且必须要为每个模块准备一个驱动模块，但不需要桩模块。

非增量测试：先要独立地测试每个模块，再将这些模块组装成完整的程序。

且测试单独的模块时，需一个特殊的驱动模块和一个或多个桩模块。

1. 驱动模块：人们编写的一个小模块，用来将测试用例驱动或传输到被测模块中，也可以用测试工具替代；还必须向测试人员显示该模块的结果。