1，V模型的局限性在于没有明确的说明早期的测试，不能体现“尽早的进行测试”的原则；且软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段结束，才能进行下一个阶段，这样就无法迭代，其活动的执行容易受到上游活动的影响，且不易调整。

2，H模型中软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。

3，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。

4，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明

http://www.51testing.com/?action_viewnews_itemid_102474.html

 

引用以下别人的文章，主要是有个记录，应该可以吧？

我一直比较困惑的一个问题就是如何把各种测试用例的设计方法融入到系统功能黑盒测试中，通过把功能点和功能测试点的概念的区分可实现。

比如，某个功能点，可以分出多个功能测试点，而功能测试点可以更进一步的用不同用例设计方法来设计测试用例。

当然这种方法会产生非常多的测试用例，但这些测试用例应该说指导性很强。

-------------------------------------------------

功能点覆盖是在测试工作中经常提到的一个东西。

　　很多测试人员为了对功能点进行覆盖费劲了心思,可惜的是当他们将达到功能点覆盖100%的,系统,仍然不断出现问题,于是领导的责备,用户的冷眼,开发人员的讥讽就全来了,这个时候测试人员唯一的解释就是测试不是万能的,不可能发现所有的问题。

　　这个时候别人一问:你的功能点不是100%覆盖了吗?为什么还有错误没有发现,于是测试人员哑口无言了.

　　其实这个问题的关键问题在于如何功能点这个概念.

　　功能点的概念其实从开发中来的,在系统开发的时候一般会分层,最上边的的是系统,然后是子系统、模块、功能。一般来说功能是一个系统中最小的单位，这个概念被引入到了测试中来，于是出现了功能点覆盖的概念。

　　功能点覆盖一直一个没有明确的概念，这个概念很容易迷惑测试人员，如何算功能点覆盖了？

　　功能一般是系统完成一个具体的操作，比如在人力资源管理系统的中人员基本信息模块中有一个增加新人员信息的功能。

　　我们在对这个功能进行覆盖的时候，一般会考虑几个方面

　　1.合法数据是否可以加入到系统中

　　2.非法数据是否可以检验出来，并给出相关提示

　　3.其他操作约束是否可以满足，

　　如果这些方面都要测试到，那么用一个测试用例是不可能覆盖的，

　　这里有问题了。

　　我就写了一个测试用例是否就算覆盖这个这个功能？

　　我用100个不同的测试用例进行测试是否算覆盖了这个功能？

　　我用里10个测试用例发现了一个bug和用200个测试用例发现了一个bug ，对系统来说是否有什么不同？

　　所以个人认为在这个时候应该引入一个概念就是功能测试点的概念

　　我们在需求报告或者概要设计报告中很容易总结出系统所有的功能点，这些功能点是开发人员提供给测试人员的，那么测试人员要做什么？就是确定每一个功能（点）有多少个地方需要测试，而这些点就是功能测试点，

　　用来衡量测试人员工作效果的就是对功能测试点的覆盖

　　这样可以很好解释，测试用例的数量和产品质量之间的关系。

　　比如功能（点）覆盖达到了100%，但功能测试点的覆盖只有10%，说明测试强度不够，即使所有的功能都涉及到了，但测试强度还是很小的，产品的质量同样是没有保证的

　　同样的是，一个功能点我用了10测试用例发现一个bug，和用1000测试用例发现一个bug，虽然从bug数量上来说是一样，但后边一种对代码覆盖率要大（按照测试用例的方法来编写测试用例），所以，说明第二个系统可靠性比第一个系统要高。

　　将功能点和功能测试点区分开来还有一个好处，就是在统计测试人员工作效果的时候比较好，

　　对于测试人员的工作成绩不能单纯地以发现bug数量来说明，否则容易造成偏颇，通过功能点覆盖和功能测试点覆盖率来分解统计可以比较精确反映测试人员实际工作量

　　软件项目开发是个分工明确的系统工程，不同的人员扮演了不同的角色，包括部门经理、产品经理、项目经理、系统分析师、程序员、测试工程师、质量保证人员等。可见，软件测试工程师只是软件项目开发中的一个角色而已。

戏剧舞台上的生、旦、丑是不同的角色，其表演方式具有明显的特征，这是由于角色决定的。同样，软件测试工程师的角色，在软件项目开发中也存在如何定位和表现自身的行为和责任的问题。 
     此处讨论测试工程师的角色并非毫无意义。须知，角色不明，责任不清，行为就失去了参照目标，结果就可能很不理想了。轻则降低了工作质量和效率，重则被视为工作能力低下，可能要退出软件项目组的舞台了。
软件测试工程师承担的任务
　　角色决定工作内容和承担的任务。测试工程师的角色应该承担什么任务呢？这没有统一的答案。因为，这与软件公司的规模，软件项目管理制度，公司领导和项目经理的管理风格，以及具体软件项目自身的特点有很大关系。而且，测试工程师也有普通和高级之分。转自www.51testing.com
　　笼统的答案列举如下：
　　设置软件测试环境，安装必要的软件工具。
　　运行软件，发现和报告软件缺陷或错误。尤其需要快速定位软件中的严重错误。
　　对软件整体质量提出评估
　　确认软件达到某种具体标准
　　以最低的成本，最短的时间，完成高质量的测试任务
　　在这其中，最重要的是要明确，程序员的责任和目标。在执行任何具体测试任务前，都要在项目组内对于责任和目标达成共识，以免带来后续工作的相互推诿。
提高测试质量的要诀
　　另外一个值得注意的方面就是工作效率和质量，或许高级测试工程师与普通测试工程师的主要区别在于高级测试工程师可以更快地发现更多软件中的严重错误。对此，有什么可以借鉴的诀窍吗？请尝试以下方法，保证不会使您失望。
　　首先测试程序的核心功能，然后测试辅助功能。
　　首先测试功能，然后测试性能。
　　首先测试常见情况，然后测试异常情况。
　　首先测试经过变更的部分，然后测试没有变更的部分。
　　首先测试影响大的问题，然后测试影响小的问题。
　　首先测试必须测试的部分，然后测试可选或没有要求测试的部分。
软件测试工程师是项目团队中的服务员
　　需要强调的一点是，无论你是多么高级的测试工程师，都要明白无论测试需要的工具多么复杂，测试步骤多么冗长，测试工程师在软件项目开发中始终都是扮演服务员的角色，这是由测试工作的特点决定的。任何服务都有被服务对象—客户，软件测试工程师的服务对象有哪些呢？
　　最重要的客户是软件的用户。测试工程师需要站在客户的使用和需求角度测试软件，报告问题。
　　项目经理也是客户。测试工程师需要报告测试工作进度和发现的问题，尤其是严重的问题。
　　程序员是最经常打交道的客户。为了便于程序员重复报告的错误，尽量提供良好的软件问题报告，以便程序员可以更快的修复软件错误。
　　技术文档工程师、市场开发人员和技术支持工程师也都是测试工程师的服务对象。
软件测试工程师避免犯的几个错误
　　前文已经指出测试工程师应该明确角色，明确任务和责任。知道哪些是自己份内的事，哪些是不属于自己的事。一定要尽最大努力完成份内的事，不要做不属于自己的事情，以免弄巧成拙。
　　为了更好的扮演软件测试工程师的角色，尽量避免犯下面的错误：
承诺完成测试的软件没有质量问题
　　软件测试只是保证质量的一种方法，软件测试工程师的工作不会直接提高软件质量，因为绝大多数软件错误都需要程序员修复。软件测试只能证明软件存在错误，不能保证软件没有错误，不可能找出全部软件错误。个人的能力和对质量的影响范围很小，软件质量的提高要靠软件项目团队全体成员的共同努力。
承担软件的发布权利
　　不要因为软件中存在还没有修复的错误，而试图提出更改软件发布的计划。也不要认为已经完成了测试计划，自己决定可以发布软件。因为，改变软件发布计划可能要失去进入市场的良机和很多客户，对此造成的经济和公司市场的损失将不是测试工程师能够承担的。另外，软件发布后，如果用户发现了新的软件错误，公司领导或项目经理可能将过错加在软件测试人员的头上，因为他们同意发布软件。通常软件发布的权利由产品经理、项目经理、测试经理、市场经理共同集体讨论决定。
扮演过程改进成员的角色
　　软件测试工程师必须报告错误，有时也要分析错误的类型、特征和产生错误的原因。但是，不要主动提出改进软件过程的具体改进措施，更不要直接干涉程序员的工作方式，以免出力不讨好，影响今后的愉快合作。软件过程改进的方法是软件质量控制部门的事情，这是他们的本职工作。

1.         项目管理的技巧：管理一般分为目标管理和手段管理，目标管理是利用组织内的文化优势来进行管理，而手段管理则是采用组织内的权利规范来进行管理；这里介绍的是手段管理

1)        经验的积累：从失败中、错误中学习，不仅仅是自己的失败和错误，也包括别人的失败和错误；分析其他人的失败和错误，需要获得比较充分的信息才能比较接近实际情况，才能分析彻底，而不至于一叶障目

a)         后期诊断分析（PPA，Post-Performance Analysis）：通常这种方法是在软件开发的后期，目的是为了找出问题发生的原因，并且讨论分析如何改进流程来防止这个问题再次发生

b)        前置问题列表（QP，Questionnaire Preparation）：先将所有的疑问和问题及时列出，为了找出这些问题的解决方法而制作的问卷进行调查，有些问题可以直接采用询问的方式；该方式很适合管理经验值不足的人员使用。至于如何准备这些问题列表，基本可以从管理事务的四大项目来着手：资源的调整、设置处理的优先级、监督事务、检讨审查

c)        管理事务的四大项目：

                         i.              资源调整：包括人力资源、软件资源、硬件资源、环境资源以及预算资源

                       ii.              设置处理事务的优先级：做错决定让人失望，但不作决定让人绝望；不要让手下跟着盲目努力

                      iii.              监督事务：进行监督无非是掌握流程进度，如果进度落后的话，就需要找出问题所在，并且可能再次进行资源上的调整；监督事务有两种方法，主动出击和自动反馈，大部分情况是两者并用

                     iv.              检讨审查：通过时候的检讨来分析问题，找出解决方法，是增加自我经验值得最好时机

2)        工作分割和单位化：一种方法是分化后逐一征服（Divide and Conquer）；不过这种一维的工作分割方式对于软件开发来说稍显不足，这时候就要采用WBS（）的工作风格方法来做规划。

a)         分割的模式：

                         i.              Project（项目）：产品需求、产品设计、程序编写、软件测试，产品需求继续分为市场调查、市场分析、编写、审查等

                       ii.              Product（产品）：自动扫描、线上更新、使用介绍、自动侦错

b)        分割的方法

                         i.              自顶向下的结构性方法：结构完整

                       ii.              自底向上的组合型方法：信息较多，需要整理

3)        分割工具

