软件测试十诫

软件测试十诫

    八周的软件测试技术课结束了,经过八周的学习对软件测试技术有了一定的了解。总结一下发现其实自己学到的也只有那么一点。测试的意义和作用之类的就不多赘述了。

  1. 软件测试的工作流程是了解需求,设计测试,实现测试用例,运行测试,总结分析。
  2. 软件测试在不同的软件开发流程中都起重要作用。比如在V字开发模型中,验收测试、系统测试、集成测试的设计工作可以在需求分析、概要设计和详细设计阶段就可以展开;在XP模型中,除了必不可少的单元测试以外,每天都要进行大量的集成测试,回归测试。可以说,软件测试伴随整个软件开发的过程。
  3. 软件测试分为正向测试和逆向测试。一般来说,都是对输入空间划分。设计测试的过程就是对输入空间的划分。
  4. 在软件测试实践中,除了根据功能或者程序结构设计测试并生成测试用例以外,还会用到在开发过程中用到的defeat list,这是对积累的经验的利用。
  5. 设计测试的方法可以分为面向功能的测试和面向结构的测试,主要目的都是覆盖,对功能的覆盖,对结构的覆盖(比如对图的覆盖),测试设计得好坏的衡量标准的衡量就是靠覆盖程度来度量。
  6. 面向功能的测试对输入空间的划分一般有三种方法,很平衡。等价类划分,边界值,因果图,决策表。等价类很直观,有效类无效类划分很清晰;边界值法很机械,但是管用,就是测试用例实现工作量大;决策表严格,实现测试用例工作量小,但是设计的时候工作量太大。氪不改命,玄不救非。问题复杂程度就摆在那里,设计简单必然实现复杂。
  7. 等价类划分实现测试用例的时候,一次最好只包涵一个无效类,这样容易定位错误。当然,等价类的划分也是个问题。前面的总结里就有例子。(详见输入空间划分一篇)
  8. 边界值没什么好说的,简单粗暴,没什么技术难度。
  9. 决策表识别条件桩和动作桩就是个问题,识别条件桩和动作桩不是简单的在说明书中找“如果……就……”,在一般问题中这样很好用。但是在更为一般的问题里,可能需要对问题的条件和动作做恰当的分解。具体的例子在前面的总结中也提到过。(详见决策表例子一篇)
  10. 以上三种方法都不是孤立的,而是相辅相成的。
  11. 对面向功能的测试设计,较多的依赖经验,需要老道的测试经验和问题相关的领域专家的协助。对测试工程师的要求较高。
  12. 反过来,面向结构的测试对测试工程师的要求就不是那么高了,为什么?因为这一部分的理论性较强,每一步做起来都是有章可循,都有相应的理论支撑 ,所以对经验的依赖较小。

(未完待续,啰啰嗦嗦说了这么多,然而却没有什么有用的东西)

