一、软件缺陷的定义
1. 软件为实现产品说明书要求的功能
2. 软件出现了产品说，明书指明不应该出现的功能
3. 软件实现了产品说明书未提到的功能
4. 软件未实现产品说明书虽未明确提及但应该实现的目标
5. 用户不易理解、不易使用、运行缓慢或者（从测试角度看）最终用户会认为不好
二、软件测试的定义和目的
1. 正向思维的定义
出发点：使自己确信产品还能够正常工作的评价一个程序和系统的特性或能力，
并确定他是否能达到期望的结果，软件测试就是以此为目的的任何行为。
2. 逆向思维的定义
出发点：
- 测试是为了发现错误而执行一个程序或系统的过程
- 测试是为了证明程序有错，而不是证明程序无错误
- 一个好的测试用例在于他能发现以前未发现的错误
- 一个成功的测试用例市发现了以前未发现的错误测试
3. IEEE定义的软件测试
- 在规定条件下运行系统或构件的过程：观察和记录结果，并对系统或构件的某方面给出评价
- 分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估项目的特性
4. 广义的软件测试
- 软件测试是对软件形成过程中的所有工作产品（包括程序以及相关文档）进行测试，而不是仅仅对程序的运行进行测试
- 确认 通过检查和提供客观证据来证实特定目的的功能或应用i是否已经实现
- 验证 通过检查和提供客观证据来证实指定的需求是否满足
5. 软件测试的目的
- 以最少的人力、物力的时间找出软件中潜在的各种错误和缺陷，保证各种错误额缺陷得以修复，避免软件发布后由于潜在软件错误和缺陷造成的隐患所带来的商业风险。
- 同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目和测试开发中重复同样的错误；
- 采用更加高效的测试管理手段，提高软件的效率和软件产品的质量。
6. 测试和调试的区别
- 在主体、目标、方法和思路上都有所不同
- 测试是从已知条件开始，使用预先定义的过程，并且有预知的结果；调试是从未知的条件开始，结果的过程可能不可预计
- 测试可以计划，可以预先制定测试用例和过程，工作精度可以度量；描述调试的过程或持续时间相对比较困难
- 测试的对象包括软件开发过程中的文档、数据以及代码，而调试的对象一般来说只是代码
7. 软件测试的对象
源程序、目标程序、数据及相关文档
三、软件生命周期模型
瀑布模型（要求会画图）
存在问题
- 强调时间顺序的严格执行。前阶段不完成，后阶段不开始
- 将i测试放在编码之后。没有体现出测试贯穿软件生命周期的原则。可以避免需求的问题一直延续到代码完成才暴露或者被发现
优点
- 为项目提供了按阶段划分的检查点
- 当前一阶段完成后，只需要关注后续阶段即可
缺点
- 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
- 线性开发，用户等到整个过程的末期才能见到开发的成果，从而增加了开发的风险。
- 瀑布模型不适用于用户需求的变化。
原型模型
- 原型模型弥补了瀑布模型的不足，更关注用户需求的正确性，也符合人们软件结构开发习惯。
- 原型模型需要迅速建造一个可运行的软件原型
- 工作中很多公司把i原型模型称为DEMO，即演示版。
- 经典应用工具：Axure，制作原型
增量模型
- 把软件分割成独立的模块，分批次的完成和交付。
- 缺点：打破原有的软件框架和结构，可能会带来一定风险。
- 增量模型一般回合迭代模型一起使用
迭代模型
- 迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必须的所有其他元素，强调开发的深入
- 在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。
- 迭代过程具有以下优点：
- 降低了在一个增量上的开支风险
- 降低了产品无法按照既定进度进入市场的风险
- 加快了整个开发工作的进度
- 迭代u过程这种模式使适应需求的变化会变得更容易
螺旋模型
- 螺旋模型是一种演化软件开发过程模型，他兼顾了快速迭代的特征以及瀑布模型的系统化于严格监控
- 引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。
- 螺旋模型适合大型昂贵的系统级软件应用
敏捷模型
敏捷模型的原则：快速迭代、让测试人员和开发着参与需求讨论、编写可测试的需求文档、多沟通，尽量减少文档、做好产品原型、及早考虑测试
个体和互动 高于 流程和工具
工作和软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
四、软件测试流程
软件测试过程模型
1. V 模型：揭示了开发过程于测试过程中各阶段的对应关系
- 缺点与不足：
- V 模型不仅仅把测试过程作为在需求分析、系统设计以及编码最后的一个阶段，忽视了测试对需求分析、系统设计的验证；
- 需求的满足情况一直到后期的验收测试才被验证；
- 没有体现出“尽早地和不断地进行软件测试”的原则
2. W 模型
- 由两个V字型模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系
- 优点：
- 测试的活动与软件开发同步进行
- 测试对象不仅仅是程序，包括需求的设计
- 尽早发现软件缺陷可降低软件开发成本
- 局限性
- 在 W 模型中，需求、设计、编码等活动被视为串行的，这样就无法支持灵活的迭代
H模型
- H模型将测试活动完全独立起来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来
- H模型揭示了一个原理：软件测试是一个独立的流程
- H模型指出软件测试要尽早准备，尽早执行；只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动可按照某个次序i先后进行，也可以反复进行。
X模型
- X模型也是对V模型的改进，X模型u提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。
- X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误
软件测试过程理念
- 尽早测试
- 测试人员早期参与软件测试
- 尽早的开展测试执行工作
- 全面测试
- 对软件的所有产品进行全面的测试
- 软件开发及测试人员（有时包括用户）全面的参与
- 全过程测试
- 测试 人员要充分关注开发过程
- 测试人员要对测试的全过程进行全程的跟踪
- 独立的、迭代的测试
- 测试活动是独立的
- 测试活动应该i是循环往复、不断的进行
软件测试分类
1.按照开发阶段分类
按照开发阶段划分
单元测试：单元测试又称模块测试，是针对软件设计的最小单位–程序模块进行h正确性检验的测试工作。其目的在于检查每个程序单元是否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试
集成测试：集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
按照开发阶段：
- 确认测试：确认测试也叫有效性测试。是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备了进入系统测试的资格。（一般不作为正式的测试环节）
- 系统测试：系统测试是在真实的系统运行的环境下，检查完的程序系统是否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并最终满足用户的所有需求
- 验收测试：是软件产品检验的最后一个环节。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。
按照测试技术划分：
黑盒测试：通过软件的外部表现来发现其缺陷和错误。黑盒测试法吧测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行的测试，他只是检查程序是否按照需求规格说明书的规定正常实现。
白盒测试：通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透名的盒子里，检查是否所有的结构及路径是否都正确，检查软件内部动作是否按照设计说明的规定正常进行。
灰盒测试：介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、时间、标志来判断内部的运行状态。
按照代码运行划分：
静态测试：
- 指不实际运行被测对象，而只是静态地检查程序代码、界面或文档中可能存在错误的过程
- 代码测试：主要测试代码是否符合相应的标准和规范
- 界面测试：主要测试软件的实际界面与需求中的说明是否相符
- 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求
动态测试：指实际运行被测对象，输入相印的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。
按照软件特性划分
功能测试：黑盒测试的一方面
- 逻辑功能测试
- 界面测试
- 易用性测试
- 安装/卸载测试
- 兼容性测试
性能测试
- 功能的另一个指标，主要关注软件中的某一功能在指定的时间、空间条件下，是否能满足使用正常
- 软件的性能包括很多方面，主要有时间性能和空间性能
安全测试
- 验证安装在系统内的保护机制是否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。
其他测试
- 回归测试
- 是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例
- 目的：
- 验证之前版本产生的所有缺陷已全部被修复;
- 确认修复这些缺陷没有引发新的缺陷
- 冒烟测试：是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。也叫可测性测试。
- 随机测试：是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。
- 猴子测试：把自己当成不懂产品的小白，随便乱点，没有任何主观意识和想法参与进来，让一些意想不到的操作造成错误的结果。
- 回归测试
软件测试的原则
- 所有测试的标准都是建立在用户需求之上的
- 软件测试必须基于“质量第一”的思想去展开各项工作，当时间和质量冲突时，时间要服从质量
- 事先定义好产品的质量标准，只有有了质量标准，才能根据测试结果，对产品的质量进行分析和评估
- 软件项目一启动，软件测试也就开始，而不是等程序写完，才开始测试
- 穷举测试是不可能的
- 第三方进行测试会更客观，更有效
- 软件测试计划是做好软件测试工作的前提
- 测试用例是设计出来的，不是写出来的，所以要根据测试目的，采用相应的方法去设计测试用例，从而提高测试效率，更多地发现错误，提高程序的可靠性。
- 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序已发现的错误数较多，其中的错误概率也就越大。
- 重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）
- 应当把“尽早和不断地测试”作为测试人员的座右铭
- 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见
- 测试应从“小规模”开始，逐步转向“大规模”
- 不可将测试用例置之度外，排除随意性
- 必须彻底检查每一个测试结果
- 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大关系
- 对测试错误结果一定有一个确认的过程
五、什么是测试用例
- 标识符（用例编号）：一般编号规则：TestCase_项目名称_项目模块_功能名称_0001
- 测试项。测试用例的测试目的。一般情况下，用一句话表明目的。例如：使用谷歌浏览器打开百度首页; 在QQ登陆界面输入正确的用户名密码能登陆上。（表明你的测试模块、测试对象、方式、事件）
- 依赖用例：一般功能流程上，下游的功能测试依赖与上游的功能测试用例
- 测试步骤：用最朴实的语言，写出来软件的操作步骤。要尽量详细。例如：在用户名文本框输入：xxx; 在省份下拉列表选择：北京 城市下拉列表选择：北京
- 测试数据：单独整合测试数据。必须和测试步骤中的数据保持一致
- 预期结果：要准确、对象准确、内容的准确，内容的准确性。原则上每一个操作，都要有一个结果。在重要步骤之后，设定预期结果。例如：页面跳转到xxx；程序弹出对话框，提示：用户名或密码错误，请重新输入！一般和测试目的密切相关。测试目的决定了测试步骤和预期结果。
- 测试结果：要求在测试执行完成后添加。没有执行保持为空。测试结果只有两个：通过/失败；Pass/Failed；和预期结果一直即为通过，不一致即为失败。
- 测试人：测试的执行人。可以和设计者相同，也可以不同
- 备注：为了测试用例正常执行而做的特殊准备。例如：专门制造网络不畅情况下，软件错误提示
- 用例设计和编写的作用
- 有效性：测试用例是测试人员测试过程中的重要参考依据
- 可复读性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率
- 易组织性：即使是小的项目，也可能有几千甚至更多的测试用例，测试用例可能在数月甚至技能的测试过程中被创建和使用
- 可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证
- 可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准
- 测试用例编写注意事项
- 不要设计”穷举测试用例“
- 在详细测试用例与有效测试时间中找到平衡点
- 好的测试用例应该多关注”反向测试问题“
- 测试用例库应该不断更新和维护
- 测试用例可以复用，但要注意数据有效性与环境变化
- 测试用例是设计出来的，不是写出来的
- 多去学习经验丰富的测试工程师所设计的测试用例
- 针对不同需求类型和测试对象，灵活采用不同测试用例设计方法
六、缺陷基本概述
软件缺陷的属性
1. 缺陷类型
功能缺陷（Function）
界面缺陷（UI）
文档缺陷（Documentation）
软件包（Package）
性能缺陷（Performance）
接口缺陷（Interface）
注意： 需求分析、设计阶段，文档类型的缺陷多；集成测试阶段，一般接口类型的缺陷多一些；系统测试阶段，功能、界面类型的缺陷多一些；验收测试阶段，更多的关注性能缺陷；实施过程，可能会遇到一些软件包的缺陷
2. 缺陷严重程度
致命（Fatal）：任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机，或者威胁人身安全
严重（Critical）：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响。
一般（Major）：系统的次要功能没有完全实现，但不影响用户正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题。
较小（Minor）：是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题
注意：结合缺陷的影响，结合软件的具体功能（业务或者流程）
3. 缺陷的修复优先级
修复优先级很大程度取决于测试工作的影响程度
| 缺陷优先级 | 描述 |
|---|---|
| 立即解决（P1级） | 缺陷导致系统几乎不能使用或测试不能继续，需立即修复 |
| 高优先级（P2级） | 缺陷严重，影响测试，需要优先考虑 |
| 正常排队（P3级） | 缺陷需要正常排队等待修复 |
| 低优先级（P4级） | 缺陷可以在开发人员有时间的时候被纠正 |
立即解决：电商系统的用户注册功能无法使用（无法登录、购买、结算、支付、下单、物流跟踪、收货、评论等功能无法进行），就必须立即修复；
高优先级：自然时常24小时之内
正常排队：新版本发布之前
低优先级：电商系统中关于用户购买流程帮助说明的网页链接点击404页面。没有什么影响
注意：优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可改可不改。
4. 缺陷的状态
缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
| 缺陷状态 | 描述 |
|---|---|
| 激活或打开 | 问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷 |
| 已修复或修复 | 已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证 |
| 关闭或非激活 | 测试人员验证后，确认缺陷不存在之后的状态 |
| 重新打开 | 测试人员验证后，还依然存在缺陷，等待开发人员进一步修复 |
| 推迟 | 这个软件缺陷还可以在下一个版本中解决 |
| 保留 | 由于技术原因或第三者软件的缺陷，开发人员不能修复缺陷 |
| 不能重现 | 开发不能再现这个软件缺陷，需要测试人员检查缺陷复现的步骤 |
| 需要更多信息 | 开发能再现这个缺陷，但开发人员需要一些信息。例如缺陷的日志文件、图片等 |
| 重复 | 这个软件缺陷已经被其他测试人员发现 |
| 不是缺陷 | 这个问题不是软件缺陷 |
| 需要修改软件规格说明书 | 由于软件规格说明书对软件设计的要求，必须要修改软件说明书 |
缺陷的状态：表示缺陷的处理进度
发现缺陷是缺陷处理的前提，但是还没有进入缺陷的处理流程
- 激活/打开（新建）：由测试人员标注
- 确认：确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、质量保证（QA）或产品经理进行确认。经确认后，有效的缺陷会指派给相关人员进行处理
- 已修复/修正：在缺陷被修复后，一般由开发人员进行
- 关闭/非激活：缺陷被修复完成后，经过测试人员的验证后，没有问题
- 重新打开：经过测试人员的验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复
- 推迟：缺陷现在不修复，推迟下一个版本或者阶段，测试要跟开发或者其他相关的管理人员进行确认
- 保留：缺陷暂时修复不了，一般也是由开发人员去设定，也需要测试人员进行确认
- 不能重现：开发按照缺陷的复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异、浏览器的缓存等信息，出现问题。所以作为测试人员，提交bug之前，要再三确认bug.
- 需要更多信息：作为测试人员，提交bug的时候，要尽可能的把所有相关文件一起提交。（图片、视频）
- 重复：测试中，一定要避免这种情况的出现。尤其在软件的某一个功能频繁被多个模块（由不同的测试人员测试）调用的情况下。
- 不是缺陷：一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是缺陷
- 需要修改需求说明书：缺陷不是技术原因造成的，而是由于需求不明确或者设计不明确造成
5. 缺陷的起源
| 缺陷起源 | 描述 |
|---|---|
| 需求 | 在需求测试发现的缺陷 |
| 架构 | 在系统架构设计阶段发现的缺陷 |
| 设计 | 在程序设计阶段发现的缺陷 |
| 编码 | 在编码阶段发现的缺陷 |
| 测试 | 在测试阶段发现的缺陷 |
| 用户 | 在用户使用阶段发现的缺陷 |
6. 缺陷的来源
| 缺陷来源 | 描述 |
|---|---|
| 需求说明书 | 需求说明书的错误或不清楚引起的 |
| 设计文档 | 设计文档描述不准确，和需求说明书不一致的问题 |
| 系统集成接口 | 系统各模块参数不匹配、开发组之间缺乏协调所引起的缺陷 |
| 数据流（库） | 由于数据字典、数据库中的错误引起的缺陷 |
| 程序代码 | 是编码中的问题所引起的缺陷 |
7. 缺陷的根源
| 缺陷根源 | 描述 |
|---|---|
| 测试策略 | 错误的测试范围，误解了测试目标，超越测试能力等 |
| 过程，工具和方法 | 无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等 |
| 团队/人 | 项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等 |
| 缺乏组织和通讯 | 缺乏用户参与，职责不明确，管理失败等 |
| 硬件 | 硬件配置不对、缺乏，或处理器导致算数精度丢失，内存溢出 |
| 软件 | 软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫的问题等 |
| 工作环境 | 组织机构调整，预算改变，工作环境恶劣，如噪音过大 |
缺陷的起源、来源、根源。一般关注较多的是缺陷的来源（直接原因）；在测试总结的时候，关注缺陷的根源。
缺陷的生命周期
发现缺陷：由测试人员发现
提交缺陷：由测试人员提交
确认缺陷：一般由测试主管、或者质量保证（QA）、由产品经理确认
分配缺陷：经过确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发、也可能是UI、可以能使产品经理。
修复缺陷：主要由开发修复，也有可能是产品经理修复文档问题，也有可能是UI修复界面设计缺陷
验证缺陷：测试人员去验证缺陷有没有修复成功。
关闭缺陷：只能是测试人员进行。否则出了问题，测试人员一律不背锅。
缺陷的识别（重点）
- 通过测试用例中的预期结果进行识别
- 通过需求规格说明书进行识别
- 通过用户手册及其他文档进行识别
- 通过同行业相类似成熟的商业软件来识别
- 通过和开发人员的沟通进行识别（最下下策）
- 通过和有经验的测试人员沟通进行识别
- 参照同行业隐式需求进行识别
客观依据：需求文档、设计文档、产品原型、测试用例
主观依据：同行业相类似的成熟软件，和开发人员沟通进行识别，和有经验的测试人员沟通，根据同行业的隐性需求
测试人员在识别缺陷的时候，要很灵活的对待。
缺陷报告
[缺陷报告本身要保证没有任何表述性的错误]
缺陷编号：Bug_项目名称_功能名称_00001
所属模块：一级模块/二级模块/三级模块。例如：上课所用的直播软件，如果想要查看签到的历史记录，需要进入直播主界面——互动应用——签到——签到历史记录
优先级：缺陷的修复紧急程度。P1>P2>P3>P4
严重程度：S1>S2>S3>S4
缺陷概述：用一句话描述缺陷的基本情况
缺陷描述：将缺陷的复现步骤、预期结果和实际结果列出来。
提交人：是谁就写谁的名字
备注：一般写出产生该缺陷的特殊情况。将bug截图作为备注信息。
缺陷报告编写目的
- 易于搜索软件测试报告的缺陷
- 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确
- 软件开发人员希望获得缺陷的本质特征和复现步骤
- 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度
预期读者：开发人员、质量管理人员、市场人员、运维人员….
缺陷报告编写准则
- Correct（准确）：每个组成部分的描述准确，不会引起误解
- Clear（清晰）：每个组成部分描述清晰，易于理解
- Concise（简洁）：之包含必不可少的信息，不包括任何多余内容
- Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息
- Consistent（一致）：按照一致的格式书写全部缺陷报告
缺陷描述的准则
- 单一准确
- 可以再现：针对绝大多数缺陷。但有一小部分缺陷难以做到，如闪退崩溃不可再现，无需做到
- 完整统一
- 短小简练
- 特定条件
- 补充完整
- 不做评价：不对缺陷的严重程度和缺陷表现出来的效果进行主观臆断-
参考表
测试需求分析
| 测试需求编号 | 测试需求名称 | 质量特性 | 所在模块 | 所在页面 | 优先级 | 负责人 | 版本号 | 需求详细描述 |
|---|---|---|---|---|---|---|---|---|
测试用例
| 用例编号 | 用例名称 | 用例描述 | 需求编号 | 步骤名称 | 步骤描述 | 预期结果 | 实际结果 | 是否通过 | 缺陷编号 |
|---|---|---|---|---|---|---|---|---|---|
缺陷报告
| 缺陷编号 | 所属模块 | 优先级 | 严重程度 | 缺陷概述 | 缺陷描述 | 提交人 | 备注 |
|---|---|---|---|---|---|---|---|
白盒测试逻辑覆盖图
