如何规范某些软件质量特性的可测量性？（09-2-9）（获奖名单已公布）

默默巫

我们在测试过程中是不是发现无法给一些质量特性进行评估，比如：可移植性，美观，可维护性，易用性等。
没有准确的给他们定一个标准，达到怎样就通过测试。
那么如何规范这些软件质量特性的可测量性呢？ 欢迎大家讨论。


感谢会员kuailederen提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
PS:回答优秀者可获得价值50元的当当卡一张．

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	archonwang	当当购物卡50元	2#
二等奖	阿七	300论坛积分	7#
三等奖	aman_cao	100论坛积分	4#

相关文章：

软件质量需求不断提高，小Bug蕴含测试大市场

书摘：什么是软件质量

软件质量保证、测试及配置管理面面观

配置管理—实施软件质量管理的关键

故障模式影响及危害性分析与软件质量

更多内容请点击＞＞＞

archonwang

沙发一把！

感觉这个问题还是要就具体情况而论，通用标准一般都是理出评估的项目，而不是给定一个数据。

在软件质量特性的因素分析上，网络上已经有了比较完整的表述，请参看如下的文章

软件质量特性因子分析管理
http://www.uml.org.cn/rjzl/200703222.asp

软件质量特性测试规范
http://www.gd-linux.org/website/test_criterion.jsp

至于如何规范化，仁者见仁，智者见智。所使用的方法无外乎设定流程、确定的数据标准和检测手段罢了。

[ 本帖最后由 archonwang 于 2009-2-13 09:55 编辑 ]

qinxiaocang1202

个人也认为这个最终有用户决定；只要项目开发的符合大多数用户的视觉、习惯，功能也实现了就OK了。一个项目适用的群体不一样，故兼容、易用等要看用户的要求，如：系统要求在IE和FIRFOX下浏览，你只需重点测试在它们下系统的兼容、界面的美观等各方面就可以了。
   在没发给客户之前可以根据测试需求来做度量标准；

[ 本帖最后由 qinxiaocang1202 于 2009-2-10 15:01 编辑 ]

aman_cao

呵呵，以前就这个话题曾与我们QA组的成员讨论过，就个人观点描述如下：
1.软件质量：软件满足明确或隐含的需求的能力（特性和特征）总和
2.测量：建立质量指标，然后用特定方法去实施测量活动。
3.度量：按质量指标得到的测量结果。

个人认为，对于一些模糊的子特性，以最终用户协商的标准来测量。
如可移植性，用户对移植有什么样的要求？
美观和易使用性就更难说了，虽然在易使用性上有定义，用户花费的在掌握系统使用上的学习时间，但每个用户的要求是不一样的，如前期做的一个项目，用户对界面的要求是大红色的背景图。符合了用户使用习惯，就是高质量的。

呵呵，对于这些子特性，觉得应该在和用户的协商中固定下来，我们现行的项目中，没有固定的指标。

期待看到大家的见解。

zynuage

我觉得一句话，就是符合用户需求就行了，什么是咱们的上帝，就是客户，如果客户说煤球是白的，咱们也没有必要说煤球是黑的，只要客户说满意，咱们还有什么疑问呢？所以，对软件测试的特性进行度量，就是符合客户的需求就行了。其他的全是白搭。

阿七

占位

阿七

一  质量属性

    许多产品特性可以称为质量属性，但是在许多系统中需要认真考虑的仅是其中的一小部分。如果开发者知道哪些特性对项目的成功至关重要，那么他们就能选择软件工程方法来达到特定的质量目标，根据不同的设计可以把质量属性分类。一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开。另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。那些对开发者具有重要意义的属性使产品易于更改、验证，并易于移植到新的平台上，从而可以间接地满足客户的需要。
        对用户最重要的属性             对开发者最重要的属性
              有效性                        可维护性  
              高效性                        可移植性  
              灵活性                        可重用性  
              完整性                        可测试性
              互操作性                        
              可靠性
              健壮性                        
              可用性
    产品的不同部分与所期望的质量特性有着不同的组合。高效性可能对某些部分是很重要的，而可用性对其它部分则很重要。把应用于整个产品的质量特性与特定某些部分、某些用户类或特殊使用环境的质量属性要区分开。
    定义质量属性必须根据用户对系统的期望来确定。定量地确定重要属性提供了对用户期望的清晰理解，这将有助于设计者提出最合理的解决方案。



