自动化实现的困难讨论

mfjin

在公司已经正式实施了三个月（前三个月算是摸索阶段）。整个流程基本上是用例写完了之后，自动化组就介入了。到上个星期为止完成了4个关键用例的测试（包含8个辅助用例）。总的来说不算很满意，整个编写阶段花了几乎30%的时间在调整测试组写的用例，20%时间写完脚本，10%的时间修改框架脚本，40%时间用来了系统调试。在整个过程中遇到了很多的困难，其中最大的困难不是自动化的脚本编写，反倒是用例的改动。用例的编写直接决定了自动化编程的思路。在测试人员没有参与过或者了解自动化的前提上，写出来的测试用例有很多冗余的地方。在编写脚本的过程中也重新整理了思路，自动化测试用例我倾向于以业务模块的角度来编写，而不要在细小的验证点上考虑。但是现在公司在过渡阶段，手动测试还是主要的测试手段，用例也不可能写两份阿。

hsjzfling

自动化测试用例可以来源于测试前期的手工测试用例，自动化测试的侧重点应该在于冒烟测试等执行次数会比较多也非常重要的Case。
至于用例的改动会影响到自动化脚本的编写，那只能说明脚本的主体框架结构不合理，对于不同的case兼容性太差，可复用性也不强。

陈能技

如果没有足够的精力投入到自动化测试的话，建议还是先实现简单的用例、容易编写的用例、重复工作量大的用例，尤其是冒烟测试的用例。
冒烟测试是自动化测试中最重要，也最应该实现的测试。
http://www.itestware.com/ctest/i ... plete&Itemid=37

davy_chen

自动化测试内容应该和手工测试内容相互协作，相对独立，即自动化测试不应该直接对原手工测试带来过多负面影响，而应该是单独考虑自动化测试，然后根据自动化测试的实践，对应削减手工测试内容，达到技术稳定期后，再将自动化测试与手工测试统一规划。

厍仕杰

自动化会使高效的东西跟高效、低效的东西更低效！

wonew1228

不是所有的东西都适合做自动化测试的，要做自动化测试以前先应该从测试中提取出被测系统中结构比较稳定比较核心（很重要，经常要测试）的部分，从这方面开始入手做规划。一般效果可能会好些！不要什么都想要上自动化，那是不现实的除非是产品测试。

mfjin

多谢各位的回复。公司的软件倒是产品，其实复用性还是很高的。前期遇到的测试用例的问题，其实归根到底还是手动测试对测试用例的不重视，所以在自动化的时候，自动化人人员反倒要花30%的时间来重新修复测试用例，当然这其中也有些测试人员在设计测试用例的时候因为以前是给人来实现的，所以一些冗余或者不合理的地方可以自行规避掉，但是在自动化的时候，将这些用例写成脚本的时候还是会发生些问题的。现在建议测试人员尽量以业务流的方式写测试用例，这样发现问题的可能性会增加，同时发现的bug等级也会增加。

兰兰

努力学习中！

wugecat

可以用那个《轻量级测试框架》那个个人感觉不错虽然存在一些弊端，但是最大的好处，就是测试用例和开发脚本可以分开。这样责任也就分开了，测试用例写的不好那就是测试人员的事，反之脚本无法实现测试用例那就是开发脚本人的责任。
在测试脚本中一定不要包含业务，业务是测试人员制定的

lc448589698

jifeng

貌似脚本里融入了太多的业务，出现上边情况是一定的了。

单个脚本不应涉及过多、复杂的业务在里边。否则维护起来比较麻烦