在计算机时代的今天，“软件”已经成为一个并不陌生的词语，软件的发展也随着时间的推移和人们软件知识的拓展，经历了风风雨雨，不断的成长、不断的进步、不断的变化，已经成为小到企业、大到全人类发展的必要因素，软件已经成为一门艺术。

    但任何一件事务都有它潜伏的困难和坎坷，软件工程也不例外。“软件危机”的出现使得人类的思想从“做出软件”转变到“做出好的软件”的历史性转变。大家开始用慧眼看事物，欣赏角度从软件的“能用、可用”转为“易用、好用”。更注重软件的质量，从而一种新的职业“软件测试”横空出世，并加入了软件工程的组织。软件测试和软件开发一样，都是寄生于软件的职业，但和程序员不同的是，程序员是在开发软件，而测试人员则是为了证明软件的可用性、检测软件中存在的缺陷、预防软件的开发前以及开发后的风险。从检查的角度上保证软件的质量。但要注意的是，软件的质量是开发、设计出来的，而不是测试出来的。

    有一位牛人曾经经典的比喻软件测试“测试是一门武功，流程是套路、工具是武器，有简单的花拳秀腿，也有深奥的少林武功！测试好比战争，知己知彼，方能百战不殆！测试好比破案，精心推断，方能柳暗花明！有人说世界不缺少美，而是缺少发现，我看：其实软件不缺少问题，而是缺少发现！以精深的少林武功、用艺术工程的眼光、战争破案的缜密思维去发现软件世界“美”吧！”。 这段比喻非常确切，作为一个软件测试人员，我们必须具备犀利的目光、敏锐的洞察力、广泛的知识面、发散的思维、良好的沟通力、和一颗永不被击垮的心！我们要努力做到不但有不次于编程人员的软件知识，也要具备高于销售人员的三寸不烂之舌，有挑战吧？那么一起来吧！

---

1. 什么是软件测试？

答：软件测试是指使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

2. 软件测试的目的是什么？

答：

1. 证明--证明软件的可用和能用.
2. 检测--检测软件中存在的缺陷.
3. 预防--预防软件的开发前以及开发后的风险.

解决软件危机的途径

软件生命周期的各个阶段工作

软件过程是为了获得高质量软件产品所需要完成的一系列任务的框架，规定了各项任务的工作步骤

通常用软件生命周期模型来简洁的描述软件过程，生命周期模型规定了生命周期的划分的阶段以及各个阶段的执行顺序，因此也成为过程模型。

瀑布模型：（本质是文档驱动的）

瀑布模型的优点：

1. 强调开发的阶段性，各阶段具有顺序性和依赖性

2. 强调早期调研和需求分析，推迟编码实现的观点

3. 质量保证的观点，每个阶段的文档都应在评审之后作为下一阶段的输入

4. 强调测试的重要性

瀑布模型的缺点：

1. 文档驱动，用户无法及时了解产品的情况

2. 依赖早期调研和需求分析，不能适应需求变化

3. 流程单一，开发过程中的成功经验无法用于本产品

4. 测试在后期引入，没有对需求分析，概要设计，详细设计文档进行检验，无法全面的保证质量

5. 组织庞大，人员闲置

瀑布模型的适用范围：需求稳定的产品

增量模型

增量和迭代的概念  例：某软件分为ABCD四个模块

增量：把软件按模块划分，依功能的重要程度定义它的开发顺序

AB——〉CD——〉ABCD

迭代：把软件（全部模块）的基本功能实现之后再进一步完善

ABCD的基本功能——〉ABCD的全部功能

增量模型的优点：

1. 可以尽早的让用户接触到产品

2. 逐步增加功能给与用户逐渐适应产品的时间

3. 可并行开发构件，加快开发的进度

增量模型的缺点：

1. 要求开发人员足够的技术能力来协调软件整体与构件之间的矛盾

并行开发构件有可能遇到不能集成的风险

 

螺旋模型（风险驱动）

螺旋模型沿着螺线旋转，如下图所示，在笛卡尔坐标的四个象限上分别表达了四个方面的活动，即： 　　·制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件； 　　·风险分析──分析所选方案，考虑如何识别和消除风险；  　　·实施工程──实施软件开发 　　·客户评估──评价开发工作，提出修正建议。

沿螺线自内向外，每旋转一圈便开发出更为完善的一个新的软件版本。例如，在第一圈，确定了初步的目标、方案和限制条件以后，转入右上象限，对风险进行识别和分析。如果风险分析表明，需求有不确定性，那么在右下的工程象限内，所建的原型会帮助开发人员和客户，考虑其它开发模型，并对需求做进一步修正。客户对工程成果做出评价之后，给出修正建议。在此基础上需再次计划，并进行风险分析。在每一圈螺线上，风险分析的终点做出是否继续下去的判断。假如风险过大，开发者和用户无法承受，项目有可能终止。多数情况下沿螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。

螺旋模型的优点：

