我的自动化软件测试小结（2）

1pO$g;m&Bmsu0　　http://www.51testing.com/html/85/n-816185.html

E)~/`p ^5r YVIS\0　　世上本没有路，走的人多了，也就有了路。今天不讲技术，只讲感悟。51Testing软件测试网sJ!}~9v!Oxr

v#@:o:Y]#g{1aA0　　第一节：质量意识是自动化的前提51Testing软件测试网+?:x$eV.sH6O/n1|rvF

^ ?'v z vSI'@S0　　任何东西都有个价格，质量也一样，如果在产品的战略定位中，质量不是核心价值，那么质量的价格自然不会高，为质量付出的代价也不会高。

P-K!~K2u!^0　　普遍讲，客户端产品的质量要求高于Web产品，客户端出了Bug，用户修复很麻烦，Web产品出了Bug，可以临时上线，或在下次上线修复；Web产品中，涉及money的质量要求高于没有盈利模式的产品，比如：游戏 or 购物类；还有就是用户群体的大小和产品活跃度，等等。

H"` w%h-O0　　第二节：减轻测试负担是现实动机51Testing软件测试网-iF7k D#l)n+i+S8X

　　古语有云：凡是机器可以解决的，就把它自动化吧！51Testing软件测试网M'aH
Z M!@ bX

pO J-c(R(h0　　有代码重构和服务器配置变更等涉及面广大的任务时，须要大量的回归测试，这时候先使用接口测试回归，可以速度得到反馈，确保功能无错，再配合UI测试。

ond(CsG0　　日常工作中，不会天天重构，但做一下每日回归，上线前再密集的多回归几个轮次，应该是比较靠谱的。51Testing软件测试网6j-Gq#@"|%y

　　自动化脚本尤其是接口测试脚本还可以用于批量准备测试数据，偶尔用用，不亦乐乎。51Testing软件测试网U'UD)w#vR

　　第三节：结合产品本身的状况是必由之路51Testing软件测试网_BY)A*D~|

0y!qX"qaa:s0　　额。。。这里的水太深了。简单讲，自动化不贴合一个产品本身的特点，十有八九是举步维艰。51Testing软件测试网K1dmE!L cQ%m

` x4[9k-cq0　 　一个比较理想状况是，产品的发展思路比较清晰，项目流程比较规范，上线的节奏稳定有序。在这种情况下，测试比较容易和开发沟通，取得开发的协助写用例， 也比较容易确定啥时候写用例，跑用例，维护用例，维护的用例也可以反复利用，而不至于因为产品的频繁变化而失效，反而拖累大家陷入维护用例的泥沼。

seyfk.y&uBL0　　第四节：持续投入，方可见到效果

　　无论从哪个角度看，自动化发现的Bug都是很少的，自动化主要是用来回归的。51Testing软件测试网5z2Xj~'k.n+X

　　用例只有十几二十个，不会有太大的收益，没有量的积累不会有质的变化。写很多用例？很大的成本，而且，产品在不断发展，用例本身也要不断维护，这些都是成本，看起来是个无底洞。51Testing软件测试网v x"Bb%cs^

"~)E
L$y/Rw0　　一天跑个一次两个，搞个每日回归，收益不见得高，最好是搞成持续集成，密集的连续跑。但是，用例挂了谁来检验？谁来维护？谁来反馈？如何做到及时？这些都须要人力。

　　所以，做自动化，不做则已，一做就要有花成本的勇气，用例要足够，至少覆盖所有核心的功能点，尽量做到持续集成，毕竟都是敏捷开发模式，代码提交的频度很高，还要有坚持扩充，维护用例库的恒心。

　　一个优良的自动化框架的价值主要体现在这里：使得用例好写，好维护，运行稳定，运行快。

　　发现Bug不是我们的目的，保证质量才是。

]"e3x&h@2n0相关链接：51Testing软件测试网
NP cAm;z9Ud N

b%A9D:e7Q0我的自动化软件测试小结（1）