说是连载不过还不知道能不能写下去，不过现在写了三章了就先贴上来吧~
我读的是英文版的《软件测试》所以有些观点或者定义或者名词有可能不是完全理解正确的，所以如果大家看到什么错漏赶紧告诉我哦。嘿嘿，其实这个也是我贴上来的目的，让大家过目一下，帮我提高~~谢谢大家了~还有的就是我并不是按照章节顺序下来的，有可能省掉一些内容，如果没看到的就是省掉了，省掉了并不是说不重要，而是我觉得可能那些知识点在其他地方有更加详细的介绍，或者说我自己觉得自己已经掌握了就没有花时间记下来~大家原谅我的懒惰吧！~~
还有的就是这个读书笔记其实是以博客的形式出现的，所以用语比较随便不正规，大家看了就取其精华去其糟粕就是了，再次原谅一下我……sdlkfj1
希望大家多提宝贵意见，共同提高！！！

《Software Testing》Second Edition, Ron Patton.为了方便~下文就称之为STSE。

Software Testing里面一个比较有趣的问题就是，应该怎么称呼这个BUG呢（貌似我已经给下了定义-__-b）。这个更加专业点吧，就是Software Failure有什么称呼！？其实有以下列举的词~包括但不仅限于哦~

·
Defect（REYREY以前就用这个，感觉还挺好~）

·
Fault（过错、毛病之类，听起来比上面的严重）

·
Problem（问题~）

·
Error（错误~看起来好像挺严重的）

·
Incident（事件~这个词看着很温和，没那么激进）

·
Anomaly（异常~嗯……）

·
Variance（不一致，这个也很“客观”啊）

·
Failure（失灵~故障，听起来也是很吓人的）

·
Inconsistency（矛盾！个人认为比较客观的说法）

·
Feature（特征，功能……这个……我汗啊）

·
Bug（最常用的就是这个）

每个公司都有自己的一个叫法，之所以有那么多叫法根据猪蹄说的原因就是~要估计程序员的感受，不要搞的DEV和QA好像是对立面似的，所以他们公司叫SIR，不是先生的意思~~System Investigation Report~~有问题了，你们（DEV）去调查调查吧~哈哈，有意思！以前公司叫SPR~System Problem Report~~这里有个问题报告哦。现在我实习的地方好像直接叫Defect Report~其实叫啥不重要，就像人的名字，一个符号而已~

现在来探讨一下一个BUG的定义是什么~根据STSE里面定义，一个BUG就是
1.the software doesn't do something that the product specification says it should do.
举例：如果spec上说，只要填好必填的项目，然后按“注册”就能注册成功，但是实际发现不行~注册不了
2.the software does something that the product specification says it shouldn't do.
举例：如果spec上说，只要填好必填的项目，然后按“注册”就能注册成功，实际发现没填完必填的项目也能成功注册
3.the software does something that the product specification doesn’t mention.
举例：如果一个网络游戏的spec上没有提及该游戏提供实时语言聊天功能，但是游戏release以后发现多了这个功能，那么这就是一个bug。因为实现的feature越多~把bug带进软件的机会就越大~
4.the software doesn't do something that the product specification doesn't mention but should.
举例：例如一个充电器spec上没有说这个充电器在电池满电的时候会自动断电保护，但是这个自动断电保护的功能是应该有，如果不是大家都被XX电池炸死了，呵呵~
5.the software is difficult to understand, hard to use, slow, or-in the software tester's eyes-will be viewed by the end user as just plain not right.
这个就不举例了，不过我个人觉得这个很难去厘定，什么是难用，什么是慢~HOHO~

有了上面的定义现在可以讨论一个问题~如果现在有这样的一个BUG，他在产品的整个开发周期里面都没有被发现，最终release了出去，但是很幸运地~客户也没发现这个BUG~那么这个BUG能叫一个BUG么？~
这个讨论一定是个很有意思的讨论，嘿嘿，大家可以在什么Seminar上拿出来研究研究，嘿嘿！我个人认为，如果根据以上对BUG的定义，那么他就是一个BUG，至于有人会争辩说~这不是一个BUG，都没有人发现他，没有对任何人或者机构造成任何的IMPACT~不过STSE上有这样的一句话：
If a tree falls in the forest and there is nobody around, does it make a sound?
呵呵，不过这个也就是茶余饭后讨论着玩的问题吧，DEV和QA有一大堆问题需要处理，对这个“未知”的BUG，何必那么较真~

下面就看看一个软件都包含了哪些东西~

嗯……软件不就是一个CD-ROM嘛~
错了！是DVD-ROM~
别傻了现在都是网上下载的~

