我啥也不会，但我得带你去医院。 别跟我谈那些“软件测试工程师是做啥的”这种开场白。你在医院门口应当已经见过一个穿着白大褂、手里拿着听诊器，对着一个病人满嘴“呃”、“啊”的医生了。软件测试也一样，别整那些花里胡哨的“黑盒测试”、“灰盒测试”术语，那是医院里医生给病人开的处方，不是你该学的药方。 咱们直接上药方。
你想自己测？行，先把手伸进锅底下看看。你又不是硬件工程师，你连电路图的源头都不知道，如何测？你连如何点击按钮都不知道，如何问用户“你点哪儿了”？测出来的是个鬼，还是个能把自己煮熟的包子？这时候你要么死磕到底，要么拉倒。 那就对了。你得先学如何“问”。问啥？问业务逻辑。业务逻辑就是用户如何在系统里“发疯”。 比方说你要测登录功能。别光想着如何配数据库。你要站在用户的角度，问他：“你上完班累死了，进门都带啥？”“你密码输错三次，手机会不会响？”“你看到验证码了没？”“你怕被记仇，是不是想把电脑锁死？”你把这些场景列出来，再对应到代码逻辑上。你这样问，用户要是还是认定不中意，那就是你问得不够细，不是你们代码写得烂，是用户忒复杂。
这时候你得像个经验丰富的老大哥，耐心听下来，直到把用户的痛点摸透，别光想着如何通过测试用例把代码敲通。 再比如测试流程。别当作写完代码就是测完。写代码是造房子，测是找虫子。你脑子里要时刻挂着“我在造啥”，而不是“我写得如何样”。 举个具体的例子。有个哥们儿写了一个好办的聊天框，小哥问我：“你测啥？”我说：“测输入、测试、发送、显示。”他点头：“那要是别人发个表情如何办？要是对方图床挂了如何办？”我这会儿就慌了，赶紧去查资料。查资料不是为了背“超时处理”、“并发压力”这种大词，是为了让他理解“大家发东西的时候，系统会不会崩？”“用户会不会出于没反应就漏水了？” 这时候就得启动练手了。别去那种几千块的小公司，去跟一个老板谈钱，问他：“这项目能上线吗？”老板说：“能就上线，不能就不，别给我找借口。”老板的心态挺关键，你要是拿着“要是形成 A 情况我们就用 B 情况做测试”的借口去忽悠他，他根本不会让你动手。你得拿真的数据、真的流程，去验证他的逻辑。 比如你要测一个“提交订单”功能。别光看需求文档里写了啥。你去真操作一次：先填个名字，再填个电话，再填个地址，最终付款。数据填得跟发票差不多，但文件名叫“客服单据”，让你填个“真姓名”，你填个“工号”。 PK 启动。你要是发现系统报错，别急着改代码。先问：“为啥是‘客服’而不是‘姓名’？”“为啥是‘工号’？”“是不是出于发票的备注栏忒长了？”你通过这种荒谬的测试，能发现需求里根本都没想清楚的地方，那些细节要么被埋了，要么被改了，要么根本没定义。 这个过程里，你会遇到大量枯燥的重复。
比如每天对着同一个页面，点点点，点错了，再改回来。你会认定自己在重复劳动。但你要明白，软件测试不是做 PPT，不是做设计图。是做验证的。验证。验证。再验证。 你要学会如何“问”。用户想测？对，就问他。业务逻辑不对？对，就让他说。逻辑没定义清楚？对，就让他填。你越能听懂用户的每一个字，你的测试用例就越能击中要害。别总想着把测试变成“测试”。 自然，光靠嘴皮子不中。你得有工具，但工具要是装得慌，那还是老样子。你得学会如何利用现有的工具，比如有没有现成的测试框架，能不能快速写个脚本跑通个流程。别总想着自己从头造轮子，那是为了造轮子造轮子，为了造车造车，要不就你是造车的标准件，否则没必要。 还有啊，别怕出 Bug。出了 Bug 你直接改代码修回去，那叫开发。
要是你发现了 Bug 没修，还在测试报告里写“待验证”，那叫测试。你得把 Bug 当成自己的责任，当成你的勋章。
哪怕 Bug 是写出来的，你也要把它当成自己的案子。 最终想说，软件测试这事儿，实际上挺累的。你每天被各种琐事缠住，得处理需求变更，得应付各种怪的考试，还得在那儿写各种乱七八糟的文档。但当你真正懂业务，当你确实能跟用户聊到半夜，当你能一眼看出系统哪儿不会讲话时，那种成就感是任何证书都给不了的。 别被那些所谓的"PMP"、“软考”给吓退了。
那些东西就像给病人开处方， prescribing medicine。药方不对，你别吃。你得自己找药方。 你要找个能跟你一起骂的搭档，要么找一群能跟你一起查 Bug 的同行。大家伙儿看着一起去，互相吐槽，互相请教。别一个人闷头写代码，没人听你讲。 好了，今天的药方就到这里。去医院，找医生，问用户，查资料，动手操作。别想那些虚头巴脑的，就实实在在做。 测得准，系统才稳。测得准，Bug 才少。测得准，你才像个真正的测试人。 记住，别总想着“测试”这四个字。你要记得，你是来解决难题的。别把难题留到上线那天，那时候系统崩了，你连补救的资格都没有。 别去管那些“最佳实践”和“行业规范”，那些都是老古董。照着做，就能活。 行了，趁热打铁。找个机会，去现场，去问人，去测。别等别人骂你。你自己算好账，然后干。 测完项目，别急着写报告。先复盘。你发现哪儿怪怪的，哪儿让用户吐槽了，为啥系统没崩？把这些细节记下来。别只写“逾期处理”，要写“用户怕逾期被记仇，可能想把电脑锁死，系统没等响应就报错了”。 这就是测试人的活儿。脏，累，但能写得挺有趣。 别怕，你不怕。你只管问，只管测，只管把那些让你头疼的、让用户头疼的、让你自己头疼的逻辑，一个个揪出来。 最终，祝你早日洗白，早日成为那个大家都愿意问：你测了啥？你测错了啥？你咋解决的？的测试人。
