51Testing软件测试论坛
标题: Ron Patton软件测试读书笔记连载 [打印本页]
作者: maguschen 时间: 2007-8-11 12:56
标题: Ron Patton软件测试读书笔记连载
说是连载不过还不知道能不能写下去，不过现在写了三章了就先贴上来吧~
我读的是英文版的《软件测试》所以有些观点或者定义或者名词有可能不是完全理解正确的，所以如果大家看到什么错漏赶紧告诉我哦。嘿嘿，其实这个也是我贴上来的目的，让大家过目一下，帮我提高~~谢谢大家了~还有的就是我并不是按照章节顺序下来的，有可能省掉一些内容，如果没看到的就是省掉了，省掉了并不是说不重要，而是我觉得可能那些知识点在其他地方有更加详细的介绍，或者说我自己觉得自己已经掌握了就没有花时间记下来~大家原谅我的懒惰吧！~~
还有的就是这个读书笔记其实是以博客的形式出现的，所以用语比较随便不正规，大家看了就取其精华去其糟粕就是了，再次原谅一下我……sdlkfj1
希望大家多提宝贵意见，共同提高！！！
《Software Testing》Second Edition, Ron Patton.为了方便~下文就称之为STSE。
Software Testing里面一个比较有趣的问题就是，应该怎么称呼这个BUG呢（貌似我已经给下了定义-__-b）。这个更加专业点吧，就是Software Failure有什么称呼！？其实有以下列举的词~包括但不仅限于哦~
·
Defect（REYREY以前就用这个，感觉还挺好~）
·
Fault（过错、毛病之类，听起来比上面的严重）
·
Incident（事件~这个词看着很温和，没那么激进）
·
Variance（不一致，这个也很“客观”啊）
·
Failure（失灵~故障，听起来也是很吓人的）
·
Inconsistency（矛盾！个人认为比较客观的说法）
·
Feature（特征，功能……这个……我汗啊）
每个公司都有自己的一个叫法，之所以有那么多叫法根据猪蹄说的原因就是~要估计程序员的感受，不要搞的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~
作者: maguschen 时间: 2007-8-11 12:56
有了上面的定义现在可以讨论一个问题~如果现在有这样的一个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.
呵呵，就是快恨准~
作者: maguschen 时间: 2007-8-11 12:57
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
我自己通俗理解就是~软件测试不是随随便便就能干的，是个有前途的职业~呵呵！
作者: maguschen 时间: 2007-8-11 12:58
然后就是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不分~呵呵
作者: maguschen 时间: 2007-8-11 22:26
哈哈~晚上又读了一章，其实也就是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 编辑 ]
作者: mojuncong 时间: 2007-8-12 11:21
很好,继续,正好我也在看这书的英文版!
作者: maguschen 时间: 2007-8-13 22:45
这章标题是：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的模块上继续努力~呵呵，物以类聚嘛：）再有就是像一个黑客那样思考，这个对测试员的要求比较高哦，最后一条就是！哈哈~根据自己的经验，直觉，感觉……大家跟着感觉走囖。
终于写完了，我觉得这个我越写就越教科书……唉 ：（
作者: 119139107 时间: 2007-8-14 09:14
好东西 谢谢楼主分享
支持
收藏了
作者: jiuquanzi 时间: 2007-8-14 11:36
加油!sdlkfj2 sdlkfj2
作者: changlang530 时间: 2007-8-14 11:44
强！！
作者: jaunty 时间: 2007-8-15 17:44
顶xia！呵呵！sdlkfj3
作者: maguschen 时间: 2007-8-15 22:09
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 编辑 ]
作者: maguschen 时间: 2007-8-15 22:10
大家不要光顶不说话啊~~
给点意见嘛！！！
作者: maguschen 时间: 2007-8-19 22:57
这个星期事情比较多，所以现在才到第七章~挺慢的~第七章：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 编辑 ]
作者: maguschen 时间: 2007-8-21 22:37
很快又看到了第八章，呵呵~说到配置测试，估计很多公司都没有时间或者精力去做，不过作为我自己的笔记，还是要照本宣科地记下来的~
配置测试(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.外包给专门做配置测试的公司
作者: maguschen 时间: 2007-8-21 22:38
兼容性测试(Compatibility Testing)。简单来说就是公司的软件要跟自己兄弟产品还有别的产品能和平地在系统上正常运作。下面有一些例子：
1.在网页上剪切一些内容，然后粘贴到文字处理软件里面
2.把一些资料用A工作表软件打开，然后保存以后，在B工作部软件里面打开
3.一个图像处理软件运行在不同版本的操作系统上
在兼容性测试里面需要注意的一些事项：
1.你的软件是被设计到工作在哪些平台上的，需要跟哪些软件进行交互。
2.公司是按照哪些标准和指引来工作的。
3.你的软件用什么类型的数据跟别人软件进行交互。
向后兼容(Backward Compatible)和向前兼容(Forward Compatible)
如果一个TXT文件是在WIN98下创建的，能被WIN32打开，那么就是向后兼容。能在XP下打开就是向前兼容。
跟配置测试相似的是，兼容测试同样遇到了测试集过大的问题，所以需要挑选出一个合理的测试集进行测试。这里面需要考虑到测试平台和软件的流行程度，版本，类型等……
标准和指引
高层标准与指引，这个通常指的是软件的外观还有一些功能。例如WIN XP认证。
底层标准与指引，这个指的是软件底层的东西，包括文件的格式，还有通信协议
作者: 海角之南 时间: 2007-8-22 10:22
好多啊 顶一个 正在看那本书呢
作者: maguschen 时间: 2007-8-26 11:31
这章叫外国语言测试，刚开始我以为是讲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盘上然后运行之类，一句话：折腾！呵呵~
测多少才算够啊？
这个问题需要用风险的分析来决定囖~例如日语版本的市场很大，那么就不敢马虎了。
作者: maguschen 时间: 2007-8-28 21:36
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 易访问性。这个通常都是针对残疾人的。当中有几个，例如视力上有缺陷的人，听觉有阻碍的人，行动不便的人等……然后我发现，对于这些，在美国是有法律来保障残疾人的权益的，看来还是人家的法律够健全啊！
作者: jaunty 时间: 2007-8-29 18:11
!!! 现在我要加油了！！！你比我有恒心多了！！！
你干吗要跟干同一种职业？！
真想不通！！！
我以后天天读你读书笔记向你学习！！！
作者: maguschen 时间: 2007-8-29 22:28
文档测试，其实可能在国内真的不太现实。国内的公司总体来说不太正规，能把那个软件测试完都不错，这个文档嘛……通常都是后来才补上去。然后如果在国内的外企的话，通常也接触不了高层的文档，看看是可以的，不过至于说道参与修订或者评审，基本很难。还是期待国内正规公司数量的增长啊！感叹完了……
软件文档的种类。说起文档，我最初认为就是一个readme。后来发现有需求文档，设计文档，帮助文档，但是……其实文档的种类是有很多的，书上列举了一些，有可能公司只有其中的某几种~也是正常的
Packaging text and graphics - (包装文字和图片)。呵呵，这个厉害吧，可能现在很多软件都不是用CD或者DVD来作为载体来发布了，不过包装，就是属于软件文档的一种哦！
Marketing material, ads, and other inserts - (市场资料，广告和其他相关插页)。这个是关乎公司的宣传效果还有能卖出多少产品的哦，不过我觉得这方面通常有专门的独立部门去处理，设置外包到专业的广告公司，所以这方面嘛~还是不要越俎代庖。一些建议是要的，不过专职去做，好像不太合适。其实上一种也是的。
Warranty/registration - (保修单和注册)。这些通常是客户填好了然后邮寄回去，现在估计基本上都是在线注册的吧。保证这个注册表上没有错误是很有必要的。
EULA (End User License Agreement) - 最终用户许可协议。这个EULA其实经常看到，就是不知道代表啥，今天我终于知道了，呵呵！这个肯定需要认真检查，因为很有可能涉及到一些法律上的责任什么的。不过我觉得QA只能做个拼写错误检查，语法检查，那些法律条文内容还是由专家来办吧：）忘记了，这个发音叫“you-la”。GUI的发音叫“GU-YI”
Labels and stickers - (标签和贴标)。这些会在软件的外包装上经常看到~
Installation and setup instructions - (安装与设置指南)。虽然说一般的软件都是傻瓜式的Next Next Next就完了，不过对于一些复杂的软件，一个安装指南100多页也不足为奇，例如QUALITY CENTER。好的指南能让用户很容易上手。
User's Manual - (用户手册)。这个东西其实比较重要。不过要检查的内容特别多，据说公司有人要把HELP里面的所有链接点一次~呵呵，这个还是看看能不能自动化啊。
Online help - (在线帮助)。这个现在流行，看OFFICE系列软件就知道了。一方面可以减小客户端的体积，另一方面可以随时更新，多好啊。不过测试这个就跟测试一个WEB系统差不多了。
Tutorials, wizards and CBT(Computer based Training) - 指南，向导和培训。这个有点类似于用户手册和在线帮助，但是多了一些与用户交互的过程。
Samples, examples, and templates - (样品，例子和模板)。我们要包装软件提供的例子模板之类的东西不能有错误。因为这些东西常常被帮助文件那块所调用。
Error messages - (错误信息)。这个是不是有点似曾相识？这里指的错误信息是“错误信息”本身的内容，并不是说错误信息什么时候该弹出来。
说了那么久，那么文档测试究竟有没有用？答案当然是有用啦~
1.改善可用性。因为有了完善的文档，自然能提高软件的可用性。
2.提高可靠性。如果一个描述有误的文档，用户照着上面的步骤一步一步执行，出来的结果是“错的”。那么这就是不可靠的表现，不是软件本市不可靠，是帮助文件不可靠。但是帮助文件其实是整个软件的一部份。
3.减少售后支持的开销。前面就说过如果一个bug在开发期间发现并且修复，代价是远远小于到了用户那里发现修复的。想一想，就电话费都不少啊！
文本测试的一些本质。
1.文档测试通常都是不被重视的。怎么办？没啥办法，只能提出来，不过估计到最后还是要屈服。
2.写帮助文档的人有可能对软件不熟悉。这个还好，首先就是跟写文档的人多沟通，然后就是保证他们拿到的其他相关文档不是过时的，不要说最新版本上去掉了一大块功能，不过帮助文档上还有。
3.做这方面的工作太费时间了。么办法啊~
作者: maguschen 时间: 2007-8-30 23:06
辛辛苦苦写了大半……浏览器一崩溃，啥都没有……吐血！！辛苦奋斗二十年，一朝回到解放前！
黑客的动机！
1.Challenge/Prestige - (挑战性和威望)通常在一个社区里面有某些高手进入了某些号称安全性很高的系统里面，对于那个人的威望的树立是很有帮助的。而且这也是意见很有挑战性的事情。
2.Curiosity - (好奇)人就是这样子，你不让我看我非要看！
3.Use/Leverage - (使用和利用)利用电脑传播病毒，或者干其他坏事。
4.Vandalize - (破坏)随便删除别人的资料，或者利用肉鸡攻击其他系统。
5.Steal - (盗窃)偷取一些重要的资料，例如商业资料，客户资料~
威胁模型
1.建立团队，而且团对里面需要有一名资深的安全专家。在这个阶段主要集中在识别威胁，不是如果去解决威胁。
2.识别出有用的部分。就是那些对于黑客来说是有利用价值的部分。例如存放客户信用卡的地方~
3.建立一个概要的架构，并且识别出不同的技术，认证授权方式之间的信任边界。
4.分解程序组件，看那些组件容易被攻击，或者很有可能受到攻击
5.识别出威胁。
6.记录威胁。
7.对威胁进行评级 DREAD
A.Damage Potential - (潜在破坏)。威胁的潜在破坏，例如对硬件，财务上的破坏
B.Reproducibility - (重现能力)。这个威胁是每次都能出现呢，还是只是尝试1w次才出现一次
C.Exploitability - (可开发性)。可以危险是不是很容易就被利用了，还是需要高深的编程技巧
D.Affected Users - (受影响用户)
E.Discoverability - (容易发现性)这个威胁是不是很容易被发现，还是只有内部人员泄露才会被发现
作者: maguschen 时间: 2007-9-2 16:59
这个Web系统测试可以出一本不厚不薄的书，而且现在就是有卖的，作者什么都忘记了，就是记得已经出到第二版了。呵呵……所以这个STSE就是带我到门口而已。不过他的编排挺巧妙的，这章讲web系统的测试，中间引出一些困难，然后下面就是自动化测试了。
Web Page Fundamentals(网页基本原理) - 网页包含的元素还是网页的一些特征，相对于传统的光盘媒质，网页元素有其特别的元素和不同。我高中的时候就尝试做网页，然后也做过一些玩，因为那时候很多免费的空间。不过正如书上说的一句很精妙的话：不要以为给你一只画笔你就成艺术大师了。最后我的网页还是不了了之。很多网页都有但是不局限于以下的基本元素：
1.大小各异色彩缤纷N多不同字体的文字。
2.图像和相片
3.文字和图像超链接
4.广告
5.下来菜单
6.可以添文字的表单
还有就是一些高级的动态功能：
1.可以让用户随意改变显示位置的功能(自定义布局 - Customizable layout)
2.用户可以选择其感兴趣的新闻(自定义内容 - Customizable content)
3.动态下拉菜单
4.动态替换的文字
5.根据分辨率而变化的动态布局和可选内容
6.对不同浏览器，不同的版本，不同的硬件和软件平台的兼容
7.许多增强可用性的隐藏的格式，标签和内嵌信息
黑盒测试在Web测试中的应用
文字 - (Text)：
1.对网页的测试有时候很想是对文本的测试，需要根据用户的水平，相关术语，内容，还有拼写错误，还有一个就是要看看那些信息是否已经是过时的。在这里要注意的是，不要依靠拼写检查器，因为他不能检查图片的文字还有表带等……
2.对于一些特别有用的信息，例如Email，地址，邮编，电话等……需要加倍留意。最与每个网页的标题也要认真细看。
3.还有一个很容易被忽略的地方就是ALT信息，就是我们把鼠标移动到一个图标上的弹出提示。
4.还有就是用不同的分辨率看看文字有没有变化。因为这里有可能出现一种问题就是，可能一段文字在特定的分辨率下显示是好的，换个分辨率就变得支离破碎了。
超链接 - (Hyperlinks)
1.看是否那些超链接都是正确的。会不会一个“注册”的超链接，最后就链接到了退出页面了。
2.如果是一个在线发EMAIL的窗口，那么就写个EMAIL看他能不能发信出去并且收信人是收到的。
3.注意检查，防止出现孤立的页面(orphan pages)。有可能这个页面没有出口或者没有入口或者两者都没有。
图像 - (Graphics)
1.看图像有没有被正常的load出来
2.如果图像和文字是弄到一起的，注意看那些在图像周围的文字有没有很好的换行，有没有文字被那个图像遮住了。
表单 - (Forms)
1.看表单的布局有没有问题，是不是有些文本框没有跟说明的文字对齐
2.文本框能否正确输入内容，例如一个要填入邮编号码的文本框里面看能否输入数字
3.看看是不是所有字段都是必填的。如果有某些是必填的话，看看他们是否真的有效
其他杂项 - (Miscellaneous)
1.如果有计数器，那么需要对之进行测试
2.如果是有搜索功能，要把这个站内搜索和搜索引擎的搜索分辨清楚
灰盒测试(Gray-Box Testing)在Web测试中的应用
灰盒测试就是用黑盒的方法，就是不管里面是怎么弄的，反正我只看功能，然后有结合白盒测试的技术，站在一个比较高的角度看这个软件是如何运作的。书中说一个网页比较适合灰盒测试，因为HTML本身不是一种编程语言，只是一种标记语言，比较容易理解。一般来说灰盒测试会在集成测试的执行过程中用到，多数由程序员来执行啦~
白盒测试在网页在Web测试中的应用
现在这个年头，已经没有人用静态网页了，有也是通过一些编程语言来动态生成的吧。白盒测试主要对以下进行测试：
1.动态内容 - (Dynamic Content)
2.基于数据库内容的页面 - (Database-Driven Web Pages)
3.程序生成的页面 - (Programmatically Created Web Pages)
4.服务器性能和负载 - (Server Performance and Loading)
5.安全性 - (Security)
配置测试和兼容性测试 - (Configuration and Compatibility Testing)
配置测试是一个检查你的软件在不同软硬件平台上以及不同的配置下能否正常工作的过程
兼容性测试是一个检查你的软件跟其他软件能否和平共处的过程
一些需要注意的东西：
1.硬件平台- (Hardware Platform)
2.浏览器软件及其版本 - (Browser Software and Version)
3.浏览器插件 - (Browser Plug-Ins)
4.浏览器选项 - (Browser Options)
5.分辨率和色深 - (Video Resolution and Color Depth)
6.文字大小 - (Text Size)
7.网速 - (Modem Speeds)
可用性测试在Web测试中的应用
可用性测试估计是提的比较多的吧。我记得以前看过一本书叫《Don't let me think》。里面就是讲述了一些提高可用性的方法还有设计原则之类的。《软件测试》这本书提到了10个最容易犯错点：
1.Gratuitous Use of Bleeding-Edge Technology - 滥用先进技术，其实做IT这个大家都知道技术更新的很快，但是一般商用的软件都不会选择最新版本或者最前沿的技术，就好像JAVA都出到1.6了但是很多开发团队还是在用1.4。稳定压倒一切啊。
2.Scrolling Text, Marquees, and Constantly Running Animations - 不要搞的整个页面动来动去的，因为用户看的是内容，看的是内容是否有价值，而不是花里胡哨的飘来飘去的文字。
3.Long Scrolling Pages - 一个页面拉啊拉~拉半天都不到底。
4.Non-Standard Link Colors - 前面都说过了，标准是要去跟的，不要随便改动，就好像一般链接是蓝色的那么就蓝色吧，特别大的标题做成红色是合理的，什么不好的事情做成黑的也是合理的，但是如果出现绿色di……那么就好像有点不合理哦。
5.Outdated Information - 过时的内容，这个有可能出现在邮件地址，电话号码的地方。
6.Overly Long Download Times - 过长的下载时间，一般用户的忍耐性都是有限，而且现在SB电信搞什么包月改为240小时，时间就是金钱啊。估计没人喜欢看着浏览器的进度栏干瞪眼。
7.Lack of Navigation Support - 缺乏导航支持。有些页面有进没有出，或者不能方便的返回上层页面。
8.Orphan Pages - 孤立的页面。没法进，万一不幸进了还没法出。
9.Complex Website Addresses (URLs) - 这个要看当时注册了个啥域名了。。。
10.Using Frames - 框架的确受人鄙视，不过不知道为什么哦，Rational ClearQuest就用的Frame。
作者: 86362838 时间: 2007-9-2 18:05
已阅，回个帖子帖支持。
作者: guohenyongheng 时间: 2007-9-2 19:41
标题: 还没有看完
真是太佩服楼主了，呵呵，我现在一口气还没有看完，以后慢慢看，辛苦了，我在这里有礼了！sdlkfj5
作者: xidian 时间: 2007-9-3 00:02
哈哈 很强
作者: maguschen 时间: 2007-9-4 15:36
原帖由 xidian 于 2007-9-3 00:02 发表 
哈哈 很强
xidian。。。。。。。
作者: maguschen 时间: 2007-9-4 15:37
我终于看到自动化测试了，呵呵，不过这章不是我想象中的那样子，可能这本书并不是主要介绍自动化测试的吧。不过也接触了一些新的知识，不错不错。自己做过的东西回头再看就是有感觉啊：）
The Benefits of Automation and Tools - 自动化测试和使用工具的好处
自动化？那要人干啥！呵呵……人不就是用来实现自动化囖。自动化测试有什么好处，面试的时候经常有人问，答案其实没有十分标准的，不过通常都离不开那些老论调。
The principal attributes of tools and automation - 其实是工具的属性。与生俱来的能力
1.Speed - 速度。机子执行的速度是人的N倍，不顾这是要付出代价的，在你教会电脑做事之前，那就是一堆废铁。
2.Efficiency - 高效。当机子在一边跑case的时候你还能设计出新的case。事情真的是这样子的么？估计是在调试脚本吧。
3.Accuracy and Precision - 准确和精确。电脑可以全天工作不休息而且不会出错。人是铁饭是钢，一顿不吃饿得荒。
4.Resource Reduction - 节省资源。这个对于性能测试是最能体现出来的，雇用100个人来胡点还不如人家一台电脑模拟出来的用户牛！
5.Simulation and Emulation - 模拟。电脑可以模拟很多东西，例如变成一台打印机，不是变形金刚，只是一个虚拟的设备。
6.Relentlessness - 电脑可以没日没夜地干活，只要有电！
工具永远都不能替代测试员，它们只是帮助人们更好地完成工作而已。所以说自动化测试并不能替代手工测试。
Test Tools - 测试工具
作为一个测试工程师，我们肯定接触过很多类型的软件，帮助我们更好地完成工作。不同厂商提供针对不停场景下应用的软件，不过这些软件来来去去都是下面要介绍的一些。设置公司里面自己写来帮助测试进行的软件，也必将落入以下的分类，嘿嘿，听起来很神奇~来看看吧。书中特别强调了两种不同风格的工具，non-invasive and invasive。非侵略性的与侵略性的。前者不会修改被测试的软件，只是检视和观察。后者就是指能够对操作环境进行某种方式的修改和对代码进行修改的测试软件。
1.Viewers and Monitors - 观察器与监视器。这些监视器就是能让你看到一些在一般情况下看不到的细节。例如白盒测试里面的代码覆盖率，分支覆盖，条件覆盖等等。这些都是可以在工具的帮助下轻松得到具体的数据的。这类型的软件算是Invasive的。因为需要编译代码链接等等~~在计算机网络里面还有一种经常被使用的工具sniffer - 嗅探器。嗅探器是属于Non-invasive的工具。反正如果有一个软件能够让你看到平常人看不到的信息的话，这个软件就是一个Viewer。
2.Drivers - 驱动器。就是一个控制器，可以控制软件的操作的工具。其实我们平时用的很多自动化测试工具，功能的性能的，都应该算是这一类的，书上举了一个例子，我看的有点迷惑，如图。
把右上角那个电脑的鼠标键盘拆掉，然后用右下角的电脑，给上面那个电脑发送模拟的键盘鼠标信息来进行测试。我刚看这个觉得很扯淡。然后书上立马就有个反问句说大家是不是觉得很扯淡啊。我真的是I cannot agree more啊，扯就一个字！书上给出的解释是：
a.有可能某些软件或者操作系统不支持多任务，所以被测试的系统只能单独运行，不能加上Driver。用这种方法就能避免这个问题。
b.如果从外部系统把操作命令输入进来，那么这个这个测试系统就是非侵略性。如果Driver和被测试的软件都在一个系统运行，那么有可能影响到测试结果。
这个解释听合理的：）呵呵。
3.Stubs - 桩。桩更好跟驱动是相反的。例如现在要测试一个打印程序，如果打印出来的话第一比较麻烦，第二可能会有一些发现不到的细节上的错误。那么桩和仿真器emulator有什么区别呢，他们之间的区别就是桩还能看到不同系统之间发送的信息，而仿真器只能仿真，不具备查看内部数据的功能。
4.Stress and Load Tools - 压力和负载工具。压力工具，可以创建一个比较苛刻的系统环境，譬如说让系统可用内存在一个很低的水平，然后运行被测试软件。负载测试工具可以帮测试工程师对被测试系统进行负载的增加。例如模拟10000个web的用户。
5.Interference Injectors and Noise Generators - 冲突注入器和噪声生成器。一图胜千言啊。
我们可以在两台机子中间加一个电脑，中间人，呵呵。然后可以加入噪声或者对包进行更改什么的，达到测试的效果。
6.Analysis Tools - 分析工具
这里面包括：
Word processing software 文字处理
Spreadsheet software 表格处理
Database software 数据库
File comparison software 文件比较
Screen capture and comparison software 抓图
Debugger 调试
Binary-hex calculator 二进制计算器
Stopwatch 计时器
VCR or camera 磁带机摄像机
Software Test Automation - 软件测试自动化。软件测试自动化的目标就是达到在无人干预的情况下能自动跑脚本，自动找出相应的bug，自动报告，做log记录等等……反正就是！一条龙。鉴于书中讲的自动化方法比较过时，这里就偷懒不说了。不过其实用上先进的工具都是同样的一个过程。1.录脚本回放，最最低级的过程。2.修改脚本加入检查点，实现了检查bug的自动化。3.模块化脚本，实现少量脚本的重用。4.数据驱动，实现广义上的重用。就是写一次脚本，运行N个case。5.关键字驱动，据说可以实现自动化脚本和测试用例同步产生。这个有待验证。
Random Testing -随机测试。这里书上用了一个猴子做比喻，呵呵，其实一个软件给了用户以后，我们根本不知道他们会怎么使用，有时候可能觉得不会有人那样子用软件的，但是什么事情都有可能发生，书上介绍了一种模拟随机时间的方法，就是搞一个robot，这个robot就像一个猴子那样子乱点，而且这个猴子还是个瞎子，软件挂了他还在乱点~
Realities of Using Test Tools and Automation - 使用测试工具和自动化的现实。前途是光明的道路是曲折的。所以要认清楚其本质！
1.软件在变，文档在变，需求在变。做自动化就要适应这些变化。由此得出，录脚本死路一条。
2.工具不能代替人的眼睛和直觉。因为是我们赋予了工具能力，那些我们没有“教”那些软件的事情他是不会做的
3.检查点是比较难做到。
4.测试工程师很容易就依赖于测试工具了。不过测试工具并不是银弹。
5.不要花费过多的时间在测试工具和自动化上面，这些都是为测试服务的，但是他们不是测试。
6.自动化脚本就是程序，所以也要跟开发程序一样，有代码控制，遵守指引。
7.一些带有侵略性(Invasive)的工具有可能对我们的测试造成影响。
作者: maguschen 时间: 2007-9-4 21:53
Bug Bashes and Beta Testing - bug盛会和beta测试
Having Other People Test Your Software - 让其他人来测试你的软件。这个跟中国古代的“三人行必有我师焉”是一个道理。同时，如果由几个不同的人来测试的话还能有很多好处：
1.可以防止“杀虫剂免疫”。一个人对某个软件不断进行测试，能找到的bug肯定是越来越少的。所以需要加入一些新鲜的血液：）
2.每个人都要自己的想法，不同的想法的一个并集就能很好地测试我们的软件啦！
3.男女搭配干活不累。那没有男男女女，几个人也行啊~反正一个人容易诱发自闭，呵呵。
4.观察其他人怎样工作的对自己的提高是相当有好处的！
Test Sharing - 共享测试
共享我们的测试，可以在工作了一段时间以后互相交换一下模块，测试一下对方的模块。或者至少应该给同事看看自己的等价类划分。还可以举行一个bug盛宴(Bug Bashes)。在一段时间内，可能是2个小时，大家放下手头的工作，然后对某个软件的某一个模块进行集中的测试，被测试的模块可以是之前已经发现好多bug的，也可以是之前是完美的模块，最后可以推举出一个bug queen bug king之类的，这个盛宴的目的就是为了对特定的部分找出bug来。在这里面，有一类人我们可以考虑把他们邀请到这个盛宴里面，他们就是做产品售后的人~呵呵。他们对软件的了解还是比较深的。
Beta Testing
Beta测试是把软件发布到已经选定好的用户群里面进行的测试，在现实的环境中进行。对于beta测试，可以考虑一下的问题：
1.beta测试的人群是哪些？应该选择有广泛代表性的，不要只给专业人员或者某一类特定的人群。不同的人群能发现不同的问题。
2.去了解那些beta测试的用户，看他们是否真的用软件了，还是放在那里发霉，还有他们发现bug以后有没有report上去。
3.对于配置测试和兼容性测试，beta测试是一个很好的手段去完成。因为在公司内部自己做完配置测试和兼容性测试是很难的，而beta测试可以有很多很多用户，不过同样要选好人群。
4.可用性测试也是一个很好的点，可以把一部份可用性测试放在beta测试里面来。理由同上。
5.除了以上优点，beta测试完全没有好处。不要指望beta测试能发现很多bug和修复他们，因为beta通常都是接近项目的尾声了~不过我发现了，google的很多东西一直beta着，什么gmail，输入法~我kao！
6.beta测试会耗费测试工程师很多的时间，因为测试工程师需要跟进这些beta用户发现的问题，帮助他们使用软件。
Outsourcing Your Testing - 把测试外包
配置测试和兼容性测试是一个不错的外包对象，一般来说一个公司没有太多的资源去购置不同的硬件，尝试不同的软件组合。另外本地化测试也是一个很好的选择，如果一个软件有10国语言，那么估计一个跨国公司也不容易找到10个不同国家的语言高手来测试吧。外包给专业的机构是个不错的选择。不过对于外包来说有以下问题需要注意的：
1.明确任务、负责人。
2.明确时间表、还有谁来定这个时间表等等
3.发包方提供什么文档和产出物给接包方
4.接包方最后的产物是什么
5.发包方和接包方之间如何沟通
6.制定一个验收的标准
作者: easyabc 时间: 2007-9-4 23:21
谢谢了，楼主真乃神人在世！
作者: maguschen 时间: 2007-9-5 11:37
原帖由 easyabc 于 2007-9-4 23:21 发表
谢谢了，楼主真乃神人在世！
凡人也sdlkfj8
作者: maguschen 时间: 2007-9-5 11:39
制定测试计划的目的是增强测试团队内部和外部的沟通，统一期望，还有对将要被执行的测试的理解。测试计划(Test Plan)只是制定测试计划过程的一个副产品，并不是制定计划的目的。当然啦，这个测试计划的文档还是相当重要的。不过要提防一种现象 - Shelfware - 那些文档永远都是躺在硬盘里面，没有去人看它。
Test Planning Topics - 测试计划的主题。
1.High-Level Expectations - 概要期望。这个问题经常被忽略，因为这个问题实在太明显了，以至于大家都默认其他人都知道了。不过作为一个测试工程师，永远不要去假设。
a.你知道制定测试计划和软件测试计划的目的么？如果你知道的话恭喜你，不过你能保证程序员，经理还有其他相关人等都知道么？还有一个更加重要的问题，他们都同意么？
b.什么样的产品会被测试？这个问题真的很幼稚啊，不就是XXXX3.0嘛。我们公司的产品，但是这个产品在什么时候release？是个简单的升级还是改头换面的大变化？是在公司内部完成的还是外包出去了？等等……完全了解一个产品是成功完成任务的关键。
c.产品的对质量的要求是到哪个水平？不同的人会有不同的要求，但是很多要求都是不可度量的，例如速度快，所以要定义一个被大家所接受的Scope是非常重要的。一定要明确指出测试的目标，而且还要得到大家的同意。这里或许需要有很多人的妥协。
2.People, Places, and Things - 人力，软件存放位置和硬件设施。人那就不用说了，没人谁来干活啊？这些参与项目的人都需要明确定义，他们是干啥的，怎么联系。尤其是在一个大的项目里面，需要跟踪每个工程师正在干啥，这样才有可能在项目进行的 过程中进行调整。文档放在哪里？被测试的软件在哪里可以下载，这些都是很重要的。如果需要某些硬件，那么这些硬件由谁来负责采购。
3.Definitions - 清晰定义。很多时候，一些看上去很简单很浅显的东西却没有被定义好的~~例如什么是一个bug？或者说bug的优先级是如果定义的，哪些是重要那些是次要的。所以在计划的过程中，要识别出那些有歧义的名词或者定义，然后对其进行明确的清晰的定义，消除歧义。书中列出了一些比较容易产生歧义的定义：
a.Build - 构建。这build也有很多种daily build，weekly build。哪种才是我们测试计划里面说的有效build，还有一个就是build的质量？是不是要通过某个冒烟测试才算是一个被承认的build。
b.Test release document (TRD) - 测试产出文档。这个是伴随每个build所附带的文档，一般包含build的状态，这个版本加入了什么新功能，跟以前的差别，修复了那些bug，还有是否为测试做好准备。
c.Alpha release - Alpha版本。需要明确Alpha版软件的质量，还有应该分发给哪些用户群进行适用。
d.Beta release - beta版本。跟Alpha版相同，还是要看质量和用户群。当然，还有发布的日期。
e.Spec complete - 什么时候文档需要完成。这个几乎是设定了也没用，因为变化才是永恒的。不过我们可以制定一个日期，在这个日期之后，这个文档就不允许有大的改动了。
f.Feature complete - 功能完成。在这个日期之后，程序员就不允许再添加新的功能，应该把精力放在修复bug上面。
g.Bug committee - Bug委员会。由各个经理组成的一个团队，他们决定那些bug是严重的，还有bug的修复优先级等等。
4.Inter-Group Responsibilities - 跨部门责任制。很多时候有一些任务是几个不同的部门的同事来负责，而又有一些任务是没有一个特别明显的负责人，到了项目的后期，很可能出现一种情况就是大家都觉得是对方完成了，最终发现谁也没有去做。为了避免这种情况的出现，我们可以制定一个表，上面把所有任务都列出来，然后相关的负责人也在上面，在表上做好特定的标记，标识出每个具体任务的负责人，还有参与者。
5.What Will and Won't Be Tested - 分清楚哪些是要测试的哪些是不需要的。
6.Test Phases - 测试阶段。制定测试阶段，假如说现在项目是迭代开发，或者应用瀑布模型，那么测试阶段也可以分好多种。可以有对需求文档进行测试的，对详细设计进程测试的，还有系统测试等等……这里有2个概念是非常重要的：entrance and exit criteria。入口条件和出口条件，测试做到什么样的程度就能结束，或者开发的具体活动到什么样的程度，测试才会介入。
7.Test Strategy - 测试策略。测试策略是定义在测试的过程中会用哪些方法。黑盒白盒？手动自动？选择外包？需要额外购买软件？
8.Resource Requirements - 资源要求。People - 人！需要多少人哪些人？Equipment - 设备，PC?MAC?打印机？Office and lab space - 这个有点夸张了。Software - 会用到哪些软件？虚拟机？Outsource companies - 外包公司？Miscellaneous supplies - 其他杂项，例如电话、参考书、培训。
9.Tester Assignments - 测试员分配。问道有先后，术业有专攻。哪些人具体负责哪项测试需要分配好，而且也需要明确责任。
10.Test Schedule - 测试日程表。对不同的人力资源进行分配。哪些测试在什么时候介入。
11.Test Cases - 测试用例。在计划里面，需要明确谁负责设计测试用例，测试用例在哪里存放，还有什么时候取出来用，还有，测试用例也需要维护。
12.Bug Reporting - 错误报告。错误报告可以帮助我们对错误的追踪。可以知道我们提交的bug到了什么杨的状态了，是否被修正了。
13.Metrics and Statistics - 度量和统计。度量和统计能够帮助我们了解项目的进程。书中列举了一些度量的例子：
a.Total bugs found daily over the course of the project
b.List of bugs that still need to be fixed
c.Current bugs ranked by how severe they are
d.Total bugs found per tester
e.Number of bugs found per software feature or area
14.Risks and Issues - 风险和问题。识别风险在测试计划里面是一个比较有用的工作。识别出风险，做出一些应对风险的准备。尽早识别风险并且解决问题对整个项目是很有好处的，因为我们都知道，修复错误的代价会随着项目的进行而变得越来越高。
作者: maguschen 时间: 2007-9-6 11:54
The Goals of Test Case Planning - 测试用例计划的目的
测试用例计划的目的是什么呢？如果你想要别人按照一定的规矩办事，那么你自己也必须首先遵守这些规矩。所以作为一个测试员，如果一拿到测试计划就坐下来疯狂的写Case，那么跟一个不看产品说明书就开始编码的程序员是一样的。我们要仔细地而且系统地去计划测试用例，为什么要这样子呢？有4个原因：
Organization - 一份好的计划可以被很好地组织起来，这样的话出来你以外的其他人就能有效地回顾你的成品
Repeatability - 如果没有一个正确的计划，那么是不可能知道我们的测试用例运行情况，而且几乎不能被重新使用，因为通常你都不知道它在哪里
Tracking - 可追踪的。有了好的计划，才能追踪项目的进度，多少case已经被执行了多少pass多少fail。各自状态如何。
Proof of testing (or not testing) - 证明已经测试过的。这个记得以前在reyrey的时候一个老外就说过，测试用例能够帮助公司避免法律的纷争。
Test Case Planning Overview - 测试用例计划概览
除了书中以前说的测试计划(Test Plan)，在它的下面会有这些：test design specification(测试设计说明书), test case specification(测试用例说明书), the test procedure specification(测试流程说明书)
Test Design - 测试设计。
这个“设计”是为产品说明书中的单独的软件功能定义测试方法的。“把测试计划中定义的测试方法提炼出来，并且识别出需要测试覆盖的对象及其相关测试。也需要识别出测试用例和测试流程，如果有需要的话完成测试的入口条件和出口条件”测试计划的目的是组织和描述那些对特定功能的测试，但是在测试设计里面是不会设计到细节的。一下列出了IEEE 829标准的一些点，这些点是一个测试计划需要包含的内容。这些都是用做参考而不是标准的：
Identifiers - 就是ID，用来跟其他相关文档做关联的。例如这个测试计划#9527对应的是#173173的测试用例。
Features to be tested - 被测试的功能。就是对被测试功能的描述~在这部分还需要识别出那些不是直接测试到的功能，例如测试一个save对话框的时候可以顺便检查UI。还有的就是要定义哪些功能是不需要测试的，不要做无用功。
Approach - 测试方法。黑盒白盒手动自动~
Test case identification - 测试用例的识别。这里不是说要有详细的测试用例，只是标明了哪些测试用例将会覆盖哪些功能的测试。具体细节不会出现在测试设计里面。
Pass/fail criteria - 通过测试和测试失败的标准。
Test Cases - 测试用例。
“对测试的实际输入以及其相应的输出进行文档记录，测试用例同时识别出任何在测试流程中可能出现的限制。”而且测试用例会跟一个或多个测试计划想关联，而通常还会跟不止一个的测试流程关联。
Identifiers - ID，用来做文档关联。
Test item - 测试项目。描述被测试的细节的功能，代码模块等等。而且还需要关联上哪些文档提及到了被测试的功能。
Input specification - 输入详述。列举出所有的输入或者执行测试用例的条件。
Output specification - 输出详述。描述测试用例的期望输出。
Environmental needs - 环境需要。是不是需要特定的硬件软件外设工具等等？
Special procedural requirements - 特殊的程序要求？
Intercase dependencies - 用例之间的相互依赖，是否有一些用例，需要在别的用例执行通过的情况下才能进行的。
Test Procedures - 测试流程。
“识别出执行所需要的步骤。测试流程是一步一步如何去执行测试用例的细节说明”
Identifiers - ID，用来做文档关联。
Purpose - 目的。
Special requirements - 特殊需求。
Procedure steps - 流程步骤。
Detail Versus Reality - 与实际的对照。
The trick is finding the right level of moderation - 这里的窍门就是找到合适的度。古人云：过犹不及。很多时候我们要做到什么样的程度，取决于每个项目不同的要求。
Test Case Organization and Tracking - 测试用例的组织与跟踪
In your head - 记载脑子里面？俗语说的好啊，好记性不如烂笔头。大家还是省点头脑风暴的时间吧。
Paper/documents - 记在文档里面有个缺点就是很难找到具体想要的东西，不过好处就是如果有个测试员的签名的话，是个很好避免法律纠纷的方法，呵呵
Spreadsheet - 电子表格。日本公司喜欢用Excel（当然啦，Excel只是其中一种Spreadsheet）。而且用的出神入化。我看我连Excel的门都没入啊。唉。
Custom database - 数据库。一种比较好的选择就是测试用例管理工具。例如QC, CC。呵呵。不过是要钱di。还是看开源的吧。
后记：其实书里面分的好细，一般公司也就是一个测试计划下来就是测试用例了，而且一般我们说的测试用例都已经包含了测试流程的内容--具体的执行步骤。我觉得任何书或者参考资料或者方法论都只是参考而不是标准，即使它们没有说能够被裁剪，但是我们也可以发挥自己的主观能动性来改造它们，让之适合我们各自的使用情况。我个人觉得就不用死扣你这公司不标准啊怎么测试用例跟测试流程都连在一起了。呵呵。做人要变通：）
作者: eferrari 时间: 2007-9-7 00:36
很厉害啊!英文过8级了!
作者: xx99 时间: 2007-9-7 11:01
高~~~
作者: maguschen 时间: 2007-9-8 16:23
这个测试执行完了发现bug也不能随便跟人说说就算了，要记录下来~
Getting Your Bugs Fixed - 让你发现的缺陷得到修复
不是我们找到什么bug，都会得到修复的，有些可能推迟，有些可能被忽略，有些可能作为下一版的feature。以下原因是为什么一个bug没有被修复
1.There's not enough time - 时间永远都是紧张的。
2.It's really not a bug - 业界有个名言“It's not a bug, it's a feature！”呵呵。
3.It's too risky to fix - 对于一些遗留系统，他们就好像定时炸弹，没人敢碰他们。
4.It's just not worth it - 不值得修复。这些决定都是商业决定或者基于风险的而得出的结论。
5.Ineffective bug reporting - 一份非高效的缺陷报告。测试员没有很好的对缺陷进行描述。
针对最后一条，也就是这章的重点，要记住以下一些报告缺陷的基本原则：
1.Report bugs as soon as possible - 尽早把缺陷报告上去。越早找到bug，能修复bug的时间就越多。
2.Effectively describe the bugs - 对缺陷的高效地描述。
a.Minimal - 简明扼要。只把必须的步骤挑出来，描述一下事实。报bug的时候并不是把test case复制粘贴过去就行了，如果这样的话请个人来测试有何意义，我们要发挥主观能动性，分析出最简单最核心的步骤。同时要对事不对人。
b.Singular - 报告单一的bug。每一个报告只能包含一个缺陷。不要把N个错误写到一个报告里面。因为在一个报告里面有许多bug的话，很容易会出现一种情况~修复了其中一个就忘记了另外的。
c.Obvious and general - 明显的和概括的。不要运行一个自动测试6个小时然后出现错误了，让修复bug的人也运行6个小时……
d.Reproducible - 可重现的。这个一定要注意，提交的bug一定要是能重现的，不能说有时候能出有时候不能出。
3.Be nonjudgmental in reporting bugs - 在缺陷报告里面，不要有任何带有感情色彩的用语。对事不对人。
4.Follow up on your bug reports - 跟进你所提交的测试报告。一个好的测试员能找到和记录下很多缺陷，并且在那些bug被修复的过程中继续监控他们。
Isolating and Reproducing Bugs - 隔离和重现缺陷。如果你发现了一个bug，它的步骤很多，而且不是每次都能重现，那么一下的一些方法可以作为参考：
1.不要对任何事情做任何假设，不能假设某些步骤肯定没有问题。我们需要记录下所做的每一个步骤的每一个细节。做这个的目的是要确信每个有可能引起bug的细节都能被记录下来用于以后的分析
2.注意那些竞争条件和并发的问题
3.利用白盒测试可以让边界条件，内存泄露和数据溢出自己暴露出来。
4.一些跟状态有关的bug只在某些状态下才能重现。
5.对于内存网络共享硬件等的问题也可能考虑进去，例如同时用一个打印机。
6.不要忽略硬件的问题，有可能这个是个配置问题。
Not All Bugs Are Created Equal - 不是所有bug都是平等的。对每个bug，都可以给它们定义出各自的严重程度还有优先等级。
Severity - 严重程度。指出这个bug有多严重，是对bug本身问题的一个描述。例如一个能让系统crash的bug可以定义为最严重的bug。
Priority - 优先级。指出需要对这个bug有多重视。
不是说越严重的bug优先级就越高。例如一个可以引起系统crash的bug，这是一个严重的bug，但是这个bug是在一些非常极端的情况下才能出现，那么就有可能不是一个优先级很高的bug。又好像是一个公司的LOGO错了，他对于用户的影响其实不大，所以这个bug的严重性可能只是很低，但是对公司的影响是很大的，所以优先级很高。
A Bug's Life Cycle - 缺陷的生命周期。
对于一个Bug来说，最简单的生命周期就是这张图所显示的。Open - Resolved - Closed。这个当然只是从测试人员的角度来看bug的声明周期了。这个是最本质的东西，每个公司都有自己不同bug生命周期，来适应本公司的一些工作吧。书中列了一个变种后的~就是下图：
1.发现bug，就要提交报告，这样一个bug报告就生成了，出于open状态
2.bug提交以后有人修复，然后就能转到resolved状态。
3.然后再经过测试员的验证，证实真的修复了，这个bug就可以open了
前3个是最最最简单的3种状态
4.通常提交一个bug以后会让一个bug委员会或者是开发经理来review，看这个到底是不是bug，还有分配给谁来修复，确认优先级等等
5.如果Review证实ok了是一个bug，那么就可以分配给工程师来修复，然后这个图其实是少了一个状态的。呵呵
6.如果Review完了以后觉得这个不是一个bug，可能是一个新的功能，或者这个bug在这个版本里面就不去修复了，就会去到Deferred状态那里。
7.如果证实这个根本不是一个bug，那么就可以直接closed。
8.对于在resolved状态，如果测试员检验的时候发现bug没有被修复，那么这个bug又回到了open状态。
9.如果一个bug在这一个版本修复了，但是在下一个版本里面又出现了，那么又能回到open状态了。
10.Deferred的bug有可能在下一版被处理。
作者: zlfoxy 时间: 2007-9-8 21:13
标题: 我觉得你错了。
原帖由 maguschen 于 2007-8-19 22:57 发表
分支覆盖(Branch Coverage)
就是每个分支都能走一次，这个要做到是很难，因为加入有5个IF语句，那么就是2的5次方，32种组合，那如果是100个IF呢~
这个地方我认为你理解错了。
所谓分支覆盖，就是使程序中每个判断的取真分支和取假分支至少经历一次，
5个if ，
最理想情况下也就2用例就ok了吧。
可能你跟路径覆盖混淆了。sdlkfj8
你真有毅力，我也在看这本书，也做了笔记，不过，没有坚持下去啊。
[ 本帖最后由 zlfoxy 于 2007-9-8 21:17 编辑 ]
作者: maguschen 时间: 2007-9-8 21:18
Using the Information in the Bug Tracking Database - 善于利用缺陷跟踪系统的数据。
我们把缺陷提交到数据库以后，其实我们得到不单只是一条记录那么简单，我们还能从里面得到更多。例如在1个月前项目的进展情况，在哪些模块上发现了多少的bug，上周的情况如何？我们还能根据这些数据来预测将来大概会是一个什么样子的情况。我们可以定义许多度量标准。有些公司可能用一个测试员发现多少bug来作为一个标准，其实这是不科学的，因为有可能刚好那个测试员所测的模块是由一个高手来写的，或者那个模块特别复杂然后做这个模块的人特别没经验，那么结果就相反了。
Metrics That You'll Use in Your Daily Testing - 日常工作中常用的度量（感觉书中文不对题） 除了提交bug，缺陷管理系统里面另外一个常用的功能莫过于查询出我们感兴趣的bug了。呵呵。我自己在公司就有几个查询，就是用来查找自己提交的bug的。随时跟踪情况。还有就是查询特定ID的bug，查询一下BUG的标题，看有没有重复提交的。
Common Project-Level Metrics - 项目中常用的度量
在第三章里面就提过，现在能找到越多的缺陷，那么就有更多的缺陷有待发掘。如果有一个统计表，上面指出了A模块上发现的缺陷很多，那么对于这个A模块应该投入更多精力去测试，因为他的潜在缺陷应该还有很多。不过我们需要一些图表以外的信息，例如如果B模块发现的BUG很少，原因是B模块根本没有开始测试或者是复杂的测试员请假了，那么这些信息是应该考虑到的。
这一章内容很多，但是都是根据图标来做的，要翻书才能想起一下来，而且基本上接触的比较少：（总算到这了，还有2章，加油加油~~
作者: maguschen 时间: 2007-9-8 21:34
原帖由 zlfoxy 于 2007-9-8 21:13 发表
这个地方我认为你理解错了。
所谓分支覆盖，就是使程序中每个判断的取真分支和取假分支至少经历一次，
5个if ，
最理想情况下也就2用例就ok了吧。
可能你跟路径覆盖混淆了。sdlkfj8
你真有毅力，我也在 ...
sdlkfj1 好啊，终于有人就内容回帖了，感动啊~~
这个我 回头看了看，的确是我当时理解的问题，我一看书就理解成
IF
IF
IF
IF
这种嵌套模式了，所以就觉得要很多测试用例
但其实这种模式也用不了多少测试用例，所以就是我理解错了，呵呵，谢谢指出错误。
我已经更新了那2个关于条件覆盖和分支覆盖的描述啦，呵呵。幸亏手头上还有别的书
其实这本《软件测试》是个基础入门书籍，并不是说上面说的就很全面或者非常权威，我觉得有其他书作为补充还是非常有必要的，呵呵~~
[ 本帖最后由 maguschen 于 2007-9-8 21:48 编辑 ]
作者: maguschen 时间: 2007-9-9 18:05
Quality Is Free - 质量是免费的。
质量为什么是免费的呢？因为其实一个公司可以不花费额外的开销就能生产出一个高质量的产品。回到前面书中已经提过了，越晚发现缺陷，付出就越大，而且这个不是呈现线性增长，而是指数增长。
把达到高质量产品的花费划分为两种不同类型，一种是conformance cost另一种是nonconformance cost。conformance的开销是指-计划测试并且运行一次测试证明软件是正常工作的，对于这些活动的总开销，就是conformance cost。如果软件存在缺陷，那么投入到隔离缺陷，提交缺陷报告，回归测试等相关活动的开销，就算是nonconformance cost的一部份。以上的错误都是在产品发布之前发生的，所以归类未内部错误(internal failures)，而且总体的付出的不多的。
如果在测试的过程中没有发现缺陷，而是由我们的用户来发现的话，那么花费就是巨大的，用户会打电话过来质疑或者寻求帮助，然后再让测试人员提交缺陷报告并且由开发人员修复，还要重新测试来确定那些缺陷已经被修复了，重新发布产品。更糟糕的是有可能要召回所有产品并且惹上官司。这一类的问题就被称为外部错误(external failures)。在正常情况下，外部错误的开销要比因为内部错误而产生的开销要大。所以要尽可能避免外部错误的出现。
Testing and Quality Assurance in the Workplace - 在工作中，有很多名词可能都用来描述测试，例如Software Testing, Software Quality Assurance, Software Quality Control, Software Verification and Validation, Software Integration and Test。大多数情况下他们是可以替换的，但是其实他们有各自的含义，这部分主要讲述了两个最常见的名词的区别Software Testing, Software Quality Assurance。软件测试和软件质量管理。
Software Testing - 软件测试。强调了一下软件测试人员的目的：The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed 简单来说软件测试可以描述为“评定，报告，跟踪”。作为一个软件测试员，有一个非常重要的特征“你不需要为软件的质量负责”。因为软件测试员只负责测试软件，提交缺陷报告并且跟踪，仅此而已。就好像一个医生不能单靠给病人量体温就能治好病人的感冒一样。
Quality Assurance - 质量保证。一个QAer，他主要负责检查和度量软件开发过程并且能改进之，使其达到防止缺陷发生的目的。QA是对软件质量负责的人员之一。很多公司可能都不分QA和测试，肯能广告是打个QA听起来比较牛吧。呵呵。
Test Management and Organizational Structures - 测试管理和组织架构。不同的架构有不同的优点缺点，这都要看哪种适合自己的公司了。最常见的是开发经理带着开发人员和测试人员一起工作，这种组织方式的好处就是开发和测试合作比较紧密，但是不好的地方就是很容易产生一种矛盾。开发经理的目的是按时完成任务，如果投入资源到测试中，测试人员就能发现更多的缺陷，这也意味着开发人员要干更多的活，那么什么时候才能发布产品呢？这种组织架构要求开发经理要十分了解开发和测试的关系，才能胜任。另外一种结构就是由一个项目经理，分别带着开发团队和测试团队，每个团队有个lead或者经理。这种组织架构的好处就是测试和开发有同等的发言权。但是缺点就是基本上什么事情都是由PM来敲定，在一些高风险的项目中，质量保证团队的声音应该更加强。所以就有另外一种组织。一个执行经理，手下有开发经理测试经理和项目经理。在这种组织下，可以简历起一系列的标准。
Capability Maturity Model (CMM) - 能力成熟度模型。
Level 1: Initial - 在这一个级别里面，整个项目都是混乱的，随机的，会发生什么事情没人会知道，项目的成功完全靠的运气和个人英雄。
Level 2: Repeatable - 这是一个项目级别的思想。基本的软件测试实践会落实到项目当中。
Level 3: Defined - 一个组织级别的思想。文档和计划都是经过评审的，测试和开发是相互独立的。
Level 4: Managed - 开发过程和软件的质量都是受控的，而且在项目过程中可以通过调整来修正问题，从而使得项目成功。
Level 5: Optimizing - 持续优化……
作者: maguschen 时间: 2007-9-9 20:09
今天晚上终于把最后一章也读完了，书中最后一章介绍了如果找一个软件测试的工作，如果开始做软件测试方面的工作等等。介绍了一些网站还有会议等。都比较有用，不过就是很花时间去看~呵呵。有时间有耐性的话应该能发现不少宝藏。
书是读完了，《软件测试》其实是一本入门书籍，读者对象应该是入门者，我觉得书上讲的算是比较系统，但是知识介绍的不够详细，所以不能光看这一本书，应该结合其他书籍还有伟大的Internet来学习。而且我个人觉得这本书还是值得多次翻阅，估计2年后我如果再次看这本书的话应该又是另外的感觉另外的收获。
作者: 770639805 时间: 2008-10-11 00:46
实在是高啊！要学的实在是太多了！
作者: nacllv 时间: 2010-6-28 11:16
看的是第二版的吗，有没有电子版
作者: mymarvell 时间: 2010-6-28 23:06
标题: 回复 1# 的帖子
加油楼主，我这两天也在看，争取也写个读书笔记出来。
作者: 千里 时间: 2010-7-3 13:33
楼主花了很大心思的，很值得大家看的。应该给这样的人送花
作者: declaring 时间: 2011-2-26 14:58
老贴 好贴 收藏
作者: david.hu 时间: 2011-7-28 14:48
学习了
作者: ruyanyun 时间: 2011-10-7 18:12
学习
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) |
Powered by Discuz! X3.2 |