我们首先会将上一期留下来的测试方案的知识进行一个收尾
一、测试方案编写
1、什么是测试方案？
测试方案是提供不同类型测试的具体方法一份文档，测试方案可能是独立的一份文档或有些测试方案合并在测试计划中。
2、功能测试的测试策略
2.1 测试目标
这是个功能模块的功能满足需求。
2.2 测试范围
注册登录，消息发布，文档查询，问题提交。
2.3 测试方法
- 针对各个功能点使用有效数据时得到预期的结果
- 针对各个功能点在使用无效数据时显示相应的错误或警告消息
- 各业务规则得到了正确的执行
2.4 完成标准
- 所计划的测试点和测试用例已全部执行
- 所发现的缺陷和bug全部记录下来
2.5 需考虑的特殊事项
消息发布是否正常显示？
3、安全性测试的测试策略
安全测试，一般它不在我们的系统测试范围中。
3.1 测试目标
- 系统安全性
- 不同用户的操作权限
3.2 测试方法
- 用正常用户和非法用户登录系统是否正常？
- 用户登录后超出一定时间是否自动退出？
3.3 完成标准
各种已知的角色类型都可访问相应的功能，而且都按照预期的方式执行。
3.4 需考虑的特殊事项
同一台测试机器上测试不同用户登录，留意catch以及session对切换用户登录的影响，测试session过期后系统的处理。
4、本地/国际化测试的测试策略
4.1 测试目标
系统能处理多种国家的语言和风俗，并且符合当地习俗、文化、背景、方言。
4.2 测试方法
- 系统是否支持不同区域的数据设计格式？
- 系统本地化的内容是否标准？
4.3完成标准
国家不同风俗的人是否都可以舒服的访问系统？
4.4 需考虑的特殊事项
不同语言的字符长度不一样，在设置字符长度时需考虑。
5、数据库测试的测试策略
5.1 测试目标
测试MySQL数据库操作是否正常合法？
5.2 测试方法
- 输入成功注册的用户信息，查看与数据库是否一致
- 查看发布信息是否可以正常输入数据库
5.3 完成标准
所有对数据库的操作准确完成，数据无错误。
5.4 需考虑的特殊事项
考虑mysql运行是否正常？
6、兼容性测试的测试策略
谈到兼容性测试一般有以下：
- 软件与平台操作系统的兼容：win10 win11 win8
- 软件与其他软件的兼容
- 浏览器的兼容(web项目)
- 对常用的主流浏览器进行一个覆盖
- 同类型的不同版本的浏览器进行覆盖(常用的主流版本)
6.1 测试目标
核实在以下软件环境下，软件能工作正常：
- Firefox 3.5.3
6.2 测试方法
在Firefox浏览器下注册登录，发布及查询信息是否正常？
6.3 完成标准
软件正常工作，没有medium级别及以上的缺陷，或者发现的错误被修改。
7、可靠性测试的测试策略
7.1 测试目标
测试其在反复点击按钮和注册不同的用户时是否出现错误。
7.2 测试方法
- 反复点击注册登录按钮，是否会发生错误
- 注册大量不同的合法用户名是否会出错
4.3 完成标准
所有反复点击测试，注册不同合法用户后都可正常操作。
8、回归测试的测试策略
8.1 测试目标
在程序有修改的情况下，保证原有整个软件系统功能正常。
8.2 测试方法
重点测试bug修改、bug修改关联模块、新增模块、重点模块，时间允许的情况下测试全部用例。
8.3 完成标准
软件系统功能正常，没有medium级别及以上的缺陷。
8.4 需考虑的特殊事项
如果系统在回归测试期间发现medium级别以上的缺陷，需要重新构建候选版本，并在新的候选报名上重新回归，直到系统稳定运行。
9、集成测试的测试策略
9.1 测试目标
检测需求中业务流程，数据流的正确性，需求中明确的业务流程，或组合不同功能模块而形成的一个大的功能。
9.2 测试方法
利用有效和无效的数据来执行各个用例用例流或功能，已核实以下内容：
- 在使用有效数据时得到预期的结果
- 在使用无效数据时，显示相应的错误消息或警告消息
- 各业务规则都得到了正确的应用
- 各种可能的业务流程符合预期的结果
9.3 完成标准
- 所计划的测试已全部执行
- 所发现的缺陷已全部解决
9.4 需考虑的特殊事项
各功能模块间的衔接以及数据传递。
接下来再回顾我们的测试流程：需求分析->测试计划和方案->用例设计->评审用例->执行测试(涉及bug评审，bug提交等)->测试报告
接下来我们就介绍测试报告。
二、测试报告
1、什么是测试报告
测试报告是对整个测试工作进行总结及软件质量进行评估的一份测试文档。
2、如何写测试报告？
根据测试报告模板来进行编写测试报告。
测试报告模版链接：测试报告模版(来源于网络)
3、测试报告包含什么核心内容？
一份合格的测试报告，就像一份项目的"体检报告"。它不是为了应付差事，而是要客观、清晰地告诉所有项目成员（开发、产品、老板）："我们测了哪里？""怎么测的？""结果怎么样？""到底能不能上线？"
下面，我们就借助AI以一份项目测试报告为例，一步步拆解它的核心内容，让AI给我们通俗解释测试报告的知识。
声明：内容由AI辅助提供参考，由本人整理
3.1 测试范围
通俗解释：
这部分就像体检前的"项目确认单"。你得先告诉别人，你这次的任务是什么，你负责检查的是身体的哪个部位（是心脏还是肝脏），用的是哪种检查方法（是CT还是抽血）。最后，你检查的结果是"这个部位功能正常"还是"发现了问题"。
从报告里看什么：
打开文档的"概述"部分，这里就清晰地定义了本次测试的边界。
-
当前你的任务是什么？（测试目的）
报告里写着："说明本次测试的目的，比如确保基本功能稳定还是其他"。结合"测试类型"是"功能测试/性能测试/兼容性测试..."，这告诉我们，这次任务的核心是验证软件的基础功能是否稳定可靠，同时也要看看它在不同环境（比如不同浏览器）下表现如何。
-
你的范围是什么？（测试范围）
报告里用表格说明了"测试范围"，包括要测哪些功能模块，哪些模块本次不测（比如一些非核心功能）。这很重要，它能避免后续扯皮------如果有人问"为什么没测A功能"，你可以指着报告说："根据计划，A功能不在本次测试范围内。"
-
你做的哪一部分？（测试类型与角色）
报告中的"测试类型"明确了你是做功能测试 还是性能测试。"测试参与人"则列出了执行测试的人是谁，让大家知道这项工作由谁负责。
-
你得到的测试结果是啥？
虽然结果在最后，但范围部分就已经埋下了伏笔。整个报告后面的所有数据，都是为了回答"测试范围内的这些任务，最终完成得怎么样"这个问题。
小结：
写测试范围，就是给本次测试活动"画个圈"。让所有人知道，我们在这个圈里努力，圈外的事情本次不负责，这样目标清晰，责任明确。
3.2 测试环境
通俗解释：
还是用体检来比喻。你告诉医生你头疼，医生会问你："你是在家里头疼，还是在嘈杂的马路上头疼？"环境不同，可能导致的结果也不同。测试环境就是告诉别人："我们是在一个什么样的'场地'里进行测试的。"这个场地越接近真实用户使用的环境，测试结果就越有说服力。
从报告里看什么：
报告里用一个详细的表格，描述了测试环境。
- 硬件环境：包括测试服务器的IP地址、操作系统、CPU、内存等。这说明了我们的软件是跑在什么样的机器上的，比如"Linux服务器，内存256MB"。
- 软件环境：包括数据库类型（如MySQL 5.0）、应用服务器（如Apache2.2）、客户端的操作系统（如Windows XP SP3）和浏览器（如IE8.0）。
小结：
记录测试环境，一是为了确保测试结果可重现 ------今天在这个环境里发现的Bug，开发人员可以用同样的环境去定位和修复；二是为了评估风险------如果只在IE8下测过，那就不能保证用户在Chrome上使用时完全没有问题。
3.3 数据统计
通俗解释：
这是"体检报告"的核心数据页。用数字说话，直观展示测试的"量"和"质"。它不再是模糊的"感觉还行"，而是清晰的"我们执行了100个用例，通过了70个，发现了21个Bug"。
此部分我们可以借助禅道中的报表来统计
3.3.1 bug数据（Bug严重级别统计）
报告中"问题单分类统计"的第一个表格，就是按严重级别来划分Bug的。
- 致命 (2个)：系统崩溃、数据丢失等，必须解决才能上线。
- 严重 (5个)：主要功能无法使用，影响核心流程。
- 一般 (12个)：非核心功能出错，或有明显的问题。
- 轻微 (0个)：界面错别字、样式小问题等。
为什么重要： 这个统计直接反映了软件的质量状况。如果"致命"和"严重"级别的问题很多，那测试结论很可能是"不通过"。它就像一个报警器，提醒项目组优先解决最严重的问题。
3.3.2 bug状态（Bug状态统计）
报告中有一个"Bug状态统计"表，它告诉我们每个Bug当前处于什么阶段。
- 未解决：开发还没开始修。
- 已解决：开发修好了，等待测试验证。
- 关闭：测试验证通过，问题已解决。
- 挂起/打回：一些特殊情况，比如延期处理或开发修得不对被打回。
为什么重要： 这个统计反映了修复的进度。一个健康的项目，在测试后期，"关闭"的Bug数量应该远多于"未解决"的数量。报告里有一个分析："正常情况 已关闭的bug要多，未解决的bug( 不予解决 延期 )"，这正是对状态数据的解读。
3.3.3 bug类型统计
表格"BUG类型统计"将Bug按性质分类。
- 功能 (11个)：功能逻辑出错。
- UI (4个)：界面显示问题。
- 体验 (6个)：用户操作不顺畅。
- 异常、极限、网络 (0个)：本次测试未发现这些类型的问题。
为什么重要： 通过这个分类，可以分析问题的根源。如果"功能"类Bug很多，说明开发质量或需求理解可能有偏差；如果"UI"类Bug很多，说明前端开发或设计评审环节要加强。这为后续改进流程提供了数据依据。
3.3.4 测试阶段统计
报告中的"测试执行阶段统计"图（media/image3.png），通常是一个曲线图，横轴是时间，纵轴是Bug数量。这个图非常有价值。
为什么重要： 它展示了Bug发现的趋势。一个理想的趋势是：测试前期Bug数量快速上升（集中发现Bug），测试中后期Bug数量快速下降并趋于0（Bug被修复，系统趋于稳定）。如果到测试末期，Bug数量还是居高不下，说明软件质量不稳定，风险很高。
3.3.5 按功能模式统计
很多测试报告会将Bug按照功能模块（如：登录模块、支付模块、搜索模块）进行统计。
为什么重要： 它能精准定位"问题高发区"。比如统计发现"支付模块"的Bug占了总数的一半，那么产品经理和开发负责人就需要重点关注这个模块，分析是需求复杂、开发人员经验不足，还是设计有缺陷。这能让团队的改进措施更有针对性。
3.4 测试总结
通俗解释：
这是整份报告的"结论"和"建议"。就像体检报告的"最终诊断"：身体各项指标是否正常？需要注意什么？是否能"健康上岗"？
从报告里看什么：
-
质量评价：对软件的整体表现做一个定性描述。比如报告里的"【质量评价】"部分，你需要根据前面的数据（用例通过率、Bug严重程度、遗留问题等）填写你的评价，例如："软件核心功能稳定，但存在少量兼容性问题，整体质量基本符合预期。"
-
测试结论 ：这是最重要的一句话结论。报告里给出了两个选项，你必须在其中做出选择。
- 通过，可以发布及系统上线：这意味着经过测试，我们认为软件的质量达标，风险可控，可以交付给用户。
- 不通过，需要进行重大修改更新版本重新测试：这意味着存在严重问题（如致命Bug未修复、核心功能不稳定等），当前版本不具备上线条件，必须修复后重新测试。
-
评估人员/审核人员：谁做的评估，谁审核的，签字确认，以示负责。
小结：
测试总结就是用最精炼的语言，给整个项目做一个最终的"盖章定论"。它结合了前面的所有数据和分析，为项目经理和产品经理决定"发不发布"提供了最直接的依据。
3、常用单位：人天
他是用来衡量工作量的。
比如我们的测试团队成员人数是5个人，时间是2天，那工作量就是2天5人【人天】
到此我们的测试流程就已经结束了：
总结就是
项目立项->测试需求分析->测试计划->测试设计->测试执行(包含bug相关的知识)->测试报告->项目结束。
- 项目立项：明确项目目标、背景，确定我们要"测什么"。
- 测试需求分析：深入理解业务需求，梳理出测试要点，为后续设计打下基础。
- 测试计划：制定测试策略、资源安排、时间节点，确保测试工作有序推进。
- 测试设计：编写测试用例，覆盖功能、异常、兼容性等场景，让测试有据可依。
- 测试执行（含Bug跟踪）：运行用例，发现缺陷，记录Bug并进行生命周期管理（提交、修复、验证、关闭）。
- 测试报告：将整个过程的数据和结论汇总成文档，向项目组交付一份客观的"质量体检报告"。
- 项目结束：基于报告结论，决定版本是否发布，并为后续迭代积累宝贵经验。
三、Git工具安装
Git工具的安装参考博客：
Git工具的安装和使用
老铁们，如果你觉得这篇文章对你有帮助，别忘了👍点赞⭐ 收藏👀 关注，🦀🦀各位老铁的支持，你的支持是我持续创作的动力~~