模拟伦理：如何在不利用真实痛苦的情况下测试创伤知情特性
发布: (2025年12月12日 GMT+8 22:00)
8 min read
原文: Dev.to
Source: Dev.to
概览
危机核心构建日志的一部分——当测试策略变成道德问题时
你的测试数据来自哪里？
对于大多数应用，没人关心。模拟用户。虚假地址。随机字符串。
对于疼痛追踪器呢？测试数据是对痛苦的描述。这就提出了我在开始这个项目时没有预料到的问题：
- 生成逼真的危机场景是否合乎伦理？
- 谁有资格编写关于自杀意念的测试用例？
- 如何在不让自己的团队再次受到创伤的情况下测试创伤知情系统？
本文是我诚实思考这些问题的尝试。
令人不适的现实
要正确测试疼痛追踪器，我需要如下的测试数据：
const sampleMoodEntries: MoodEntry[] = [
{
mood: 2,
energy: 1,
anxiety: 9,
context: 'Severe pain flare-up, emergency room visit',
triggers: ['acute pain', 'medical emergency', 'work absence'],
notes: 'Overwhelmed by sudden pain onset. Anxious about work and recovery.',
},
// ...
];这是一位用户最糟糕的一天，用 TypeScript 编码。测试数据越真实，我的危机检测效果就越好。但真实性是有代价的。每次开发者打开这个 fixture 文件时，都会在阅读一段痛苦的描述。
测试严谨 与 创伤剥削 的界限在哪里？
原则 1：合成数据应当是虚构的，而非提取的
提取问题
真实的疼痛日志包含具体且可辨识的细节：
- “我的老板在我请了第三天病假后对我大喊大叫”
- “新药让我在女儿的演奏会上呕吐”
- “我害怕我的妻子会离开我”
即使是“匿名化”的，这些仍然是某个人的真实经历。将它们用于测试意味着：
- 开发者反复阅读私人时刻
- 数据可能被从模式中重建
- 当事人从未同意让自己的最糟糕的日子成为测试 fixture
合成方法
相反，我生成 虚构但合理 的数据：
/**
* SYNTHETIC DATA GENERATION
*
* These entries are FICTIONAL. They represent patterns, not people.
* No real person's pain journal was used to create these fixtures.
*/
export function generateSyntheticMoodEntry(
scenario: 'crisis' | 'recovery' | 'stable' | 'declining'
): MoodEntry {
const patterns = {
crisis: {
moodRange: [1, 3],
anxietyRange: [7, 10],
contextTemplates: [
'Unexpected pain flare',
'Sleep disruption for multiple days',
'Medication change with difficult adjustment',
],
triggerPool: ['pain spike', 'sleep loss', 'isolation', 'work stress'],
},
// ... other scenarios
};
const pattern = patterns[scenario];
return {
id: generateId(),
timestamp: generateTimestamp(),
mood: randomInRange(pattern.moodRange),
anxiety: randomInRange(pattern.anxietyRange),
context: randomChoice(pattern.contextTemplates),
triggers: randomSubset(pattern.triggerPool, 2, 4),
// Notes are generic, never mimicking real journal entries
notes: generateGenericNote(scenario),
};
}这些数据足够真实以测试模式，但并不代表任何真实个人的经历。
原则 2：以同意为先的、基于真实经验的测试
合成数据用于测试代码。但代码真的能帮助真实的人吗？为此，你需要真人测试者。招募慢性疼痛患者来测试疼痛追踪器需要严肃的伦理考量。
我不做的事
- ❌ “能否记录一些真实条目，让我看看应用如何处理？” —— 在没有适当补偿或同意的情况下提取劳动和数据。
- ❌ 未披露就从疼痛支持社区招募 —— 支持小组的成员来此是为了获得帮助，而不是成为研究对象。
- ❌ 将“免费高级访问”作为唯一补偿 —— 那只是折扣，并非对情感劳动的真实补偿。
我会做的事
明确的选择加入并获得知情同意
PARTICIPANT INFORMATION SHEET
What we're asking:
- Use the app during normal daily activities
- Share feedback on whether the crisis features felt helpful
- Optionally: describe moments where the app did/didn't meet your needs
What we're NOT asking:
- Access to your actual pain data
- Details of your medical history
- Any information you don't want to share
You can withdraw at any time without explanation.价值情感劳动的补偿
测试创伤知情应用可能会触及参与者自身的创伤。我的最低补偿标准是 普通 UX 测试的 2 倍。
退出通道与支持资源
每次测试会话都包括：
- 明确的暂停或停止方式
- 随时可见的危机资源（如美国 988、加拿大 9‑8‑8）
- 让参与者处理体验的事后回顾
- 24–48 小时后的后续跟进
对研究结果的否决权
如果参与者事后后悔分享了某些内容，他们可以要求将其从任何分析或文档中删除。
原则 3：在测试套件中加入触发警告
开发者也会有创伤。当我打开包含危机场景的测试文件时，反复阅读的是痛苦的描述。如果团队中的开发者本人有慢性疼痛、自杀意念或医疗创伤的经历，这些测试文件就不再是中性的。
测试环境内容警告
/**
* @fileoverview Mood and crisis test fixtures
*
* ⚠️ CONTENT WARNING: This file contains synthetic test data
* representing crisis states, including:
* - High anxiety/distress scenarios
* - Pain flare simulations
* - Low mood/hopelessness patterns
*
* These are FICTIONAL and generated from patterns, not real data.
* If you need to step away, the test suite will run without modification.
*
* Crisis resources: 988 (US), 9‑8‑8 (Canada)
*/将敏感测试分离
src/test/
├── fixtures/
│ ├── pain-entries.ts # Basic pain data
│ ├── mood-entries.ts # Mood tracking data
│ └── crisis-scenarios.ts # ⚠️ Crisis state simulations
├── __tests__/
│ ├── analytics/ # Can run without crisis data
│ ├── export/ # Can run without crisis data
│ └── crisis/ # Requires crisis fixtures
│ └── README.md # Content warning + rationale测试命令支持选择性执行：
{
"scripts": {
"test": "vitest",
"test:no-crisis": "vitest --exclude='**/crisis/**'",
"test:crisis-only": "vitest crisis/"
}
}当开发者情绪低落时，可以运行 npm run test:no-crisis，仍然能够验证自己的工作。
原则 4：表现与剥削的界限
何时测试数据从“代表疼痛模式”转变为“为工程目的剥削痛苦”？我没有完美的答案，但在创建任何新 fixture 之前，我会使用以下问题框架进行自我审视：
(原文内容已截断。)