这些只是我们一般用户看到的最终产物~不过对于一个tester来说，以下的东西对工作是比较重要的：
Customer Requirements（客户需求）~现在这个物质极大丰富的年代（相对于80's，呵呵），做生意已经不是说我做一个XXX产品出来卖给你，而是我看你（用户）喜欢什么，然后我回去做好了再拿来卖给你，所以客户需求是很重要的，不过说实话估计大多数公司的tester都没时间看需求吧~接到任务的时候都已经快release了~天啊！！
Specifications（说明书），说明书从需求转化而来，定义了产品是怎么样的，能干什么等等……根据行业的不同，说明书的详细程度也有所不同。
Schedules（进度表）大家都见过的~呵呵。这个表的目的其实就是能看到哪些工作已经完成，没有完成的任务还需要多长时间才能完成，然后总的任务在什么时候能完成等等~
Software Design Documents（设计文档）书上说的5种，不是全的，有些也可能只是某文档的一部份而已。我自己见过比较常见的High-Level Design, Low-Level(Detail) Design。书上说的数据流图，状态转换图等等，有时候就出现在HLD里面了~
Test Documents（测试文档）包括了测试计划，测试用例，问题报告，统计报告等……这里我自己讲讲体会，刚来这个公司看文档的时候我看到了Test Script这个名词，一开始我以为是自动化脚本，后发现其实就是Test Case，所以说这些所有名词都可以有其他叫法，概念上本质上是一个东西就行了~呵呵

说了那么久，那一个Tester究竟是干啥的，STSE里面说的是
The goal of a software tester is to find bugs.
嗯！那么简单，就是找BUG嘛~~哈哈！但是……如果tester找的比customer慢，那岂不是白养了？所以就有
The goal of a software tester is to find bugs and find them as early as possible.
如果我们找的比客户快和早，那么对于用户来说就不是BUG啦，呵呵~~慢着，找到就完了？哦~对，还要保证BUG被修复的啊，如果不是就白找了~最终的定义是
The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed.
呵呵，就是快恨准~

Testing Axioms，做每样事情都是有他的游戏规则的，考个驾照怎么样也得买个烟吧，小孩子入学怎么样也得给点XX费吧，买饭也要排队哦。同样软件测试也有一些需要遵守的原则吧~呵呵

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
逛街一天，安全回家，没有丢东西，但这样你就能100%肯定地说街上没有贼么？嘿嘿~同样适用于对软件的评价~
4.The More Bugs You Find, the More Bugs There Are
通常BUG都是扎堆的，物以类聚啊~
5.The Pesticide Paradox
杀虫剂用多了~害虫也就对杀虫剂免疫了~对于BUG也是一样，书中建议要设计不用的TC来测试软件，但是实际上估计是没有那么多的时间让人去设计新的TC，能Regression完就不错了~不过这或许以后能做到~
6.Not All the Bugs You Find Will Be Fixed
有时候可能会很兴奋地发现一个bug，但是提交了上去却没有被修复，这时候不要郁闷，平常心~有可能你发现的bug是个大bug，在短时间内修复不了，嘿嘿，自己YY一下嘛~也有可能是一些无关紧要的bug，就留到下一个release吧~反正我自己觉得，不要没发现一个bug都追着DEV让给修复~大家都是出来混的，都不容易嘛
：）
7.When a Bug's a Bug Is Difficult to Say
这个我前面提过了~
8.Product Specifications Are Never Final
所以当你知道spec又改的时候，不要灰心，因为这是很正常的事情，要去面对，而不是埋怨~
9.Software Testers Aren't the Most Popular Members of a Project Team
测试工程师不好当啊~呵呵，书中要我们做到3点~
尽早发现问题，因为问题发现的越早，修复这个问题的代价就越小~
调节一下自己的狂热情绪~，不要一发现了问题就走去DEV那里给他说你发现了超级大BUG嘿嘿。这样子DEV肯定不爽
不要总给DEV坏消息，要给点鼓励的，例如一个模块没有bug，发个email赞扬一下~
10.Software Testing Is a Disciplined Technical Profession
我自己通俗理解就是~软件测试不是随随便便就能干的，是个有前途的职业~呵呵！

然后就是Software Testing Terms and Definitions。一些相近的定义，但是要分清楚他们的区别~那些英文单词我就不翻译了，估计是翻译不准，反正在公司也是英文来英文去的~
1.Precision and Accuracy
这个我一开始看也看不出有什么不同来~后来发现了，前者是精确后者是准确，计算器的例子就是，如果10/3，出来的是3.3333333那么就是准确的，但是精确到多少位呢？看说明书~书上那个图很能说明这两个定义的区别，果然是a picture is worth a thousand words啊~呵呵！
2.Verification and Validation
这两个词第一次接触是在reyrey培训的时候pat给说的~那时候还查了WIKI，现在公司居然上不去WIKI~VPN白搭了~。WIKI上的定义是
Verification ensures that the final product satisfies or matches the original design (low-level checking) — i.e., you built the product right. This is done through static testing.

