需求的定义和分类
需求的重要性
- 在软件测试过程中，从需求分析开始到集成测试阶段引入测试手段，能发现所有缺陷的80%，系统测试阶段引入测试手段，能发现剩余缺陷中80%的缺陷，在运行维护阶段经过长时间、大量运行软件后，能够发现最后剩余的20%缺陷
需求的定义
- 1.用户解决问题或达到目标所需条件或权能
- 2.系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能
- 3.一种反映上面1或2所诉条件或权能的文档说明
- 它包括功能需求及非功能需求，非功能性需求对设计和实现提出限制，比如性能需求、质量标准，或者设计限制
需求的分类
- 用户需求
- 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明
- 业务需求
- 反映了组织机构 或客户对系统、产品高层次的目标要求、它们在项目视图与范围文档中予以说明
- 功能需求
- 定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求
需求说明的规范
需求分析和跟踪矩阵
- 软件测试需求分析步骤：
- 根据软件开发需求说明书逐条列出软件开发需求，并判断其可测试性
- 形成可测试的描述并界定出测试范围
- 根据质量标准，逐条制定质量需求，即测试通过标准
- 分析测试执行时需要实施的测试类型
软件测试分类
按照开发阶段划分
- 单元测试
- 单元测试又称模块测试，是针对软件设计的最小单位–程序模块进行正确性检验的测试工作。其目的在于检测每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部机构出发设计用例。多个模块可以平行地独立进行单元测试。
- 集成测试
- 集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
- 确认测试
- 确认测试也叫有效性测试（冒烟测试）。是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备了进入系统测试阶段的资质
- 系统测试
- 系统测试是在真实的系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台）正确配置、连接，并满足用户的所有需求
- 验收测试
- 是软件产品验证的最后一个环节。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。
- α测试：软件开发公司内部人员模拟各类用户对即将面世的软件产品（称为α版本）进行测试，试图发现错误。由用户、测试人员、开发人员等共同参与的内部测试
- β测试：内测之后的公测，即完全交给最终用户测试。软件开发公司组织各方面的典型用户在日常生活中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善
- γ测试：第三方的软件测试
按照代码运行划分
- 静态测试
- 指不实际运行被测对象，而只是静态地检查程序代码、界面或文档中可能存在错误的过程
- 代码测试：主要测试代码是否符合相应的标准和规范
- 界面测试：主要测试软件的实际界面与需求中的说明是否符合
- 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际要求
- 动态测试
- 指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序
按照软件特性划分
- 功能划分：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求
- 逻辑功能测试
- 页面测试
- 易用性测试
- 安装\卸载测试
- 兼容性测试
- 性能测试
- 功能的另一个指标，主要关注软件中的某一功能在指定的时间、空间条件下，是否使用正常
- 软件的性能包括很多方面，主要有时间性能和空间性能两种
- 安全性测试
- 验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不被各种因素的干扰
按照测试技术划分
- 黑盒测试
- 通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现
- 白盒测试
- 通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成一个透明的盒子里，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试
- 灰盒测试
- 介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性。同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表现特征的现象、事件、标记来判断内部的运行状态
其他测试
- 回归测试
- 是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例
- 目的：
- 1.验证之前版本产生的所有缺陷已全部被修复
- 2.确认修复这些缺陷没有引发新的缺陷
- 冒烟测试
- 是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。也叫可测性测试
- 随机测试
- 是指测试人员基于经验和直觉的测试，发现一些边缘性的错误
- 猴子测试
- 把自己当成不懂产品的笨蛋或小动物，随便乱点，没有任何的主观意识和想法参与进来，让一些意想不到的操作造成错误的结果
软件测试的原则
- 所有测试的标准都是建立在用户需求之上
- 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量
- 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估
- 软件项目一启动，软件测试也就开始，而不是等程序写完，才开始进行测试
- 穷举测试是不可能的
- 软件测试计划是做好软件测试工作的前提
- 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性
- 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。
- 重视文档，妥善保存-切测试过程文档(测试计划、测试用例、测试报告等)
- 应当把“尽早和不断地测试”作为测试人员的座右铭
- 回归测试的关联性一定要引起充分的注意， 修改一一个错误而引起更多错误出现的现象并不少见
- 测试应从"小规模”开始，逐步转向“大规模”。
- 不可将测试用例置之度外，排除随意性。
- 必须彻底检查每个测试结果。
-定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
对测试错误结果一定要有一一个确认的过程。
什么是测试用例
- 简单地说，测试用例就是:
- 设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果
- 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内
- 软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题己修改完成。
周测
- 1.请写出缺陷定义
- 2.请从不同角度写出软件测试的定义（至少三个角度）
- 3.请写出软件生命周期中每一阶段的名称
- 4.请对软件开发模型中瀑布模型和迭代模型各自优缺点
- 5.请写出完整的软件测试流程包含的内容
- 6.软件测试应该遵行什么样的理念
- 7.你认为什么样的需求是好的需求？它对测试有什么样的影响
- 好的需求：四点原则
- 对测试的影响：
- 1.不好的需求的影响
- 2.80-20原则时，需求引发的缺陷是最多的（54%）
- 3.需求阶段的问题早点发现，可以降低开发成本
|