夜雨聆风注册功能的代码还没写，可是测试工作却已经偷偷开始了。如果需求文档里已经写了手机号格式、验证码有效时间和重复注册限制等细节，这些就成了后面核对的依据。
测试人员这会儿没点那个还不存在的页面，是在思考：以后输入什么内容能成功，什么样的情况会被拒绝，系统应该反馈什么样的结果。
代码没影子，规则却早已拆成了三块
为什么软件测试工程师要提前把需求过一遍？程序代码虽还没影子，可是业务规则却早已拆解成了正常、异常与边界条件三块。
需求能不能被测试，关键全在于要确立那些明确、可观察、能验证的预期结果，不能只停留在“体验良好”“提示友好”这种没法直接核对的模糊说法上。
就拿注册功能来说，“手机号格式正确才能提交”这条规则，马上就能变成具体的检查场景：输入合规手机号，系统就放行进入下一步；输入格式有误，系统立刻阻断提交并给出对应提示；验证码一旦过期，注册流程就不能继续；若是已注册手机号再次提交，系统则按约定返回结果。
代码虽没出现，但何种情况该得何种结果的规则，却早已在那儿了。
需求模糊，测试人员会先把问题问出来
如果需求只是大概标注“提交失败的时候给出提示”，软件测试工程师就会发现信息不够用：网络一旦不能用，到底该提示网络问题，还是统一显示失败？用户如果不断地点击提交，系统是该忽略重复的请求，还是弹出等待的提示？验证码过期和手机号已经注册，是不是需要区分不同的结果？
这些问题，不是测试人员越权去替产品定功能。反过来，它们是在开发开始前，提醒相关人员一定要补全规则。毕竟，如果后面碰到模糊的要求，判断功能对不对就更难了。
把需求规则转成可验证条件，要留意几处关键
把需求规则转成可验证条件，要留意几处关键：输入到底是什么，允许的范围是什么；平常系统应该输出什么；如果碰到异常输入或者外部条件变了，系统应该怎么回应；一次处理完，用户或者系统接着能做什么。
需求分析阶段的测试工作，就是在测试范围、测试目标和具体验证内容之间来回折腾，给后面的检查打基础。
版本变动，验证条件也得跟着换
版本变动也要提前考虑。比如说验证码的有效时长，原先定的是5分钟，然后改版后变成十分钟了，那之前的失效条件、页面提示还有异常场景就得重新检查。如果注册限制从“同手机号不能重复注册”变成“允许重新激活”，之前的验证条件肯定不能再用原来的了。软件测试工程师得一直盯着规则变了之后，哪些检查点还能用，哪些得更新。
测试和编码，是两条不同的线
这项任务，虽然和软件工程师的编码工作相互交织，但发展方向却完全不一样。代码，是工程师把确定好的功能规则转化出来的；而测试工程师，通常会抢先一步，提取那些以后用来判断结果的标准条件。
对于规则冲突、异常情况，乃至可验证性问题，测试人员会一个一个提出来。可是，他们从来不为业务方做决定，更不会越权去设计具体的实现方案。
所以，软件测试工程师的身影，常常在代码完成之前就已经出现，甚至比页面出现得还要早。一旦需求变成输入、处理规则还有预期结果，要检查的对象就已经确定了。早点把这些条件理清楚，后面验证才有了根据，也能够防止功能弄好了之后，才突然发现规则本身还不完整。
拿着软件测试工程师职业技术证书，通常只是反映出你参与过哪些学习项目。它既不是企业测试岗位的录用硬性门槛，也绝对不会和软件测试职称或者各类认证体系相提并论。