Validation checks that the product design satisfies or fits the intended usage (high-level checking) — i.e., you built the right product. This is done through dynamic testing and other forms of review.

STSE上说的是Verification是检查软件是否符合说明书的要求。Validation是检查软件是否符合用户的需求。其实都是一个意思。

3.Quality and Reliability
质量与可靠性，很多人觉得高质量的产品就是可靠性很高的产品，但其实不然~质量包括了很多方面，可靠性只是“很多方面”里面中的一个而已。

4.Testing and Quality Assurance (QA)
这个在reyrey培训的时候也说过，当时说的是QC和QA的区别。一般理解是：
QA:为了确保软件开发过程和结果符合预期的结果，依照过程和计划采取的一系列活动及其结果评价。
QC:为了发现软件产品的错误而进行工作的过程。
这两个其实是不一样的东西，不过现在很多公司基本上都是QA,QC不分，进去以后可能是看具体你要干啥就干啥……不过这个概念上还是要分清的，这个面试也经常有，虽然面试那个人搞的好像很清楚似的，但是进去以后也是QAQC不分~呵呵

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

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

第二部分讲的是对说明书的详细测试~书里面列举了两个Checklist
1.关于说明书本身的属性。
Complete--说明书上有没有漏掉什么东西
Accurate--正确性，对产品的定义是否是正确的呢
Precise, Unambiguous, and Clear--描述要清晰，不要出现模棱两可的描述
Consistent--要一致，不要前后矛盾或者跟其他相关文档矛盾
Relevant--相关性，（其实我还不太能完全理解）
Feasible--是否可行，如果说用手机来看HDTV，可以不，也许可以，不过不是现在。
Code-free--不要在说明书里面出现代码算法什么的，客户不会关心我们怎么实现。
Testable--是可测试的。

2.关于说明书的一些术语。
Always, Every, All, None, Never--对于这些肯定的用语，一定要检查清楚看究竟所描述的相关部分是否真的100%肯定。
Certainly, Therefore, Clearly, Obviously, Evidently--这些带有假设性的词语也是需要注意的，别跳坑了。
Some, Sometimes, Often, Usually, Ordinarily, Customarily, Most, Mostly--这个跟上面提到的Precise, Unambiguous是一致的，不要出现模棱两可的定义，例如这个系统大多数情况下是不会死机的。
Etc., And So Forth, And So On, Such As--出现这些词语都是有问题的，违背了Testable这个准则。因为这样的列表是没完没了的列表。
Good, Fast, Cheap, Efficient, Small, Stable--出现这些词语也是违背了Testable原则。快？对于每个人来说都有不同的定义，“系统启动的很快”。有的人觉得5秒启动就是快的，有人可能觉得10分钟也是快的哦，谁知道呢。呵呵。
Handled, Processed, Rejected, Skipped, Eliminated--通常这都会隐含了很多功能，而这些功能却没有被详细地指出来。
If…Then…(but missing Else)。有IF就必须要有ELSE！

[ 本帖最后由 maguschen 于 2007-8-13 22:46 编辑 ]

很好,继续,正好我也在看这书的英文版!

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

动态黑盒测试(Dynamic Black-Box Testing)
也有叫行为测试(behavīoral Testing)，功能测试(Functional Testing)。现在可能国内很多单位就真的是一个瞎子来测试软件，不是说那个测试人员是瞎子，是老板让他们变成了瞎子，为什么呢？因为可能大多数都缺少文档，我们需要的是软件的需求文档-Requirements Document（需求文档） or 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（探索性测试）。
他的定义是：simultaneously learning the software, designing tests, and executing those tests.意思是同时进行对软件的学习，设计测试用例和执行测试用例这3种活动。说句实话我觉得这个瞎测没有什么区别。不过我以前看过这个Exploratory Testing（探索性测试）的资料，是一个讲Rapid Testing的PDF上看到的，我记得对于Exploratory Testing有一个很关键的步骤，就是把在测试活动过程中开发出来的测试用例记录下来，以便以后做回归测试。还有对测试用例进行维护。我觉得这个把测试用例写下来是很重要的，在这种瞎测的过程中，大家的思维肯定是很随机的，或许明天上班我们对同样的软件进行测试就有完全不同的方法，对于有用的正确的方法应该记录下来。

Test-to-Pass and Test to Fail
这个英文里面也叫Positive Testing and Negative Testing.正向测试和反向测试。前者是证明软件是能正常工作的，后者主要是为了证明软件在接受到一些预期不到的输入的时候能够有一个合理的相应。例如我们在计算器里面输入英文字母不会让系统死机。一般来说我们应该先执行Positive Testing然后再执行Negative Testing。不过这里在实际操作中会遇到有一个问题，这两种测试用例都是对同样的测试对象进行测试，如果先执行Positive Testing然后再执行Negative Testing的话就有可能增加了测试的时间，我估计大多数时候这两种测试都是同时进行的吧，呵呵。

