第13章——软件测试简介
一、软件测试基本概念：
为了度量和提高被测软件的质量，对测试件进行工程设计、实施维护的整个生命周期过程。
二、软件测试案例：
1、迪士尼的狮子王 （19941995）软件在少数系统中能正常工作，但在大众使用的常见系统中不行。后来证实，迪士尼公司没有对市场上投入实用的各种pc机型进行正确的测试。
2、英特尔奔腾浮点除法软件缺陷（1994）英特尔为自己处理软件缺陷拿出4亿美元支付更换坏芯片的费用。导致付出如此昂贵的代价，其主要原因是发现了软件缺陷没有正确的处理。
3、美国航天局火星极地登陆（1999）该项目使用前有经过测试，两个测试小组双方独立工作都很好，但从未走在一起。
4、爱国者导弹防御系统 （1991）一枚导弹在多哈击毙28名美国士兵，症结在于一个软件缺陷，一个很小的系统时钟错误累积起来就可能拖延14小时，造成跟踪系统失去准确度。在多哈袭击战中系统被拖延100小时。
总结：再严密的测试也不能完全发现软件当中所有的错误，但是测试还是能发现大部分的错误，能确保软件基本是可用的，所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论，故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。
三、软件测试的基本原则包括：
1.所有的测试都应追溯到用户需求。正如我们所知软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2.应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。 因此，所有测试应该在任何代码被产生前就进行计划和设计。
3. Pareto原则应用于软件测试。简单地讲 ，Pareto原则暗示着测试发现的错误中的 80%很可能起源于程序模块中的20%。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4.测试应从小规模开始，逐步转向大规模。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
5.为了达到最佳效果应该由独立的第三方来构造测试。 最佳效果指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。
6.不充分的测试是不负责任的，过分的测试是一种资源的浪费，同样也是一种不负责任的表现. 。
四、软件缺陷的定义：
1、软件未达到产品说明书标明的功能。
2、软件出现了产品说明书指明不会出现的错误。
3、软件功能超出产品说明书指明范围。
4、软件未达到产品说明书虽然未指出但应达到的目标，此条是抓住产品说明书上遗漏之处。
5、软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
五、产生软件缺陷的原因很多：
1、软件模型或者说业务建模制定不正确，这类占了70%左右，并且难以纠正。
2、软件庞大，功能复杂。
3、编程过程出错，此类占20%左右，一般比较容易纠正。
4、个别功能要求改变而影响其他部分。
5、与要开发的软件对接的第三方软件有缺陷。
6、人为因素。
不同时期修复BUG的投入费用也不一样，越到开发后期修复BUG的成本越高。
六、软件测试原则：
1、完全测试程序是不可能的，不可能找出软件的所有缺陷。
2、软件测试是有风险的行为，风险来自于软件测试的范围，故要去粗存精。
3、测试无法显示的潜伏的软件缺陷，
4、软件缺陷都是成群出现的。
5、软件测试方法及技术要不断更新。
6、不是所有软件都能修复。
7、开发小组对于缺陷的的定义不一定一致。
8、产品不断升级导致缺陷越多。
9、软件测试员在小组不受欢迎。
七、关于软件测试的分类从是否需要执行被测软件的角度可分为 ：
1.静态测试：
静态测试是指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。
其中包括代码测试、界面测试和文档测试3个方面。对于代码测试，主要测试代码是否符合相应的标准和规范。对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。对于文档测试，主要测试用户手册和需求说明是否符合用户的实际要求。
2.动态测试：
动态测试是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以，我们判断一个测试属于动态还是静态测试，唯一的标准就是看是否运行程序。
八、从测试是否针对系统的内部结构和具体实现算法的角度来看可分为：
1.黑盒测试：
指的是把被测软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子，只关心软件的输入数据和输出结果。
黑盒测试方法是在程序接口上进行测试主要是为了发现以下错误:
1.是否有不正确或遗漏了的功能?
2.在接口上输入能否正确地接受?能否输出正确的结果?
3.是否有数据结构错误或外部信息(例如数据文件)访问错误?
4.性能上是否能够满足要求?
5.是否有初始化或终止性错误?
用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。
黑盒测试的测试用例设计：
1.等价划分法
2.边界值法
3.错误推测法
4.因果图法
2.白盒测试：
指的是把盒子盖打开，去研究里面的源代码和程序结构。
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。 使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。
白盒测试的主要方法：
1.逻辑驱动测试
2.基本路径测试
主要用于软件验证。
使用程序设计的控制结构导出测试用例。
白盒测试、灰盒测试、黑盒测试。分别由三个不同的角度：开发者、旁观者、用户来进行测试。
按软件测试要求可以把软件测试分为基本功能测试、全面测试和基准测试。
基本功能测试：只对软件关键功能测试。
全面测试：对软件全部功能测试，是回归测试的主要组成部分。
基准测试：通过多个相同环境的计算机的测试，测试其性能是否一致。
按软件特性可以分为功能测试和非功能测试。
九、自动化测试一般在下班后进行，不需要人进行干预。
有以下优点
1、节省大量时间。
2、没有时间限制。
3、可以反复执行。
4、保证测试的一致性以及准确性。
5、有较高的功能测试覆盖率。
6、模拟操作进行压力测试。
缺点：
1、并非所有都能使用自动化。
2、没有创造性。
3、受具体项目资源限制，受人力限制。
一般自动化测试可按照：
1、编写测试用例。
2、分析、验证测试用例。
3、对已有测试用例归类，制订自动化计划方案。
4、编写自动化测试程序。
5、尽量用“数据驱动”来提高测试覆盖率。
6、将测试用例编写成自动化测试程序。
7、执行测试程序，记录并反馈BUG。
8、不断完善自动化测试系统或程序。
十、BUG管理
1、BUG登记——测试工程师，初始。
2、指派任务——项目经理，激活。
3、修改BUG——开发工程师，修改。
4、验证——测试工程师，通过则转第5步，否则转第2步，状态为再激活。
5、关闭——测试工程师。
BUG的分类：
1、按缺陷状态分类。
2、按缺陷严重分类。
3、按缺陷优先级分类。
第14章 系统实现与测试过程
一、CMMI中与之对应的实践也包括了三大部分。技术解决方案（Tenchnical Solution,TS）过程域、验证（Verification,VER）过程域、产品集成（Product Integration，PI）过程域。
技术解决方案（TS）过程域中对应的实践
SG3 Implement the Product Design（实现产品设计）
SP3.1 Implement the Design（实现设计）
SP3.2 Develop Product Support Documentation（建立产品支持文档）
产品集成（PI）
SG1 Prepare for Product Integration（产品集成准备）
SP1.1 Establish an Integration Strategy（建立集成战略）
SP1.2 Establish the Product Integration Environment（建立产品集成环境）
SP1.3 Establish Product Integration Procedures and Criteria（建立集成规程及准则）
SG2 Ensure Interface Compatibility（确保接口的兼容性）
SP2.1 Review Interface Descriptions for Completenss（审查接口描述的完整性）
SP2.2 Manage Interfaces（管理接口）
SG3 Assemble Product Components and Deliver the Product（装配产品组件并交付作品）
SP3.1 Confirm Readiness of Product Components for Integration（确认用于集成的产品组件准备就绪）
SP3.2 Assemble Product Components（装配产品备件）
SP3.3 Evaluate Assembled Product Components（评估已装配产品部件）
SP3.4 Package and Deliver the Product Component（打包并交付产品或产品组件）
验证（VER）
SG1 Prepare for Verification（准备验证）
SP1.1 Select Work Product for Verification （选择待验证的工作产品）
SP1.2 Establish the Verification Environment（建立验证环境）
SP1.3 Establish Verification Procedures an Criteria（建立验证规格说明）
SG3 Verify Selected Work Products（验证选定的工作产品）
SP3.1 Perform Verification（执行验证）
SP3.2 Analyze Verification Results（分析验证等级）
二、系统实现与测试过程简述：
软件开发过程中，系统实现与测试过程至关重要。
1、实现产品组件的编码并产生相应的支持文档
2、准备产品/系统集成，确保接口兼容性，组装产品组件。
3、同时适时对产品组件进行单元测试和集成测试，实现对产品组件及集成的产品构件的验证。
不同的角色在软件开发分别担任不同的职责。
三、编码中常见问题：
1、如何避免卡法阻塞？
项目经理在安排任务是要得当的分配。
2、有最好的编程语言吗？
没有，只有最适合的编程语言。
3、换用更快的计算机还是开发更快的算法？
根据“成本——收益”来决定。
4、要多用新技术和技巧吗？
开发软件是为了满足客户的需要，尽可能使用成熟的技术。
5、夜里编程效率更高吗？
一鼓作气完成效率最高。
6、如何提高团队编程的质量
组件开发团队时多一些编程老手，多一些责任心。
四、测试流程：
1单元测试：在设计阶段整个系统被分为许多的单元模块，因此要先进行单元测试来找出具体问题。
2集成测试：集成测试是单元测试的逻辑扩张，找出当许多单元结合时产生的问题。
第15章 制定测试方案及编写测试用例
一、CMMI对应实践：
CMMI中VAL（Validation，确认）过程域的相关准备活动
SP1.1 Select Product for Validation（选择需要确认的产品）
SP1.2 Establish the Validation Environment（建立确认环境）
SP1.3 Establish Validation Producedures and Criteria（建立并维护确认过程和准则）
二、测试资料整理：
1、通用信息
一般信息：
公司大体情况；测试部门大体情况；周围人与事、工作环境；公司文化
技术信息：
软件类别及构成；软件的用户界面；涉及的第三方软件
2、被测软件的类别及构成
需要了解软件的类别及结构
3、被测软件的用户界面
需要了解最终用户的软件界面
测试计划要解决的重点：
1、软件及测试基本情况
2、软件目前主要存在的问题
3、软件管理流程（BUG）
4、使用的测试软件、BUG管理软件、配置管理软件
5、测试环境
6、软件产品的文件、说明
三、测试方案是软件测试的总体规划：
测试计划书的衡量标准——必须有明确的测试目标、范围和深度、具体实施方案、及测试重点；提供大体的测试进度及所需的资源（人力、物力、软件、硬件等）
测试计划内容
1、测试计划书的文件名及版本号
2、基本情况介绍
3、测试的具体目标
4、具体执行的测试类型
5、测试通过的判断标准
6、测试用例
7、测试准备工作及测试结果的处理
8、测试工作中涉及的相关事项
9、部门责任分工
10、测试人力资源分配
11、测试进度列表
12、测试工作可能面临的偶然事件及危机处理；缺陷管理流程
第16章 系统测试
一、CMMI中对应实践：
VAL过程域
SG2 Validate Product or Product Components（确认产品或产品组件）
SP2.1 Perform Validation（执行确认）
SP2.2 Analyze Validation Results （分析确认结果）
二、系统测试活动内容：
1、用户层,主要是面向产品最终的使用操作者的测试，重点是突出从操作者角度，测试系统对用户支持的情况。
2、应用层，针对产品应用的测试，重点在系统应用的角度，模拟实际应用环境，对系统兼容性、可靠性、性能进行的测试
3、功能层、针对产品具体功能实现测试
4、子系统层，针对产品具体功能实现的测试
5、协议/指标层，针对系统支持的协议、指标的测试