八周的软件测试技术课结束了,经过八周的学习对软件测试技术有了一定的了解。总结一下发现其实自己学到的也只有那么一点。测试的意义和作用之类的就不多赘述了。

  1. 软件测试的工作流程是了解需求,设计测试,实现测试用例,运行测试,总结分析。
  2. 软件测试在不同的软件开发流程中都起重要作用。比如在V字开发模型中,验收测试、系统测试、集成测试的设计工作可以在需求分析、概要设计和详细设计阶段就可以展开;在XP模型中,除了必不可少的单元测试以外,每天都要进行大量的集成测试,回归测试。可以说,软件测试伴随整个软件开发的过程。
  3. 软件测试分为正向测试和逆向测试。一般来说,都是对输入空间划分。设计测试的过程就是对输入空间的划分。
  4. 在软件测试实践中,除了根据功能或者程序结构设计测试并生成测试用例以外,还会用到在开发过程中用到的defeat list,这是对积累的经验的利用。
  5. 设计测试的方法可以分为面向功能的测试和面向结构的测试,主要目的都是覆盖,对功能的覆盖,对结构的覆盖(比如对图的覆盖),测试设计得好坏的衡量标准的衡量就是靠覆盖程度来度量。
  6. 面向功能的测试对输入空间的划分一般有三种方法,很平衡。等价类划分,边界值,因果图,决策表。等价类很直观,有效类无效类划分很清晰;边界值法很机械,但是管用,就是测试用例实现工作量大;决策表严格,实现测试用例工作量小,但是设计的时候工作量太大。氪不改命,玄不救非。问题复杂程度就摆在那里,设计简单必然实现复杂。
  7. 等价类划分实现测试用例的时候,一次最好只包涵一个无效类,这样容易定位错误。当然,等价类的划分也是个问题。前面的总结里就有例子。(详见输入空间划分一篇)
  8. 边界值没什么好说的,简单粗暴,没什么技术难度。
  9. 决策表识别条件桩和动作桩就是个问题,识别条件桩和动作桩不是简单的在说明书中找“如果……就……”,在一般问题中这样很好用。但是在更为一般的问题里,可能需要对问题的条件和动作做恰当的分解。具体的例子在前面的总结中也提到过。(详见决策表例子一篇)
  10. 以上三种方法都不是孤立的,而是相辅相成的。
  11. 对面向功能的测试设计,较多的依赖经验,需要老道的测试经验和问题相关的领域专家的协助。对测试工程师的要求较高。
  12. 反过来,面向结构的测试对测试工程师的要求就不是那么高了,为什么?因为这一部分的理论性较强,每一步做起来都是有章可循,都有相应的理论支撑 ,所以对经验的依赖较小。

(未完待续,啰啰嗦嗦说了这么多,然而却没有什么有用的东西)

时间: 2025-01-15 06:20:12

软件测试十诫的相关文章

爱的十诫

爱的十诫林仕锟 说 爱的十诫文北京军海专科/林仕锟爱,原本是就是一种道不清.说不明的本质:与这个世道的真相一样,你无法探索清楚什么是道,什么是爱,什么是天.简单来说,它们太浩瀚无边了,以至于人类无法从认知的世界里找到匹配的解释.这样的结果唯有一点,那就是人们不断的妄下定论,以己之见对应爱的存在,以己之心衡量爱的事实!爱有时候很害羞,爱有时候很恐惧,爱有时候很虚假,那不是爱的错,而是人们在发出爱的时候的生命状态出现问题.比如在创伤恐惧的人生里,爱是带着恐惧的,它不断的化身为另一种方式来对待你.比如

十诫在天主教和新教之间的差别

最近看基耶斯洛夫斯基的<十诫>中有所了解,不过基本无差.想想东西欧文化差别还是蛮有意思的,有机会再深入深入. 天主教十诫: 第一诫 钦崇一天主在万有之上. 第二诫 毋呼天主圣名以发虚誓. 第三诫 守瞻礼之日. 第四诫 孝敬父母. 第五诫 毋杀人. 第六诫 毋行邪淫. 第七诫 毋偷盗. 第八诫 毋妄证. 第九诫 毋愿他人妻. 第十诫 毋贪他人财物. 新教十诫: 第一条 不可信仰耶和华以外的神. 第二条 不可制造偶像与拜偶像. 第三条 不可妄称耶和华的名字. 第四条 以安息日为圣日,要敬拜上帝表示

源码管理十诫

英文原文:The 10 commandments of good source control management 若是还有能够毫无偏见地涉及各个编程语言.比源码管理软件更必要的工具.我倒是非常想见识一下.源码管理软件是我们工作的必备工具.是很多开发团队的血液.那为什么我们都会对它有所误解呢?为什么都非常难理解版本号控制系统的核心价值和基本原理呢? 我总结出 10 条惯例--假设你愿意也能够用"戒律"--意味着必须服从它并且从一開始非常难去理解. 它们与全部类型编程语言的版本号控制软

程序员父亲的遗产——编程十诫 转载

