软件测试

　　软件测试（英语：Software Testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

测试原则

　　对计算机软件进行测试前，首先需遵循软件测试原则，即不完全原则的遵守。不完全原则即为若测试不完全、测试过程中涉及免疫性原则的部分较多，可对软件测试起到一定帮助。因软件测试因此类因素具有一定程度的免疫性，测试人员能够完成的测试内容与其免疫性成正比，若想使软件测试更为流畅、测试效果更为有效，首先需遵循此类原则，将此类原则贯穿整个开发流程，不断进行测试，而并非一次性全程测试。

所谓的测试原则指的就是我们在执行测试工作时必须要遵守的一些规则：

　　1．测试证明软件存在缺陷：无论执行什么样的测试操作都保能证明当前软件是有缺陷的。

　　2．不能执行穷尽测试：有些功能是没有办法将所有的测试情况都逻列出来，所以任何的测试操作都有结束的时间。

　　3．缺陷存在群集现象：对于软件功能说，核心功能占 20%，非核心是 80%。在实际工作中我们会集中测试 20%的核心功能，所以这个部分发现缺陷的几率就会高于 80%。因此我们我们就会遇到缺陷都集中在 20% 功能模块里的现象。比如qq的核心功能就是聊天，但是它还有很多其他的功能。

　　4．某些测试需要依赖特殊的环境

　　5．测试应尽早介入：为了更多的发现和更好的解决软件中的缺陷，我们追求测试工作尽早的开展。

　　6．杀虫剂现象：同样的一个测试用例不能重的执行多次，因为软件会对它产生免疫。  

　　7．不存在缺陷谬论：任何软件不可能是完美的。

测试方法

静态测试方法

　　静态测试方式指软件代码的静态分析测验，此类过程中应用数据较少，主要过程为通过软件的静态性测试（即人工推断或计算机辅助测试）测试程序中运算方式、算法的正确性，进而完成测试过程，此类测试的优点在于能够消耗较短时间、较少资源完成对软件、软件代码的测试，能够较为明显地发现此类代码中出现的错误。静态测试方法适用范围较大，尤其适用于较大型的软件测试。

动态测试

　　计算机动态测试的主要目的为检测软件运行中出现的问题，较静态测试方式相比，其被称为动态的原因即为其测试方式主要依赖程序的运用，主要为检测软件中动态行为是否缺失、软件运行效果是否良好。其最为明显的特征即为进行动态测试时软件为运转状态，只有如此才能于使用过程中发现软件缺陷，进而对此类缺陷进行修复。动态测试过程中可包括两类因素，即被测试软件与测试中所需数据，两类因素决定动态测试正确展开、有效展开。

黑盒测试

　　黑盒测试，顾名思义即为将软件测试环境模拟为不可见的“黑盒”。通过数据输入观察数据输出，检查软件内部功能是否正常。测试展开时，数据输入软件中，等待数据输出。数据输出时若与预计数据一致，则证明该软件通过测试，若数据与预计数据有出入，即便出入较小亦证明软件程序内部出现问题，需尽快解决。

白盒测试

　　白盒测试相对于黑盒测试而言具有一定透明性，原理为根据软件内部应用、源代码等对产品内部工作过程进行调试。测试过程中常将其与软件内部结构协同展开分析，最大优点即为其能够有效解决软件内部应用程序出现的问题，测试过程中常将其与黑盒测试方式结合，当测试软件功能较多时，白盒测试法亦可对此类情况展开有效调试。其中，判定测试作为白盒测试法中最为主要的测试程序结构之一，此类程序结构作为对程序逻辑结构的整体实现，对于程序测试而言具有较为重要的作用。此类测试方式针对程序中各类型的代码进行覆盖式检测，覆盖范围较广，适用于多类型程序。实际检测中，白盒测试法常与黑盒检测法并用，以动态检测方式中测试出的未知错误为例，首先使用黑盒检测法，若程序输入数据与输出数据相同，则证明内部数据未出现问题，应从代码方面进行分析，若出现问题则使用白盒测试法，针对软件内部结构进行分析，直至检测出问题所在，及时加以修改。

测试流程

1. 需求分析

 (1) 当前阶段的核心目的就是梳理清楚我们需要设计的点是什么。

 (2) 需求的来源：需求规格说明书、API 文档、竟品分析、个人经验

2. 设计用例：

 (1) 用例就是用户为了测试软件的某个功能而执行的操作过程。

 (2) 设计用例是有方法的（ 等价类、边界值、判定表...... ）

3. 评审用例:对当前的用例进行添加或者删除。

4. 配置环境

 (1) 环境：指的就是当前被测对象运行所需要的执行环境，做为测试人员需要具备配环境的能力。【 一般情况下都会使用一键安装的集成环境 】

 (2) 环境分类：操作系统 + 服务器软件 + 数据库 + 软件底层代码的执行环境。

5. 执行用例

