1.                        测试中心 刘艳会

在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术

本文将 web 测试分为 6 个部分：

·         功能测试

·         性能测试（包括负载/压力测试）

·         用户界面测试

·         兼容性测试

·         安全测试

·         接口测试

本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。

1 功能测试

1.1 链接测试

链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

采取措施：采用自动检测网站链接的软件来进行。

推荐软件：

Xenu Link Sleuth 免费 绿色免安装软件

HTML Link Validator 共享（30天试用）

1.2 表单测试

当用户通过表单提交信息的时候，都希望表单能正常工作。

如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

1.3 数据校验

如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。

在测试表单时，该项测试和表单测试可能会有一些重复。

1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。

1.4 cookies测试

Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。

采取措施：

1 采用黑盒测试：采用上面提到的方法进行测试

2 采用查看cookies的软件进行（初步的想法）

可以选择采用的软件

IECookiesView v1.50

Cookies Manager v1.1

1.5 数据库测试

在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

采取措施：暂时没有更好的测试方法

考虑结合到1.2和1.3的测试中

1.6 应用程序特定的功能需求

最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。

采取措施：深刻理解需求说明文档

1.7 设计语言测试

Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

暂时没有方法测试，可以多参考一点讨论组内的更新信息

2 性能测试

2.1 连接速度测试

用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。

　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

2.2 负载测试

负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？

2.3 压力测试

负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

　　压力测试的区域包括表单、登陆和其他信息传输页面等。

负载/压力测试应该关注什么

测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。

瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。

每个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?

长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。

采取措施：采用测试工具

查看(900) 评论(3) 收藏 分享 管理

测试用例模板（Test Case Template）

测试

简介

　　测试的主要评测方法包括覆盖和质量。

　　测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

　　质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。

覆盖评测

　　覆盖指标提供了"测试的完全程度如何？"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。

　　系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。

　　如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 75% 的性能测试需求。

　　如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

　　两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。

基于需求的测试覆盖

　　基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。

　　在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。

　　这些覆盖评测通过以下公式计算：

　　这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。

基于代码的测试覆盖

　　基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。

　　基于代码的测试覆盖通过以下公式计算：

质量评测

　　测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。

　　缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。

　　严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。

　　缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。

　　对于缺陷分析，常用的主要缺陷参数有四个：

　　· 状态：缺陷的当前状态（打开的、正在修复或关闭的等）。
　　· 优先级：必须处理和解决缺陷的相对重要性。
　　· 严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。
　　· 起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。

　　可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。

　　例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测"较差的模块"、"热点"或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。

　　这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。

缺陷报告

　　Rational Unified Process 以三类形式的报告提供缺陷评估：

　　· 缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。

　　· 缺陷龄期报告是一种特殊类型的缺陷分布报告。 缺陷龄期报告显示缺陷处于特定状态下的时间长短，如"提出的"。在龄期类别中，缺陷还可以按其他属性分类，如"拥有者"。

　　· 缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。

　　· 测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。
许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括有关特定类别（如严重性级别）中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类，该评估可以侧重于不同的需求集。

　　要有效生成此类报告，一般需要工具支持。

缺陷密度报告

缺陷状态与优先级

　　应该给定所有缺陷的优先级，通常可行的做法是设定四种优先级中的一种：

　　1. 立即解决
　　2. 高优先级
　　3. 正常排队
　　4. 低优先级

　　一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式。例如，对于一个成功的测试标准来说，可能不存在优先级为 1 的打开的缺陷，而且优先级为 2 的打开的缺陷要少于 5 个。例如下面的缺陷分布图：

　　很明显该图显示的情况没有达到标准。请注意，该图需要通过过滤器才能只显示需要的打开的缺陷。

缺陷状态与严重性

　　缺陷严重性报告显示每种严重性级别的缺陷个数，例如致命错误、未执行主要功能、次要错误等严重性级别。

缺陷状态与在实施模型中的位置

