对于固定场景的验证，有预期的输入和输出，无论是接口测试还是 LLT （底层测试），都是具备这个特点。测试人员的重点是将具体的场景抽象为自动化用例，提升回归测试的工作效率。对于基于 UI 的自动化，因为产品可能存在较大变动，UI 识别也存在部分确定性，我们可以量力而行或尽可能抽象为接口自动化。在自动化工作中，测试要对开发有足够的可测试性要求，产品具备良好的代码解耦的架构。
对于未知场景的探索，主要是针对没有对应测试设计的测试驱动。可以分为工具类的自动化探索，例如我们手机可靠性测试使用的 monkey，以及安全测试的 fuzzy 等。测试的场景由工具生成和决定。另外一种是人工的探索测试，这个概念近几年也比较盛行。但个人认为这种在可行性上还是有一定难度，对测试人员的经验要求较高，目前我们也并没有组织，主要通过 Beta 测试，引入大量普通用户完成各类场景的探索。
任何测试都是不能 100% 发现问题，网上问题的发生也是很难避免，测试需要尽量降低网上问题的级别和发生概率，并且需要具备较高质量风险防范的意识，对于高风险产品必须有双重（或三重）的防范机制。例如我们做一个支付类产品，可能会在存在某些质量问题，导致用户未支付的情况下，支付状态进行了更新（这个例子可能大家感觉不会出现，但是现实中有各类可能）。测试人员必须对产品提出，有额外的管控系统，对账号进行准实时的核查比对，确保收支一致。互联网有过类似的安全，2012 年某东积分兑换 BUG 的问题轰动一时。好的测试专家需要像扁鹊大哥一样，尽可能的识别和规避可能的质量风险。
测试人员的技能模型应该保持多样性的发展，在广度方面不断延伸，深度方面可以选择一两项技术进行不断挖掘。有三点需要测试重点关注：
编码能力：特别对于新员工，这个能力是与开发有共同语言的基础。测试人员需要了解对应业务的代码框架，构建工具，以及 LLT 测试，持续推动开发过程中的改进，能给予代码提出测试建议，将质量构建在开发阶段。
组网能力：测试需要对系统的组网，以及实际的部署情况有清晰的技术理解，这样才能发现更多的质量问题和隐患。这个说起来是比较简单，但是如果做到深入的了解，还是有很高的技术难度，例如我们现在各个业务使用的 CDN 和 DNS，如何组网可以让我们的系统体验会更快更好。用户使用的 UC、QQ 浏览器等是具备缓存加速，在缓存场景下是否会对某些业务特性产生影响。
业务能力：测试不能脱离业务，这也是为测试人员未来转型产品经理或其他岗位的一个必备能力。无论开发还是测试，能在整个职业生涯中，坚持到底的，是少之又少。大型产品线如有测试系统部之类的部门，如果脱离业务，纯粹投入技术规划或流程规划，往往会逐步被产品边缘化。
产品会有各类的隐患和问题，测试人员如果长期只发现简单的 BUG，不仅会让技能水平下降，而且会失去对工作的兴趣，我们只有通过工具或技术不断解决问题，才能挖掘测试工作的乐趣。