我的父亲在和我彻谈编程两个星期之后就去世了. 那个时候我22岁,一个刚刚完成美学学士毕业设计的大四学生.而我的父亲62岁,比大多数我同龄人的父亲都要老.早在60年代,他就已经在田纳西理工大学开始编程了,那个时候他在穿孔卡片上写FORTRAN语言.不得不承认,我的父亲学富五车.学识渊博. 我和编程第一次亲密接触的时候,它像烟花,瞬间绚烂了我的生命.它给我的感觉既魔幻又强大,在很多方面都比视觉设计要更富有创造性和实践性. 当我节假日回家的时候,我的父亲分享了他的<编程十诫>.他打印了一份,然后和我

谈谈源码管理那点事儿(一)——源码管理十诫(转)

引言: 若是还有能够毫无偏见地涉及各个编程语言.比源码管理软件更必要的工具.我倒是非常想见识一下. 源码管理软件是我们工作的必备工具,是很多开发团队的血液. 那为什么我们都会对它有所误解呢?为什么都非常难理解版本号控制系统的核心价值和基本原理呢? 原文作者总结出10条惯例(假设你愿意也能够用"戒律")意味着必须服从它,并且一開始非常难理解. 它们与全部类型编程语言的版本号控制软件都有关联.在这里我选取了Subversion和.NET的几个样例,只是它们也广泛地适用于其它的一些技术. 英

程序员父亲的遗产——编程十诫

1.理解并承认自己也会犯错误. 关于此点的关键就是要在发布之前早点发现.不过幸运的是,除非你是在喷射推进实验室开发火箭制导软件,否则很少有错误是致命的.所以,犯了错误之后我们可以从中学习经验教训,然后保持一个积极的心态,继续前行继续进步. 2.人非圣贤,孰能无过. 复审代码的目的就是为了发现问题.不过如有遗漏,也不可把责任归咎于某一个人身上去针对他. 3.人外有人.天外有天. 三人行必有我师,问问良师益友,会让你受益无穷.要学会倾听他人的意见和建议,特别是当你认为毫无必要时,更要怀着谦虚的态度.

谈谈源代码管理那点事儿(一)——源代码管理十诫(转)

引言: 若是还有可以毫无偏见地涉及各个编程语言,比源代码管理软件更必要的工具,我倒是很想见识一下.源代码管理软件是我们工作的必备工具,是许多开发团队的血液.那为什么我们都会对它有所误解呢?为什么都很难理解版本控制系统的核心价值和基本原理呢? 原文作者总结出10条惯例(如果你愿意也可以用"戒律")意味着必须服从它,而且一开始很难理解.它们与所有类型编程语言的版本控制软件都有关联.在这里我选取了Subversion和.NET的几个例子,不过它们也广泛地适用于其他的一些技术. 英文原文:Th

源代码管理十诫

英文原文:The 10 commandments of good source control management 若是还有可以毫无偏见地涉及各个编程语言,比源代码管理软件更必要的工具,我倒是很想见识一下.源代码管理软件是我们工作的必备工具,是许多开发团队的血液.那为什么我们都会对它有所误解呢?为什么都很难理解版本控制系统的核心价值和基本原理呢? 我总结出 10 条惯例--如果你愿意也可以用"戒律"--意味着必须服从它而且从一开始很难去理解.它们与所有类型编程语言的版本控制软件都有关

Docker 容器十诫

[编者按]本文作者为 Rafael Benevides,主要介绍使用 Docker 容器时应该注意的十个陷阱. Docker 容器十诫 当你刚开始使用容器时,会发现容器能解决许多问题,而且好处很多: 首先:容器是不可变的 —— 操作系统.库版本.配置.文件夹以及应用全都包裹在容器内.你可以确保,在 QA 阶段测试的一张图片,肯定会在生产环境中出现,并且行为保持一致. 其次:容器是轻量级的 —— 容器的内存占用很小.容器只会给主进程分配内存,因此无需十几万个 MB 的内存空间. 最后:容器速度很快