Equivalence Partitioning
等价类划分，也叫Equivalence Classing。等价类划分可以在测试质量得到保证的同时大大减少测试用例的数量。等价类的定义是：An equivalence class or equivalence partition is a set of test cases that tests the same thing or reveals the same bug.例如可以把输入分为有效输入和无效输入，在有无效输入里面也可以有好几种细分。总之我觉得想等价类划分是一个不断细化的过程，并不是粗略地分为有效无效就万事大吉了。书中最后说到一个有趣的事情。A final point about equivalence partitioning is that it can be subjective. It's science but it's also art.如果说一样东西即时科学又是艺术，就证明他不是科学的，呵呵……跟个人能力有很大关系啊。

Data Testing
这个我以前真的没听说过，而且网上的资料也比较少，直接翻译应该是数据测试。一种对软件的简单看法就是：软件由两部分组成：The data and the program。Data（数据）的定义。数据可以是键盘的输入，鼠标的点击，磁盘文件，打印输出等等~程序：就是可执行的流，事务，逻辑和计算。

Boundary conditions
边界条件。原文是这样说的:If software can operate on the edge of its capabilities, it will almost certainly operate well under normal conditions.如果我们在悬崖边走过而边缘上的岩石没有塌掉的话，那么我们就可以认为在远离悬崖边的地方走路是很安全的~~边界条件通常会跟等价类划分一起使用。
以下是有可能涉及到边界条件的类型：
数字，字符，位置，数量，速度，区域，大小
我们可以想一下一下的情况：
第一个/最后一个；最大/最小；开始/结束；之上/之下；空的/满的；最慢的/最快的；最大的/最小的；最短的/最长的；最先的/最后的；最高的/最低的。
这里有一个TIPS就是。当我们考虑边界条件的时候，需要考虑以下三种情况。
第一：合法数据范围里面的其中一个取值。
第二：最后一个合法数据（刚好在合法数据集合的边界上的值）取值。
第三：邻近与最后一个合法数据的非法数据数值。举例~~如果一个Text Box允许输入最大的字符数是20个，那么就可以选19，20，21，刚好符合以上条件。（这个举例只针对最大值20哦）

次边界条件(sub-boundary conditions)
或者叫内部边界条件(internal boundary conditions)。这部分内容要求测试人员要对计算机和软件怎么运行，有一个基本的了解。这些次边界通常会来自于：ASCII码所引起的问题，因为ASCII码并不是一个连续的编码，大家可以发现大写字母和小写字母在ASCII码里面并不是连续的，这里面有可能出现问题，再有就是一些单位，例如Byte，word等等。

状态测试(State Testing)
一个软件的状态的定义是：软件在某一时刻所处于的一种状态或者模式。作为一个测试员，我们必须对程序的状态和事务的转换进行测试。测试一个软件的逻辑流程应该首先画出一个状态转换图。这个状态转换图应该包括三个方面。
1.软件的每一个可能的状态。
2.触发软件的状态转换的输入和条件。
3.进入和退出某种状态的条件设置及其产生的输出。
由于状态的转换路径也是一个不可能全部测试的集合，所以需要对这个集合进行瘦身。有5种方法可以做到。
1.每个状态至少访问一次
2.测试那些看起来是很普遍或者是很常用的状态转换
3.对那些最不常用的状态切换进行测试
4.测试所有的错误状态和从错误状态切换回来的状态
5.测试随机的事务

Testing States to Fail
反向状态测试。竞争条件(Race conditions)是需要包括的。这个很多地方都讲了，我省一点字，呵呵。
Repetition Testing（重复测试）就是不断执行同样的操作。最简单的是不停地启动、关闭程序。这个测试有可能可以发现内存泄露，不过像这样子的测试当然最好是留给自动化工具去完成啦~呵呵。
Stress Testing（压力测试）书上的定义是把软件置于比理想状态要差的条件中运行。也有点像是边界条件，这里的边界就是软件的运行平台条件。
Load Testing（负载测试）跟压力测试相反，我们需要做的是让软件满负荷地运作
这里关于压力测试和负载测试的定义我自己也不太确定书上说的是不是真的完全正确，因为类似的定义在网上论坛也不是一个很明确的定义，以后查资料补上吧：）

其他黑盒测试技术
其中有一条是：像一个傻瓜一样去使用软件。的确，软件到了用户的手里以后，没有人可以预计用户会如何使用这些软件~还有就是在已经发现BUG的模块上继续努力~呵呵，物以类聚嘛：）再有就是像一个黑客那样思考，这个对测试员的要求比较高哦，最后一条就是！哈哈~根据自己的经验，直觉，感觉……大家跟着感觉走囖。

