发布新日志

  • 一个软件如何确定测试结束点呢?

    尛蟲蟲 发布于 2008-09-24 10:58:13

    引用来源:http://bbs.51testing.com/viewthread.php?tid=124864&page=1#pid1055013

    在软件消亡之前,如果没有测试的结束点,那么软件测试就永无休止,永远不可能结束。软件测试的结束点,要依据自己公司具体情况来制定,不能一概而论!个人认为测试结束点由以下几个条件决定::

    1.基于“测试阶段”的原则:

    每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段,我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后,再进行后面一个阶段的测试。举个例子来说:单元测试,我们要求测试结束点必须满足“核心代码100%经过Code Review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准,当然也是如此。

    2.基于“测试用例”的原则:

      测试设计人员设计测试用例,并请项目组成员参与评审,测试用例一旦评审通过,后面测试时,就可以作为测试结束的一个参考标准。比如说在测试过程中,如果发现测试用例通过率太低,可以拒绝继续测试,待开发人员修复后再继续。在功能测试用例通过率达到100%,非功能性测试用例达到95%以上,允许正常结束测试。但是使用该原则作为测试结束点时,把握好测试用例的质量,非常关键。

    3.基于“缺陷收敛趋势”的原则:

      软件测试的生命周期中随着测试时间的推移,测试发现的缺陷图线,首先成逐渐上升趋势,然后测试到一定阶段,缺陷又成下降趋势,直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向,来定测试是否可以结束,这也是一个判定标准。

    4.基于“缺陷修复率”的原则:

      软件缺陷在测试生命周期中我们分成几个严重等级,它们分别是:严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时,严重错误和主要错误的缺陷修复率必须达到100%,不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到85%以上,允许存在少量功能缺陷,后面版本解决;对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题,可以暂时不用修改。

    5.基于“验收测试”的原则:

    很多公司都是做项目软件,如果这种要确定测试结束点,最好测试到一定阶段,达到或接近测试部门指定的标准后,就递交用户做验收测试。如果通过用户的测试验收,就可以立即终止测试部门的测试;如果客户验收测试时,发现了部分缺陷,就可以针对性的修改缺陷后,验证通过后递交客户,相应测试也可以结束。

    6.基于“覆盖率”的原则:

    对于测试“覆盖率”的原则,个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求,包括行业隐性需求、功能需求和性能需求等等,只要测试用例执行的覆盖率达到100%,基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心,非得要看看测试用例的执行效果,检查是否有用例被漏执行的情况,可以对常用的功能进行“抽样测试”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试,每个阶段都不能忽略。

    7.基于“项目计划”的原则:

    大多数情况下,每个项目从开始就要编写开发和测试的Schedule,相应的在测试计划中也会对应每个里程碑,对测试进度和测试结束点做一个限制,一般来说都要和项目组成员(开发,管理,测试,市场,销售人员)达成共识,团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了,测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成,就可以作为一个结束点。很多不规范的软件公司,都是把项目计划作为一个测试结束点,但是如果把它作为一个结束点,测试风险较大,软件质量很难得到保证。

    8.基于“缺陷度量”的原则:

    这个原则也许大家用的不是很多,了解比较少。我们可以对已经发现的缺陷,运用常用的缺陷分析技术和缺陷分析工具,用图表统计出来,方便查阅,分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题,我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然,最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说:一万行代码最多允许存在多少个什么严重等级的错误,这样比较好量化,比较好实施,成为测试缺陷度量的主流。

    9.基于“质量成本”的原则:

    一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是:人命关天的航天航空软件,那还是质量重要些,就算多花点钱、推迟一下进度,也要测试能保证较高质量以后才能终止测试,发布版本。如果是一般的常用软件,由于利益和市场的原因,哪怕有bug,也必须得先推出产品,没办法呀。一般来说,最主要的参考依据是:“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候,可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”,同时保证公司利益最大化。如果找到bug的成本比,用户发现bug的成本还高,也可以终止测试。

    10.基于“测试行业经验”的原则:

    很多情况下,测试行业的一些经验,也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度,测试人员的工作能力,测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中,每个人都没有项目行业经验数据积累,拿到一个新的项目,自然是一头雾水,不知道从何处开始,测试质量自然不会很高。因此通过测试者的经验,对确认测试执行和结束点也会起到关键性的作用。
  • 测试用例设计_如何提高测试覆盖率(三)

    iamseaing 发布于 2008-03-27 09:11:05

    三、测试数据的设计

    每一个测试思路最终都要转化成具体的数据才能来执行。关于测试数据设计的方法也不外乎那几种,就不再赘述了。此处单就一些经常易犯的错误,提出一些注意点,作为用例数据设计时的参考:

    1、尽量避免可能出现歧义测试结果的数据:即你设计的数据必须能唯一正确地反映出你所希望测试的结果。比如一组测试数据,有可能得到结果A或结果B,此时单用此数据来测试预期结果为A的用例,那明显就产生了歧义。

    2、对于不便具体列示的数据,则必须详细描述其各项特性:有时我们在设计用例时为节约时间,不一定要到具体的一个数值,这也是允许的,但前提是你必须要详细描述清楚你要测试的数据特性。比如数据库字段限长20,要测试超长数据时,可以描述为:尝试输入长度为21位的半角英文字符;尝试输入长度为19位的半角英文字符,然后切换到中文全角再输入一位全角字符等。千万不能写成:尝试输入超长字符,因为这只能是测试方案,作为方案是可以这样写,但到用例阶段,必须要是具体的、明确的、可操作的。

    3、测试数据的设计必须有明确目的性:即测试数据是从测试方案衍生而来的。如上例测试方案是测超长字符输入控制,所以测试数据就要根据具体字段长度来录入超长数据,如果一味录入长15位、长16位的数据那就没意义了。好的测试数据是可以同时针对多个测试方案的,此时可以在用例边注明一下该数据的测试目的,因为随着时间推移,对着具体的数据你也许会忘了它到底是测什么的,而这对你最后总结测试,查验测试覆盖率是非常不利的,所以随时记下你的思路想法吧,好记性不如烂笔头。

    4、测试数据可省略描述:测试数据描述以能让人看懂为准则。所以写用例时当碰到连续几个用例,仅某几个关键数据值改动,其余均是一样的情况下,不必每个用例都要重复描述所有数据,可以在第一个用例描述完整之后,其余用例中仅列示不同的数据,并标明其余数据同上第X个用例,即可。这样测试时仍能复原测试数据,且该用例的测试目的一眼就明,增加了用例的清晰性。

    至些,我根据测试用例设计的顺序,从测试数据的切面设计(即测试项划分),到详细测试用例设计,再到测试数据设计三个层面,逐一介绍了如何来提高测试用例的覆盖度。因为具体项目中的具体情况太多,以上叙述的内容也只能是管窥蠡测。至于其中的疏漏错误之处应也难免,只希望各位阅后能打开思路,从自己多年的测试经验中多总结、提炼出一些想法思路,进一步补充完善这个文档,使大家的测试用例设计能力都能进一步提升。

Open Toolbar