Re: [心得] 為什麼軟體開發者需要在意軟體品質指標

[derekhsu (華麗的天下無雙)]

※ 引述《TonyQ (自立而後立人。)》之銘言：
: ※ 引述《semop (semop)》之銘言：
: : 看來看去，明明從頭到尾就是在講 unit test 的 automation 啊。
: : test case 到底是哪來的名詞?
: : 我覺得這根本就像是知道了一個"新"方法，然後就狂熱提倡的言論，
: : 還真以為我們這種老人不知道啊?
:         我說得其實是「寫test-case」這件事情。
:         不用 automatic tests 是因為他不見得需要 automatic test ，
:         很多時候我們是手動 trigger 這些 test。
:         不用 unit-test 是因為還有 integration test，
:         所以挑了一個比較中性的詞「寫test-case」來說。
:         當然，如果你看不懂這個詞，我可以再定義清楚一些，
:         寫「用程式可以跑得測試」。


隨便用Google查一下都可以查到成千上百個Test Case的定義，我附在最後面你可以
自己看，也許它們之間有點差距，但絕對不會是像你定義的這樣子。

最簡單最簡單的來說，

「Test Case是一組已經定義好的輸入、輸出以及操作步驟，提供測試者用已確認程式
是否如常運作。」

Test Case可以Manual Test或Automation Test，Manual Test就是透過人工操作所有的
測試步驟，而Automation Test就是透過程式自動化所有的操作步驟，另外還有比較少人
提到的半自動測試，就是混和自動化測試以及人工測試，跟是不是用程式跑得毫無關係。
絕大部分的Test Case都是文件化的東西。「Write test case」是寫測試案例文件
或是腳本，他的產物是Excel、Word，或是另外某些管理Test Case的工具（ex silktest)
Write automation test case才是寫自動化測試案例。你用Google查圖片甚至還有Sample
給你看，什麼叫做「寫Test Case」。


在某些公司有QA，Test Develper的編制，QA負責撰寫Test Case，而Test Develper
將測試案例自動化，不是所有的Test Case都有自動化的價值，這跟自動化的ROI有關
，由於有時間與資源的限制，Automation Test不是萬靈丹，這個我若有空會談如何
評估Test Case的ROI。

unit test跟integration test是「測試階段/範圍」兩者之間沒有任何衝突。
unit test針對的是程式碼層級。
integration test是系統層級。

Test Case一般也是指integration test層級的測試，不過少數也會用在unit test層級
上面。
Automation Test一般是用在integration test層級的測試。


Test Case(測試案例)
from wiki
http://en.wikipedia.org/wiki/Test_case
A test case in software engineering is a set of conditions or variables under
which a tester will determine whether an application or software system is
working correctly or not. The mechanism for determining whether a software
program or system has passed or failed such a test is known as a test oracle.
In some settings, an oracle could be a requirement or use case, while in
others it could be a heuristic. It may take many test cases to determine that
a software program or system is considered sufficiently scrutinized to be
released. Test cases are often referred to as test scripts, particularly when
written. Written test cases are usually collected into test suites.

Test Script(測試腳本)
http://en.wikipedia.org/wiki/Test_script
A test script in software testing is a set of instructions that will be
performed on the system under test to test that the system functions as
expected.

There are various means for executing test scripts.
 Manual testing. These are more commonly called test cases.
 Automated testing Short program written in a programming language used to
test part of the functionality of a software system. Test scripts written as
a short program can either be written using a special automated functional
GUI test tool (such as HP QuickTest Professional, Borland SilkTest, and
Rational Robot) or in a well-known programming language (such as C++, C#,
Tcl, Expect, Java, PHP, Perl, Powershell, Python, or Ruby).
 Extensively parameterized short programs a.k.a. Data-driven testing
 Reusable steps created in a table a.k.a. keyword-driven or table-driven
testing.


These last two types are also done in manual testing.

http://www.hudong.com/wiki/test+case
test case - 基本定义
Test Case

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结
果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件
产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试
环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。


test case - 区别
不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软
件的用户需求更加不统一，变化更大、更快。

What is Test Case? How to write a good test case?

What is Test Case? How to write a good test case?
Post to: IpadIt! | digg It! | del.icio.us | Reddit