终于写完了，我觉得这个我越写就越教科书……唉 ：（

好东西  谢谢楼主分享  
支持
收藏了

加油!sdlkfj2 sdlkfj2

强！！

顶xia！呵呵！sdlkfj3

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)找出问题。核心我觉得就是一句话，对事不对人。发现了代码或者文档的问题，就只能就这些问题进行批评，而不是去找到谁干的，然后对他劈头盖脸的训斥一顿。（不过如果有人老犯错那么真的很难做到对事不对人啊~呵呵）
2.(Follow Rules)一切按照规矩走~。无规矩何以成方圆，在审查进行前需要制定一系列规矩并且遵循这些规矩来进行。包括审查数量的多少啊~时间~内容等等。要不然很容易成了吵架大会。
3.(Prepare)事前做好准备。经常看到有人写“那些有充分准备的人才能抓住机会”（我总蹲在A点怎么样也能阴死几个人吧哈哈~）。以前有一次做Peer Review，老大问我们看文档了没有，我们异口同声说没有，结果就是中午花一个多小时看完那个文档~看完了才开始Review的：）！因为很多时候，发现问题是在我们准备这个Review的时候，也就是看文档或者代码的时候。不要期望一个脑子一片空白的人进入会议室能对大家带来什么帮助。
4.(Write a Report)。做会议记录。会上发现了27个bug，很好，大家都很开心，除了那个做文档（代码）的可怜的娃~大家有说有笑地离开了会场回到了座位继续MSN~那可怜的娃脑子早都蒙了谁还记得那27个bug具体在哪里啊，可能1分钟后会是26个bug了~所以做会议记录是很重要的~记下来都发现了什么，问题集中在哪些地方发生。

另外，除了能发现一些系统的问题，正式审查还有以下“副作用”：
1.更好的沟通~大家坐到一起讨论，新人能够从经验丰富的高手那里学到不少本领~测试员能了解软件的内部结构等等……
2.更好的质量：书上说如果一个人知道自己的代码要被被人看，那么他肯定会更加用心去做。也是，如果在会上发现低级错误那多么丢人啊~~
3.团队和谐，现在这个社会什么都讲和谐，今天你和谐了没有？？如果评审进行的好能促进沟通，彼此尊重信任（其实这个我觉得基本不太可能吧？呵呵！难！）
4.解决方案，有时候换个角度看问题可能会发现新的解决问题的方法哦！

A.(Peer Reviews) - 同行评审。也叫(Buddy Reviews)。
同行评审是正式审查里面最随便的一种。不过需要注意的是进行同行评审要时刻注意以上正规评审的4大要素。一个都不能少啊！

B.(Walkthroughs) - 走查。
走查比同行评审更加正规。在走查的过程中通常有代码的作者来给与会的人讲解自己那份代码是干啥的，为啥那样写。在走查的过程中最好是一个有个高级工程师在场~这个没玩过，不了解~

C.(Inspections) - 审核。
审核是最正规的的审查形式。对与会者的要求比较高，而且最好是有经验的，培训过的。审核与前两者的不同在于--讲解或者阅读代码的人并不是那份代码的原作者。也是没玩过~不清楚细节~ 唉……：（
记得当初我们的测试经理来的第一天，美国来的Trainer就问过他这个问题，当时我也没听出个所以然，就记得Pat说“Yes, You'er right.”……呵呵~现在我也知道这三者有什么区别了~

编码标准(Standards)和规范(Guidelines)
标准(Standards)是已经确定的，固定的，必须遵循的规则。规范(Guidelines)是建议的最佳实践，推荐的，首选的方式。标准是必须要遵守的，而规范可以有一定的灵活性~。我觉得跟法律和道德的关系有点相似哦~
很奇怪，既然软件都能run起来了那为啥还说有bug！没天理啊~~不过，其实是有理由的~
1.Reliability（可靠性）。
2.Readability/Maintainability（可读性和可维护性）一个C语言函数我就写在一行上光用分号分开我看你怎么维护，娃哈哈！
3.Portability（可移植性）
最后还有好几页讲的是Code Review Checklist。由于List太长而且我又没什么经验，还是留着慢慢琢磨吧~我觉得这个list对于程序员来说价值也很大~：）

[ 本帖最后由 maguschen 于 2007-9-13 11:23 编辑 ]

大家不要光顶不说话啊~~
给点意见嘛！！！

这个星期事情比较多，所以现在才到第七章~挺慢的~第七章：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)了。呵呵~~

动态白盒测试和调试(Debugging)的区别
可以抓住一个要点，他们的目的分别是什么。白盒测试是一种测试手段，测试的目的是为了找到bug，所以白盒测试的目的是找bug。而Debug的目的是什么？是修复bug。之所会让人分不清，是因为他们有一些重叠。就是在分离并确定(Isolating)发生bug的原因。