　　缺陷起源报告显示缺陷在实施模型元素上的分布情况。

缺陷龄期报告

　　缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试工作。

缺陷趋势报告

　　趋势报告确定缺陷率并提供了一个出色的测试状态视图。在测试生命周期中，缺陷趋势遵循着一种比较好预测的模式。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降。

　　要发现问题，可以根据这一趋势复审项目时间表。例如，在四个星期的生命周期中，如果缺陷率在第三个星期中仍然增长，则项目很明显没有按时间表进行。

　　这一简单的趋势分析假定：缺陷是立即关闭的，且在随后的工作版本中对修复进行测试，这样关闭缺陷的速率应该遵循与打开缺陷的速率相同的增减趋势。如果情况并非如此，则表明缺陷解决流程发生了问题；缺陷修复所需的资源或再次测试和确认修复所需的资源可能不足。

　　该报告反映的趋势显示，在项目开始时，发现和打开新缺陷的速率很快，但随着时间推移，该速率不断降低。打开的缺陷的趋势与新缺陷的趋势相似，但稍微滞后一些。关闭的缺陷的趋势随着打开的缺陷的修复和核实而不断增长。这些趋势描述的是成功的工作。

　　如果您的趋势与这些趋势差别显著，则表明存在问题，并可以确定可能需要附加资源以应用于开发或测试特定区域的时间。

　　当与测试覆盖评测结合起来时，缺陷分析可提供出色的评估，测试完成的标准也可以建立在此评估基础上。

性能评测

　　评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。

主要的性能评测包括：

　　· 动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。

　　· 响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。

　　· 百分位报告 - 数据已收集值的百分位评测/计算。

　　· 比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。

　　· 追踪报告 -主角（测试脚本）和测试对象之间的消息/会话详细信息。

软件作为一种纯数字化商品，在没有权威的第三方进行监督认证的情况下，软件供应商和用户在软件产品是否达到目标需求的问题上，往往各执一词。

　　关于软件质量标准和认证，国内虽然制定了有限的几个软件技术标准，但无法从根本上对软件这种特殊商品实施有效的质量监督和认证。在国际上通行的做法是，软件的质量标准和认证工作，由独立的软件测试机构来完成。这些测试机构的行为是市场化的，但因为测试能力和权威性将直接关系到它们的市场影响力，所以他们的测试行为极其严格，力求将垃圾软件扼杀在摇篮中。

　　樱花西街一座不太显眼的大厦里，迈捷实验室技术总监武友文从软件测试说起，以第三方的视角分析了制约国内软件发展的瓶颈，发表了不同意见，提出了自己的建议。

为什么需要软件测试

　　“我是清华大学77级的学生，在国内做了3年软件开发，随后就去了加拿大读研，专业是网络协议测试。毕业后我在北电、惠普等公司做软件质量的控制和测试项目。”武友文轻声细语地说着自己的经历，“1998年我回到国内，在对金融和电信行业进行考察时，发现他们买的硬件设备都是顶级的，可惜软件应用这一块跟不上，导致了硬件功能得不到充分的发挥。硬件设备低下的运行效率，造成了资源与资金的隐性浪费。不客气地说，实际上，是国内软件在拖硬件的后腿。”

　　在武友文回国期间，国内一些软件开发商通过朋友的引见，邀请武友文与公司研发人员交流时，武友文发现当时国内的软件开发普遍存在“重开发，轻测试”的现象，常常是在项目开发完成之后，才发现软件有严重缺陷问题，不得不全部推倒从头再来。推倒重来则意味着前期人、财、物的投入全部浪费了，即大大增加了软件的开发成本，又会因为超出了客户的委托时间，付出的代价就更高了。

　　武友文以自己在国际公司的实践经验，一再强调，软件测试是软件开发过程中的一个重要步骤，或者说测试应该贯穿在软件开发过程的每一个阶段。软件测试所起到的作用就是：能够确保在软件开发的过程中，随时发现问题，方便开发人员及时修改。