二  对用户重要的属性



1  有效性
    有效性指的是在预定的启动时间中，系统真正可用并且完全运行时间所占的百分比。更正式地说，有效性等于系统的平均故障时间除以平均故障时间与故障修复时间之和。有些任务比起其它任务具有更严格的时间要求，此时，当用户要执行一个任务但系统在那一时刻不可用时，用户会感到很沮丧。询问用户需要多高的有效性，并且是否在任何时间，对满足业务或安全目标有效性都是必须的。一个有效性需求可能这样说明：“工作日期间，在当地时间早上6点到午夜，系统的有效性至少达到95%，在下午4点到6点，系统的有效性至少可达到98%。

2  效率
效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽的。如果系统用完了所有可用的资源，那么用户遇到的将是性能的下降，这是效率降低的一个表现。拙劣的系统性能可激怒等待数据库查询结果的用户，或者可能对系统安全性造成威胁，就像一个实时处理系统超负荷一样。为了在不可预料的条件下允许安全缓冲，你可以这样定义：“在预计的高峰负载条件下，10%处理器能力和15%系统可用内存必须留出备用。”在定义性能、能力和效率目标时，考虑硬件的最小配置是很重要的。

3  灵活性
就像我们所知道的可扩充性、增加性、可延伸性和可扩展性一样，灵活性表明了在产品中增加新功能时所需工作量的大小。如果开发者预料到系统的扩展性，那么他们可以选择合适的方法来最大限度地增大系统的灵活性。灵活性对于通过一系列连续的发行版本，并采用渐增型和重复型方式开发的产品是很重要的。灵活性目标可以是如下设定的：“一个至少具有6个月产品支持经验的软件维护程序员可以在一个小时之内为系统添加一个新的可支持硬拷贝的输出设备。”

4  完整性
    完整性主要涉及：防止非法访问系统功能、防止数据丢失、防止病毒入侵并防止私人数据进入系统。完整性对于通过www执行的软件已成为一个重要的议题。电子商务系统的用户关心的是保护信用卡信息，web的浏览者不愿意那些私人信息或他们所访问过的站点记录被非法使用。完整性的需求不能犯任何错误，即数据和访问必须通过特定的方法完全保护起来。用明确的术语陈述完整性的需求，如身份验证、用户特权级别、访问约束或者需要保护的精确数据。一个完整性的需求样本可以这样描述：“只有拥有查账员访问特权的用户才可以查看客户交易历史。”

5  互操作性
    互操作性表明了产品与其它系统交换数据和服务的难易程度。为了评估互操作性是否达到要求的程度，你必须知道用户使用其它哪一种应用程序与你的产品相连接，还要知道他们要交换什么数据。如wps可以写下这样的互操作性需求：“wps可以导入office生成的doc后缀的文件，亦可以导出同类格式的文档”

6  可靠性
    可靠性是软件无故障执行一段时间的概率。健壮性和有效性有时可看成是可靠性的一部分。衡量软件可靠性的方法包括正确执行操作所占的比例，在发现新缺陷之前系统运行的时间长度和缺陷出现的密度。根据如果发生故障对系统有多大影响和对于最大的可靠性的费用是否合理，来定量地确定可靠性需求。如果软件满足了它的可靠性需求，那么即使该软件还存在缺陷，也可认为达到其可靠性目标。要求高可靠性的系统也是为高可测试性系统设计的。例如银行的支付系统，这些设备全天工作并且要求数据的完整和安全。用户要求真正与支付的那部分软件要高可靠性，而其它系统功能，例如周期性地统计交易数据，则对可靠性要求不高。对于该系统的一个可靠性需求说明如下：“由于软件失效引起交易失败的概率应不超过1‰”。

