软件测试技术大全读书笔记
- 格式:doc
- 大小:75.50 KB
- 文档页数:2
软件测试技术学习笔记1. 软件工程:应用计算机科学,数学及管理科学等原理开发软件的工程。
软件工程是实现一个大型程序的一套原则方法,是指将其他工程领域中行之有效的工程学知识运用到软件开发中来,即按工程化的原则和方法组织软件开发工作。
2. 软件:程序以及开发,使用和维护程序所需的所有文档。
3. 软件测试:使用人工和自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别,软件测试以检验是否满足需求为目标。
4. 软件测试的价值:(1)防止质量灾难的发生;(2)确保软件满足用户的需求(功能性,非功能性);(3)确保软件符合质量标准(国家,行业,企业)。
5. 软件测试的目的:(1)证明程序的正确性—除非仅处理有限种情况;(2)发现程序错误(BUG)—直接目标;(3)检查软件(系统)是否满足需求—期望目标。
6. 软件测试的原则:(1)测试必须是有计划的,有准备的,包括任务,时间,人员,设备,经费,方法与工具,问题等;(2)所有的测试都应追溯到用户需求;(3)应当尽早地和不断地进行软件测试;(4)软件测试充分注意测试中的集群现象;(5)总假定程序具有错误的;(6)旁举测试是不可能的;(7)彻底检查每一个测试结果。
7. 软件测试的分类:(1)按照开发阶段划分:单元测试,集成测试,系统测试,验收测试;(2)按照测试实施组织划分:开发方测试,用户测试,第三方测试;(3)按照测试技术划分:白盒测试,黑盒测试。
8. 软件测试流程:制定测试计划,设计测试,实施测试,执行测试,评估测试。
9. 白盒测试:已知产品的详细设计过程,可以通过测试证明每种内部操作是否符合设计规格需求,所有内部成分是否已通过检查。
10. 黑盒测试:已知产品的用户需求规格,可以通过测试证明整个软件系统是否符合用户最终要求。
11. 采用等价类划分的原因:由于旁举测试的办法数量太大,以至于无法实际完成,自然促使我们选取测试用例。
The Art of SoftWare Testing》读书笔记(1)_引子有关自己与软件测试之间的渊源而言,获悉这个领域的时间不长,接触的时间就更可谓短暂,但仔细想来,还要从大学期间说起比较好。
软件测试这个概念第一次出现在我的眼前时,是大四上学期开的软件工程这个科目中所涉及到的一点点。
由于某些因素,使我在大学期间忽略了对测试领域相关知识的储备。
第二次面对它时,是考研复习准备阶段。
那时,我对测试这个领域也仅仅只是知道,就是中文书面表达的“测试”这两个汉字的含义而已。
工作的前两年里,或许是因为从事的是有关算法方面性质的工作,所以并未对测试这个领域给予过多的关注,还好,或多或少还是接触到了一些。
直到最近一年多来,由于一个大型项目人手不够的缘故,所以临时从自己负责的另一个研究项目中抽过来(刚好该项目阶段性完成),负责有关此项目的测试部署与规划。
而这个时候,才能说是:真正意义上接触到了软件测试这个领域。
虽然,在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。
但,从这个项目阶段性结束后自己的体会而言,给我感悟最深的还是有关软件测试这个领域的。
通过在这个项目里的工作,让我真正体会到了:软件测试是一门艺术。
恰恰也是因为这个缘故,这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。
《The Art of SoftWare Testing》读书笔记(2)_前言喜欢在网上书店中遛达,看到不错的书就买下。
为什么不去书店?一个字,懒呗!总觉得,有那去书店的时间,完全可以好好睡一美觉,亦或可亲手烹制一顿美味可口的美食。
哎,反正就是,懒得走出家门去逛街!恰巧,此次浏览书籍时,无意间看到了《The Art of Software Testing》这本书。
在看了大家所给予它极高的评价留言后,虽然有些疑惑(毕竟这个时代,枪手太多了!),但我深信:一本书能够“活”25年,应该还是很不简单的。
于是,就半信半疑的订购了这本书,期望能够从这本书中获悉到有用的知识,来丰富一下自己面对这个领域时的贫乏困境,亦作为知识储备。
软件测试必备1、软件测试基本概念和方法三个重要的测试原则:1. 软件测试是为发现错误而执行程序的过程;2. 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性;3. 一个成功的测试用例能够发现某个尚未发现的错误。
1.测试的过程具有一定的破坏性2.测试用例包括:输入数据的详细描述和正确输出结果的精确描述3.检查程序是否‘没有做它应该做的’仅仅是测试一半,另一半是检查‘是否做了它不应该做的’4.全面测试目标:验证是否做了应该做的事情,确保可靠性验证程序是否做了不应该做的事情,确保安全性5.任何多余的功能都应视为安全隐患6.Boehm给出的度量中的头10个表示软件现象遵守Pareto分布:20%的模块消耗80%的资源(人力、经费等);20%的模块包含80%的错误;20%的错误消耗80%的修改成本;20%的改进包含了80%的适应性为主的成本;20%的模块占用了80%的执行时间;20%的软件工具使用占80%的整个工具使用时间。
补充:20%的软件缺陷造成80%的软件故障20%的软件开发和管理人员(骨干),决定了80%软件开发质量:Pareto原理强调了精力集中在少数重要的事情上(vital few),而不是多数琐碎的事情上(trivial many)。
6.软件测试是一种作为主体的人通过各种手段对客体软件的某种固有属性进行的一种以8.审查的终极目标——确认缺陷9.人工审查包括:文档审查代码审查10. 软件缺陷的类型:可追溯性、逻辑、赋值顺序、控制、数据、接口、文档、注释、例外情况处理、内存等。
11. 只要简单地使用静态代码分析来增强输入验证的正确性就能够避免OWASP(业界领袖的安全性协会)所列出的约70%的安全性问题。
12. 圈度复杂度(独立路径的最大数量=程序控制流图中的区域数)=控制流图边数—控制流图的节点数+2二、测试框架的表述13. 测试框架(Test Framework):一组相互协作的组件的集合,能够实现一个或多个测试域中的一系列问题的解决方案。
软件测试技术经典教程——学习笔记公司推荐的入门书,《软件测试技术经典教程》是一本难得的好书。
注重理论与实践结合!之前看过的一些软件测试方面的书,大多注重理论,而且大都讲得泛泛,不具体,书本之间的重复内容很多。
全书分为三部分:软件测试基础知识、黑盒测试工具和白盒测试工具。
其中黑盒测试中介绍的几个工具,很长见识,带人进入真实的软件测试工作环境。
它让我第一次深得,原来软件测试是这个样子的。
LoadRunner,这个软件之前有听过,大概知道它是性能测试的工具,但没有用过,直觉是这软件应该比较复杂。
此次书中的介绍,其实并不算好,跟任何介绍软件使用的计算机书一样,价值是不大的。
我操作的时候也没有太多按照书上的内容来,而是借助网上的电子文档教程,但书是一个好东西,它让我明白这个工具的重要性,明白它是软件测试理论及实践中的位置,这个意义比软件教程本身重要很多,是决定要不要学习一个工具的前提。
下载了安装程序之后,对着教程进行操作,发现其实过程还是非常简单的。
软件的操作,一两天就可以学会,并应用在工作中,软件操作遇到的具体问题也可以通过查找资料或者向同事请教的方式解决。
但工作过程中跟项目相关的内容,就需要软件测试理论和其它知识的支撑了。
正如前面所提到的,本书的意义在于——它带我走进真实的软件测试环境。
QTP(Quick Test Professional),是一个功能测试工具。
这个软件之前在软件测试论坛上也有人提及,还看到有专门的教程,因此感觉软件本身可能比较复杂。
但真正使用起来,才发现非常易学易用。
同LoadRunner一样,重要在于通过本书,知道了它的重要意义,软件的学习是容易的。
这款软件的主要功能是录制与回放,可对测试过程插入检查点等,回放时,可用参数化的方式进行输入。
QC(Quality Center),是一款软件测试过程管理工具,它的老版本叫Test Director,也是书中所介绍的版本。
有管理员与用户两种模式。
《软件测试》读书笔记(持续更新)⽂章⽬录#第⼀部分 软件测试综述##第⼀章 软件测试的背景###1.1臭名昭著的软件错误⽤例研究###1.2软件缺陷是什么####1.2.1软件失败的术语确实严重,甚⾄是危险的情况:故障(fault)、失败(failure)、缺点(defect)不那么尖锐,主要指未按预料运⾏,⽽不指全部失败:异常(anomaly)、事件,插曲(incident)、偏差(variance)最常⽤的术语:问题(problem)、错误(error)、缺陷(bug)其他术语:⽭盾(inconsistency)、特殊(feature)软件测试中出现的其他术语:产品说明书(product specification):简称为说明(spec)或产品说明(product spec)。
它对开发的产品进⾏定义,给出产品的细节、如何做、做什么、不能做什么。
这种协定从简单的⼝头说明到正式的书⾯⽂档有多种形式。
之后《软件开发的过程》会讲述产品说明书和开发过程中的更多内容。
在每个公司,不同的开发⼩组⾥会有不同的术语,但在⽤词上过多的计较是没有意义的。
在这本书中,所有的软件问题都被称为缺陷####1.2.2软件缺陷的官⽅定义 ☟⾄少满⾜下列5个规则之⼀才称发⽣了⼀个软件缺陷(software bug)1)软件未实现产品说明书要求的内容(产品说明书:计算器能够准确⽆误的进⾏加减乘除;按下(+)键,没有反应,或者得到错误答1)软件未实现产品说明书要求的内容(产品说明书:计算器能够准确⽆误的进⾏加减乘除;按下(+)键,没有反应,或者得到错误答案)2)软件出现了产品说明书指明不应该出现的错误(产品说明书:计算器永远不会崩溃、锁死或者停⽌反应;狂敲键盘,计算器停⽌接受输⼊)3)软件实现了产品说明书未提到的内容(计算器求加减乘除还可以求平⽅根,这也是缺陷,虽然有了更好,但会增加测试的⼯作,甚⾄带来更多的缺陷)4)软件未实现产品说明书虽未明确提及但应该实现的⽬标(⽬的为了捕获那些产品说明书上的遗漏之处。
1.1什么是软件测试软件测试:在可控的预置条件下操作软件的过程,其目的是拟定软件行为符合产品规格说明、发现错误和验证软件复符合用户的需求。
注意:目的不仅仅是发现软件存在缺陷没有发现缺陷的测试同样有价值测试是评估软件质量的一种方法1.2软件测试原则(1)尽早和不断的进行软件测试发现软件缺陷越早,其修复成本越低(2)重视无效数据和非预期使用习惯的测试缺陷高发区(3)充足注意测试中的群集现象缺陷扎堆(4)用例要定期评审,适时补充修改用例保持测试用例的活力(5)应当对每一个测试结果做全面检查发现隐含的缺陷(6)经济原则穷尽测试不也许,考虑成本(7)开发人员应避免测试自己的程序思维定势、心理作用1.3软件测试分类软件开发阶段:单元测试、集成测试、系统测试、验收测试测试方法:白盒测试、黑盒测试测试实行方:开发方测试、用户测试、第三方测试测试内容:功能测试、性能测试、安全性测试、兼容性测试、可靠性测试按软件开发阶段分类:(1)单元测试:模块测试,对软件中最小可测试单元进行检查、验证(2)集成测试:组装测试,对软件不同单元或部件的接口进行测试(3)系统测试:将软件与外设、网络等结合在一起,对整个产品系统进行的测试(4)验收测试:按照验收依据,对整个系统进行测试按测试方法分类:(1)白盒测试(结构测试、逻辑驱动测试)基于代码的内部逻辑知识,检测软件内部动作是否按照规格说明书的规定正的确现,检查软件中的所有结构和途径是否可以按预定规定对的工作。
(2)黑盒测试(功能测试、数据驱动测试)用的多把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,只检查程序功能是否按照需求规格说明书的规定正常使用,程序能否适本地接受输入数据,并产生对的的输出信息。
1.4软件测试方法黑盒测试:等价类划分法、边界值分析法、错误推测法、因果图法、鉴定表驱动法、正交实验法、场景法、功能图法白盒测试:代码走查、代码审查、静态分析、逻辑覆盖、基本途径测试、域测试、符号测试、程序插桩几种常用的测试方法(1)等价类划分法:一种重要的、常用的设计方法根据数据的需求,吧数据划分为有效等价类和无效等价类,进而从每个等价类中选取一个数据作为测试用例数据。
软件测试学习笔记-概念篇(⼀)前⾔ 每个系统的成型,上线都离不开测试,这段时间陆陆续续的学习测试,在这⾥总结⼀番;作为学习交流之⽤;正⽂早期定义:软件测试是对程序能够按预期运⾏建⽴起⼀种信⼼。
经典定义:测试是为了发现错误⽽执⾏程序的过程。
IEEE定义(ISO/IEC/IEEE 29119):使⽤⼈⼯或者⾃动的⼿段来运⾏或测量软件系统的过程,以检验软件系统是否满⾜规定的要求,并找出与预期结果之间的差异。
五⼤要素有:质量、⼈员、资源、流程、技术。
其中最主要的是软件质量,其他四个要素都是为质量服务的。
其次是⼈员,决定了技术,资源,流程,以及配置和使⽤。
技术包含了:软件测试技术、软件测试⽅法、使⽤的⼯具。
技术是⼿段。
流程:测试计划,测试⽤例,测试执⾏,测试报告。
有⼀些进⼊进出的标准(规范性,对软件测试做⼀个规范的要求)。
资源:测试所需要的硬件设备、⽹络环境、测试设备、测试时间(周期)。
注意:⼈不是资源。
⽬标:①提升测试覆盖率-> 能够有效的保证软件的质量②提升测试效率->能够使我们更好地完成软件测试⼀、测试显⽰缺陷的存在,但不能证明系统不存在缺陷。
经过软件测试,可以发现软件中的故障;但是经过软件测试,不能保证软件就没有故障了。
⼆、穷尽测试是不可能的,应设定及时终⽌的条件。
三、测试应该尽早进⾏四、缺陷具备群集特性越是发现问题多的模块,越是需要重点测试的对象五、测试的杀⾍剂悖论在测试中,如果采⽤同样的测试⽤例,同样的测试⽅法。
多次重复的测试某⼀个模块,最后就不能再发现新的缺陷。
所以说,测试⽤例和测试⽅法应该不定期的评审修改,并且增加不同的测试⽅法和⽤例来测试不同的部分,从⽽更多的发现软件的缺陷。
六、测试的⼆⼋原则测试时间和资源往往是有限的,要找出所有的缺陷是不可能的,这时我们需要遵循⼆⼋原则。
把80%的时间或者资源⽤在20%的重点模块上,重点测试模块中20%的重要模块。
来达到测试效率和资源配置的最佳的⽐例。
作者在该书第七章着重讲述了调试的五种⽅法。
不过有必要先明确⼀下调试的定义。
调试,是执⾏⼀次成功的测试之后所要进⾏的⼯作。
它有两个步骤:从错误定位(可解决95%的问题);再错误修改。
⽽对于各种⽅法的具体步骤及过程,都不再详叙。
暴⼒法调试,不需要过多的思考,但同时也是效率低下,即:不是很成功。
它⾄少可被划分为三种类型:⽤内存信息输出来调试;根据⼀般的“在程序中插⼊打印语句”建议来调试;使⽤⾃动化的调试⼯具进⾏调试(可设置断点)。
不过,该⽅法的主要问题在于:它忽略了思考的过程。
因此,该⽅法的使⽤情况为:其它的⽅法都失败了;座位其它⽅法思考过程的补充,⽽不是替代⽅法。
全程软件测试:软件测试简介——读书笔记软件测试起源于20世纪70年代中期,是伴随着软件的产生而产生的。
在早期,测试只是整个软件开发过程的一个阶段。
测试与调试含义相似,目的都是排除软件故障,常常由开发人员自己来完成。
直到1957年,软件测试才开始与调试区别开来,成为一种发现软件缺陷的活动。
在很多人的观念中,开发是一种创造价值的劳动,而软件测试只是整个开发过程结束后的一种活动。
1972年,北卡罗来纳大学举行了首届软件测试正式会议。
1975年,约翰·古德·因纳夫(John Good Enough)和苏珊·格哈特(Susan Gerhart)在IEEE发表了文章《测试数据选择的原理》,软件测试才被确定为一种研究方向。
1979年,格伦福特·迈尔斯(Glenford Myers)的《软件测试的艺术》(The Art of SoftwareTesting)成为软件测试领域的第一本重要专著,迈尔斯给出了软件测试的定义:“软件测试是为发现错误而执行一个程序或者系统的过程”。
尽管在这位大师眼里,软件测试还是艺术,但是,书中除了介绍众多的测试经典方法之外,还向人们揭示了测试的目的是证伪,而不是证真。
1981年,比尔·赫策尔(Bill Hetzel)博士开设了一门公共课“结构化软件测试”,后来他出版了《软件测试完全指南》(The Complete Guide to Software Testing)一书。
1988年,戴维·吉尔佩林(David Gelperin)博士和比尔·赫策尔(Bill Hetzel)博士在《美国计算机协会通讯》(Communication of the ACM)上发表了《软件测试的发展》(The Growth ofSoftware Testing),文中介绍了系统化的测试和评估流程。
直到20世纪80年代早期,软件行业才开始逐渐关注软件产品质量,并在公司内建立软件质量保证部门。
软件测试工程师学习笔记软件测试读书笔记之一软件测试背景一.软件缺陷的正式定义:符合下边5个规则的才能叫做软件缺陷。
1.软件未达到产品说明书标明的功能。
2.软件出现了产品说明书指明不会出现的错误。
3.软件功能超出产品说明书指明范围。
4.软件未达到产品说明书虽未指出但应达到的目标。
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。
二.软件缺陷的产生原因:导致软件缺陷最大的原因是产品说明书;第二大来源是设计方案;三是代码;四是某些软件缺陷产生的条件被错误地认定。
三.软件缺陷的修复费用:随时间增长,修复软件缺陷的费用是呈几何数级增长的,随时间推移,数十倍增长。
四.软件测试人员的目的:软件测试远的目标就是发现软件缺陷,尽可能早一些,并确保其得以修复。
五.怎么成为优秀测试员:1.探索精神2.故障排除能手3.不懈努力4.创造性5.追求完美6.判断准确7.老练稳重8.说服力9.除了这些素质,在软件编程方面受过的教育也是重要的。
10.软件的功能为了解决现实问题,因此,教学烹饪航空木工医疗等知识都将对查找该领域软件的缺陷有莫大帮助软件测试读书笔记之二软件开发过程一.测试文挡包括:1.测试计划2.测试案例3.软件缺陷报告4.归纳,统计和总结。
二.软件产品由哪些部分组成(都是要测的哦,当然我国许多软件都无法达到这么多部分~呵呵)1. 最终产品(光盘/软盘/程序...)2.帮助文件3.用户手册4.样本和示例5.标签和帖子6.产品支持信息7.图标和标志8.错误信息9.广告和宣传材料10.安装11.说明文件这些都是要测试的,书中尤其提到了不要忘了测试错误提示信息(错误提示信息是软件产品最容易忽视的部分,通常是有程序员而不是训练有素的稿手来写的。
这些信息很少照顾到修复软件缺陷的需要,还常常造成麻烦。
软件测试员也难以找到并显示全部信息。
在软件中不要加入吓人和不友好的错误提示信息。
)三.软件开发模式1.大棒式:所有精力都在开发软件和编写代码上2.边写边改式:没有时间做好,总有时间返工哈哈!这句话经典,测试者几乎每天都拿到一个新版本,新版本出来的时候,旧版本还没测完!而新版本还包含新的或者经过修改的功能)3.流水式:创意-分析-设计-开发-测试-最终产品,只许前进不能后退!4.螺旋式:开始不必详细定义所有细节。
软件测试学习笔记:测试点总结_0 软件测试学习笔记:测试点总结邮件群发软件测试学习笔记:测试点总结软件测试1、可编辑文本框的测试:主要是“字符长度、字符类型、文本格式”的测试字符长度的验证:最大值、最小值、适当值、超长值。
字符类型的验证:中(简、繁)、英(大小写)、数字(整数、小数、负数)、标点符号(全角、半角)、特殊符号(回车、空格、TAB、脚本语言、NULL、null)、转义字符,及这些字符类型的组合。
文本格式的验证:比如日期(控件、手动输入)、邮箱、手机号。
2、文件上传下载的测试:主要是“文件格式、文件内容格式、文件信息、文件大小、文件重复上传、文件下载”的测试文件格式的验证:文本格式、图片格式、音频格式、压缩包等等。
文件内容格式的验证:系统要求上传的文件的内容是一定格式的(系统给出一定的内容模板)。
文件信息的验证:文件具体内容(有时文件数据的合理性是要经过校验的)、文件内容包含特殊字符、文件名(参考1中的字符类型验证)、文件路径(直接导入、手动输入)。
文件大小的验证:0、适当值、超大值。
文件重复上传的验证:系统是否具备去重处理的能力。
文件下载的验证:左键(打开时文件内容是否正确显示)、右键。
3、查询功能的测试:主要是“查询条件、查询结果列表、查询处理时间是否能够接受”的测试查询条件的验证:空格、查询条件前后中加空格、数据库中的值、非数据库中的值(参考1中的字符类型验证)、是否支持模糊查询、组合查询。
查询结果列表的验证:结果列表表头内容是否正确、结果数据是否正确、结果列表是否具备翻页功能。
查询处理时间的验证:数据库中存在大数据量数据时,查询时间是否能接受。
4、权限的测试5、表单打印、导出、提交的测试打印功能的验证:打印出的内容、分页打印。
导出功能的验证:导出内容(部分数据还是全部数据)、打开导出的文件。
提交功能的验证:检查表单信息是否被正确保存、同一条数据多次提交。
6、数据增、删、改功能的测试增加功能的验证:增加后的显示效果(内容是否正确、是直接显示还是需刷新才能显示)、多次增加相同的记录。
软件测试学习笔记之一/软件测试概述一、什么是软件测试?简单的说,如果你写了一段代码,我来帮你查看代码并找出里面的错误,这就是测试。
IEEE的定义:―使用人工或自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
‖有位大师曾说过:―软件测试的目的在于发现错误,一个好的测试用例在于发现从来未发现的错误,一个成功的测试是发现了从未发现的错误的测试。
‖二、常见导致软件错误的根源1、缺乏有效的沟通,甚至根本就没有进行沟通。
2、软件复杂度过大。
3、编程出现错误。
4、不断变更的需求,项目失败的最大杀手。
5、时间的压力,为了赶时间交付,错误也就伴随发生了。
6、缺乏文档的代码。
7、软件开发工具本身存在问题。
8、人员过于自信。
三、软件测试中的误区1、测试和调试是一样的。
2、测试组的人应当为保证质量负责。
3、过分依赖Beta测试。
4、把测试作为新员工的一个过渡工作。
5、把不合格的开发人员安排做测试工作。
6、关注与测试的执行而忽略测试的设计。
7、测试自动化是万能的。
8、测试时可以穷尽的。
9、测试是为了证明软件的正确性。
10、测试是枯燥乏味,缺乏创造力的工作。
软件测试是一种检测手段,目的是为了寻找软件系统中的缺陷。
业界越来越多的公司已经意识到软件测试的重要性,并在测试方面加大了投入。
软件测试有很多误区,只有认识到了这些误区才能真正理解测试本身的含义,才能以正确的态度看待测试。
软件测试学习笔记之二/白盒测试与黑盒测试一、为什么要进行白盒测试?1、逻辑错误和不正确假设与一条程序路径被执行可能性成反比。
当我们设计和实现主流之外的功能、条件和控制时,错误往往开始出现在我们的工作中。
日常处理往往能被很好的理解,而―特殊情况‖的处理则难于发现。
2、我们经常相信某个逻辑路径不可能被执行,而事实上,它可能在正常的情况下被执行。
程序的逻辑流有时候是违反直觉的,这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误,只有路经测试才能发现这些错误。
软件测试技术大全读书笔记-标准化文件发布号:(9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
一.测试是一种服务:
1.可以化解很多测试与开发之间的矛盾;
2.有利于测试客观公正地进行工作。
二.软件测试应该遵循的几个原则:
1.GoodEnough原则;--投入与产出成正比
2.Pareto原则;--80-20原则
3.尽可能早的开展测试;--早发现,代价小
4.在发现比较多错误的地方需要投入更多的测试;--聚集效应。
5.同化效应。
--交叉测试避免出现盲点。
三.IBM公司的软件测试方法
1.单元测试
2.集成测试
3.系统测试
4.验收测试
四.为什么需要回归测试
1.所谓回归:指产品的质量从一个较高的水平回落到一个较低的水平。
2.回归的问题根源是软件系统的内在复杂性。
3.随着系统构建的时间越长回归的问题也会增多。
2。