Ron Patton软件测试读书笔记连载

maguschen

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

ruyanyun

学习

david.hu

学习了

declaring

老贴 好贴 收藏

千里

楼主花了很大心思的，很值得大家看的。应该给这样的人送花

mymarvell

加油楼主，我这两天也在看，争取也写个读书笔记出来。

nacllv

看的是第二版的吗，有没有电子版

770639805

实在是高啊！要学的实在是太多了！

maguschen

今天晚上终于把最后一章也读完了，书中最后一章介绍了如果找一个软件测试的工作，如果开始做软件测试方面的工作等等。介绍了一些网站还有会议等。都比较有用，不过就是很花时间去看~呵呵。有时间有耐性的话应该能发现不少宝藏。

书是读完了，《软件测试》其实是一本入门书籍，读者对象应该是入门者，我觉得书上讲的算是比较系统，但是知识介绍的不够详细，所以不能光看这一本书，应该结合其他书籍还有伟大的Internet来学习。而且我个人觉得这本书还是值得多次翻阅，估计2年后我如果再次看这本书的话应该又是另外的感觉另外的收获。

maguschen

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

原帖由 zlfoxy 于 2007-9-8 21:13 发表

这个地方我认为你理解错了。
所谓分支覆盖，就是使程序中每个判断的取真分支和取假分支至少经历一次，
5个if ，
最理想情况下也就2用例就ok了吧。
可能你跟路径覆盖混淆了。sdlkfj8

你真有毅力，我也在 ...

sdlkfj1 好啊，终于有人就内容回帖了，感动啊~~
这个我 回头看了看，的确是我当时理解的问题，我一看书就理解成
IF
   IF
      IF
         IF
这种嵌套模式了，所以就觉得要很多测试用例
但其实这种模式也用不了多少测试用例，所以就是我理解错了，呵呵，谢谢指出错误。

我已经更新了那2个关于条件覆盖和分支覆盖的描述啦，呵呵。幸亏手头上还有别的书
其实这本《软件测试》是个基础入门书籍，并不是说上面说的就很全面或者非常权威，我觉得有其他书作为补充还是非常有必要的，呵呵~~

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

maguschen

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章，加油加油~~

zlfoxy

原帖由 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

这个测试执行完了发现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有可能在下一版被处理。

xx99

高~~~

eferrari

很厉害啊!英文过8级了!

maguschen

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。还是看开源的吧。




后记：其实书里面分的好细，一般公司也就是一个测试计划下来就是测试用例了，而且一般我们说的测试用例都已经包含了测试流程的内容--具体的执行步骤。我觉得任何书或者参考资料或者方法论都只是参考而不是标准，即使它们没有说能够被裁剪，但是我们也可以发挥自己的主观能动性来改造它们，让之适合我们各自的使用情况。我个人觉得就不用死扣你这公司不标准啊怎么测试用例跟测试流程都连在一起了。呵呵。做人要变通：）

maguschen

制定测试计划的目的是增强测试团队内部和外部的沟通，统一期望，还有对将要被执行的测试的理解。测试计划(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

原帖由 easyabc 于 2007-9-4 23:21 发表
谢谢了，楼主真乃神人在世！

凡人也sdlkfj8

easyabc

谢谢了，楼主真乃神人在世！