《Software Testing》第十二章 – 文档测试

文档测试,其实可能在国内真的不太现实。国内的公司总体来说不太正规,能把那个软件测试完都不错,这个文档嘛……通常都是后来才补上去。然后如果在国内的外企的话,通常也接触不了高层的文档,看看是可以的,不过至于说道参与修订或者评审,基本很难。还是期待国内正规公司数量的增长啊!

软件文档的种类。说起文档,我最初认为就是一个readme。后来发现有需求文档,设计文档,帮助文档,但是……其实文档的种类是有很多的,书上列举了一些,有可能公司只有其中的某几种~也是正常的

Packaging text and graphics – (包装文字和图片)。呵呵,这个厉害吧,可能现在很多软件都不是用CD或者DVD来作为载体来发布了,不过包装,就是属于软件文档的一种哦!

Marketing material, ads, and other inserts – (市场资料,广告和其他相关插页)。这个是关乎公司的宣传效果还有能卖出多少产品的哦,不过我觉得这方面通常有专门的独立部门去处理,设置外包到专业的广告公司,所以这方面嘛~还是不要越俎代庖。一些建议是要的,不过专职去做,好像不太合适。其实上一种也是的。
Continue reading “《Software Testing》第十二章 – 文档测试”

《Software Testing》第十一章 – 可用性测试

Usability Testing – 可用性测试

UI Testing – 用户界面测试。UI这个词其实范围很宽。什么样的东西是UI呢?VISTA那样炫的是UI,DOS窗口也是UI。以前古老电脑上的LED也是UI的一部份,其实一句话,UI就是用户跟计算机交互的界面。什么样是一个好的用户界面?书上归纳了7点。

Follows Standards and Guidelines – 遵循标准和指引。这两个东西在书上都出现了好多次了,呵呵,反正就是说标新立异的东西都是有风险的,因为标准已经是被前人证明是好的,至少是合理的嘛~所以遵守这些标准来做出来的东西一般来说会有一个好的UI。大家发现没有,WINDOWS跟LINUX的UI规范是不同的,WINDOWS里面,左边的是OK,Cancle在OK的右边,而linux里面就是相反的:)
Continue reading “《Software Testing》第十一章 – 可用性测试”

《Software Testing》第十章 – 国际化测试

外国语言测试,刚开始我以为是讲I18N的,不过看完这章以后觉得这章并不是讲I18N的,虽然提到了一部份,不过不够完整吧。也讲到了一些L10N的。

  • G11N就是Globalization 软件全球化
  • I18N就是Internationalization 国际化
  • L10N就是Localization 本地化

相关的资料现在国内有一本书《国际化软件测试》,电子工业出版社出版,作者是崔启亮和胡一鸣。

第一条就是是“使文字和图片有意义”。简单来说不要把What are you doing翻译为什么是你在做。是不是很像某某翻译软件出来的结果?不过这一条都不是一般的测试工程师能做的,通常都是外包给当地的一些翻译的公司或者专门做L10N的公司。

下来讲了一下翻译的问题,书中提到一个比较好的方法是外包给当地的L10N测试公司。现在这年头什么都外包啊,不过外包的确有它的优势。

Continue reading “《Software Testing》第十章 – 国际化测试”

《Software Testing》第九章 – 兼容性测试

兼容性测试(Compatibility Testing)。简单来说就是公司的软件要跟自己兄弟产品还有别的产品能和平地在系统上正常运作。下面有一些例子:

1.在网页上剪切一些内容,然后粘贴到文字处理软件里面
2.把一些资料用A工作表软件打开,然后保存以后,在B工作部软件里面打开
3.一个图像处理软件运行在不同版本的操作系统上

在兼容性测试里面需要注意的一些事项:

1.你的软件是被设计到工作在哪些平台上的,需要跟哪些软件进行交互。
2.公司是按照哪些标准和指引来工作的。
3.你的软件用什么类型的数据跟别人软件进行交互。
Continue reading “《Software Testing》第九章 – 兼容性测试”

《Software Testing》第八章 – 配置测试

配置测试(Configuration Testing)是一个检查我们的软件在不同的硬件环境下能否正常地工作的过程。这当中牵涉到几样东西,电脑本身,电脑配件,外设,接口,选项,存储器和驱动。不同的软件会有不同的针对点,例如对于一个游戏软件,例如QUAKE IV,它最应该关心的是显卡和声卡的测试,一个图像处理软件有可能关注于显示配置和打印机的测试。

怎样准确分离出配置错误(Isolating configuration bugs)。一个简单的方法就是,如果在测试的过程中遇到了bug,在其他一些不同配置的机器上运行同样的操作,看问题是否能重现,从而达到分离出引起这个bug的最根本的原因。

那么遇到了问题应该又谁来负责修复呢,是软件公司呢还是硬件厂商?一个配置错误通常会有一下四种表现形式:

1.软件在一系列的硬件配置条件下都出现错误,例如连上激光打印机就挂了。
2.软件在一个特定的型号的硬件下出现错误,例如只是连接上Magus牌扫描仪才挂!
3.软件只受到某个硬件或者是硬件的驱动程序所影响而出现错误。
4.硬件或者它的驱动程序本身是有问题的,也影响了其他的一些软件,不过我们测试的软件在当前硬件配置下受到的影响特别大。

Continue reading “《Software Testing》第八章 – 配置测试”

《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》第三章 – 软件测试”