(1) 一般在执行用例之前我们会做一个冒烟测试。 这种测试的核心就是快速的对当前软件的核心功能或者主体执行流程进行验证。如果冒烟测试阶段有问题，则可以将此版本回退给开发。

(2) 如果冒烟测试通过那么才会开展示全面的测试。

6. 回归测试及缺陷跟踪

 (1) 回归测试指的就是当我们将某个缺陷提交给开发之后，由它们进行修复，修复完成之后需要测试认员再次对其进行测试【回归测试】

 (2) 缺陷跟踪：指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪。

7. 输出测试报告

 将当前的测试过程中产生的数据进行可视化的输出。方便其它人去查看。

8. 测试结束 

当将整个测试过程中产生的一些文档进行整理归档，方便后续版本使用。

 

计算机组成图

 

软件开发过程模型

瀑布型模型

 

 

测试切入点

　　测试阶段处于软件后期实现后，必须在代码完成后留有足够的时间给测试，

　　导致测试时间不够充分，很多问题到项目后期才暴露出来。

优点：

　　开发的各个阶段比较清晰。

　　强调早期计划及需求调查。

　　适合需求稳定的产品开发

缺点：

　　依赖于早期的需求调查，不适应需求的变化。

　　单一流程不可逆。

　　风险往往延至后期才显露，失去及早纠正的机会。

　　问题在项目后期才开始暴露。

　　前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败。

快速原型模型

 

　　在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。第一步是建造一企快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化徒开发软件的需求。通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么。第二步是在第一步的基础上开发出用户满意的软件产品。

快速原型模型优点

　　克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。

　　适合预先不能确切定义需求的软件系统的开发。

快速原型模型缺点

　　不适合大型系统的开发（适合开发小型的、灵活性高的系统）。

　　前提要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

 

 

螺旋模型

螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，螺旋模型沿着螺旋线旋转，即在坐标的4个象限上分别表示了4个方面的活动，如图所示：

制定计划

风险分析

实施开发

客户评估

 

 

螺旋模型优点

　　螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

螺旋模型缺点

　　采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。过多的迭代次数会增加开发成本，延迟提交时间。

 

测试模型

 

 

需求分析：用户的需求、业务需求。

概要设计：系统架构、模块划分、模块与模块之间的接口。

详细设计：模块内部实现的逻辑和方法。

编码：实现上面的设计。

单元测试：（类、函数、组件）

集成测试：多模块连接测试

系统测试：系统主体进行测试

验收测试：检测产品是否符合最终用户的需求

优点：

　　V模型清楚的标识出软件开发的阶段

　　测试V模型即包含了底层测试又包含了高层测试

　　　　底层测试 ：检验源代码质量的测试，如：单元测试

　　　　高层测试：检验整个系统的需要，如：系统测试

缺点：

 　　V模型一大缺点正是它自身的顺序性所导致的。到了测试阶段，程 序已经完成，错误已经产生，很多前期的错误一直到测试阶段才 发现，甚至无法发现，往往无从修改了。 

 　　灵活性比较低。

 

X模型

 

 

　　X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。

　　X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执 行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。

    X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

优点

　　X模型定位了探索性测试，这是不进行事先计划类的测试，这一方式往往帮助有经验的测试人员在测试计划之外发现更多的软件错误。

缺点

　　可能对测试造成人力、物理和财力的浪费，对测试员的熟练程度要求比较高。

W模型

　　测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试（这里针对设计文档，一般可以划分为需求设计文档、概要设计文档、详细设计文档和代码文档），也就是说，测试与开发是同步进行的。

　　从这个角度来说，一个完整合格的测试人员对软件各方面把握程度应该比开发人员更高，一个测试人员要能胜任软件研究任何一个岗位。

　　W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求文档的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

 

 

 

　　 但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

优点

　　测试的活动与软件开发同步进行

　　测试的对象不仅仅是程序，还包括需求和设计

　　尽早发现软件缺陷可降低软件开发的成本

缺点

　　开发和测试依然是线性的关系，需求的变更和调整，依然不方便；
　　如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！

H模型

　　H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备, 尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展。

H模型优点：

　　开发的H模型揭示了软件测试除测试执行外，还有很多工作。

　　软件测试完全独立贯穿整个生命周期与其它流程并发进行；

　　软件测试活动可以尽早准备尽早执行，具有很强的灵活性；

　　软件测试可以根据被测对象的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

H模型的缺点：

　　管理型要求高：要定义清晰的规则和管理制度，否则测试过程将很难管理和控制

　　技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；

　　测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪，就绪点标准是什么，对后续的测试执行启动带来很大的困难

　　对整个项目组的人员要求非常高：在很好的制度下，大家都能高效的1工作，否则容易混乱（对整个项目足够熟悉）。例如：你分了一个很小的迭代，但因为人员技能不足，使得无法完成，那么整个项目会受到很大的干扰。

 

总结：

1.软件测试过程模型－V模型是软件开发瀑布模型的变种，主要反映测试活动与分析和设计的关系；局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现

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

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

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

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