单元测试(Unit Testing)和集成测试(Integration Testing)
单元测试通常是由程序员来执行的，集成测试也是。不过有些公司是Tester来完成集成测试的，我比较怀疑这个是否应该由Tester来完成~对于集成测试通常有3种。
1.大爆炸形式。就是一次把所有东西搞到一次然后测，虽然都觉得这个模式比较扯淡，但是实际上很多公司都是这样的方式来工作，呵呵~
2.Bottom-up（自底向上）。就是现在有了底层的模块，然后需要一步一步做集成测试，通常会让测试的人员编写驱动模块(Test Drives)。驱动模块能模拟上层模块对下层模块的调用，从而实现了测试的目的。
3.Top-Down（自上向下）。就是有了上层的模块然后需要编写桩模块(Stub)来模拟对底层的调用。
其实后面的两种方法就跟单元测试里面用的一种技术(mock)是很相似的。都是模拟一个东西出来，不需要实现内部的功能，只需要把接口定义好，然后设计一些输入输出就好了。

一个软件，其实是由数据+程序实现。所以也就有以下两种覆盖。

数据覆盖(Data Coverage)
1.数据流(Data Flow) - 对于黑盒测试，我们只知道输入数据和输出数据，我们对这一对数据的中间处理是一无所知的，但是在运用白盒测试的技术以后，我们可以对中间的变量转换还有变化会有一个清晰的了解。正是基于对这些的了解，所以我们可以修改或者增加一些Test Case来对那些风险比较高的地方进行充分的测试，不要忽略了白盒测试的优势--对内部的了解。
2.次边界值(Sub-Boundaries)
3.公式(Formulars)和等式(Equations)-这里面可以考虑到如果一些公式里面用到除法，那么就应该考虑一下这个如果除数是0的时候程序有没有正确处理。
4.强制错误(Error Forcing)-这个就是刚开始说的需要强制的把一些flag改未错误的标记然后看看结果是否正确。不过这里需要知道做的要合适才行。就例如说前面一个例子，一个除数是N，而且N不是直接用户输入而且结果一些计算得出最后给赋值的，我们可以考虑N=0的时候有没有错。但是如果我们通过这个“强制错误”的方法，把N赋值为0，然后报错，这样子是不合理的。因为在生成N的时候有可能已经是经过检验的不可能出现N=0的情况，如果我们硬要把N赋值为0那么其实这不是一个有效的测试用例。

代码覆盖(Code Coverage)
通常做代码覆盖都需要用工具作为辅助~通过软件的帮助我们可以得到以下的信息：
1.软件的哪些部分我们没有覆盖到，我们需要补充更多的case来覆盖他
2.那些测试用例是冗余的，我们可以把那些冗余的case用等价类来减少case的数量
3.对于覆盖率不高的模块可以增加case来覆盖

语句覆盖(Statement Coverage)行覆盖(Line Coverage)
这个是代码覆盖里面最简单的覆盖，而且要做到100%的语句覆盖是比较容易的，不过意义不大，以为即使做到100%覆盖，还是没法很好的检查软件，因为大部分的错误都是逻辑错误。

分支覆盖(Branch Coverage)判定覆盖(Decision Coverage)
似的程序中的每个判断至少取真分支和假分支一次。做到100%的判定覆盖是有可能的。不过对于符合条件（就是出现 IF A AND B AND C）分支覆盖会在其中一个组合中被测试到。这是分支覆盖的一些弱点。

条件覆盖(Condition Coverage)
条件覆盖要求是每个判断中的每个条件的可能只至少满足一次。例如(IF A AND B)那么需要有1) A=TRUE,B=FALSE，2)A=FALSE,B=TRUE。这样就完成了，这2个测试用例达到了条件覆盖的要求但是可以看看，没有达到分支覆盖。

这章完了~呵呵，书上介绍的很简单。其实我在看其他的一些书的时候对于这个代码覆盖就介绍了好多方法，看来还是要好好补补啊，不过没有机会让我做白盒，我补这个也是瞎补啊~~

[ 本帖最后由 maguschen 于 2007-9-8 21:46 编辑 ]

