為什麼軟體開發者需要在意軟體品質指標 11

作者: derekhsu (華麗的天下無雙) 看板: Soft_Job
標題: Re: [心得] 為什麼軟體開發者需要在意軟體品質指標
時間: Mon May 28 21:06:17 2012

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

TonyQ，不要亂扯，我現在必須要用這麼嚴重的話，來阻止你這一連串顛三倒四的文章。

你自己翻一下你前面的文章，你的Test Case根本就跟Automation Test混在一起亂用。
我看過你一些過去的文章，我對於你Javascript的專業是尊重的，但我已經開始懷疑你
在測試領域的專業性。

Test Case不是「你可以定義的」。Test Case是軟體工程的專有名詞，世界共通，不是
你定義，或是Zk定義的。

隨便用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」。

不要把在Unit Test的Framework中的Class Name「Test Case」扯進來。你完全弄混了。

我在猜測你說「人工Trigger Test」是什麼意思，很抱歉，因為你的定義跟世界的人
都不太一樣，你是不是指透過CI make build的時候不啟動自動化測試，而是採用人工
的方式啟用自動化測試。

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

你有沒有發現當你自己必須不斷的對自己的名詞作解釋，因為有一大堆人看不懂的時候，
其實不是因為別人大家看不懂，而是因為你在亂用？

「不用 unit-test 是因為還有 integration test，」這句話也莫名其妙。
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:理工人看上下文決定一個詞的意義的能力好差啊..           05/28 21:18
→ derekhsu:專有名詞就是專有名詞，還有在用上下文決定的             05/28 21:19
→ superpai:來念念社會科學就知道了 每個大師的馬克思都不一樣        05/28 21:22
推 lunastorm:推這篇，理工人本來就講求精準，不要混為一談            05/28 21:36
※ 編輯: derekhsu        來自: 175.182.34.146       (05/28 21:39)
推 ledia:不過 T 大講的我看得很順耶, 難道有平行世界 ? XD            05/28 21:47
推 searcher:d大發一下test case的ROI啊...這東西真的很難衡量orz      05/28 21:48
→ TonyQ:基本上我覺得只有你看不懂。                                05/28 21:48
→ TonyQ:我也嚴重的拒絕你的警告，名詞是用來閱讀的，我可以修改名詞  05/28 21:48
→ TonyQ:、用詞，但這跟你所謂顛三倒四是完全兩回事。                05/28 21:48
→ TonyQ:我的論點完全就是強調用「撰寫 test-case 」的方式可以有效   05/28 21:49
→ TonyQ:降低開發時間，你如果舉不出對這個論點的反駁，你要說我在    05/28 21:49
→ TonyQ:顛三倒四就沒有什麼公信力。                                05/28 21:49
→ TonyQ:我必須承認我對測試領域並不算專家，我只是用了三年，但這裡  05/28 21:49
→ TonyQ:並沒有要求要是專家才能發言，我並不排斥你說我不專業，但是  05/28 21:50
→ TonyQ:我想回頭問你，那請拿出你的專業來駁斥我內文論述錯誤的部份  05/28 21:50
→ TonyQ:另外你給出的定義我在 #1FmUa9qQ (Soft_Job) 第四頁就提過了  05/28 21:51
推 ledia:別生氣, 有些人覺得 well-defined 比較重要                  05/28 21:51
→ TonyQ:test-case 是自己準備好 input - output ，                  05/28 21:51
→ TonyQ:去驗證可預期的資料範圍內出什麼事情。                      05/28 21:51