3、AI测试辅助-测试计划编写(自动生成任务甘特图)

一、创建测试计划

测试计划格式内容:
一般需要包括以下几点:
1、测试目标
2、测试范围
3、测试人员
4、测试排期
5、测试资源
6、测试方法与方案
7、风险评估
8、测试报告

1.1 使用ChatGpt生成测试计划

  • 提示词:当我是测试经理时,根据上述的电商app购物车模块的功能需求,请帮我编写一页完整的测试计划

    测试计划:电商App购物车模块
    
    版本:1.0
    日期:XXXX年XX月XX日
    
    目录
    
    引言
    
    测试目的
    
    测试范围
    
    测试方法
    
    测试策略
    
    测试进度
    
    测试资源
    
    风险评估
    
    缺陷管理
    
    测试报告
    
    参考文献
    
    引言
    本测试计划是为了对电商App购物车模块进行全面的测试,确保其功能、性能、可靠性和用户体验符合需求和用户期望。此测试计划将包括测试目的、测试范围、测试方法、测试策略、测试进度、测试资源、风险评估、缺陷管理和测试报告等内容。
    
    测试目的
    本测试计划的目的是:
    
    对电商App购物车模块进行全面测试,确认其功能、性能、可靠性和用户体验符合需求和用户期望。
    在测试过程中发现和记录缺陷,并及时反馈给开发人员以便修复。
    确定测试进度和测试资源,有效利用测试资源,保证测试任务按计划顺利完成。
    提供测试报告,记录测试结果和缺陷情况。
    测试范围 本测试计划的测试范围包括:
    添加商品到购物车
    修改商品数量
    删除商品
    结算
    响应式布局测试
    浏览器兼容性测试
    主题风格一致性测试
    导航和操作流畅性测试
    错误信息提示测试
    用户友好性测试
    无障碍访问性测试
    测试方法 本测试计划的测试方法包括:
    单元测试
    集成测试
    系统测试
    验收测试
    4.1 单元测试
    单元测试主要测试购物车各功能模块的正确性,用于发现和定位代码缺陷。单元测试包括以下测试用例:
    
    测试用例	测试内容
    添加商品到购物车	验证商品信息与显示一致,确认商品数量正确增加
    修改商品数量	验证数量修改后的商品信息是否正确更新
    删除商品	验证商品删除成功后是否在购物车页面中消失
    结算	验证结算按钮是否正确跳转到结算页面,确认商品信息、收货地址、支付方式等信息正确
    4.2 集成测试
    集成测试模拟各功能模块之间的交互,测试购物车整体功能是否正常。集成测试包括以下测试用例:
    
    测试用例	测试内容
    添加商品到购物车	测试与商品模块的交互
    修改商品数量	测试修改数量功能和商品模块的交互
    删除商品	测试删除功能和商品模块的交互
    结算	测试结算功能和订单模块的交互
    4.3 系统测试
    系统测试在真实环境下进行全面测试,包括响应式布局、浏览器兼容性、主题风格一致性等方面。系统测试包括以下测试用例:
    
    测试用例	测试内容
    响应式布局测试	在不同设备上测试购物车模块的响应式布局
    浏览器兼容性测试	在各种主流浏览器上测试购物车模块的兼容性
    主题风格一致性测试	测试购物车模块的主题风格是否一致
    导航和操作流畅性测试	测试购物车模块的导航和操作流畅性
    错误信息提示测试	测试错误信息提示是否正确
    用户友好性测试	测试购物车模块的用户友好性
    无障碍访问性测试	测试购物车模块的无障碍访问性
    4.4 验收测试
    验收测试邀请实际用户参与,测试购物车模块的易用性和用户体验。验收测试包括以下测试用例:
    
    测试用例	测试内容
    添加商品到购物车	测试添加商品功能是否易用
    修改商品数量	测试修改数量功能是否易用
    删除商品	测试删除功能是否易用
    结算	测试结算功能是否易用
    测试策略 本测试计划的测试策略包括:
    正常情况下的测试用例
    异常情况下的测试用例
    5.1 正常情况下的测试用例
    正常情况下的测试用例主要测试购物车模块的常规功能,确保其能够顺利完成各项操作。
    
    5.2 异常情况下的测试用例
    异常情况下的测试用例主要测试购物车模块的容错能力和异常处理能力,包括并发添加商品、超出库存数量添加、商品下架后添加、超出购物车容量限制、无效商品信息添加等。
    
    测试进度 本测试计划的测试进度如下:
    单元测试:2天
    集成测试:3天
    系统测试:5天
    验收测试:2天
    测试资源 本测试计划所需的测试资源包括:
    测试设备:安卓和iOS手机、平板、电脑等多个设备
    测试环境:不同浏览器(Chrome、Firefox、Safari、Edge等)
    测试工具:Jira用于缺陷管理,Selenium用于自动化测试
    风险评估 本测试计划的风险评估如下:
    高风险:购物车模块无法正常添加商品或结算功能出现严重问题
    中风险:购物车模块存在一些小问题,但不影响使用
    低风险:购物车模块基本符合需求和用户期望,但还有一些需要改进的地方
    缺陷管理
    本测试计划的缺陷管理将使用Jira进行,测试人员将及时记录和反馈发现的缺陷,并跟踪缺陷的处理过程。
    
    测试报告
    测试报告将包括测试结果、缺陷情况、风险评估等内容,并在测试结束后提交给开发人员和项目经理。
    

