《软件测试的艺术》读书笔记
- 格式:doc
- 大小:110.51 KB
- 文档页数: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):一组相互协作的组件的集合,能够实现一个或多个测试域中的一系列问题的解决方案。
《软件测试》读书笔记(持续更新)⽂章⽬录#第⼀部分 软件测试综述##第⼀章 软件测试的背景###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、将软件最终用户的要求转换为一系列书面的需求。
这些需求就是该软件产品要实现的目标。
2、通过评估可行性与成本、消除相抵触的用户需求、建立优先级和平衡关系,将用户需求转换为具体的目标。
3、将上述目标转换为一个准确的产品规格说明,将产品视为一个黑盒,仅考虑其接口以及与最终用户的交互。
该规格说明被称为“外部规格说明”。
4、如果该产品是一个系统,而不仅是一个程序,那么下一步骤就是系统设计。
该步骤将系统分隔为单独的程序、部件或子系统,并定义它们的接口。
5、通过定义每个模块的功能、模块的层次结构以及模块间的接口,来设计程序或程序集合的结构。
6、设计一份准确的规格说明,定义每个模块的接口与功能。
7、经过一个或更多的子步骤,将模块接口规格说明转换为每个模块的源代码算法。
需求规格说明定义了为什么要开发程序。
目标定义了程序要做什么,以及应做得怎样。
外部规格说明定义了程序对用户的准确表现。
与后续阶段相关的文档越来越详细地规定了程序是如何建立起来的。
模块测试的目的是发现程序模块与其接口规格说明之间的不一致功能测试的目的是为了证明程序未能符合其外部规格说明系统测试的目的是为了证明软件产品与其初始目标不一致6.1、功能测试功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。
外部规格说明是一份从最终用户的角度对程序行为的精确描述。
6.2、系统测试将系统或程序与其初始目标进行比较。
给定这个目标之后,隐含两方面的含义:1、系统测试并不局限于系统。
如果产品是一个程序,那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程。
2、根据定义,如果产品没有一组书面的、可度量的目标,系统测试也就无法进行。
The Art of Software TestingSecond EditionGlenford J. MyersRevised and Updated byTom Badgett and Todd M.Thomaswith Corey SandlerCopyright© 2004 by Word Association, Inc. All rights reserved.Published by John Wiley & Sons, Inc., Hoboken, New Jersey.Published simultaneously in Canada.整理:丁兆杰,黄墀晖,黄米青,林嘉,马晓靖,王博,吴航,余华兵,俞培源v.1.2 7/1/2008前言1979年Glenford J.Myers出版了一本现在仍被证明为经典的著作,这就是本书的第1版。
本书经受住了时间的考验,25年来一直被列在出版商可供书目的清单中。
这个事实本身就是对本书稳定、基础和珍贵品质的佐证。
在同一时期,本书第2版的几位合著者共出版了120余本著作,大多数都是关于计算机软件的。
其中有一些很畅销,再版了多次(例如Corey Sandler的《Fix Your Own PC》自付印以来已出版到第7版,Tom Badgett关于微软PowerPoint及其他Office组件的著作已经出版到第4版以上)。
然而,这些作者的著作中没有哪一本书能够像本书一样持续数年之后仍畅销不衰。
区别究竟在哪里呢?这些新书只涵盖了短期性的主题:操作系统、应用软件、安全性、通信技术及硬件配置。
20世纪80年代和90年代以来的计算机硬件与软件技术的飞速发展,必然使得这些主题频繁地变功和更新。
在此期间出版的有关软件测试的书籍已数以十计、甚至数以百计。
这些书也对软件测试的主题进行了简要的探讨。
然而,本书为计算机界一个最为重要的主题提供了长期、基本的指南:如何确保所开发的所有软件做了其应该做的,并且同样重要的是,未做其不应该做的?本书第2版中保留了同样的基本思想。
软件测试技术读书心得大致把《软件测试》翻了一遍,一本非常有趣且实用的入门级软件测试参考书,从技术角度,摘录/引申以下几个值得关注的话题:一、软件测试的主要目标软件是产品,作为产品,就需要类似“质检”的技术人员参与,我们所称的软件测试员、软件质量保证员(QA)。
软件测试员的工作目标是尽可能早地找出软件缺陷,这点,非常非常认同。
QA人员则侧重过程的改进,制订并执行防止软件缺陷的标准和方法。
软件缺陷主要包括:1、软件未实现应实现的功能2、软件出现了不应出现的错误3、软件实现了不应实现的功能4、软件未实现符合一般软件常识的功能5、软件出现了使用、性能上等不易被用户接受的问题二、软件测试的基本方法即静态/动态黑盒测试/白盒测试四类基本方法,某种程度上而言,构成了软件测试员主要的测试工作。
- 静态黑盒测试侧重根据功能需求说明文档设计测试用例。
- 动态(黑盒测试,好比带上眼罩测试软件,不需要了解软件如何实现的,尽可能地模仿最终用户。
- 静态白盒测试,侧重代码的审查及代码细节上的检验- 动态白盒测试,就好比带上X光镜测试软件,需要了解代码结构。
三、设计测试用例的主要原则1. 软件正常使用的用例,test-to-pass(通过性)2. 迫使软件出现错误(既定或未定的)的用例,test-to-fail(失效性)3. 使用等价类划分方法,合理减少测试用例且确保质量四、黑盒测试时应注意的事项1)测试对象数据;程序;2)测试方法对数据的测试,一般,考虑:- 边界条件包括,临近边界的有效数据、边界上可能有效的数据、刚超出边界的无效数据,例如:最小值-1/最大值+1- 次边界条件,例如:2的冥- 默认/空白/空值/0值/负值- 非法/不正确对程序操作的验证,主要对其状态进行测试,考虑每个独立的状态、状态间转换所需的输入条件、进入/退出某状态的条件及结果等。
此外,还需考虑容易使软件出错的测试:多任务执行;重复测试;压力测试;负载测试五、白盒测试时应注意的事项白盒测试主要通过查看代码的内部结构,了解代码实现了什么,如何实现,在此基础上,设计并执行测试,往往可以结合黑盒测试 + 代码覆盖测试的方法/技术同时进行。
《软件项目的艺术》阅读随笔目录一、内容描述 (2)1. 软件项目的重要性 (3)2. 软件项目管理面临的挑战 (4)二、软件项目策划阶段 (4)1. 明确项目目标 (6)2. 制定项目计划 (7)3. 分析项目风险 (9)三、软件项目设计阶段 (10)1. 设计项目架构 (12)2. 设计系统界面 (13)3. 设计数据库结构 (14)四、软件项目编码阶段 (15)1. 编写代码 (17)2. 代码审查 (17)3. 问题解决与调试 (19)五、软件项目测试阶段 (21)1. 测试计划制定 (22)2. 执行测试用例 (23)3. 缺陷追踪与修复 (25)六、软件项目部署阶段 (27)1. 部署环境准备 (28)2. 上线前的最终测试 (29)3. 系统上线与监控 (30)七、软件项目收尾阶段 (31)1. 项目总结与评估 (33)2. 项目经验教训分享 (35)3. 后期维护与优化 (36)八、结语 (37)1. 软件项目管理的艺术性 (39)2. 持续改进与创新的重要性 (40)一、内容描述在软件开发的世界里,每一个项目都如同一件艺术品,充满了创意与挑战。
当我翻开《软件项目的艺术》我仿佛进入了一个全新的世界,被其中关于软件项目管理的深刻见解所吸引。
书中详细描述了软件项目的开发过程,从需求分析、设计、编码到测试、部署和维护,每一个环节都充满了智慧和策略。
作者强调了项目管理的重要性,认为一个成功的软件项目离不开周密的计划和执行。
在阅读过程中,我特别被作者对于团队协作和沟通的阐述所打动。
在软件项目中,团队成员之间的协作和沟通至关重要。
只有通过有效的沟通,才能确保项目的顺利进行。
作者提供了一些实用的沟通技巧和方法,帮助读者更好地与团队成员协作,共同完成项目目标。
书中还谈到了风险管理、质量保证等方面的问题。
这些都是在软件项目中不可避免的挑战,作者通过丰富的案例和经验分享,为读者提供了应对这些挑战的策略和思路。
《软件测试的艺术》阅读整理(⼆)第三章代码检查、⾛查与评审编写的代码⼀开始时,只是给机器执⾏的,并没有想着供⼈们阅读,到了20世纪的70年代,⼀些程序员才开始意识到阅读代码对于完善软件测试和调试的价值。
到了今天,并不是所有的软件测试⼈员都要阅读代码,但是去研读程序的代码也是测试⼯作的⼀部分,已经得到了⼴泛的认同了。
3.1 影响到特定的测试和调试⼯作需要⼈⼯实际阅读代码可能性的⼏个因素:1. 软件测试规模和复杂度2. 软件开发团队的规模3. 软件开发的时限(例如时间安排表是松散还是紧张)4. 编程⼩组的技术背景和⽂化等3.2 ⼈⼯测试⼈⼯测试技术在查找错误⽅⾯⾮常有效,以⾄于任何编程的项⽬都应该使⽤其中的⼀种或是多种的技术来测试。
在程序开始编码前前期,中期,后期都可来进⾏设计测试。
重要的注意事项:由于包含了⼈为的因素在内,导致很多⽅法的正规性要差于由计算机执⾏的数学证明,我们可能会去怀疑有些简单和不正规的东西是不是有⽤。
反之,这些不正规的⽅法并没有影响到测试取得成功;相反,它们还从以下两个⽅⾯显著的提⾼了测试的功效和可靠性:1. 我们通常认为错误发现的越是早,改错误的成本会越低,正确的改正错误的可能性也越⼤2. 程序员在开始基于计算机的测试时似乎会经历⼼理上⼀个转变。
从程序⼈员⾃⾝的内部压⼒似乎会越来越⼤,产⽣⼀个想法,要:“尽可能的修复这个缺陷”。
由于这些压⼒⼤的存在,程序员在改正某个Bug时,要⽐改正早期发现的问题时所犯的失误会更多⼀些。
3.3 检查与⾛查代码检查和⾛查都是⼈⼯检测的⽅法。
这种测试技术在编码之后计算机测试之前使⽤,要求⼈们组成⼀个⼩组来阅读和检查程序,可以有效的在项⽬早期发现错误,并改正错误。
代码检查和代码⾛查有以下的相同点:1. 组成⼩组来阅读或直观检查特定的程序2. 在代码⾛查中,⼀组开发⼈员(3-4⼈最佳)对代码进⾏审核。
参加者当中只有⼀⼈是程序编写者。
3. 代码检查与⾛查是对过去桌⾯的检查过程(在提交测试前程序员阅读⾃⼰的程序的过程)的改进。
The Art of SoftWare Testing》读书笔记(1)_引子有关自己与软件测试之间的渊源而言,获悉这个领域的时间不长,接触的时间就更可谓短暂,但仔细想来,还要从大学期间说起比较好。
软件测试这个概念第一次出现在我的眼前时,是大四上学期开的软件工程这个科目中所涉及到的一点点。
由于某些因素,使我在大学期间忽略了对测试领域相关知识的储备。
第二次面对它时,是考研复习准备阶段。
那时,我对测试这个领域也仅仅只是知道,就是中文书面表达的“测试”这两个汉字的含义而已。
工作的前两年里,或许是因为从事的是有关算法方面性质的工作,所以并未对测试这个领域给予过多的关注,还好,或多或少还是接触到了一些。
直到最近一年多来,由于一个大型项目人手不够的缘故,所以临时从自己负责的另一个研究项目中抽过来(刚好该项目阶段性完成),负责有关此项目的测试部署与规划。
而这个时候,才能说是:真正意义上接触到了软件测试这个领域。
虽然,在此项目中也有自己开发的一些模块、算法及一些模块、算法的优化跟重构。
但,从这个项目阶段性结束后自己的体会而言,给我感悟最深的还是有关软件测试这个领域的。
通过在这个项目里的工作,让我真正体会到了:软件测试是一门艺术。
恰恰也是因为这个缘故,这也才让我开始有了想重新认识和品位测试艺术这一领域的奥妙所在。
《The Art of SoftWare Testing》读书笔记(2)_前言喜欢在网上书店中遛达,看到不错的书就买下。
为什么不去书店?一个字,懒呗!总觉得,有那去书店的时间,完全可以好好睡一美觉,亦或可亲手烹制一顿美味可口的美食。
哎,反正就是,懒得走出家门去逛街!恰巧,此次浏览书籍时,无意间看到了《The Art of Software Testing》这本书。
在看了大家所给予它极高的评价留言后,虽然有些疑惑(毕竟这个时代,枪手太多了!),但我深信:一本书能够“活”25年,应该还是很不简单的。
于是,就半信半疑的订购了这本书,期望能够从这本书中获悉到有用的知识,来丰富一下自己面对这个领域时的贫乏困境,亦作为知识储备。
晕,这么薄!这是我拿到这本书后的第一反应。
真的!没有预料到这书会这么薄!原以为这本经典的书,会诸如《C++ Primer》、《The C++ Programming Language》、《Programming Windows》等这些著作那么厚。
而当翻看了几章后,觉得确实很经典,也明白了为什么这本书会“活”了25年。
于是,就诞生了我对这本书的第二感觉:薄而精!看来是需要自己多花些时间去慢慢的品味,这样才方可体味到最纯最美的底酝。
打住自己对这本书的侃侃而谈(怕跑题太远,拽不回来),还是关注一下软件测试这个领话题吧!软件测试,怎么说呢?就自身经历而言,确实如书上所说:测试依然是软件开发中的“黑色艺术”。
大学期间,计算机课程开的不少,没听说有专门开一门关于测试的课程。
所以,在学生阶段,测试就属于是个被抛弃掉的名词!毕业时,不是做软件就是去搞网络,没有听到一个同学去应聘测试的!工作中,有专门的测试组(或部门),就更不用自己怎么上心去研究了!如今的氛围就是:红的够红,黑的够黑!那叫一个“专”!哎,为什么不实行“两手都要抓,两手都要硬”的政策呢(一己之见,偏颇在所难免)?或许,我还不明白:“术业有专攻”的深刻含义吧!算了,最后还是谈谈对这本书的总观吧!1.该书是针对测试这一主题进行的实践探讨,而不是理论研究,顺便捎带了些对新的语言和过程的探讨;2.前言中提到了一个最为重要而又是长期、基本的指南:如何确保所开发的所有软件做了其应该做的,并且同样重要的是,未做其不应该做的?3.引言里指出一条著名的经验:即在一个典型的编程项目中,软件测试或系统测试大约占用50%的项目时间和超过50%的总成本。
《The Art of SoftWare Testing》读书笔记(3)_一次自我检测有创意!这是我对该书第一章的评价,也是唯一一次在看新书开篇时,能够把第一章给透透彻彻看完的。
为何?还不是实在不能恭维有些书籍在开篇就进行枯燥而繁多的总结性、介绍性的文字。
虽心里也清楚这些文字存在的重要性。
但每每,还总是先粗略瞄过,在通读全书后,才会再次认认真真的看那些文字(这时,才真的能感悟到“提纲携领”的中文含义啊)。
创意在于:它只通过展示一次自评价测试,就能吸引我的眼球,并涌出一种想继续向下读的冲动;更能引起对自身一些有关逻辑思维(考虑欠周全、缜密,存在盲点)、联想能力(需拓展思维,要富于联想与想像,即:思维“活”起来)、角度问题(要巧妙转换角度)等方面,所可能存在的不足进行深思。
当然,能够引起深思的缘故,还不是在于那个评价测试嘛!提起来,汗颜!依据所谓的测试用例(即:特定的数据集合)自测试后,发现自己只能考虑到11项(总14项)需要测试的关键点。
文尾,谈谈作者对“软件测试”这个概念的定义吧。
所谓软件测试,就是一个过程或一系列过程,用来确认计算机代码完成了其应该完成的功能,不执行其不该有的操作。
软件应当是可预测且稳定的,是不会给用户带来意外惊奇的。
《The Art of SoftWare Testing》读书笔记(4)_初次探究“软件测试是一项技术性工作,但同时也涉及经济学和人类心理学的一些重要因素”,这是该书第二章中最吸引我的话,耐人深思。
而对于该章的内容,我个人觉得可概括为以下三个方面:o心理学角度:驳斥了一些社会普遍存在的错误认识,并给出了测试的正确定义及在含义上进行了延伸。
(用写文章上常用的术语来说,是:先破后立。
)o经济学角度:验证软件测试不能够发现“所有”的错误。
(术语是:各个击破。
)o归纳了软件测试中的一些基本原则(术语是:归纳与演绎。
),及三个重要的测试原则:1.软件测试是为发现错误而执行程序的过程;2.一个好的测试用例具有较高的发现某个尚未发现的错误的可能性;3.一个成功的测试用例能够发现某个尚未发现的错误。
文尾,值得一提的是:在本章能明显感到作者侧重于从心理学角度来分析一些潜在的问题。
The Art of SoftWare Testing》读书笔记(5)_心理学视角解析(上)先谈谈从心理学角度所需要分析的问题。
在章节的开始,作者就明确的给予了一个认知:要成功地测试一个软件应用程序,测试人员也需要有正确的态度。
在某些情况下,测试人员的态度可能比实际的测试过程本身还要重要。
并且,分析了现在社会上普遍存在的两种“本末倒置”的错误认识。
•针对程序员:一开始就把“测试”这个术语的定义搞错了。
所以可想而知,作者肯定要先破其错误的根源和弊端,然后再立其正确的认知,为了能更深入的理解和在实践上的把握,作者又对正确的认知给予了进一步延伸的阐述;•针对项目经理:针对测试方面而言,对“成功的”和“不成功的”的理解认识上的错误。
文尾,值得一提的是:作者在这引荐一个病人去医生那里看病的例子,于是将一些绕人的关系和原理,刹那间弄的清晰易懂了。
看来恰当适宜的举例还是比枯燥的讲解概念间的区别与联系要容易的多,也生动的多,并且使人也能理解的更加深刻。
《The Art of SoftWare Testing》读书笔记(6)_心理学视角解析(中)上次谈到了两个错误认识,那就继续这个话题吧。
先分析与项目经理有关的这个错误认识吧。
因为这个因素可能会导致一些在测试问题上的根本性错误的认识。
作者主要是从“成功的”和“不成功的”这两个方面来剖析的:•指明了错误认识的本源:“成功的测试”是指没有发现错误的测试用例;而“不成功的测试”是指发现了某个新错误的测试。
•明确正确认识的本质:如果在测试某段程序时发现了错误,而且这些错误是可以修复的,就将这次合理的设计和由此得到有效执行的测试称为是“成功的”;并对如果在本次测试中可以最终确定再无其他可查出的错误,同样也被称作是“成功的”;而对未能适当地对程序进行检查,且在大多数情况下,未能找出错误的测试被称为是“不成功的”。
•引荐病人去找医生看病的这一生动的例子,加以引申理解并给予了结论:能发现新错误的测试用例不太可能被认为是“不成功的”,相反,能发现错误就证明它是值得设计的。
一个“不成功的”测试用例,会使程序输出正确的结果,但不能发现任何错误。
细想:如果规划的测试用例是能使程序输出正确的结果,但不能发现任何错误的话,那是多么的可怕阿。
那么测试就等于没有测试,或者是在徒劳。
而潜在的错误还依然潜在,这会开发人员跟用户来说,都是有不小的隐患的。
这才真正认识到:发现测试真的是一门需要去潜心研究的艺术。
不仅仅是为了我们开发人员自己,也为了用户,更为了将来软件能够更好的维护跟升级。
《The Art of SoftWare Testing》读书笔记(7)_心理学视角解析(下)接着,来谈谈程序员方面会产生的错误认识吧!这个方面可能在具体实践中显的更重要。
由于作者在开篇就先把三个错误认识给摆到读者的眼前;然后就立马表明了其正确的定义,并给予了分析和对错误认识的驳斥。
洋洒洒的写了许多,条理上未免会有些混乱。
因此,我就按照自己理解的来小结一下吧!首先,测试的正确定义是:测试是为发现错误而执行程序的过程。
该定义暗示了两层含义:•软件测试是一个破坏性的过程,甚至是一个“施虐”的过程。
(就自己的亲身经历而言,大部分的开发人员在测试期间,对测试人员或多或少都会暂时产生一点厌烦或恐惧的心态。
主要是会让开发人员的代码改的面目全非的,且这个过程是反反复复的。
)•对于一个特定的程序,应该如何设计测试用例(测试数据)、哪些人应该而哪些人又不应该执行测试。
(这是有关测试人员构成的问题。
就自己的亲身经历而言,这一点很重要,因为测试人员的态度要比测试的过程更为重要。
)然后,明确测试的正确含义后,探究了一下现今面临的三个错误认识并逐一给予了充分的驳斥。
•“软件测试就是证明软件不存在错误的过程”。
1.若目的仅是为了证明程序中不存在错误,就会在潜意识中倾向于实现这个目标;即,会倾向于选择可能较少导致程序失效的测试数据;若目标在于证明程序中存在错误,设计的测试数据就有可能更多地发现问题。
后者肯定比前者会更多地增加程序的价值。
2.心理上,对于证明不存在是一个不可能完成的任务,无论该工程多么小;但若是一个寻找错误的任务,是可以完成的。
就心理承受而言,也是更容易接受的。
•“软件测试的目的在于证明软件能够正确完成其预订的功能。
”1.心态上,不要本着只是为了证明程序能够正确运行而去测试程序,而应该一开始就假设程序中隐藏着错误(这种假设对于几乎所有的程序都成立)。
这样测试程序时,才能够发现尽可能多的错误。
2.要清楚这样一个道理:每当测试一个程序,实质上是想为其增加一些价值。
通过测试来增加程序的价值,及是指测试提高了程序的可靠性或质量。