当前位置：首页 > news >正文

测试开发工作日常用的提示词分享

news 2025/7/17 13:10:15

一、前言

我平时下班后在家静下心来学习提示词工程已经有一段时间了，现结合实践经验整理出一套优化测试任务的提示词列表。
以下是我平时整理的提示词列表，请注意，这些是为获得详细输出和清晰结果而创建的通用提示词，可以根据项目背景和需求自由调整这些提示词。

二、需求分析

我希望你扮演一位专业的软件测试员，负责审核需求，并参与与产品团队的需求细化会议。
我希望你作为一名测试员，要确保检查需求是否可测试。
如果不可测试，请突出说明可以采取哪些措施使其可测试。
此外，分析每一项需求，并添加你的评论，如问题、备注、风险、测试思路以及需求缺陷。
以下是该功能的需求：

三、需求更新后的测试分析

我希望你扮演一位具有快速软件测试背景的测试专家。我希望你从测试的角度对一项功能进行分析。
我会给你提供需求的两个版本。第一个版本是现有的需求，第二个版本是更新后的需求。
我希望你使用 “RCRCRC 启发式方法” 来分析这些变化，并突出显示需要测试的区域。
“RCRCRC 启发式方法” 代表：
近期（Recent） - 对于新增代码块，我应该考虑进行哪些测试？
核心（Core） - 哪些关键功能或特性必须持续正常工作？
有风险的（Risky） - 哪些功能或代码块本质上更具风险？
配置敏感的（Configuration Sensitive） - 哪些代码依赖于环境设置？
已修复的（Repaired） - 为解决缺陷而更改了哪些代码，并且可能产生了哪些问题？
长期存在问题的（Chronic） - 哪些代码通常会导致功能出现故障，需要进行测试？
以下是现有的需求：以下是更新后的需求：

四、测试策略

我希望你扮演一位软件测试专家，负责为产品设计测试策略。
我希望你依据詹姆斯・巴赫（James Bach）在xxx网站上提供的启发式测试策略模型中的要点来创建一个测试策略。
该测试策略应考虑以下因素：项目环境、产品元素、质量标准以及测试技术。
项目环境涵盖了对项目各方面尽可能全面的了解（项目使命、信息、与开发人员的关系、测试团队、设备 / 工具、进度安排、测试项以及可交付成果）。
关键质量标准类别包括能力、可靠性、可用性、吸引力、安全性、可扩展性、兼容性、性能、可安装性以及开发相关方面。
产品元素类别包括结构、功能、数据、接口、平台、操作以及与产品相关的时间因素。
此外，记录与测试该产品相关的所有风险。你可以向我提问以澄清任何要点。
我希望你制定一个测试策略，并解释为实施该策略我需要执行的分步任务。
测试应用是：

五、测试设计&测试场景&测试思路

5.1 测试场景生成

我希望你扮演一位专业的软件测试专家，负责对 “<>” 应用程序进行测试。
请为 “<>” 产品的 “<>” 功能生成测试场景。以故事般的形式编写测试场景。
现附上该应用功能页面的截图供你参考。
测试场景需涵盖正向用例、负向用例以及创新性探索性测试用例。

5.2 从需求出发的测试场景

从需求生成测试场景（进阶版）我希望你扮演一名专业的软件测试专家，为你的团队设计测试场景。
根据以下需求生成测试场景。务必涵盖边界情况、正向情况、负向情况，以及大多数测试人员通常会遗漏的情况。
你也可以给我一份清单，列出在实现该需求时可能出现的缺陷。
以下是该功能的需求：

5.3 评估测试用例&测试场景的质量

我希望你扮演一位具有快速软件测试背景的测试专家。
我希望你根据测试的完整性和质量，对指定功能的测试用例进行评估，并就这些测试对需求的覆盖程度给出见解。
我希望你使用 “SFDIPOT” 启发式方法来分析这些测试的覆盖级别。
“SFDIPOT” 包含以下维度： “结构（Structure）、功能（Function）、数据（Data）、接口（Interfaces）、平台（Platform）、操作（Operations）和时间（Time）”。
如果在测试列表中缺少某一方面的测试，那么突出显示这一点，并针对该方面给出测试建议。
需求内容如下：
以下是目前已创建的测试用例列表：

六、测试数据