a)         REDC：Review（审查）、Evaluation（评估）、Dsicussion（讨论）、Conclusion（总结）

                         i.              Review：目的是对所要理清的议程项目做一个初步的审查，先锁定未来所要讨论的方向；Review的方式一般有3种，浏览性的审查（Walkthrough）、阅读性的审查（Reading）和设立审查机制（Inspection），这里所采用的是Reading和Workthrough这两种方式；建议将Review和会议分开处理，最好是会议前3-4天将所有要讨虏难得议题法E-mail给所有与会人员，

                       ii.              Evaluation：先给出几种方案，然后对方案进行评估

                      iii.              Discussion：讨论方案，给出结论；要注意讨论的方式和控制讨论现场的局面，不要偏离主题，不要讨论已经否定了的问题上

                     iv.              Conclusion：最后一定要得出结论，不然就是一次无效会议，必须通过再一次的会议来讨论相同的问题

b)        SWOT：策略分析法

                         i.              Strengths（优势）：内部要项，常量；举例如下

1.         开发和测试人员的经验充足

2.         人员之间的工作默契良好

3.         人员士气并未受损

4.         修改部分只占整体的15%

5.         不需要额外配置测试环境

6.         所准备的软硬件不需变更

                       ii.              Wesknesses（劣势）：内部要项，常量；举例如下

1.         人员并不熟悉新增的功能所需的开发技术及测试技术

2.         修改需要时间

3.         测试工具也需要修改

4.         相关文件也需要修改

5.         产品需要重新集成

6.         需要再次进行回归测试

7.         需要再次进行系统测试

                      iii.              Opportunities（机会）：外部要项，变量；举例如下

1.         更改组件符合客户需求

2.         产品功能更加完整

3.         符合市场策略

4.         公司高层全力支持

                     iv.              Threats（威胁）：外部要项，变量；举例如下

1.         经销商不满产品推出延误

2.         竞争对手先行抢先推出

3.         市场环境变动

4.         委外厂商无法配合

4)        建立检查单（Check List）：Product Release Check List

a)         P1到P3的bug是否已经解决？

b)        是否准备好所有的程序列表（安装前和安装后）？

c)        所有程序的版本、时间、日期及其他属性是否正确？

d)        程序安装完后的初始化资料是否是最新的资料或设置？

e)         程序内部所有有关版本的信息是否已经更新？

f)         所建构的程序是否为Release版本而不是Debug版本？

g)        所有的测试资料是否已经从程序内部移除？

h)        Help档案的内容是否已经更新？

i)          相关的文件是否已经准备完成？

j)          Readme文件的内容是否已经更新？

k)        GM（Golden Master）版本的程序是否经过防毒软件的扫毒测试？

l)          所制成的母片是否进行了安装测试及移除安装测试？

m)      是否在完全初始化的操作系统下进行过安装及移除安装测试？

2.         QA人员的角色与责任：人员管理是项目管理中最难的一项

1)        组织结构介绍

a)         功能式组织结构：适用于规模较小的企业，管理层直接管理财务、信息、业务、管理、工程等职能部门，各职能部门各自管理

b)        矩阵式组织结构：适用于跨国企业、大型企业，可以应对横向沟通较多的问题；同一个人员接受多个部门或管理者的管理，比如测试人员或测试leader在项目组中要接受项目经理的管理，同时要接受测试manager的管理

c)        项目式组织管理：项目经理全权负责项目组内的人员、工作安排，甚至奖金发放；该种方式可能会导致资源利用不充分，各项目风格不统一等

d)        对软件公司而言，要采用何种组织结构出了要考虑管理人员的能力之外，还要考虑公司内部人员的数量、业务规模及资源分配等内容。除了慎重选择组织结构之外，让整体组织运作顺畅的要点取决于管理能力和规划能力

2)        软件开发人员的组织结构

a)         项目经理或产品经理：Project Manager或Product Manager

b)        QA Lead：

c)        Design Lead：

d)        Requirement Lead：

e)         … …

3)        QA人员的组织结构

a)         以产品或项目划分：为产品或项目分配测试人员，由这部分测试人员完成所有测试；缺点是人员进入后的变动困难

b)        以专业项目划分：根据测试人员的专长来参与产品或项目的部分测试；缺点是容易遗漏测试内容，并且测试人员的责任心不强，没有归属感

c)        以产品划分的建议事项：以项目或产品方式划分时，要让测试人员轮替进入项目组，把产品知识能够分散到所有测试人员身上，避免人员流失引起的风险

d)        对于任何一种方式，都必须形成尽可能多的文档，文档要有实用性，见效人员流动带来的风险

4)        QA人员的角色扮演

a)         QA Engineer（QA 测试人员）：好的QA测试人员必须由追根究底的精神，还需要有良好的沟通能力

                         i.              发现Bug

                       ii.              证明Bug

                      iii.              QA人员的知识更宽，而开发人员的知识更深

b)        QA Lead（QA组长或主任）：除了拥有QA Engineer的技能之外，还需要具备汇总与组织能力，对进度的掌控能力；处理事务的优先级上，也要有策略性的思考

                         i.              编写测试计划

                       ii.              统合软件测试用例

                      iii.              配置测试环境<

1.         测试计划

测试计划是对测试的范围、方式、资源及测试所需的时间做出一个预先的指定方针，而计划的内容必须包括进行测试的项目、产品功能的测试、所需进行的测试工作、每位测试人员所应该负责的测试工作，以及与测试有关的风险。如果再加上测试计划的目标及测试的重点所在，测试计划的定义就更加完整了。

1)        编写测试计划的目的

a)         帮助软件测试进行的更顺利：对软件测试来说，它的风险包括：项目终止、测试中断、设计规格不断的变化、人员不足、人员流失、人员测试经验不足、测试进度不足、测试进度被压缩、软件硬件资源不足、软件硬件资源流失、测试方向错误，以及其他可能会影响测试过程的种种议题。这些都是不可预期的风险。对测试计划而言，凡是会影响到测试的议题，最好都纳入测试计划的内容中，这样除了可以让测试过程更加顺畅外，对管理而言也是一大帮助。

b)        明确测试方向、促进彼此沟通

c)        让软件测试更易于管理：测试计划中包含了两种重要的管理方式：一个是WBS（Work Breakdown Structure，工作分割结构），另一个是DC（Divide and Conquer，分化后逐一征服），这都是管理上的技巧。对软件测试计划来说，WBS就是将所有的测试工作一一单位化，这有利于测试人员的工作分配。在进行软件测试时，管理人员可以利用DC技巧来监督过程，掌握测试进度。

2)        计划的种类

a)         STP（单一文件测试计划）

就是将测试计划所有的议题编写在同一份文件上

b)        MTP与DTP

MTP（主要方针测试计划）与DTP（详细运作测试计划），这两种计划通常在一起使用。基本上MTP的内容是将测试分成不同的阶段，对于每个阶段规划出概略的测试方针，至于各阶段的详细测试计划则编写在DTP内，因此通常一个MTP会伴随好几个DTP。较大的、周期较长的项目、人员组织复杂、开发模式复杂的项目更能体现出测试计划的重要性和测试计划更新的必要性

c)        另外一种划分方法可分为：做样子的测试计划（BTP，Beautiful Test Plan）和有帮助的测试计划（UTP，Useful Test Plan），BTP可以让人升官发财，但被称赞的永远是UTP

3)        计划的纲要：5W（who、how、when、where、what）

2.         其他文件准备

1)        软件开发所应准备的文件类别

a)         销售用途

                         i.              White Paper：产品白皮书

                       ii.              Product Road Map：产品未来方向报告

                      iii.              Performance Report：使用性能报告

                     iv.              Compatibility Report：兼容性报告

                       v.              Product Presentation Files：产品演示文稿说明

b)        设计用途

                         i.              Product Requirement Document：产品功能需求，提出产品所要具备的功能

                       ii.              Architecture Document：产品基础设计文件，产品的底层设计

                      iii.              Design Spec. Document：产品设计规格，产品的详细规格设计内容

c)        产品用途

                         i.              Brochure：产品目录，介绍产品的文件

                       ii.              Readme File：自述文件，伴随产品一同发行的文件

                      iii.              Help File：帮助文件

                     iv.              User Manual：使用手册

                       v.              Product Licensed File：产品授权书

d)        客服用途

                         i.              Know Issues List：已知问题列表

                       ii.              FAQ：常见问题解答

                      iii.              Survival Guide：危机处理指南

                     iv.              Trouble Shooting：问题诊断指南

e)         测试用途

                         i.              Test Plan：测试计划

                       ii.              Test Case：测试用李

                      iii.              Bug Report：问题报告

                     iv.              Testing Report：测试结果报告

                       v.              Test Tool User Manual：测试软件使用手册

                     vi.              Test scrīpt：测试脚本（测试步骤），基本的测试程序指南

2)        准备文件的目的

a)         知识的交接

b)        知识的管理

c)        减少重复的工作

d)        促进人员彼此的沟通

3)        如何准备工作

a)         准备工具：比如word、excel、visio等

b)        定义文件形式：定义文件的编写形式，包括内容的编排、内容的专业程度和所采用的字句

c)        搜集资料

d)        分析资料

e)         组织文件

4)        测试人员应准备的文件及模版

a)         Bug Report用例

                         i.              Daily Bug Report：重点在程序bug的状态还是处于open的情形，所代表的意义是目前整体项目修改bug的进度是什么，还可以了解每天新增的bug数量的多少

                       ii.              Weekly Bug Report：重点在项目在本周内所发现的重大问题的原因及解决方法，通常这些重大问题会影响到项目的开发进度和质量优劣

                      iii.              Bug Repor要素：

1.         产品名称（Product Name）

2.         版本（Version）

3.         建构版本（Build）

4.         日期（Date）

5.         Bug的总数量（Overall Bug Number）

6.         根据优先级分配的Bug数量（Bug Number by Priority）

7.         新增的Bug数量（New Submitted Bug）

8.         等待处理的Bug数量（Remain Open Bug）

9.         已经解决的Bug数量（Bug Closed ）

10.     Bug的ID号码（Bug ID）

11.     Bug的名称（Bug Title）

                     iv.              FAQ用例

                       v.              Test scrīpt用例

                     vi.              Performance Test Report用例

                    vii.              Compatibility Test Report用例

1.         配置测试环境

1)        测试环境的快速变迁：软件版本不停增加、新系统不断推出等各方面原因

2)        配置测试环境的困难点

a)         资源不足

b)        操作系统的更新

c)        硬件设备的更新

d)        新的软件不断的推出

e)         客户端复杂的使用环境

3)        如何配置测试环境

a)         环境设立建议

                         i.              将操作系统、其他软件、硬件规格一一列出，为项目经理判断作参考

                       ii.              将测试环境作等级区分，使用最多的环境，其次的环境，使用最好的环境

b)        硬件环境建议

                         i.              至少要有一套低级与高级的设备

                       ii.              所有设备所采用的硬件厂牌最好相同

                      iii.              硬件供货商必须提供产品保证及服务

                     iv.              考虑以租借方式替代购买高级的服务器

c)        安装软件建议

                         i.              调研用户安装了其他什么软件

                       ii.              根据用户的工种来判断安装了什么软件

                      iii.              先列出基本需求软件清单，如office；再到提供下载的网站下载最受欢迎的前20名的软件

d)        操作环境建议（从windows98到windowsXP共有43个版本）

                         i.              利用系统映像备份软件

                       ii.              虚拟操作系统：根据经验，对功能面测试的效果相当不错，可以不必质疑它的准确性

e)         专业管理人员

4)        测试环境配置需求清单