当然,如果你可以要求输出你想要的结构文本

  • 提示词:当我是测试经理时,根据上述的电商app购物车模块的功能需求,请帮我编写一页完整的测试计划,内容需要包括以下几点:
    1、测试目标
    2、测试范围
    3、测试人员
    4、测试排期
    5、测试资源
    6、测试方法与方案
    7、风险评估
    8、测试报告

1.1.1 测试计划细化-测试任务排期

  • 提示词:现在测试人员有三名,这个版本测试周期为一周,请对测试任务与安排模块进行细化
    在测试人员有三名且测试周期为一周的情况下,可以进行如下细化的测试任务与安排:

    第一天:

    测试人员1:用例编写(添加商品到购物车)
    测试人员2:用例编写(删除商品)
    测试人员3:用例编写(修改商品数量)
    第二天:

    测试人员1:集成测试(添加商品到购物车)
    测试人员2:集成测试(删除商品)
    测试人员3:集成测试(修改商品数量)
    第三天:

    测试人员1:系统测试(响应式布局测试)
    测试人员2:系统测试(浏览器兼容性测试)
    测试人员3:系统测试(主题风格一致性测试)
    第四天:

    测试人员1:系统测试(导航和操作流畅性测试)
    测试人员2:系统测试(错误信息提示测试)
    测试人员3:系统测试(用户友好性测试)
    第五天:

    测试人员1:系统测试(无障碍访问性测试)
    测试人员2:验收测试(添加商品到购物车)
    测试人员3:验收测试(删除商品)
    第六天:

    测试人员1:验收测试(修改商品数量)
    测试人员2:缺陷管理
    测试人员3:缺陷管理
    第七天:

    所有测试人员:系统测试(完整回归测试)、缺陷管理、测试报告编写
    通过以上安排,测试人员可以充分利用一周的时间完成各项测试任务,包括用例编写、集成测试、系统测试和验收测试。同时,保证了测试人员在测试过程中全面覆盖功能,并及时发现和处理问题,最终提供高质量的测试报告和结果。测试人员之间可以根据需要进行合作与协调,确保测试进度的顺利进行。

1.1.2 测试计划细化-利用plantuml输出甘特图(不推荐)

  • 提示词:请根据这个任务安排,输出一份人员排期plantuml 绘制的甘特图
    @startuml
    Project: 版本测试任务安排

    \[第一天]

    *   测试人员1: 用例编写(添加商品到购物车)
    *   测试人员2: 用例编写(删除商品)
    *   测试人员3: 用例编写(修改商品数量)

    \[第二天]

    *   测试人员1: 集成测试(添加商品到购物车)
    *   测试人员2: 集成测试(删除商品)
    *   测试人员3: 集成测试(修改商品数量)

    \[第三天]

    *   测试人员1: 系统测试(响应式布局测试)
    *   测试人员2: 系统测试(浏览器兼容性测试)
    *   测试人员3: 系统测试(主题风格一致性测试)

    \[第四天]

    *   测试人员1: 系统测试(导航和操作流畅性测试)
    *   测试人员2: 系统测试(错误信息提示测试)
    *   测试人员3: 系统测试(用户友好性测试)

    \[第五天]

    *   测试人员1: 系统测试(无障碍访问性测试)
    *   测试人员2: 验收测试(添加商品到购物车)
    *   测试人员3: 验收测试(删除商品)

    \[第六天]

    *   测试人员1: 验收测试(修改商品数量)
    *   测试人员2: 缺陷管理
    *   测试人员3: 缺陷管理

    \[第七天]

    *   所有测试人员: 系统测试(完整回归测试)、缺陷管理、测试报告编写

    @enduml

