IT博客-小龙虾的博客-文章分类-测试经验

度量之估算---COSMIC方法

小龙虾 — Mon, 02 Nov 2015 02:23:00 GMT

COSMIC 功能点法在对软件中功能点的划分上更加灵活, 对软件内部的结构和实现依赖更小, 对软件功能变化的应对能力更强。全功能点分析方法于1997 年被提出, 后来被通用软件度量协会(COSMIC) 继承和发展, 并且得到了广泛的推广和使用。2003 年1 月31日,COSMIC-FFP 标准(COSMIC的前身) V2.2 版本诞生后, 被国际化标准组织正式接纳其为国际标准, 编号为150/ IEC19761:2003。2007 年9 月1 日, COSMIC-FFP 方法改称为COSMIC 方法, 标准也升级至3. 0 版本[8] 。

COSMIC功能点分析方法是第二代功能点分析方法, 符合国际标准, 编制标准的专家来源广泛。在过去几年中, 这种方法得到了广泛和严格的测试, 目前在实时系统、业务支撑领域的多层结构应用软件、面向对象的分析方法以及可视化开发工具等方面都有很好的适应性。

COSMIC 功能点方法将待度量的软件系统划分成一系列的功能过程, 对每个功能过程的规模大小进行度量, 最终汇总所有功能过程的规模就可以得到软件程序的总规模大小。COSMIC 功能点方法有四种数据移动, 分别为数据入、数据出、读和写。

表1 COSMIC与IFPUG的详细比较

COSMIC 功能点法在早期估算中非常有效，它适用于:

（1）以数据处理为主的商务应用软件, 如银行、财务、保险、采购等领域的信息系统;

（2）实时系统, 如电话交换系统、嵌入式控制软件;

（3）上述两种类型的混合, 如飞机售票系统、旅馆预订系统等

COSMIC 功能点法在早期估算方面的具体计算过程如下:

( 1) 识别软件层次。识别层次的目的是为了识别被度量软件的边界, 清晰地定义被度量软件的范围。

( 2) 识别软件边界。边界定义为被研究的软件与其用户之间的概念性接口, 用户既包括系统的使用人员, 也包括其他软件或者硬件系统。

( 3) 识别功能处理。一个功能处理是用户功能需求集合的一个基本部件, 包括一组惟一的、内聚的、可独立执行的数据移动。

( 4) 识别数据组。一个数据组包含的每个数据属性描述了感兴趣的同一个对象的一个互补的侧面。一个数据组可以是永久存储的也可以是短期存储的数据, 它必须在系统中被具体化。

( 5) 识别数据属性。一个数据属性是已识别的数据组中最小的信息包, 识别数据属性并非是必须的活动。COSMIC-FFP 中基本的功能度量单位是一次数据移动, 数据移动的对象是数据组, 数据组是数据属性的集合。

( 6) 识别数据移动, 计算并汇总。COSMIC 功能点法就是一个计算数据移动的过

程。每一个有效的数据移动都被看成一个COSMIC 功能的规模大小单位, 为每一个功能过程找到其所有的数据移动之后, 将它们累加在一起就是这个功能过程的软件大小, 可以表示为:

Size( FPi ) = Size( 数据入i ) + Size( 数据出i ) +Size( 读i ) + Size( 写i )

将所有功能过程的大小数值累计就可以得到整个软件程序的规模大小:

通过该度量方法, 可将一个十分复杂的软件系统最终转换成一些具体的数值,以表示软件实际规模大小。

下面是一个用COSMIC估算的例子：

表2 COSMIC功能点法规模计算

组件	功能点数
数据入	33
数据出	138
读	13
写	25
功能点数合计	209

在运用COSMIC 功能点法估计规模时,

结果如由表2所示。取单位功能点成本为

3000元, 则该系统建设的软件成本为

209 *3000 元, 即627000 元. 而该系

统建设的软件实际投资为70万。估算

结果与实际投资的偏差为10.43% 。

ISBSG组织积累了大量的COSMIC功能点估算的经验数据，并发布了相关的经验数据库，但是该经验数据库是收费的，我们暂时无法获取。第一次发布的版本包括了来自实时系统和基础软件系统的62个项目数据，以及290个来自商业软件的项目的数据。这些数据对确定软件基准、估算、项目计划以及研究具有非常重大的价值。但是这些数据目前是不对外开放的或者是收费的。基于这些经验数据所得出的转换公式现在我们也无法获取。

