测试常识

软件测试产生的背景

软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证(SQA)的主要职能，包含软件质量评价的内容，Bill Hetzel在《软件测试完全指南》(Complete Guide of Software Testing)一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义至今仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。

测试工作的定位

相关前辈提到“测试工作负责桥接开发的结果与客户的需求，站在客户的角度审视开发的结果是否是用户想要的作品，做好产品发布前的最后一班岗”。

百度百科自称IEEE提出的软件测试定义：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。（这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体）。

有博客提到“软件测试是一种实际输出与预期输出之间的审核或者比较过程”和”软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程”。

有博客提到测试的目的是“为了发现程序中存在的错误而执行程序；
为了证明程序有错，而不是证明程序无错误”，即以发现开发的问题为目的，以客户需求为标准衡量是否是问题（即也不要乱提问题）。

软件测试的基本原则

站在用户的角度，从需求出发，对软件进行全面的、深入的测试，尽早、尽可多地发现Bug，并跟踪和分析软件中存在的问题，对不足之处提出质疑和改进意见。

软件测试的具体原则：

1、准备详尽的测试工作计划，并及时维护。
2、所有测试的标准都应该建立在需求之上。
3、事先定义好产品的质量标准，并不遗余力的去执行。
4、尽可能早的开始测试工作。
5、避免让程序员测试自己的程序。
6、测试用例是设计出来的，不是写出来的。
7、对发现错误较多的程序段，应进行更深入的测试；对于出错多的程序员编写的程序同样需要给予特别关注。

测试工作的流程

测试工作的各个阶段

• 单元测试：
  将整个软件分解为各个单元，随后对单元模块进行功能测试、边界测试、容错测试、界面测试、控制流和数据流测试，以及模块内的业务流程测试。

  此类测试策略的优点在于所需分析数据较少，且针对性较强，程序开发者于开发过程中可通过操作经验明确出问题所在的大致区域，随后针对此类问题对相关单元展开分析，进行问题排查。

  但需注意的是，某些程序中无具体单元驱动程序，即单个单元无法有效驱动，易出现问题，若针对此类软件展开测试，需重点注意此类分解单元。

• 集成测试：
  系统集成后的相关接口测试、功能测试、容错测试、约束测试，跨模块的业务流程测试等。

系统测试：
系统性的初始化测试、功能测试、业务处理和数据处理测试、性能测试、压力测试、安装卸载测试等。

验收测试：
在用户现场和用户一起对系统进行功能确认、用户需求确认、备份恢复测试、安全性测试等。

回归测试：
系统使用过程中发现问题修改完成以后，测试对应的问题是否修改好了，测试新修改的功能是否引发新的缺陷，测试与修改代码相关的其它程序功能是否依然正确。

软件测试模型

V模型

W模型

X模型

H模型

测试用例

为了特定的测试目的而设计的具有测试输入、测试执行条件、预期结果及结果验证方法的文档。

测试用例的特点

• 最有可能抓住错误的
• 不是重复的、多余的
  （待定是否保留）一组相似测试用例中最有效的
  （待定是否保留）既不是太简单，也不是太复杂

测试用例设计原则

• 测试用例的代表性
• 需求的可追溯性
• 测试结果的可判定性、可再现性
• 测试用例粒度的合适性