我们首先会将上一期留下来的测试方案的知识进行一个收尾一、测试方案编写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.36.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数量快速下降并趋于0Bug被修复系统趋于稳定。如果到测试末期Bug数量还是居高不下说明软件质量不稳定风险很高。3.3.5 按功能模式统计很多测试报告会将Bug按照功能模块如登录模块、支付模块、搜索模块进行统计。为什么重要它能精准定位“问题高发区”。比如统计发现“支付模块”的Bug占了总数的一半那么产品经理和开发负责人就需要重点关注这个模块分析是需求复杂、开发人员经验不足还是设计有缺陷。这能让团队的改进措施更有针对性。3.4 测试总结通俗解释这是整份报告的“结论”和“建议”。就像体检报告的“最终诊断”身体各项指标是否正常需要注意什么是否能“健康上岗”从报告里看什么质量评价对软件的整体表现做一个定性描述。比如报告里的“【质量评价】”部分你需要根据前面的数据用例通过率、Bug严重程度、遗留问题等填写你的评价例如“软件核心功能稳定但存在少量兼容性问题整体质量基本符合预期。”测试结论这是最重要的一句话结论。报告里给出了两个选项你必须在其中做出选择。通过可以发布及系统上线这意味着经过测试我们认为软件的质量达标风险可控可以交付给用户。不通过需要进行重大修改更新版本重新测试这意味着存在严重问题如致命Bug未修复、核心功能不稳定等当前版本不具备上线条件必须修复后重新测试。评估人员/审核人员谁做的评估谁审核的签字确认以示负责。小结测试总结就是用最精炼的语言给整个项目做一个最终的“盖章定论”。它结合了前面的所有数据和分析为项目经理和产品经理决定“发不发布”提供了最直接的依据。3、常用单位人天他是用来衡量工作量的。比如我们的测试团队成员人数是5个人时间是2天那工作量就是2天5人【人天】到此我们的测试流程就已经结束了总结就是项目立项-测试需求分析-测试计划-测试设计-测试执行(包含bug相关的知识)-测试报告-项目结束。项目立项明确项目目标、背景确定我们要“测什么”。测试需求分析深入理解业务需求梳理出测试要点为后续设计打下基础。测试计划制定测试策略、资源安排、时间节点确保测试工作有序推进。测试设计编写测试用例覆盖功能、异常、兼容性等场景让测试有据可依。测试执行含Bug跟踪运行用例发现缺陷记录Bug并进行生命周期管理提交、修复、验证、关闭。测试报告将整个过程的数据和结论汇总成文档向项目组交付一份客观的“质量体检报告”。项目结束基于报告结论决定版本是否发布并为后续迭代积累宝贵经验。三、Git工具安装Git工具的安装参考博客Git工具的安装和使用老铁们如果你觉得这篇文章对你有帮助别忘了点赞⭐ 收藏 关注各位老铁的支持你的支持是我持续创作的动力~~