昨天去参加活动跟几个朋友谈到测试，觉得几个点值得专文记录下来。 ----------------------------------- 首先 这篇文章不是要说测试有没有用，测试值不值得作，不是要战这个。 当然有兴趣要战的可以自己开炮，但是我先说我没有要战这个的意思， 纯粹是分享作测试的几个阶段跟心情。 这篇文章废话多心得少，加减看就是了。 ----------------------------------- 然後基本上我们谈的都是工程师如何面对程式码的自动化测试， 不是讲专案的测试，也不是讲测试方法论。 （听不懂我在讲什麽往後看就知道） ----------------------------------- 我也不假设你会怎麽样看到测试这个名词跟怎麽样进入测试领域， 我觉得测试这块太多雷就是别人都会告诉你测试很好很赞怎样， 或者是给你一个很适合用测试的情境告诉你测试的好处， 但是你会发现，(呃)，我拿到我的环境开始写测试就完全不是这麽一回事。 因为别人都在说，所以你觉得他好像是有用的， 但你可能根本不知道怎麽写你的测试，你可能不知道你要测什麽。 你试着去做了，但是你不知道你获得了什麽， 然後你开始想，你是不是作错了， 然後你可能感觉不到他带来的好处，於是，你就放弃了， 你觉得测试是浪费时间。 ----------------------------------- 我不会用可惜来形容这件事情，因为你确实从过程中得到了经验， 有时候，我会认为你甚至可能是对的， 你的确花时间在写没用的测试，只是那并不浪费时间。（原因後述） 我希望尽量从我的经验中抽出大家可能会有共鸣的部份， 带大家走一次我经历测试的感想。 我只说，我当初是怎麽开始想写测试，经过哪些问题， 撞过哪些雷跟我现在的想法是怎样。 因为时间有限再加上这不是个严肃的议题， 我会用轻快的风格带过以下的文字， 希望你也可以感受到测试并不是个沈重的主题。:) 然後我也必须要先说明的， 测试是一个很有争议的题目， 有些我认同的见解或者我的经验不见得是对的，欢迎挑战跟更正。 ----------------------------------- Let's get started. ----------------------------------- ok，首先我以前一开始写程式是写 Java 的， 一开始时我写程式都是写新手级的小功能， 有个 main method ，要使用者从 console input 一堆东西， 然後我去印出对应的结果。 因为我不可能找出我当初到底写什麽，所以我举假想例子。 ----------------------------------- 比方说新手入门题， 停车场收费一小时五十块，三小时以上打九折，六小时以上打八折， 使用者输入停车多少分钟我帮他算出他要付多少钱，未满一小时的算一小时。 （不要小看新手入门题， 你以为我现在写的小单元除了画面漂亮点， 需要存档到 DB 以外， 逻辑上到底比这个东西复杂到哪去？） 这时候我就要开始写程式啦，我用虚拟码写，大家将就着看。 main(){ //假设使用者输入一行资料（停车几分钟）并转数字 //并假设使用者都是善良user，不会输入英数字 int k = console.getInt(); int hours = ceil(k/60) ; //除60并且无条件进位 int money = 50 * hours; print(money); } 这时候我发现，我写程式我需要程式他到底会怎麽作， 我需要知道使用者输入数字时系统要回传什麽， 於是我会开始累积测资： user input : 1，系统应该回应： 50 user input : 61，系统应该回应：100 user input :121，系统应该回应：150 够眼尖跟够经验的都知道，一开始的测资， 不可能这麽机车刚好都在边界值，一定都是顺手乱打， 所以上面的测试资料是有作弊的，是我花时间想过的结果， 要能够作到这麽机车的测试案例，都是需要我用脑袋想的。 所以，换句话说，如果我没有想到有其他可能性，我就不会去测他。（窃笑） 我没有要表达什麽，就只是陈述一件事情。:) ----------------------------------- 所有写过程式的应该都知道我在讲什麽，以上面的例子， 每改一段 code ，你可能就会key 1，key 61 来测系统回应对不对。 ----------------------------------- 然後眼尖点的，会发现我刚刚的程式码有bug，测到 181 的时候会出事， 但是我一开始写完时没有想到要用 181 的测试资料去测试， 那这只就会是 bug ，一直到使用者测试， 并真的碰到这条件了，我才会知道。 ----------------------------------- 如果你有写程式经验或者看到别人的介绍， 你大概这时候会期待我说抽 method ， 写 unit test ，跑 unit test。 但是我说了，我只是分享我的经验， 而我的经验是，我一开始会宁可用手打。 因为我刚写程式很兴奋，跟 console 多点互动会有满足感。（咦） 有时候自己当当假想中的蠢 user 其实是蛮爽的（无误）， 一开始就要把东西变成一版一眼的 input/output 其实蛮无聊的。 什麽可靠性阿，什麽稳定性阿， 我还不是要花时间想一堆很机车的测试案例， 我後面可能还有别的好点子要做，这功能随便就好啦。 最後还不是活人要用，我当当活人测测有什麽不好？ （注：我这里隐含一个判断是，这段程式码我对他很有信心不会错， 或者说我认为我对他的操作已经涵盖大部分的使用情境， 我对他在大部分的状况下有信心。 另外我假设这里有逻辑 bug 并不会导致使用者或我散尽家财， 不然写个程式一下就因为 bug game over 对新手也太可怜了。XD ） ----------------------------------- 结果这东西就上线给使用者用了， 糟糕，使用者回报输入超过三个小时有问题。 简单嘛，小问题，我改改 int hours = ceil(k/60) ; //除60并且无条件进位 int money = 50 * hours; if( hours > 3) { money = money * 0.9; } print(money); ......... 我又打了一次测试资料，然後我只有个模糊印象记得我上次测啥， 好像有 1 61 121 ， 糟糕，那这次要测什麽？ 还好使用者有告诉我 188 是有问题的， 耶我不用自己想测试案例，真开心。 （使用者在你背後，他非常火） 那我心内 OS，我之前测过 1 跟 61 记得都好好的，这次也没改多大， 我这次只有改一点点，打个 121 算数确定（我有信心）没改多大就好， 然後再测测 188 ，正确。（你安心的过板跟跑去回使用者信） ----------------------------------- 然後，就没有然後了。 ----------------------------------- 如果你有认真看程式码，你可能会问我，那使用者停车超过六小时咧？ 那 bug 就放着不管吗？？ 对，因为这个停车场是一个内用限时三个半小时餐厅， 并且不准外人停车的停车场， 所以上线以来没有使用者会停车超过六小时的情境。 （欸，你这也凹太大了吧...那你题目订个屁啊。） 囧，（假想的）餐厅老板就在我写完程式後， 才订了这个内用不能太久的规定。 我写程式时也刚好恍神没想到这条件，怪我罗？ ----------------------------------- 以上案例真的就结束了，跟测试的关系是？ 1.测试资料跟希望的测试结果是人想的，而且它是测试中最重要的部份， 而且更重要的是，不管写不写 unit test 或什麽鬼 test， 这都是你的责任。 测试不会因为你有作就自动变满分，决定测试成效的人是你。 另外，因为你跟其他写程式的人终究都还是个人， 你可能写久了就不会像刚刚那个程式开发者（我）那麽散仙， 连题目有写的条件都忘记要写要测，但是你还是可能会打错字但没测到。 2.以测试而言，经过市场（使用者）测过的东西是以结果而言最可靠的， 因为过了那关其实你也就不用太介意别的东西了， 六个小时以上会有问题，so what ，反正现在能用， 以後用餐时间规定又改了也不是你的错，总有人会去 debug 。（囧） 但是因为使用者跟後面接手的开发者会生气说你坏话， 所以作人还是要自我要求一下，只是那就无关「目前」的产品品质。 而是「未来」的产品品质，所以如果一个产品没有未来... 当然，现实世界这种好事不多， 多得是上 production 之後，题目没写到的潜规则跑来找你麻烦。 3.test 我们本来就在做了，没有开发者不需要作 test。 ----------------------------------- 因为我下午有事要出门，就先卖个关子， 晚上再来写（二），预计会写到三、四篇， 请大家轻松看待这个系列文章，不要太严肃。XD 我不预设任何立场，只是分享经验，以工程师看软体测试而言， 会看见什麽东西，更多的是你宁愿相信什麽。:) 注意，我这里讲的都是工程师自己如何作/练习软体测试， 不是一个专案要怎麽测试，怎麽确保专案上线有品质，那是两回事。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 111.80.200.204 ※ 编辑: TonyQ 来自: 111.80.200.204 (03/24 13:46) ※ 编辑: TonyQ 来自: 111.81.205.78 (03/24 21:30) ※ 编辑: TonyQ 来自: 111.81.205.78 (03/24 21:31)