a)         硬件规格

b)        所需安装软件

c)        操作环境版本与语言

d)        网络环境

e)         机器数量

f)         测试开始与结束日期

5)        测试环境与外界真实环境

a)         模拟外界真实环境相当困难

b)        台湾：中小企业较多，因此可能一台服务器有可能安装相当多的软件来处理许多事务；日本，组织结构一般是金字塔形式，譬如一台Server有可能管理4000个Clients；美国，企业并购相当普遍，所以IT环境相当复杂；美国企业在采购时，为了分散风险，有时候会同时采用不同软件上的产品。这样更让他们的使用环境处于一个混乱但可行的情况下

2.         测试用例设计（test cases design）

1)        测试用例是将软件测试的行为活动作一个科学化的组织归纳

2)        为什么需要测试用例

a)         从管理层面：系统化管理测试工作

b)        从实际测试层面：测试工作有依据、有记录

3)        测试用例的种类

a)         边界测试用例：容易产生缓冲区溢出的问题

b)        功能测试用例：功能测试用例一般占测试用例的50%-80%

                         i.              功能是否符合需求

                       ii.              功能是否完整

                      iii.              功能是否有作用

                     iv.              功能是否无错误

c)        设置测试用例：也就是组件测试用例，配置测试用例，主要是针对配置项、配置文件等的测试

d)        状态测试用例：状态，也就是使用控制流程；测试人员必须模拟使用者的使用情境来进行软件测试

e)         压力测试用例：测试使用程序在承受某种程度的压力下是否能依然运行正常，压力测试与性能测试的最大不同点在于压力测试时找出程序在合理的临界点边界内的运行情形，而性能测试的目的是提出测试数据评比

                         i.              压力情境的设置可以根据以下几个项目来考虑

1.         cpu处理速度

2.         cpu使用量

3.         安装磁盘空间

4.         物理内存使用量

5.         虚拟内存使用量

6.         使用者数量

7.         处理资料量多少

f)         错误处理测试用例

g)        回归测试用例

h)        其他测试用例

                         i.              使用界面测试用例

                       ii.              发行验证测试用例

                      iii.              验证测试用例

                     iv.              性能测试用例

1.         基本性能测试用例：产品本身在不同的使用状况下进行测试并记录下数据

2.         网络带宽使用性能测试：产品本身在不同的使用状况下进行测试并记录下网络使用带宽数据

3.         比较性能测试：对比同类软件和本软件的性能，并记录数据

4.         设计性能测试用例与压力测试用例最大的不同在于，性能测试用例的设计以能够提供数据报告为出发点，例如，程序在正常的使用情况下，内存使用量有多少，而在处理大量资料的情况下，内存使用量是多少。需要记录的内容参考压力测试

                       v.              兼容测试用例

1.         操作系统测试

2.         软件兼容测试

3.         硬件兼容测试

4)        测试用例设计技巧

a)         设计方法

                         i.              按测试类型组织测试用例，比如功能测试、边界测试、错误处理测试等；功能测试中包括不同模块，比如安装功能测试、登录功能测试、卸载功能测试

                       ii.              按测试功能来组织测试用例，比如安装、登录、卸载；安装测试用例中就包括功能、边界、设置、状态等测试

                      iii.              作者一般使用第二种方式

b)        设计技巧

 

3.         测试工具

1.         软件测试

1)        软件测试具有组织性、步骤性和计划性的特点

软件测试仪测试形态分类，可以分为建构性测试、系统测试以及专项测试

a)         建构性测试又称为开发测试，一般包括，单一步骤测试、尝试性测试、单元测试、组建测试、集成测试

b)        系统测试通常称为QA Testing，测试人员通常为专业的系统测试工程师，系统测试是针对系统急性测试，这包括所应支持的软件、硬件、操作系统以及所应集成的第三方软件；包括集成测试、前哨测试（冒烟测试）、功能测试、设置测试、发行测试、验收测试

c)        专项测试，就是需要额外的人力及资源来进行的测试活动，有时也需要根据产品的本质特征来安排或略去专项测试，如所开发的产品属于pda软件的话，进行压力测试就显得多此一举了。专项测试一般包括回归测试、压力测试、兼容性测试、性能测试、Alpha和Beta测试

2)        测试技术

a)         准备工作：一般包括测试计划、测试用例等

b)        执行方式：人工执行、自动化执行

c)        测试方法：黑盒测试、白盒测试，黑盒测试以测试广度为主，白盒测试以测试深度为主

                         i.              白盒测试也成为结构性测试，有时候涉及到内部机密的问题这种测试一般都在公司内部进行，很少委托给其他公司或个人。严格来说，白盒测试有两大方面：数据流面和控制流程面，数据流面就是数据进出系统的程序所经过的流程，控制流程面就是测试程序在执行过程中每个阶段的流程

1.         语句覆盖：每一个程序语句都被执行到

2.         分支覆盖：每一个程序的进出点都至少被执行过一次

3.         条件覆盖：分支覆盖再加上所有的判断情况都至少被执行过一次

4.         条件组合覆盖：不同的组合的判断情况都至少被执行一次

                       ii.              黑盒测试着重于软件的功能面，也成为功能测试；可以委托其他机构去执行

1.         测试用例覆盖：test cases的每一个用例都被测试过

2.         输入覆盖：所有输入都必须考虑到

3.         输出覆盖：所有输出都必须考虑到

2.         软件缺陷的种类

1)        Bug的历史：bug，debug

2)        造成软件缺陷的原因：

a)         程序编写错误

b)        编写程序未按照规定

c)        软件越来越复杂

d)        开发人员的态度

e)         测试人员的经验与技巧不足

f)         沟通上的问题

g)        需求变更太过频繁

h)        进度上的压力

i)          管理上的缺失

3)        缺陷的种类

a)         功能不正常

b)        难以使用的软件

c)        未作良好规划的软件

d)        所提供的功能不足

e)         与使用者的互动

f)         使用性能太差

g)        未作好错误处理

h)        边界错误

i)          计算错误

j)          使用一段时间所产生的错误

k)        控制流程的错误

l)          在压力下所产生的错误

m)      不同硬件设备所产生的错误

n)        版本控制不良所产生的错误

o)        文件的错误

3.         问题跟踪系统：缺陷跟踪系统

1)        实施目的

a)         质量无法控制

b)        问题无法量化

c)        重复问题接连发生

d)        解决问题的知识无法保留

2)        问题的生命周期

a)         测试人员找到问题

b)        制定问题的拥有者

c)        开发人员检查问题

d)        如果是问题，修改；如果不是问题，关闭

e)         将修改的问题送回到测试人员

f)         测试人员确认问题，如果问题修改完成，关闭问题；如果发现新问题，重新进入流程

3)        设置问题的等级：

a)         Bug严重等级分类

                         i.              高：缺少主要功能，或主要功能毫无作用；所产生的问题会导致系统停摆、工作不正常；所产生的问题导致无法进行下一步的测试

                       ii.              中：主要功能运行不完全；所产生的问题会导致系统部分功能不正常；所产生的问题虽然严重但是不影响下一步的测试

                      iii.              低：功能运行正常，但是会有一些不一致的情形产生；所产生的问题不会导致系统任何问题；所产生的问题不影响下一步的测试

                     iv.              微：功能运行正常，可是有改进的空间；所产生的问题不会导致系统任何问题；所产生的问题不影响下一步的测试

b)        Bug处理紧急程度

                         i.              1：立即修改完成

                       ii.              2：下一阶段结束前必须修改完成

                      iii.              3：产品推出前必须修改完成

                     iv.              4：如果时间允许的话再来修改

                       v.              5：在下一版本再修改

c)        两种分类方法的讨论

                         i.              严重等级分类法是从质量管理的角度来考虑，主动权在QA人员手中；处理优先级分类法是从项目管理的角度来考虑，主动权在项目经理或产品经理手中；两者往往会出现矛盾

                       ii.              让缺陷跟踪系统运作流畅必须配合适当的游戏规则，建议常常召开问题审核会议；并利用REDC（Review、Evaluate、Discussion、Conclusion）来减少测试人员与开发人员不必要的冲突和对立

第1篇           理论篇

1.         质量管理

1)        软件公司生存的三要素：

是否有核心技术

在核心技术的基础上，是否能够开发出不同种类的完整产品

是否对其产品开发及其售后服务进行严格的质量管理

 

核心技术，就是要建立竞争的门槛，竞争者要跨越这个门槛是有一定难度的

核心技术不仅仅是针对技术层面的，有些企业所拥有的核心技术是在过程控制或物流控制方面的，比如戴尔的核心技术就是它的供应链管理

一家软件公司最好能拥有不同类型的产品，用来应付不同客户的需求，最重要的是能够随着市场行情的变化调整销售目标

不重视产品开发和售后服务，除了增加更多的客户服务成本之外，还有修改软件缺陷所耽误的开发时间和成本

2)        质量管理简介与模式

a)         顾客导向模式：认同并满足客户需求，根据以往客户对企业的建议和要求作出改进

b)        标准衡量模式：根据质量管理标准实施质量管理，比如ISO9000；企业必须针对所有生产过程建立文档化的规程并进行管理，并且要经过合格的认证机构审核才能通过

c)        全面质量管理：

是在企业组织文化上的点、线、面各个层次作持续性的质量提高。就定义而言，全面质量管理要求企业内部所有员工将它视为一种信条，并且不断的提高个人及组织的生产过程能力，以满足内部及外部顾客的需求为首要目标。

在解决问题的层面上，TQM（Total Quality Management）采取了符合科学规律的方法，通过环环相扣的安排，在实施过程中确保所有部门的员工都已接受过培训，并且不断的努力提高服务质量，最终达到甚至超过顾客所期望的要求。简单的说，就是TQM创造出一个系统化的管理过程，用来满足客户的需求，并且将过程变成企业文化的一部分，最终达到连续性的质量管理。

d)        选择质量管理模式的考虑方向：8个方向供参考

                         i.              运作方式

                       ii.              员工培训

                      iii.              计划及监控

                     iv.              企业的规模及已成立的时间

                       v.              管理模式改变所造成的影响

                     vi.              授权方式

                    vii.              顾客反应回馈机制

                  viii.              实施成本：一般而言，成本包括3个要素：失败的成本、评估的成本和预防问题发生的成本。

3)        软件质量管理的重要性：

a)         降低维护成本

b)        法律上的要求

c)        市场竞争

d)        质量标准化趋势

2.         软件生命周期简介

1)        软件3N：Vision（远见）、Mission（任务）、Action（行动）

2)        软件开发生命周期模型：软件开发模型种类繁多，这里只列举7种软件开发模型以供参考。在之前，先了解REDI模型，在系统开发过程中有一定循环的现象为REDI，在REDI的过程结束后，之后的过程就是生产过程；REDI分别是Requirement Determination（调查需求阶段）、Evaluation of Altermatives（评估阶段）、Design Specification（设计阶段）、Implementation（制作阶段）

a)         建构修改循环模型（Build and Fix Model）：先推出一个版本给用户，再根据用户的反应作持续的修改，这个修改的过程要持续进行到客户满意后才会告一段落

