STST
如果软件只考虑第一次交付的话，不考虑后面的变更维护，自动化什么的确实没用，但是这种理想情况存在的概率有多大？
H
自动化是为了发现问题？
BS
我觉得有这个目标
STST
自动化本质上就是用来让将人的精力从重复性的工作中解放出来
STST
"自动化是为了发现问题？"这个是不可能的，发现问题的是人
HL
我觉得。。。@英界尔 说的是具体问题 而@Black Swan 和我刚才指的是可能存在的问题，毕竟 具体问题的话还是要人来发现
BS
也没办法人工智能啊
STST
自动化用来固定一组不变式，而这一组不变式是需要人脑去发掘的
我们所说的问题，说白了就是指这一组"不变式"
BS
测试里面的bug的本质不是和需求，设计不一致的地方吗，我们人不也是这样找bug的吗
HX
自动化能发现的问题有限啊
STST
发现问题的是人，而不是自动化
XM
为什么指着自动化去发现问题
STST
人发现了问题，用自动化来测试验证
HX
所以不能完全依赖自动化
BS
嗯，好多东西人如果没见过是很难相信的
WL
人判断什么可能会出问题，通过自动化来验证
WJ
根源在于层次不同，底层靠自动化也许能发现多点:其它时候自动化只能照着写好的定义跑，无法处理变化的场景
STST
自动化的用途就是起一个固定问题边界的作用，在以后的任何改动，只要破坏了这组边界，很快就能通过自动化测试感知到
WL
反正没达到对一个全新的无人接触过的需求，自动地进行测试的地步
H
感觉说得不错
STST
这样就很快告诉了开发人员，你刚才的修改"有问题"，而不是，两个月以后的一次部署中，才发现改动有问题
H
理解的多深才能表达这么通俗，学习
STST
到那时候回头修改这个改动，成本极大，问题发现的越早，解决的成本越低
DH
那这个问题的范围怎么定义
如果开发修改了这个方法 发现了使用这个点的功能出了问题 那人需要去确认下哪里有问题
但如果测试对象就是这个方法 能不能就说是自动化发现了这个问题的所在呢
DH
这跟什么时候发现问题没有关系 我想说的是在某一层级 自动化测试是能准确发现问题的 除非你们觉得单元测试不是自动化测试的一环
H
自动化只能发现，与预期不符。问题都是人发现
STST
是的，预期是"不变的"，变化的是实现的过程，自动化用来约束"实现的过程"，以在整个软件的生命周期里无论怎么改变，都必符合预期，用数学里的说法，就是"满足不变式"
BS
手工不也是对比预期吗
H
自动化不就是自动化手工吗
STST
手工的重复性极大，自动化就是用来替代重复性劳动的
WJ
自动化定义很广
WL
这个是有争议的，测试在很多公司地位低下，就是因为这个预期到底是不是确定的
BS
自动化不完全是代替手工，他有他很多手工无法做的
WL
如果需求分析、设计过程已明确了这个预期，测试人员所做的只是手工去验证一下开发的实现，那测试地位低也是正常的
H
测试工具为无法手工设计的，自动化是为重复手工设计的。手机打字辛苦
WL
特别是，这个手工的过程如果是只要会使用软件的人就可以来做，那就更是如此了
STST
是的，确实存在这种情况，但是很多都是因为过程有问题
如果开发写了一大堆，抛出来给你做测试，肯定很难
H
讨论问题就不要大神，高手了把
WL
楼上的英界尔兄不就是高手嘛，抽象思辨很强啊
STST
可测试性，是软件的一个非常重要的特点
H
他是，等讨论完了说
HX
手工和自动化的优劣已经有定论了，感觉没有争论的必要了
STST
无法自动化测试，意味着系统各个单元的耦合性很高，你很难模拟一个完整的测试环境而已