额。。。所以最终的结论是？做业务的时候不要从开发的角度去思考问题。那如何平衡技术和业务两者呢？

我个人做业务的时候倒从来不去想怎么实现的，我更喜欢从体验角度，但其实也不是真正业务方想要的，更多的只是我想要的。＝ ＝。。

不过另外一点我觉得 TDD 和 BDD 不是这个区别啊，不在一个层面上的事情。。＝ ＝

其实，真的很难去平衡的，而且，因为有着技术情怀，你对于一些重复的事情根本就不再想去动手，一心只想自动化实现，却不去管到底有没有必要。

#1 楼 @monkey 没有结论，我还比较困惑，而且思路比较涩，写不下去了
TDD 考虑代码实现对不对，BDD 考虑业务实现对不对。

业务这东西真心蛋疼，过于偏感性了
除了需求以外的，好还是不好都是个人偏好，想要说服开发的时候都不知道怎么说更容易让他们愿意改
不像专项的东西都是有明确指标，用例执行也只有过或者不过，不是 0 就是 1

业务测试是根基，并且贯穿始终，专项、自动化这些是业务基础部分已经打好，或者规模已经发展到另一个层次，业务上有了更高的要求，从而在成本，时效上权衡出的产物，与业务测试并不对立。

技术是为了服务业务，更好的支持和驱动业务，两者不需要分开谈。

技术情怀要有的，但脱离业务谈技术容易陷入技术情节，人或事情本身可能会出问题。

经验不多，专意听教。

技术实现基本上是为业务服务的，业务测试是必须的

测业务的时候定位的问题自己都知道怎么改不是一件很欢乐的事情么，至于会不会影响到其他模块，反正也不是真的给我改:)

偶也是程序猿出身的测试人员。@skytraveler 写的很好了，其实我们面对业务理解和学习的过程都是一致的，解决问题和学习的能力有了接触新的业务也会很快。对 bug 的敏感度也是能力的体现，不分业务的。

业务测试最痛苦的是 我这边刚理好所有的业务逻辑、第二天所有的逻辑都变了、不是部分 是所有的

#10 楼 @cathy 从流程上做优化是可以从很大程度上做到减少返工的。测试不是被动的按照需求设计用例，发现需求和设计中的问题也是测试的一项重要工作。建议了解一下敏捷和精益，还有软件开发过程相关的一些知识。
参考书：
实例化需求
http://item.jd.com/11073791.html
用户故事与敏捷方法：
http://item.jd.com/1695419808.html
scrum 敏捷软件开发
http://item.jd.com/10400883.html
看板方法
http://item.jd.com/1702705156.html
软件需求最佳实践
http://item.jd.com/11224645.html

@xdf 我觉得任何测试都是业务测试，因为都是面向用户面向需求的。 只是测试的手段不同，有的适合使用黑盒，有的适合自动化，但目的无非是一个"让用户用的爽"。 所以， 我也不觉得有 “技术情怀” 这么个概念。就好比需求是制造一个凳子，最重要的是凳子质量过关，坐的舒服，符合用户需求。 至于是手工打造好，还是通过制作生产线来提高生产效率好，完全看情况。
我觉得测试就应该懂技术，懂代码， 这不是情怀， 是基本功

我觉得业务应该是团队任务~cross PM&dev&test&UI team.

看产品性质吧，像 iphone 那样的产品老乔当时肯定是把技术排在需求后面的，“劳资不管你怎么做怎么实现，反正就要达到这个样子！”

—— 来自 TesterHome 官方 安卓客户端

业务的确是很繁琐的一个工作，开发往往会陷入如何实现从而忽略结果，老板盯着结果但忽略实现的艰难，但是测试应该是从 0-1 都需要关注，任何一个步骤出错都会随时一个黑锅下来；
关于如何更好理解业务理解需求也是没 sei 了，（O2O 同城服务，只能各种脑补）因为我公司没有需求文档没有 PRD，各种文档都没有，开发都是看着 UI 图做的，靠的都是口口相传（不是敏捷团队），怎一个累字了得~~

#15 楼 @mr_zeng 领域专家之殇

#8 楼 @skytraveler 在业务和技术之间权衡，我这两年偏重了自身的发展，对于业务点到为止，想来也是挺自私的。公司其实需要大量的业务测试来牺牲，从而成就业务。

