业务测试是根基
　　产品测试的需求跟人的需求一样， 也是分层次的.
　　业务测试肯定是第一位的. 是产品基础. 围绕业务会有很多的衍生需求， 比如性能 安全 稳定性 兼容. 但是首要的还是业务功能.
　　与其他需求一样 业务功能也是存在可被模型化和技术化的. 产品的衍生需求大多都已经是实现了现代化的检测. 而唯独业务正确性未实现. 这是有很大的历史原因在里面. 我觉得限制主要来自于两个方面.
　　· 第一个是业务的正确性无法被很精细化的模型化. 这种复杂性算是alphago也搞不定， 而且每个领域的模型还不尽相同.
　　· 第二个是做业务测试的人大多没技术属性. 导致业务测试的技术发展不足.
　　业务的建模
　　业务的本质是个处理流程， 你可以认为是一个巨复杂的函数. 从数学上讲是一个输入到输出的映射
　　class 业务{
　　public 业务模型类  def 业务流程(业务输入数据){
　　处理业务
　　return 业务输出数据状态
　　}
　　}
　　复杂度体现在两个层面.
　　业务的数据模型复杂. 典型的业务比如民航订票 股票基金交易 航天飞机. 里面的物件和物件属性很多.
　　业务的流程模型复杂. 典型的业务比如搜索引擎 机器学习算法
　　人脑也是一种计算. 大多数业务正确性， 人能够验证正确性是基于历史数据过多而逐渐学习出来的.
　　以前有人提一万小时的领域专家成长的时间理论 其实是基于数据不断的学习进化的过程. 说明人脑的计算速度是这个瓶颈了.
　　这个过程同样也适用于计算机. 前几年Google通过机器学习+数据训练也让内部的一个服务器集群成功识别出了它以前没见过的新事物. 参考猫脸识别 http://36kr.com/p/122132.html
　　很明显高大上的技术在十年内还是难以普及的， 不过有些简单的科学方法还是可以利用起来来改进业务测试的.
　　业务测试的技术化改进
　　业务的流程和数据模型肯定是存在的 他存在于产品的脑子里， 形成于研发的代码， 并应用于用户身上. 所以三个维度都能做到对业务的建模并识别正确性.
　　第一个维度是产品层面的业务建模， 这是过去几十年我们测试行业采用的办法. 根据产品文档写用例 根据研发代码流程补充细节用例， 根据用户投诉和线上故障来补充用例. 这个几十年没变过.
　　第二个维度是研发的代码. 如果你把代码的演变和执行流程都统计下， 你会发现任何程序都是一种生命体. 他可以进化， 业有瑕疵. 甚至是崩溃. 对代码的建模行业里面也有人在做了. 做法是如下的几种
　　· 静态分析
　　· Code Review
　　· 单测
　　这几个层面主要是想在底层做一些基础的质量保证， 并尝试把复杂的模型分拆验证. 但是他无法很好的做到全局正确性的校验.
　　第三个维度是线上产品监控， 使用的技术主要是
　　· 代码埋点
　　· 字节码插桩
　　· 特定语言的debug trace和hook技术
　　典型的应用场景比如Bugly崩溃分析 Flurry GrowingIO业务流程分析 友盟的运营监控. NewRelic听云 OneAPM性能分析产品兼具部分的业务分析.
　　这个层面的产品和发展非常的迅猛， 因为他迎合了业务分析+大数据+云计算多个东风. 导致已经非常成熟的应用起来了. 但是还不能完全做到质量正确性验证. 比如因为某个bug. 用户的资产算错了. 这个这些系统都检测不出来.
　　第四个维度是数据建模分析， 可用的技术方案是
　　· 数据采集. 包括建模的各种属性
　　· 规则分析. 根据业务模型指定简单的规则去扫描问题
　　· 机器学习. 不借助于任何规则. 通过训练数据学习出哪些是bug和正确的功能.
　　实用的业务测试策略
　　根据产品完善测试用例仍然是第一位的. 所以你需要有一些扎实的业务测试同学.
　　因为业务的策略大部分都埋藏于代码中， 很多雷也埋在其中. 纯靠粗略的产品需求你很难覆盖到足够多的场景. 所以你需要用code review或者其他的工具作为弥补. 来挖掘代码中的业务实现.
　　埋点与字节码插桩. 这个技术已经是非常的成熟了. 了解用户的业务场景并完善你的用例是非常有用的. 而且还能做到精简你的测试用例