关注51Testing
如何制定一个有效的测试策略
发表于： 10:26 &作者：Jimmy Bogard & 来源：51Testing软件测试网采编
推荐标签：
　　在近期的一个大型项目中，我们在初期就制定了目标,我们不想让很多的QA人员手动我们的软件。通过手工测试来发现漏洞是非常耗时的，成本也很昂贵, 尝试尽可能从软件内部着手构建高质量的产品。这并不是说,手工测试应经无用武之地, 手动测试常常能触发某些你无法预期到的软件使用行为。　　这是一个18个月左右的长期项目, 后续还会有持续更新。先前我们就发现,一个好的对项目的成功是至关重要的,特别是让我们的团队能够：1）随着时间的推移持续提高我们的效率,2)有信心应对我们的应用程序的大大小小的变更。　　为了建立一个有效的策略，我们花了相当长一段时间。这主要是因为我们不得不如何在应用程序的每一层来设计我们的应用程序的可测试性。我们的团队成员之前都有很丰富的TDD经验,但这并不是我们需要创建一个有效的测试策略的唯一技能。　　测试的层次　　为不同的测试分类是很麻烦的。你需要有、集成测试、、验收测试,缓慢测试,快速测试,界面测试,等等。我们发现我们的测试属于三个主要类别:　　*系统测试　　*皮下测试　　*单元测试　　每个测试所测的内容的视角都是不同的。一个完整通过外部应用程序,测试诸如浏览器,文件下拉菜单,队列,WinForms应用程序这类问题。　　皮下测试直接针对用户界面以下的内容。在一个应用程序的环境中, 我们的我们用例的其中一个皮下测试是在所有的真实的类和实现都部署到位的前提下，通过命令行处理器发送的表单对象。我们绕过仅仅包含界面逻辑的控制层,直接到领域层。发送表单对象后,就能获取成功/失败的测试结果。　　最后,我们有单元测试。单元测试的目的是测试一个类,可以是快或慢的测试。快速测试是正常的TDD测试,用于构建类的设计。根据需要进行重复测试,但严格interaction-based测试没有多大价值,除非我们找到非常有趣的交互。我们也有缓慢的单元测试,也可以归类为集成测试。这些将是诸如库测试、持久性测试,等等。　　不同类型测试的比例，单元测试:皮下测试:系统测试在10:2:1附近徘徊。我们完成的这个项目大约有5000个单元测试，1000个皮下的测试中和500完整系统测试,使用WatiN和Gallio来驱动一个浏览器。这6000个单元/皮下测试大约10分钟执行完毕,然而500个UI测试需要大约50分钟完成。　　单元测试策略　　单元测试是在一个相当严格的TDD方式。在任何设备投入使用之前，我们都会编写测试，并使用测试驱动代码的设计。这些测试帮助识别设计问题,封装问题,代码问题等等。　　我们努力避免编写纯粹用于提供测试的代码。它们常常意味着我们有设计问题、责任错位或封装已被破坏。　　当我们进一步深入到项目管道,我们开始越来越少使用交互测试。也仅仅是满足对此真正感兴趣的人的兴趣而已。但更多的时候,我们更感兴趣的是它的副作用,而交互是一个实现细节而已。我们经常所做的反而是模拟缓慢或不可测试,如存储库,在外部服务facade,配置等。否则,我们模拟仅限于我们很感兴趣观察点。在大型项目中,它可以变得很明显,你的设计需要一个large-level重构,提取其中的概念使其更快实现交付功能。在我们最后的项目,一些概念发现包括:　　§ &AutoMapper　　§ &处理的形式作为单独的命令消息　　§ Input builders　　有了所有这些，单元测试实际上是重构的一个保障。但只有我们依赖这些测试来覆盖应用程序中所有有趣的行为时，才能起到保障的作用。为了有效地允许大型和中型的重构，我们需要额外的测试级别。
搜索风云榜
51Testing官方微信
51Testing官方微博
测试知识全知道966,690 三月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
一种有效的测试策略
一种有效的测试策略
日. 估计阅读时间:
不到一分钟
给不同的测试分类是一件令人烦恼的事。有功能测试，集成测试，单元测试，验收测试，slow tests，fast tests，UI测试...等等等等。然后我们发现属于我们的测试主要有三种类型：
它们之间的区别主要在于被测试内容的范围。系统测试指的是通过应用的外部接口进行运作，无论对象是一个浏览器，文件下拉菜单，队列，window窗体应用或者其他的什么东西。
皮下测试运行在外部用户接口之下。如果测试的是Web应用，皮下测试在我们理解就是指在真实的类以及环境部署到位的情况下，通过命令处理器进行发送的表单对象。绕过UI层逻辑，直接到达domain层。发送表单对象，抛出”成功/失败”的执行结果。
相关厂商内容
相关赞助商
ArchSummit深圳-8日，深圳&华侨城洲际酒店，
对于最底层而言，我们有单元测试。单元测试用于测试一个类，并且可以是fast test 或者 slow test中的一种。Fast Test 即是常规的TDD测试，用于增量的类设计。Test doubles曾被认为是必要的，但是除非系统交互非常值得关注，否则严格的 基于交互的测试 并不是那么有价值。我们同样也有slow 单元测试，其同样可被分类为 交互测试。当然它们同样可归类为 repository tests, persistence tests等。
单元：皮下：系统 测试在我们的测试工作中各自占的比重差不多是 10:2:1。 为了完成项目我们做了大约 5000 个单元测试，1000个皮下测试，500个使用 WaitN 以及 Gallio驱动浏览器的系统测试。6000个单元/皮下测试的执行时间大概是10分钟，而剩下的500个UI测试大概需要50分钟完成。
单元测试策略
单元测试是在严密的TDD模式下开发的。我们在功能实现之前编写单元测试，并用这些测试驱动代码设计。这些测试可以帮助发现设计问题、封装问题、代码异味等。
我们努力避免编写纯粹用于提供测试的代码。它们常常意味着我们有设计问题、责任错位或封装已被破坏。
随着我们越来越深入项目管道，我们对交互测试的重视越来越少。 如果你真的对交互感兴趣，那么通过mock进行的交互测试也仅仅是有趣而已。但更多的时候，我们更感兴趣的是附加作用，而交互只是一个实现细节。反之，我们经常做的是模拟（mock）出过慢或不可测的代码，比如存储库、基于外部服务的外观、配置类等等。否则，我们有限的模拟只是模拟了我们感兴趣的那些观察点。
在大型项目中的某些时间点，为了提取出能加快功能交付的理念，设计往往需要做大型的重构。在我们上一个项目中，我们发掘出了如下理念：
AutoMapper
将表单作为单独的命令消息处理
Input builders
有了以上这些，单元测试是重构时的保障。但只有我们依赖这些测试来捕获应用程序中所有有趣的行为时，才能有保障的作用。为了允许有效的大中型重构，我们需要增加额外的测试层级。
皮下测试策略
皮下测试，顾名思义，所有的测试都是在用户界面之下进行的。在MVC应用程序中，皮下测试是测试控制器下面的所有内容。对于Web service，一切测试都在终端下进行。皮下测试的思想是，应用程序的最上层不执行任何实际的业务逻辑，而只是外部接口与底层服务之间的连接。
皮下测试的重要性体现在我们希望在抛开如用户接口和外部服务这类外部连接点的情况下，能够在整个系统运行的同时测试业务逻辑。相对于单元测试关注小模块的设计，皮下测试关注的不涉及设计，而是测试整个系统的基本输入和输出。
要建立有效的皮下测试，我们可以尝试通过常见的逻辑流程建立uniform pinch points。例如，我们可以建立一个命令消息处理系统，或一个普通的查询界面。在最近的一个处理批处理文件项目上，批处理文件中的每一行都被转换为一条消息。然后，我们创造一条消息，发送给这个系统，然后验证处理该消息的所有异常情况。
由于皮下测试不是基于设计而是基于高级（业务）行为，它们是理想的基于场景的测试策略，如BDD或模式。如果我们要进行大的重构，我们需要这些高层次的测试，为商业行为建立全面的安全保障。由于皮下测试更关注于端对端的逻辑，所以它也是标志功能点完成的一个重要的目标点。
虽然皮下测试使我们能够安全地执行较大的重构，但它仍无法保证我们可以放心地将系统升级到生产环境。
全系统测试策略
起初，我们把全系统测试称为“UI 测试”，直到我们的项目越来越多地牵涉到集成策略。这时输入到我们系统中的不再是浏览器，取而代之的是消息，来自 REST 端点、FTP 或批处理文件。UI 测试只是全系统测试的一个子集。全系统测试背后的思想是，我们想按照软件在生产环境中的使用方式来测试它们。对于一个 MVC 应用程序来说，就是基于浏览器的测试。对于批处理文件来说，我们会使用实际的文件。对于 REST 使用实际的 HTTP 请求。对于消息则使用实际的队列和消息。
如果我们想知道，应用程序在部署到生产环境之前是否能按照预期工作，一个有效而且高效的方法是，创建一个自动化测试来测试整个系统。如果我可以让 UI 测试登录到应用程序中、创建一个订单，然后我可以验证是否产生了一个订单请求，那么我会感觉很良好。
关于全系统测试的一个常见误区是认为它就是黑盒测试。然而，全系统测试的特点在于，你必须对系统内部发生的事情了如指掌。实际上，全系统测试甚至还可以利用域模型来生成数据，而不是一个纯粹为测试目的而构建的系统后门。很多团队容易掉进去的一个大坑是，不按照与生产环境一样的代码路径来测试，这将导致系统处于古怪的、无效的、很难处理的状态。
在我们的项目中，全系统测试代码是我们在声称一个功能/故事做完之前的所写的最后代码。对于描述一个功能的“已完成”特性来说，手工测试的成本太高、而且不可靠。但是，如果我能像在生产环境一样去测试，通过完全一样的外部界面来完成，那这样的手工测试也算是成功的。
在一个未经测试过的应用程序中，作为提高覆盖率的手段，我们发现实际上最有价值的测试策略是从全系统测试开始，然后往下移，直至单元测试。我们先做最宽松、最简单的断言，然后慢慢往下移，直至单元级别的逻辑。在全新开发的应用程序中，我们倾向于不只是特别关注某一个区域，因为对于一个需要长期维护的系统来说，所有的测试都很重要。
这种测试策略确实需要一定的投资。我们发现，当我们知道这个应用程序对客户的业务有决定性作用的时候，这样的全盘考虑在特别有效。如果一个应用程序对业务有决定性作用，那它将不得不面临变更。当变更来临的时候，我们最好能安全地实施变更而不影响客户的业务。
1.& 作者简介
Jimmy Bogard是德克萨斯州Headspring公司的技术架构师,致力于研究DDD,分部式系统和其他acronym-centric design/架构/方法论的研究.同时也是AutoMapper的创始人和 MVC in Action的作者
原文来自于.LosTechies是一个公开的论坛，致力于通过一种公开且集中的途径分享技术见解和思维。并且希望所有人能够在思维讨论和借鉴中获得成就感和喜悦.
2. 译者简介
Let's trrrans 翻译小组(qq群号:)一个致力于翻译和分享业界最前沿测试技术以及测试理念的翻译小组
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（）或者腾讯微博（）关注我们，并与我们的编辑和其他读者朋友交流。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。博客访问： 2721614
博文数量： 698
博客积分： 10
博客等级： 民兵
技术积分： 11080
注册时间：
认证徽章：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Web开发
《软件测试的有效方法（第2版）》笔记（一）
第一章 评估软件测试的能力和人员资格
1、软件开发过程：计划P、执行D、检查C、行动A。－－PDCA循环
2、软件测试涉及的人员：软件客户、软件用户、开发人员、测试人员、信息技术管理人员、高级组织管理人员、审计员。
3、软件测试的多种角色：制造、创作车间、专业化过程。
4、缺陷：与期望的产品属性存在的差异。分两类：
（1）产品规格书中的缺陷；
（2）与客户/用户的期望不符。
另一种分法：
（1）错误；
（2）遗漏；
（3）超额。
故障：当缺陷引起了运行错误或对客户/用户产生了消极影响时。
××注意：至少90%的缺陷是由于过程问题引起的。
创建软件时产生缺陷的数量主要取决于过程是否完备，完备指过程中可以允许多大的变化。
风险：指不希望的事件发生的可能性。
5、软件测试中的“三步测试法”：
（1）确定当前测试能力的状态；
（2）确定改进目标；
（3）制订测试计划以达到测试目标。
6、质量保证协会QAI确定了与世界级软件测试组织普遍相关的八项标准：
（1）测试计划；
（2）对测试人员的培训；
（3）对测试工作的管理；
（4）用户对测试的满意程度；
（5）测试过程的使用；
（6）有效的测试实践；
（7）应用测试工具；
（8）对测试全过程的质量控制。
如果一组织能达到这八项标准的要求，就可以称他为世界级的软件测试组织。
7、评估现有测试过程的质量
实现过程：
（1）组建评估小组；
（2）完成评估调查问卷；
（3）创建Kiviat图；
（4）评估结果。
软件测试工程师认证CSTE
通用知识主题CBOK：五大类：
（1）一般技能；
（2）测试技巧/方法；
（3）测试计划；
（4）执行测试计划；
（5）测试分析的报告与改进。
第二章 制定软件测试策略
1、确定解决方法的有效性是解决问题的必要步骤。测试就是用来确定解决方法的技术。
三个方面：
（1）在软件系统开发生命周期的每个节点对软件有效性的证明；
（2）根据用户的需要和要求确定最终系统的有效性；
（3）通过使用样本测试数据执行软件来检查系统的行为。
问题的紧急程度决定了解决方案。明确测试需求。
2、风险：是引起损失的一种情况。系统在开发和安装阶段可能存在的策略风险是：
（1）可能得出不正确的结果；
（2）系统接受了未经授权的事务处理；
（3）计算机文件的完整性受到破坏；
（4）处理过程不可重建。
（5）失去处理的连续性；
（6）提供给用户的服务达不到满意的程度；
（7）系统安全性达不到标准；
（8）处理过程不符合组织原则或政府规定；
（9）系统结果不可靠；
（10）系统使用难度大；
（11）程序不可维护；
（12）系统不能移植到其它硬件或软件中；
（13）系统不能与其它计算机系统互连；
（14）性能不合格；
（15）系统操作难度大。
有效的测试方法就是明确和评价计算机系统的各种风险。
“太少的测试是犯罪，太多的测试是罪恶。”
测试中的问题产生的原因：
（1）没有定义测试目标；
（2）测试软件生命周期的错误阶段；
（3）使用无效的测试技术。
测试费用的有效性可用测试费用曲线来表示。
3、测试信息服务系统不仅仅是一类IT问题，还是一类组织问题。
一些技术的发展会导致测试方法的修改，如下：
（1）一体化；
（2）系统链接；
（3）多米诺骨牌效应；
（4）依赖电子商务；
（5）多用户。
4、建立测试原则 四项标准：
（1）测试的定义：定义一个清晰、扼要、明确的测试；
（2）测试系统：通过这一方法实现测试和强制测试；
（3）评价：信息服务管理将如何衡量和评价测试；
（4）标准：衡量测试的标准。
建立测试原则的方法：
（1）直接管理：一个或多个高级管理员制定的原则；
（2）信息服务一致原则：IT管理部门召集一些高级专家和有声望的人来参与原则的制定；
（3）用户会议：联合IT各部门管理用户的关键人员制定测试原则。
5、测试的结构化方法
测试过程要包括生命周期的每个阶段：
（1）需求——决定验证方法；确定需求是否恰当；生成功能测试数据；确定设计是否符合需求。
（2）设计——确定设计是否恰当；生成结构合功能测试数据；确定是否符合设计。
（3）编程——确定程序完成得是否恰当；生成程序的结构合功能测试数据。
（4）测试——测试应用系统。
（5）安装——把测试过的系统投入生产。
（6）维护——修改和重新测试。
在每个阶段都要完成的活动有：
（1）分析该阶段的产品结构是否适合于测试；
（2）根据该阶段的结构产生测试单元。
另外，在设计和编程阶段完成的活动：
（1）确定该阶段的结构是否符合前面阶段产生的结构；
（2）精炼或重新定义前面阶段生成的测试单元。
6、测试策略的两个组件是：
（1）测试因素：需要由测试策略确定的风险和问题；
（2）测试阶段：系统开发生命周期里需要测试的各阶段。
7、测试因素：正确性、文件完整性、合法性、审计跟踪、处理的连续性、服务水平、访问控制、符合性、可靠性、易用性、可维护性、可移植性、耦合、性能、易操作性。
8、制定测试策略 步骤：
（1）选择和分级测试因素；
（2）明确系统开发阶段；
（3）明确系统开发时的商业风险；
（4）把风险置于矩阵中。
9、创建测试策略样例：
（1）选择和分类测试因素；
（2）明确受到影响的阶段；
（3）联系每个阶段和因素，确定测试需要考虑的问题；
（4）定义测试策略。
10、测试方法论：与测试策略相统一，代表了测试应用系统的详细工作程序。工作程序用测试方法论立方体表示。
第三章 建立软件测试方法论
测试方法论是使测试策略得以实施的一套方法。依照需求恰当的使用测试策略矩阵。任务是决定测试、制定可行的测试方法，识别出风险。
1、测试目的：发现和消除软件的缺陷或者与预期结果的偏差。两类缺陷：
（1）与规格说明不符；
（2）与期望不符。
2、导致软件缺陷的原因：
（1）信息技术对需求的解释不正确；
（2）用户提出了错误需求；
（3）没有正确记录用户的需求；
（4）设计规格说明不正确；
（5）程序规格说明不正确；
（6）程序编码中有错误；
（7）数据输入错误；
（8）测试错误；
（9）纠错时出现错误；
（10）纠错条件导致另外的缺陷。
测试的费用主要取决于在项目生命周期的什么时期开始测试，越晚越贵。
测试应该从生命周期的第一个阶段开始，并贯穿于整个软件开发的生命周期。
生命周期测试：是对解决方案的持续测试，即使在软件开发计划完成后或者被测试的系统处于执行状态的时候，都不能中断测试。直到正式开始开发过程，生命周期测试才能开始。
3、四个测试技术：
（1）验证：确保系统遵循组织标准和规程，主要靠评审或一些不可执行的方法。
验证需要的评审有：
&&& （1.1）需求评审：研究并讨论计算机系统的需求，以确保它能满足用户的需要及其可行性；
&&& （1.2）代码走查：对程序源代码进行非正式的分析，以发现缺陷并且验证编码技术；
&&& （1.3）代码审查：对程序源代码进行正式的分析，以发现为符合计算机系统设计规格说明所发生的设计缺陷；
&&& （1.4）设计评审：研究并讨论计算机系统的设计，以确保它支持系统需求；
&&& （1.5）回顾评审。
（2）确认：通过一系列可以看到和评价的测试来执行系统功能，以确保系统操作按照计划实现。
确认的测试有：
&&& （2.1）单元测试：单独程序、模块或代码单元的测试；
&&& （2.2）集成测试：相关的程序模块、代码单元测试；
&&& （2.3）系统测试：对于整个计算机系统的测试；
&&& （2.4）用户验收测试：对于计算机系统或系统某部分的测试，确保它们能配合系统工作，而无需考虑系统需求。
（3）功能测试：即黑盒测试。基本只能使用确认技术。
（4）结构测试：白盒测试。主要使用验证技术。
功能测试的优势：模拟实际系统的使用；进行没有系统结构的设想。
功能测试的不足：遗漏软件中潜在的逻辑错误；可能造成冗余测试。
结构测试的优势：可以测试软件的结构逻辑；测试时不用考虑是否完成了功能测试。
结构测试的不足：不能保证是否满足用户的需求；结构测试不可以模拟现实世界的情况。
两者结合才能确认整个系统。
4、工作流程：是一种方法，它用图示或文档的方式来说明指定的活动是如何完成的。
每一个工作流程由以下四个部分组成：输入、执行过程、检查过程、输出。
工作流程的概念可用作系统创建步骤的图示说明。
5、开发测试方法论中要考虑的八个问题
（1）获取和研究测试策略；
（2）确定开发项目的类型；
（3）确定软件系统的类型；
（4）确定项目的范围；
（5）确定战术风险；
（6）确定何时进行测试；
（7）建立系统测试计划；
（8）建立单元测试计划。
步骤如下：
（1）获取和研究测试策略；
（2）确定开发项目的类型；
项目类型：指开发的软件环境或方法论。
当环境变化大了，测试风险也会不同。
（3）确定软件系统的类型
软件系统的类型指该系统要完成的处理过程，一般有16种不同的软件处理类型：
&&& （3.1）批处理：可以运行一般的批量处理；
&&& （3.2）事件控制：由外部事件引发的实时处理数据；
&&& （3.3）处理控制：从外部接收数据，根据收到的数据发出命令来控制某些行为；
&&& （3.4）规程控制：控制其它软件；
&&& （3.5）高级数学模型：类似于模拟和商业策略软件，但具有过多运用数学模型造成的复杂性；
&&& （3.6）消息处理：管理输入输出消息，处理文本或者文本包中包含的信息；
&&& （3.7）诊断软件：检测和隔离硬件错误，这些硬件存在于电脑或与其通信的硬件中；
&&& （3.8）传感器和信号处理：类似于消息处理，但需更多的处理过程来分析输入数据，并使之转换成可用的数据处理格式；
&&& （3.9）模拟：模拟一种环境、任务状况、其它硬件；从这些输入中得出对计算机程序或硬件最真实的评价；
&&& （3.10）数据库管理：管理数据的存储和访问；
&&& （3.11）数据采集：实时接收信息，并以某种形式保存数据，用作以后的处理；
&&& （3.12）数据表示：格式化数据及转化数据；
&&& （3.13）决策和计划辅助：使用人工智能技术提供一个专家系统来评价数据，为决策和政策制订者提供附加的信息和考虑；
&&& （3.14）图形和图像处理：生成和处理计算机图像；
&&& （3.15）计算机系统软件：为运行计算机程序提供服务；
&&& （3.16）软件开发工具：为辅助软件开发提供服务；
（4）确定项目的范围：指包含在被测试的软件中的所有行为——可以理解的系统需求和规格说明的范围。
（5）确定战术风险& 战术风险分为三类：
&&& （5.1）结构化风险：应用系统及创建应用系统的方法中所涉及的风险；
&&& （5.2）技术风险：创建和操作应用系统的技术所涉及的风险；
&&& （5.3）规模风险：软件各方面的规模所设计的风险。
确定战术风险的步骤：
&&& 第一，理解风险和对风险的分级；
&&& 第二，确定被测试的软件系统中适当级值；
&&& 第三，计算和累计风险分数。
（6）确定何时进行测试
测试在项目的各个阶段都应该进行。在这些阶段的测试行为有：
& A. 需求阶段行为：确定测试策略；确定需求是否恰当；创建功能测试条件。
& B. 设计阶段行为：确定需求设计符合性；确定设计是否恰当；创建结构和功能测试条件。
& C. 编程阶段行为：确定设计符合性；确定执行是否恰当；创建程序单元的结构和功能测试条件。
& D. 测试阶段行为：确定测试计划是否恰当；测试应用系统。
& E. 安装阶段行为：修改和重新测试系统。
（7）建立系统测试计划
测试计划要提供测试软件的背景信息、测试目标和风险，以及测试的业务功能和要完成的特殊测试。
测试计划类似于执行测试的路线图，它被分解成特殊测试和低级测试。
测试执行后，要测试结果生成测试报告。
（8）建立单元测试计划
把系统分成组件和单元来执行具体的处理，这些单元都要有自己的测试计划。根据软件对质量的要求程度，决定这些计划的复杂程度。
单元测试计划着重确定单元测试完成时间。
阅读(1039) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。测试简答_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
上传于|0|0|暂无简介
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩3页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢制定一个有效的测试策略 - 没翅膀的飞鱼 - 51Testing软件测试网 51Testing软件测试网-中国软件测试人的精神家园
51testing论坛版主，专注于软件测试及测试吐槽，屌丝测试攻城师一枚。。。。。。。。。。。。。。。。。。。。。。。。。新浪微博：@没翅膀的飞鱼-------邮件交流：wzb_------
制定一个有效的测试策略
& 11:00:33
/ 个人分类：
在近期的一个大型项目中，我们在初期就制定了目标,我们不想让很多的QA人员手动我们的软件。通过手工测试来发现漏洞是非常耗时的，成本也很昂贵, 尝试尽可能从软件内部着手构建高质量的产品。这并不是说,手工测试应经无用武之地, 手动测试常常能触发某些你无法预期到的软件使用行为。这是一个18个月左右的长期项目, 后续还会有持续更新。先前我们就发现,一个好的测试策略对项目的成功是至关重要的,特别是让我们的团队能够：1）随着时间的推移持续提高我们的效率,2)有信心应对我们的应用程序的大大小小的变更。为了建立一个有效的策略，我们花了相当长一段时间。这主要是因为我们不得不如何在应用程序的每一层来设计我们的应用程序的可测试性。我们的团队成员之前都有很丰富的TDD经验,但这并不是我们需要创建一个有效的测试策略的唯一技能。测试的层次为不同的测试分类是很麻烦的。你需要有、集成测试、、验收测试,缓慢测试,快速测试,界面测试,等等。我们发现我们的测试属于三个主要类别:*系统测试*皮下测试*单元测试每个测试所测的内容的视角都是不同的。一个完整通过外部应用程序,测试诸如浏览器,文件下拉菜单,队列,WinForms应用程序这类问题。皮下测试直接针对用户界面以下的内容。在一个应用程序的环境中, 我们的我们用例的其中一个皮下测试是在所有的真实的类和实现都部署到位的前提下，通过命令行处理器发送的表单对象。我们绕过仅仅包含界面逻辑的控制层,直接到领域层。发送表单对象后,就能获取成功/失败的测试结果。最后,我们有单元测试。单元测试的目的是测试一个类,可以是快或慢的测试。快速测试是正常的TDD测试,用于构建类的设计。根据需要进行重复测试,但严格interaction-based测试没有多大价值,除非我们找到非常有趣的交互。我们也有缓慢的单元测试,也可以归类为集成测试。这些将是诸如库测试、持久性测试,等等。不同类型测试的比例，单元测试:皮下测试:系统测试在10:2:1附近徘徊。我们完成的这个项目大约有5000个单元测试，1000个皮下的测试中和500完整系统测试,使用WatiN和Gallio来驱动一个浏览器。这6000个单元/皮下测试大约10分钟执行完毕,然而500个UI测试需要大约50分钟完成。单元测试策略单元测试是在一个相当严格的TDD方式。在任何设备投入使用之前，我们都会编写测试，并使用测试驱动代码的设计。这些测试帮助识别设计问题,封装问题,代码问题等等。我们努力避免编写纯粹用于提供测试的代码。它们常常意味着我们有设计问题、责任错位或封装已被破坏。当我们进一步深入到项目管道,我们开始越来越少使用交互测试。也仅仅是满足对此真正感兴趣的人的兴趣而已。但更多的时候,我们更感兴趣的是它的副作用,而交互是一个实现细节而已。我们经常所做的反而是模拟缓慢或不可测试,如存储库,在外部服务facade,配置等。否则,我们模拟仅限于我们很感兴趣观察点。在大型项目中,它可以变得很明显,你的设计需要一个large-level重构,提取其中的概念使其更快实现交付功能。在我们最后的项目,一些概念发现包括:§& AutoMapper§& 处理的形式作为单独的命令消息§&Input builders有了所有这些，单元测试实际上是重构的一个保障。但只有我们依赖这些测试来覆盖应用程序中所有有趣的行为时，才能起到保障的作用。为了有效地允许大型和中型的重构，我们需要额外的测试级别。皮下测试策略皮下测试,就像他们的名字所暗示的, 测试一切都只是用户界面的表面之下。在MVC应用程序中, 所有这些测试将只是控制器下的所有内容。对于一个web服务,一切都在端点。这个想法是，最上层的应用程序不执行任何实际的业务逻辑，而只是连接的外部接口与相关服务。皮下测试的重要性体现在我们希望在绕开如用户界面和外部服务来测试业务逻辑的情况下。单元测试只是聚焦在小规模设计上,皮下测试并没有关注设计, 而是将被测系统作为一个整体来关注输入和输出。为了构建一个有效的皮下测试,我们可以试着通过共同的逻辑流构建统一的压力点。例如,我们可以构建一个命令消息处理系统,或者一个通用的查询接口。在最近的一个项目中,批处理文件中的每一行变成了一条消息。我们可以起草一个消息，通过系统发送，然后验证处理该消息的所有副作用。由于皮下测试解决高层次的行为，而不是设计,他们非常适合基于场景的测试策略，如BDD或测试类夹具的模式。如果我们希望能够执行大的重构,我们需要这些高级测试创建wide-cast安全网的业务行为。皮下测试也是调用功能的大目标点,他们关注的更多是终端到终端的逻辑。而皮下测试使我们能够安全地执行较大的重构，他们仍然不提供一个我们的系统将在生产中运行的令人满意的信心水平。全面的系统测试策略我们的团队最初称这些测试为“UI测试”，直到我们更多的项目和更多的整合策略。其中输入我们的系统的不是一个浏览器，而是消息，一个REST端点，或FTP下拉菜单，批文件的处理。UI测试是全系统测试的子集。一个完整的系统测试背后的想法是,我们想要测试我们的软件,因为它可能会用于生产。对于一个MVC应用程序,这些将是基于浏览器的测试。对于批处理文件,我们将使用实际的文件。REST中，是实际的HTTP请求。消息，是真正的队列和消息。在产品上线前，如果我们想知道应用程序能否按照预期运行,一个有效和高效的方法是创建一个自动化的测试,测试完整的系统。如果我的基于UI的测试可以登录应用程序，并下订单，然后可以验证是否生成一个订单。我感觉是一件很不错的事情。有关完整的系统测试中一个常见的误解是，他们是。他有自身的特点，全系统测试要求必须能了解系统内部发生了什么。实际上，全系统测试甚至可以采用领域模型来构建数据，而不是通过纯粹为了测试的系统后门来创建测试数据。团队中常犯的错误是，不按照与产品实际应用一直的路径来测试代码，导致系统处于奇怪的、失效的和无法处理的状态。在我们的项目中，全系统测试时我们生成一个特性/用户故事完成之前所写的最后的代码。手工测试的成本太高，而且也无法可靠地验证一个特性已完成。但如果我可以通过外部接口来验证产品实际使用时的操作，这是成功的。整体策略对于一个待测系统，为了提高覆盖率，我们发现最有效的测试策略是从全系统测试开始，逐渐深入到单元测试。首先使用宽松的但是简单的断言，然后逐渐深入单元级别的逻辑。对于一个新的应用程序，我们倾向于不只是关注一个区域，对于一个长期维护的系统来说，所有的测试都是很重要的。我们这种测试策略确实需要一定程度的投入。当知道这个应用程序对于客户的业务来说至关重要时，我们发现这种整体策略是非常有效的。如果应用程序是关键业务, 它定会发生变更，如果发生需求变更，我们最好能安全的实施变更，而不会影响我们的客户的业务。【英文原文：】