发布新日志

  • 关于测试用例(三)

    2007-04-03 11:59:51

    Difference Between Use Case & Test Case

     

     

    S. No.

    Use Cases

    Test Cases

     

     

     

    1

    Use case is one complete flow of that module or functionality .

    Test case consist of input value with expected out put value       

    2

    Use case is given by the client

    Test case is a document to test whether the application meet customer expectations.

    3

     

     

    Use Case testing is done by thinking differently from the test case. The main Objective of testing is to see "How to Break the software"

    Test cases are written accroding to the requirements taken from the documents and that requirements are given by the client.

    4

    All use cases are not covered in Test cases but all test cases are covered in Use case.

     

    5

    The specification of tests that are conducted from the end-user perspective.

     

    Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.

     

    A use case is a technique for capturing functional requirements of systems

    Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc.

     

    A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement

    6

    Example:

     

    Use case: After entering all required data login should successful

    Example of test cases to get desired use case:

     

    1. Provide wrong user name but right
        password

    2. Provide only name without password

    3. Provide only password without name

    4. Don't provide anything and directly try to
        login

    5. Provide name and password but don't
        hit enter

    6. Provide login name and password and
        hit enter : Login

     

     

    上面是我参加 the Google Groups "Software Testing (QC) & Software Quality Assurance (QA)" group 收到的一封邮件,个人感觉挺有参考价值的,所以粘过来给大家参考一下,希望能对大家有帮助。


     

  • 关于测试用例编写(二)

    2007-02-11 12:32:50

    在(一),困扰我的问题主要是如何把Test Requriements和Test Plan连接起来。

    我们先来了解一下什么是“软件需求(software requirements)”,即“软件需求”定义

    软件需求是(1)用户解决问题或达到目标所需的条件或权能(Capability)。
           (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
           (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
            (IEEE软件工程标准词汇表(1997年)中定义)

     

    我们再来看看什么是“测试需求(test requirements)”?

    在“http://bbs.51testing.com/viewthread.php?tid=269”用举例的方式阐述什么是测试需求,而且描述得很不错(个人意见)。为了朋友们阅读方便,我把网址内容直接粘贴过来了

    Brian Marick
    测试需求的概念比较简单。例如,比方说一个计算平方根的程序,如果输入一个大于或等于零的数,程序可以给出一个结果;如果输入一个小于零的数,程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试;对零非常接近的负数进行测试,这就是两个具体的测试需求。

    在一个更加复杂的程序中,你可以将打算测试的项目做成一个列表。但是,这些测试需求都不会确定具体的测试数据。例如,一个银行交易程序,一个测试需求是试图支付客户的金额为负数,另一个测试需求是交易中的客户并不存在,等等。你有一系列这样的测试需求,它们并没有指出具体的数值或数据,如客户的姓名。

    测试的下一步是选择满足这些测试需求的输入值/测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求,当然是最理想的情况,但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例,就可以不必考虑那些复杂的测试用例,但是这些相对简单的测试用例发现缺陷的能力就会有所下降。

    这里有一个测试需求的实例:对一个哈希表的插入操作进行测试,有以下这些测试需求:
    1)插入一个新的条目
    2)插入失败-条目已经存在
    3)插入失败-表已满
    4)哈希表在插入前为空
    这些就是测试需求,而非测试用例,因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例,就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审,确保正确和没有需求遗漏。

    从上面关于“软件需求”和“测试需求”解释的内容,总结一下几点内容:

    1 它们的主要读者不一样,前者主要针对开发人员,后者主要针对测试人员;

    2 软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。开发人员一般在受限的情况下(用户需求,业务需求,非功能需求)以开发软件(功能需求);而测试人员必须参考“软件需求”内容,从各自工作的内容出发(主要白盒,黑盒,性能等)编辑出适合自己的“需求”,即是“测试需求”。

    现在既然明确了“测试需求”,那么测试人员就要开始工作,设计自己的测试用例(Test Plan),来最大化地发现软件中的BUGs。

    最后,还是那句话,请各位朋友多多提意见,小弟再此感谢拉。

  • 关于测试用例编写(一)

    2007-02-07 09:01:20

    来单位实习已经大半个月了,终于开始写自己的用例了。

    公司用工具TestDirector(简称TD)来编写测试用例,一上来就有点犯迷糊。因为在TD中,主要有四大块:

    1 Requirements

    2 Test Plan 

    3 Test Lab

    4 Deffects

    查看了关于TD的Guide,Tutorial文档,了解第二步Test Plan的编写是基于第一步Requirements的基础之上的。但是我面临的情况却不一样,老板让我直接从第二步开始写起,参考的资料就是软件需求文档中的用例。我个人觉得,这样写出来的用例只能反映产品功能行的需求,对于其他环境(再多就想不起来的了)需求就没有包括到。其实我的老板也是这样想的,但是这个Requirements到底改怎么样和Test Plan连接呢?

    也许这里的朋友或者过路的朋友能给我一个思路,嘿嘿

    当然,我也会不停探索这个问题,直到圆满解决这个问题为止。

     

     

我的栏目

数据统计

  • 访问量: 5036
  • 日志数: 7
  • 建立时间: 2007-02-06
  • 更新时间: 2007-04-03

RSS订阅

Open Toolbar