软件开发过程

 目    录

第1章   软件测试的背景
第2章   软件开发的过程
第3章   软件测试的实质

第4章   检查产品说明书
第5章   带上眼罩测试软件
第6章   检查代码
第7章   带上X光眼镜测试软件

第8章   配置测试
第9章   兼容性测试
第10章 外国语言测试
第11章 易用性测试
第12章 测试文档
第13章 软件安全性测试
第14章 网站测试

第15章 自动测试和测试工具
第16章 缺陷轰炸和beta测试

第17章 计划测试工作
第18章 编写和跟踪测试用例
第19章 报告发现的问题
第20章 成效评价

第21章 软件质量保证
第22章 软件测试员的职业
第一部分  软件测试概述
第2章  软件开发的过程
2.1  产品的组成部分

  软件产品到底是什么？大多数人认为，软件产品仅仅是从互联网上下载或者从DVD光盘安装到计算机上的程序。这样描述并无不对，实际上制作软件还包括许多隐含的内容。还有许多“藏在背后”的东西通常被认为理所当然或者被忽视。尽管这些部分容易被遗忘，但是软件测试员要铭记在心，因为这些全是可测试的对象并且包含缺陷。
2.1  产品的组成部分

 2.1.1  软件产品需要多少投入
2.1  产品的组成部分

 2.1.1  软件产品需要多少投入

2.1.1.1  客户需求
       编写软件的目的是满足一些人的需求，这些人称为客户。为了准确地满足需求，产品开发小组必须摸清客户所想地。有些小组只是凭猜测，但大多数小组搜集详细信息时采取问卷调查、收集软件以前版本反馈信息、收集竞争产品信息、收集期刊评论、收集焦点人群地意见以及其他诸多方式，一些是正规的，一些是非正规的。接下来，所有这些信息都将被研究、提炼、分析以便确定软件产品应该具备哪些功能。

        利用焦点人群审视软件功能
2.1 产品的组成部分

 2.1.1  软件产品需要多少投入

2.1.1.2  产品说明书

       对于客户需求的研究结果其实只是原始资料，并没有描述要做的产品，只是确定是否需要做（或不需要做）以及客户要求的功能。产品说明书综合上述信息以及没有提出但必须要求实现的需求，真正地定义产品是什么、有哪些功能、外观如何。
        产品说明书的格式千差万别。有些公司——特别是为政府、航天部门、金融机构和医药企业开发的产品的公司——才用严格的过程，要进行大量的检查和对比。结果是产品说明书极其详细完整，而且是“锁定”的，也就是说，没有极特殊的理由绝不能变。开发小组的每一个成员都清楚的知道他们在做的是什么。
2.1  产品的组成部分

 2.1.1  软件产品需要多少投入

2.1.1.3  进度表
2.1  产品的组成部分

 2.1.1  软件产品需要多少投入

2.1.1.4  软件设计文档
        根据公司和项目合作小组的不同，程序员的文档也千差万别，但其目的都是规划、组织即将编写的代码。常用软件设计文档清单：

结构文档。描述软件整体设计的文档。
数据流图。表示数据在程序中如何流动的正规示意图。
状态转换图。把软件分解为基本状态或者条件的另一种正规示意图，表示不同状态间转换的方式。
流程图。用图形描述程序逻辑的传统方式。
代码注释。软件代码中嵌入有用的注释是极为重要的，这样便于维护代码的程序员轻松掌握代码的内容和执行方式。
2.1  产品的组成部分

 2.1.1  软件产品需要多少投入

2.1.1.5  测试文档

        和程序员必须对工作进行计划和进行文档记录的原因一样，测试员必须写测试文档。软件测试小组提交的文档比程序员还多的情况并不少见。比较重要的测试提交清单：

测试计划（test plan）。描述用于验证软件是否符合产品说明书和客户需求的整体方案。
测试用例（test cases）。列举测试的项目，描述验证软件的详细步骤。
缺陷报告（bug reports）。描述执行测试用例找出的问题。
测试工具和自动测试（test tools and automation）。如果测试小组使用自动化测试工具测试软件，不管是够买的还是自己编写的工具，都必须有文档记录。
度量、统计和总结（metrics，statistics，summaries）。测试过程的汇总。
2.1  产品的组成部分

 2.1.2  软件产品由哪些部分组成
2.1  产品的组成部分

 2.1.2  软件产品由哪些部分组成

        要认识到当产品打包分发时，不仅仅分发的是代码，许多支持包含在内。由于所有这些部分客户都要查看或使用，所以也需要测试。牢记下面的清单，从而对软件产品不仅限于代码这点有个初步印象：

       帮助文档  用户手册
       样本和实例  标签和不干胶
       产品支持信息 图标和标志
       错误信息  广告和宣传材料
       安装   说明文件

 别忘了测试错误提示信息
2.2  软件项目成员

  公司和项目不同，人员也就大不相同。但是对于大多数情况，分工是一样的，只是叫法不同而已。下面的清单不按次序地列出了主要人员极其职责。给出了最常用地名称，但是不包括变动和增加等情况：

