一、概述

（一）测试的定义
1.IEEE(电子和电气工程师协会，全称Institute of Electrical and Electronics Engineers)的定义
通过人工或者自动化手段来运行或检查某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差距
2.自己理解的定义
（1）软件测试是一个过程；
（2）软件测试可以人工方式也可借助工具；
（3）进行软件测试可以运行软件也可以不运行软件；
（4）软件测试就是证明程序有错，而不是证明程序无错；
（5）软件测试的目的不仅仅是为了发现错误；
（6）以最少的人力、物力、时间找到软件中的缺陷并修改，从而回避商业风险。
（二）测试的目的
1. 根本目的
提高软件的质量，给用户带来更好的体验
2.目的
（1）证明：证明软件在受控条件下可用；
（2）检验：检查产品中的缺陷，检验产品中的质量信息；
（3）预防：通过尽早的测试发现问题，修复问题，避免问题延续到后续阶段扩大化，通过测试发现问题，并找出问题的原因并加以改进，避免同类问题在次发生。
（三）软件中的缺陷（BUG）
1.软件中为什么会引入缺陷（bug）？
（1）开发过程中缺乏有效的沟通；
（2）软件复杂度越来越高；
（3）编程中产生的错误；
（4）需求不断变更；
（5）项目进度压力；
（6）不重视开发文档；
（7）开发工具本身存在问题。
2.软件缺陷类型
未按照软件需求规格说明书（SRS）而出现的以下几种缺陷：
（1）遗漏 （2）错误 （3）冗（rǒng）余 （4）提高/建议
（四）测试工程师的主要工作

1. 测试计划、测试方案、需求评审、设计评审
2. 编写测试用例、用例评审
3. 执行测试
4. 测试日报
5. 测试报告

（五）软件测试流程
1.需求分析
2.测试需求
3.测试计划
4.测试方案
5.测试用例
6.执行测试
7.测试报告

二、软件的生命周期

一个软件的生命周期包括制定计划、需求分析定义、软件设计、程序编码、软件测试、软件运行、软件维护、软件停用、8个阶段
（一）制定计划阶段
1. 计划阶段的工作内容
（1）确定软件开发总目标；
（2）给出软件的功能、性能、可靠性以及接口等方面的设想；
（3）研究完成该项目的可行性，探讨问题解决方案（三峡工程）；
（4）对可供开发使用的资源、成本、可取得的效益和开发进度做出评估（还包括风险）；
（5）指定完成开发任务的实施计划。
2. 举例（以研发计算器为例）
（1）研发一个计算器；
（2）支持加、减、乘、除，所有运算都在一定时间之内完成；
（3）该项目目前不存在任何技术问题；
（4）需要在三个月之内完成所有开发项目和测试工作，并推向市场；
（5）具体计划参见一般项目一级计划。
（二）软件需求分析阶段
1. 需求分析阶段的工作内容
对开发的软件进行详细的定义，由需求分析人员和用户共同讨论决定哪些需求是可以满足的，并且给予确切的描述，写出软件说明书（SRS）。
软件研发的类型（产品/项目）不同，需求的来源也不同、用户也不同。
2. 举例（以分析计算器为例）
（1）功能需求：十进制加、减、乘、除；八进制；二进制；十六进制。
（2）性能需求：十进制加法需在1s内完成；十六进制乘法需在3s内完成。
（三）软件设计阶段
设计是软件工程的技术核心，这个阶段需要完成设计说明书。
1. 分类
概要设计（HLD）：英文缩写High Level Design (顶层设计) 在设计阶段把各项需求转换成相应的体系结构，每一部分是功能明确的模块。
详细设计（LLD）：英文缩写Low Level Design (底层设计) 对每个模块要完成的工作进行具体的描述。
2. 举例（以设计计算器为例）
（1）概要设计
整个软件分成六个模块：界面模块、主控模块、加法模块、减法模块、乘法模块、除法模块等（主控模块调用后四个模块）。
加法模块包含五个主函数：加法主函数、十进制主函数、二进制主函数、八进制加法主函数、十六进制加法主函数（加法主函数调用后面四个主函数）。
（2）详细设计
加法主函数的主流程图或者伪代码。

