基于价值的软件测试管理作者软件测试是做什么的

软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。

使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别. 它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。

Grenford J.Myers曾对软件测试的目的提出过以下观点: (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功的测试是发现了至今为止尚未发现的错误的测试。

然而,这种观点指出测试是以查找错误为中心,而不是为了演示软件的正确功能.但是只从字面意思理解,可能会产生误导,认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上并非如此!

(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进；

(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性；

(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法软件测试完整分类，参见：软件测试的完整分类

以上的都是官话！其实说白了，软件测试就是在开发人员做出软件投放市场前，尽可能早的找出软件当中所存在的BUG！因为任何软件在理论上来说都是存在问题的，都不是完美的！尽早的找出漏洞，公司的损失也就越低！这也就是软件测试人员越来越受重视的原因！

其实软件测试是一种相当乏味枯燥的工作，一般面公司都比较偏向稍微内向的人，另外测试人员还要具备相当的口才，方便与开发人员还有客户交流！

软件测试工程师具体是干什么的？

1.负责公司软件产品的黑盒测试，具体又细分为软件新增功能的测试、软件bug纠正后的测试以及新版本发布前的测试。

2.负责测试计划、测试用例及测试报告等文档的编写

3.负责bug识别、归类、跟踪到解决的整个过程并以记录形式提交备查

4.使用ACT等负载测试工具进行压力测试

开发一个好的软件，40%以上的时间用在测试上,所以软件测试工程师非常重要,用我们的话来说很吃香。现在从事程序员的人有很多,做测试工程师的人少点,工作压力不太大

测试工程师应该具备的三项基本素质[1] 很多年轻或者刚刚从事测试工作的工程师，经常会问：“测试工程师需要什么技能或者具有什么素质才是合格的？”与开发人员相比，测试人员不但需要一技之长，还需要掌握诸如操作系统、数据库、网络等多方面的知识。

经过这几年的发展，国内IT公司的测试水平有了很大的提高，但是与此同时，很多测试工程师也迎来了个人的发展瓶颈：很多人从测试工程师做到了测试经理的职位，不知道下一步如何发展；或者每天机械地从事着功能测试工作。

根据作者多年的经验，一个有竞争力的测试人员要具有下面三个方面的素质：

计算机专业技能

计算机领域的专业技能是测试工程师应该必备的一项素质，是做好测试工作的前提条件。尽管没有任何IT背景的人也可以从事测试工作，但是一名要想获得更大发展空间或者持久竞争力的测试工程师，则计算机专业技能是必不可少的。计算机专业技能主要包含三个方面：

测试专业技能

现在软件测试已经成为一个很有潜力的专业。要想成为一名优秀的测试工程师，首先应该具有扎实的专业基础，这也是本书的编写目的之一。因此，测试工程师应该努力学习测试专业知识，告别简单的“点击”之类的测试工作，让测试工作以自己的专业知识为依托。

测试专业知识很多，本书内容主要以测试人员应该掌握的基础专业技能为主。测试专业技能涉及的范围很广：既包括黑盒测试、白盒测试、测试用例设计等基础测试技术，也包括单元测试、功能测试、集成测试、系统测试、性能测试等测试方法，还包括基础的测试流程管理、缺陷管理、自动化测试技术等知识。

软件编程技能

“测试人员是否需要编程？”可以说是测试人员最常提出的问题之一。实际上，由于在我国开发人员待遇普遍高于测试人员，因此能写代码的几乎都去做开发了，而很多人则是因为做不了开发或者不能从事其它工作才“被迫”从事测试工作。最终的结果则是很多测试人员只能从事相对简单的功能测试，能力强一点的则可以借助测试工具进行简单的自动化测试（主要录制、修改、回放测试脚本）。

软件编程技能实际应该是测试人员的必备技能之一，在微软，很多测试人员都拥有多年的开发经验。因此，测试人员要想得到较好的职业发展，必须能够编写程序。只有能给编写程序，才可以胜任诸如单元测试、集成测试、性能测试等难度较大的测试工作。

此外，对软件测试人员的编程技能要求也有别于开发人员：测试人员编写的程序应着眼于运行正确，同时兼顾高效率，尤其体现在与性能测试相关的测试代码编写上。因此测试人员要具备一定的算法设计能力。依据作者的经验，测试工程师至少应该掌握Java、C#、C++之类的一门语言以及相应的开发工具。

网络、操作系统、数据库、中间件等知识：

与开发人员相比，测试人员掌握的知识具有“博而不精”的特点，“艺多不压身”是个非常形象的比喻。由于测试中经常需要配置、调试各种测试环境，而且在性能测试中还要对各种系统平台进行分析与调优，因此测试人员需要掌握更多网络、操作系统、数据库等知识。

在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理，尤其要掌握一些网络环境的配置，这些都是测试工作中经常遇到的知识。

操作系统和中间件方面，应该掌握基本的使用以及安装、配置等。例如很多应用系统都是基于Unix、linux来运行的，这就要求测试人员掌握基本的操作命令以及相关的工具软件。而WebLogic、Websphere等中间件的安装、配置很多时候也需要掌握一些。

数据库知识则是更应该掌握技能，现在的应用系统几乎离不开数据库。因此不但要掌握基本的安装、配置，还要掌握SQL。测试人员至少应该掌握Mysql、MS Sqlserver、Oracle等常见数据库的使用。

作为一名测试人员，尽管不能精通所有的知识，但要想做好测试工作，应该尽可能地去学习更多的与测试工作相关的知识

软件测试报告怎么写

摘要

测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。本文提供测试报告模板以及如何编写的实例指南。

关键字

测试报告缺陷

正文

测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

下面以通用的测试报告模板为例，详细展开对测试报告编写的具体描述。

PARTⅠ 首页

0.1页面内容：

密级

通常，测试报告供内部测试完毕后使用，因此密级为中，如果可供用户和更多的人阅读，密级为低，高密级的测试报告适合内部研发项目以及涉及保密行业和技术版权的项目。

XXXX项目/系统测试报告

报告编号

可供索引的内部编号或者用户要求分布提交时的序列号

部门经理 ______项目经理______

开发经理______测试经理______

XXX公司 XXXX单位（此处包含用户单位以及研发此系统的公司）

XXXX年XX月XX日

0.2格式要求：

标题一般采用大体字（如一号），加粗，宋体，居中排列

副标题采用大体小一号字（如二号）加粗，宋体，居中排列

其他采用四号字，宋体，居中排列

0.3版本控制：

版本作者时间变更摘要

新建/变更/审核

PARTⅡ 引言部分

1.1编写目的

本测试报告的具体编写目的，指出预期的读者范围。

实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。

提示：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。

1.2项目背景

对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。

1.3系统简介

如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。

1.4术语和缩写词

列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。

1.5参考资料

1．需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。

2．测试使用的国家标准、行业指标、公司规范和质量手册等等

PARTⅢ 测试概要

测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分）

2.1测试用例设计

简要介绍测试用例的设计方法。例如：等价类划分、边界值、因果图，以及用这类方法(3-4句)。

提示：如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念，顺便说一句，在这里写上一些非常规的设计方法也是有利的，至少在没有看到测试结论之前就可以了解到测试经理的设计技术，重点测试部分一定要保证有两种以上不同的用例设计方法。

2.2测试环境与配置

简要介绍测试环境及其配置。

提示：清单如下，如果系统/项目比较大，则用表格方式列出

数据库服务器配置

CPU：

内存：

硬盘：可用空间大小

操作系统：

应用软件：

机器网络名：

局域网地址：

应用服务器配置

…….

客户端配置

…….

对于网络设备和要求也可以使用相应的表格，对于三层架构的，可以根据网络拓扑图列出相关配置。

2.3测试方法(和工具)

简要介绍测试中采用的方法(和工具)。

提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。

敏捷开发模式用的测试是什么模型

【编者按】敏捷的理念已经深入人心，开发过程已经渐入佳境，测试的处境却稍显尴尬。测试从业者应该何去何从，怎样才能拥抱敏捷，体现出自己新的价值呢？InfoQ特地邀请了来自Google的敏捷测试专家段念，为读者答疑解惑，希望所有测试从业者可以从中得到自己的答案。更多关于敏捷测试的内容，请访问InfoQ中文站敏捷测试相关内容。

在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：到底？，敏捷软件开发还需要测试工程师吗？。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。

确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的频繁交付，还是对可工作的软件的度量，或是敏捷开发实践中的测试驱动开发，行为驱动开发，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中，测试不再是一个单独的、和开发独立的过程，而是变成了驱动开发、衡量产出的主要的手段，成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之，敏捷软件测试更多的是一种理念，而非过程。

既然是这样，为什么我们还要在这个专栏中专门来讨论敏捷软件测试？本人接触过不少软件开发和测试工程师，他们所处的组织有的正在努力向敏捷开发转型，有的已经实践了一段实践的敏捷开发，但由于由来已久的工作习惯，他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用，而是有意无意的将测试仍然看作是与开发截然分开的下一个阶段，导致在实践敏捷开发的过程中遇到种种问题：要么是忽略了代码质量，导致在频繁的迭代过程中，每一个迭代的问题层出不穷；或是沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的进度。在这种情况下，专门来讨论敏捷软件开发中的测试，也就是敏捷软件测试的话题，对这些工程师应该会有一些帮助。

那么，到底？很难给敏捷测试下一个精确、完善的定义，在本人看来，接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中，我们主要从宏观的角度来描述敏捷软件测试，而在本专栏的后续文章中，我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。

使用Dashboard、燃尽图等方式展示当前工作与可交付产品之间的距离

建立单元测试覆盖率等度量指标

共享质量目标意味着质量责任由所有工程师共同承担

开发测试应该建立一定的测试覆盖率标准，例如，在单元测试这个级别上，建立60%或80%的覆盖率要求

通过使用TDD、BDD等技术，保证产品和代码的可测试性

建立足够多的自动化测试，保证测试能够满足快速迭代的要求

检查表提到了团队、反馈、质量文化和开发测试四个方面的内容，在本人看来，这四个方面体现的就是敏捷软件测试与传统软件测试的最大的不同。传统软件测试关注的是通过尽可能完备的覆盖去发现尽可能多的问题，把测试和开发当成是两个独立的过程，测试是对开发阶段产生成果的验证

。而敏捷软件测试则建立了一种不同的质量文化：测试的目的是为了保证产品快速发布，也就是对生产率本身的提高。基于验证的出发点必然会要求测试与开发的独立，以及尽可能客观和完备的度量产品质量；而基于生产率的出发点则要求建立敏捷的团队，要求测试与开发尽可能紧密，要求建立具有高度可测试性的软件，以及基于这些的高度自动化测试。

在检查表列出的所有项目中，质量文化是基础，团队是敏捷软件测试得以实施的条件，反馈和开发测试则是敏捷软件测试的具体方法。当然，你可以可以从敏捷的核心价值观来阶段这些项目：团队关注的是沟通与尊重；反馈直接对应于反馈；质量文化基于勇气（承担质量责任的勇气）与尊重；而开发测试则是反馈与简单的具体体现。

另一个在本文最初提出来的问题是：敏捷软件开发还需要测试工程师吗？，对这个问题，业界有不同的观点。有人认为需要，因为总有一些是需要测试工程师的技能完成的工作；当然，也有人认为不需要，因为敏捷开发中的测试注重开发测试与自动化测试，开发工程师就可以自己搞定与测试相关的工作。在实践中，那些大规模实践敏捷开发的公司（例如Google），倾向于在组织中设置数量较少的测试工程师，在项目中分配较少的测试资源，甚至对某些项目，完全不使用测试工程师。

就我的个人实践经验，对大部分的项目，尤其是为明确的客户开发的项目，需要在敏捷开发团队中设置专职的测试工程师，因为：

测试与开发具有不同的思维方式：测试更注重全面的验证和检查一个系统，而开发工程师往往很难在大的范围内建立这样的思维方式。因此，无论是从系统的层面验证产品，或是从应用系统的角度发现值得测试和验证的点（access point），专职的测试工程师都更有效。

专职的测试工程师能够更关注于测试基础，建立测试需要的基础架构：由于测试工程师具有更好的对测试的理解，通常他们能够更多的考虑测试的需求而开发适合项目的测试基础架构（自动化测试框架），而开发工程师可以使用这些框架来建立面向功能或代码的测试。

但是，不得不说的是，敏捷开发对开发和测试工程师都提出了更要的要求，尤其是对测试工程师而言，传统的只能精确模拟用户操作的测试工程师，因为不能为产品带来生产率的提升，在敏捷开发的团队中，很难有所作为。在本专栏的后续文章中，我们会进一步讨论测试工程师在敏捷软件开发中的工作和任务。

关于作者段念：Google中国高级测试经理，毕业于华中科技大学，先后在通讯、嵌入式软件、互联网等多个行业的国内外知名公司中从事软件开发与测试工作。对软件测试中的技术和管理工作有独到见解，对软件测试团队管理、自动化测试、性能测试与开发测试有较多研究。

软件测试具体是做什么的？（面试人员说刚开始做的是处理一些代码非常枯燥的事）请有做过工作的过来人指点

　　(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进；

　　(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性；

　　(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法软件测试完整分类，参见：软件测试的完整分类

　　其实软件测试是一种相当乏味枯燥的工作，一般面公司都比较偏向稍微内向的人，另外测试人员还要具备相当的口才，方便与开发人员还有客户交流！

软件测试的测试内容

软件测试主要工作内容是验证（verification）和确认（validation），下面分别给出其概念：

验证(verification)是保证软件正确地实现了一些特定功能的一系列活动，即保证软件以正确的方式来做了这个事件(Do it right)

1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程。

2.程序正确性的形式证明，即采用形式理论证明程序符合设计规约规定的过程。

3.评审、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。

确认（validation）是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件做了你所期望的事情。（Do the right thing）

1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性。

2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问题。

软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期间各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。等价类

1.定义

是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试用例设计方法。

2.划分等价类

等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

1)有效等价类

是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

2)无效等价类

与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

3.划分等价类的标准

1)完备测试、避免冗余；

2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合；

3)并是整个集合：完备性；

4)子集互不相交：保证一种形式的无冗余性；

5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到相同的执行路径。

4.划分等价类的方法

1)在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

如：输入值是学生成绩，范围是0～100。

2)在输入条件规定了输入值的集合或者规定了必须如何的条件的情况下，可确立一个有效等价类和一个无效等价类。