#17 楼 @lihuazhang 不叫自私的。就个人来说，肯定是个人发展最重要啊，这没什么可说的。其实大部分的时候个人发展和公司发展能结合到一块儿。如果发现真的被消费了。两个选择，选取 smart 的方式规避；走人。

我估计很多社区里的人都和楼主有相似的感觉——当得到一个测试任务后，总爱对问题进行深度优先遍历，究其开发原理，想不通睡不着，反而忽视了更重要的广度优先遍历，覆盖业务逻辑。否定后者其实就是否定自己的存在啊！

个人感觉，技术是为了更好的测试，而不是为了做技术而做技术。
所以流程上应该是，功能测试（业务逻辑）- 易用性测试（体验）- 技术手段优化（自动化或者工具）
不过 感觉上 很多人弄反了，遇到功能先想怎么实现，然后做工具，写脚本，测功能，说白了就是为了 我得用技术去测试，而不是我得去测试。
当然，我觉得这方面，专职的测试人员和测试开发人员应该是分开的，测试开发说白了是测试工具的开发，确实需要先搞清楚原理，然后写测试工具。而测试人员需要先保证功能，再优化测试。

#20 楼 @441385483 其实现在整个行业都是颠倒的，技术优先级很高，业务便更多的认为有局限性以及 low。但其实企业最终落地的都是业务，技术落地也是 base 在业务上，技术是为了业务服务的。这点很多人却没有理解这点

其实关于测试开发现在定位，只要不理解业务，不了解业务的情况下，其实就是开发。当然很多人说不要那么绝对，但现实情况的确就是如此。

我觉得鸡汤是没有意义的，我就举个例子说，现在一个业务专家，只要不是医疗，金融非常垂直，非常资深的。一般的业务测试，出去有出路么？

业务测试是根基

产品测试的需求跟人的需求一样, 也是分层次的.
业务测试肯定是第一位的. 是产品基础. 围绕业务会有很多的衍生需求, 比如性能 安全 稳定性 兼容. 但是首要的还是业务功能.

与其他需求一样 业务功能也是存在可被模型化和技术化的. 产品的衍生需求大多都已经是实现了现代化的检测. 而唯独业务正确性未实现. 这是有很大的历史原因在里面. 我觉得限制主要来自于两个方面.
第一个是业务的正确性无法被很精细化的模型化. 这种复杂性就算是 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 或者其他的工具作为弥补. 来挖掘代码中的业务实现.
埋点与字节码插桩. 这个技术已经是非常的成熟了. 了解用户的业务场景并完善你的用例是非常有用的. 而且还能做到精简你的测试用例

#22 楼 @seveniruby 既然说到这个，你觉得现在大量的测试人员，业务测试他们应该怎么体现自己的价值呢？或者说怎么让自己公司，外面公司看到自己的价值呢？

#23 楼 @monkey 业务测试的 KPI 主要是挖掘 Bug 测试活动工作量和收集分析产品问题.

因为技术受限, 他们大多无法认识到问题的深层根源, 但是用基础工具是可以的, 这个时候要考借助于其他团队打造的工具或者开源的方案来做事.

以前他们的工作是没法量化的. 现在借助于一些监控可以统计这部分的大概工作量和测试能力. 所以就会变的可量化可管理了.
技术受限会导致与研发团队的沟通会有障碍, 也无法快速的应用新的解决方案.
这波人只有一条路, 就是管理. 不然就会被新人逐渐代替. 靠改造他们已经不现实. 只能招聘优秀新人.
他们自身也面临着质量压力, 因为人力的限制, 他们无法做到更深入的问题发现. 以及更广的测试范围. 同时又面临新解决方案和众测, 灰度, AB 测试以及全员内测等各种新思潮模式的制约. 发展已经是困难重重了.
从管理层面来说, 整个大行业都在逐步的精简业务测试. 大的质量部门也逐渐被取消, 从管理层面也已经没有了上升空间了.
这几年业务也在快速的变化, 而且 BAT 已经都开始面试开发能力了. 这类人也几乎已经到了无法跳槽的地步.
未来会很凶险.

