前情提要，这是写给软体开发者的测试历程， 主要是以我自己进入测试的经验说明如何进入测试门槛， 以及我身为软体开发者进行软体测试时需要知道的事情跟可能的心路历程。 所有的内容都只是个人经验仅供参考，欢迎提供意见分享跟挑战。 ----------------------------------- 另外这里所指的软体测试都只是主要针对者自己对软体的测试， 而与专案测试（目的为增加专案品质）的目的并不直接相关。 也就是说，这里讲的主要目的，是开发者如何可以在开发过程， 快速验证自己的修改是否有误跟常见的一些问题。 ----------------------------------- 本文开始 ----------------------------------- 到目前为止我们依序描述了几个情境， 1.我写了一个简单程式，我要验证他的结果是不是对的。 我需要：测资。 2.我写了一个复杂程式，我需要一直测试系统的某个部份是不是对的。 我发现：测试路径跟测试路径优化 3.我发现我测试的过程，常常需要修改程式码才能加速、优化测试路径， 然後发现有时候改的多，有时候改的少，有时候甚至测不动。 这时候我知道，程式码有可测试性。 而我将开始研究起如何让代码更有测试性。 4.我从这些过程中开始发现，测试程式码时， 常常需要撰写特别的测试程式码，这些程式码如何管理， 如何让测试程式尽量避免影响程式，也会是一个大问题。 ----------------------------------- 什麽是我们没有说的： 1.我们没有说单元测试 (unit test) 2.我们没有说自动化测试 我认为他们在你还没掌握可测试性之前一点都不重要。 如果你连改 code 测试都做不到， 那就更不用讨论写 unit test 这种必须从抽象视野才能作得事情了。 而且时候还没到，在这个时候， 我们还看不出来单元测试跟自动化测试的好处在哪。 如果还不知道好处，甚至是连想像都想不到好处， 那我个人认为与其从中贸然进入，倒不如先从改善手边流程着手。 ----------------------------------- ----------------------------------- 我们即将继续往後走，继续讨论更多的开发案例， 并且发现更多开发过程伴随而来的测试观念。 之後我们还会回来再来谈可测试性，但现在我们要先往前走， 因为可测试性也并不是我们关注的全部。 ----------------------------------- ----------------------------------- 讨论可测试性的要点之前， 我要继续先带入更多的测试看法， 那就是「测试权重」。(Test Priority) ----------------------------------- 我们这里谈的是开发上的测试权重，而不是专案的测试权重， 再一次强调，专案测试跟我们现在谈开发测试是完全两回事。 专案测试是期待有高品质的专案，但开发测试， 则主要是希望能加速开发者工作流程。（测得快自然写得快。） 专案测试是希望测试能完整，能够测到所有情境， 而开发测试则是希望开发整体而言能用更少时间作测试， 并且达到至少跟原本一样的开发效果。 专案的目的不见得总是跟开发的目的相合， 我们之後也会专章讨论专案测试，现在还不是时候。 所以我们这里的权重主要的判断依据， 并不是这些程式码对专案目的真的有多重要， 而是这些需要测试的程式码对其他的程式码有多重要， 也就是你今天万一改坏了这东西，後面会影响多大程式码。 以开发者而言，专案的测试权重比较难定义， 但开发的测试权重则相对单纯。 我们每一段程式码被呼叫的次数是显然会有很大差异的， 有些很冷门的情境可能久久才被呼叫一次， 有些程式码属於别人依赖的资料来源，自然就会影响比较大。 一般而言我是用使用者的最常操作路径，作为优先权重的第一个要素， 也就是使用者最常走的路。（通常都是 default 值造成的路径。） 以 blog 类型的专案而言， 最多的操作显然是显示文章、登入系统、新增文章、修改文章， 其他的像是 sidebar 的操作、 theme 的编辑、留言管理等， 相对之下就会是次要权重的操作。 再来就是以程式库的相依性， 以网页专案而言，ORM / DAO 的东西虽然单纯， 但是以影响而言则没有什麽东西比他们影响更大了。 下错一个 SQL 你後面的显示资料可能会完全不对， 本来要算平均值的你下错下成最大值，大概也不见得有多少人会发现。 一个类别被越多的地方呼叫，目的越多，他的测试权重就越高。 ----------------------------------- 我举我的 Eclipse plugin 专案 (Run-Jety-Run) 为例， 使用者的使用情境是，他们会用这个工具开启一个 web server ， 然後跑他们的网页专案进行浏览。 而这个 web server 会先需要建立一个 Run Configuration （执行设定档）， 其中有提供超过 20 个选项可以设定，但是根据非正式统计， 有八成的选项只有 10% 不到的使用者使用过。 有一些选项甚至是 undocumented feature（主要使用者就是我 （笑））。 举个例子，其中有个功能叫 SSL enable，可以提供 https 协定作为测试， 但是绝大多数的开发者不会需要用到 Https 。 我自己用这工具一年半了，我也从来没用过， 所以对我这开发者来说，他的测试权重是相对低的。 或者我应该这麽说，即使他今天是坏的，使用者也还有其他替代方案， 对开发者/使用者来说也不痛不痒，它是个可以被放弃的 feature 。 当然，站在开发者立场我们是鱼能捞的尽量捞， 但是如果资源不足，像这个专案只有我一个人在维护， 平均每周只能吃我六到八小时，那我们还是得要挑重要的事情作。 开发是这样，测试当然更是这样。 测试是有权重的，而他的权重通常就跟开发的权重一样。 ----------------------------------- 有个时间管理的法则是这样说的，把事情分成四种。 紧急且重要 紧急但不重要 不紧急但重要 不紧急也不重要 ----------------------------------- 在这里我则是把测试分成四种， 简单且重要 简单但不重要 (ex. Getter/Setter) 不简单但重要 不简单也不重要 这里说的简单是说写 test case 的简单程度， 而这简单与否便是我们反覆强调的可测试性， 会随着程式码品质跟开发者能力而变化。 其中有些东西天生可测试性就是低的， 什麽是不简单的 test case 我们之後会慢慢介绍。 （一次只说一点点，这个主题才说的清楚， 即使拆开来看，很多东西可以挑战， 但是当所有主题讲完时就会相对清楚了。:P） ----------------------------------- 以测试的目的来讲，如果让我再重来一次， 我会说，写简单而重要的测试； 一个 test case ，如果你不能在一个小时内写完一个，那就不要写了。 我过去就是花了太多时间写「不简单但重要」的测试， 而且这个重要很有可能随着需求变更而变成「不重要」。 如果这个测试对你来讲写起来不简单， 那你应该要记在心里偶尔想想为什麽难， 有空闲或有碰到前辈时，再一次的来 review 更适合的方法， 但尽量不要一头热就栽进去想写测试， 往往你只是绕一大圈作手动测试很简单的东西。 切记不要贪图测试的好处而卡在「不简单而重要」的测试上。 如果写 test 赚不到比你开发手动测试更多的时间， 像是 test case 每次你修改程式码时都要异动，那就不如不要做了。 ----------------------------------- 我可以说我在这点上自认干过最大的蠢事是什麽。 玩 web test 的大概都对 seleinum 不陌生， 敝公司全面导入 selenium 对元件进行自动化测试已经快两年了。 PS. 当初一开始它是不被公司看好的，是我主管跟我几个死忠派的人， 自愿协助并力挺到他开始发挥效果，现在已成为敝公司最主要验证工具之一。 ----------------------------------- 一方面是当时我还是公司内的新人，又算是 JS debug 经验还可以， 另一方面也是我个人兴趣，所以被指派去撰写 test case， 再加上自己闲暇把时间丢进去作，大概前後也累积至少有两三个多人月。 Selenium 1.1.2 官方要升 selenium 2.0 时， 也就是正在改很大的要跳 web driver那时， IE9 刚出没多久， chrome 也拼命在追版本，当时也还改很大。 IE9 Selenium 支援还很烂， drag and drop 跟相关事件根本没办法在 ie9 测， 我们虽然当时已经有专门的 VM 搭配 hudson 在作自动化测试， 测试 IE6, IE7 ,IE8 ,FF3 ,FF4 ,Chrome , safari 5 ， 印象中大概一千个 test case 全浏览器跑完只需要四五个小时。 （时间都浪费在启动 browser ， 後来我有用一些点子作 finetune ，让时间缩到只剩 1/5 。:P） 阿我说的蠢事是什麽？ 因为 IE9 支援坏掉了，我为了要自动化测试好处， 缺 IE9 总觉得可惜，而且他确实是重要的。 我跑去 debug selenium，把他的 js 解出来一只一只看， selenium code 是 java base跟js ，程式码有点脏但不算难懂。 花点时间了解 selenium 原理，也对 IE9 打 patch ， 但是代价实在是太高了，我花了快八个工作天才搞定这件事， 结果 IE 改个版上个更新，他就又坏别的东西了。Orz 最後还是要放弃 IE9 一部分的测试，人森啊... 而 dnd 的 test case 大概只有 50-100 个（估计值）， 如果我牺牲掉 IE9 上那一百个 test case， 把那八个工作天拿来写别的 test case ， 我大概可以多写出至少几十个 test case，对整体的效益算起来会更大， 後来还被当说花时间结果作白工。（囧 XD） ps. selenium 2.0 换成 web driver ，是有稳定一点，速度也有变快， 不过最近换 firefox 最新版测不动了，还是奉劝要 debug selenium 的人， 还是把时间花去写别的 test case 吧。囧 ----------------------------------- 总之，写 test case 我认为是写那些重要，而且写起来很快的测试。 ----------------------------------- 如果你的测试写起来不快，你该检讨的是你的开发方法跟程式码品质， 或者是你该注意的事情是那个对象是不是很难测试的东西。 我们之後的章节也会探讨哪些是难测试的东西， 跟一些因应而生的测试工具，测试工具的面貌有很多而且很有趣的。 ----------------------------------- 希望你看完这篇之後，能了解「不是所有东西都需要测试」。 你几乎不可能穷举整个系统进行测试，因为那测试组合将是天文数字。 本篇介绍的是测试权重，下篇我们将回头探讨重新可测试性。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 114.25.104.110 ※ 编辑: TonyQ 来自: 114.25.104.110 (03/27 23:56) ※ 编辑: TonyQ 来自: 114.25.104.110 (03/27 23:58) ※ 编辑: TonyQ 来自: 114.25.104.110 (03/28 00:05)