b)        瀑布式开发模型：从建构修改循环模型演变而来，将开发过程定义为许多不同的阶段，每个阶段的开始及结束也都被清除的定义，各个阶段的转换除了必须进行审查之外，同时也要准备许多的文件；最大的问题是需求变更造成的后续影响较大

c)        增量模型：通俗的说，就是将整个过程分成许多小型的瀑布式开发模型，主要是利用焚化后注意征服的方法将产品需求切割成不同的优先级

d)        V型开发模型：也是改良自传统的瀑布式开发模型，它的重点在于进行确认和审查的步骤；（各阶段的对应关系）

e)         快速原形模型：

f)         螺旋型开发模型：

g)        极限型开发模型（XP）：

h)        基本上我们不建议特别采用何种开发模型，因为每种模型都有其优点和缺点；建议采用几种方法互相结合的模型

3)        现实环境的软件开发模型

a)         以功能为基础，比如一些通用软件word等

b)        以解决问题为基础，比如ERP、CRM，以及一些硬件驱动软件等

c)        在考虑了软件形式之后，介绍两种常见的产品开发方式：

                         i.              自顶向下的方式（top-down approach）：也成为框架式开发方式，采用的方法其实就是REDI Model；先调研需求，然后设计功能，最后实现。这种产品在扩展性和稳定性上较好，但开发时间较长，准备工作也较多

                       ii.              自底向上的方式（bottom-up approach）：通常使用这种方式是基于市场竞争的考虑，这种方式也称为组合式开发方式，所采用的方法是将目前所拥有的资源和技术进行快速的组合而成为产品。扩展性和稳定性较差，但开发时间较短。

3.         软件质量管理

1)        QA和QC有什么不同？都属于质量管理（Quality Management）的一环

QA，质量保证（Quality Assurance）的目标是预防缺陷和错误的发生（Defect Prevention）

QC，质量控制（Quality Control）是找出缺陷和错误（Defect Detection）

 

2)        质量保证的事务：制定计划(Planning)、需求审查(Requirement Review)、设计审查(Design Review)、程序代码审查(Code Review)、测试用例审查(Test Case Review)

质量控制的事务：测试（Testing）、跟踪(Tracking)、监督(Monitoring)

 

3)        审查方法：浏览性审查（Walkthrough）、阅读性审查（Reading）、设立审查机制（Inspection）

a)         需求审查

                         i.              是否准备了软件需求文件

                       ii.              所提供的软件需求是否符合客户的需求

                      iii.              所提出的需求在设计上的可行性如何

                     iv.              产品开发完成后是否与软件的需求吻合

b)        设计审查

                         i.              是否准备了软件设计规格文件

                       ii.              其内容是否参考了软件需求

                      iii.              所采用的设计规格是否符合公司的规定

                     iv.              设计内容是否考虑到质量，如稳定性、可扩展性等

                       v.              设计内容是否考虑到将来对客服的支持

c)        程序代码审查

                         i.              编写内容是否符合公司的规定

                       ii.              批注内容是否详细标示

                      iii.              是否参照I18N的规定内容

                     iv.              所编写的内容是否简单易懂

d)        测试用例审查

                         i.              是否准备了软件测试用例文件

                       ii.              内容是否参照软件需求和设计规格文件

                      iii.              所设计的用例是否考虑到测试的深度和广度

                     iv.              设计的用例测试是否可行

                       v.              设计的用例是否可自动化

 

　　测试盲区，也就是软件中测试人员未测试到的地方，造成这方面的原因主要有测试人员对测试需求理解不足、经验不足和思维僵化等原因造成的。接下来，就如何避免测试盲区给出几点建议。

一、 充分理解软件需求

　　需求方面的如果理解有误或者分析遗漏，那么将对软件功能测试很难全面覆盖。基本功能测试有遗漏的话，那是不可饶恕的，所以在测试前以及测试过程中要多注意软件需求文档、产品规格书，尤其是没有文档化的规格更改、需求变动，这都是很容易出现误测或漏测的。这在项目进程中需要项目成员之间加强信息沟通。

二、制定一份完善的测试方案

　　测试方案包括的内容比较多，这里我们主要指测试用例，测试前需要制定一套完善的测试用例，完善指我们的测试用例至少要覆盖所有软件需求，同时对于边界测试、中断测试、性能测试都要涵盖。测试用例编写很简单，但编写高质量的测试用例真的不容易，至少，让我称之为高质量的不多。测试方案应该要经过评审的，至少要和开发人员一起有针对性地讨论下测试内容、重点和需求。

三、多采取交叉测试

　　也就是同一项目组的不同测试模块的测试人员互换模块，相互测试。由于每个人的测试角度、思维方式等都不太一样，所以这种互测是发现更多问题的一个有效途径。事实证明，这种效果非常棒！

四、多学习同类产品的bug库

　　同类产品的bug库对于测试人员而言，是个非常好的资源，测试人员从那里可以了解更多产品容易出问题的地方，甚至很多问题本产品上就潜在着，还未被发现。

五、多沟通、交流

　　每一阶段，项目测试组长都应该组织小组测试人员多多交流，分析、总结下测试中遇到的问题，由于是一些概率性以及容易被忽略的问题，单个测试人员测试时可能遇到，但并不以为意，这样，通过讨论、交流，能够加强测试人员对问题的印象，在接下来测试中加强薄弱环节的测试。

六、加强相关产品知识学习

　　尤其是一些技术原理上的东西，只有深入了解了，测试上才能更加发现更多原来力所难及的问题，如协议层的问题。

七、经常测试、充分测试

　　测试上有个原则：及早测试、经常测试、充分测试。要发现更多的问题、减少测试盲区，多测是少不了的。

　小结

　　以上，根据个人的一些经验简单地谈了下如何避免测试盲区问题。其实，更广义地理解，测试盲区还涉及到测试软件质量目标和针对性问题，测试还要注意把握一个度和量，我们要知道软件在生命周期内的质量目标是什么。过犹不及，将大量时间浪费在测试一些用户永远无法涉及到或者无关轻重的地方，这都是很盲目的！

 

        测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：
    一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；
    二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；
    三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；
    四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；
    五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等；
    六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；
    七、有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；
    八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。
    前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。
    针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

Ø         测试环境不正确可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查；

Ø         有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险；

Ø         有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险；
    为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如： 在做资源、时间、成本等估算时，要留有余地，不要用到100%；

Ø         在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中；

Ø         对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍能可以继续下去；

Ø         制定文档标准，并建立一种机制，保证文档及时产生；

Ø         对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换；

Ø         对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。

要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。

在G.J.Myers的经典著作《软件测试之艺术》（The Art of Software Testing）中，给出了测试的定义：“程序测试是为了发现错误而执行程序的过程”。这个定义，被业界所认可，经常被引用。除此之外，G.J.Myers还给出了与测试相关的三个重要观点，那就是：

ü         测试是为了证明程序有错，而不是证明程序无错误；

ü         一个好的测试用例是在于它能发现至今未发现的错误；

ü         一个成功的测试是发现了至今未发现的错误的测试。

实际上，这里暗示了“软件测试”在不同侧面上的含义，也就决定了对软件测试不同的定义和不同的理解。根据作者多年的经验和理解，软件测试的不同视野，概括为如下5类：

ü         软件测试的狭义论和广义论——静态和动态的测试软件

ü         测试的辨证论——正向思维和反向思维

ü         软件测试的风险论——测试是评估

ü         软件测试的经济学观点——为盈利而测试

ü         软件测试的标准论——验证和确认

 

一、              软件测试的狭义论和广义论
　　G.J.Myers所给出了测试定义——“程序测试是为了发现错误而执行程序的过程”，实际是一个狭义的概念，因为他认为测试是执行程序的过程，也就是传统意义上的测试——在代码完成后，通过运行程序来发现程序代码或软件系统中错误。但是，这种意义上的测试是不能在代码完成之前发现软件系统需求、发现设计上的问题，把需求、发现设计上的问题遗留到后期，这样就会可能造成设计、编程的部分返工。增加软件开发的成本、延长开发的周期等。需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。这种狭义论是受软件开发瀑布模型影响。
　　正是为了更早地发现问题，所以将测试延伸到需求评审、设计审查活动中去，也就是将“软件质量保证”的部分活动归为测试活动。实际上，在软件开发实际操作中，常常将软件测试和质量保证——这两种努力（efforts）合并起来。
　　延伸后的软件测试，被认为是一种软件测试的广义概念。这就引出软件测试的两个概念“静态测试”和“动态测试”，如 测试方法的辩证统一（1）所述，这样就由静态测试和动态测试构成一个全过程的、完整的软件测试，而且静态测试显得更为重要。

二、              软件测试的辨证论
    G.J.Myers的第2个观点“测试是为了证明程序有错，而不是证明程序无错误”，引出了软件测试的另外一个争论，软件测试究竟是证明所有软件的功能特性是正确的呢？还是其反向思维——对软件系统进行各种试探和攻击，找出软件系统中不正常或不工作的地方呢？从我个人理解，这两个方面都有一定道理，前者（证明所有软件的功能特性是正确的）是从质量保证的角度来思考软件测试，后者（证明程序有错）从软件测试的直接目标和测试效率来思考，两者应该相辅相成。在后者的思想背景下，我们认为，测试不是为了证明所有的功能可以正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的地方。也就是说，测试的一般工作就是发现缺陷 (detect bug)，即在软件开发过程中，分析、设计与编码等工作都是建设性的，而测试是带有“破坏性”的工作。
　　对于不同的应用领域，两者的比重是不一样的，如国防、航天、银行等软件系统，承受不了任何系统失效，因为一次系统的失效完全有可能导致灾难性的损失，所以强调前者以保证非常高的软件质量。而一般的软件服务应用则不同，强调后者，质量目标设置在“用户可接受水平”，不要过度追求质量，从而可以降低软件开发成本。作者建议，在我们实际操作中，可以分阶段实施不同的测试思想，在早期阶段集中在“证明程序有错”—— 发现Bug，后期集中在验证所有特性是否正常工作——降低风险，见作者的另外一篇讨论：测试执行中非常有效的策略
　　下面就是这两种观点的基本描述：
　　验证软件是验证软件是“工作的”，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。其代表人物是软件测试领域的先驱Dr. Bill Hetzel （代表论著《The Complete Guide to Software Testing》)。
　　证明软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。其代表人物就是上面多次提到的G.J.Myers。他强调，一个成功的测试必须是发现Bug Bug的测试，不然就没有价值。

