第十三章
1.软件测试基本概念
1.1 软件测试背景
1979年Glenford Myers在《软件测试艺术》一书中作出了当时最好的软件测试定义：“测试是为了发现错误而执行的一个程序或者系统的过程。”
1983年，bill hetzel在《软件测试完全指南》一书中指出：“测试是以评价一个程序或者系统属性为目标的如何一种活动。测试是对人家质量的度量。”
Myers和hetzel的定义至今仍被引用
2002年，Rick和Stefan在《系统的软件测试》中对软件测试做了进一步的定义：“测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护整个生命周过程。”
1.2 软件缺陷
可以从以下5点来定义软件缺陷。
1）软件未达到产品说明书（简称,SPEC）标明的功能。
2）软件出现了产品说明书指明不会出现的错误。
3）软件功能超出产品说明书指明的范围。
4）软件未达到产品说明书虽然未指出但应达到的目标，此条的目的是抓住产品说明书上遗漏之处。
5）软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
产生软件缺陷的原因一般可以归纳为以下几点。
1）软件模型或者说业务建模制定不正确，更直观的理解是，SEPC本身不明确或有错误，没有很好的描述要开发的软件。
2）软件庞大，功能十分复杂。
3）编程过程出错，此类比较容易纠正。
4）个别功能要求改变从而影响到其他部分。
5）与要开产的软件对接的第三方软件有缺陷。
6）其他人为因素。
1.3 软件测试原则
在执行软件测试的过程中可以参照以下几点原则。
1）完全软件测试是不可能的，不可能找出软件的所有缺陷。
2）测试无法显示潜伏的软件缺陷。
3）软件缺陷大概率都是成群出现的。
4）并非所有软件缺陷都能修复。
1.4 优秀的软件测试员必备
1）探索精神。 2）不懈努力。 3）创造性。 4）追求完美。 5）判断准确。 6）成熟老练。 7）表达能力好。
13.2 软件测试分类
白盒测试。测试人员直接在软件程序上进行测试、修改、复测。分为：语句测试；分支测试；路径测试；条件测试；目测等。
黑盒测试。测试人员不必深入了解软件的内部设计，只是从一个终端用户的角度根据产品说明书的指标，从外部测试软件的各项功能及性能。
灰盒测试。介于黑白两者之间，是两者的结合。
自动化测试。使用自动化工具进行的测试。一般不需要人为干预。
13.3 BUG管理流程
3.1 通用BUG管理流程
1）BUG登记——测试工程师，初始。
2）指派任务——项目经理，激活。
3）修改BUG——开发工程师，修改。
4）验证——测试工程师，通过则转第5步，否则转第2步，状态为再激活。
5）关闭——测试工程师。
3.2 BUG的分类
1）按缺陷严重级分类
严重。不能完全满足系统要求，基本功能未能完全实现；
较严重。严重影响系统要求或基本功能的实现，且没有更正办法。
一般。严重地影响系统要求或基本功能的实现，但存在合理的更正方法。
轻微。使操作者不方便或遇到麻烦，但不影响执行工作或重要功能。
2）按缺陷优秀级分类
高：立即解决，否则将影响进一步测试。
中：正常排队，在产品发布前按正常安排进行修复。
低：可暂缓解决，如果时间允许应该修复，不修复也能发布。
第十四章
1 系统实现与测试过程简述
系统实现与测试过程至关重要，在此过程中，主要是达到以下几个目的。
1）实现产品组件的编码并产生相应的支持文档。
2）准备产品/系统集成，确保接口兼容性，组装产品组件。
3）同时适时对产品组件进行单元测试和集成测试，实现对产品组件及集成的产品构件的验证。
整个实现及测试过程的活动可分为：准备工作、产品实现、单元测试、缺陷管理与改错、系统集成及集成测试、建立产品支持文档六部分。
2 测试流程
1）单元测试
在设计阶段，整个系统被细分为许多模块（或类），这里可以把模块或类理解为单元。每个单元的接口、数据结构与算法都已经设计完成。在编码完成以后，把这些单元集成起来之前，需要先执行单元测试，以保证单元本身正确无误，保证单元符合设计要求。
2）集成测试
集成测试是单元测试的逻辑扩展，最简单的形式是将两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。
集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。
3 缺陷管理与改错
1）在单元测试和集成测试过程中发，发现缺陷时，必须将缺陷记录在《缺陷管理列表》或记录进BUG管理工具。
2）开发人员消除缺陷后，测试开发人员应当马上进行回归测试，确保不会引入新的缺陷。
3）测试人员发现缺陷后，填写《缺陷管理列表》或BUG管理工具中缺陷信息项，并将其状态置为“已建议”，提交项目经理。
4）项目经理确认缺陷内容后，将其转为相关人员解决或指派给相关人员解决，状态改为“活动的”。
5）当缺陷解决人员认为缺陷已经修复后，即可填写《缺陷管理列表》或BUG管理工具中相应项改为“已解决”，指派给原来的测试人员进行回测。
6）测试人员回测，填写《缺陷管理列表》或BUG管理工具中验证信息项。
如该缺陷被修复了，则将该缺陷状态改为“关闭”
如该缺陷未被修复，则将该缺陷状态置为Reopen。
不论该缺陷有没有被修复，若在回测过程中，测试出新缺陷，则在原《缺陷管理列单》中创建新的工作表，并标识为复测。
7）开发人员查询状态为open和reopen的缺陷，不是缺陷，由项目经理确认后，可置状态为rejected。
8）对于不能解决和延期解决的缺陷，开发人员要提出申请，争求项目经理的同意后，才能将其状态置为“rejected”。
4 建立产品支持文档
文档人员在开发人员的协助下编制《用户操作手册》、《系统维护手册》、《培训教材》、联机帮助、系统安装包等。
《用户操作手册》、《系统维护手册》、《培训教材》、联机帮助等完成之后，由项目经理组织同行评审。
当满足以下条件时，系统实现与测试整个过程可以结束。
软件代码已经编写完成，软件集成在一起可以运行。
满足集成测试结束准则，集成测试通过。
本过程所有文档已经完成，并通过同行评审。
十五章
1 测试资料收集与整理
1）通用的信息
2）被测软件的类别及构成
3）被测软件的用户界面
2 测试方案的确定
在制定测试方案时，需要考虑以下四个因素。
1）软件的现状及将来可能的发展，现状包括软件的复杂程度、规模、现有缺陷的难度及缺陷发现的频率等；软件将来可能的发展，需要在决定测试结构时预留一些空间。
2）现有资源及将来可能获得的补充资源。
3）风险分析：软件系统与选定的硬件或某些第三方软件的不兼容性；
4）制定测试的策略，确定采用的测试方法、范围，一般功能测试、安装测试，兼容性测试是必不可少的。
3 测试用例编写
1）单元测试用例编写
1.1 什么时候进行单元测试
一般来说，对于开发单元测试越早越好。
先编写产品的函数框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码。
1.2 谁来执行单元测试
单元测试由程序员完成，经过了单元测试的代码才是已完成的代码。在项目中，单元测试也由开发人员来做。一般单元测试用例包含以下内容。
用例编号、被测对象。
测试用例的核心是输入数据，输入数据包括四类：参数、成员变量、全局变量、IO媒体。
期望输出，在给定的输入条件下，单元应当给的反映。
十六章
1 系统测试简述
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计的标准和规定。
2 系统测试活动内容
1）系统测试内容
1.1 用户层
主要是面向产品最终的操作者的测试，包括用户界面的规范性，友好性，可操作性，以及数据的安全性。
1.2 应用层
针对产品应用的测试，重点在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行的测试。
1.3 功能层
针对产品具体功能实现的测试。
1.4 子系统层
针对产品内部结构性能的测试，关注子系统的性能，模块间接口的瓶颈。
1.5 协议/指标层
针对系统支持的协议、指标的测试。
2）制订系统测试计划
3）设置测试用例
4）执行系统测试