验收测试与UI

CRS

如果功能复杂的情况下,是不是先写验收测试,然后写单元测试,最后写代码?

STST

是的

从高往低走，无论是分析，还是测试，还是开发

从高往低走，带来的是干净无累赘的，底层依赖高层的优雅的结果

CRS

那模式是否
1.  先写feature
2.  实现自动化验收测试
3.  再写view层的ut(事实上view层的ut咋写?基本没法写啊..)
4.  实现view层(写死)
5.  实现controller的ut
6.  实现controller的代码
7.  重构view和controller,对接起来(这会儿要补针对view和controller的集成测试么?
8.  写model和orm的ut
9.  实现model和orm的代码
10.  重构view,controller,model,完全对接,形成真正可用的功能?

是这么个流程么?
H

可以唠点接地气的不  
CRS

从最顶上往下写?

H

我们经常就是  什么东西开发完了 测一下

CRS

就是玩多了这个..老板要玩玩不一样的..

所以今天结对了两个小时琢磨了一下,没琢磨明白

STST

UI可以先不管，UI设计的时候，注意用一个隔离层，不要直接调用底层的功能

其实就是顶上往下写
先写死view,让测试通过,然后补controller,让controller对接,接着最后补最底下DB的model和orm

自顶向下做，一定会效果好，但是可能很多人无法做到这一点
CRS

但是这里有几个地方没理解啊
如果先写了验收测试
那是否在写view代码之前,还是要先写view的单元测试?

STST

UI的测试先放一放，自动化确实很难

注意把UI层做的尽量薄就行

CRS

BDD的不应该就是先做验收么..,验收基本就是UI的啊

STST

验收测试不是UI吧

CRS

对于web而言基本就是了..

STST

把验收测试理解为UI就有点狭隘了

JXL

我理解就是业务

STST

如果验收测试=UI的话，那么描述登录就是如下面了

"用户名输入框输入 admin,密码输入框输入 123456,点击登录按钮"
这是UI的实现，而不是登录业务的验收

 

登录业务的验收测试应该是：
"调用login方法，参数如下，user=admin,password=123456,期望返回结果True"

DH

这其实不就是之前有群友说的"所有的测试都是功能测试"了么

STST

前面UI只是业务的一种展现方式而已，在UI上面描述验收测试，会导致一点点地变化，测试就失败

Qk

UI应该是验收的一部分吧

STST

UI应该说是单独的一门测试，我尝试了1年多的界面自动化测试，现在放弃了，还是人工点一点靠谱一些
J 

对ＵＩ只是一部分

你看客户需求，比如购物车功能，那一定是业务流表达

感觉公司在ＵＩ就是为了跑数据

跑大批量数据
JXL

我觉的客户着重点应该是这个业务是否实现

STST

是的，UI只是展现数据的一个方式

没有这个WEB的UI，很容易用一个别的UI来完成，比如命令行，窗体程序都可以
JXL

ui 这么说吧 算是用户体验度了

STST

是的

Qk

验收是为了确定系统是否实现目标

STST

我已经接受了，UI主要是关注用户体验，想自动化真的很难

CRS

cucumber是在描述业务,只不过验收的时候走ui的途径..

JXL

cucumber 没做过 不清楚了

CRS

跑题鸟..
到底BDD开发实践中
ut啥时候插足..

STST

UI可以最先开始,但是不要牵扯逻辑，就是画UI，能表达意思就行
DH

你用BDD做的是UI层的。。跟UT有啥关系啊

STST

用来沟通需求
DH

颗粒度完全不一样

CRS

BDD -> TDD -> refactor

应该是这个过程啊...

今天结对完了有点懵..

STST

BDD我还没去深入理解，我觉得过程应该差不多吧

但是应该是很多并行的，比如TDD就是和refactor密不可分的
CRS

群里有人玩过这种实践的么..，求分享一下

KAI

UI自动化没你们说的那么鸡肋吧，现在很多前端和后端都是分开的。不在UI发起，光测接口不能保证的

STST

UI自动化的问题是成本大，收益小，不是说没用，维护成本太大

KAI

可是不做自动化又怎么"敏捷"呢？核心用例还是需要自动化的

STST

比如这个，业务不变的情况下，把"用户名输入框"替换为下拉框，就会导致失败
DH

其实。。要看底层怎么设计吧。。

STST

针对UI，100个客户有100个看法，但是业务相对要稳定地多

不能看底层怎么设计，一定不要去看底层怎么设计

DH

对咯
其实这个需求完全可以理解成，将XX的内容设置为YY

STST 

而是要看需求怎么描述，底层只能为高层服务，而不是高层根据底层的设计来迁就

DH

至于怎么去设置 底层搞定就可以了

STST

如果先做底层设计，那么底层的设计人员会给你提供一个具有1000多公共方法的列表类，然后高层就去调吧，底层设计人员可能觉得这还不够全面

千万不要从底层入手
DH

肯定都是由需求来设计底层的

STST

是的，高层定义需要的接口，底层去实现这些接口，不要累赘的内容