• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• 黑盒测试的测试用例设计方法

  2008-3-03

  等价类划分:

        是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

        1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

        有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

        无效等价类:与有效等价类的定义恰巧相反.

        设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

   

  2）划分等价类的方法:下面给出六条确定等价类的原则.

        ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

        ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

        ③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

        ④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

        ⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

        ⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

   

  3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

        输入条件 有效等价类 无效等价类

        ... ... ...

        ... ... ...

        然后从划分出的等价类中按以下三个原则设计测试用例:

        ①为每一个等价类规定一个唯一的编号.

        ②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

        ③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

   

  边界值分析法

        边界值分析方法是对等价类划分方法的补充.

  （1）边界值分析方法的考虑:

        长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

        使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

  （2）基于边界值分析方法选择测试用例的原则:

        1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

        2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

        3）根据规格说明的每个输出条件,使用前面的原则1）.

        4）根据规格说明的每个输出条件,应用前面的原则2）.

        5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

        6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

        7）分析规格说明,找出其它可能的边界条件.

   

  错误推测法

        错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

        错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

   

  因果图方法

        前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.

        因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

        利用因果图生成测试用例的基本步骤:

        (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

        (2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

        (3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

        (4) 把因果图转换为判定表.

        (5) 把判定表的每一列拿出来作为依据,设计测试用例.

        从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

        前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

        判定表通常由四个部分组成.

        条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

        动作桩（Action Stub 查看(126) 评论(0)

• 界面测试

  2008-2-26

  1.验证界面显示内容的完整性：

  　　a) 报表显示时应考虑数据显示宽度的自适应或自动换行。

  　　b) 所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等)，必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常;

   

  2.验证界面显示内容的一致性：

  　　a) 如有多个系统展现同一数据源时，应保证其一致性;

   

  3.验证界面显示内容的准确性：

  　　a) 对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“--”或“/”，表示该字段值无意义。

   

  4.验证界面显示内容的友好性：

  　　a) 对统计的数据应按用户习惯进行分类、排序。

  　　b) 某些重要信息在输入、修改、删除时应有“确认”提示信息;

  　　c) 界面内容更新后系统应提供刷新功能。

  　　d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;

   

  5.验证界面提示信息的指导性：

  　　a) 在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。

  　　b) 用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕。

  　　c) 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。

  　　d) 在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);

   

  6.验证界面显示内容的合理性：

  　　a) 在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。

  　　b) 界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。

  　　c) 界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确;

   

  7.界面测试时，应考虑用户使用的方便性：

  　　a) 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。

   

  8.界面测试时，应考虑界面显示及处理的正确性：

  　　a) 界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。

  　　b) 应验证各种对象访问方法(Tab 健、鼠标移动和快捷键)是否可正常使用，并且在一个激活界面中快捷键无重复;

  　　c) 界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。

  　　d) 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。

  　　e) 对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变;

   

  9.界面测试时，应考虑数据显示的规范性：

  　　a) 确保数据精度显示的统一：如单价0元，应显示为0.00元;

  　　b) 确保时间及日期显示格式的统一;

  　　c) 确保相同含义属性/字段名的统一;

  　　d) 对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中。

   

   

  查看(37) 评论(0)

• 测试问题收集

  2008-2-22

  软件测试的目的？测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

   

  Beta 测试：在客户场地，由客户进行的对产品预发布版本的测试。

   

  软件验收测试合格通过准则：

  1软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。

  2所有测试项没有残余的一级二级三级的错误。

  3立项审批表、需求分析文档、设计文档和编码实现一致。

  4验收测试工件齐全（测试计划，测试用例，测试日志，测试通知单，测试分析报告）

   

  软件验收测试包括正式验收测试、alpha测试、beta测试三种测试。

   

  系统测试的策略：功能测试，性能测试，外部接口测试，界面测试，强度测试，冗余测试，可靠性测试，恢复测试等

   

  设计系统测试计划需要参考的项目文档有软件测试计划、软件需求工件、和迭代计划。

   

  利用因果图导出测试用例需要经过的步骤
  1.分析程序规格说明的描述中，哪些是原因，哪些是结果。
  2.分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的因果图
  3.在因果图上使用若干个特殊的符号标明特定的约束条件
  4.把因果图转换成判定表
  5.把判定表中每一列表示的情况写成测试用例

   

  阶段评审与同行评审的区别：

  同行评审目的:发现小规模工作产品的错误,只要是找错误;
  阶段评审目的:评审模块阶段作品的正确性可行性及完整性
  同行评审人数:3-7人人员必须经过同行评审会议的培训,由SQA指导
  阶段评审人数:5人左右评审人必须是专家具有系统评审资格
  同行评审内容:内容小一般文档 <   40页, 代码 < 500行
  阶段评审内容: 内容多,主要看重点
  同行评审时间:一小部分工作产品完成
  阶段评审时间: 通常是设置在关键路径的时间点上!  

   

  什么是软件测试？使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

   

  软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。

   

  软件测试是为了发现错误而执行程序的过程。

   

  简述集成测试的过程根据IEEE标准 集成测试划分为4个阶段：计划阶段，设计阶段，实现阶段，执行阶段（实施阶段）

  
  计划阶段
  1）时间安排        概要设计完成评审后大约一个星期
  2）输入            需求规格说明书 概要设计文档   产品开发计划路标
  3）入口条件        概要设计文档已经通过评审
  4）活动步骤      

  a.       定被测试对象和测试范围

  b.       评估集成测试被测试对象的数量及难度，即工作量