软件文档的种类。说起文档，我最初认为就是一个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.做这方面的工作太费时间了。么办法啊~ 辛辛苦苦写了大半……浏览器一崩溃，啥都没有……吐血！！辛苦奋斗二十年，一朝回到解放前！
黑客的动机！
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 - (容易发现性)这个威胁是不是很容易被发现，还是只有内部人员泄露才会被发现 这个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。 已阅，回个帖子帖支持。
还没有看完
真是太佩服楼主了，呵呵，我现在一口气还没有看完，以后慢慢看，辛苦了，我在这里有礼了！sdlkfj5 哈哈很强 原帖由 xidian 于 2007-9-3 00:02 发表 http://bbs.51testing.com/images/common/back.gif哈哈很强
xidian。。。。。。。 我终于看到自动化测试了，呵呵，不过这章不是我想象中的那样子，可能这本书并不是主要介绍自动化测试的吧。不过也接触了一些新的知识，不错不错。自己做过的东西回头再看就是有感觉啊：）
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 - 驱动器。就是一个控制器，可以控制软件的操作的工具。其实我们平时用的很多自动化测试工具，功能的性能的，都应该算是这一类的，书上举了一个例子，我看的有点迷惑，如图。
http://www.51testing.com/attachments/2007/09/68764_200709041402521.jpg
把右上角那个电脑的鼠标键盘拆掉，然后用右下角的电脑，给上面那个电脑发送模拟的键盘鼠标信息来进行测试。我刚看这个觉得很扯淡。然后书上立马就有个反问句说大家是不是觉得很扯淡啊。我真的是I cannot agree more啊，扯就一个字！书上给出的解释是：
a.有可能某些软件或者操作系统不支持多任务，所以被测试的系统只能单独运行，不能加上Driver。用这种方法就能避免这个问题。
b.如果从外部系统把操作命令输入进来，那么这个这个测试系统就是非侵略性。如果Driver和被测试的软件都在一个系统运行，那么有可能影响到测试结果。
这个解释听合理的：）呵呵。
3.Stubs - 桩。桩更好跟驱动是相反的。例如现在要测试一个打印程序，如果打印出来的话第一比较麻烦，第二可能会有一些发现不到的细节上的错误。那么桩和仿真器emulator有什么区别呢，他们之间的区别就是桩还能看到不同系统之间发送的信息，而仿真器只能仿真，不具备查看内部数据的功能。
4.Stress and Load Tools - 压力和负载工具。压力工具，可以创建一个比较苛刻的系统环境，譬如说让系统可用内存在一个很低的水平，然后运行被测试软件。负载测试工具可以帮测试工程师对被测试系统进行负载的增加。例如模拟10000个web的用户。
5.Interference Injectors and Noise Generators - 冲突注入器和噪声生成器。一图胜千言啊。
http://www.51testing.com/attachments/2007/09/68764_200709041514221.jpg
我们可以在两台机子中间加一个电脑，中间人，呵呵。然后可以加入噪声或者对包进行更改什么的，达到测试的效果。
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)的工具有可能对我们的测试造成影响。
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 发表 http://bbs.51testing.com/images/common/back.gif
谢谢了，楼主真乃神人在世！
凡人也sdlkfj8 制定测试计划的目的是增强测试团队内部和外部的沟通，统一期望，还有对将要被执行的测试的理解。测试计划(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 - 风险和问题。识别风险在测试计划里面是一个比较有用的工作。识别出风险，做出一些应对风险的准备。尽早识别风险并且解决问题对整个项目是很有好处的，因为我们都知道，修复错误的代价会随着项目的进行而变得越来越高。 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。还是看开源的吧。
后记：其实书里面分的好细，一般公司也就是一个测试计划下来就是测试用例了，而且一般我们说的测试用例都已经包含了测试流程的内容--具体的执行步骤。我觉得任何书或者参考资料或者方法论都只是参考而不是标准，即使它们没有说能够被裁剪，但是我们也可以发挥自己的主观能动性来改造它们，让之适合我们各自的使用情况。我个人觉得就不用死扣你这公司不标准啊怎么测试用例跟测试流程都连在一起了。呵呵。做人要变通：） 很厉害啊!英文过8级了! 高~~~ 这个测试执行完了发现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 - 缺陷的生命周期。
http://www.51testing.com/attachments/2007/09/68764_200709081554151.gif
对于一个Bug来说，最简单的生命周期就是这张图所显示的。Open - Resolved - Closed。这个当然只是从测试人员的角度来看bug的声明周期了。这个是最本质的东西，每个公司都有自己不同bug生命周期，来适应本公司的一些工作吧。书中列了一个变种后的~就是下图：
http://www.51testing.com/attachments/2007/09/68764_200709081600581.jpg
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有可能在下一版被处理。
我觉得你错了。
原帖由 maguschen 于 2007-8-19 22:57 发表 http://bbs.51testing.com/images/common/back.gif分支覆盖(Branch Coverage)
就是每个分支都能走一次，这个要做到是很难，因为加入有5个IF语句，那么就是2的5次方，32种组合，那如果是100个IF呢~
这个地方我认为你理解错了。
所谓分支覆盖，就是使程序中每个判断的取真分支和取假分支至少经历一次，
5个if ，
最理想情况下也就2用例就ok了吧。
可能你跟路径覆盖混淆了。sdlkfj8
你真有毅力，我也在看这本书，也做了笔记，不过，没有坚持下去啊。
[ 本帖最后由 zlfoxy 于 2007-9-8 21:17 编辑 ] 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 于 2007-9-8 21:13 发表 http://bbs.51testing.com/images/common/back.gif
这个地方我认为你理解错了。
所谓分支覆盖，就是使程序中每个判断的取真分支和取假分支至少经历一次，
5个if ，
最理想情况下也就2用例就ok了吧。
可能你跟路径覆盖混淆了。sdlkfj8
你真有毅力，我也在 ...
sdlkfj1 好啊，终于有人就内容回帖了，感动啊~~
这个我 回头看了看，的确是我当时理解的问题，我一看书就理解成
IF
IF
IF
IF
这种嵌套模式了，所以就觉得要很多测试用例
但其实这种模式也用不了多少测试用例，所以就是我理解错了，呵呵，谢谢指出错误。
我已经更新了那2个关于条件覆盖和分支覆盖的描述啦，呵呵。幸亏手头上还有别的书
其实这本《软件测试》是个基础入门书籍，并不是说上面说的就很全面或者非常权威，我觉得有其他书作为补充还是非常有必要的，呵呵~~
[ 本帖最后由 maguschen 于 2007-9-8 21:48 编辑 ] 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 - 持续优化……