　　在国内对于消费类软件来说，经常出现一些已经推向市场的产品由于被发现有严重缺陷而导致大量退货的局面。而对于定制的行业软件来说，则是一再的返工、绵绵无绝期的修改和维护，既拖死了软件提供商，也耽误了客户的正常业务。

　　这一系列现状使用户对国内软件提供商失去信心，因此我们经常听到有人抱怨：国内软件没法用，对于正在成长的国内软件市场来说，这一结论无疑是灭顶之灾。

　　武友文告诉记者：“因为国外软件的成熟度高，开发商对软件质量的控制力度很强，所以国外软件测试外包的不是太多；不过在国外有些软件需要比较专业的质量认证，例如软件的本地化测试，就必须借助第三方机构来完成了。拿微软来说吧，微软的产品要翻译成欧洲的6种文字，如果是自己来做这些本地化测试工作，成本就会很大，所以外包给别的公司来做就很合适；另外还有一种情况也会外包的，例如对一些大型软件的测试，不一定每家开发商都有专业的测试队伍和测试的工具。从成本上来说，某些软件测试工作外包是经济的。相反，国内软件的成熟度比较低，软件开发商基本没有能力来做测试，我指的是专业的、职业的测试，所以从目前来说，国内软件测试的市场空间很大。”

　　凭着对软件测试行业的深刻理解，武友文意识到要解决国内软件应用滞后于硬件的问题，就必须提高国内软件的质量，而要提高软件质量，就必须加强软件开发过程中的测试力量，而独立的第三方测试机构正是一个市场空白点，于是专业从事软件测试的迈捷实验室就应运而生。

软件测试如何做

　　“迈捷成立之初，主营业务只是受客户委托，测试已经开发完毕的软件，更多的是事后验收工作，后来我们慢慢的从事后测试，向质量控制上转型，例如开始介入软件开发前的需求评审，以及开发时的文档评审、代码走查等等。我们最终的发展方向就是做软件监理，但是不能不承认，目前我们与国际上通行的软件监理还有一定的距离。”说到迈捷的发展方向，武友文沉稳中略显激昂。

　　武友文接着说：“美国实际是在软件规模的扩大和结构的不断复杂的情况下，开始建立软件测试制度和规矩的。我想美国在软件开发的起步阶段，也不会自己主动去做，是在现实的压力下，才去实施这些流程规范的。国内一定要有这种意识，意识到软件开发过程中一定要引进这些规章制度。另外，意识到了还不行，一定要实践。

软件测试现状

　　武友文向记者提供的一个市场调查报告说明，目前国内做软件测试的机构，还没有发现与迈捷公司商业形态相同的企业，只是有某些政府部门下属的机构做一些软件产品验收工作，但完全商业化操作的机构没有；另外就是开发商临时承接的一些软件测试项目。当记者问到迈捷实施软件测试时遇到的最大障碍是什么时，武友文很爽快的回答到： “一是客户的意识，二是我们派出的项目实施人员的素质问题。”

　　实施软件评测项目时，客户要有接受管理软件开发流程的意识。

　　客户交给开发商一个项目，通过测试等质量掌控流程，可以将产品的质量保证在一个相对较高的水准，减少后续工作的成本。但是现在很多开发商和客户很短视，觉得只要现在没有出问题，就可以了，不愿意在软件开发过程中，让测试介入的程度不深，这导致测试不完全，埋下了隐患。

　　无论是对软件开发商还是对客户来说，忽视软件测试，必将导致上的软件开发项目越多，将来会被这些有问题的项目给拖死的概率越高。

　　武友文说：“有独立的软件测试第三方的出现，好处就是严格地掌控软件质量，减少维护成本，这不光对客户有好处，对开发商也有好处。所以一个项目，在我们实施很长一段时间，大约是半年至两年后，客户才意识到这样做是有用的。这很正常，因为软件开发一定会有大大小小的问题，包括我们评测也有一些问题查不出来。”