边界值

1. 定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

2. 与等价划分的区别

1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

3. 边界值分析方法的考虑：

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

4. 常见的边界值

1) 对16-bit 的整数而言 32767 和 -32768 是边界

2) 屏幕上光标在最左上、最右下位置

3) 报表的第一行和最后一行

4) 数组元素的第一个和最后一个

5) 循环的第 0 次、第 1 次和倒数第 2 次、最后一次

5. 边界值分析

1) 边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

例：测试计算平方根的函数

--输入：实数

--输出：实数

--规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息平方根非法-输入值小于0并返回0；库函数Print-Line可以用来输出错误信息。角度细分

从是否关心软件内部结构和具体实现的角度划分（按测试分类）

A.白盒测试

B.黑盒测试

C.灰盒测试

从是否执行程序的角度

A.静态测试

B.动态测试。

阶段细分

从软件开发的过程按阶段划分有

A.单元测试

B.集成测试

C.确认测试

D.系统测试

E.验收测试

F.回归测试

G.Alpha测试

H.Beta测试

* 测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发布测试。

* 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。

*集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。

* 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。

* 系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。

单元测试 (Unit Testing)

* 单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。

* 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

1. 单元测试的内容

* 在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。

(1) 模块接口测试

* 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：

– 调用本模块的输入参数是否正确；

