测试流程

测试基本流程

• 获取测试需求
• 编写《测试计划》
• 制定测试方案
• 设计测试用例
• 执行测试此处测试才会与开发交汇
• 提交《缺陷报告》
• 测试分析与评审
• 提交《测试总结》
• 准备下次测试

测试独立性（高 –> 低）

• 专门的测试外包公司测试岗位
• 企业内部独立于研发部门的测试岗位
• 研发团队内部的测试岗位
• 开发人员自己测试

---

测试模型

软件测试模型与软件开发模型一样，都是测试和开发工作的指导

1. V模型

优点：

• 揭示了开发过程与测试过程中各阶段的对应关系。

缺点：

• 仅将测试过程视为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证；
• 需求的满足情况一直到后期的验收测试才被验证；
• 没有体现出“尽早地和不断地进行软件测试”的原则。

2. W模型

优点：

• 测试的活动与软件开发同步进行；
• 测试对象不公仅仅是程序，包括需求和设计；
• 尽早发现软件缺陷可降低软件开发的成本。

缺点：

• 需求、设计、编码等活动被视为串行的，这样就无法支持灵活的迭代。

3. H模型

优点：

• 测试是一个独立的过程，只要满足条件就可以开始测试；
• 测试对象是整个产品包，而不仅是程序、需求和相关说明书；
• 可以与所有的开发活动紧密结合，又足够灵活满足敏捷和迭代的开发模型。

缺点：

• 如果管理者没有足够经验实施H模型，可能会事倍功半，提高成本。

4. X模型

优点：

• 有测试步骤，包括测试设计、工具配置、执行测试；
• 提倡探索性测试，帮助有经验的测试工程师发现测试计划之外更多的软件错误；
• 它呈现了测试是一个不断迭代的过程，更符合企业实际情况。

缺点：

• 测试设计、工具配置、执行测试三个测试步骤并不很完善；
• 在V模型基础上改进，导致缺点与V模型类似。

---

测试理念

• 尽早测试：测试人员早期参与软件项目；尽早的开展测试执行工作。
• 全面测试：对软件的所有产品进行全面的测试；软件开发及测试人员（有时包括用户）全面的参与到测试工作中。
• 全过程测试：测试人员要充分关注开发过程；测试人员要对测试的全过程进行全程的跟踪。
• 独立的、迭代的测试：测试活动是独立的；测试活动应该循环往复、不断的进行。

---

软件测试分类

1. 按照开发阶段：

• 单元测试：又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序内部结构出发设计测试用例。多个模块可以平等地独立进行单元测试；由于测试人员大多不懂代码，所以单元测试一般由开发人员自己进行。
• 集成测试：也叫组装测试，通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统；集成测试涉及的接口测试较多，是一个持续不断的过程。
• 确认测试：也叫有效性测、冒烟测试，是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备了进入系统测试阶段的资质；一般都是正向的测试，主要看系统有没有这个功能，一般不作为正式的测试环节。
• 系统测试：在真实的系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并最终满足用户的所有需求；系统所有功能的测试，模拟所有的软件用户的操作，软件和硬件、系统软件、其他软件的联系。
• 验收测试：是软件产品检验的最后一个环节，按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统；一般是供求双方之间的测试，有三种验收测试的主体：α测试：开发商自己的测试；β测试：软件需求方的测试；γ测试：第三方的测试。

2. 按照测试技术：
   • 黑盒测试：通过软件的外部表现来发现其缺陷和错误，墨盒测试把测试对象看成一个黑盒子，完全不考虑内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。
   • 白盒测试：通过对程序内部结构的分析、检测来寻找问题，白盒测试可以把程序看成装在一个透明的盒子里，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明书的规定正常进行。白盒测试又称结构测试。
   • 灰盒测试：介于白盒测试和黑盒测试之间的测试，灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。
3. 按照代码运行：
   • 静态测试：指不实际运行被测对象，而只是静态地检查程序代码、界面或文档中可能存在错误的过程：
     • 代码测试：主要测试代码是否符合相应的标准和规范；
     • 界面测试：主要测试软件的实际界面现需求中的说明是否相符；
     • 文档测试：主要测试用户手册和需求说明书是否真正符合用户的实际需求。
   • 动态测试：指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。
4. 按照软件特性：
   • 功能测试：包含逻辑功能测试、界面测试、易用性测试、安装/卸载测试、兼容性测试。
   • 性能测试：功能的另一个指标，主要关注软件中的某一功能在指定的时间、空间条件下，是否使用正常；软件的性能主要有时间性能和空间性能两种。
   • 安全性测试：验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。
5. 其他测试类型：
   • 回归测试：对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例，目的是验证之前版本产生的所有缺陷已全部被修复和确认重复这些缺陷没有引发新的缺陷。
   • 冒烟测试：在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，所以也叫可测性测试。
   • 随机测试：测试人员基于经验和直觉的测试，发现一些边缘性的错误。
   • 猴子测试：把自己当成不懂产品的笨蛋或者小动物，随便乱点，没有任何的主观意识和想法参与进来，让一些意想不到的操作造成错误的结果。
   • 手工测试：测试人员使用“点点点”的方式执行测试用例。
   • 自动化测试：使用某些工具或软件来让计算机代替测试人员执行测试用例。

	单元测试	集成测试	确认测试	系统测试	验收测试
测试技术	黑/白盒测试	黑/白/灰盒测试	黑/白盒测试	黑/白盒测试	黑/白盒测试
代码运行	动/静态测试	动/静态测试	动/静态测试	动/静态测试	动/静态测试
软件特性	功能/性能/安全测试	功能/性能/安全测试	功能/性能/安全测试	功能/性能/安全测试	功能/性能/安全测试
其他测试	–	–	冒烟测试	回归测试	随机/猴子测试
测试手段	手工/自动化测试	–	–	–	–

---

测试原则

• 所有测试的标准都是建立在用户需求之上；
• 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量；
• 事先定义好的产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估；
• 软件项目一启动，软件测试也随之开始，而不是等程序写完才开始进行测试；
• 穷举测试是不可能的；
• 第三方进行的测试会更有效；
• 软件测试计划是做好软件测试工作的前提；
• 测试用例是设计出来的，不是写出来的，所以要根据测试目的，采用相应的方法设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。
• 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大；
• 重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）；
• 应该把“尽早和不断测试”作为测试人员的座右铭；
• 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见；
• 测试应从“小规模”开始，逐步转向“大规模”；
• 不可将测试用例置之度外，排除随意性；
• 必须彻底检查每一个测试结果；
• 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系；
• 对测试错误结果一定要有一个确认的过程。