三、              软件测试的风险论
　　测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这就是软件测试的风险论。软件测试自身的风险性是大家公认的，测试的覆盖度不能做到 100％。测试的这种风险定义一方面源于这层含义，另外软件测试的标准有时不清楚，“软件规格说明书（Specification/ Spec）”是其中的一个标准，但也不是唯一的，因为Spec中有些内容完全有可能是错误的。所以，我们常常强调软件测试人员应该站在客户的角度去进行测试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对Spec 去报Bug。但是，测试在大多数时间/情况下,是由工程师完成，而不是客户自己来做，所以又怎么能保证工程师和客户想得一样呢？
　　有人把开发比作打靶，目标明确，就是按照Spec 去实现系统的功能。而把测试比作捞鱼，目标不明确，自己判断哪些地方鱼多，就去哪些地方捞；如果只捞大鱼（严重缺陷），网眼就可以大些、撒网区域相对比较集中（测试点集中在主要功能-major features）。如果想把大大小小的鱼捞上来，网眼就要小、普遍撒网，不放过任何一块区域（测试点遍及所有功能——all features）。
　　在“风险”论的框架下，软件测试可以被看作是一个动态的监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，发现问题、报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去，包括回归测试。这时，软件测试可以完全看作是软件质量控制的过程。
　　对应这种观点，产生基于风险的测试策略，首先评估测试的风险，功能出问题的概率有多大？哪些是用户最常用的20％功能——Pareto原则（也叫 80/20原则）？如果某个功能出问题，其对用户的影响有多大？然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20％功能（优先级高）的测试会得到完全执行，而低优先级的测试（另外用户不经常用的80％功能）就不是必要的，如果时间或经费不够，就暂时不做或少做。

四、              软件测试的经济学观点
　　“一个好的测试用例是在于它能发现至今未发现的错误”，体现了软件测试的经济学观点。实际上，软件测试经济学问题至今仍是业界关注的问题之一。经济学的核心就是要盈利，盈利的基础就是要有一个清楚的商业性目标。同样，商业性目标是否正确，直接决定了企业是否盈利的结果。多数情况下，软件测试是在公司内的执行。正是公司的行为目的，决定了软件测试含义或定义的经济性一面。正如，对软件质量的定义不仅仅局陷于“和客户需求的一致性、适用性”，而且要增加其它的要求——“预算内、按时发布、易于维护”。
　　软件测试也一样，要尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。原因很简单：平均而言，如果在需求阶段修正一个错误的代价是1，那么，在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是 40～ 1000倍。修正错误的代价不是随时间线性增长，而几乎是呈指数级增长的。

五、              软件测试的标准论

如果从标准论来看软件测试，可以定义为软件测试就是“验证（Verification）”和“有效性确认（Validation）”活动构成的整体，即软件测试 = V&V。
　　“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性、准确性等）相一致。相当于，以Spec为标准进行软件测试活动，验证软件产品和Spec的一致性。
　　“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。相当于，保持对软件需求定义、设计的怀疑，一切从客户出发，理解客户的需求，发现需求定义和产品设计中的问题。这主要通过各种软件评审活动来实现。
　　需要说明的是，软件测试的对象是产品（包括阶段性产品，如市场需求说明书、产品规格说明书、技术设计文档、数据字典、程序包、用户文档等），而质量保证和管理的对象集中在软件开发的标准、流程和方法等。  

 

究竟什么是软件测试呢？综上所述，软件测试的定义为：
　　软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，
　　其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。

一、引言
 
随着社会信息化水平的不断提高，信息行业急速膨胀，信息企业快速成长，随之带来的信息市场竞争激烈，企业为了求生存，满足客户要求则成为各行各业的首要责任。依赖于质量、成本和进度的客户满意度，质量则是重点支撑之一，这样要求我们对质量管理需要加强认识。我们都知道pmbok把项目管理划分为9个知识领域，即范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和综合管理。质量管理作为9大知识领域之一，可见其重要性。

质量管理包括：质量计划编制、质量保证和质量控制三个过程域。质量计划是质量管理的第一过程域，它主要结合各个公司的质量方针，产品描述以及质量标准和规则通过收益、成本分析和流程设计等工具制定出来实施方略，其内容全面反应用户的要求，为质量小组成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。质量保证则是贯穿整个项目全生命周期的有计划和有系统的活动，经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一致。质量控制是对阶段性的成果进行检测、验证，为质量保证提供参考依据，它是一个PDCA循环过程。 

二 质量管理责任分配
 
我们公司在开发项目上按照规范化软件的生产方式进行生产，在生产流程上采用ISO9000的标准进行。每个项目除配备了项目开发所需角色外，还专门配备了配置管理小组、测试小组和质量保证小组确保质量管理的实施，下面针对这三种角色进行说明： 

1、配置管理小组职责
 
配置管理小组是保证项目开发完毕的同时，内部文档和外部文档都同时完成。内部文档的及时产生和规范，是保证项目开发各小组能够更好的接口和沟通的重要前提，从另一个方面讲，也是保证工程不被某个关键路径所阻塞而延滞的前提。如上所述，配置管理小组还是保证质量保证小组得以发挥作用的基础。配置管理小组的主要职责包括：完善各个部门发送需要存档和进行版本控制的代码、文档（包括外来文件）和阶段性成果； 对代码、文档等进行单向出入的控制； 对所有存档的文档进行版本控制； 提供文档规范，并传达到开发组中。 

2、测试小组职责 

测试小组作为质量控制的主要手段，负责软件的测试设计和执行工作。如同软件开发一样，测试在执行之前，同样需要进行测试计划和测试策略的设计，通常情况下测试可以分为如下几种类型，如：正确性测试、功能性测试、性能测试、安全测试和系统测试等。而这些测试均需要在测试计划和测试策略中进行描述用以指导测试小组成员进行测试用例编写和测试执行。程序员在交给测试人员之前是进行过一定的单元测试，确保程序编译、运行正确。 

测试人员根据详细设计的文档对软件要实现的功能进行一一测试，保证软件的执行正确的实现设计要求，在此也只证明了软件正确的反映了设计思想，但是否真正反映了用户的需求仍需要进一步的功能性测试。 

测试人员只有根据软件需求规格说明书所提及的功能进行检测，才能确保项目组开发的软件产品满足用户需求。在正确性测试完成之后，需要测试的是软件的性能，软件的性能在本项目中占有重要的地位，性能要求有可能改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧重。如果有必要的话，测试小组还需要做安全测试，以确保系统使用安全可靠。
 
3、质量保证小组职责

质量保证小组作为质量保证的实施小组，主要职责是保证软件透明开发的主要环节。在项目开发的过程中几乎所有的部门都与质量保证小组有关。质量保证小组对项目经理提供项目进度与项目真正开发时的差异报告，提出差异原因和改进方法。 

在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时，提请项目经理、项目负责人等必要的相关人员举行质量会议。解决当前存在的和潜在的问题。质量保证是建立在文档的复审基础之上，因而文档版本的控制，特别是软件配置管理，直接影响软件质量保证的影响力和力度。质量保证小组的检测范围包括：系统分析人员是否正确的反映了用户的需求； 软件执行体是否正确的实现了分析人员的设计思想；测试人员是否进行了较为彻底的和全面的测试； 配置管理员是否对文档的规范化进行的比较彻底，版本控制是否有效。  

三 质量管理实施

有了良好的资源配备，又如何在项目全生命周期内实施质量保证，让我们从以下几个方面来看质量保证的实施过程：
 
1、项目进度的质量保证

项目进度是项目进行是否顺利的最直观表现。显然在项目开始之前，项目开发计划是必须的。如果项目开发计划的制定的是完全合理的，那项目进度也就真正表达了项目与最终的交付使用之间的距离，然而要制定完全合理的项目开发计划几乎不太可能。可见要保证项目进度，首先要保证项目开发计划尽可能合理。
项目计划的合理程度与项目计划制定者从事类似规模和类似业务的项目的经验有直接关系，通过经验往往能够预见潜在的阻碍，这样要求项目计划制定者需要集众人之力来完善计划。 

当项目计划制定初期，由质量保证小组组织召开的项目计划评审会，邀请公司技术专家、用户以及项目组小组成员一起讨论项目计划的可行性，会议通常采用头脑风暴法，各抒己见，会后由指定的记录员形成质量记录，发送给相关人员，对其计划中不合理的地方进行修改完善，并由质量保证人员对其结果跟踪，以确保项目计划完整性、可行性，完善后的计划交由配置管理人员进行版本控制。 

然而在计划实施过程中，计划不是“固定化”。常有人道，“计划赶不上变化”，但“要跟上变化”。项目计划以里程碑为界限，将整个开发周期划分为若干阶段。根据里程碑的完成情况，适当的调整每一个较小的阶段的任务量和完成的任务时间，这种方式非常有利于整个项目计划的动态调整。也利于项目质量保证的实施。 

实际运作中，当质保小组发现计划实施的差异后，报告项目经理，由项目经理组织负责对计划进行周期性维护，对于已经变动的计划由质保小组协助配置管理小组完成版本控制。本公司已经开发湖南移动的集中客服系统，开发中的子项目多达六个，历时十个月，目前多数项目已经开发完毕，系统正在试运行阶段，项目金额数千万元。在这样的项目中，从管理者到开发人员到测试人员都积累了较为丰富的经验，特别是项目开发计划的制定，和项目进度的控制。

摘要：1999 年，火星气象卫星(Mars Climate Orbiter)到达火星之后不久就消失；1996 年6月4 日，Ariane 5 发射40 秒后爆炸；在一些报刊上，我经常看见报刊报道一些市民在ATM上取款时，发现自己卡内的存款为天文数字。软件质量已成为软件公司和软件客户越来越关心的问题。无疑，软件测试是软件质量保证的关键步骤，许多研究数据表明，软件公司只有建立良好测试体系，才能较早地发现软件中存在的问题，降低开发费用和维护费用，减少客户使用软件时由于质量问题带来的损失，有效地提高软件公司的软件过程改进能力和软件工程化能力。

我公司以前在软件开发上同样碰到不注重软件测试带来的软件质量不高和巨大维护成本的惨痛教训，后来通过软件测试体系的建设，极大地增强了公司产品量，加强风险防范能力，减少员工劳动强度和企业对系统的维护成本。下面我将介绍在软件测试体系建设上我公司的整体解决方案，以供大家相互交流。

在软件测试体系的建设上我们公司分别从软件测试的管理体系和技术体系两方面上着手，从团队组织、环境建设、标准制定、人员培养、配置管理、工作流程、绩效管理与激励制度七个方面进行建设。实践证明，此种测试体系能有效提高软件质量和软件过程能力，能极大提高员工工作效率和降低员工工作强度。

测试团队组织
为了让大家更好地了解我们公司软件测试体系建设的外部环境，我先简要介绍一下我们公司软件研发部门的相关组织情况，我们公司在软件研发上相关的有四个部门：
1. 金融事业部，主要负责金融产品的研发，产品范围覆盖windows 和unix 两大平台；
2. 政府事业部，主要负责政府、公安、税务产品方向上的研发，产品范围主要集中于windows 平台；
3. 测试部门，主要负责公司的软件产品验证、代码审查和测试工作；
4. 质量保证（QA）部门，主要负责公司的软件过程改进指导工作，最终交付产品的质量检查和质量保证工作以及版本管理工作。
在测试的组织方式上，我们采用独立的测试部门，负责整个公司软件项目的测试工作。
部门内设有测试经理一名，负责测试人员的组织和管理工作；设置有测试工具和测试文档保管员一名，负责测试文档和测试工具管理工作；设置有测试人员若干名，这些测试人员地位相互平等，但他们的每个人有自己的发展和研究方向，有的发展方向是基于需求的测试，有的是基于安全的测试，有的是基于接口的测试，有的基于界面的测试等等，各测试人员必须精通自己测试发展方向，并要求熟悉其他人的测试技术。
我们公司在开发软件的方式上，是采用基于项目的管理模式。在对一项目的研发过程中，设置有项目经理，其下设置有开发主管和测试主管，测试主管和开发主管地位相等，同属于项目经理负责，测试主管管理若干个测试人员，测试主管和测试人员都来自于独立的测试部门，项目进行完毕测试主管的使命也随之结束。所以，在多个项目中，一测试人员在一项目可能是测试主管，在另一项目中可能是测试员。