复制到
https://www.plantuml.com/plantuml/uml/SyfFKj2rKt3CoKnELR1Io4ZDoSa70000网址,发现报错了,ChatGpt3.5生成的格式有问题,多次修改后还是报错。最后官网找个例子,给它作为demo,根据上下文,提示ChatGpt进行以下优化

  • 优化提示词:“甘特图格式是这样的”@startgantt
    [Prototype design] requires 15 days
    [Test prototype] requires 10 days
    [Prototype design] starts D+0
    [Test prototype] starts D+15
    @endgantt"请优化下"

结果如下

@startgantt
[用例编写] requires 2 days
[集成测试] requires 3 days
[系统测试] requires 4 days
[验收测试] requires 2 days
[缺陷管理] requires 1 day
[测试报告编写] requires 1 day

[用例编写] starts D+0
[集成测试] starts D+2
[系统测试] starts D+5
[验收测试] starts D+9
[缺陷管理] starts D+11
[测试报告编写] starts D+12
@endgantt

周期是不对的,最后需要自己手动修改。
不建议直接使用ChatGpt3.5生成甘特图,与现在的plantuml格式有冲突。

1.1.3 测试计划细化-利用mermaid 生成甘特图(推荐)

  • 提示词:请生成测试任务的mermaid甘特图
gantt
    dateFormat  YYYY-MM-DD
    title 测试任务安排

    section 第一天
    用例编写: 2024-02-20, 2d
    删除商品: 2024-02-20, 2d
    修改商品数量: 2024-02-20, 2d

    section 第二天
    集成测试(添加商品到购物车): 2024-02-22, 1d
    集成测试(删除商品): 2024-02-22, 1d
    集成测试(修改商品数量): 2024-02-22, 1d

    section 第三天
    系统测试(响应式布局测试): 2024-02-23, 1d
    系统测试(浏览器兼容性测试): 2024-02-23, 1d
    系统测试(主题风格一致性测试): 2024-02-23, 1d

    section 第四天
    系统测试(导航和操作流畅性测试): 2024-02-24, 1d
    系统测试(错误信息提示测试): 2024-02-24, 1d
    系统测试(用户友好性测试): 2024-02-24, 1d

    section 第五天
    系统测试(无障碍访问性测试): 2024-02-25, 1d
    验收测试(添加商品到购物车): 2024-02-25, 1d
    验收测试(删除商品): 2024-02-25, 1d

    section 第六天
    验收测试(修改商品数量): 2024-02-26, 1d
    缺陷管理: 2024-02-26, 1d
    缺陷管理: 2024-02-26, 1d

    section 第七天
    系统测试(完整回归测试): 2024-02-27, 1d
    缺陷管理: 2024-02-27, 1d
    测试报告编写: 2024-02-27, 1d

生成后在线直接可以使用以下地址查看:https://mermaid.live/
,也可直接使用mardown格式生成,在上述文本中加上mermaid标识,结果如下:

