你为什么要做自动化测试[2] 自动化测试工具
先考虑一下两个问题:
这个功能没测试好的后果是什么?
CEIP是用于指导下个版本的可用性(Usability)设计的。如果里面的缺陷导致不准确的信息,那么CEIP分析师会被误导从而得出不反映真实情况的结论。例如,本来用户很常用的一个菜单项“打印”,被误记录为“属性”的话,结论会是“打印”没什么人去用,“属性”倒有不少用处。那么开发下个版本的软件时,根据这个“据说从真实的用户统计数据得来”的结论,很可能“属性”被放到显眼处,很常用的“打印”反而被藏起来了。不要争辩哦,这是被大量用户数据所证实的嘛。所以,CEIP是把双刃剑,不准确的数据比没有数据更糟糕。
这个功能没在测试中发现的缺陷,会被谁、什么时候发现?
很多测试中没发现的功能缺陷,发布出去之后用户迟早会发现。唯独这种CEIP的功能,用户除了打开或者关闭之外永远不会去接触:用户为什么要关心CEIP记录得对不对呢?事实上这些功能缺陷用户不知道,微软也不一定知道,只会根据CEIP数据调整设计。除非之后的若干个版本改得实在太过分以致怨声载道,或者跟用户调查的结论相差实在太大,才会惊觉可能是CEIP的问题。所以CEIP数据的缺陷,是一个不定延时引信地雷,埋下去就难以挖出来,而且要挖出来还极为麻烦:怎样回应用户“上几个版本都是这样的,我都习惯了为什么又要改”的质疑?“根据CEIP数据决定这样改,但后来我们发现CEIP数据错了”?(用户一脸茫然:什么是CEIP数据?跟我有什么关系?什么叫做记录我做过的事?你想说这是我自作自受的结果吗?)软件测试
综上所述,这个功能不是对着界面点击一通就能看出对不对的,测试人员还需要观察记录下的数据并与做过的操作相对照;测试用例需要持续的在多个版本中执行以防范回归缺陷(Regression Bug);测试这个功能,防止缺陷被埋进去具有更高的价值,因为事后很难挖出来。
表面上看,似乎自动化测试是板上钉钉的事:人工测试很难;还需要反复执行。但请考虑一下最初提到的一个问题:“自动化测试总是任何时间内、任何条件下、任何项目阶段中的最佳选择吗?”
回答这个问题之前,请先看看加入CEIP之后设置向导有什么变化:
设置向导在每一页收集用户的输入,直到“完成”按钮被按下,然后拿着设置的数据往指定的地方一一写入。加入CEIP之后,如果用户按“后退”按钮呢?
放在以前,如果“前进”按钮没有按下,用户输入不会生效,所以“后退”就是界面改为前一页,没什么大不了的。现在就不一样了,“后退”意味着某些状态发生了变化,如果那些状态要被CEIP记录,那就是一个值得关注的问题。