环境建设
在环境建设上，我们主要从软硬件环境两方面作手。
在硬件方面，我们保证了每个工作人员有自己的PC 机。在基于PC 机上的环境，我保证测试部门有单独的测试PC 机环境。对于小型机等测试部门不能单独配备硬件，我们通常与开发部门协调，建立独立的两套环境，不能建立独立环境一般与开发部门约定各自可以使用的时间。
同时，测试相关文档的管理是一个复杂和繁琐的工作，我们通过购置国内一软件厂商的测试管理系统对计划、用例、过程、缺陷、过程等文档进行有效的管理。对于单独的测试部门来说，利用测试工具可以大幅提高测试质量，根据公司产品特点和经济条件，我们通常使用免费工具和自己书写自动化工具，如对于代码审查和单元测试我们经常用C++ TEST，对于回归测试、压力测试我们通常使用自己书写的工具，对于比较复杂环境的性能测试我们公司一般外包给专门的测试公司来做，以便减少测试成本和保证测试质量。

标准制定
对于一个团队来说，任何活动制定相关的标准尤为重要。
同样，为了便于沟通和管理，保证测试文档术语的一致性，节约测试人员的时间和精力，提高测试质量，我们公司的测试部门同QA 部门一起制定一系列测试文档模板和测试文档编制说明，测试模板主要根据公司的项目特点和GJB 438A 国家标准制定。
这些模板和编制说明主要包括计划、用例、过程、日志、测试分析报告等等。所有模板和测试规程说明保存在QA 部门，每一项目开始时由测试主管和相关测试人员确定此次测试应使用模板和规程说明，如已有模板和规程不够必先提出并让测试主管与QA 部门协商先形成相关测试模板和规程说明，测试人员才能进行测试和填写文档，严禁测试人员提供不符合要求的测试文档。
当然测试人员在测试当中发现模板不合乎要求，同样可以提出增加模板，但同样要遵循先有模板再有文档的原则。
同时，我们公司的测试人员同时负责代码检查工作，主要检查代码是否符合软件开发规范的各项格式和要求，测试人员检查代码工作主要依据软件开发规范进行，开发规范的制定主要由QA 部门完成，项目开始时由QA 部门提供给该测试项目的项目主管。

人员培养
一个优秀的测试团队的形成并非一早一夕能形成。软件测试和软件开发一样，是一项高智力的活动。
在对测试人员的选择上我们通常从技术能力、沟通能力、记忆力、自信心、耐心、怀疑精神、洞察力、有条理和注意细节八方面进行考虑。对于新进入部门的测试人员，无论是否有无编程经验，都要进行测试的技术和管理规范培训，同时根据他们以往知识和个人特点给他们定位合适的测试方向。
为了留好和用好测试人员，我们注重了对测试人员职业生涯的规划。对于任何测试人员来说，我们都要求他懂得编程，对于一个新人来说，我们公司培养周期是开始对他进行测试规范和软件开发规范的培训，一个新的测试员一般开始做代码审查和测试用例执行工作，一个新的测试员经过一段时间工作，我们会让他从事开发工作，过了一段时间根据个人意愿和发展趋向又可能重新调回测试岗位，此时他将从测试管理和测试用例设计上发展。
在测试空闲时，我们要求测试人员互相培训，增加测试人员知识的广度。并重点钻研自己的测试发展方向，并形成相关文档变成企业的资源。
代码审查和用例执行等
软件开发 测试管理和用例设计等
开发规范和测试规范培训

配置管理
软件测试过程是一个复杂性的劳动，测试过程中会产生大量文档。我们主要通过购买工具的方式实行对文档的管理。在文档的管理方面，我们按照公共类、项目类、软件缺陷类、开发人员类、测试工具类：
1. 公共类主要放置测试模板及测试规程说明，测试经验共享文档，开发技术规范等。
2. 项目类主要包括项目各阶段文档，如测试计划、测试用例设计等。
3. 开发人员类是针对每个开发人员易犯错误的总结。
4. 测试工具类主要放置常用的测试工具。
对于每个测试人员来说，由于我们测试管理软件采用的是B/S 结构，所以每个测试人员可以通过internet 网查看和下载公共类、软件缺陷类、开发人员类文档和自己权限范围类的项目文档。

工作流程
为了使测试工作有序，提高工作效率。我们形成了一套测试工作的流程。
当一项目启动。测试经理将向所有测试人员介绍项目情况，由测试人员申请测试项目主管，测试经理和项目经理根据实际情况择优选用一测试人员作为测试项目主管。
测试项目主管和测试部门经理共同商定该项目各阶段所需的测试人员，随着项目的进行，各阶段测试人员相继加入。每个阶段首先相关测试人员首先对文档进行验证，并编写相关测试用例，随后按项目实际情况加入进行测试。
需求分析----------------------------------------- ----需求验证
概要设计 ------------------ 概要设计验证
详细设计 ----------- 详细设计验证
编码-----代码审查

总体来说，项目整个测试过程按V 模型进行，V 模型是测试组织中常用到的一种模型，它指的是根据需求进行验收测试，根据概要设计进行系统测试，根据详细设计进行集成测试，根据编码进行单元测试。对于测试过程中，原则上要求每个测试人员要求必须每天提供测试文档让文档管理员放入测试管理系统中。对于测试阶段和维护阶段测试人员测出的软件缺陷，要求按错误登记分类及时录入系统中，方便开发人员及时查阅，对于软件缺陷，我们通过系统的6 个生命周期状态（打开、工作、验证、取消、关闭、延期）进行管理。
开发人员总能通过测试管理软件中的缺陷子系统及时知道自己开发部分所存在的软件缺陷。
各阶段测试人员工作完毕相继离开此项目。项目进行完毕时，测试项目主管的使命结束。
需求分析 验收测试
概要设计 系统测试
详细设计 集成测试
编码 单元测试

绩效管理与激励制度
对于测试人员来说，在绩效管理和激励制度上，我们通常按照测试人员业绩和贡献进行激励。主要表现在两个方面：
1. 为部门提供所负责部分测试技术质量、数量和对其他人员的培训效果。
2. 项目部分，对于每参与一个项目的测试，测试人员要一定绩效工资。在项目中，对测试人员绩效考核在于他发现问题个数、等级及说服开发人员修改问题个数和等级；同时在项目投放市场时自己负责发现问题的多少和级别来确定。

存在问题和不足
对这种体系实施一定时间后，经一段时间后，我们发现存在三方面问题：
1. 由于我公司采用独立的测试部门，很容易形成测试人员和开发人员的对立。所以在对测试人员的培训时强调了注意原则性的同时，要注用一定的灵活性，要让开发人员意识到测试人员是他们的朋友，而不是敌人，同时在对测试人员的考核上把说服开发人员改正问题个数作为重要考核内容。但即使这样，形成对立的事情还是时有发生，以后双方沟通问题还应加强。
2. 项目结束后，再测试时人员组织问题和责任划定问题。在项目结束后，我公司通常采用以后再需测试时仍由原该项目测试主管负责进行，但此时组织工作可能不如以前容易，因为此时相关测试人员已经有其他工作安排，同时多次测试的责任和绩效不好划定。在这方面我们公司还需制定具体问题细则。
3. 项目较多时，一测试人员可能在一段时间内完成几个测试项目，容易产生几个项目时间规划对于一个测试人员的时间冲突问题。避免测试人员在多个项目中时间上的交叉也是以后测试经理规划时应注意的问题。

最近，根据我对国内公司测试行业的招人情况的观察，发现起步比较晚的测试行业已经跟开发行业一样开始了细分：
比如做ERP的用友或者外包做微软MBS，会要求应聘者有ERP行业经验；做银行的企业，会要求应聘者有银行背景；做财务软件的企业，会要求应聘者有财务相关知识；做CRM、IPTV、手机等等都会要求应聘者各自有相关的经验。
在同样的大的理论测试框架下，不同行业方向领域的测试所用技术细节、侧重的方向、使用的测试工具、采取的测试策略都已差别很多。不熟悉该领域的fresh man很难在短时间内把握产品的特点和做出有效地测试。
这些岗位应聘时需要的经验，对没有很对口经验的应聘者来说，一部分可以靠多年的测试职业经验(一般3~5年)来弥补，另一部分可以靠个人比较精通的领域知识来弥补。对于这类测试岗位来说，没有相关的经验，一定会影响到个人拿到高薪的成功率，但不会是应聘这类岗位成功的阻碍。
所以，我认为个人想在测试方面得到很高的成就感认同感，已经必须象开发那样专注一个个人认为比较有潜力的领域或行业，深入钻研，做出成绩，从而得到企业认可，获得高薪达到事业的高峰。

质量管理新理念——以员工为中心（转载朱少民老师）

质量管理，在过去多少年都提倡“以顾客为中心”、“顾客是上帝”，现在可能是我们打破这种理念的时候，企业更强调人性化管理，建立质量的新理念——“以员工为中心”，为什么怎么说呢？

产品需要顾客掏钱买，服务需要顾客接受，如果顾客不满意，顾客就不会买我们的产品，就不会为我们的服务付费。从这个意义上说，我们要让顾客满意，顾客都是对的，一切工作围绕顾客服务。但是，我们都清楚知道，任何产品都是由我们员工开发出来的，任何服务都要由我们员工提供的。如果我们员工不满意，在开发产品的时候，他们能精益求精、追求完美吗？如果我们的员工不满意，员工就不可能有很高的敬业精神，你能想象我们的员工能时时从客户需求出发、时时为客户着想？如果不是这样，产品的质量就得不到保证，就得不到本质的提高。再设想一下，当我们的员工为客户服务时，如果他/她对自己的企业不满意，脸上的微笑一定不自然，是非常僵硬的，甚至是伪装的——皮笑肉不笑，客户不会觉得很舒服。我自己在酒店、餐馆就有这种感觉，听到服务员不断喊 “先生好”、“欢迎光临”等，觉得是应付，没有亲切、或温暖的感觉。在国内，多数情况下，服务员得不到足够重视和关心，不会对企业有较强的满意度，完全是为了养家糊口。

许多企业认识到这些，国际上有惠普、微软、Adobe等，国内有浪潮软件集团，都强调 “员工满意了，顾客才满意；顾客满意了，股东才满意”，员工是管理工作的核心，员工要得到无微不至的关怀，从基础上提高产品的质量。
1. 我 在另一篇文章中 企业究竟会带给员工什么？ 就介绍了惠普这种理念：
没有满意的员工，就没有满意的客户。所以各级管理人员的工作重点是令员工满意。如果员工对公司不满意，不可能指望员工发自内心地替客户去着想，而为客户着想恰恰就是为公司的长远利益着想，只有那些真正关心客户利益的企业才能长久地生存下去。
2. 浪潮软件集团，也有相同的理念：
员工满意才能够保证客户满意，客户满意股东自然就满意。这三个满意中，员工满意是第一位的。“以员工为中心”，“让员工满意”已经作为一个长久理念纳入到浪潮通软的企业文化，并在行动上落到了实处。首先为员工组建了自己的组织——员工关系部。