#24 楼 @seveniruby 嗯，我同意对于现状的这个解析。但是不是只有管理一条路，可能还可以尽早的换行吧。不过我还有问题，既然这样说的话，分两个点来讲吧。

1. 现在时代的发展，管理也不是纯业务就可以做的，虽然纯业务的管理也有，但可能更多的还有人脉，关系等关系在里面
2. 假设纯业务很多都管理了，那么行业其实上层还是业务人员堆积，那么是不是说技术人员的本身发展其实还是受限，因为上面根本不懂价值。

当然好的总归能做好，我希望我们讨论的点在于大面积的现状，个别案例不管哈

评论区讨论不错，加个精

赞@skytraveler 的回复，业务测试往往和行业关系密切，传统业务测试向来是从用户使用角度来测试产品 (这也是很多行业还设有 UAT manager)，现在回过头来看，当年的 DE 其实不算个强业务类型的产品，除了每年的大版本发布，很多是客户大数据使用后的补丁，这也是目前银行类测试为什么还需要大量的业务测试 (比如最近汇丰银行的增值税项目需要 100 个测试)，大量的时间是在模拟各种用户场景，而 DE 实际是抛给用户做了。
业务测试的上升空间确实受到了挤压，管理由于岗位有限，能升上去的不多；其实在业务测试之前，QA(严格意义的质量保证) 就受到很大的冲击，因为流程和组织架构的变化，从瀑布到敏捷，很多公司的 QA 部门都裁掉了，所以后面经常会把 TE 和 QA 混淆。
业务测试的出路可以考虑需求，售前售后，实施；业务测试人员自身学习技术转型的也不少。
我个人觉得业务测试最大的价值在集成测试这块，从我目前做的产品，历经 3 年多的时间，各类型的测试都做得不错，覆盖率也足够，发布也够快，但是集成测试这块还不敢全面放心的只跑自动化，随着系统的庞大，模块依赖关联复杂，业务测试从全局上考虑问题，从用户体验和使用习惯上和 PM 合作。

#25 楼 @monkey 早些年的确出现了因为测试部管理层是业务测试出身而导致对测试开发工程师不重视的情况.

因为重业务测试必然会带来大 QA 的局面, QA 本身对质量提升的作用会随着队伍的增加衰减, 而人员队伍成本和项目的工期却在递增.
这自然是导致了公司管理层的不满意. 后来出现几波行业变革才扭转了局面.
第一个是创业浪潮. 这带来的思潮是速度与质量的平衡, 快速迭代和快速反馈.
第二个推进作用是中大型公司对 QA 或者测试队伍的调整. 算是对国外公司的跟随.
第三个浪潮是移动互联网, 导致了传统型的业务测试人员要面临转变和跳槽.
第四个是敏捷. 敏捷迎合了创业浪潮, 得以大放异彩. 他侧面辅导了创业浪潮的崛起. 敏捷的方法论也是倡导快速迭代, 弱流程重沟通, 这必然也冲击了大 QA 模式.

大环境最后注定了大 QA 模式的瓦解. 但是业务测试的地位和作用仍然还是有的. 基本只会停留跟用户有交互的产品部分. 传统的后端测试工程师已经逐渐式微甚至是消失. 会逐渐只剩下少数业务模式比较重的行业比如金融, 电商等.
问题是当 QA 或者业务测试的总量下降到一定 level 后, 就会快速的坍塌. 当有一天人们不再像提研发和产品那样提测试的时候. 业务测试的未来就没有了.
当然这个过程可能并不快.

小产品的测试体系可以参考微博 id 纯银发布的产品测试经验. http://www.jianshu.com/p/9f3041818702?utm_campaign=maleskine&utm_content=note&utm_medium=writer_share&utm_source=weibo

行业的发展要求 QA 满足如下的需求

1. 速度
2. 质量

这必然会导致了新兴的服务模式模式 比如灰度测试, AB 测试. 众测, 云测, 质量监控, APM 数据分析等. 未来还会很精彩.
不过我相信, 质量保证行业只有自身能迎合时代的发展, 就自然会再度崛起. 这就是一个适者生存的环境.