Test Cases are the implementation of a test case design which will help the
software tester to detect defects in the application or the system being
tested. This should be the primary goal of any test case or set of test
cases. When I write a test case, I think of both types of test cases,
positive test cases and negative test cases. Positive test cases are those
which execute the happy path in the application and make sure that the happy
path is working fine. Negative test cases as the name suggests are
destructive test cases which are documented with some out-of-box thinking to
break the system.
A Test Case should be documented in a manner that is useful for the current
test cycle and any future test cycles. At a bare minimum each test case
should contain: Sr No, Summary or Title, Description, Steps to reproduce,
Expected Results, Actual Results and Status of the test case or remarks.

Test Case Summary or Title

The Summary or title should contain the essence of the test case including
the functional area and purpose of the test. Using a common naming convention
that groups test cases encourages reuse and help prevents duplicate test
cases from occurring.

Test Case Description

The description should clearly state what sequence of events to be executed
by the test case. The Test Case description can apply to one or more test
cases; it will often take more than one test case to fully test an area of
the application.

Test Case Steps to reproduce

Each test case step should clearly state the navigation, test data, and
events required to accomplish the step. Using a common descriptive approach
encourages reuse and conformity.

Expected Results of Test Case

The expected behavior of the system after any test case step that requires
verification / validation - this could include: screen pop-ups, data updates,
display changes, or any other discernable event or transaction on the system
that is expected to occur when the test case step is executed.

Status or Remarks

The operational status of the test case - Executed or not executed etc.

Also check Test Plan, Defect-Bug, and Status Report