– 本模块调用子模块时输入给子模块的参数是否正确；

– 全局量的定义在各模块中是否一致

* 在做内外存交换时要考虑：

– 文件属性是否正确；

– OPEN与CLOSE语句是否正确；

– 缓冲区容量与记录长度是否匹配；

– 在进行读写操作之前是否打开了文件；

– 在结束文件处理时是否关闭了文件；

– 正文书写/输入错误，

– I/O错误是否检查并做了处理。

(2) 局部数据结构测试

* 不正确或不一致的数据类型说明

* 使用尚未赋值或尚未初始化的变量

* 错误的初始值或错误的缺省值

* 变量名拼写错或书写错

* 不一致的数据类型

* 全局数据对模块的影响

(3) 路径测试

* 选择适当的测试用例，对模块中重要的执行路径进行测试。

* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。

* 对基本执行路径和循环进行测试可以发现大量的路径错误。

(4) 错误处理测试

* 出错的描述是否难以理解

* 出错的描述是否能够对错误定位

* 显示的错误与实际的错误是否相符

* 对错误条件的处理正确与否

* 在对错误进行处理之前，错误条件是否已经引起系统的干预等

(5) 边界测试

* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。

* 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。

2. 单元测试的步骤

* 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。

– 驱动模块 (driver)

