《Software Testing》第七章 – 白盒测试

第七章:Testing the Software with X-Ray Glasses。

Dynamic White-Box Testing(动态白盒测试)-动态,就是软件在运行;白盒,我们能看见里面怎么运行。所以就好像是带了X-光眼镜一样。它还有另外一个名字,就是结构测试(Structural Testing)。动态白盒测试通常包含了四个方面。

1.直接对底层的函数,过程,库~等进行测试。也就是对API的测试
2.站在一个比较高的层次来测试软件,而且是根据你对软件行为的认知的情况下进行,根据code具体的情况设计有针对性的case进行测试
3.验证已经设计好的case是否真的符合了当初设计的初衷。还有就是强行改变一些通过正常途径很难达到的软件的状态。这个例如说,一般软件都有很多错误的提示信息,但是要把全部错误信息通过正常渠道(用这个软件)得到,是比较困难的。不过在白盒测试里面,我们可以直接在debug器里面改相应的flag变量来达到目的
4.根据各种code coverage的结果来对已有test case的增加和修改,以达到更好的测试效果。
个人的一些体会,其实测试就是一个动态的过程,test case需要动态的维护、更新和增加,以达到好的效果。呵呵,动态可不单只是指软件运行~一语双关啊~或者说这个词被重载(Overload)了。

Continue reading “《Software Testing》第七章 – 白盒测试”

《Software Testing》第六章 – 检查代码

Examining the Code – 检查代码。这章主要讲的是(Static White-Box Testing)静态白盒测试:对设计和代码的检查。

(Static Testing)静态测试,就是对那些不运行的东西进行测试–检查和评审。
(White-Box Testing)白盒测试,指可以看到内部结构并且可以对之进行评审。
(Static White-Box Testing)静态白盒测试,就是在不运行软件的情况下对其设计,架构或者代码进行检查。有时候也叫(structural analysis)结构分析。

 (Formal Reviews)正式审查。正式审查是一个严格的正规的活动。如果评审是一个随机的过程,那么所有事情都成了随机,开会时间是随机,发现的bug是随机,效果是随机,回家的时间也是随机的。对于正式审查,有以下4个根本要素

1.(Identify Problems)找出问题。核心我觉得就是一句话,对事不对人。发现了代码或者文档的问题,就只能就这些问题进行批评,而不是去找到谁干的,然后对他劈头盖脸的训斥一顿。

Continue reading “《Software Testing》第六章 – 检查代码”

《Software Testing》第五章 – 黑盒测试

这章标题是:Testing the Software with Blinders On。带上眼罩去测试软件,不是让你瞎测哦。主要讲的内容就是黑盒测试的技术。

动态黑盒测试(Dynamic Black-Box Testing)

也有叫行为测试(behavīoral Testing),功能测试(Functional Testing)。现在可能国内很多单位就真的是一个瞎子来测试软件,不是说那个测试人员是瞎子,是老板让他们变成了瞎子,为什么呢?因为可能大多数都缺少文档,我们需要的是软件的需求文档-Requirements Document(需求文档)或者是 Product Specification(产品说明书)。

测试用例(Test Case)。

Test cases are the specific inputs that you’ll try and the procedures that you’ll follow when you test the software.我的理解,测试用例就是一组根据相应文档而设计出来的操作步骤,输入数据和输出结果,是对软件产品的进行测试的执行过程。

这章还提到了一个概念–Exploratory Testing(探索性测试)。
Continue reading “《Software Testing》第五章 – 黑盒测试”

《Software Testing》第四章 – 检查产品说明书

这章主要介绍了静态黑盒测试的一种:对说明书的测试。我觉得跟以前的PEER REVIEW是相同的。之所以是静态的是因为测试的对象是静态的文档而不是运行的软件。黑盒呢就是因为测试员并不需要知道这个说明书是怎么写出来,那些资料来源于哪里,是否准确,怎么利用数据等等……只需要关心说明书的本身就可以了。