1. 强调风险

2. 强调阶段质量

3. 提供纠错的机会

螺旋模型的缺点：

1. 每个阶段都要提出被选方案，进行风险分析，研发周期长，效率低

2. 必须要转业的风险分析人员的参与

螺旋模型的适用范围：内部开发的大型项目

 

RUP流程（以架构为中心迭代流程）

RUP流程的优点：

1. 任何功能开发后就进入测试过程，及早进行验证

2. 早期风险识别，采取预防措施

RUP流程的缺点：

1. 需求必须在开始之前完全弄清楚，否怎有可能在架构上出现错误

2. 必须有严格的过程管理，以免使过程退化为原始的试-〉错-〉改模式

如果不加控制的让用户过早接触没有测试完全，版本不稳定的产品可能对用户和开发团队都带来负面的影响

需求评审

本节相关概念：

客户与用户：客户是消费的，用户可能是客户的职员，或亲戚（随便理解了）

原始需求：

针对项目类软件：指的是需求分析人员通过与最终用户或客户进行需求调研获得最初的文档。

针对产品类软件：指的是通过市场调研人员分析潜在用户的使用需求经过整理分析后形成的最初产品需求。

需求规格说明书（SRS）---software requirement specification：原始需求经过分析得到说明书经过基线化获得的产物。

                 目的：A在客户和开发者之间达成一致

                       B为编制计划和成本计价提供基础

                       C为确认和验证提供一个基础（验收测试）

       D便于移值
                    写作要点：（每个项目其实对应着相关测试类型 ）

1项目介绍

                        2产品环境介绍

                        3 软件功能

                        4用户特征

                        5假设和依赖关系

                        6功能需求

          7功能需求—简单介绍

          8功能需求—输入

                        9功能需求—处理

                        10功能需求—输出

                        11性能需求

                        12用户接口

                        13软件接口

                        14硬件接口

                        15标准符合度

                        16硬件约束

                        17技术限制和本地化

                        18需求分级

关注点：

需求只强调做什么，而不是如何做。概要说细设计中关注如何做。

 

必要性：

在国内许多开发人员和分析人员都不喜欢编写需求规格说明书，而用户也是既不关心需求规格说明书是否已经完成，也不关心需求规格书是否恰当地表述了用户的需求。大家所关心的仅仅是系统何时能够做出来，而这最终导致的一个结果是系统不断被除数修改，各种Bug不断出现，好像没有个尽头。其实任何文档形式的需求都是一个模型或一种描述，我们要保证所有的风险承担者在描述需求的那句词上能够达成一致的意见，这可以减少后期不断修改甚至一切到头来的麻烦，从而缩短了研发的进度同时保证质量，节省了不少的成本。

 

需求的分类：

 

显示需求：需求分析人员在用户或客户那里获得最早的软件信息。简单的说就是用户眼里未来软件的影子。

           主要组成部分：软件功能方面的特性（根据客户软件知识而定，不要以貌取人）

隐式需求：需求分析人员从用户的显示需求中分析或客户确认得到用户发现不了软件产品条件和能力。

           主要组成部分：软件的可靠性、易用性、效率、维护性、可移值性方面的性能（详细参考软件质量模型）

如研究人员不去关注隐式需求，客户也不会认帐的。你说我都是按你要求做的，客户你做出这样的东西怎么能用啊。最终也是通不过验收测试的。

需求工程：

                         需求工程

需求开发：                                         需求管理：

  需求获取                                           需求分配

  需求分析                                           需求评审

  需求定义                                           需求基线

  需求验证                                           需求跟踪

需求变更

需求获取：

方法：A调查问卷  B专家指导 C 企业实地实践 D 与用户/客户沟通（不一定单选）

注意事项：需求人员要补充相关方面的知识水平站在比客户还高的行业角度上去考虑问题，并给用户提解决方案。不能向软件方面知识不强的客户问专业方面的问题，要是部他问解决方案，一定要有备选答案，不然，他哪知道，这样用户开始会怀疑研发方的水平地。

成果物：原始需求（需求说明书）

需求分析：

目的：将需求规格化

规格化的过程：1 明确每个需求输入参数

2 明确每个需求处理处理

3 明确每个需求的输出

4 明确相关接口

5其它隐式需求

6相关的约束条件

成果物：需求规格说明书SRS

需求定义：

主要是指经过需求分析规格化过程后，将它形成一个正式的需求说明书SRS。

需求验证：（开发方与客户）

目的：和客户共同明确统一的需求，为后续的需求管理奠定基础。

需求分配：

目的：产生工作任务书，让工作明确划分。

对象：有公司内部人员，或其它公司人员。（如外包公司）

需求评审：

流程：把内部的SRS（经过需求定义）进行一次内部的确认，提交用户进行需求验证。（需求评审流程详见同行评审）

评审要点：

1是否所有的分配需求都在SRS中体现？