7  健壮性
    健壮性指的是当系统或其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异常的操作情况时，能继续正确运行功能的程度。健壮的软件可以从发生问题的环境中完好地恢复并且可容忍用户的错误。当从用户那里获取健壮性的目标时，询问系统可能遇到的错误条件并且要了解用户想让系统如何响应。举个图形引擎的例子，该图形引擎具有描述图形规划的数据文件，并且把这一规划传送到指定的输出设备上。许多需要产生规划的应用程序就要请求调用图形引擎。由于在图形引擎中，我们将无法控制这些应用程序的数据，所以此时健壮性就成为必不可少的质量属性。我们的一个健壮性需求是这样说明的：“所有的规划参数都要指定一个缺省值，当输入数据丢失或无效时，就使用缺省值数据。”这个例子反映了对一个“用户”是另一个软件应用程序的产品，其健壮性设计的方法。

8  可用性
    可用性也称为“易用性”和“人类工程”，它所描述的是许多组成“用户友好”的因素。可用性衡量准备输入、操作和理解产品输出所花费的努力。你必须权衡易用性和学习如何操纵产品的简易性。“CMS备货管理系统”的分析员询问用户这样的问题：“你能快速、简单地请求某商品备货并浏览其它信息，这对你有多重要？”和“你请求某一种商品备货到出库大概需花多少时间？”对于定义使软件易于使用的许多特性而言，这只是一个简单的起点。对于可用性的讨论可以得出可测量的目标，例如“一个培训过的用户应该可以在平均3分钟或最多5分钟时间以内，完成从供应商目录表中请求一种商品备货到出库的操作。”同样，调查新系统是否一定要与任何用户界面标准或常规的相符合，或者其用户界面是否一定要与其它常用系统的用户界面相一致。这里有一个可用性需求的例子：“在文件菜单中的所有功能都必须定义快捷键，该快捷键是由Ctrl键和其它键组合实现的。出现在Microsoft Word 2000中的菜单命令必须与Word使用相同的快捷键”。可用性还包括对于新用户或不常使用产品的用户在学习使用产品时的简易程度。易学程度的目标可以经常定量地测量，例如，“一个新用户用不到30分钟时间适应环境后，就应该可以对一个商品进行备货出库处理”，或者“新的操作员在一天的培训学习之后，就应该可以正确执行他们所要求的任务的95%”。当你定义可用性或可学性的需求时，应考虑到在判断产品是否达到需求而对产品进行测试的费用。



三  对开发者重要的属性



1  可维护性
可维护性表明了在软件中纠正一个缺陷或做一次更改的简易程度。可维护性取决于理解软件、更改软件和测试软件的简易程度，可维护性与灵活性密切相关。高可维护性对于那些经历周期性更改的产品或快速开发的产品很重要。你可以根据修复一个问题所花的平均时间和修复正确的百分比来衡量可维护性。“CMS备货管理系统”包括如下的可维护性需求：“物流部门提出修改与增加备货商品的查询条件，对于现有报表的更改操作必须在3天内完成。”等等。在图形引擎工程中，我们知道，我们必须不断更新软件以满足用户日益发展的需要，因此，我们确定了设计标准以增强系统总的可维护性：“函数调用不能超过两层深度“，并且“每一个软件模块中，注释与源代码语句的比例至少为1∶2。”认真并精确地描述设计目标，以防止开发者做出与预定目标不相符的愚蠢行为。

2  可移植性
    可移植性是度量把一个软件从一种运行环境转移到另一种运行环境中所花费的工作量。软件可移植的设计方法与软件可重用的设计方法相似。可移植性对于工程的成功是不重要的，对工程的结果也无关紧要。可以移植的目标必须陈述产品中可以移植到其它环境的那一部分，并确定相应的目标环境。于是，开发者就能选择设计和编码方法以适当提高产品的可移植性。

