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

看板Soft_Job作者derekhsu (華麗的天下無雙)時間12年前 (2012/05/28 21:06)推噓12(12推 0噓 119→)

留言131則, 17人參與討論串15/20 (看更多)

※ 引述《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

05/28 21:18, , 1^F

05/28 21:18, 1^F

→

derekhsu

05/28 21:19, , 2^F

05/28 21:19, 2^F

→

superpai

05/28 21:22, , 3^F

05/28 21:22, 3^F