很快又看到了第八章，呵呵~说到配置测试，估计很多公司都没有时间或者精力去做，不过作为我自己的笔记，还是要照本宣科地记下来的~
配置测试(Configuration Testing)是一个检查我们的软件在不同的硬件环境下能否正常地工作的过程。这当中牵涉到几样东西，电脑本身，电脑配件，外设，接口，选项，存储器和驱动。不同的软件会有不同的针对点，例如对于一个游戏软件，例如QUAKE IV，它最应该关心的是显卡和声卡的测试，一个图像处理软件有可能关注于显示配置和打印机的测试。
怎样准确分离出配置错误(Isolating configuration bugs)。一个简单的方法就是，如果在测试的过程中遇到了bug，在其他一些不同配置的机器上运行同样的操作，看问题是否能重现，从而达到分离出引起这个bug的最根本的原因。
那么遇到了问题应该又谁来负责修复呢，是软件公司呢还是硬件厂商？一个配置错误通常会有一下四种表现形式：
1.软件在一系列的硬件配置条件下都出现错误，例如连上激光打印机就挂了。
2.软件在一个特定的型号的硬件下出现错误，例如只是连接上Magus牌扫描仪才挂！
3.软件只受到某个硬件或者是硬件的驱动程序所影响而出现错误。
4.硬件或者它的驱动程序本身是有问题的，也影响了其他的一些软件，不过我们测试的软件在当前硬件配置下受到的影响特别大。
对于前两种情况，毫无疑问需要软件厂商来修复。如果后面两种情况的话比较复杂，因为责任在谁身上就决定了谁要付出额外的钱来修复问题啊。软件厂商可以联系硬件生产商，一起解决问题，有时候某些软件的光盘上会带有一些硬件的补丁，这个估计就是配置测试发现问题，所以加入其他补丁。

现在市面上有成千上万的硬件，他们之间的组合是数以亿计的，是不可能都测试一次的。而且有时候某些配置平台还有可能测试N次，所以需要做一些工作来减少我们测试的工作量。
1.决定哪些功能是软件需要用到的，例如一个word程序可能对显卡要求是很低的，没有必要去测试太多。又或者一个3D游戏根本没有打印功能，那么就不需要管打印机了。
2.看看要对哪些牌子，型号，具体那些驱动程序的硬件是可用的。这里一般都会选用市场上比较流行的软件，就例如在现在就没有必要去测试ISA显卡了吧！？
3.看看哪些硬件特性，模式和选项是可用的。
4.在已有的测试集合里面挑选出一个可维护可管理的测试集，还是挑出表常见的硬件。
5.分离出软件特有功能，这个功能对配置是要非常敏感的。例如一个打印文本的程序，就多打几种不同的字体等等。
6.设计好在不同配置下运行的测试用例
7.在每个配置环境下执行测试用例
8.重新运行测试用例直到团队觉得ok

取得硬件的途径
1.买那些常见的硬件，一个测试团队里面最好每个人的配置都是不同的~我用酷睿其他人用赛扬吧~
2.联系一下硬件厂商看能不能免费给我们用~
3.给公司的同事发邮件，让他们从家里带过来~
4.外包给专门做配置测试的公司

兼容性测试(Compatibility Testing)。简单来说就是公司的软件要跟自己兄弟产品还有别的产品能和平地在系统上正常运作。下面有一些例子：
1.在网页上剪切一些内容，然后粘贴到文字处理软件里面
2.把一些资料用A工作表软件打开，然后保存以后，在B工作部软件里面打开
3.一个图像处理软件运行在不同版本的操作系统上
在兼容性测试里面需要注意的一些事项：
1.你的软件是被设计到工作在哪些平台上的，需要跟哪些软件进行交互。
2.公司是按照哪些标准和指引来工作的。
3.你的软件用什么类型的数据跟别人软件进行交互。
向后兼容(Backward Compatible)和向前兼容(Forward Compatible)
如果一个TXT文件是在WIN98下创建的，能被WIN32打开，那么就是向后兼容。能在XP下打开就是向前兼容。
跟配置测试相似的是，兼容测试同样遇到了测试集过大的问题，所以需要挑选出一个合理的测试集进行测试。这里面需要考虑到测试平台和软件的流行程度，版本，类型等……
标准和指引
高层标准与指引，这个通常指的是软件的外观还有一些功能。例如WIN XP认证。
底层标准与指引，这个指的是软件底层的东西，包括文件的格式，还有通信协议

好多啊 顶一个 正在看那本书呢

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

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

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

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

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

1.文本扩展(text expansion)。有可能英文版的软件里面只有2个单词，但是翻译到阿拉伯或者中文的时候就需要7~8个字符，那么就有可能出现这个所谓的文本扩展，一个常见的现象就是一个按钮放不下那么多的字，那么后面的一串文字就被砍掉了。不过这种UI上的问题还算好了，还有更严重的就是由于程序没有分配足够的内存来保存那些文字，有可能导致系统崩溃。

2.ASCII, DBCS and Unicode
这个基本没接触过，不懂啊~呵呵。不过现在很多软件都支持Unicode，就单单Unicode本身就有好几种不同的版本，这个我觉得其实数据软件的I18N范畴。

