标签：测试报告 用例 水杯 测试用例 测试 缺陷 过程 测试环境
- 首先，我们需要了解需要工作的项目现状，项目的开发者和应用的语言，和前端的网页框架，以及后端的数据库是什么和版本。和网站系统的架构和涉及的中间件。是B/S,还是C/S项目架构格式和项目的进度，为了测试的开发阶段划分。
- 之后，我们需要快速熟悉业务需求，通过用户手册和产品经理的开发要求，当遇到文档存疑的地方，可以咨询产品经理和甲方用户，确定业务要求，熟悉业务的要求和基本功能，方便编写测试计划和测试用例。同时需要画出业务流程图和组织结构图。
- 在熟悉业务后，我们将要编写测试计划，按照开发阶段划分，确定测试阶段，按照测试方式和要求，是选择白盒测试还是黑盒测试，如果是白盒测试，是测静态和动态的一种，亦或者是两种都测。测试代码的执行情况和代码覆盖率。在黑盒测试中，包括前端的UI测试，如尺寸大小和出现情况，有无敏感字和敏感图片，是否遵守法律。逻辑功能，是否符合使用的逻辑和场景分析法，功能是否完全实现和功能是否有遗漏和缺陷。兼容性，如果只在浏览器端使用，需要测试不同主流浏览器和版本，以及尺寸问题和不同的操作系统的浏览器兼容性。如果是同时在手机端和浏览器使用，在前者的基础上，还要测试不同系统的手机，如IOS和鸿蒙，和不同手机的主流浏览器和主流手机尺寸的解析显示情况。易用性，是否方便用户使用，如果有青少年和老人，能否顺利实现业务功能，对老人的使用操作是否简单易用。安全性，如果涉及个人信息，是否容易泄露和被攻击，安装卸载是否简单，不影响用户体验等等。性能测试，运行空间的要求和高并发的时候，数据库和程序事发后崩溃。稳定性测试和压力测试，不断给系统施加压力，直到压垮为止。负载测试，在承受范围内，持续运行，查看系统处理能力。回归测试和冒烟测试。冒烟测试，查看系统基本功能有没有实现，会不会阻塞进一步的测试。
- 搭建测试环境，选择合适的云服务器，通过第三方工具上传的tomcat，nginx和jdk，解压安装tomcat和nginx。在配置文件中配置环境变量，同时上传数据库，设置用户名密码，导入数据，启动连接数据库，启动tomcat和nginx。通过第三方工具Navicat，连接数据库。对比前台和后端数据是否一致，排查问题，确认测试环境搭建情况。
- 设计，编写，执行测试用例，在了解功能的基础上，划分模块，分配工作到个人，通过测试用例编写方法，实现测试用例的覆盖。如等价类划分法，输出输入法，决策表，正交法，边界值法，流程法等等。从不同角度，使用不同方法，极可能多的覆盖测试用例。开会，评审测试用例，进行调整和补充测试用例。执行测试用例，通过工具，实现自动化执行测试用例，可以在工具输入测试用例，也可以把测试用例编写成文件，方便导入执行和传递使用调整。通过编写python代码脚本，导入数据，自动执行。设置报告模板，自动生成测试报告，用于复测和调整方案。反馈开发，修改bug。
- 编写和提交缺陷报告，发现缺陷
用户体验不够好 界面上有明显的错误信息
功能不完备，没有按照需求说明编写代码，致使某些功能缺失
功能不完善，不能正常运行或者运行的过程中出现程序崩溃、停止运行的情况
逻辑不正确，与需求说明书，测试用例不符
模块之间的交互性不好，与其他的模块做集成测试的时候遇到问题
程序的性能不够好，不能承载压力考验
BUG重现
- 不要想当然的接受任何假设，要做好记录
- 查找时间依赖和竞争条件的问题
- 边界条件软件缺陷、内存泄漏和数据溢出等白盒问题可能会慢慢自己显露出来
- 状态缺陷仅在特定软件状态中显露出来
- 考虑资源依赖性和内存、网络、硬件共享的相互作用
缺陷报告的组织架构
1 缺陷的标题
2 缺陷的基本信息
3 测试的软件和硬件的环境
4 测试的软件版本
5 缺陷的类型
6 缺陷的严重程度
7 缺陷的处理优先级
8 复现缺陷的操作步骤
9 缺陷的实际结构描述
10 期望的正确结果描述
11 注释文字和截图的缺陷图像
- 编写测试报告，
一、测试报告书内容
测试报告书的内容可以总结为以下目录：
(1)首页
(2)引言
目的
背景
缩略语
参考文献
(3)测试概要
测试方法
测试范围
测试环境
测试工具
(4) 测试结果与缺陷分析
功能测试
性能测试
(5) 测试结论与建议
项目概况
测试时间
测试情况
结论性能汇总
(6) 附录
缺陷统计
二、测试报告书各部分的格式内与容
1、首页
(1)测试报告名称
产品名称
版本号
XX测试报告
(2)测试报告委托方
报告责任方
报告日期等
(3)测试版本变化历史
(4)测试密级
2、引言
2.1 引言编写
引言编写目的是简单的阐述该测试报告的具体编写目的，指出预期的读者范围。
实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。
2.2 项目背景
对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。
2.3 系统简介
如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图。
2.4 术语和缩略语
列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。
2.5 参考资料
(1)需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的资料。
(2)测试使用的国家标准、行业指标、公司规范和质量手册等等。
3、测试概要
3.1 测试的概要介绍
包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。
3.2 用例设计方法
简要介绍测试用例的设计方法
3.3 测试环境与配置
简要介绍测试环境及其配置。
提示：清单如下，如果系统/项目比较大，则用表格方式列出数据库服务器配置。
4、测试结果与缺陷分析
整个测试报告中这是最重要的部分，这部分主要汇总各种数据
并进行度量，度量包括对测试过程的度量和能力评估、对产品产品的质量度量和产品评估。对于不需要过程度量或者相对较小的项目，例如用于验收时提交用户的测试报告、小型项目的测试报告，可省略过程方面的度量部分；而采用了工程标准过程的，需要提供过程改进建议和参考的测试报告－主要用于内部测试改进和缺陷预防机制－则过程度量需要列出。
4.1 测试执行情况与记录
(1)描述测试资源消耗情况
(2)记录实际数据
测试数据
项目关注部分数据
4.2 测试组织
可列出简单的测试组架构图，包括：
(1)测试组架构 （如存在分组、用户参与等情况）
(2)测试经理（领导人员）
(3)主要测试人员
(4)参与测试人员
4.3 测试时间
列出测试的跨度和工作量，最好区分测试文档和活动的时间。数据可供过程度量使用。
例如 XXX子系统/子功能：实际开始时间－实际结束时间,总工时/总工作日,任务开始时间/结束时间,总计。
4.4 测试版本
给出测试的版本，如果是最终报告，可能要报告测试次数回归测试多少次。列出表格清单则便于知道那个子系统/子模块的测试频度，对于多次回归的子系统/子模块将引起开发者关注。
4.5 覆盖分析
(1) 需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100%的目标。
(2)测试覆盖：需求/功能（或编号） 用例个数 执行总数 未执行 未/漏测分析和原因。
4.6缺陷分析
本部分对上述缺陷和其他收集数据进行综合分析
缺陷综合分析
缺陷发现效率 = 缺陷总数/执行测试用时
可到具体人员得出平均指标
用例质量 = 缺陷总数/测试用例总数 ×100%
缺陷密度 = 缺陷总数/功能点总数
缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出哪部分功能/需求缺陷最多，从而在今后开发注意避免并注意在实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。
测试曲线图 描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向
4.7 残留缺陷和未解决的问题
残留缺陷
编号：BUG号
缺陷概要：该缺陷描述的事实
原因分析：如何引起缺陷，缺陷的后果，描述造成产品局限性和其他限制性的原因
预防和改进措施：弥补手段和长期策略
未解决问题
功能/测试类型：
测试结果：与预期结果的偏差
缺陷：具体描述
评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响
5、测试结论与建议
5.1 测试结论
(1)测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
(2) 对测试风险的控制措施和成效
(3) 测试目标是否完成
(4) 测试是否通过
(5) 是否可以进入下一阶段项目目标
5.2 建议
(1)对系统存在问题的说明，描述测试所揭露的产品缺陷和不足，以及可能给产品实施和运行带来的影响
(2)可能存在的潜在缺陷和后续工作
(3)对缺陷修改和产品设计的建议
(4)对过程改进方面的建议
6、附录
(1) 缺陷列表
(2) 缺陷等级定义标准
(3)测试通过标准
按顺序依次为：【搭建测试环境】、【需求评审】、【编写测试计划】、【分析测试点.编写测试用例】、【用例评审】、【执行用例提bug】、【测试报告】
一 : 搭建测试环境
在服务器上搭建测试环境。
(1) 搭建测试环境之 【常见项目结构模式】
（2）建测试环境之 【服务器介绍】
（3）搭建测试环境之 【HTTP协议】-—— 请求
（4）搭建测试环境 之【HTTP协议】——响应
（5）搭建测试环境 之【HTTP与HTTPS的区别】
（6）搭建测试环境之 【http1.0 与http 1.1的区别】
搭建后台测试环境操作
（7）*编辑环境变量文件 ，配置环境变量
vi /etc/profile
———————————————————————————————————————————————————————————
JAVA_HOME=/usr/local/jdk1.8.0_161/
CLASSPATH=$JAVA_HOME/lib/
PATH=$PATH:$JAVA_HOME/bin
export PATH JAVA_HOME CLASSPATH
———————————————————————————————————————————————————————————
* 刷新环境变量文件
source /etc/profile
* 验证是否安装成功了java环境
java -version 查看java版本号
javac
* 只要不报不是内部或者外部命令 就代表java环境变量配置完成
* 坑---->可能需要断开xterm再次连接
(8) *服务器安装Tomcat 软件
（9）*启动Tomcat 服务器
（10）*安装mysql并导入数据库
（11）*链接数据库工具 Navicat
* 操作数据库需要连接数据库的工具navicat,但是navicat不能够直接`连上远程mysql,mysql需要远程授权
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'root' WITH GRANT OPTION;
mysql>flush privileges; 刷新远程授权
* windowns电脑上使用navicat工具连接linux的mysql数据库
* 创建育华商城需要的数据库,并且导入数据
用命令行创建数据库yhsc_mall_db
导入数据
*项目前台和后台数据库对比说明
二：（1）需求评审
二：（2）一份完整/标准的需求文档包含哪些内容
概述:专业名词解释 阅读对象…
产品描述
* 整体流程
* 需求描述
* 版本规划
* 功能列表--产品结构图
功能需求(具体某个功能的要求)
* 流程图
* 界面
* 字段说明
非功能需求
* 安全
* 性能
上线需求
* 验收标准
运营计划
附录
二：（3）*测试人员在需求评审阶段干什么?
1.听懂产品经理讲述的需求标准
2.划分功能模块/功能列表,如果prd里面没有列出功能模块,自己列出
3.捋清楚整个项目的流程 以及各个功能模块的流程
二：（4）包括以下
三：编写测试计划 之【软件测试分类】——（1）
三：（2）*如何测试XXXX案例
三：（3）*测试计划是怎么编写的？
三：测试用例覆盖率是多少？为什么这么说？
三：（1）分析测试点,设计并编写测试用例
三：测试用例的基本概念（1）
三：测试用例的特征（2）
三：你们测试用例里面有哪些内容/测试用例模板中有哪些栏位 （3）
三：编写测试用例方法（3）
三：测试用例设计思路
独立功能测试
场景测试
界面测试
Web页面性能
兼容性测试 之 什么时候测试
兼容性测试 之 如何测试
安全性测试
常见的web安全问题
三：用例评审 （1）
三：执行用例 提bug 之【关于bug】——bug的分类
三：执行用例 提bug 之【关于bug】——bug的生命周期
三：执行用例 提bug 之【测试管理工具】——禅道
三：执行用例 提bug 之【测试管理工具】——禅道 （概念）
三：执行用例 提bug 之【测试管理工具】——禅道 （介绍）
三：执行用例 提bug之【测试管理工具】—禅道 后台环境搭建）
三：执行用例 提bug之【测试管理工具】—禅道 （使用）
三：执行用例 提bug之【测试管理工具】—禅道 （测试人员）
四：测试报告
水杯测试
标签：测试报告,用例,水杯,测试用例,测试,缺陷,过程,测试环境 来源： https://blog.csdn.net/hhjjzd/article/details/120585499
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。