第一章 基本概念
一、软件生命周期(SDLC)的六个阶段
（1）问题的定义
此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
（2）需求分析
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
（3）软件设计
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
（4）程序编码
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
（5）软件测试
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
（6）运行维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。
二、.软件生命周期模型
典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型、螺旋模型。
1.瀑布模型
传统的软件开发流程。即：问题定义、需求分析、设计、编码、测试、运行维护六个阶段。
2.V模型
在V模型中，测试过程被加在开发过程的后半部分，单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。
V模型的缺陷：
仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段 ；
忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。
3.W模型
对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
W模型的优点：
测试的活动与软件开发同步进行；
测试的对象不仅仅是程序，还包括需求和设计；
尽早发现软件缺陷可降低软件开发的成本。
补充：
软件测试生命周期：需求分析→测试计划 → 测试设计 → 测试执行→ 测试评估
三、软测的定义、目的及原则
1.定义：是为了发现程序中的错误而执行程序的过程。
2.目的：在软件投入运行之前，尽可能多地发现软件中的错误和缺陷，以确保软件的质量。
3.原则：
软件测试应尽早执行，并贯穿于整个软件生命周期
软件测试应追溯需求
测试应由第三方来构造
穷举测试是不可能的,要遵循Good-enough原则
必须确定预期输出（或结果）
必须彻底检查每个测试结果
充分注意测试中的群集现象
缺陷的二八定理
严格执行测试计划，排除测试的随意性
注意合法合理的输入，也要注意非法的非预期的输入
检查程序是否做了不该做的
测试应从“小规模”开始，逐步转向“大规模”
反复使用同样的测试会使软件具有抵抗力
关注缺陷的修复
四、软件缺陷的定义
即计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷、瑕疵。精确定义：
（1） 软件未达到产品说明书要求的功能
（2） 软件出现了产品说明书指明不会出现的错误。
（3） 软件功能超出了产品说明书规定的功能
（4） 软件未实现产品说明书虽未明确指出但应该实现的目标
（5） 软件难以理解，不易使用，运行缓慢或者最终用户认为使用效果不好。
五、软件测试的分类
1．按软件测试的生命周期：
（1） 单元测试：程序员完成。检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。
（2） 集成测试：白盒测试人员或开发人员完成。检查各个单元模块结合到一块是否协同配合，正常运行。
（3） 确认测试：运用黑盒测试检验被测软件是否满足需求规格说明书规定的要求。
（4） 系统测试：黑盒测试人员完成。将已确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种集成测试和确认测试。目的是发现所开发系统与用户需求不符或矛盾的地方。
（5） 验收测试：用户测试为主。
2.按软件技术：白盒、黑盒、灰盒
其中白盒测试可以分为两大类：静态测试、动态测试
静态测试（不运行程序）：代码检查、静态结构分析
动态测试（运行程序）：逻辑覆盖、路径分析
3.按测试内容：功能测试、性能测试、易用性测试、可移植性测试、可靠性测试等
六、软件质量保证和软件测试的关系
同：目的都是尽力确保软件产品满足需求，从而开发出高质量的软件产品。
异：软件质量保证工作侧重对软件开发流程中的各个过程进行管理与控制，杜绝软件缺陷的产生。而测试是对已经产生的软件缺陷进行修复。
七、能力成熟度模型CMM
CMM是指“能力成熟度模型”，是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
八、黑盒测试
1.定义：又称功能测试或数据驱动测试，是针对软件的功能需求/实现进行测试，通过测试来检测每个功能是否符合需求，不考虑程序内部的逻辑结构。
2.黑盒测试方法：等价类划分、边界值分析、决策表法、因果图、错误推测等
九、白盒测试
1.白盒测试也称结构测试或逻辑驱动测试，必须知道软件内部工作过程，通过测试来检测软件内部是否按照需求、设计正常运行
2.白盒测试的主要方法是：
动态测试需要在开发/测试环境或实际运行环境中运行软件，并使用测试用例去查找软件缺陷。主要有逻辑覆盖、路经分析测试
静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估.静态测试包括代码检查、程序结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行。主要有：静态结构分析、代码检查
十、手工测试和自动测试
1..手工测试缺点在于测试工作量大，重复多，回归测试难以实现
2.自动测试利用软件测试工具自动实现全部或部分测试工作：管理、设计、执行和报告；节省大量的测试开销，并能够完成一些手工测试无法实现的测试
手工完成测试的全部过程无法保证测试的科学性与严密性:
– 修改的缺陷越多，回归测试越困难
– 没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率
– 反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一
– 测试花费的时间越长，测试的严格性也就越低
自动测试将测试人员从反复、烦杂的测试执行中解放出来，用更多的时间进行测试设计和结果分析
软件测试不可能完全自动化
不能完成所有手工测试任务
无创造性且灵活性差，不能改进测试的有效性
过程中可能会遇到许多意想不到的问题，特别是当软件不稳定时
测试脚本的维护高
十一、软件测试工程师的素质
良好的沟通能力
掌握比较全面的技术
充分的自信心
足够的耐心和责任感
具备怀疑精神和学习能力
超强的记忆力和良好的洞察力
十二、软件测试的生命周期
需求分析→测试计划 → 测试设计 → 测试执行 → 测试评估
第二章 软件测试从编写开始各个阶段
一、各阶段介绍
1.单元测试
通常情况下是面向白盒的
对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早地发现和解决不易显现的错误
单元测试的内容
– 接口测试
– 内部数据结构
– 全局数据结构
– 边界测试
– 语句覆盖
– 错误处理测试
– 路径测试
单元测试的策略有哪些？
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
2.集成测试
通过测试发现与模块接口有关的问题
目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构
应当避免一次性的集成（除非软件规模很小），而采用增量集成
主要内容：API、API/参数组合
3.确认测试
又称为有效性测试，目的是验证软件的功能和性能及其特性是否与客户的要求一致，是否满足软件需求规格说明书中的规定。
4．系统测试
目的是验证最终软件系统是否满足产品需求并且遵循系统设计
系统测试人员相当于用户代言人
在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作
系统测试主要内容
所有功能需求得到满足
所有性能需求得到满足
其他需求（例如安全性、容错性、兼容性等）得到满足
常见的系统测试方法
安全测试
正确性测试
可靠性测试
兼容性测试
5.用户验收测试
Alpha测试
– 是由用户在开发者的场所来进行的，Alpha测试是在一个受控的环境中进行的
Beta测试
– 由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者
二、各阶段测试任务与可交付文档
第三章 各个文档内容介绍
一、 测试计划
1.如何编写测试计划
测试计划编写6要素（5W1H）
1）why—为什么要进行这些测试；
2) what—测试哪些方面，不同阶段的工作内容；
3) when—测试不同阶段的起止时间；
4) where—相应文档，缺陷的存放位置，测试环境等；
5) who—项目有关人员组成，安排哪些测试人员进行测试
6) how—如何去做，使用哪些测试工具以及测试方法进行测试。
2.通用测试计划应包含以下几个项目：
测试目的、背景、范围
具体目标：列出需要测试和不需要测试部分
测试的策略：采用的测试方法
测试通过的标准，以及没有通过的处理办法
停止测试的标准
测试用例
测试的基本支持
部门责任分工、人力资源分配
测试进度安排
风险估计和危机处理
3.测试计划的组成部分
引言：目的、背景、范围、定义、参考资料
测试内容：测试功能清单
测试规则：进入准则，暂停/退出准则、测试方法、测试手段、测试要点、测试工具
测试环境：硬件环境、软件环境、特定测试环境要求
项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结
实施计划：工作量估计、人员需求及安排、进度安排、其它资源需求及安排、可交付工件
风险管理
二、 缺陷报告（bug报告）
三、 测试用例
测试用例应该包含：测试用例表、测试用例清单、测试结果统计表、测试结果统计表、测试问题表、测试问题统计表、测试进度表、测试总结表（测试评估）
1.测试用例表的组成部分
项目名称 测试编号 功能模块名 功能特性 测试目的 优先级 测试类型 预置条件 操作步骤 预期结果 实际结果 备注
四、测试总结
1.测试报告的版本
2.测试的人员和时间
3.测试所覆盖的缺陷——测试组在这轮测试中所有处理的缺陷，报告了测试组长处理的缺陷和实施工程师验证的缺陷。不仅要写出覆盖缺陷的总数，还要写明这些缺陷的去向，测试新发现的缺陷数量 ，上一版本活动缺陷的数量 ，经过此轮测试，所有活动缺陷的数量及其状态分类 。
4.测试评估——写明在这一版本中，那些功能被实现了，那些还没有实现，这里只需写明和上一版本不同之处即可
5.急待解决的问题——写明当前项目组中面临的最优先的问题，可以重复提出
另外一种测试报告的内容：
l 测试资源概述——多少人、多长时间
l 测试结果摘要——分别描述各个测试需求的测试结果，产品实现了哪些功能点，哪些还没有实现
l 缺陷分析——按照缺陷的属性分类进行分析
l 测试需求覆盖率——原先列举的测试需求的测试覆盖率，可能一部分测试需求因为资源和优先级的因素没有进行测试，那么在这里要进行说明
l 测试评估——从总体对项目质量进行评估
测试组建议——从测试组的角度为项目组提出工作建议