1.3软件测试基本概念
测试（Test）就是检测特定的目标，是否符号标准而采用专用工具或方法进行验证，并最终得出特定结构，软件测试（Software Testing）伴随着软件的诞生而产生，软件测试就是在有限的时间内提高软件质量的保证，是软件开发过程中非常重要的一部分。
1.3.1软件测试发展
经历了5个重要时期：
1、以调试为主：早在20实际50年代，只有科学家级别的人才会编程，编程人员承担了所有工作，没人区分调试和测试，有些比较严谨的科学家已经开始思考“怎么知道程序满足了需求”这类问题
2、以证明为主：在1957年在《软件测试发展》书中作者强调了调试和测试区别
1）调试（Debug）确保程序做了程序想让它做的事情
2）测试（Testing）确保程序解决了程序员想让它做的事情
这也是软件测试史上一个重要的里程碑，它标志软件测试终于自立门户了，这个时期的主要目的就是确认软件是满足需求的，也就是我们常说的“做了该做的事情”
3、以破坏为主
在1979年测试界的经典之作《软件测试之艺术》书中提出测试的经典定义：测试是为了发现错误而执行的程序的过程，我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面、更容易发现问题。
还指出亮点：好的测试用例时发现迄今为止尚未发现的错误的测试用例，成功的测试执行时发现了至今为止尚未被发现的错误的测试执行。
4以评估为主
1983年美国国家标准局提出了测试界很有名的两个名词：验证（Verification）和确认(Validation)就是我们常说的V&V理论，同时IEEE提出软件工程标准术语给软件测试定义是“使用人工或自动手段”来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
5、以预防为主
STEP(Systematic Test and Evaluation Process)产品模型数据交互规范）认为测试与开发是并行的、分析、设计、开发、执行和维护组成，是贯彻整个软件生命周期
1.3.2软件测试的目的
软件测试目的演进，如图1-7所示
1、证明：保证软件茶农是完整的，并且可用或可被集成，同时需要尝试在非正常情况下的功能和特性时否可用，评估系统的风险承受耿立。
2、检测：发现确信错误和系统不足的地方，定义系统的能力和局限性，并提供相关的组件，工作产品和系统质量信息。
3、预防：提供预防和减少可能导致错误的信息
软件测试目的往往包含如下内容：
1） 测试并不是为了找出错误，而是要通过分析错误产生的原因和错误的发生趋势，帮助项目管理者发现当前软件开发过程中的缺陷以便即使改进。
2）需要测试工程师设计出具有针对性的测试方法和改善测试有效性
3）没有发现错误的测试也是有价值的，完整的测试是评估软件质量的一种方法
1.3.3软件测试原则
有以下8种软件测试基本原则
1、所有的测试要追溯到用户的需求：从客户的需求触发，想用户所想、一切从用户角度触发。
2、测试应今早地介入
3、测试无法穷举：需要通过风险分析、优先级分析以及软件质量模型和不同测试的方法来确定测试关注点，从而代替穷举测试，提高测试覆盖率
4、避免开发者自测：如程序员对需求规格说明理解错误，而引入的错误是很难发现。
5、群集现象：二八定律表明：80%的错误集中在20%的程序模块中，测试过程中药充分注意群集现象，对发现错误较多的程序段或软件模式，应进行反复的深入的测试。
6、杀虫剂悖论：杀虫剂用的多了，害虫就有免疫力了，杀虫剂就发挥不了效力，如果测试用例被反复使用时，发现缺陷的能力就会越来越差，为了避免克服这种现象出现，测试用例需要进行定期评审和修改，不断增加新的不同的测试用例来测试系统的不同部分，从而发现更多的潜在的缺陷，作为测试人员要具有摸索性思维和逆向思维。
7、不存在缺陷的谬论
8、测试活动依赖于测试背景：针对不同的测试背景，进行的测试活动也不同，测试策略和测试方法在选取上也有所不同。
1.4软件测模型
软件测试根据不同的测试对象以及测试项目的背景可采用不同的测试模型实施测试活动：软件测试模型y有V模型、W模型、H模型、X模型和敏捷模型
1.4.1V模型
RAD(Rap Application Development)快速应用开发简称RAD)是软件开发过程中的一个重要模型，模型构图形似字母V，所以又称软件测试的V模型，它通过开发和测试同时进行的方式缩短开发周期，提高开发效率，如图1-8所示
V模型在20世纪80年代后期提出，V模型中的过程从左到右描述了基本的开发过程和测试行为，价值在于它强调软件开发的协作和速度，反映测试活动和分析设计关系，将软件实现和验证有机结合起来，现已渐渐被淘汰。
1.4.2W模型
W模型是在V模型的基础上演变而来的相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动，W模型由2个V组成分别代表开发和测试过程，它明确表明开发和测试的并行关系，如图1-9所示
V&V理论，即验证和确认，在模型实施过程中进行的具体地说就是验证是否做了正确的事情和确认是否把事情做正确了。
1）验证：保证软件正确地实现了特定 功能、验证是否满足了软件生命周期过程中的标准和约定，判断每一个软件生命周期活动是否完成。
2）确认：保证所生存的软件可追溯到用户需求，确认过程是否满足系统需求，并解决了相应的问题。
W模型强调被测对象，不仅使程序需求，设计以及每个阶段输出的文档通用需要测试，测试与开发同步进行的。
W模型局限性：在W模型中需求、设计、编程等活动被视为串行的同时测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束后才可以正式开始下一阶段，这样就无法支持迭代的开发模型。
1.4.3H模型
H模型中，软件测试活动是完全独立的，它将测试准备和测试执行分离，有利于资源调配，降低成本、提供测试效率、充分体系测试过程的复杂性、如图1-10所示
测试准备：包括测试需求分析、测试计划、测试设计、测试用例、测试验证等。
测试执行：包括测试运行、测试报告、缺陷分析、回归测试
H模型贯穿整个产品的生命周期与其他流程并发地进行，要尽早准备、尽早执行、不同的测试活动可按照某个次序先后进行，也可以反复进行。
1.4.4X模型
模型如图1-11所示
X模型：左边描述的是针对单独程序片段所进行的相互分离的编码和测试，伺候将进行频繁的交接，通过集成最终称为可执行的程序，然后再对这些可执行程序进行测试，如已通过集成测试的成品可进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多跟并行的曲线表示变更可以在各个部分发生，X模型中提出一个重要的理念是探索测试，这是不进行事先设计的特殊类型的测试。
1.4.5敏捷测试
它通过不断修正的质量指标，正确建立测试策略，确认客户的有效需求来保证产品的质量。
敏捷测试需要关注需求变更产品设计，源代码设计等，通常情况下需要全程参与敏捷开发团队的讨论评审活动，并参与决策指定等。
敏捷测试的主旨是测试驱动开发，所以对测试人员的要求有以下两点。
1）理解敏捷的核心兼职观（沟通、反馈、尊重、学习、分享）
2）具备测试基本的技能，也可以擅长某个领域（如：探索性测试、白盒测试等）
1.5软件缺陷
软件缺陷（Defect）常常又被叫做Bug，是指计算机软件程序中存在的某种破坏正常运行能力的问题错误或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
在IEEE中对缺陷中有一个标准定义如下
1）从产品内部看，是指软件产品开发或维护过程中存在的错误，毛病等各种问题。
2）从产品外部看，是指系统需要实现的某种功能的失效或违背
1.5.1软件为什么会引入缺陷
常见的导致软件中存在缺陷的根源主要有以下几点
1、缺乏有效的沟通或没有进行沟通
2、软件的复杂度
3、程序员编程错误：包括语法、拼写错误以及逻辑设计的错误等。
4、需求的不断变更
5、时间的压力
6、人员过于自信
1.5.2缺陷种类
常见的分为以下4种情况。
1、遗漏：可能是需求调研和分析阶段，还可能后期实现阶段的遗漏。
2、错误
3、冗余：指需求规格说明并未涉及的需求被实现了，也可能是开发人员的画蛇添足或代码复制复用导致的。
4、不满意：用户对产品不满意，项目也算是一个失败的项目。
1.6测试用例
测试用例（Testcase）指对一项特定的软件产品测试任务的描述，体现测试方案、测试方法、测试策略和技术。其目的是将软件测试的行为转化为可管理的模式，同时测试用例也是将测试具体量化的方法之一。
测试用例时软件测试的核心，也是软件测试质量稳定的根本保障，不同的测试类型测试用例也是不同的。
1.6.1测试用例的重要性
主要表现在以下几个方面
1、避免程序漏测：主要是通过把用户的每一个需求发生变更，测试用例也要及时更新，这样可以避免在测试过程中将用户需求遗漏。
2、测试进度把控
3、一个度量指标：可以通过测试用来度量测试覆盖率是多少，测试合格率是多少等。它也是测试结束标准的一个度量指标。
4、分析缺陷的依据：通过在编写用来时，要规划好测试环境所属模块以及测试数据等，当发现缺陷后，开发人员通过测试用例准确的定位和分析缺陷。
5、项目的管理成本
1.6.2测试用例写作思路
编写测试用例需要遵守5C原则（Correct准确 Clear清晰、Conlise简洁、Complete完整、Con-sistent一致）大多公司的测试用例通常包含：用例编号、所属模块、用例标题、用例优先级、前提条件、测试数据操作步骤、预期结果、用例状态等。
1、用例编号：是测试用例的唯一标识主要用来识别该测试用例的目的，用例编号需要具有指引性和维护性格式一般由字母、数字下划线组成，具体格式如下：
产品名称-需求编号-用例类型-测试子项-数字编号
1）产品名称通常是指产品的简称：如客户管理系统简称CRM
2）需求编号通常记录需求规格说明书，需求的编号。
3）用例类型描述测试所属的测试阶段：如单元测试UT、集成测试IT、系统测试ST、验收测试 UAT等。
4）测试子项一般具体指被测试的需求点
5）数字编号根据测试预估用例数来定，通常由001或0001开始
2、所属模块：指被测试需求具体属于那个模块，为了更好识别以及维护用例
3、用例标题：用简洁明了的一句话来描述测试用例的关注点。原则上测试标题也是具有唯一性，就是每一条用例对应一个测试目的。
4、用例优先级：分为三个级别：高、中、低根据需求的优先级别来定义，通常来说高优先级别用例时指软件的核心业务，基本功能需要特性以及使用频率比较高的部分，但是在定义时针对一个需求点我们会定义2-3个优先级高的测试用例。
5、前提条件：指被测功能的先决条件以及测试环境，简单说就是跟测试用例存在因果关系的条件。
6、测试数据：需要输入一些外部数据来完成测试这些数据根据测试用例的具体情况来定，有参数、文件以及数据库记录等。
7、操作步骤：执行测试用例的步骤描述，测试用例执行人员可以根据该操作步骤完成测试，执行、在编写操作步骤时需要注意点就是避免冗余。
8、预期结果：主要用来判断被测对象是否正常，通常在编写预期结果可以从以下两个方面考虑。
1）操作界面的提示：也就是说在执行操作步骤后界面会有什么提示信息。
2）数据库的变化：也就是说在执行操作步骤后，数据库会发什么变化。
9、用例状态
用例状态一般分为：pass通过、FAIL失败、N/A为执行、此项在编写用例时为空，当执行完测试用例后在填写。