3  可重用性
从软件开发的长远目标上看，可重用性表明了一个软件组件除了在最初开发的系统中使用之外，还可以在其它应用程序中使用的程度。比起创建一个你打算只在一个应用程序中使用的组件，开发可重用软件的费用会更大些。可重用软件必须标准化、资料齐全、不依赖于特定的应用程序和运行环境，并具有一般性。确定新系统中哪些元素需要用方便于代码重用的方法设计，或者规定作为项目副产品的可重用性组件库。

4  可测试性
可测试性指的是测试软件组件或集成产品时查找缺陷的简易程度。如果产品中包含复杂的算法和逻辑，或如果具有复杂的功能性的相互关系，那么对于可测试性的设计就很重要。如果经常更改产品，那么可测试性也是很重要的，因为将经常对产品进行回归测试来判断更改是否破坏了现有的功能性。因为我们知道随着图形引擎功能的不断增强，我们需要对它进行多次测试，所以作出了如下的设计目标：“一个模块的最大循环复杂度不能超过20。”循环复杂度度量一个模块源代码中逻辑分支数目。在一个模块中加入过多的分支和循环将使该模块难于测试、理解和维护。如果一些模块的循环复杂度大于20，这并不会导致整个项目的失败，但指定这样的设计标准有助于开发者达到一个令人满意的质量目标。



四  属性的取舍



    有时，不可避免地要对一些特定的属性对进行取舍。用户和开发者必须确定哪些属性比其它属性更为重要，并定出优先级。在他们作决策时，要始终遵照那些优先级。例如，增强软件可重用性的设计方法也可以使软件变得灵活、更易于与其它软件组件相连接、更易于维护、更易于移植并且更易于测试。一个单元格中的减号表明单元格所在行的属性增加了对其所在列的属性的不利影响。高效性对其它许多属性具有消极影响。如果你编写最紧凑，最快的代码，并使用一种特殊的预编译器和操作系统，那么这将不易移植到其它环境，而且还难于维护和改进软件。类似地，一些优化操作者易用性的系统或企图具有灵活性、可用性并且可以与其它软硬件相互操作的系统将付出性能方面的代价。例如，比起使用具有完整的制定图形代码的旧应用系统，使用外部的通用图形引擎工具生成图形规划将大大降低性能。你必须在性能代价和你所提出的解决方案的预期利益之间作出权衡，以确保作出合理的取舍。为了达到产品特性的最佳平衡，你必须在需求获取阶段识别、确定相关的质量属性，并且为之确定优先级。
* 如果软件要在多平台下运行（可移植性），那么就不要对可用性抱有乐观态度。
* 可重用软件能普遍适用于多种环境中，因此，不能达到特定的容错（可靠性）或完整性目标。
* 对于高安全的系统，很难完全测试其完整性需求；可重用的类组件或与其它应用程序的互操作可能会破坏其安全机制。
在软件中，其自身不能实现质量特性的合理平衡。在需求获取的过程中，加入对质量属性期望的讨论，并把你所了解的写入软件需求规格说明中。这样，才有可能提供使所有项目风险承担者满意的产品。


五 具体体现
  1 http://www.51testing.com/?168798/action_viewspace_itemid_106801.html
  2 http://www.51testing.com/?168798/action_viewspace_itemid_106802.html
  3 http://www.51testing.com/?168798/action_viewspace_itemid_106804.html


六 ...


七 阿七签名专用...嘿嘿...


[ 本帖最后由 阿七 于 2009-2-12 15:27 编辑 ]

kuailederen

我是提这个问题的，我希望的答案是有具体的解决办法，实施方案。比如：
有谁写过度量的准则，可以共享以下。

投缘