项目经理、程序经理或者监制人员自始至终驱动整个项目。
体系架构师或者系统工程师是产品小组中的技术专家。
程序员、开发人员或者代码制作者设计、编写软件并修复软件中的缺陷。
测试员或者质量保证（Quality Assurance，QA）员负责找出并报告软件产品的问题。
技术作者、用户协助专员、用户培训专员、手册编写员或者文案专员编制软件产品附带的文件和联机文档。
配置管理员或构建员负责把程序员编写的代码及技术作者写的全部文档资料组合在一起，合成一个软件包。
2.3  软件开发生命周期模式

 2.3.1  大爆炸模式

 
2.3 软件开发生命周期模式

 2.3.1 大爆炸模式

        关于宇宙的形成有一种大爆炸说，数百亿年前，一股无穷的能量大爆炸创造了宇宙。软件开发大爆炸模式与上述理论一样。一大堆东西（人力和资金）放在一起，巨大的能量释放——通常很野蛮——产生了优秀的软件产品——或者一堆废品。
       大爆炸模式的优点是简单。计划、进度安排和正规开发过程几乎没有，所有精力都花在开发软件和编写代码上。假如产品需求无需很好理解，而且最终发布日期可以随便更改，这样的开发过程很理想。此外，还要有聪明过人的客户，因为他们直到最后才知道自己会拿到什么样的软件。
       多数情况下，大爆炸模式几乎没有什么测试。假如有的话，也要挤在产品发布前进行。这种模式下居然有测试的容身之地真是令人感到神奇，也许是进行测试会使大家感觉好一些。
2.3  软件开发生命周期模式

 2.3.2  边写边改模式

2.3  软件开发生命周期模式

 2.3.2  边写边改模式

        边写边改模式是项目小组在未刻意采用其他开发模式时默认的开发模式。这是在大爆炸模式基础上更进了一步，至少考虑到了产品需求。
       由于开头几乎没有计划和文档编制，项目小组得以迅速展现成果。因此边写边改模式极其适合意在快速制作而且用完就扔的小项目，例如原型范例和演示程序。即便如此，许多著名的软件仍然才用了边写边改模式。如果文字处理或者电子表格软件存在大量软件缺陷，或者功能不完备，就可能是在边写边改模式下制造出来的。
       与大爆炸模式类似，测试在边写边改模式中未特别强调，但是在编写代码和修复缺陷过程中举足轻重。

  作为边写边改的项目的软件测试员，需要和程序员一样清醒地认识到自己将陷入无休止地循环往复。
  几乎每一天都会拿到新的软件版本并着手进行测试。当新版本出来时，旧版本的测试可能尚未完成，而新版本还可能包含新的或者经过修改的功能。最后，终于有机会对几乎所有功能进行测试了，并且发现软件缺陷越来越少，这时某人（或者进度）决定该发布软件了。
  在进行软件测试工作期间，边写边改模式是最有可能碰到的。这种模式是软件开发的入门，有助于理解更加正规的方法。
2.3  软件开发生命周期模式

 2.3.3  瀑布模式
2.3  软件开发生命周期模式

2.3.3  瀑布模式

        瀑布模式常常是编程学校所教的第一课，现在已经无处不在。它简捷、精致、很有意义，在合适的项目中效果显著。
       从测试的角度看来，瀑布模式比截至到目前为止的其他模式更有优势。瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以制定精确的计划和进度。测试对象非常明确，在分辨是功能还是缺陷上也没有一点问题。
       然而，这个优点也带来一个巨大的缺点。因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。还记得第1章“软件测试背景”中所讲的软件缺陷修复费用怎样随时间增长吗？我们需要一个模式可以在早期费用不大时执行测试。
2.3  软件开发生命周期模式

  采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来直到准备好。
  关于瀑布模式有三点需要强调：

瀑布模式非常强调产品的定义。注意，开发或者代码编制阶段只是其中单独的一块。
瀑布模式各步骤是分立的、没有交叉。
瀑布模式无法回溯。一旦进入某一步骤，就要完成该步骤的任务，然后才能向下继续——无法回溯。
2.3  软件开发生命周期模式

 2.3.4  螺旋模式
2.3  软件开发生命周期模式

2.3.4  螺旋模式

        螺旋模式的总体思想是一开始不必详细定义多有细节。从小开始，定义重要功能，努力实现这些功能，接受客户反馈，然后进入下一阶段。重复上述过程，直至得到最终产品。
       螺旋模式中包含了一点瀑布模式（分析、设计、开发和测试的步骤）、一点边写边改模式（螺旋模式的每一次）和一点大爆炸模式（从外界观察）。加上该模式发现问题早、成本低的特点，可以算做相当好的开发模式。
        软件测试员喜欢该模式。因为通过参与最初设计的设计阶段，可以尽早地影响到产品，可以把产品的来龙去脉弄得很清楚；并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员地测试一直都在进行，所以最后一步只是一个验证表面所有部分都没有问题。

  敏捷软件开发

  敏捷软件开发的目的是：

通过过程和工具理解个人和交流的作用
通过全面的文档理解运行的软件
通过合同和谈判得到客户的协作
在计划的执行中做出对变更的响应

在一方面有价值的时候，更应评价它在另外一方面的价值

  敏捷软件开发宣言：

个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户个作胜过合同谈判
响应变化胜过遵循计划

XP - Extreme Programming（极限编程）
敏捷软件开发参考书籍
（美）Robert C. Martin著
邓辉 译
清华大学出版社
2003.9