小龙虾 2015-11-02 10:23 发表评论

Web 测试的经验

小龙虾 — Mon, 05 Jun 2006 09:13:00 GMT

1. 功能测试
1.1.链接测试
　　链接是 Web 应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web 应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的 URL 地址才能访问。
　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个 Web 应用系统的所有页面开发完成之后进行链接测试。
1.2. 表单测试
　　当用户给 Web 应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
1.3.Cookies测试
Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用 Cookies 访问了某一个应用系统时， Web 服务器将发送关于用户的信息，把该信息以 Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
　　如果 Web 应用系统使用了 Cookies ，就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用，是否按预定的时间进行保存，刷新对 Cookies 有什么影响等。
1.4.设计语言测试
Web 设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的 HTML 等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了 HTML 的版本问题外，不同的脚本语言，例如 Java 、 JavaScript 、 ActiveX 、 VBScript 或 Perl 等也要进行验证。
1.5.数据库测试
　　在 Web 应用技术中，数据库起着重要的作用，数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中，最常用的数据库类型是关系型数据库，可以使用 SQL 对信息进行处理。

在使用了数据库的 Web 应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
2. 性能测试
2.1.连接速度测试
　　用户连接到 Web 应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长（例如超过 5 秒钟），用户就会因没有耐心等待而离开。
　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2.负载测试
　　负载测试是为了测量 Web 系统在某一负载级别上的性能，以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量，也可以是在线数据处理的数量。例如： Web 应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？ Web 应用系统能否处理大量用户对同一个页面的请求？
2.3.压力测试
　　负载测试应该安排在 Web 系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个 Web 系统能同时处理的请求数量将远远超出这个限度，所以，只有放在 Internet 上，接受负载测试，其结果才是正确可信的。
　　进行压力测试是指实际破坏一个 Web 应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试 Web 应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到 Web 应用系统崩溃，接着当系统重新启动时获得存取权。
　　压力测试的区域包括表单、登陆和其他信息传输页面等。
3. 可用性测试
3.1.导航测试
　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个 Web 应用系统是否易于导航：导航是否直观？ Web 系统的主要部分是否可通过主页存取？ Web 系统是否需要站点地图、搜索引擎或其他的导航帮助？
　　在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动，很快地扫描一个 Web 应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构，因此， Web 应用系统导航帮助要尽可能地准确。
　　导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容，内容在什么地方。
Web 应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
3.2.图形测试
　　在 Web 应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
　　（ 1 ）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
　　（ 2 ）验证所有页面字体的风格是否一致。
　　（ 3 ）背景颜色应该与字体颜色和前景颜色相搭配。
　　（ 4 ）图片的大小和质量也是一个很重要的因素，一般采用 JPG 或 GIF 压缩。
3.3.内容测试
　　内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。
　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用 Microsoft Word 的 " 拼音与语法检查 " 功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般 Web 站点中的所谓 " 相关文章列表 " 。
3.4.整体界面测试
　　整体界面是指整个 Web 应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览 Web 应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个 Web 应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。
　　对所有的可用性测试来说，都需要有外部人员（与 Web 应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
4. 客户端兼容性测试
4.1.平台测试
　　市场上有很多不同的操作系统类型，最常见的有 Windows 、 Unix 、 Macintosh 、 Linux 等。 Web 应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
　　因此，在 Web 系统发布之前，需要在各种操作系统下对 Web 系统进行兼容性测试。
4.2.浏览器测试
　　浏览器是 Web 客户端最核心的构件，来自不同厂商的浏览器对 Java ，、 JavaScript 、 ActiveX 、 plug-ins 或不同的 HTML 规格有不同的支持。例如， ActiveX 是 Microsoft 的产品，是为 Internet Explorer 而设计的， JavaScript 是 Netscape 的产品， Java 是 Sun 的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。
　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
5. 安全性测试
Web 应用系统的安全性测试区域主要有：
　　（ 1 ）现在的 Web 应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
　　（ 2 ） Web 应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如 15 分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
　　（ 3 ）为了保证 Web 应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
　　（ 4 ）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
　　（ 5 ）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
6. 总结
　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于 Web 的系统测试方法。
基于 Web 的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于 Web 的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

小龙虾 2006-06-05 17:13 发表评论