51Testing软件测试论坛

标题: 四个简单的软件测试题，送给学习测试的朋友们 [打印本页]

作者: 千里 时间: 2009-12-1 11:48
标题: 四个简单的软件测试题，送给学习测试的朋友们
1.测试三大文档（测试计划、测试用例、测试报告）它们的主要组成部分有哪些？
2.黒盒测试用例的设计方法，比如等价类、边界值、因果图的了解。
3.测试流程的认识。
4.怎么样编写一个BUG，BUG生命周期是怎么样的？

四个题目比较简单，但是我认为包括了软件测试的主要部分。
清楚了三大文档可以深入文档规范整个范畴；
黒盒测试用例设计是功能测试最核心的部分；
测试流程的扩展即时测试管理；
了解BUG生命周期后，像mantis bugzilla jira的使用就容易多了。
四个问题，抛砖引玉，请楼下的发表各自的意见。

[ 本帖最后由千里于 2009-12-1 11:54 编辑 ]

作者: 小兜兜 时间: 2009-12-1 11:54
说啥呢实在不知道说啥了。。。。

作者: crystal50112 时间: 2009-12-1 11:55
面试常遇到的问题，对新手很有帮助哦。顶一下！

作者: 投缘 时间: 2009-12-1 12:01

原帖由 小兜兜 于 2009-12-1 11:54 发表
说啥呢实在不知道说啥了。。。。

楼主在帮助新手找到了解测试内容的方向。通过这些问题，你们去找到答案，更快的了解测试知识！

作者: 小兜兜 时间: 2009-12-1 12:04

原帖由投缘于 2009-12-1 12:01 发表

楼主在帮助新手找到了解测试内容的方向。通过这些问题，你们去找到答案，更快的了解测试知识！

呵呵，知道了。谢谢大家的提点。都是热心人。。。。

作者: asdf001_ 时间: 2009-12-2 16:47
看看，谢谢楼主。。。

作者: shanshan3346 时间: 2009-12-2 21:21
原来是我大叔啊，换名字了呢，幸好还认得出来，好久不见，升版主啦
顶下

作者: chengyan_qh 时间: 2009-12-2 21:21
黑盒测试的测试用例设计方法

·等价类划分法

·边界值分析法

·错误推测法

·因果图法

·判定表驱动分析法

·正交实验设计法

·功能图分析法

1、等价类划分法:

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

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

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

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

设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.
2）划分等价类的方法:下面给出六条确定等价类的原则.

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

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

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

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

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

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

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

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

... ... ...

... ... ...

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

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

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

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

2、边界值分析法

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

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

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

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

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

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

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

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

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

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

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

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

3、错误推测法

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

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

4、因果图法

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

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

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

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

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

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

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

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

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

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

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

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

动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值.

动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.

规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.

判定表的建立步骤:（根据软件规格说明）

①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有种规则.

②列出所有的条件桩和动作桩.

③填入条件项.

④填入动作项.等到初始判定表.

⑤简化.合并相似规则（相同动作）.

B. Beizer 指出了适合使用判定表设计测试用例的条件:

①规格说明以判定表形式给出,或很容易转换成判定表.

②条件的排列顺序不会也不影响执行哪些操作.

③规则的排列顺序不会也不影响执行哪些操作.

④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

作者: 724818600 时间: 2009-12-6 20:45
标题: 1.测试三大文档（测试计划、测试用例、测试报告）它们的主要组成部分有哪些？
1、测试计划：
   * 1 基本概述
* 2 测试目标
* 3 “5W”规则
* 4 评审更新机制
* 5 详细规格
* 6 模板要求
* 7 参考资料
具体内容链接：http://www.hudong.com/wiki/%E8%B ... 5%E8%AE%A1%E5%88%92

2、测试用例：
测试用例应该由以下两部分组成

1）输入数据

2）处理（如计算、合并等）

3）预期的输出结果

这就是说，在执行系统之前应该对期望的输出有很明确的描述，这样，测试后就可将系统的输出同它仔细对照检查。否则，如果不是先确定输出，就可能把似乎是正确而实际是错误的结果当成是正确的结果。

