发布新日志

  • 转:10大负面测试

    2008-03-10 10:29:24

    负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说,正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点,正面测试就象一个毕恭毕敬的小学生,老师叫我做什么,我就做什么;而负面测试就象一个调皮捣蛋的孩子,你叫我这样做,我偏不这样做,而且和你对着干。开发人员也是最讨厌修改此类bug的。
    正面测试主要根据需求,功能说明书,设计文档等相关参考文档来执行测试,而负面测试则主要根据错误猜测,逆向思维来测试系统,一定程序上的的依赖测试人员的经验积累。
    执行负面测试时,不单单要测试系统是否处理了用户的异常操作,还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。
    简言之负面测试的三部曲就是:
    1. 检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束;
    2. 测试系统是否处理了用户的异常操作;
    3. 检查系统的错误提示是否清晰且充分。

    以下是Steve Miller的《Top 10 Negative Test Cases》,概括性的提到了一些做负面测试时经常需要注意的测试。

    负面测试用例被设计于用软件未意欲被使用的方式测试软件,它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的10大负面测试用例。
    1.植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题,例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。
    【Kiki补充】其实不只是单引号,基本上测试人员应该测试所有的特殊字符和空/空格(单纯的空格和文本前后的空格)。单引号,逗号,/,<,>(对于web的应用程序)都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符,然后在处理用户的输入时套用这个函数就可以避免此类错误了。

    2.必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。
    【Kiki补充】对于强制输入的字段,在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致,错误信息提示是否正确,强制输入的字段是否真的必须输入。

    3.字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求(日期字段,数字字段,电话号码,邮编等等)的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据(数字型字段应该不允许字符或特殊字符,日期型的字段应该允许输入一个正确的日期等等)
    【Kiki补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求,这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)以及系统是否正确识别输入的格式。有些字段对字段的内容有限制,如常见的用户名,不能包含特殊字符,首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)还有不符合内容要求的数据输入时系统是否正确的处理。

    4.字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数(例如,first name必须是50个或更少的字符)。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。
    【Kiki补充】一般对于限制长度的字段,现在开发大多采用限制输入的方法(设置字段的长度)来处理。所以测试时需要测试限制的长度是否合理(和功能说明书或其他参考文档相一致),对于没有限制长度的字段,要测试无穷输入时是否出错,有问题报bug时建议开发人员根据需要限制长度。

    5.数字型的边界测试。对于数字型的字段,测试上下边界是非常重要的。例如,如果你正在计算某个账户的利息时,你永远不会输入一个负的利息数给应该赢取利息的账户。因此,你应该尝试用负数测试。同样,如果功能说明书上要求字段在某一个特定的范围(如从10~50),你就应该尝试输入9或51,它应该给出一个得体的信息表示失败。

    6.数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常,整数的范围是从-32,767~32,767,长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目,用这些限制测试以确保不会出现数字的溢出错误。
    【Kiki补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段,尝试输入负整数,负小数,0,正整数,正小数进行测试。
    不管是哪种数据库系统,对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。

    7.日期边界测试。对于日期型的字段,测试上下边界是很重要的。例如,如果你正在检查一个出生日期的字段,很大可能出生日期不能早于150年前。同样,出生日期应该不是将来的某一天。
    【Kiki补充】一般来说,每种数据库系统的日期都有个范围,如SQL Server最小日期是1753年1月1日,所以如果是输入型的日期字段同样也应该测试早于1753的日期。

    8。日期的有效性。对于日期字段,确保不允许无效的日期是很重要的(04/31/2007是一个无效的日期)。测试用例也应该检查闰年(每个第4年和第400年是一个闰年)。

    9。web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户,应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。

    10.性能的改变。当发布产品的最新版本时,应该有一套运行于识别屏幕(列出信息的屏幕,add/update/delete数据的屏幕等等)速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。

    【Kiki补充】从第一条到第八条是我们在测试字段时常常需要做的测试,一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中,一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里,很少去做这样的比较,除了一些有针对性的性能测试。

  • 转:软件需求评审九条建议

    2007-11-14 21:41:04

    建议一:分层次评审
      
      我们知道用户的需求是可以分层次的,一般而言可以分成如下的层次:
      
      目标性需求:定义了整个系统需要达到的目标;
      
      功能性需求:定义了整个系统必须完成的任务;
      
      操作性需求:定义了完成每个任务的具体的人机交互;
      
      目标性需求是企业的高层管理人员所关注的,功能性需求是企业的中层管理人员所关注的,操作性需求是企业的具体操作人员所关注的。对不同层次的需求,其描述形式是有区别的,参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求,可能会很容易地导致“捡了芝麻,丢了西瓜”的现象,如果让高层的管理人员也去评审那些操作性需求,无疑是一种资源的浪费或者就会出现案例三的情形。
      
      建议二:正式评审与非正式评审结合
      
      正式评审是指通过开评审会的形式,组织多个专家,将需求涉及到的人员集合在一起,并定义好参与评审人员的角色和职责,对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式,一般也不需要将人员集合在一起评审,而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。两种形式各有利弊,但往往非正式的评审比正式的评审效率更高,更容易发现问题。因此在评审时,应该更灵活地利用这两种方式。
      
      建议三:分阶段评审
      
      应该在需求形成的过程中进行分阶段的评审,而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审,降低了需求返工的风险,提高了评审的质量。比如可以在形成目标性需求后进行一次评审,在形成系统的初次概要需求后进行一次评审,当对概要需求细分成几个部分,对每个部分进行各个评审,最终再对整体的需求进行评审。
      
      建议四:精心挑选评审员
      
      需求评审可能涉及的人员包括:需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管;供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同,对同一个问题的看法是不相同的,有些观点是和系统的目标有关系的,有些是关系不大的,不同的观点可能形成互补的关系。为了保证评审的质量和效率,需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来,否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的,对系统有足够了解的人员参与进来,否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。

    建议五:对评审员进行培训
      
      在很多情况下,评审员是领域专家而不是进行评审活动的专家,他们没有掌握进行评审的方法、技巧、过程等,因此需要对评审员进行培训,同样对于主持评审的管理者也需要进行培训,以便于参与评审的人员能够紧紧围绕评审的目标来进行,能够控制评审活动的节奏,提高评审效率,避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训两种。简单培训可能需要十几分钟或者几十分钟,需要将在评审过程中的需要把握的基本原则,需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训,需要花费较长的时间,是一个独立的活动。需要注意的是被评审人员也要被培训。
      
      建议六:充分利用需求评审检查单
      
      需求检查单是很好的评审工具,需求检查单可以分成两类:需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责,主要是针对需求文挡的格式是否符合质量标准来提出的,需求内容的检查是由评审员负责的,主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等,这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题,检查单也是随着工程财富的积累逐渐丰富和优化的。
      
      建议七:建立标准的评审流程
      
      对正规的需求评审会需要建立正规的需求评审流程,按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。
      
      建议八:做好评审后的跟踪工作
      
      在需求评审后,需要根据评审人员提出的问题进行评价,以确定哪些问题是必须纠正的,哪些可以不纠正,并给出充分的客观的理由与证据。当确定需要纠正的问题后,要形成书面的需求变更的申请,进入需求变更的管理流程,并确保变更的执行,在变更完成后,要进行复审。切忌评审完毕后,没有对问题进行跟踪,而无法保证评审结果的落实,使前期的评审努力付之东流。
      
      建议九:充分准备评审
      
      评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是,需求文档在评审会议前并没有提前下发给参与评审会议的人员,没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者,没有执行需求评审的进入条件,在评审文档中存在大量的低级的错误或者没有在评审前进行沟通,文档中存在方向性的错误,从而导致评审的效率很低,质量很差。对评审的准备工作,也应当定义一个检查单,在评审之前对照检查单落实每项准备工作。
      
      在实践中细心体会、实施上述的9个建议,相信您定会受益非浅

我的栏目

数据统计

  • 访问量: 1991
  • 日志数: 2
  • 建立时间: 2007-11-05
  • 更新时间: 2008-03-10

RSS订阅

Open Toolbar