02 A — 属性：形容词框定测试目标
什么是你听到"这个产品"之后，最先冒出来的三个形容词？
如果是 Chrome："快、稳、安全。"\ 如果是微信："方便、封不掉、熟悉。"\ 如果是 RedPen："轻量、简洁、可定制。"
这三个词，不是评论——它们是测试的出发点。
开篇除恐
"属性"听起来很像 UI 设计师的活，跟测试有什么关系？
关系大了。属性告诉你要给产品把关什么。"快"这个属性背后的测试问题是：快慢的界限在哪里？低于这个界限算不算 bug？"安全"背后的问题是：什么信息不该被别人看见？\ 你把属性列出来，测试目标就自动清晰了。
只不过它用了形容词，看起来不像"测试用例"那么严肃。好——这就是它难被认出价值的原因。
白话化
A — Attribute（属性）
属性是产品的性格。
- 形容词是你的直觉读法。"这台电脑轻"和"这台电脑运行快"说的是两件事。前者是重量属性，后者是性能属性。
- 同一产品的不同用户对属性的排序不一样。重度编辑用文本编辑器，关心"流畅"；轻度用户可能更关心"好看"。
- 一个测试团队不可能一次测所有属性的全部疆域。属性越少，目标越清晰；属性越精炼，越容易讨论"哪些测到了、哪些没测到"。
规矩
- 属性必须是可验证的形容词，不能用"好""不错""棒"这种笼统的表达。"很方便"→可以更具体："三步内到达发消息界面"。
- 完美的属性集通常在三条到七条之间。少于三条显得随意，多于七条会失去焦点。
- 属性叫 Coefficient 更好理解：产品因为那几条形容词，才被叫做它自己。
属性 vs 其他视角的关系
| 想象 | 对应的 ACC 视角 |
|---|---|
| "我想让笔记本开盖即用" | A — 属性（"快"） |
| "它有一块固态硬盘" | C₁ — 组件（名词） |
| "它能启动" | C₂ — 能力（动词） |
属性回答的是 "什么样"，组件回答 "有什么"，能力回答 "能做什么"。三者缺一，地图有一块空白；合在一起才有满格的可能。
直觉先行
随便拿一部你的手机，现在，写下三个你在推荐它时会用到的形容词。
这三个词，是你脑子里"它是什么"的速写。不需要解释为什么——对你来说，那三个词本身就是原因。
"iPhone——流畅、耐用、贵。"\ "安卓备机——便宜、能装、电池大。"\ "Kindle——轻、省电、护眼。"
每一组形容词，都自带一套测试议程：
| 你写的形容词 | 它自带的测试问题 |
|---|---|
| 流畅 | 滑动一页需要多久？打开大文件会不会卡？ |
| 便宜 | 定价边界在哪？促销导致的价格归零会怎样？ |
| 轻 | 以克计的重量，合不合格标准是多少？ |
| 耐用 | 摔过之后怎样？掉电快不快？边框容易掉漆吗？ |
好。你刚刚自己做了一次"属性到测试问题"的推导。这就是 ACC 的第一步。 不需要教科书，你做到了。
例子贴身
☼☼ 正经：RedPen 的核心属性（自编）
RedPen 是一款虚构的开源 Markdown 编辑器，设计目标是为有主题和插件改造需求的用户服务。它的三位创始人（虚构）在 README 里这样描述产品：
RedPen 是轻量的。启动时间在 50ms 以内。\ RedPen 是可定制的。主题和插件由用户自行安装。\ RedPen 是协作友好的。支持多人同时编辑同一文件。
对应这三个属性，测试议程可以这样写：
属性：轻量
- 冷启动的基准：打开一个空白文件，50ms 内光标就位。
- 大文件下限：10MB 的 Markdown 文件，反应速度出现肉眼可识别的卡顿阈值在哪里？
- 内存占用下限：空闲态下 RAM 上限是多少？超过这根线，算"不够轻量"。
- 插件数量对启动速度的影响：0 个 / 5 个 / 20 个，三条基准线。
属性：可定制
- 用户自写脚本能不能热加载（不需要重启编辑器）？
- 破坏性改动会不会白屏？
- 第三方插件之间是否互相屏蔽？
属性：协作友好
- 两个人同时改同一段文本，最后的合并结果有没有丢字？
- 网络断开三十秒再恢复，两端同步是否正常？
- 对冲突的检测与提示：用户能否清晰知道"这里两个人改了什么"？
这三条测试议程加起来，就是 RedPen 在"属性"维度上的测试覆盖地图。\ 这张地图现在还是空白——我们后面要填它。（第五章会回来。）
如何判断属性"够好"
一个属性值不值得保留，用两个问题检验：
- 如果我把它从产品描述里删掉，产品会不会少一点骨骼？
- 我能描述出"不满足这个属性"的样子吗？
两个答案都是"是"——这条属性留。
☼ 热身：给你常用的 app 测一测重量
打开任何一款你每天用的 app（微信、浏览器、笔记软件都行），做以下练习，时间不超过三分钟：
- 在脑子里说三个你在向别人介绍它时会使用的形容词。
- 每个形容词，试着写一个对应的测试问题（就是"怎么验证它"）。
你用了什么形容词？它们对应的测试问题是什么？
☼☼ 正经：当两个属性冲突时
（自编）
RedPen 既要"轻"又要"可定制"。
- 要"轻"：插件数量增加，启动时间随之增长，且这可预测。
- 要"可定制"：插件多到一定程度是好事。
这两件事天然有拉锯。\ 测试怎么办？
不解决矛盾——暴露矛盾。 测试的任务不是"让两个属性都达到最优"，而是度量这个拉锯，把它变成可读的数字。
这把尺子要刻在 README 里：\ "RedPen 插件的实际影响：每个插件约增加 X ms 的冷启动时间。"\ 用户读到这句话，他会自己判断——这个 X 值得不值得。
属性测试的最高境界：让用户在决定之前，拥有足够的信息做自己的判断。 你测的不是"对不对"，是"值不值"。
这一章要带走的东西
- 属性 = 形容词 = 产品的性格，它为测试圈定"什么值得测"
- 属性必须可验证，用"不满足它会怎样"检验
- 属性之间会对立——测试的任务是度量和暴露，不是消除矛盾
- 好的属性集在 3–7 条之间，少而精
就这样。