在立项前的需求采集阶段，最好把这些方面特性收集完全，这样就可以作为后期测试的一个目标依据，满足了客户的就是达标的。

yetties2005

也没有什么比较好的方法，跟着学习下。

b45993e

软件特征
复杂性：人脑功能的加强与延伸
难以描述性：自然语言的二义性导致难以表达
不可见性：无形的，存在于各种存储介质中
变化性：代码的修改引起功能的变化

加强需求分析力度
需求分析的目的
消除模糊性、歧义性和不一致性、分析数据要求，建立逻辑模型；
需求分析的任务
发现问题并求精的过程；
需求定义的结果
进一步准确无误的定义产品需求；

ipkh840122

公司做的是产品，最终东西都由老大说了算，我们测试的根本就不用管，管了也没有用！

maclehappy13

个人认为这些东西主要是通过质量保证措施来保证.

hai105

没什么说的，最后的东西只能客户说了算，就算通过了测试，但拿到客户那里仍然有可能不满意，所以比较合理的方法还是和客户充分沟通，例如经常让客户参与到测试过程中；在开发初期，尽快做出来一个model让客户看。

namisang

到现在为止，还没有那个软件企业敢保证自己开发的软件没有任何缺陷，更不敢不经过测试就直接发布，而且当软件中存在的缺陷发现的越早，它由于修复所花费的成本就越低，发现的越晚，修复所要花费的成本就越大，如果比较严重的缺陷在软件发布前还没有被发现并修复，后果是严重的，可能会导致项目倒闭，给公司造成重大的损失。在成本一定的条件下，高质量的软件才会占据市场，给软件企业带来更多的利润。提高并保证软件的质量，是企业发展的根本，软件企业必须非常重视自己开发的软件质量，应该最大限度的保证自己的软件在发布后没有比较严重的缺陷，要做到这点就必须对软件做测试，在公司中像重视软件质量一样来重视软件测试。

软件测试并不是软件生命周期中的收尾工作，由开发人员顺便做做而已的事情，而是软件测试工作已经参透到了软件生命周期的每一个阶段，从刚开始的需求分析到最后的软件发布前，都有软件测试的活动，每一个阶段的测试都有详细周密的计划和测试执行，来最大限度的保证软件的缺陷早发现早修复，降低开发成本。

现在的软件企业要想做大，做强，具有非常强的竞争力，不但要有优秀的开发团队，更要有非常优秀的测试团队，重视测试团队的建设，来保证软件的质量，这样在软件行业的激烈竞争中才能立于不败之地。

光明

哎。。肯定是老大和客户说了算啊。他们要怎样我们就怎样，服从安排。

free_xiaoyu

目前这些都是软性指标，从我们公司做的项目情况看，主要是满足了客户的就好。

atomtiger

   看的我头都大了。。。先回一个感慨。。再慢慢思考。。。

dream_cui

首先：应该满足客户的需求；
其次：美工搭配要柔和、美观，切图要细致；
再次：不同人员的查看感觉，以及客户意见。
当然最好能有长期经验的积累，了解客户的爱好，然后能提前挖掘客户的潜在需求，以免以后反攻麻烦。
个人认为，一次细致的活比反复多次好多了！
个人见解，呵呵~

郁闷的我

原帖由 dream_cui 于 2009-2-13 11:37 发表
首先：应该满足客户的需求；
其次：美工搭配要柔和、美观，切图要细致；
再次：不同人员的查看感觉，以及客户意见。
当然最好能有长期经验的积累，了解客户的爱好，然后能提前挖掘客户的潜在需求，以免以后反攻麻 ...

想法差不多西西．
还有4#的
1.软件质量：软件满足明确或隐含的需求的能力（特性和特征）总和
2.测量：建立质量指标，然后用特定方法去实施测量活动。
3.度量：按质量指标得到的测量结果。

[ 本帖最后由 郁闷的我 于 2009-2-13 13:24 编辑 ]