2在SRS中定义需求时，是否避免使用那些会引起歧义的术语，诸如也许、可能等，每条需求都清晰无歧义？

3是否在SRS中描述了软件使用的目标环境，指明并简短描述了软件要什么及不做什么？

4是否在SRS中描述了是否在SRS中描述了软件使用的目标环境，指明并简短描述了目标环境中其它相关软件产品/子系统/模块？

5是否每一个具体需求都有唯一的编号？

6每一个需求是否切实可行、可测试、前后一致、彼此不冲突？

7是否在SRS说明了对每个输入的验证措施，并描述了每个输入的属性如：度量单位、边界值、时序要求等等？

8是否在SRS中说明了对每个输入的处理？

9是否在SRS中说明了第个输出项是如何输出的，并且描述每个输出的属性如：度量单位、边界值、时序要求等等？

10是否在SRS中描述了软件所有的性能需求？

11、是否性能需求的描述能通过测试来进行验证?

12、是否在SRS中说明了所有对系统可能的约束？

13、质量属性是否以可测量或可验证的术语进行描述？

14、是否要SRS中描述了系统中与其它子系统、模块或硬件设备的相关接口？

15、是否对每个接口的描述足够清楚，实现时不需更多解释？

16、是否在SRS中描述了与操作系统的接口？

17、是否在SRS的附录中记录了分配求可行性的分析结果？

18、是否项目SOW文档所对应的分配需求都在RTM中体现？

注：原始需求也从这些方面入手，这项不是死的，也是根据质量模型扩展来，根据不同项目从不同的质量特性入手。

评审意义：通过需求评审，可以尽早发现缺陷，对于发现的缺陷可以及时修复，避免遗留到后继阶段，以免扩大，造成更大的损失，在需求阶段对修复投入的成本是最低的。

注意事件：1为了保证需求评审的并行果，必须确保参与评审人员技术水平；

评审工作完成，一定要做好后继的需求跟踪，当需求发生变更时，要重新对而求进行变理和评审。不然评审就毫意义了。

2要根据项目特点对评审流程以及评审参与人，评审时间进行调整和裁剪。

需求基线：

评审完成后，把SRS变为受控状态（详见配置管理）

需求跟踪：

需求的实现和验证和跟踪

开发方面：对需求逐步实现

测试方面：对需求逐级验证

需求跟踪涉及到的配置项：

 

配置项：是软件生命周期个阶段产生的程序、数据、文件、环境

变更控制：

通过需求的跟踪建立RTM可以进行变更控制，RTM没有完成时，需求变更所设计的变更项比较少，这也就测试工作为什么要在早期进行的原因了。

描术方法：

通过输入、输出来说明（自然语言）

使用规范化的模型方法（UML）

使用电子表格

使用代表性的例子

第二种是现在通用的表达方式。其UML详见ROSE工具

 

需求阶段的角色和职责：

 

软件开发项目经理：

带领项目组分析审核工作任务书；

带领项目组与系统工程师（需求分析人员）进行需求交流并进行分析和文档化

组织SRS文档评审

组织需求跟踪

软件开发人员：

完成SRS文档；

完成需求跟踪

参加SRS评审

根据SRS评审专家意见，修改SRS文档

参加系统测试计划的评审

软件经理

在SRS评审结束后，批准SRS文档

QA

    

监督项目组遵循需求管理流程

参加相关文档评审（关注过程）

保证相关组参加文档评审

CCB（需求变更委员会）

控制需求的变更

软件测试经理

参与开发人员的软件需求分析，提出可测试性需求

组织人员参与SRS的评审工作

软件系统测试计划写作

组织系统测试计划评审

组织本阶段测试需求跟踪

软件测试工程师

参与SRS评审工作

协助软件测试项目经理完成软件系统测试计划写作

参加系统测试计划的评审

完成本阶段测试需求跟踪

*各个公司人员的任务不一样，但也要有具备这些工作的责任人

在这里总结一下测试人员参与需求分析的具体工作：

A方法途径：测试人员与需求分析人员共同负责原始需求诉获取。或

测试人员依据需求分析人员获取原始的需求相关资料，通过一定的分析过程，来明确需求中的相关内容（显示需求、隐式需求）。

B如何分析：通过与用户和需求分析人员进行讨论和沟通。

依据相关的需求资料设计UML与用户和需求认员进行确认和讨论。

C需求分析确认：要保证需要每一个需求的可测试性。（构造各种不同的输入，依据需求明确的处理过程分析预期输出。如某一条件不具备，则需求是有问题的）

要保证所有需求都被文档化

协助需求分析人员整理需求文档

需求项

定义：根据工作任务书（客户需求）的规格，把任务书中的任务（客户需求）分解为可以实现的符合要求的具体的需求项，需求项最终落实到需求文档中（SRS）

命名方式：产品编号—SRS—需求类型句—XXX

如：CALC——SRS——FUNC——ADD—001，表示计算器十进制加法功能需求。