3.热键和快捷方式(Hot Keys and Shortcuts)
书中举了一个例子，法语和英语的“搜索”。法语是R开头，英语是S开头，可能会有一些问题。不过我觉得这些快捷方式应该是不变的吧。反正用中文版的时候基本没有感觉，也可能是中文的意思根本不在考虑范畴当中，呵呵，就跟着英文走了。不过可能在其他语言里面，快捷方式是会变的。我记得我用德语XP的时候好像右键点桌面，然后按"E"就没有反应。按理来说在英文或者中文XP下，应该是刷新一下桌面。

4.扩展字符(Extended Characters)
就是测试的时候要看到一些特殊的字符，例如重音字符ä，还有特殊的符号例如♡。

5.字符的计算(Computations on Characters)
在ASCII码里面，大写字母+32就等于小写字母了。不过对于其他的希腊文字语言，却不是这样子的，如果程序里面只是+32来转换的话，多半会出现问题。

6.从左到右和从右到左的阅读
这个问题幸亏操作系统已经做好了，我们也不必费神了，测试一下就好了。

7.图形里面的问题(Text in Graphics)
书中举例就是我们最常见的3个图标，加粗(B)、斜体(I)和下划线(U)。有些语言里面加粗就不是B开头的，那么这个图标就显得没有意义了？迷惑ing……

8.文字和代码分离
这个估计大家都在做的，一句话就是避免Hard-code。然后还有一个就是语序的问题，虽然说已经把该显示的文字从程序里面分离出来了，不过还是要注意一些语序。

本地化的问题

1.文字内容。一个典型的例子就是在美国Football和Soccer就不是一个东西~还有当地的文化，例如中国人对龙是有崇拜的，那么一个中国本地化的软件最好不要在龙上面做什么手脚，毕竟文化有差异。

2.数据格式。这个就是说一些货币，电话号码，日历，时间，日期等等……

配置和兼容的问题

1.外文平台的配置
这个光XP就提供了106种语言，但是光英语就有好多不同的国家，英国美国新西兰澳洲加拿大等……西班牙语也是如此……这里我遇到过的一个问题就是在日本操作系统里面是没有"\"反斜杠的，他们都是用日圆符号¥来代替，我刚开始就纳闷我考日本人没那么贪财吧，服务器地地址什么都要用到反斜杠的啊，在英文版XP下拷贝过去也不行。后来才发现其实日本操作系统的¥就相当于英文版里面的"\"。只是看起来不同而已，用的都一样，真恶心啊！！！

2.数据兼容
书上画了一个错综复杂的图，反正就是在A平台下保存，然后在B平台上打开，然后放在C平台的U盘上然后运行之类，一句话：折腾！呵呵~

测多少才算够啊？
这个问题需要用风险的分析来决定囖~例如日语版本的市场很大，那么就不敢马虎了。

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里面就是相反的：）

Intuitive - 直观。什么是直观，如果你看到的这些文字他不是文字，而是0100010010101001010，你吐血不？不过这只是一个极端的例子。一个好的UI就是让用软件的人根本就感觉不到UI的存在~UI要求是简洁的而且布局是合理的，没有不必要的功能的。这里我觉得还是去看看竞争对手的产品，就知道我们需要有什么改进了：）

Consistent - 一致性。例如一个软件把复制的快捷键定义为CTRL+X，剪切的快捷键是CTRL+V……那么估计用户鼻子都气歪了吧。创造性是好的，不过有些时候还是循规蹈矩比较好。

Flexible - 灵活。就好像计算器的例子，WINDOWS的计算器有2种模式，可以给用户选择，不过这种灵活性是有代价的，就是投入更加多的人力物力。

Comfortable - 舒适。通俗点说就是这个软件用的爽不爽。正所谓人要有人样，一个财务软件不应该出现很多卡通的配图吧~然后就是错误处理，软件很难避免错误，这时候需要处理这些错误，那么就需要好好处理这些错误提示哦。然后就是性能，慢成马的软件谁用啊。

Correct - 正确性。保证软件里面的内容，功能是没有错误的。例如不要有拼写错误。还有是否有一些功能，是我们的软件产品所没有但是却又是在这个市场是有需求的呢？（这个要求有点高了吧？）

Useful - 可用性。一个软件是不是有用通常都是由客户说了算，不过这里存在一个问题，是不是某些功能对于我们的软件来说是没有用的呢？这个我觉得也是很难做到测试，这些通常都是产品经理负责。

另一个大的主题就是 - Accessibility Testing 易访问性。这个通常都是针对残疾人的。当中有几个，例如视力上有缺陷的人，听觉有阻碍的人，行动不便的人等……然后我发现，对于这些，在美国是有法律来保障残疾人的权益的，看来还是人家的法律够健全啊！

!!! 现在我要加油了！！！你比我有恒心多了！！！
你干吗要跟干同一种职业？！
真想不通！！！
我以后天天读你读书笔记向你学习！！！