软件测试概述
2.1 软件测试的概念
软件测试其实应该是伴随着软件生产而产生，有了软件生产就必然有软件测试，但直到1957年，软件测试才和软件调试区分开来，软件测试的概念也有很多版本。测试目的演变如下表：
证明 检测 预防
表明软件能
工作 发现错误 管理质量
20世纪60年代 20世纪70年代 20世纪90年代
到上世纪80年代，软件质量“号角”吹响之后，软件测试的概念才逐步的稳定下来。1983年IEEE提出了软件工程标准术语定义如下：
“使用人工或
自动化工具运行和测试某个系统的过程，目的在于验证它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”这个定义明确提出了软件测试以检验是否满足需求为目标。
假如给大家一个纸杯子,如何测试呢?大家可能会有很多种答案，比如：倒满水杯，测试一下水杯的容量，这个应该是最先想到的。可能会想到测试杯子的质量，体积，规格尺寸等等。甚至还会想到测试杯子的耐热性，测试杯子的耐腐蚀性等。所有这些测试方案最终的目的就是为了验证纸杯子是否满足了预期设计需求。当然纸杯的最初需求可能是很简单的，就是可以盛水，供人饮用。但质量上乘的纸杯子一定要最大程度的满足用户的需求。而测试过程就是验证这些直接需求和衍生需求是否得到实现，是否达到了预期的设计目标。再发散一下思维还可以有很多想法，比如测试水杯装热水后的传热性，使用者端起水杯是不是可以忍受住？或是采用
其他形式让人端起水杯？测试纸杯是不是可以燃烧？燃烧后是不是会产生有毒的烟？测试水杯制作材料是不是有毒？装其他饮料会不会产生有毒物质？大批量纸杯处理是不是环保的？测试一下水杯的容量等物理规格是否合理？测试一下小孩子拿水杯是不是很容易？等等。可能大家还会想到很多测试方案，其中肯定不乏奇思妙想。当然有的方案需要采用复杂的测试设备和技巧才能完成，甚至需要专门的实验室。但对于一个要做出好产品的企业来说这些测试是必要的。总之开发人员通过设计来实现预期的需求目标，测试人员通过测试来验证预期的需求是否满足。
2.2 软件测试
技术的广度和深度
一个纸杯有不计其数的测试方案，而对于复杂软件产品，特别是大型软件项目的测试就会涉及到很多技术环节，下面谈一下
测试技术的广度和深度。
测试技术的广度体现在软件产品的种类繁多和业务领域的复杂性上。针对与不同的软件产品需要应用不同的软件测试技术。软件测试技术本身也是在不断发展，尤其是近几年。各种测试技术发展迅猛，这就使得软件测试知识体系越来越庞大。大体上软件测试可以分为以下类型和维度：
1) 按生命周期分：
单元测试，集成测试，系统测试，验收测试。
单元测试：又称为模块测试,是针对软件结构中独立的基本单元进行测试。是对单元设计文档的验证过程，通常在编码阶段进行的。
集成测试：又称为组装测试，可以根据集成策略对软件模块进行组装后测试。
系统测试：是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件，外设，某些支持软件，数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统的一系列测试。系统测试根据测试类型又分为功能，性能，容量，GUI测试等测试技术。
2) 按测试方法：分为黑盒测试，
白盒测试，灰盒测试。黑盒测试包括
功能测试用例设计技术；白盒测试包括词法语法分析，静态错误分析，测试驱动技术，程序分析技术。灰盒是介于黑盒与白盒之间的测试方法。
3) 测试过程模型开发和测试项目管理。
4) 按执行测试方式：人工手动测试，
自动化测试技术。其中自动化测试技术又包含了功能自动执行和回归自动化测试，性能模拟自动化测试，数据自动生成，测试过程管理自动化技术，嵌入式自动化。另外还包括整套的测试过程管理解决方案等。
5) 专用系统和专项测试技术。
测试技术不光体现还广度上还体现在深度上。涵盖了计算机网络，
操作系统，处理机，计算机体系结构，软件架构，编码，软件工程等计算机科学领域的多门学科。所以作为测试工程师，这些领域的知识掌握的越深，测试的效果也就越好。
2.3 软件测试工作的特点和重要性
记得<<人件>>书中提过黑衣团队这么一个概念，大意是一公司为了提高软件产品质量，将那些非常有才能的测试工程师组成一组，并给他们特权，让他们在软件产品上市之前进行最终的测试。这个团体逐渐形成自已的个性，也发展了一种渴望并期待发现产品缺陷的哲学。为了更加有个性，他们开始都穿上黑色的衣服，程序一旦有BUG他们就可怕地笑起来。他们的测试根本不是在支持开发人员，而是乐于将程序与程序员放到一种不是测试而是折磨的工序下面。他们还经常聚在一起研究出十分可怕的测试策略，他们一些变态的想法与测试方法让程序员望而生畏欲哭无泪，程序员越觉得糟糕，他们就越觉得过瘾与高兴。虽然这个故事比较夸张但也从另外的角度反映了测试工程师在一定程度上是与开发人员处于对立面，程序员类似于建设者，而测试员更像是破坏者。
其实事实并不是这样的。测试组和开发组同属一个项目组，有着共同的目标，就是生产出高质量的软件产品，测试组发现缺陷增加了开发组的前期工作量，但却能减少项目后期的维护工作量和成本。而如果用户拿到了满是bug的软件产品，损失的不光是后期的维护成本，更重要的是损失了公司的质量信誉。所以测试组和开发组的关系应该是密切配合，通力合作的关系。实践也证明，测试人员与开发人员沟通越充分，测试的效果越好。
