发布新日志

  • 关于测试用例(三)

    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-03-19 08:56:56

        星期五晚上熬了一个通宵,把论文的初稿终于个完成了。想想自己真是不容易,从大年初一一直到现在,论文工作持续了一个月点。自己都无法想象是怎么熬过来的。早上8点起来吃个早饭,然后在电脑面前写。然后就是中午,晚上不停在写。最痛苦的就是自己就在电脑前坐者,一个字都写不出来,头脑里面全是痛苦的语言和表情,sigh,一言难尽。
        说实话,写论文从另外一个方面锻炼了我的忍耐力或者是毅力,磨平了我的浮躁的心情,让我懂得要想达到自己的目标或者获得成功,必须伴随者自己的艰辛和汗水。
        最后祝福自己以后在测试这条道路上越走越远。同样Bless 这里的兄弟姐妹们。
        
  • 新年祝福

    2007-02-23 09:58:56

        终于可以在家里面上网了。好幸福的事情啊
        在这里首先祝福自己在新的一年里,工作顺利,身体健康。希望自己能够顺利地接受老板安排的事情,能够学习尽可能多的知识。
        其次我要祝福妈妈身体健康,心情快快乐乐的。
        再次祝福51testing越办越好,以及这里的朋友们心想事成,
  • 关于测试用例编写(二)

    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-09 09:08:45

    昨天,老板让我修正测试用例中的编号问题,说白了就是一项要求细心+体力的活儿拉

    我认为做什么事情,无论大与小,重要与不重要,关键还是态度的问题。所以我做的很认真。做的过程中,发现有一些测试用例是重复的,当时也没有管那么多。就继续认真做下去。

    大概块做完了,老板这时候说有些测试用例需要删除,原因跟我当时想的一样——用例重复。当时心理痛啊。自己辛苦的劳动就白费,又需要重新校正测试用例的编号。当时,真是有一种懊恼的感觉,但后来还是忍了下来,继续把工作做好。

    从以上小事情有一下感想:

    1 有好的工作态度很重要,它能够帮你投入到工作当中,但是在工作时候,还是不要忘记思考。

    2 既然想到,在自己思考再三之后,应当采取适当行动,不能为了完成工作而完成工作,要从工作中学习中东西。

    3 时间是宝贵的,效率第一。

    4 在发现自己的工作成绩遇到以外情况时,更应该小心谨慎。

    5 学会控制自己的情绪

     

    自己的一点点感想,希望工作的前辈能给我这个小辈多多指导

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

    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连接呢?

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

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

     

     

  • 第一次写日志

    2007-02-06 09:11:36

    终于有时间,有机会在网上留下自己的日记拉,更没有想到的是,竟然是在自己离开校园以后才做的事情。

    嘿嘿,还不知道写一些什么东西。不过,我感觉应该写一些对自己要求,也可以说对自己的希望吧。

    希望自己能够做到以下几点

    1 戒骄戒躁,踏踏实实;

    2 对自己制定的计划能够严格执行,不要以任何接口推托;

    3 制定计划要切实可行,不要好高骛远;

    4 严于律己,宽以待人;

    5 对自己能够做好的事情一定要做到最好;

    6 学会“忍”,这个很重要

    7 做事情贵在坚持,就象写日志一样。要坚持。

    差不多了,就这么多。祝福自己

     

我的栏目

数据统计

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

RSS订阅

Open Toolbar