作者TonyQ (沉默是金。)
看板Soft_Job
标题Re: [闲聊] 写系统的人最无法忍受别人唬弄
时间Wed Mar 31 22:46:58 2010
※ 引述《Ting1024 (无)》之铭言：
: → TonyQ:网站都很难反覆测试啦，而且test case也很难写。 03/31 22:26
: → TonyQ:这是个还有发展空间的领域。 03/31 22:26
: → derekhsu:T兄，其实这也不见得. 03/31 22:30
: → TonyQ:咦，楼上有没有什麽好妙计。这问题已经苦扰我好几年了XD 03/31 22:31
: → derekhsu:网银有验证码没错，但难道他们没建测试平台吗？ 03/31 22:31
: → derekhsu:测试平台的验证码是可以Pass的 03/31 22:31
: → derekhsu:网站其实算很容易反覆测试的，因为网站有共同的介面 03/31 22:32
: → derekhsu:不同的程式语言开发的网站，在整合/回归测试阶段 03/31 22:33
: → derekhsu:很多自动化测试工具都能完成网站的测试，甚至AJAX 03/31 22:33
: → derekhsu:但是GUI的东西，就必须要抓到Componment 03/31 22:34
: → derekhsu:能作到这样的Tools都还满贵的就是了 03/31 22:34
这是个值得讨论的话题，我目前时间不多只能简单带一些意见。
我先带一些我讨论的问题背景
1.要达到自动化简测 （纯人工检测不考虑）
2.网站的内容没有固定格式
3.开发者（或者测试团队）可以参与撰写 test case
-------------------------------------------------------------
GUI甚至是应用程式的逻辑测试，
其实型别检测比较严谨的状况下，unit test是比较好写得。
以 structs+spring+hibernate 的开发为例，
测试 orm DAO 的working , 测试 action 的各个可能的结果页面导向，
js 也有 js unit可以处理，
不过因为js牵扯到页面资讯的效果，测起来并不容易。
这都是比较不困难的，至少也是我曾经参与的专案有去试着进行过得。
目前我所看过得网站自动化简测，其实只有失联连结检测，
再来就是 js unit，还有我刚说的 seleniumhq 可以模拟browser行为，
透过操作 firefox 来达到行为单元测试。
那难点在哪，第一就是有验证码的页面会过不去，
因为他是模拟browser行为，所以比较棘手。
d大提到一个这个问题的常见解决方案，用测试环境造假讯息，直接让他pass，
不过这样的动作因为跟真实环境比起来是相对失真，
其实有时候在写这些虚假讯息的时候也会 miss 掉很多该注意的事情，
不过相对之下这的确是一个值得去做的方法啦。
第二就是其实网站的行为很难说成功与否，
有时候是反应比较慢，有时候效果是复杂多变的，
有时候是与使用上的习惯不符，而不是内容上的错误。
另外就是 test case 要写多细的问题。（这所有test类的问题都会碰到。XD）
我个人是认为 web 的功能太细了，要为他写 Test有点不划算，
但是不写又常常东一包西一包的。
我目前是比较倾向於设计并重复利用元件，因为反覆经过锻链，
自然会有比较好的表现，而且错误率也会比较下降。
--
其实这一块真的是很困扰的，所以如果有比较好的作法真的是帮助很大。XD
--
I am a person, and I am always thinking .
Thinking in love , Thinking in life ,
Thinking in why , Thinking in worth.
I can't believe any of what ,
I am just thinking then thinking ,
but worst of all , most of mine is thinking not actioning...
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 220.133.218.161
1F：推 Adonisy:推一个 03/31 22:49
2F：推 derekhsu:所以Web的QA真的是挑战^^ 03/31 23:12
3F：→ TonyQ:这个问题我已经想很久了，真的是想不到什麽简单的方法...... 03/31 23:15
4F：→ derekhsu:这就跟QA的功力有关了 03/31 23:22
5F：→ TonyQ:没错，另外我个人是强烈反对自写自测，盲点太多了。 03/31 23:24
6F：→ TonyQ:（我指的是正式的QA编制，个人写完程式的自我测试还是要有。 03/31 23:25
7F：推 Adonisy:自写自测只是为了防止低级错误... XD 03/31 23:25
8F：→ TonyQ:我看过有把自写自测作为防制所有bug的公司.当时建议公司至少 03/31 23:26
9F：→ TonyQ:请个工读生来帮忙按按按钮也好，主管为了节省成本结果自己跳 03/31 23:26
10F：→ TonyQ:下去测。真不知道该说什麽。 03/31 23:27
11F：→ TonyQ:不过这就是题外话＋抱怨文了就是了。後续应该不难想像。XD 03/31 23:27
12F：推 chihyi1980:想不到连这种话题都能扯上一长串..XD 03/31 23:47
13F：→ sazabijiang:而且就这个讨论串的case, 这算是逻辑bug, 不易测出 03/31 23:49
14F：→ sazabijiang:网银後端会连结多个不同的主机系统, 沟通桥梁可能是 03/31 23:49
15F：→ sazabijiang:MQ或者其他介面. 即使讯息都能正确往返, 如果没有人为 03/31 23:50
16F：→ sazabijiang:监测, 可能会得到格是正确的错误内容... 03/31 23:50
17F：→ sazabijiang:举个例子, 网银一定会连结存款主机, 偏偏存款主机是 03/31 23:51
18F：→ sazabijiang:被一堆周边系统连结着, 比方说你写个透过网银转帐的 03/31 23:52
19F：→ sazabijiang:自动化测试剧本, 但是存款系统是另一个系统, 要先透过 03/31 23:53
20F：→ sazabijiang:存款系统把钱存进去, 你在网银才有钱可以转出.... 03/31 23:53
21F：→ ledia:自动的 web test 工具越来越多, 就算只是比对固定操作抓个 04/01 00:08
22F：→ ledia:工具用一用也不会花多少时间 04/01 00:08
23F：推 luciferii:验证值的部分，常见的不是先人工 Login一次，然後反覆利 04/01 00:36
24F：→ luciferii:用已抓到的session cookie作後续测试吗? 04/01 00:36
25F：推 ledia:差不多, 就是 record and replay, 还可以程式化 04/01 01:01
27F：推 itsfreya:e-ATM就整个交易流程来说，如果能以自动化测试=不合格阿~ 04/01 01:56
28F：→ TonyQ:通常会去做自动化测试的不是「整套流程」.而是各子流程 04/01 09:03
29F：→ TonyQ:ledia 有keyword吗 XD 04/01 09:04
30F：推 ledia:wikipedia for "web testing" 我还用过 M$ vsts 的 webtest 04/01 10:35
31F：→ TonyQ:ok thanks a lot ^^~ 04/01 10:39
32F：→ xlk:sazabijiang说的问题在unit test能用mock类工具处理的 04/01 19:59
33F：→ xlk:test case coverage当然是Design by contract符合80/20rule 04/01 20:20
34F：推 itsfreya:楼楼上，我指的是交易流程。MS曾经来我们公司对某个专案 04/01 20:30
35F：→ xlk:整合测试的自动化剧本要是涵盖的功能模组太多时只会是场恶梦 04/01 20:31
36F：推 itsfreya:技术简报兼推销vsts，但是自动化测试能用得很开心 04/01 20:34
37F：推 itsfreya:表示网站被机器人模拟操弄越的越轻松阿... 04/01 20:37
38F：→ xlk:请问楼上不合格的理由是？有什麽风险吗？ 04/01 20:46
39F：推 itsfreya:类似e-ATM网站交易验证的前提，就是只允许"真人"操作阿 04/01 20:51
40F：推 netburst:没错 不然验证码早就被 04/01 21:58
41F：→ xlk:自动化目的在检验系统本身，这应该是两回事吧？确认是否真人 04/01 23:24
42F：→ xlk:应有其它机制处理，像上述的验证码的子系统。 04/01 23:27
43F：→ xlk:更正：自动化测试目的是取代系统已知行为的手动测试常态工作 04/01 23:38