三、软件测试的原则

（一）应尽早地和不断地进行软件测试；
（二）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；
（三）程序员应当避免检查自己的程序；
（四）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件；
（五）充分注意测试中的群集现象（二八理论：80%的错误出现在20%的模块中）；
（六）严格执行测试计划，排除测试的随意性；
（七）应当对每一个测试结果做全面检查；
（八）妥善保存测试计划、测试用例、出错和最终分析报告，为维护提供方便。
（九） 杀虫剂现象：同样的一个测试用例不能执行多次，因为软件会对它产生免疫

四、软件测试的分类

（一）按照开发阶段（过程）划分
单元测试（详细设计说明书）、集成测试（概要设计明说书）、系统测试（需求规格说明书）、验收测试、产线验证。
1. 单元测试的概念
是对软件的基本组成单位进行的测试，测试对象是一个方法（函数）或者是一个类，目的是检测软件模块对详细设计说明书的符合程度。
2. 集成测试的概念
是在单元测试的基础上，将所有模块按照概要设计要求组装称子系统或者系统，验证组装后的功能以及模块间的接口是否正确的测试，目的是检测软件模块对概要设计说明书的符合程度。
3. 系统测试的概念
将已经集成好的软件系统，做为计算机系统的一个元素，连同硬件、外部设施、人员等做为一个整体进行的测试，目的是检验软件系统对软件需求规格说明书的符合程度。
4. 单元测试、集成测试与系统测试之间的比较
（1）测试方法不同：单元测试属于白盒测试的范畴；集成测试属于灰盒测试的范畴；系统测试属于黑盒测试的范畴。
（2）考查范围不同：单元测试主要测试单元内部的数据结构、逻辑控制、异常处理；集成测试主要测试模块之间的接口和接口之间的数据传递关系，以及模块组合后的整体功能；系统测试主要测试整个系统相对于需求的符合度。
（3）评估基准不同：单元测基准主要是逻辑覆盖率；集成测试基准主要是接口覆盖率；系统测试基准主要是测试用例对于需求规格的覆盖率。（覆盖的意思可理解为执行）

（二）按照测试技术（方法）划分
1. 黑盒测试
把软件看成一个黑色的盒子，不了解程序的内部结构，也叫基于功能（规格）的测试。
以用户的观点，从输入数据与输出数据的对应关系，即根据程序外部特性进行测试，而不考虑内部结构及工作情况。
2. 白盒测试
把软件看成一个透明的盒子，了解程序的内部结构，只根据程序的内部结构进行测试，也叫基于结构（逻辑驱动）的测试。
3. 灰盒测试
介于黑盒和白盒之间的测试，可理解为接口测试。
灰度测试：一般指先在一个范围或有权限的特定用户进行的测试。

五、软件测试停止的标准

（一）第一类标准：测试超过了预定时间，则停止测试。
（二）第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。
（三）第三类标准：使用特定的测试方案作为判断测试停止的基础。
（四）第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订数目的故障。
（五）第五类标准：根据单位时间内查出故障的数量决定是否停止测试。

六、软件测试的过程