#29 楼 @seveniruby 嗯。好趋势分析。其实所有工种都得进化。
但是我对 QA 整体进化速度不乐观。对传统 QA 的淘汰现状也不会太悲观。因为技术的门槛没有那么高。认识 N 个姐姐已经成功跳槽互联网了，慢慢补一些技术（只要肯学，根本没多难），现在也发展很好。

你分析的质量会变成多层次承载的这种趋势其实真的挺明显。
灰度，云测，众测，生产系统质量监控、反馈、数据分析，这些都有大片工作去做。也改变了很多现有测试的工作模式。
其实本质是传统的测试方法论搞不定现在的系统了，需要不断的进化

我总结的就是：不同高度的天花板和地板对应的薪资上限和崩塌下限不同。这简直是废话——有些人天生就是牛，再加上后天的努力，达到了你这辈子都达不到的高度。假如有一天行业崩塌了，你可能会流离失所，而他们仍然衣食无忧——你改变不了别人，只能改变自己。我穷其一生也挣不了马云爸爸一天挣的钱——但是不代表我就不努力了，因为我还有我的生活，还有要为了生活质量提高的奔头。既然选择了这条路，就坚定地走下去。

#30 楼 @skytraveler 能进化的都是好同学.

传统的业务测试，从用户角度和测试角度思考问题，价值体现在扎实的测试基础知识、发现问题的敏感性、业务知识的专业性、业务提议的建设性。
随着敏捷、快速迭代的兴起，对业务测试的要求越来越高，缩小问题范围、精准定位原因，节约开发耗时成为业务测试的另一种价值体现。
业务和技术是测试人员的左膀右臂，业务知识让你发现有问题的现象，技术让你透过现象看清本质。

#8 楼 @skytraveler 不能同意更多

#12 楼 @lvchongen 没什么应该不应该。 不懂技术可以做好业务测试。如果懂技术可以更快递高效全面的做好测试。艺不压身，会的越多越好。你的本领决定了你的高度。

#21 楼 @monkey 猴哥说的很对。现在业界就把流程搞反了。应该是由浅入深而不是深入浅出

评论版果然是精华所在，谢谢各位大神们，是你们点燃了我 “进化” 的激情！

业务测试是门技术活

评论区非常精彩，赞，工作几年，其实觉得业务测试是非常不简单

最近两年看到很多这方面的讨论，应该说大部分的人对业务测试（或者功能测试、手工测试）是报悲观的态度的。
其实换一个角度来想这个问题，如果是开发人员在讨论自己的出路呢？
在国内很多开发也会觉得纯做开发没有前途，会考虑转架构什么的。

所以问题在于，行业对人员的要求越来越高，或者随着工作年限的越来越长，大家对自己的定位越来越高，要求越来越高。
而一般人的学习曲线是趋平的，所以才会有 3-5 年的测试工程师最好找工作的说法。
一旦工作超过 8 年，或者 10 年，不做突破，很难说比工作 5 年的人有太多的优势。

这个时候就必须要找一个突破口，比如说：我还会编程、我会做专项测试、我会做自动化测试
说白了就是需要一门门槛比较高的技能，来和其他人区分开。

下次可以聊聊，我为什么觉得做业务测试比较悲观的原因。

毕竟业务测试工资不理想

个人理解，不管你做什么，始终还是得看自己，自己的规划是什么，方向是什么，顺着走。
不管业务还是自动化，只要自己不是温水煮青蛙的蛙就好~
当然，我认识的一些人里，有些因为家庭而选择了不再 “深造”

嗯，家庭和工作没法兼得。有些人可能看上去两者都做得很好，其实你反过来想，可能是都做得不好，因为按他的能力，专注于任何一个都可以做更好。取和舍，在心里就可以了。

可能是行业造就，很多业务自己内心觉得自己卑微，我经常鼓励我身边的人，无论是业务的，还是技术的，大家都为做好一件事情，都不容易。
于我而言，我目前也处于转型 ing，很多都是靠自己靠网上资料什么的，所以我来论坛啦~还期望不要觉得我的问题太低级，给我一个成长的过程哈~

业务测试毫无疑问是根基
技术的贡献主要是让业务测试可以更好更安心的去专注于最值得花时间花精力去做的工作，而技术就是为了让业务测试可以没有顾虑的去完成这件事情，去保驾护航，减少人生的浪费。