--
所有我的作品，請到.....
～四十八個德瑞克～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
→ superpai:理工人看上下文決定一個詞的意義的能力好差啊..
→ derekhsu:專有名詞就是專有名詞，還有在用上下文決定的
→ superpai:來念念社會科學就知道了 每個大師的馬克思都不一樣
推 lunastorm:推這篇，理工人本來就講求精準，不要混為一談
※ 編輯: derekhsu        來自: 175.182.34.146       (05/28 21:39)
推 ledia:不過 T 大講的我看得很順耶, 難道有平行世界 ? XD
推 searcher:d大發一下test case的ROI啊...這東西真的很難衡量orz
→ TonyQ:基本上我覺得只有你看不懂。
→ TonyQ:我也嚴重的拒絕你的警告，名詞是用來閱讀的，我可以修改名詞
→ TonyQ:、用詞，但這跟你所謂顛三倒四是完全兩回事。
→ TonyQ:我的論點完全就是強調用「撰寫 test-case 」的方式可以有效
→ TonyQ:降低開發時間，你如果舉不出對這個論點的反駁，你要說我在
→ TonyQ:顛三倒四就沒有什麼公信力。
→ TonyQ:我必須承認我對測試領域並不算專家，我只是用了三年，但這裡
→ TonyQ:並沒有要求要是專家才能發言，我並不排斥你說我不專業，但是
→ TonyQ:我想回頭問你，那請拿出你的專業來駁斥我內文論述錯誤的部份
→ TonyQ:另外你給出的定義我在 #1FmUa9qQ (Soft_Job) 第四頁就提過了
推 ledia:別生氣, 有些人覺得 well-defined 比較重要
→ TonyQ:test-case 是自己準備好 input - output ，
→ TonyQ:去驗證可預期的資料範圍內出什麼事情。
→ derekhsu:#1FmUDIQi 你自己翻這篇文章，比把test-case當成什麼
→ derekhsu:如果你 test-caes 寫得時候想不到，你「手動測試」時也想
→ derekhsu:不到。相對手動測試是自動化測試
→ TonyQ:我那篇文章講得一樣是「給定input-output的一種形式」，手動
→ TonyQ:測試類比是無亦是的隨意測試。
→ TonyQ:就算是自動化測試一樣是一種 test-case 這並無錯誤。
→ TonyQ:難道把自動化測試的 unit test 說成 test-case 是錯得？
→ TonyQ:integration test 說成是 test-case 是錯得？
→ TonyQ:這兩者本就是 test-case 的子集。
→ TonyQ:我想你的爭議點是手動測試也可以說是一種測試案例，ok 廣義
→ TonyQ:上來說他的確也可以是，那我那句話就可以修改成自動化測試對
→ TonyQ:手動測試來得有效率，一樣無損我論點的中心。
→ TonyQ:所以我完全看不懂你到底用哪一點來說一個人的文章顛三倒四。
→ derekhsu:你還是完全沒有搞清楚
→ TonyQ:我想我不需要清楚你的明白。
→ TonyQ:^那
→ derekhsu:自動化測試跟手動測試是測試案例的執行方法，不是子集
→ TonyQ:那你的警告你就自己吞回去吧，因為我看不懂你的意見。XD
→ TonyQ:感謝你的意見，但是我覺得那沒什麼參考價值，就醬啦。:P
→ derekhsu:反正我已經貼出來Ref了，看不懂英文是你的事
→ TonyQ:我對這個 ref 不屑一顧，那並非我們平常慣用 test-case 這詞
→ derekhsu:我想你受過正式的QA訓練之後，會比較知道自己寫什麼
→ TonyQ:的用法。你要 follow 這個定義是你的事情，但不關我的事情。
→ TonyQ:我很歡迎你提供何謂正式 QA 訓練，何處可以受正式 QA訓練，
→ derekhsu:你們？哪些你們？是Zk還是誰？Google成千上萬文章是少數?
→ TonyQ:甚至是你正式 QA 訓練中，跟我前述論點有關的部份，
推 ledia:疑問: 是要受過正式 QA 訓練才能討論測試嗎 ?
→ TonyQ:但就 test-case 這個名詞，我覺得那不是問題的核心。
→ derekhsu:不用，但弄清楚基礎名詞再來討論才有價值
→ TonyQ:我無意在這個名詞上跟你多打轉，你要認為我不用那個定義就不
→ TonyQ:專業我無所謂，但是這樣的討論有沒有價值恐怕也不是你可以定
→ TonyQ:義的。你不就論點討論只針對名詞，這是一種很有趣的狀況。
→ TonyQ:更何況，你自己都表達出你可以讀懂我想講什麼了，這就更有趣
→ TonyQ:了。
→ derekhsu:你錯誤的名詞誤導一般對QA不專業的人，這是對的嗎？
→ TonyQ:我們是誰喔？好啦，我說我們是有點多了。就「我」吧。:P
→ ledia:每個人都有自己的角度 有何誤導可言
→ derekhsu:不，我不懂，我是看過你後來自己的解釋才懂
→ ledia:不過就是討論而已, 沒有人會奉為圭臬吧
→ TonyQ:我很感謝你出來澄清這個名詞，這很重要，這點我必須說感謝你
→ derekhsu:就如同多型、繼承，都有專有的定義，測試也是一樣
→ TonyQ:提供資料。這的確是沒有話說。但是我只能說，以我討論的方式
→ MasterChang:TonyQ寫的東西，我這種外行都知道怎麼回事。不過你的
→ TonyQ:跟論點，我寧願繼續誤用，因為這樣比較方便溝通，懂嗎？
→ MasterChang:文章我完全看不懂你想表達甚麼？
→ derekhsu:並沒有，一般業界對Test Case定義就是跟你不同
→ derekhsu:當你用國際的的一般觀點去看你的文章，就會變得不倫不類
→ TonyQ:我覺得我無意在這個論點上打轉，你等我一下我重新更正所有
推 ledia:只要討論的人看得懂就好啦 你是要去投國際期刊噢? XD
→ TonyQ:用到 test-case 的這個詞，然後我希望你可以回歸文章主旨討
→ TonyQ:論。
→ derekhsu:我也想，如果能夠標準的定義，我很樂意溝通
→ derekhsu:先有Case，才有Automation，如果你把Test Case當成
→ derekhsu:Automation Test來用，那Case在哪裡？不規劃就寫程式嗎?
→ derekhsu:這就是將Test Case跟Automation Test混用的發生的問題
→ TonyQ:好的，我改了所有的用詞，把你所謂的案例改成實作，但基本上
→ TonyQ:這並沒有損及我任何論點，只是我們對名詞認知不同。=____=
→ TonyQ:我是不覺得這很嚴重，但是既然有人有意見我就拿出誠意修改，
→ TonyQ:現在你可以回來討論一下那幾篇文章的內容嗎？我覺得這才是我
→ TonyQ:在乎的。=3=
→ derekhsu:我是覺得很嚴重，我都拿Ref出來了，還不夠客觀嗎？
→ TonyQ:btw 哪裡有在上QA 的正式訓練我倒是蠻有興趣去上的...
→ TonyQ:@derekhsu 這點我覺得就算了，我都順你意思改了，嚴重就嚴重
→ TonyQ: 吧，讓我們回歸議題本身討論。之後提到 test-case 我會用你
→ TonyQ: 定義。
→ derekhsu:有啦，台灣有專職養一大堆QA的公司就那幾間M社T社....
→ derekhsu:我依然確定你手動Trigger Automation是什麼意思，是CI嗎?
→ TonyQ:就是手動執行 unit test 啊...你自己挑 test-case 出來跑得
→ TonyQ:那種
→ TonyQ:CI 是定期執行吧，還是這裡也有名詞定義上的問題。>__<
→ TonyQ:我是沒受過什麼 QA 專業訓練只做實作，名詞就別考我了。XD
→ TonyQ:我重新說明那裡的論述，不管是全面性的執行所有 unit-test
→ TonyQ:，或是開發者手動只自己篩選有關的 unit-test 都可以達到
→ TonyQ:省力的效果。
→ derekhsu:你用到Selenium就是Integration Test了...
→ derekhsu:所以我不知道你unit test跟integration test到底差在哪裡
→ TonyQ:我就說我找不到一個詞同時可以包含 unit-test跟integration
→ TonyQ:test。
推 musie:我認為這種東西就跟MVC一樣 一種概念各自表述..
→ TonyQ:不見得有用到 selenium 就算是 integration test。JSunit
→ TonyQ:有一些實作是靠 selenium 作啟動的動作。
→ musie:不需要留於空泛的討論名詞定義，那對現實沒有任何意義
→ TonyQ:我認為問題是看測試對象是誰。
→ TonyQ:我對 unit-test 的認知我覺得還蠻清楚的，unit-test 是單元
→ TonyQ:獨立的，所有外界進來的東西都是 mock ，只有測試目標是實的
→ derekhsu:MVC有客觀定義啊，怎麼會各自表述, Model都有了
→ ykjiang:兩位的寫法我竟然都看得很順，我是不是精神分裂了？
→ TonyQ:integration-test 是測試多個模組之間交互運作，selenium
→ TonyQ:會被認為是 integration test 是因為他不可避免的製造了
→ derekhsu:嗯，我對JSUnit的確不懂，若是這樣確實算是Unit Test
→ TonyQ:browser 這個不穩定的外界因素，但是有些環境是用他當載體。
→ TonyQ:好啦，要勉強用 nodejs 或 rhino 來講，的確是也可以啦。~_~
→ derekhsu:還有你說的隨意測試我想起來了，那叫ad-hoc testing
→ TonyQ:good ，多學到一個名詞，謝謝～
→ derekhsu:所以你說的是automation testing vs ad-hoc testing
→ TonyQ:我重新看過，我還是更正好了。
→ TonyQ:我當初想說的應該是 automatic test vs 手動測試沒錯。
→ derekhsu:測試名詞有的沒的很多，我之前也不懂，懂了以後卻很難跟
→ derekhsu:不知道這些名詞的人溝通
→ Arminius:因為溝通前都得先吵一遍名詞解釋? 呵...
→ Ting1024:好吧，從善如流吧，用標準來對話也是好事
→ derekhsu:既然已經改了那我也修一下文好了
※ 編輯: derekhsu        來自: 175.182.34.146       (05/28 22:44)
推 andymai:感謝這篇更正了我的觀念~科學的人就該做科學的事~沒有設立
→ andymai:共同觀點的討論就像多頭發展的open source一樣難以捉摸...
→ superpai:MVC有客觀定義？有的話僅止於MVC是什麼的縮寫吧
推 littlebau:對於幾個重要的名詞.有個定義,討論起來才不會整篇都在猜
→ superpai:光是web的後端MVC跟前端MVC的View的能力就完全不同
→ guest2008:偷偷的說:我的前後台 view 能力都相同(快閃人免得被轟)
推 atpx:推~ 這篇對於test case定義說得很清楚.
※ 編輯: derekhsu        來自: 175.182.34.146       (05/29 00:55)
推 Wush978:推用標準, 標準真的很重要, 沒有標準則溝通會很沒效率
推 twk:感覺兩邊的觀點都還蠻不錯的, 只是彼此都在捍衛彼此的觀點,
→ twk:流於爭吵了~ 不然兩邊都有蠻重要東西的說~