**书面上的流程：**测试计划—测试设计—测试执行—测试总结
我公司的流程：
① 需求评审。发起人：产品（产品经理）；参与人：开发、测试、UI设计人员（视觉人员）；目的：了解需求、讨论
② 编写用例
③ 用例评审。发起人：测试人员；参与人：产品、开发、UI；目的：讨论、查漏补缺
④ 提测。通俗的说是告诉测试人员，软件开发完以后可以进行测试。
⑤ 测试执行。参照测试用例进行执行
⑥ 冒烟测试
⑦ 系统测试
⑧ 回归测试
⑨ 产线验证
⑩ 测试报告。发送形式：邮件里面说明或word文档
（一）测试计划
**输入：**软件测试任务书（或合同）和被测软件的需求规格说明（SRS），是开展软件测试计划的基础和依据。（任务书是指实现什么功能、在什么时间完成）
**输出：**软件测试计划
1.软件测试计划的制定
需求分析、测试策略、工作量估算、进度安排、度量标准、风险评估、子计划制定、计划评审
2.软件测试计划的内容要素
软件测试的范围、软件测试的策略、软件测试的需求、软件测试的资源要求、软件测试的人员要求、软件测试的进度
（二）测试设计
编写测试用例
输入：软件测试计划；输出：测试用例和测试数据
1. 测试用例的定义
通常讲是对一项测试任务的描述，包含输入数据，操作步骤，预期结果等。
2. 测试用例八大基本要素
测试编号，测试项目，测试标题，重要级别，前置条件，输入数据，操作步骤，预期结果。
3. 用例管理工具
禅道、TestLink、QC、自定义（公司自己开发的），一般我们用Excel写用例
4. 使用测试用例的好处
（1）可以避免盲目测试并提高测试效率；
（2）令软件测试的实施重点突出、目的明确；
（3）在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期；
（4）试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。
5. 设计测试用例的基本准则
（1）测试用例的代表性
能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
（2）测试结果的可判定性
测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
（3）测试结果的可再现性
对同样的测试用例，系统的执行结果应当是相同的。
6. 测试用例设计方法（黑盒测试方法）
**常用：**等价类划分、边界值分析、流程分析法（场景分析法）
**其他：**错误推测法、因果图、判定表、正交试验法
（1）★等价类划分法
① 概念
等价类划分法是把所有可能的输入数据，即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。
② 进行等价类划分的依据
I. 按照区间划分。 在输入条件规定了取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类。
II. 按照数值划分。 在规定了一组输入数据（假设包括 n个输入值），并且程序要对每一个输入值分别进行处理的情况下，可确定 n 个有效等价类（每个值确定一个有效等价类）和一个无效等价类（所有不允许的输入值的集合）。
III. 按照数值集合划分。 在输入条件规定了输入值的集合或规定了“必须如何”的条件下，可以确定一个有效等价类和一个无效等价类（该集合有效值之外）。
IV. 按照限制条件或规则划分。 在规定了输入数据必须遵守的规则或限制条件的情况下，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
V. 细分等价类。 在确知已划分的等价类中各元素在程序中的处理方式不同的情况下，则应再将该等价类进一步划分为更小的等价类，并建立等价类表。
（2）★边界值分析法
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
（3）决策表（判定表）
决策表是分析和表达多逻辑条件下执行不同操作的情况的工具
组成：条件桩、条件项、动作桩、动作项
有n个条件的决策表有2n个规则（每个条件取真、假值）
（4）正交试验设计法
从大量的试验点中挑选出适量的、有代表性的点，应用依据迦罗卡瓦理论导出的“正交表”，合理的安排试验的一种科学的试验设计方法
（5）★流程分析法（场景分析法）
通过描述流经用例路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流 ：直黑线表示基本流，是最基本、最简单的路径；（软件功能按照正确的事件流实现的一条正确流程无任何错，程序从开始直到结束）
（6）错误推测法
① 概念：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
② 基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
（三）测试执行
输入：测试用例和测试数据；输出：软件测试记录
（四）测试总结（测试报告）
输入：软件测试计划、测试用例、软件测试记录；输出：测试报告
测试报告的内容：
1. 首页
报告名称（软件名称+版本号+XX测试报告）、报告委托方、报告责任方、报告日期、版本变化历史、密级
2. 引言
（1）编写目的
实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。
（2）项目背景
对项目目标和目的进行简要说明，必要时包括简史。这部分基本不需要脑力劳动，直接从需求或者招标文件中拷贝即可。
（3）系统简介
如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。
（4）术语和缩略语
列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。
（5）参考资料
需求、设计、测试用例、手册以及其他项目文档；测试使用的国家标准、行业指标、公司规范和质量手册等等。
3. 测试概要
（1）测试的概要介绍
包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。
（2）用例设计方法
例如：等价类划分、边界值、因果图
（3）测试环境与配置
（4）测试方法与工具
主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。
4. 测试结果与缺陷分析
（1）测试执行情况与记录
描述测试资源消耗情况，记录实际数据。
（2）测试组织
可列出简单的测试组架构图，包括：测试组架构（如存在分组、用户参与等情况）、测试经理（领导人员）、主要测试人员、参与测试人员。
（3）测试时间
列出测试的跨度和工作量，最好区分测试文档和活动的时间。数据可供过程度量使用。
例如 XXX子系统/子功能：实际开始时间－实际结束时间；总工时/总工作日；任务 开始时间 结束时间 总计。
（4）测试版本
给出测试的版本，如果是最终报告，可能要报告测试次数回归测试多少次。列出表格清单则便于知道那个子系统/子模块的测试频度，对于多次回归的子系统/子模块将引起开发者关注。
（5）覆盖分析
① 需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。
② 测试覆盖：需求/功能（或编号） 用例个数 执行总数 未执行 未/漏测分析和原因。
（6）缺陷分析
本部分对上述缺陷和其他收集数据进行综合分析
缺陷综合分析
缺陷发现效率 ＝ 缺陷总数/执行测试用时
可到具体人员得出平均指标
用例质量 ＝ 缺陷总数/测试用例总数 ×100％
缺陷密度 ＝ 缺陷总数/功能点总数
缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷最多，从而在今后开发注意避免并注意在实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。
测试曲线图
描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向
（7）残留缺陷和未解决的问题
① 残留缺陷
编号：BUG号
缺陷概要：该缺陷描述的事实
原因分析：如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因
预防和改进措施：弥补手段和长期策略
② 未解决问题
功能/测试类型：
测试结果：与预期结果的偏差
评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响
5. 测试结论与建议
（1）测试结论
① 测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
② 对测试风险的控制措施和成效
③ 测试目标是否完成
④ 测试是否通过
⑤ 是否可以进入下一阶段项目目标
（2）建议
① 对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响
② 可能存在的潜在缺陷和后续工作
③ 对缺陷修改和产品设计的建议
④ 对过程改进方面的建议
6. 附录
缺陷列表、缺陷等级定义标准、测试通过标准等