– 桩模块 (stub) ── 存根模块

* 如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。

* 对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

集成测试（Integrated Testing）

* 集成测试 (组装测试、联合测试）

* 通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：

– 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

– 一个模块的功能是否会对另一个模块的功能产生不利的影响

– 各个子功能组合起来，能否达到预期要求的父功能；

– 全局数据结构是否有问题；

– 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。

* 子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。

* 通常，把模块集成成为系统的方式有两种

– 一次性集成方式

– 增殖式集成方式

1. 一次性集成方式(big bang)

* 它是一种非增殖式组装方式。也叫做整体拼装。

* 使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。

2. 增殖式集成方式

* 这种集成方式又称渐增式集成

* 首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统

* 在集成的过程中边连接边测试，以发现连接过程中产生的问题

* 通过增殖逐步组装成为要求的软件系统。

(1) 自顶向下的增殖方式

* 这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。

* 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。

* 选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。

(2) 自底向上的增殖方式

* 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。

* 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。

* 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。

* 一般来讲，一种方式的优点是另一种方式的缺点。

(3) 混合增殖式测试

* 衍变的自顶向下的增殖测试

– 首先对输入/输出模块和引入新算法模块进行测试；

– 再自底向上组装成为功能相当完整且相对独立的子系统；

– 然后由主模块开始自顶向下进行增殖测试。

* 自底向上-自顶向下的增殖测试

– 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试；

– 然后对含写操作的子系统做自顶向下的组装与测试。

* 回归测试

– 这种方式采取自顶向下的方式测试被修改的模块及其子模块；

– 然后将这一部分视为子系统，再自底向上测试。

关键模块问题

* 在组装测试时，应当确定关键模块，对这些关键模块及早进行测试。

* 关键模块的特征：

① 满足某些软件需求

② 在程序的模块结构中位于较高的层次（高层控制模块）

③ 较复杂、较易发生错误

④ 有明确定义的性能要求。

确认测试（Validation Testing）

* 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。

* 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。

1. 进行有效性测试（黑盒测试）

* 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。

* 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。

* 通过实施预定的测试计划和测试步骤，确定

– 软件的特性是否与需求相符；

– 所有的文档都是正确且便于使用；

– 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试

* 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：

– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。

– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。

2. 软件配置复查

软件配置复查的目的是保证软件配置的所有成分都齐全；

各方面的质量都符合要求；

具有维护阶段所必需的细节；

而且已经编排好分类的目录。

应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。

系统测试（System Testing）

* 系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

* 系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。

验收测试（Acceptance Testing）

* 在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。

* 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。

* 由用户参加设计测试用例，使用生产中的实际数据进行测试。

* 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。

*确认测试应交付的文档有：

– 确认测试分析报告

– 最终的用户手册和操作手册

– 项目开发总结报告。 1、制定测试计划

2、编辑测试用例

3、执行测试用例

4、发现并提交BUG

5、开发组修正BUG

6、对已修正BUG进行返测

7、修正完成的BUG将状态置为已关闭，未正确修正的BUG重新激活单元测试

单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位：模块。

集成测试

集成测试也称联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。

系统测试

系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。

回归测试

回归测试指在软件维护阶段，为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。

与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用，因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。 V模型

测试阶段:

单元测试

集成测试

系统测试

实现意义

V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系。

从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。

用户需求验收测试

需求分析和系统设计确认测试和系统测试

概要设计集成测试

详细设计单元测试

编码

V模型问题

1.测试是开发之后的一个阶段。

2.测试的对象就是程序本身。

3.实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。

4.整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度

W模型

W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

H模型

H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行，并且可以根据被测物的不同而分层次进行。

这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程，例如设计流程或者编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。

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

X模型

X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

求一篇项目管理英文文献及翻译

　　希望对你有用，然后给点分数给我。

　　外文资料名称： Value-Based Management of

　　Software Testing

　　外文资料出处： Institute of Software

　　Technology & Interactive System

　　附件： 1.外文资料翻译译文

　　2.外文原文

　　基于价值的软件测试管理

　　鲁道夫,斯蒂芬,保罗

　　摘要: 根据研究表明测试已经成为软件开发过程中一个很重要的环节，它占据了整个软件开发成本的百分之三十到五十。测试通常不是用来组织商业价值的最大化，也不是肩负着项目的使命。路径测试、分支测试、指导测试、变换测试、场景测试以及需求测试等对于软件的所有方面都是同等重要的。然而在实践中百分之八十的价值往往来自百分之二十的软件。为了从软件测试中得到最大的投资回报，测试管理需要最大化它的价值贡献。在本章，我们将更加促进对基于价值的测试的需要，描述支持基于价值的测试管理的实践，勾画出基于价值的测试管理的框架，并举例说明该框架。

　　关键词: 基于价值的软件测试,基于价值的测试,测试成本,测试利益,测试管理

　　11.1 前言

　　测试是软件质量保证过程中最重要和最广泛使用的方法。校验和验证旨在通过综合分析, 测试软件确保其正确运行功能，确保软件的质量和软件的可靠性。在IEEE610.12(1990)中,测试被定义为在规定条件下对执行的系统或者组件进行观察和记录,并对系统或者组件进行评价的活动。

　　测试在实践过程中被广泛的使用，在保证质量策略的诸多组织中扮演着重要的角色。软件影响着成千上万人的日常生活，担负着艰巨的任务。因此软件在不久的将来将显得尤其的重要。研究表明，测试通常消耗软件开发成本的30%至50%。对于安全危急系统，甚至更高的比例也不足为奇。因此软件测试具有挑战的就是寻找更多的有效途径进行有效的测试。

　　软件测试管理的价值在于努力减少测试成本和满足需求。有价值的测试管理对于项目目标和商业价值也能有很好的向导。在第一章，Boehm 列举了很多方面的潜在测试成本。该例子说明了利用客户结账类型的7%的成本来完成50%的软件测试利益。尽管百分百测试是一个不太切实际的目标, 然而通过调整测试方法, 仍有很大的空间来改进和节省达到预期的价值。基于软件工程的价值动力在于目前软件工程的实践研究都是把需求, 测试案例, 测试对象和产品缺陷看的同等重要。这对测试显然是正确的，它对产品价值间接的做出贡献。开发和测试的分离使得这问题显得更为突出。测试往往是一个纯粹的技术问题，将使得测试和商业决策之间曾解链的关系变的更加紧密。本章主要描述了提高基于价值的测试管理的需求, 解释其基本要素, 讨论现有的实例来支持基于价值的测试, 以及基于价值的测试管理的基本框架。本章接下来部分的基本结构如下：11.2节讨论测试管理的贡献价值； 11.3节讨论已测案例对于测试管理的支持； 11.4节用例子描述基于价值的测试管理的框架。本章最后将对具体的再作更进一步的研究。

　　基于价值测试的描述

　　基于价值的校验和验证的目标被定义为确保软件的实施能够满足其预期的目标价值利益。如果我们从价值的角度去考虑，那么测试的贡献应该在哪呢？从根本上来说, 可以从两个方面来考虑: 内部方面包括测试成本以及测试效益, 外部方面强调未来系统的威胁以及机遇。对于基于价值的测试，其关键就是要把这两个方面结合起来,也就是说通过客户和市场需求调整内部测试的过程。

　　为了使内部和外部两方面因素相结合，只专注于技术方面的测试显然是不恰当的。相反，测试管理需要有个全局的把握。

　　例41描述了测试管理内外双方面之间的依赖关系。内部方面的就如同测试经理对整个项目的控制。这方面的费用主要来自于软件测试实践以及短期长期的测试。而外部方面被认为是测试主管所能控制以外的一些利益和参数数据.基于价值的软件测试管理使得测试能够满足以利益为重的价值主张，以及使整个小组聚焦在有价值的测试方向上。

　　对于软件测试的外部观点的首要问题是“我们如何确保软件系统的价值目标？” 这目标就是通过协调价值主张来测试软件集中的有价值部分，最重要的品质以及项目风险的及时调整等.回答这样的问题包括市场机遇，项目的价值主张以及成本效益。参考第一章关于机遇和风险的详细介绍以及参考第七章的价值主张的引出与调和。

　　内部观点是建立在价值主张的利益之上，以及测试的预算代表着整个项目的一个大概水平。这主要的问题就是如何把测试作为一项投资活动。为了能够高效迅速的测试及降低开发预算。适当的内外部交流协调能够满足测试的利益价值。

　　测试的价值贡献

　　测试与其他的开发环节诸如代码和用户界面设计相比，它不能立即对产品创造价值。然而测试提供和支持软件开发过程中产生的有价值的任务活动。理解测试贡献价值的关键点在于测试的贡献效应。测试的贡献建立了测试与最终产品价值利益之间的关系。

　　最直接的客户是直接与测试小组有密切联系的程序开发者和项目主管。在基于价值的软件工程测试过程中的集中力量是顾客和用户（见第七章）。顾客和用户通过设定语境和范围来进行测试达到测试的价值目标。

　　测试的客户

　　开发人员,项目主管,质量主管,顾客,分析者,最终用户或者维修人员们都得益于软件系统的分析,依靠反馈来检测问题,降低其不确定性,做出相关的决定来加快产品进程。

　　下面的例子显示了不同组对于测试需求的反馈信息：

　　顾客和用户关于多大程度上需求一致是否满意以及在多大程度上满足软件的价值利益.测试还对项目的进程提供可见性和洞察力.通过测试的结果可以了解已通过的测试案例.当验收测试时出现不实用的或者失败的显示在实际环境中才能出现的问题，α和β测试提供了一个更加坚实的基础来验证结果。

　　销售和产品主管从测试计划、定价、促销和分配方面获取相关的信息。产品实际的质量与顾客和用户所期望的质量之间的差异很容易会导致误解和错误的设想以至于降低或者阻止了真正价值的实现。为了能够成功地达到这些期望以及满足个人或组织的目标，通过客户需求来调整产品设计满足某些功能。

　　对于项目主管，测试支持了风险管理和项目进程的估计。重点是识别和排除潜在的价值破坏和抑制价值功绩的风险。早期的大幅降低项目绩效的严重缺陷,是一个主要的目的。测试降低了不确定性和帮助项目主管对于清除缺陷、系统稳定性以及产品更新发布能够作出更好、更明智的决定。

　　质量主管对于问题的识别以及对特定问题的动态趋势较为感兴趣。测试结果对于项目评估、对于质量策略的保证以及进程的改进提供了帮助。Rosenberg讨论了测试如何对确保质量作出贡献并展示了测试问题如何验证如何修正以此来提升项目进程。开发者和用户了解相关问题的当前状态，并且提供相关数据来衡量及预测软件的质量和可靠性。

　　开发人员通常需要获取反馈信息来验证测试实施是否完整，是否符合标准，是否满足质量要求。为了保证稳定性，测试提供了相关缺陷的详细信息，提示测试失败的原因。除此之外，测试对于项目缺陷的改进作出反馈。例如，通过相关的修改以后需要测试其是否随着相关的改动使原先的功能有所改动或者出现衰退的情况，这些都是需要注意的。

　　对于需求工程师来说，测试对于验证和确认需求是很有价值的。Weinberg曾指出“最有效的方法之一就是通过测试案例就象测试一个完整的系统来形成测试需求”。黑盒测试通过其需求帮助能够保证它们的完整性，准确性，透明性及简明性等。因此测试能够提升要求且向着测试驱动的方向发展。

　　简言之，测试能够通过降低计划的不确定性和风险性来提升利益，作出相关的决定，努力控制把不必要的消耗减少到最低程度(内部原因)。尤为重要的是，它有助于实现预期的价值利益。这些利益的得来也并不是免费的，测试的代价通常也是有意义的(外部原因).测试可以被理解为购买信息，也可被认为降低成本风险，减少不确定性的投资活动。在成本和利益的投资上需要对测试需求作出相关的决定。因此接下来的两个问题是：什么是测试成本？什么是价值活动的测试利益？

　　受到字数的限制，英文部分不能贴上来了，你如果觉得可以的话，可以留下发邮件460512957@qq.com联系

软件测试面试人家问做过什么项目怎么说

对应自己的项目去熟悉每一个模块，这个介绍基本跟你简历上面的项目介绍可以一致。

继续问：在这个项目中负责什么？

说明一下自己在项目中负责的模块测试。包括任务安排、用例编写、环境搭建

继续问：如果他问你是如何测的呢？

挑某个最熟悉的模块具体说

继续问：项目做了多久？现在上线的？上家公司多少测试人员？多少开发？公司规模？

这个提前准备好

转载请注明出处51数据库 » 基于价值的软件测试管理作者软件测试是做什么的