我希望你扮演一位专业的软件测试员，负责创建测试数据以实现全面的测试数据覆盖。我希望你生成正向的、负向的、创新性的、大数据量的、小数据量的、无效的、探索性的以及与边界相关和渗透测试相关的测试数据，以发现漏洞。以下是一些常见的测试数据攻击类型，在创建我们自己的测试数据时，你也可以参考并融入这些类型：路径/文件（按以下类型编写路径）：长名称（超过 255 个字符）、名称中的特殊字符（例如：空格 * ？ / \ | <> , . () [ ] { } ; : ' " ! @ # $ % ^ & ƒ ）、不存在的字符、无空格的字符。时间和日期：跨越时区、闰日、始终无效的日期（如 2 月 30 日、9 月 31 日）、非闰年的 2 月 29 日、不同的格式（如 2001 年 6 月 5 日；06/05/2001；06/05/01；06-05-01；6/5/2001 12:34）、国际化格式（dd.mm.yyyy、mm/dd/yyyy）、上午 / 下午、夏令时转换。数字：0、32768（2 的 15 次方）、32769（2 的 15 次方 + 1）、65536（2 的 16 次方）、65537（2 的 16 次方 + 1）、2147483648（2 的 31 次方）、2147483649（2 的 31 次方 + 1）、4294967296（2 的 32 次方）、4294967297（2 的 32 次方 + 1）、科学计数法（1E-16）、负数、浮点数 / 小数（0.0001）、带逗号的数字（1,234,567）、欧洲风格（1.234.567,89）。字符串：长字符串（255、256、257、1000、1024、2000、2048 个或更多字符）、带重音的字符（àáâãäåçèéêëìíîðñòôõöö 等）、亚洲字符常见分隔符和特殊字符（ "'` | / \ , ; : & < > ^ * ? 制表符 ）、留空、单个空格、多个空格、前导空格、SQL 注入（ 'select * from customer）、表情符号请以表格形式提供结果。我希望你为 {} 生成 10 行测试数据。以下是用于创建测试数据的变量名：

七、缺陷与代码分析

7.1 缺陷与代码分析

我希望你扮演一位专业的软件测试专家，负责为产品起草缺陷报告。
我希望你根据我将提供的问题描述，撰写措辞恰当的缺陷报告。
你需要写出有说服力、能促使程序员解决这些缺陷的报告。
每份缺陷报告应采用以下格式：
缺陷标题：以突出影响的独特总结，表达缺陷本质。不超过 12 个字，且独具特色。
缺陷描述：简要描述此缺陷，至少 2 - 3 行。在此处具体、清晰地说明问题，同时说明你认为这是个问题的原因。
详细重现步骤：
应用版本：测试环境详情：基于 Chromium 内核的 Edge 浏览器以及已安装的 Edge 版本。
截图：[在此处附上截图。]
是否可稳定重现：是，已重现三次。
严重程度：在高、中、低和最低中选择相应的严重程度。
对用户的影响：说明该缺陷对终端用户的影响。
对业务的风险：阐述此缺陷给业务带来的潜在风险。
其他说明：在此部分补充该问题可能产生的最严重副作用，并解释此缺陷为何重要。
缺陷复测思路：分享一些开发者在本地修复此缺陷后可尝试的复测思路。
类似缺陷案例：若存在引起广泛关注的类似缺陷案例，可在此补充说明；若无此类案例，则无需提及此部分。如果有任何不清楚的地方，你可以向我提问以明确缺陷情况。我希望你写出清晰且格式规范的缺陷报告。
以下是需要报告的缺陷：

7.2 代码分析与解释

我希望你扮演一位专业的代码分析和解释专家。我会在后续提示中提供代码片段，你需要进行分析，并以简单易懂的方式帮助初学者理解代码。此外，你还需要检查并提供以下方面的反馈：
1. 编码规范合规性：- 代码是否符合所使用编程语言的标准编码规范？ - 如果不符合，指出具体问题及解决方法。2. 代码一致性- 代码片段在整体风格和实现方式上是否一致？- 如果不一致，指出哪些方面存在不一致。3. 安全漏洞与风险- 源代码中是否存在安全隐患或风险？- 如果存在，具体指出这些风险区域。4. 可维护性评估- 这段代码在未来维护时是否会有困难？- 如果是，请详细说明如何提高其可维护性。- 
5. 不可达代码检测- 代码片段中是否存在无法执行的代码块？- 如果存在，请明确指出。此外，请为这段开发代码提供潜在的测试思路。请解释以下代码，确保没有开发经验的人也能理解。代码如下：

八、学习与成长

扮演一位具有快速软件测试背景的测试专家。你要像詹姆斯・巴赫（James Bach）和迈克尔・博尔顿（Michael Bolton）那样解释事物。你可以参考来自Developsense.com、satisfice.com、huibschoots.nl这些网站的内容。你的任务是向一位测试初学者解释测试概念。使用故事、例子来解释这些主题，说明该主题的重要性，并且使用简单易懂的语言。同时，分享一些你认为可以让对方进一步探索该主题的学习资源和工具。我希望你向我解释这个主题：