软件测试流程模型和测试分类

软件测试流程

获取测试需求，编写测试计划，指定测试方案，开发与设计测试用例，执行测试，提交缺陷报告，测试分析与评审，提交测试总结，准备下一版本测试

软件测试过程模型
软件测试和软件开发一样，都遵循软件工程、管理学原理。测试专家通过实践总结出了很多很好的测试模型。这些模型将测试活动进行了抽象，明确了测试与开发之间的关系，是测试管理的重要参考依据。有V、W、H、X四种模型

1. v模型
   揭示了开发过程与测试过程中各阶段的对应关系
   缺点与不足
   • V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证；
   • 需求的满足情况一直到后期的验收测试才被验证；
   • 没有体现出“尽早地和不断地进行软件测试”的
   原则。

软件测试的原则

1. 测试不能穷尽原则
   输入量太大
   输出结果多
   软件实现途径太多
   软件说明书没有客观标准
   

2. 测试尽早介入
   在软件或系统开发生命周期中，测
   试活动应该尽可能早的介入，并且
   应该将关注点放在已经定义的测试
   目标上

3. 80-20原则
   80%的缺陷，分布在20%的模块里面;
   一般情况下，在分析、设计、实现阶段的
   复审和测试工作能够发现和避免80%的
   Bug，而系统测试又能找出其余Bug中的
   80%，最后的5%的Bug可能只有在用户的
   大范围、长时间使用后才会曝露出来。因
   为测试只能够保证尽可能多地发现错误，
   无法保证能够发现所有的错误。
4. 缺陷集群性：如果你在一个软件模块发现了较多错误，那么这个模块可能隐藏着更多缺陷。

软件测试的分类

根据是否关心具体代码划分
白盒：只查看内部代码是否有缺陷是否按照规格说明书的需求实现。
黑盒：通过软件的外部表现来发现其缺陷和错误。完全不考虑内部程序的结构和处理过程。
灰盒测试：白加黑，介于两者之间的测试。
按照开发阶段划分
1.单元测试：单元测试又称模块测试，是针对软件设备的最小单位。主要测试单元内部的数据结构、逻辑控制、异常处理等，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试属于白盒测试

2.集成测试：也称组合测试，主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能。属于灰盒测试。

3.系统测试：主要测试整个系统相对于需求的符合度，在真实的系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、
外设、网络和系统软件、支持平台等）正确配置、连接，并最终满足用户的所有需求，属于黑盒测试的范畴

4.验收测试：由用户或者第三方根据测试用例测试软件的功能能否达到预期的结果。属于黑盒测试的范畴。

1、单元测试的评估基准主要是逻辑覆盖率。
2、集成测试的评估基准主要是接口覆盖率。
3、系统测试的评估基准主要是测试用例对需求规格的覆盖率。

根据代码进行分类
1.静态测试：
• 指不实际运行被测对象，而只是静态地检查程序代码、界面或文档中可能存在错误的过程。
• 代码测试：主要测试代码是否符合相应的标准和规范
• 界面测试：主要测试软件的实际界面与需求中的说明是否相符
• 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求

动态测试：
指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是运行程序

根据软件特性分类
功能测试：：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求
逻辑功能测试
界面测试
易用性测试
安装/卸载测试
兼容性测试
• 性能测试：
功能的另一个指标，主要关注软件中的某一功能在指定的时间、空间条件下，是否使用正常
软件的性能包括很多方面，主要有时间性能和空间性能两种
• 安全性测试：
验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。
可靠性测试和兼容性测试
其他测试方法

回归测试：
在完成某一个版本的测试之后，开发将缺陷修复提交了新的版本，需要将上个版本的测试用例再执行一遍的过程
回归测试的目的：
验证新的版本中是否已经修复了所有缺陷
验证新的版本在修复缺陷的时候是否引入了新的错误
回归测试的方式：
全量回归
部分回归
冒烟测试（确认测试）：
在进行大规模的系统级测试之前，先去验证系统的主要功能是否已经实现，是否具备了测试的条件（可测性）
冒烟测试该有谁来做？
一般是有开发来完成，测试通过之后再提交测试
一般是有测试人员来提供冒烟测试的测试用例
随机测试：
有经验的测试工程师，基于经验和直觉，发现一些边缘性的缺陷

猴子测试：
对软件和行业知识可能一概不知，随便地操作软件，并发现一些他认为是问题的bug
移动端的性能测试会讲到monkey测试

测试的常见原则

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

软件测试人员的发展