员工关系部会定期组织各种活动，针对员工遇到的一些细节问题进行沟通并协助解决。比如，派到外地的员工到春节放假的时候，公司会帮他提前定好车票；离开公司的员工，一旦遇到生病等困难，公司知道后会提供帮助，比较有人情味。“要营造一种大家庭的企业文化。”，为员工提供开放、融洽、和谐的工作环境与氛围，公司员工才会满意，工作效率和工作质量才会提高。“只要是员工发自内心去工作，有一种奉献精神，客户肯定是认可的，客户认可，赢利就是水到渠成的事情，股东自然会满意。”

3. 中调网：以员工满意度为核心全面树立CS经营理念

 鉴于员工（内部顾客）满意和顾客满意对于企业的重要作用及其二者间的紧密关系，将员工满意度与顾客满意度结合起来而构成员工/顾客满意矩阵。将满意水平可划分为满意和不满意（也可以把满意水平划分为高、中、低等），这样就可以把所有企业划分为四种类型

1、属于A类的企业，员工满意，顾客也满意，企业发展的基础及目的都得以完美实现，说明这个企业的市场营销、产品质量及内容管理都做的很好，是一个健康型的企业，今后应继续保持。

2、属于B类的企业，顾客满意而员工不满意，说明企业的产品质量、外部营销等暂时做得还不错而内部管理工作并不理想，诸如有些管理不善的企业由于某个新产品可能在市场上会有类似昙花一现之表现。但从长远的角度看若不改善内部管理并使员工满意，最终会使顾客满意度降低甚至于不满意，从而使企业由B转入D。因此，时于B类企业应在保持顾客满意的条件下尽快提高员工满意度，以使企业由B类转向A类。

3、属于C类的企业其员工满意而顾客不满意，这说明企业的外部营销有问题，诸如几年前我国的一些邮电、银行等企业职工其工资和福利都很高但社会形象却不佳。从长远看顾客不满意肯定会影响到企业的投资回报，并且最终会影响到员工的满意水平（这一情况上述企业近期已有表现）。故对于这类企业应大力加强外部营销，提高产品（服务）质量，让顾客满意，促使企业由C转向A类。

4、D类企业是状况最差的企业，员工及顾客都不满意，内忧外患并存。企业要深刻检讨自己的内部管理与外部市场营销工作，以市场为导向建立内部科学合理的管理体系，使企业逐渐向A类转移。
    个人感想：（1）中国企业缺少的就是这样的思考。其根本原因在于，中国企业的竞争太大。当老板的几个没有和领导有关系的？一旦关系确定，市场的一大部分就会到手，恶性竞争导致的中国企业不去想这些事情。（2）大部分的市场利润都流失到了关系上，导致成本增高。当一个项目有500万，但是搞关系需要250万，做出来的东西依然是500万。哪里谈利润？在老板的眼里就是利润大幅缩水，怎么来进行管理？
以上这段都为个人观点，跟作者无关。

已上传文档：http://www.51testing.com/batch.download.php?aid=12604

随着国内软件行业的不断发展，国内软件公司也越来越注重于软件的质量，越来越关注软件的可靠性，因此，做为质量保证的重要手段，软件测试过程的实施与管理成为一个热点，其中系统测试是整个测试活动的一个重要的阶段，系统测试的设计也就成为了关注点之一。以下是本人从事系统测试工作中的一些体会。 

1、系统测试的定义：
   系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。 

2、系统测试的对象：
   系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。 

3、系统测试的设计
   系统测试过程包含了测试计划、测试设计、测试实施、测试执行、测试评估这几个阶段，而整个测试过程中的测试依据主要是产品系统的需求规格说明书、各种规范、标准和协议等。在整个测试过程中，首先需要对需求规格进行充分的分析，分解出各种类型的需求（功能性需求、性能要求、其他需求等），在此基础之上才可以开始测试设计工作，而测试设计又是整个测试过程中非常重要的一个环节，测试设计的输出结果是测试执行活动依赖的执行标准，测试设计的充分性决定了整个系统过程的测试质量。因此，为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。这就需要我们在测试设计中，从多方面来综合考虑系统规格的实现情况。通常需要从以下几个层次来进行设计：用户层、应用层、功能层、子系统层、协议层 

3.1、用户层：
主要是面向产品最终的使用操作者的测试。这里重点突出的是在操作者角度上，测试系统对用户支持的情况，用户界面的规范性、友好性、可操作性，以及数据的安全性。主要包括：
3.1.1、用户支持测试
用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。
3.1.2、用户界面测试
在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下，测试用户界面的风格是否满足用户要求，例如：界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。
3.1.3、可维护性测试
可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来的影响。例如：对支持远程维护系统的功能或工具的测试。
3.1.4、安全性测试
这里的安全性主要包括了两部分：数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问系统，其他不符合规格的数据不能够访问系统；核实只有规格规定的操作权限才可以访问系统，其他不符合规格的操作权限不能够访问系统； 

3.2、应用层：
针对产品工程应用或行业应用的测试。重点站在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行的测试。
3.2.1、系统性能测试
针对整个系统的测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程；强度测试是在资源情况低的情况下，找出因资源不足或资源争用而导致的错误；破坏性测试重点关注超出系统正常负荷N倍情况下，错误出现状态和出现比率以及错误的恢复能力。
3.2.2、系统可靠性、稳定性测试
一定负荷的长期使用环境下，系统可靠性、稳定性。
3.2.3、系统兼容性测试
系统中软件与各种硬件设备兼容性，与操作系统兼容性、与支撑软件的兼容性。
3.2.4、系统组网测试
组网环境下，系统软件对接入设备的支持情况。包括功能实现及群集性能。
3.2.5、系统安装升级测试
安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如，正常情况下，第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。还有一个目的是核实软件在安装后可立即正常运行。另外对安装手册、安装脚本等也需要关注。 

3.3、功能层
针对产品具体功能实现的测试。
3.3.1、业务功能的覆盖
关注需求规格定义的功能系统是否都已实现。
3.3.2、业务功能的分解
通过对系统进行黑盒分析，分解测试项及每个测试项关注的测试类型。
3.3.3、业务功能的组合
主要关注相关联的功能项的组合功能的实现情况。
3.3.4、业务功能的冲突
业务功能间存在的功能冲突情况。比如：共享资源访问等。 

3.4、子系统层
针对产品内部结构性能的测试。关注子系统内部的性能，模块间接口的瓶颈。
3.4.1、单个子系统的性能
应用层关注的是整个系统各种软、硬件、接口配合情况下的整体性能，这里关注单个系统。 3.4.2、子系统间的接口瓶颈
例如：子系统间通讯请求包的并发瓶颈。
3.4.3、子系统间的相互影响
子系统的工作状态变化对其他子系统的影响。 

3.5、协议/指标层
针对系统支持的协议、指标的测试。
3.5.1、协议一致性测试
3.5.2、协议互通测试  

作者：袁琳   2004-09-01

信息产业部软件与集成电路促进中心(CSIP)已成功地主办了两届中国软件质量年会。本届年会将以“软件质量创新助力两化融合”为主题，继续深化我们已取得的成绩，把软件质量年会做实，为增强我国软件企业竞争能力、振兴我国软件产业，助力信息化与工业化融合做出积极贡献。

 

在以下半个小时的时间大家有任何疑问或者不明白的，你就举手说，会场可以产生互动，没有任何问题。

 

在座有多少测试人员，很高兴，大概是百分之百，大家都是同行，看有没有这样的问题。

 

虽然觉得软件测试很重要，但苦于没有办法组建规范的测试中心，什么叫规范的测试中心，有章有法，你的技术是可控的，你的人是可控的，很少有这样的公司，我做过企业内训的公司有上百家了，但很少，大多数认为是成本中心，或者是花钱，公司一直在不停的投入，但是对产品的质量没有多少帮助。有多少帮助？你能说出来的，老板持续给你买工具，组建团队，招聘新人，由于你的存在，由于你的团队的存在，你为公司创造了很多效益，有吗？你隐隐约约觉得有，但没有办法拿数字说明，所以没有办法证明你存在的价值，或者你部门存在的价值。

 

无法衡量软件测试工作的成果，你说我的测试工作很规范，很努力，我写了一千个测试用例，工作成果好不好？很难说，因为你的老板会说，才写了一千个啊？我认为应该是上万个，因为我的系统很复杂。可能还会问什么呢？你怎么能写一千个呢？我认为咱们系统有一两个足够了，你用例怎么写的，是不是花了很多无用功，都有这样的疑问。你还没办法说明它。

 

总感觉测试工作，或者测试团队的工作是不可控的。不可控到什么程度，在坐有这么多测试人员，大家都会有这样的感觉，我可能今天很累，累在什么地方，我好好测试我的软件一个BUG都没有发现，你的老板问你工作成果是什么，你没办法说。你可能今天很闲，你心情不好，不想干活，你可能上了一天网，被测的软件没有打开，虽然今天没干活，但是对整个质量也没产生影响，你可以心安理得的回家，第二天再说，对吗？可能都有这样的经历。作为公司，作为部门经理如何对你监控，从公司的角度来说，这是一件很可怕的事情。

 

测试过程混乱，无法进行有效的持续改进。什么叫持续改进，没有人有能力，没有公司有能力，一次把所有的事情都做正确，都做好，做对，没有人，没有公司。你要知道你现在目标在哪儿，而且能判断到你持续向你的目标迈进。

 

我们这么多做软件测试的，软件测试的目标是什么？上午和下午有很多嘉宾说，保证产品质量，认为是保证产品质量的我看看，很遗憾，保证不了，谁可以说经过你的测试，这个软件质量就可以保证，谁敢说？那么多第三方的评测机构，哪个评测机构敢说这个软件经过它的评测，质量就没问题，谁敢说，你保证不了。

 

做一个简单的数学题，一个软件有一百个功能点，这个软件大吗？很小。如果从测试的角度来说，它可能有的功能点组合有多少？概率，C100、100，C100、100的数学等等多少？等于100的阶乘，已经是天文数字了，从数学模型来讲，测试无法建立，这个目标你可以影响，但保证不了。

 

验证需求和实际软件的相符程度，同意这个举手我看看？同意吗？软件和需求相符就证明软件的质量高吗？需求就做错了，你怎么办？

 

对开发团队进行有效的考核？行吗？好象都不对。

 

软件测试的目标是什么？可能是一个很大的问号。

 

我现在提出两个目标，这两个目标可能在其他的书上，或者在网上都看不到，最近才提出来的，两个什么目标？

 

第一个，稳定控制软件产品质量的振幅，ISO做了那么多质量管理体系，它能保证单一的产品进来就肯定出去是一个优秀的产品吗？不可能。它能做什么？是以统计学的观点控制软件产品质量的振幅，你通过我的流程，出现一个高品质产品的概率高，同意吗？是概率高，不可能完全控制。

 

稳定控制软件产品质量的振幅这件事情不归测试人员管，归谁管？头长是通过SEPG组，建立度量体系，进行有效跟踪和监控实现，是统计学。

 

