前情提要，这是写给软体开发者的测试历程， 在笑谈软体测试的几个阶段（一）中我们提到测试的基本形式， 主要是以我自己进入测试的经验说明如何进入测试门槛， 以及我身为软体开发者进行软体测试时需要知道的事情跟可能的心路历程。 所有的内容都只是个人经验仅供参考，欢迎提供意见分享跟挑战。 ----------------------------------- 另外这里所指的软体测试都只是主要针对者自己对软体的测试， 而与专案测试（目的为增加专案品质）的目的并不直接相关。 也就是说，这里讲的主要目的，是开发者如何可以在开发过程， 快速验证自己的修改是否有误跟常见的一些问题。 ----------------------------------- 本文开始 ----------------------------------- 就像先前的停车场计费程式，我们慢慢写了很多程式， 慢慢的会发现修改程式码是我们常做的，不论是修 bug 也好、做新功能也好， 我们每次修改完之後都需要进行测试程序。 ----------------------------------- 假设现在我们在做一个部落格系统好了， 我今天已经写好後台可以发文， 发文时我需要提供编辑器给使用者输入， 还要让使用者可以做一些删除或修改的操作。 ----------------------------------- 我们一开始开始会一直用测试的『完整环境』做测试，（重点一） 测试程式码的运作，然後我开始发现，测试有点麻烦。 某些重复的程式片段我会发现我测试很多次， 有时是它很重要跟复杂，像发文的编辑器特别容易出问题或修改； 有时则是它很重要大家都要用，像是很多功能相依於会员登入。 这些片段改程式码特别容易测到， 就每次都在测一样的程式，感觉就很琐碎而无聊， 特别是登入，我可能根本就没有改那段code，为什麽我要测他？ ----------------------------------- 然後很重要的是，我也不总记得上次的测资，应该说，我很有可能会忘记。 （重点二） ---------我的现况是这样，看起来是个困境，那我怎麽办??--------- 你可能还是会期待我会说拆 method 跟 unit test ， 然後补一句视状况采用跟引入这种我自己也觉得有讲等於没讲的废话。 好像这样事情就结束了，这些话我很常说，它是政治正确的， 但问题是，听的人在这些话的讯息中收到什麽。 平常讲话是真的没办法，因为三言两句我也讲不出个屁， 要讲经验我後面有一票的前提论述要讲， 还要先看看对方用的语言我有没有经验，像讲 C++ 的测试我就囧很大。 要讲故事没个五六小时是讲不完的，不过写文章就不一样了。 我写文章很重视实战，就是因为这种东西只有实战体验过， 你才会有点体悟那些心法在干嘛。 特别是这种心法是可以各自表述。 举个例子，今天有人说『你写的 java 程式不 OOP』， 你真的能从『不 OOP』这四个字知道他想表达什麽，要怎麽修正吗？ 你可能会因为这样赌气跑去读 OOP 的书， 然後试着把学到的东西用到你专案，多用了几个模式跟切分类别， 然後很开心的说我程式更 OO 了。（事实上是不是就另外一回事。） 结果你可能一辈子不会知道， 人家只是在嫌弃你写类别时没有写 Getter/Setter 。 (注：这曾经是 OOP 议题中很重要(无聊)的争论之一) http://0rz.tw/3T9d0 拿心法等级的名词互相 PK ， 大概也是赶云端流行的一种做法，我是觉得作事不用这麽复杂啦， 有时你必须承认我们真的很难明白别人的明白。 因为他们的经验跟心法，不是你的经验，而且测试是一体成形的。（後述） ----------------------------------- ----------------------------------- 扯远了，拉回主题。 ----------------------------------- ----------------------------------- 我们刚刚有个困境，那我们现在要来试着改善他了。 注：改善的过程不见得每个方法都是好的， 但我的信念是有尝试就是好事，有尝试就会有收获跟所得。 ----------------------------------- 我是懒惰的人，我痛恨无聊、重复而且不必要的事情。 我宁愿花五倍的时间写个有趣的 template ， 我就是不想乖乖好好一行一行 cp 当 code gen。 我写程式的心法就是上面这句话。 （觉得这样是好是坏是个人自由啦， 有时候它真的可以省事，有时候它又会误事。XD） ----------------------------------- 首先我是想办法设计成，我自己测试时可以跳过登入页面， 我尝试设定，「测试环境」启动时在session 先塞测试帐号假装登入， 以 java 来讲就是写 filter ， 以 php 来讲就是先 include 一只php。 (从这里我们可以看出语言支持度跟特性会影响开发习惯很多。) 这样的确很有效，我瞬间省了好多测试时间， 但问题来了，如果我上线时忘记把测试程式拿掉就完蛋了。 所以我要想办法建出 debug 环境， 正式一点的会有设定档，或是利用版本控制系统设 ignore 。 不正式一点的就是放档案弄脏 workspace 自己小心不要弄错。 但是即使是最蠢的方案都可以帮我每天开发， 省下几分钟到一两小时的测试过程登入的时间。 Ok , it works. 但是这样也有别的缺点， 1.它跟真实的环境有出入 2.要是登入真的坏掉了你也不会发现 3.你要小心不要弄错环境XD 4.如果登入的程式码有变的话，你可能也要跟着修改。 ----------------------------------- 测试资料的管理的部份，我会在程式码中留下测试资料的注解， 特别是 regular expression ， 没留下测资我大概过个两天大概就不知道我自己在写杀小。 还有就是善用 issue tracker 跟版本控制系统留下纪录。 所以当这些纪录薄弱时， 我们也会特别倚赖团队中资深成员进行「观落阴」， 从无边地狱中用力回想当初的测试情境。 最後真的不行就是走逆向工程，他会用到什麽， 你就想办法整他恶搞他自己想办法丢东西测。 ----------------------------------- 我们第二篇的案例先讲到这， 至於那些异动频繁的程式区块，我们留到第三篇谈。 ----------------------------------- ----------------------------------- ok， 第一篇我们讲的是一个简单的范例， 第二篇我们讲的是复杂的范例， 从第二篇我们谈到的事情里面，有哪些测试的要素？ 1.测资的问题 我们第一篇强调过，测资是一切的根本， 而这篇我们开始提到，测资是需要被管理的， 测资的有效/可靠程度就跟你程式的稳定程度跟开发效率成正比。 2.测试路径问题 每个测试的过程中你需要作的操作，我称之为测试路径。 测试路径决定你的测试效率。 最佳化你的测试路径是开发过程中很重要的事情。 （像是想办法把登入这个过程跳过） 这其实不只是程式码的问题，比方说你 server 启动要十分钟， 那你就应该挑一个 server 启动快一点跟方便一点的设计。 3.文章中有特别对「完整环境」这件事情下重点 在测试的范畴里面，我们把最接近使用者的环境测试， 也就是 dev server 或 dev environment ， 称之为整合测试。 (Integration test) 这种状况下，你有可能被其他的因素干扰， 举例， db 如果挂了你登入可能就就整个没办法测试。 整合测试的重点在於他是尽量要达到测试最接近真实的情境。 当然这里我们还没有要对 unit test 跟 integration test 多着墨， 但是我想说的是，通常我们一开始进行的测试都是整合测试为主。 为什麽会这样，我们之後的章节会继续探讨。 ----------------------------------- 下一篇，我们将延伸这篇的主旨， 继续探讨其他案例下，测试路径跟测资的问题。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 111.81.205.78 ※ 编辑: TonyQ 来自: 111.81.205.78 (03/24 23:16) ※ 编辑: TonyQ 来自: 111.81.205.78 (03/24 23:16) ※ 编辑: TonyQ 来自: 111.81.205.78 (03/24 23:17) ※ 编辑: TonyQ 来自: 111.81.205.78 (03/24 23:21) ※ 编辑: TonyQ 来自: 111.81.205.78 (03/25 01:06) ※ 编辑: TonyQ 来自: 111.81.205.78 (03/25 01:08) ※ 编辑: TonyQ 来自: 223.143.225.151 (03/25 22:51)