既然谈到Automation Test，分享一下在下的经验好了， Test Case： 文件化後的测试描述，相对於Use Case从使用者角度出发，Test Case从 测试角度出发。至少有输入(Input)、预期输出(Expected Output)、步骤(Test Step) 等三项要素，其他像是测试编号(Test Id)，测试方法(Test Method)、前置条件( Precodtion)，这些依照不同公司、环境的测试规范而定。 自动测试：Automation Test，采用电脑自动执行Test Case中的Step。 人工测试：Manual Test，采用人力执行Test Case中的Step 随意测试：Ad-hoc Test，在没有Test Case的情况下人工乱打。 单元测试：Unit Test，程式码层级的测试，主要透过Unit Test Program自动完成。 理想的Unit Test应该能够去除类别之间的Dependency. 除单元测试外，其他的测试若没有主动提到都是指在整合测试阶段的测试。 这里的单元测试是指透过xUnit家族之类的Unit test automation framework来 进行的单元测试。 其他还有一堆有的没有的测试像是Monkey Test、Randomness Test、Load Test、 Stress Test的ROI就不在这里讨论的范围之内的。 有人说Automation Test一定胜过Manual Test或Ad-hoc Test，我的答案是： 从ROI的角度来看，并非100%赞同，特别是GUI Automation。 Ref: http://www.testingmentor.com/imtesty/2009/11/18/gui-automation-and-roi/ Dan Mosley and Bruce Posey (Just Enough Software Test Automation) suggest that on average an automated test must run approximately 17 times in order to break even. But, this doesn’t imply that we break even if we simply run the same test on a daily build for the next 17 days. 这一段引用了一篇来自於Dan Mosley与Bruse Posey的书，这本书告诉我们自动化测试 「够用就好」，原本这里面的数据是某位我以前的同事告诉我的，我最近才找到来源， 它说「一个平均的自动化测试要打平它的开发成本，至少要可执行约17次。」「而且 这17次不是说执行每日建构17天，而是要在17次版本改变里面被正确执行。」 我们说一个自动化测试不是对的，并不是说被测试的程式是错的，而是自动化测试程式 本身无法依照测试脚本(案例，Test Script/Test Case)上面的定义去验证程式。 这一点是自动化测试一个非常严重的迷思： 错在哪里？ 如果一个自动化测试不能够被稳定的执行多次，而每次错误都必须找出自动化错误程式 错在哪里，最後却发现原来都是自动化测试程式的错而不断去修改自动测试程式，那麽 若是由Developer开发自动化程式，这样的程序浪费了他用在Feature开发的时间；若是 由QA开发自动化测试，那麽这样的程序浪费了他执行其他更重要的测试的时间，於是这 个自动化测试案例就失去了他原本的价值。 更严重的是，他会使整个团队不再信任自动化测试的结果，而这就是绝大部分专案执行 自动化测试失败的原因。 「被测试程式的稳定性」是评估自动化测试ROI的第一项指标。 那麽，哪种被测试程式的稳定性最差？ GUI。 因为GUI是最容易因为需求改变而被改变的程式，因此GUI Test(通常GUI Test是 Integration Test层级)的Automation的争议性一直是最高的，甚至有台湾大神 vgod开发的sikuli都做到用Screenshot来Test了但还是有很多问题在。 用Screenshot的Test，假设图改了呢？(Sikuli) 用座标的Test假设位置变了呢？(AutoIt, PyAuto...) 用Id/xpath的Test假设Id换了，或是...没有Id(动态元件，如Ext3)呢？ (Selenium, HP QuickTest ...) 有太多因素可以影响GUI，造成自动化测试程式不是依照预期的正确、或是错误。 一般而言，稳定性最低的GUI Test最不适合做Automation。如果你的团队要做自动化 测试，请将GUI Test的投资顺序挪後。如你能很神奇的维持GUI的稳定，那请您一定要 分享给我们您是怎麽做到的。 稳定性最差的情况是连需求都不稳定，需求一旦变化，Test Case要跟着动，主程式要 跟着动，当然Automation Test也要跟着动。这也是几乎所有专案公司执行Automation Test都会失败的原因，因为台湾的专案公司在验收时都还可能在改需求在改Code。 所以很多人对於自动化测试的经验相当两极化，原因就是在你是不是在做一个稳定的 产品或专案，一个好的Unit Test可以增加Automation Test的稳定性，但一个乱七八 糟的需求变更流程可以让Unit Test毁Automation Test更厉害。 -- 所有我的作品，请到..... ～四十八个德瑞克～http://blog.derekhsu.homeip.net 马皇本纪：http://blog.derekhsu.homeip.net/2009/08/821 上官先生传：http://blog.derekhsu.homeip.net/2009/08/825 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 175.182.34.146 ※ 编辑: derekhsu 来自: 175.182.34.146 (05/29 00:10) ※ 编辑: derekhsu 来自: 175.182.34.146 (05/29 00:19) ※ 编辑: derekhsu 来自: 175.182.34.146 (05/29 01:01)