2024-02-20 2024-02-21 2024-02-22 2024-02-23 2024-02-24 2024-02-25 2024-02-26 2024-02-27 2024-02-28 用例编写 删除商品 修改商品数量 集成测试(添加商品到购物车) 集成测试(删除商品) 集成测试(修改商品数量) 系统测试(响应式布局测试) 系统测试(浏览器兼容性测试) 系统测试(主题风格一致性测试) 系统测试(导航和操作流畅性测试) 系统测试(错误信息提示测试) 系统测试(用户友好性测试) 系统测试(无障碍访问性测试) 验收测试(添加商品到购物车) 验收测试(删除商品) 验收测试(修改商品数量) 缺陷管理 缺陷管理 系统测试(完整回归测试) 缺陷管理 测试报告编写 第一天 第二天 第三天 第四天 第五天 第六天 第七天 测试任务安排
集成测试计划 版本:V1.3 文 档 编 号 保 密 等 级 作 者 最后修改日期 审 核 人 最后审批日期 批 准 人 最后批准日期 修订记录 日期 版本 修订说明 修订人 目 录 1 简介 3 1.1 目的 3 1.2 背景 3 1.3 范围 3 1.4 参考文档 3 2 测试约束 3 2.1 测试进出条件 3 2.1.1 进入条件 3 2.1.2 退出条件 3 2.2 测试通过和失败准则 3 2.2.1 通过准则: 3 2.2.2 失败准则: 4 2.3 测试启动/结束/暂停/再启动准则 4 2.3.1 测试启动准则 4 2.3.2 测试结束准则 4 2.3.3 测试暂停/再启动准则 4 3 测试需求 4 4 测试风险 5 5 集成策略 5 6 测试策略 5 6.1 策略描述 5 6.2 测试类型 5 6.2.1 功能测试 5 6.2.2 接口测试 6 6.2.3 容错测试 6 6.2.4 回归测试 6 6.3 测试轮数 7 7 测试资源 7 7.1 人力需求 7 7.2 测试环境 8 7.3 测试工具 8 8 测试进度 8 9 本阶段量化计划 9 10 交付物 9 简介 目的 【描述集成测试计划编写目的及本次集成测试的主要目的。】 如,编写目的:本文档用于描述XXX开发项目集成测试所要遵循的规范以及确定测试方法、测试环境、测试用例的编写测试整体进度的计划安排、人力资源安排等。 测试目的:集成测试的目的是测试组成XXX系统的各子模块间的接口及功能实现等。 背景 【描述项目或产品的背景。】 范围 【描述集成测试在项目的整体范围。如,需要集成的各功能模块的描述。】 参考文档 【描述本次集成测试所需要参考的文档。】 测试约束 【描述本次集成测试所要遵循的准则及条件约束等。】 测试进出条件 进入条件 【描述集成测试测试依据和满足该阶段测试进入的条件和约束。】 退出条件 【描述满足该阶段测试退出的条件,要根据 《项目量化管理计划》中第3节的内容来制定退出条件,例如 致命和严重级别的缺陷清除率达到 100%,致命和严重的缺陷修复率达到100%,一般缺陷的修复率达到99%并且遗留缺陷数小于5个;同时参考《测试过程》中的相关描述,并要求系统测试每轮发现的缺陷数量呈收敛趋势。】 测试通过和失败准则 通过准则: 【描述集成测试每一轮测试通过的条件。】 如,每轮测试所有用例全部执行完毕,且没有出现致命性错误,回归测试或执行新增测试用例时不再出现问题,则测试工作通过; 失败准则: 【描述集成测试某轮次测试失败的条件。】 如,每轮测试所有用例全部执行完毕,没有出现致命性错误,回归测试或执行新增测试用例时不再出现问题,且回归测试的周期不少于X天,回归测试执行的测试用例数比例不低于XX%,则测试工作通过。 测试启动/结束/暂停/再启动准则 测试启动准则 【描述集成测试执行启动的约束准则。】 如, 配置管理员提交给测试组每次build的正确版本及集成的模块清单。 测试环境通过检验之后。 测试结束准则 【描述集成测试执行结束的约束准则。】 如,测试案例全部执行完毕,测试结果证明系统符合需求,遗留的问题满足测试退出条件且在质量标准允许范围内,即可结束测试测试暂停/再启动准则 【描述集成测试执行过程中出现的特殊情况的约束准则。】 如,被测模块出现某个致命性错误。测试案例无法继续执行,测试工作需暂停,如果非关联模块可以进行测试则执行非关联模块的测试;当这些问题得到解决后重新启动该模块的测试工作。 测试需求 【根据系统集成构建计划,列举每次集成的新版本产生新的测试需求功能点,包括接口的测试需求。】 需求ID 模块 子模块 待测试功能需求点 优先级 模块一 子模块1 功能点1 功能点2 … 功能点N 子模块2 … 子模块N 测试风险 【此处描述测试任务可能遇到的风险,以及规避的方法】 风险 编号 风险描述 风险发生可能性 (高、中、低) 风险的影响程度 (高、中、低) 责任人 规避方法 集成策略 【描述集成的方法、集成的顺序和集成的环境。详细的集成环境见《环境配置清单-集成环境》 集成顺序一般有:深度优先、自下而上、自上而下等; 深度优先:即关键(主控路径上的)业务流程涉及到的模块先集成到一起,然后再集成辅助业务模块; 自下而上:即已实现的较底层的功能优先集成,然后逐层上升,形成整个系统; 自上而下:即事先存在一个稳定的架构,不断地向下细化,最后实现所有具体的功能细节; 集成顺序的选择可以是不同集成顺序的综合。 】 集成计划 【说明项目周期内计划执行的集成活动的时间安排】 集成次号 集成目标 被集成对象 计划集成时间 包含的接口 测试策略 【测试策略提供了对以上测试对象实施测试的方法。上一节“测试需求”中说明了将要测试哪些对象,而本节则要说明如何对这些测试对象进行测试。】 【对每一个工作版本将进行以下三种类型的测试:A、接口测试测试接口调用。B、功能测试测试工作版本应该实现的功能。C、回归测试,在新版本中执行以前集成版本的测试用例脚本。】 策略描述 【此处描述根据项目的具体特征所确定的集成测试的策略(如:测试可行性分析,测试技术方法确定,测试类型选择以及集成的方案环境描述等】 测试类型 【此处描述集成测试选择的测试类型,一般建议有如下四种:】 功能测试 测试目标: 确保已经集成的工作版本的正确性,能够实现该集成版本应该具有的功能的正确性以及完整性。 技术: 重用为系统功能测试设计的部分测试用例,部分测试过程。生成测试脚本,实现测试自动化。 完成标准: 所计划的测试全部执行、 对以前版本的接口完成了回归测试、 所发现的高优先级缺陷和高等级的缺陷已完全解决。 需考虑的特殊事项: 开发人员应该保证每个后续的集成版本的基本界面元素都未改变。 考虑测试脚本的重用性以及自动化测试测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 接口测试 测试目标: 确保“测试需求”中对应的所有工作版本的内部单元组合到一起后能够按照设计的意图协作运行,接口的调用正确。 技术: 重用为系统测试准备的测试用例、 分析测试用例对接口的覆盖情况,对没有覆盖的接口设计足够的测试用例,以覆盖所有的调用接口。 为每个测试用例制定测试过程,生成测试脚本。以实现测试的自动化。 完成标准: 所计划的测试全部执行、 对以前版本的接口完成了回归测试、 所发现的高优先级缺陷和高等级的缺陷已完全解决。 需考虑的特殊事项: 开发人员应该保证每个后续的集成版本的基本界面元素都未改变。 考虑测试脚本的重用性以及自动化测试测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 容错测试 测试目标: 验证异常错误流程能顺利执行,并有易懂的提示信息 技术: 包含在上述功能和接口的测试用例设计中 完成标准: 对每一个非法的操作显示相应的错误信息或警告信息。 需考虑的特殊事项: 测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 回归测试 测试目标: 确保前一个集成的版本并未因为新版本的增量集成而带来缺陷。 技术: 在新的集成版本中使用前一个集成版本的自动化测试脚本执行自动化测试。 完成标准: 前一个集成版本的所用测试用例已全部执行。 所发现的缺陷已全部解决。 需考虑的特殊事项: 开发人员应该保证每个后续的集成版本的基本界面元素都未改变。 考虑测试脚本的重用性以及自动化测试测试方法描述 【此处描述一个特定的测试类型在项目测试活动中如何具体的执行。】 测试轮数 【根据集成计划确定的集成次数,计划整个产品开发周期内集成测试的次数】 测试资源 人力需求 【列出此项目的测试人员配备方面的需求。】  角色 人员 具体职责 测试经理 进行管理监督。 职责:          提供技术指导          获取适当的资源          提供管理报告 测试设计员   确定测试用例、确定测试用例的优先级并实施测试用例。 职责: 生成测试计划 生成测试模型 评估测试工作的有效性 测试员 执行测试。 职责: 执行测试 记录结果 从错误中恢复 记录变更请求 测试系统管理员 确保测试环境和资产得到管理和维护。 职责:管理测试系统    分配和管理角色对测试系统的访问权 数据库管理员 确保测试数据(数据库)环境和资产得到管理和维护。 职责:  管理测试数据(数据库)   测试环境 【列出了测试项目所需的系统资源。 】 资源 名称/类型 硬件和网路环境 数据库服务器 - 网络或子网 - 服务器名称 - 数据库名称 用户端测试 PC 包括特殊的配置需求 测试数据存储库 \\JJJ\Test\Data - 网络或子网 内部局域网 - 服务器名称 \\JJJ 测试开发 PC \\03824-1,\\02194-2,\\02336。 软件环境 DBMS 中间件 AppServer 浏览器 其它 测试工具 【本次测试将使用的工具】 用途 工具 厂商/自产 版本 测试管理 测试执行 缺陷报告 测试进度  【根据集成测试的轮次,分解测试工作,计算工作量(N:人数,M:工作日)。每一轮次任务均包括上轮次的回归验证工作】 编号 任务 工作量(人日) 开始日期 结束日期 制定测试计划 N*M 设计测试用例 执行测试(第一轮) 执行测试(第二轮) … 执行测试(第N轮) 最后一轮回归测试测试进行评估 合计工作量 交付物 【描述集成测试需要交付的工作产品】 交付物名称 责任人 参与者 交付日期 测试计划 测试用例 测试脚本 测试报告 。。。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值