七、软件质量模型

（一）功能性

1. 适合性：提供了相应的功能
2. 准确性：正确（用户需要的）
3. 互操作性：产品与产品之间交互数据的能力
4. 保密安全性：允许经过授权的用户和系统能够正常的访问相应的数据和信息，禁止未授权的用户访问…
5. 功能性的依从性：国际/国家/行业/企业 标准规范一致性
   （二）可靠性
   产品在规定的条件下，在规定的时间内完成规定功能的能力
6. 成熟性：防止内部错误导致软件失效的能力
7. 容错性：软件出现故障，自我处理能力
8. 易恢复性：失效情况下的恢复能力
9. 可靠性的依从性
   （三）易用性
   在指定使用条件下，产品被理解、 学习、使用和吸引用户的能力
10. 易理解性
11. 易学性
12. 易操作性
13. 吸引性
14. 易用性的依从性
    （四）效率性
    在规定台条件下，相对于所用资源的数量，软件产品可提供适当性能的能力
15. 时间特性：平均事务响应时间，吞吐率，TPS（每秒事务数）
16. 资源利用性：CPU 内存 磁盘 IO 网络带宽 队列 共享内存
17. 效率依从性
    （五）软件维护性
    “四规”：在规定条件下，规定的时间内，使用规定的工具或方法修复规定功能的能力。
18. 易分析性：分析定位问题的难易程度
19. 易改变性：软件产品使指定的修改可以被实现的能力
20. 稳定性：防止意外修改导致程序失效
21. 易测试性：使已修改软件能被确认的能力
22. 维护性的依从性
    （六）软件可移植性
    从一种环境迁移到另一种环境的能力
23. 适应性：适应不同平台
24. 易安装性：被安装的能力
25. 共存性
26. 易替换性
27. 可移植性的依从性

八、CMM能力成熟度模型

