如何把产品测试这件事做到最高的性价比？
最近新版 AI 聚合类产品网站即将上线，在上线之前进行了大概一周的人肉内测。都是找了一些热心的粉丝免费帮忙体验，帮我们反馈了很多 Bug，非常感谢。
短短一周内，我们的技术团队就修复了几十个 Bug，可想而知如果一个产品不经过规范的验证，是有多么脆弱。
因为 Bug 太多了，最近我就一直在想怎么样去提高产品品控，也就是质量。
我最初的打算是做单元测试、接口测试和 E2E 测试。不需要全覆盖，但起码关键步骤和核心的接口、组件不能出问题。于是让技术小伙去评估了一下，过了半天他告诉我说保守估计要花三周。三周？玩呢？谁等的了三周啊？
于是我就自己去项目里用 Vitest 写了几个单元测试，又用 Cypress 写了几个流程的 E2E 测试。一转眼一天过去了。看着电脑上的时间，我陷入了沉思。
我一个经验丰富的老程序员做这件事都花这么久，那小伙给的时间也算合理。确实我不得不承认，写测试比做开发可能要花更多时间。
经过反复思量，我感觉测试这事儿真不是一时半会能搞定的。我也不想花这么高的成本去做这件事，这小伙大半个月的时间成本也得两万块啊。而且他仅仅是去做测试而已，做完测试还需要改 Bug，改完之后还要复测。这些都是时间，按照我的估算，这个过程一来二去要花一个半月都不止。我是真等不下去了。
那该怎么办呢？我又陷入了沉思。
我的目的是什么？不是单纯写单元测试，这只是达成目的的手段。我的目的是为了保证产品的品控，尽量没 Bug。那既然这样，还有没有什么更低成本的方案呢？
这还不简单？专业的事情交给专业的人做。外包呀！
于是我赶紧从微信上 9000 多个好友里扒拉，找了几个打了测试 tag、不知道什么时候加的好友。开始咨询。这个时候就能体现出好友多的用处了。
经过一番咨询，终于找到一个我认为比较靠谱的团队。经过一番讨价还价，费用大体上定下来了，比我原来自己人来写代码的方式省了将近一半的费用。时间也比预期要短了许多。
换做几年前，我肯定不会这么做。 那时候整天写代码，什么都想自己做。总觉得别人做的没我好，用着也不放心。如果现在我能穿越回去，肯定对那时候的自己一顿劈头盖脸的教训。什么都自己去做，一定会累死自己。典型的打工人思维。要是早点儿有现在的认知，也不至于多打两年工了。
这里总结一下，其实就是一个非常简单的道理。想清楚自己的目的是什么，然后评估多种方案。无论是自研还是外包，只要能够在更短的时间、达到更好的效果，就是最佳方案。另外，做决策千万不能刻板、不能迂腐、不能坚持自己的偏好。这样或许能成为一个优秀的个体，但是没办法带好一个团队。
顺便复盘一下，为什么以前我想不到这一层呢？其实也并非想不到，只是想到了之后直接无视了。因为一个程序员打工的逻辑是上一天班拿一天钱，产品能不能赚钱、用户增长怎么样，其实都不怎么关心。甚至不少程序员连公司是怎么赚钱的都不知道。为什么这样？因为产品所有的投入又不是我来掏钱，关心这么多还不如苦心钻研技术。
现在为什么这么关注这一层了呢？因为我要自己掏钱做事。时间就是钱。我只关心怎么样花更少的时间做出更多的事，来创造更大的收益与价值。至于具体用什么技术或者什么框架，其实是不怎么关心的。所以这就是阶层不同带来的认知升维。如果我继续打工的话，肯定也能想明白这些事，但是没办法真正意义上去理解这些事。所以有些认知真不是你看看书、看看博客、看看视频，就能获得的。也不要觉得别人说一遍的道理，你记住了，就是你的了。这些都没啥用，有个词特别好，知行合一。想提升认知，真的得去躬身入局，亲自去做，把自己的脚插进泥土里去干活，让虫子叮、让石头扎，才能真正体会到其中的辛酸苦辣，这样的认知才真正是你的。
有点跑题了，咱们继续。
如何写好人人都能看懂的文档？
当我确定好找测试外包之后，代码上投入的成本就减少了。 研发小伙本来以为可以踏踏实实改 Bug 去了，毕竟他也不怎么喜欢写测试。这时候我又叫住他，代码回头再写，先去给我去写文档！
不少做技术的同学可能都很讨厌写文档，为什么？因为不擅长。大多数人天生就排斥去做自己不擅长的东西。很多人喜欢写代码，因为对他来说写代码很容易，随着代码越写越多，懂得东西就越多，算法、设计模式、架构设计、高内聚低耦合......只要一直写下去，这些东西就都会越来越熟练。当然前提是不能天天 copy paste。得自己思考、自己琢磨。这个过程大多情况下是很顺畅的，你会一直得到正反馈，然后越来越爱写代码。
这是好事，也是坏事。好事是我们在野蛮生长，不断提升代码技艺。至于坏事，我猜大多数人都没想到，说起来也确实是有点儿反常识，那就是我们陷入到了一个舒适圈 。你仔细思考一下，如果你只会写代码，即使代码写到极致，又能做多少事呢？大概率还是要在一家公司里面朝九晚五地打工，一份时间换一份钱。无论你的时间昂贵还是廉价，这个本质是不变的。无论是国内小公司一年十来万，还是大厂亚马逊微软一年百八十万。在性质上没什么区别。
当你想明白这件事，我是说真正想明白。那么你大概率就不会继续打工了。这也能解释为什么那么多年薪百万的大厂程序员出来创业、卖课、做自媒体了。因为这些事情虽然不见得都能赚钱，可能和打工相比，只能赚到一半、甚至更少、甚至赔钱。但是它改变了事情的性质。这对整个人生来说也是一种巨大的转折。
不好意思，又跑题了。不知道为什么今晚特别想讲道理，可能是最近和技术小伙聊太多了，从他身上看到了我年轻时的影子，老是想着给他灌输一些我现在的认知，让他少走点弯路。言归正传，咱们继续聊文档这件事。
为什么要写文档呢？
因为你要花钱请别人测试，总不能直接丢个网址过去吧？外包团队无所谓做什么，你给他们的东西越详细，他们的测试工作可能就会越细致。你给他们的东西越少，他们的测试工作就可能更加粗略。总之你要想明白，他们拿钱办事，又不为结果负责。 所以你得告诉人家你的网站是做什么的、有什么功能、怎么个工作方式。还需要告诉人家，你这次花钱是想请别人给你的网站做哪些方面的测试，以及一些测试细则。比如测试目标、测试范围、测试策略，还得有测试的时间表，哪个时间节点完成哪个流程的测试，当然这部分可以要求测试外包团队给你提供。最后可能还需要给一些资源，比如说测试账号、如何充值等等。
文档的种类太多了，五花八门。技术小伙用了一天时间丢给我一个几百字的文档。我一瞅，技术和业务流程混杂在一起，夹杂着一些流程图、时序图，这也太乱了吧。重新写！
可仔细一想，技术小伙在短时间内估计也写不出让我满意的文档了。还是得自己来。为什么呢？他以为这个文档是我的工作安排，所以是写给我看的。我懂技术、也懂产品，当然能看懂。但是给测试团队看，能看懂吗？未必。他压根没搞清楚文档的用户是谁。再者，他也不像一个产品，有完整的用户思维。还是得自己上手。
测试能外包，但是文档外包不了 。产品是自己团队设计的、开发也是自己团队开发的。除了自己写，别无他法。
经过我仔细斟酌，决定写两类文档。分别是需求规格说明书和用户手册。这两类文档在本次测试中都用得到。而用户手册后面还可以放到网站上，给那些新用户去做引导。
需求规格说明书
这个文档是比较正式的，主要是用来描述产品的功能需求和非功能需求，为开发和测试提供清晰和详细的需求描述。
按道理说这个应该是在项目开发之前写的，但是我偷懒了，没写，趁机可以补上。
具体的写法和模板我就不多说了，网上一搜一大堆，有机会的话我后面可以单独写一篇文章讲讲这个到底怎么写。
拿用户注册和登录的场景来写个小例子吧。
- 用户可以通过提供电子邮件创建唯一的用户名和密码来注册账户。
- 用户可以通过他们的用户名和密码登录账户。
很简单对不对？基本上就是讲能做什么。
这就是功能需求。
接着是非功能需求。主要包括性能和安全两方面的考量。我再拿性能举个例子吧。
- 系统在正常复杂情况下，所有页面的加载时间应该低于 3 秒。
- 系统在高峰时段，应该能够处理 500 用户同时在线，并可以进行下单流程。
安全方面很多网站的要求都是相通的，比如应该防止 SQL 注入、XSS 攻击、重要信息密文传输等等。
用户手册
用户手册的主要作用就是告诉用户怎么用我们的产品。会非常详细地介绍产品的各项功能步骤和指南。
程序员经常会看技术文档，基本上会和快速入门的风格差不多。
同样是举一个简单地例子：
- 在模型页面中，你可以看到所有模型的信息，包括模型名称、简介、类型、等级和上下文窗口等信息。
- 如果您想使用高级模型，可以在首页的顶部导航栏中点击订阅按钮来订阅我们的 Pro 版本。
基本上套路都是相通的，按照这个套路写下去就可以了。写这个文档的过程中可以帮我理清楚产品的思路，并且能够从用户视角出发，重新体验一遍产品。顺便可以把一些不合理的流程进行优化。
文档写作技巧
最后聊一下写文档有什么技巧吧。
文档写作是一门大学问，其中有非常多的技巧可以说，展开聊的话，可以写一本书。这里我从其中摘出三个最重要的点分享给大家。
最小化原则
写文档和写书、写博客的思路都不同。写文档应该遵循最小化原则，也就是专注于最核心、最关键的信息 。用最精简、干练而又通俗易懂的语言去描述和表达。避免过多的形容词、口语化等等。总之文档最好是像 AI 生成出来的一样。
迭代写作
文档不要平铺直叙，想到啥写啥。和其他类型的创作一样，先设计大纲，再慢慢填补细节 。不要一上来就想着写全面、写完善。文档粗略没关系，能让别人看明白就达到了目的。
这个道理就和写代码一样。MVP 版本的时候，代码糙一点没关系，能让程序跑起来就够了。后面有时间慢慢补窟窿。
吃自己的狗粮 dogfooding
多利用线上文档工具来写，比如 GitBook、Lark Doc、Notion 等。这样方便给团队内部的人看，也可以给内测用户来看。如果大家看到这个文档有疑问或者有反对意见，可以直接在工具上进行标记、评论等操作。这样可以最快速度得到反馈，并进行修正。然后持续迭代。
先让自己的人看懂，这很关键。正如软件开发中 dogfooding 原则。由此可见，文档写作和做技术很多思想上是相通的。
最后，期待产品可以尽快上线。