　　迈捷对派出的项目实施人员的标准很高，要求既有综合素质，又要有专业素质，目前国内这种复合型的人才太少了，于是迈捷只能自己培养。

　　而人才培训，则令武友文最为头痛。人才培养是迈捷在资金和力量上投入最大的一块。其中专业素质的培训最难，因为需要实践。这如同医生一样，从医学校毕业了，虽然有很多理论上的积累，但是缺乏临床经验，你还不是一个合格的医生，更别谈做一个好医生了。项目实施管理者也一样，既要有理论基础，更要有经验积累，而一个优秀的项目实施管理者重要的素质是，能在按流程做的基础上，发挥个人的主观能动性，这个要求就太高了，但这又是项目实施成否的关键。

　　国内软件业和国外相比，最大的差异就在：质量和质量控制应该是最重要的一项内容。但是，无论在消费类软件还是大型软件的测试领域，与国外相比，国内软件产品的质量掌控体系和标准都是模糊的。国内软件提供商的质量承诺，既没有相应机构的监督，质量水平也没有第三方来认证，承诺显得极其苍白而无力。

　　可喜的是，软件测试机构在我国正逐渐成长起来，并且，它们在软件市场上的影响力正逐步得到提升。因缺乏游戏规则导致整个软件行业的市场行为不规范，并且严重制约软件行业健康成长的局面，一定会有所改善。

采访后记：

　　软件评测只是用技术手段来监控软件产品的质量，并不能从根本上提高我国软件产品的水平。目前，国内最缺的是软件项目实施的高级管理人才和软件结构分析的专业人才。这种高级人才的培育制度才是最重要的，缺乏高级人才培养的后果，会影响国内软件的进程。与培养软件蓝领相比，虽然高级人才培育的时间周期长，资金投入大，但是我们一定不能急功近利，要有这种忧患意识，去做这项有长远影响的工作。这种工作不是非得要谁去做，但是我们一定要有这种意识去投入去做。

　　在采访中，武友文认为大量的蓝领、很少的白领，这样的软件产业肯定有问题。不少人对将软件分为对白领蓝领很有意见，软件开发流程应该有一定的延续性。因为写程序不难，谁都能写，难的是写出合格的、优秀的程序。单一的写程序对软件开发很不合适，如果你不懂别的，譬如软件架构和质量目标，那么程序也写不好。单从编程的角度进行培训，对蓝领见效快，对白领则不太公平。

　　日本在软件开发中分得很细，国内接日本软件外包的业务很多，但大部分只是负责一个模块。软件是个创造性的工作，变成流水线工业化生产也许有问题。在我们的软件开发中，往往技术是不成问题的，但是管理是个大问题。我们的软件企业中，各个员工意识不一样，在不同的阶段理解不一样，管理人员的素质也不一样。软件管理和测试是一个需要反复实践的过程，要通过反复的实践才能解决问题。这些问题根本不是培训大量的软件蓝领就能解决的。

　　现在关于软件工程的培训很多，如果只是讲课意义不大，这些课在学校都已经讲过了，现在要的是实践。但是，目前国内还很欠缺这种实践的机会。

的主要评测方法

简介

　　测试的主要评测方法包括覆盖和质量。

　　测试覆盖是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

　　质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。

覆盖评测

　　覆盖指标提供了"测试的完全程度如何？"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。

　　系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。

　　如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 75% 的性能测试需求。

　　如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

　　两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。

基于需求的测试覆盖

　　基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。

　　在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。

　　这些覆盖评测通过以下公式计算：

　　这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。

基于代码的测试覆盖

　　基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已作定义。

　　基于代码的测试覆盖通过以下公式计算：

质量评测

　　测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。

　　缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。

　　严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。

　　缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。

　　对于缺陷分析，常用的主要缺陷参数有四个： 查看(280) 评论(0) 收藏 分享 管理