有以下五个等级：
（一）初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
（二）可重复级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。
包括：需求管理、软件项目策划、软件项目跟踪与监控、软件子合同管理、软件质量保证、软件配置管理
（三）已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。
包括：组织过程定义、组织过程焦点、培训大纲、集成软件管理、软件产品工程、组间协调、同行评审
（四）定量管理级
收集对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。
包括：定量过程管理、软件质量管理
（五）优化级
过程的量化反馈和先进的新思想、新技术促使过程不断改进。
包括：缺陷预防、技术变更管理、过程变更管理

每个等级都被分解为三个层次加以定义，这三个层次是关键过程区域、共同特征和关键实践。每个等级都有几个关键过程区域组成，这几个关键过程域共同形成一种软件过程能力。每个关键过程域，都有一些特定的目标，通过相应的关键实践来实现这些目标。每个关键过程域按五个共同特征加以组织。当一个关键过程域的所有关键实践都按要求得到实施，就能实现该关键过程域的目标

九、缺陷管理

（一）软件缺陷严重性和优先级

1. 严重级
   （1）严重：系统崩溃、数据丢失、数据损坏
   （2）较严重：操作性错误、错误结果、遗漏功能
   （3）一般：小问题、错别字、UI布局、罕见故障
   （4）建议：不影响使用的瑕疵或更好的实现
2. 优先级
   （1）最高优先级：立即修复，停止进一步测试
   （2）次高优先级：在产品发布之前必须修复
   （3）中等优先级：如果时间允许应该修复
   （4）最低等优先级：可能会修复，不修复也能发布

一般严重性和优先级的划分用数字1～4表示，有的小数字表示的级别最高，而有的用大数字表示级别高。另外严重级和优先级的划分并不唯一，可适当修改。
3. 缺陷等级划分

（二）缺陷跟踪管理
为了正确跟踪每个软件缺陷的处理过程，通常将软件测试发现的每个错误作为一条条记录输入指定的错误跟踪管理系统。
bug管理工具：RTC、jira、禅道、QC、Bugzilla等。
作为一个缺陷跟踪管理系统，需要正确的记录错误信息和错误处理信息的全部内容。
1. Bug记录信息
测试软件名称、测试版本号、测试人名称、测试用例、标题、测试软件和硬件配置环境、发现软件错误的类型、错误严重等级、详细步骤、必要的附图、发生错误的模块…
2. Bug处理信息
处理者姓名、处理时间、处理步骤、缺陷记录的当前状态
（三）软件缺陷状态
新建（New）： 测试中新报告的软件缺陷；
打开（Open)： 被确认并分配给相关开发人员处理；
修正（Fixed）： 开发人员已完成修正，等待测试人员验证；
拒绝（Declined）： 拒绝修改缺陷；
延期（Deferred)： 不在当前版本修复的错误，下一版修复
关闭（Closed）： 错误已被修复。
（四）缺陷管理流程（缺陷生命周期）

1. 测试人员提交新发现的缺陷入库，缺陷状态为“New”
2. 高级测试人员验证错误
   如果确认是错误，则分配给相应的开发人员，设置状态为“Open”
   如果不是错误，则拒绝，设置为“Declined”状态
3. 开发人员查询状态为“Open”的缺陷，对其进行处理
   如果不是错误，则状态置为“Declined”
   如果是错误，则修复并置状态为“Fix”
   如果不能解决，要留下文字说明并保持缺陷状态仍为“Open”
   对于不能解决或者延期解决的缺陷，不能由开发人员自己决定，一般要通过某种会议（评审会）才能认可
4. 测试人员查询状态为“Fix”的缺陷，验证缺陷是否已解决，做如下处理
   如果问题解决了，置缺陷的状态为“Closed”
   如果问题没有结果，则置状态为“Reopen”
   （五）缺陷数据分析
5. 缺陷数据分析的重要性
   （1）统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。
   （2）分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。
   （3）根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。
   （4）根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。
6. 缺陷数据分析的数据指标
   （1）每天/周报告的新缺陷数目；
   （2）每天/周修复的缺陷数；
   （3）累计报告的缺陷数目；
   （4）累计修复的缺陷数；
   （5）不同严重性类型的缺陷数；
   （6）程序模块与发现的缺陷的对应关系；

好好学习天天向上加油少年，好好记着努力的人会被上天眷顾