第二个，测试做什么？高效的提高软件测试用例的覆盖率。好的测试人员和差的测试人员有什么区别？放在日常工作中，就是你想不到，同意吗？你的组长或者你的老板永远比你想的多一点，多的那点是什么？就是测试用例的覆盖度，同意吗？我们找了两个关键字，一是高效，二是覆盖度，后面我会证明这两个怎么度量。

 

怎么样能高效？通过测试用例的复用来达到高效，以数据驱动的形式自动化测试用例可以提高效率，通过有效的测试用例设计方法，扩大覆盖率。我现在要做什么事情？首先我把软件测试的质量分解为一个目标，这个目标是高效提高软件测试用例的覆盖度，把一个复杂的问题简单化，简单为一个明确的问题。下面我又做了分解，我把高效提高软件测试用例的覆盖度分为三个指标。就是通过测试用例的复用，以数据驱动的形式自动化测试用例，通过有效的测试用例设计方法扩大覆盖率。

 

这是典型软件测试过程文档体系结构，我们来看通常情况下，我会把整个软件测试划分为几个步骤，首先最关键是软件测试策略的制订，测试策略提供几个信息，项目实施范围，可见可衡量的指标，验证方法和阶段。通常情况下，我们会把整个软件测试过程划分为单元集成系统。从所有的软件工程或者从所有方法来说，都需要怎么做呢？都需要单元集成系统，一个都不能少。通常在不同企业里面做不同程度的裁减，单元测试必须要做吗？

 

WPS1.0你相信第一个版本出现的时候会通过单元集成系统测试，我不相信，你们相信吗？我肯定也不相信，但是不影响这个产品。产品在每个阶段有不同的竞争要求。WPS刚出现的时候，是功能上的竞争，填补市场空白，只要有就OK，只要能用就OK，当竞争到一定程度，WPS到现在你能相信它不进行单元集成系统测试就可以卖吗？不可想象。你现在就是选择适合你的过程，当我们明确完策略以后，我们一般会把测试分为计划、方案、实施、报告几个阶段。计划主要解决五个W问题，谁，什么时间、什么地点，干什么事，由谁来完成，就是做资源合理分配，然后进行专项测试方案。专项测试方案就是性能测试方案，安全测试方案，易用性测试方案，加密狗测试方案等等，然后进行测试实施，测试实施主要做两个内容，首先是测试记录，通过写记录证明你执行到哪儿，没通过的写缺陷报告，整个阶段完成写阶段完成报告，包括测试评估，然后做测试结论。

 

通常情况下测试策略我们会明确以下几个内容：

 

1、明确测试需求，你要对什么进行测试，这个点很重要，重要到什么程度？这么多人做软件测试，我问大家一个问题，如果产品发布了以后，产生了质量问题，谁的问题？是测试员的问题吗？是吗？同意是测试员的问题，举手我看看，不同意是测试员的问题我看看。经过你最后一道手发布出去了，产品出现问题了，你说不是你的问题，你能解释吗？很重要一个问题要明确测试的工作范围，如果在你测试范围内发现问题，肯定是你的问题，在你测试范围外发现的问题，就不是你的问题吗？不一定。我们要明确测试工作范围，需要测试的对象，达到的目标等，可以来源于软件需求，个人经验，以前发生的错误等。我们要确定测试目标，确定测试类型和方法，测试风险分析。

 

策略完成以后，大家一定要注意，策略里面不包括人和时间，为什么不包括这两项，从项目的角度来讲，这两项变化的风险太大。测试策略中一定不包含可能变化比较频繁的要素，目的就是测试策略不允许随便修改，它确定了该项目最关键的要素，当我们确定测试策略以后，将进行测试计划的制订。测试计划包括什么呢？目标、方法、环境、工具，确定时间段，确定资源，自动化测试分析。一个项目里一定要进行自动化测试分析吗？完全没必要，自动化测试不能帮助你解决发现BUG的问题。首先大家要对自动化或者功能类自动化工具产生明确的认识，它不能帮助你发现新的BUG，它能帮助你提高效率，提高测试用例覆盖效率。

 

但计划完成以后，我们要进行专项测试方案制订，我们要把计划策略中所有需求拿出来，进行备案，然后细化测试规矩等等。

测试实施包括测试记录和测试报告。

 

阶段总结报告要提供测试执行株距，证明测试过程完整的执行了测试计划内容，提供测试分析数据，证明系统的质量达到要求或未达到要求，如果比较重要的系统要提供模拟测试，比如说银行或者电信系统，当它一个周期是一个月的数据，如果你随意切换，你的系统不行怎么办，有一种方式就是这一个月的数据，原来的系统跑一遍，新上线的系统在另外一套系统跑一遍，两个出现的结果对比一下，走一个月就可以顺利切换了。

 

其次提供遗留问题及后续的解决办法，刚才都问到一个问题，测试什么时候结束，测试结束有两个必要条件，缺陷处于收敛状态，所有遗留问题都有了明确的解决方案。

 

刚才跟大家简要的说了一下我们认可的，或者我们觉得比较合适的一个软件测试过程控制方法，谈到度量，谈到对过程的控制，我们首先要明确过程是什么，刚才我们过程摆在那儿了，我们再来看。

 

我们把复杂的问题明确为两个问题，一是质量振幅，二是高效提高软件测试用例覆盖率。质量振幅如何控制，针对软件测试过程的符合度进行控制，通过由EPG组进行监控，SQA进行检查，检查报告就是振幅的一个指标，不在我们讨论范围之内。

 

我们谈测试相关的东西，高效提高软件测试用例的覆盖率，高效和覆盖度是我们关注的目标。通过这两个目标，我们去抓整个的软件测试过程，我们看怎么抓。

 

软件测试工作如何提出效率，可能的指标有什么？我只能说可能的指标，因为度量也好，过程也好，针对每个公司都是个性化的过程，比如说我们通常在网上能拿到的数据，最完备的过程是什么？是RUP，一张光盘，上头有整个从项目需求一直到最后部署，整套的文档，整套的模板，你能用吗？我跟IBM的工程师聊过，RUP的精华在什么？精华在裁减，你只有了解的全部，了解到本企业的现状才知道自己用什么，不要盲目套用任何一套你看的好的方法或者模板，必须要个性化定制。这块谈到的目标只是参考。可复用的产品多，可能提高效率吧，如果每次做项目能用到复用的产品很多，一定会提高效率，我们的指标就是测试资源复用率，包括计划、方案、用例，自动化测试脚本等等一系列，你在一个项目中产生的所有文档、代码或者思想，这些复用率有多高，拿一个指标控制。

 

无用的工作少，上礼拜我们在对面开测试时代的交流会，有几个人，测试用例我们写到什么程度，大家想象，如果你只有一个礼拜的测试时间，五个工作日，你花三天写测试用例，两天做测试执行，合理吗？五天全部做测试执行，我不写测试用例，合理吗？假设一年我八个月写测试用例，四个月做执行，合理吗？我一年不写测试用例，只执行，合理吗？所以当你看你项目的时候，绝对没有一个统一的方法、指标让你去做，要根据目标来决定。

 

上午在说我推崇一句话，这句话是两部分，第一部分是目标决定过程，一定要注意，目标决定过程，第二部分，过程决定质量。为什么目标决定过程？跟敏捷开发方法的理念是一样的，你想做什么，想达成什么样的结果，就让过程不多不少的配合你，你要做什么，完全跟你的目的有关系，不要做过多或者过少的工作。所以它都是定制化的过程。无用的工作少，你要做度量，比如说以前我作为测试组，或者你们作为测试人员，有多少测试人员在写文档，我指的文档是用户使用手册说明书，举手我看看。在小组织小工作量下是没问题的，如果你的测试工作或者测试有效工时三分之一以上都被明显跟工作质量无关的工作就有问题了，所以我们要拿到有效测试工时率。

 

和开发的配合好，在研发过程中，测试是辅助流程，还是主流程？辅助流程，如果你是辅助流程，你当然要跟主流程配合。跟主流程如何配合，首先协作点的数量，你跟开发人员有多少次交互，我指的正式交互，不是你平常没事吃饭、打球、聊天，而是在技术方案中你跟开发人员做的交互有多少点，协作点的正确率，正确率主要指时间和质量，1月1号说给你协作点，1月1号没给你，这个协作点没有成功，如果给了你，你没有评估，这也没有成功。

 

测试项目进度贴合度好，什么叫贴合度好？第一，我没看到过没有发现BUG的项目，有没有这样的测试人员，我测试一个产品压根没发现BUG。项目变化率，你作为项目经理，你写了份测试计划，你的计划会有多少次变化，变化的程度会是怎样的，也是判断你的效率。工期贴合率，你们之间的工期是否有很好的贴合。

 

自动化测试提高效率，首先自动化测试不能发现BUG，它可以把你的手工测试用例自动化，自动化手工测试用例的数量，跟手工用例的比例，这个比例越高越好，但一定要考虑成本和产出，值不值得这样做。以前我看一个项目，它的测试经理给我们展示QDP做的自动化测试，从头到尾自动化，所有的操作不用人工干预，我看了挺高兴，后来我问他，它发现过BUG吗？没发现，你平常测试用它吗？也不用。做它干什么？演示。你就看到鼠标在那儿点，一个流程一个流程完成。为什么这么做？处于测试人员自我的爱好，他觉得这个有意思，技术含量高，想学这门技术，也给老板做演示，老板看了很高兴，它不产生实际的效率。

 

测试用例的覆盖度，测试用例的覆盖度是一个求积分的过程，什么叫求积分的过程？可以无线接近，但是永远到达不了，只可能无限接近，但不可能等于。

 

有效度量测试用例覆盖度增加的条件：

 

1、现有测试用例进行了有效的管理，首先测试用例你需要用工具或者手段管理起来，一条一条放在那儿，做一个基线。

 

2、明确测试用例编写的颗粒度，大家都有这种感觉，你写测试用例，你测试这个产品的时候，你十条测试用例就测试完了，有人写三十条，你就觉得奇怪，我觉得十条已经是局限了，怎么你能写到三十条，你去看他的用例，发现这也能算一条，这是组织内部测试用例颗粒度没有达成一致，颗粒度你可以跟代码行数对应，跟功能点对应，组织内部测试用例颗粒度要统一，保证所有人员大致是一致的。

 

3、单个功能点都进行了有效的规整，确定最小测试范围。你如果做测试用例的度量，需要保证单一个功能点进行了规整。

 

4、提高的方式放在功能点的组合和测试数据的增加上，如果你想提高效果，很重要的两个目标，就是功能点的组合增加了多少，测试数据又增加了多少。

 

5、每轮新增测试用例量和率，通常情况下测试一个软件，你的测试用例要跑好几轮，三到五轮，有的可能更多，每轮会新增一些用例，这些新增的量和率是多少，如果在组织稳定的时候，新增数量不会太大，如果组织不稳定，或者产生新的功能点比较多的时候，新的功能点组合比较大，这个率就会比较高。对于你进行一个项目控制也是有借鉴意义的。

 

软件测试过程的定制是一个个性化很强的工作，每个企业都应该不一样，如果一样了，就会有问题，指标确定确立不能照抄，你抄没问题，你照着人家的进行，就有很大问题，需要根据能力成熟度进行有效的分析和定制。