这个评审分为两个部分,第一部分是对说明书的概要评审。有三点是要做到的:
1.以用户的角度去看问题。可以先找软件的最终用户去谈谈,了解一下他们的习惯什么的,我觉得这里说的最终用户是End User而不是Customer。在这章里面我觉得比较精辟的句子就是:The definition of QUALITY means “meeting the customer’s needs”。
2.研究现有的标准和指南。不要做出来的软件是标新立异的,有时候个性是好,不过过分的个性通常不会有好的下场啊。
3.对类似的软件进行评审和测试。有句话说的很好,“你想不到的你的敌人会告诉你”。去看一下竞争对手的产品。  Continue reading “《Software Testing》第四章 – 检查产品说明书”

《Software Testing》第三章 – 软件测试

Testing Axioms,做每样事情都是有他的游戏规则,同样软件测试也有一些需要遵守的原则。

1.It’s Impossible to Test a Program Completely
当然啦,要测完岂不是要我命!得出这个结论的理由是,当输入集是很大的,输出集也是很大的,软件的可能路径太多。而且还有一个因素也是最要命的:说明书是很主观的

2.Software Testing Is a Risk-Based Exercise
既然没办法100%全部测试,那怎么办?根据风险来判断什么该测,定义好出口条件

3.Testing Can’t Show That Bugs Don’t Exist
软件测试这份工作很特殊,当你找到问题的时候,证明了软件是有缺陷的;但是当你找不到问题的时候,并不能证明该软件是BugFree的。
Continue reading “《Software Testing》第三章 – 软件测试”

《Software Testing》第二章 – 软件开发过程

软件开发过程,软件就是一件产品,那么这个产品的生产过程是什么呢?在这个过程中都有些什么中间产物呢?

Customer Requirements(客户需求)

Specifications(说明书),说明书是从需求转化而来,定义了产品是怎么样的,能干什么等等

Schedules(进度表)

Software Design Documents(设计文档)书上说的5种,有些也可能只是某文档的一部份而已。我自己见过比较常见的High-Level Design(概要设计), Low-Level(Detail) Design(详细设计)。书上说的数据流图,状态转换图等等,有时候就出现在HLD里面了

Test Documents(测试文档)包括了测试计划,测试用例,问题报告,统计报告等……这里我自己讲讲体会,刚到SPSS实习的时候看文档的时候我看到了Test scrīpt这个名词,一开始我以为是自动化脚本,后发现其实就是Test Case,所以说这些所有名词都可以有其他叫法。

以上就是作为一个测试工程师会经常遇到的文档。
Continue reading “《Software Testing》第二章 – 软件开发过程”

《Software Testing》第一章 – 软件测试的背景

这个读书笔记系列是我在上学实习的时候写的,现在要把它从51TESTING搬过来,顺便梳理一下。

从事软件测试的同学获取曾经都遇到过这样一个问题:应该怎么称呼BUG呢?一个专业的定义是:Software Failure,但是还会有很多各种各样的称呼,例如:

  • Defect(很多美国公司都是用这个,例如Reynolds, SPSS, MySpace.com)
  • Fault(过错、毛病之类,听起来比上面的严重)
  • Problem(问题)
  • Error(错误,看起来好像挺严重的)
  • Incident(事件,这个词看着很温和,没那么激进)
  • Anomaly(异常,非正常)
  • Variance(不一致,这个也很“客观”啊)
  • Failure(失灵~故障,听起来也是很吓人的)
  • Inconsistency(矛盾!个人认为比较客观的说法)
  • Feature(特征,)
  • Bug(最后一个,也是最常用的就是这个,MySpace.cn一般都这样叫)

每个公司都有自己的叫法,之所以有那么多叫法根据猪蹄说的原因就是~要估计程序员的感受,不要搞的DEV和QA好像是对立面似的。在埃森哲叫SIR,不是先生的意思,而是System Investigation Report。其实叫啥不重要,就像人的名字,一个符号而已。
Continue reading “《Software Testing》第一章 – 软件测试的背景”