3、测试报告：
   缺陷分类报告是测试报告的重要组成部分，可以再细分为：缺陷类型分布报告、缺陷区域分布报告和缺陷状态分布报告等。
   1）缺陷类型分布报告
      缺陷类型分布报告主要描述缺陷类型的分布情况，看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意，并分析缺陷为什么会集中在这种类型。例如，如果缺陷主要是界面类型的，如界面提示信息不规范、界面布局凌乱等问题，那么就要讨论是否需要制定相应的界面规范，让开发人员遵循，从而防止类似问题的出现。

   2）缺陷区域分布报告
      缺陷区域分布报告主要描述缺陷在不同功能模块出现的情况，这些信息有助于开发人员分析为什么缺陷会集中出现在某个功能模块。例如，如果缺陷主要集中在单据的审批过程中，那么就要分析是否是审批流程调用的工作流接口设计不合理。
   3）缺陷状态分布报告
      缺陷状态分布报告主要描述缺陷各种状态的比例情况，例如Open、Fixed、Closed、Reopen、Rejected、Delay的Bug分别占了百分之多少。这些信息有助于评估测试和产品的现状：
      如果Open的Bug比例过高，则考虑让开发人员暂停开发新功能，先集中精力修改Bug；
      如果Fixed状态的Bug很多，则考虑让测试人员暂停测试新功能，先集中精力做一次回归测试，把修改的Bug验证完；
      如果Closed的Bug居多，则可能意味着功能模块趋于稳定；
      如果Reopen的Bug比较多，则需要分析开发人员的开发状态，是什么原因造成缺陷修改不彻底；
      如果Rejected的Bug比例过高，则要看开发人员与测试人员是否对需求存在理解上的分歧；
      如果Delay的Bug比例过高，则要考虑这个版本是否满足用户的要求，是否缺少了太多应该在这个版本出现的功能特性。

作者: 一粒盐2009 时间: 2009-12-9 18:27
领教了，谢谢~

作者: liujianming1979 时间: 2009-12-9 22:46
标题: 测试流程
测试工作流程:
一、测试计划
根据测试项目的要求，制定测试计划，制定测试计划的目的是确定和描述要实施和执行的测试，这是通过生成包含测试需求和测试策略的测试计划来完成的。
二、测试用例设计
三、测试准备
对测试用例和测试文档的学习，对所要使用的测试工具的学习和操作，搭建测试环境，准备测试数据。
四、测试执行运行测试用例，查看测试结果。
五、缺陷管理
从发现问题开始，包括问题定位、问题解决、对解决的确认；状态跟踪；邮件系统支持；统计处理。
六、测试停止
测试结束后，测试负责人应编制《测试报告》，内容须包括以下几个方面：
1）对该阶段工作进行综合评价，包括测试工作效率、资源消耗情况、测试技术和工具的采用以及测试用例的质量等；
2）对测试结果进行概述，对该版本软件质量进行综合性的评价；
3）对测试过程中的经验、教训进行总结。
七、测试总结
项目结束后，测试人员需要对测试项目进行总结：内容须包括以下情况：
1）项目阶段历时
2）实际测试工作是否与预想的进度一致，有多少差异，如何使进度差异减小，有哪些好的测试经验或方法有哪些需要改进地方
3）测试新需求的过程与预想的是否一致，在测试过程中吸取到什么教训
4）沟通和协调管理上的是否存在问题
5）时间上的观点
6）对测试流程的建议和发现的问题

作者: 千里 时间: 2009-12-10 09:26
标题: 回复 11# 的帖子
这是系统测试的参考流程，还有单元测试、集成测试、验收测试的流程略有区别。
另外软件测试的流程是单元测试、集成测试、系统测试、验收测试四大部分组成。

作者: 开着拖拉机上班 时间: 2009-12-10 14:28
标题: 回复 12# 的帖子
测试流程中包括确认测试吗？

作者: 千里 时间: 2009-12-10 20:20

原帖由 开着拖拉机上班 于 2009-12-10 14:28 发表
测试流程中包括确认测试吗？

我看到的资料有的不包括确认测试，有的包括确认测试。
不在流程中的就包括在系统测试中，在流程中的有的在系统测试之前，有的在系统测试之后。

PS：非常感谢“开着拖拉机上班”，当年整理的《史上最齐的测试用例设计方法》很通俗易懂，对我的学习非常有帮助。

作者: 283017152 时间: 2010-1-6 13:42
这几个问题好像在教我怎样将一本书读薄

作者: 原点 时间: 2010-1-15 10:15
然后再把一本书读厚，就出师了？

作者: freedom_me 时间: 2010-4-21 09:19
呵呵,现在做手工黑盒最大感受就是：
以测试管理的角度执行测试;
以测试执行的角度管理测试;
:）

作者: tomzhang 时间: 2010-4-24 14:52
标题: 这些问题不必太较真，做过测试的人都应该了解
针对第1个问题，我个人的理解：
测试计划--what，when，who
测试用例--how
测试报告--result

作者: 千里 时间: 2010-4-26 13:18
tomzhang大哥，我的问题出得没有误导新人吧。

作者: careySucci 时间: 2011-10-19 17:47
有点喜欢楼主了，新手受教了谢谢

作者: gzrong 时间: 2011-10-19 18:33
虽然接触测试很长时间了，但一直没好好去整理过这几个问题的答案。

作者: hjwahjl 时间: 2011-10-19 21:35
看看，谢谢楼上的。

作者: yiyan408 时间: 2012-5-4 14:28
受教了。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)