2017-08-09 16:57:55 zjuxsl 阅读数 378
  • 机器学习之概率与统计推断

    本课程讲解机器学习算法所需概率和统计推断知识。概率部分包括概率公理及推论、条件概率、贝叶斯公式、随机变量及其概率函数(CDF/pdf)、常用概率分布及其均值、方差;统计推断部分包括大数定律和中心极限定理、极大似然估计、贝叶斯估计,估计的评价、偏差-方差平衡。课程还会讲解假设检验的基本概念。

    20303 人正在学习 去看看 AI100讲师

什么是谷歌测试定律?

软件测试(Software Testing)是软件工程(Software Engineering)中不可或缺的一个过程。软件测试触发预定义的测试步骤、比较软件的实际输出结果和预期输出结果,以此来评价软件质量(Quality),判断软件的实现是否满足设计目标和用户需求。只有经过严格测试的软件,才能发布给用户使用。在实际中,根据测试阶段的不同,软件测试可以分为:

  • 单元测试: 测试对象通常是一个函数(Function)或一个类(Class)。单元测试与软件代码高度相关,通常由开发人员自己完成。

  • 组件测试: 测试对象通常是一个模块(Module),目的是验证模块的功能是否满足设计目标。组件测试通常和软件开发同步进行。

  • 集成测试: 测试对象可以是一个独立软件实体(Entity)的对外接口(本质上测试的是这个软件实体对外呈现的功能);也可以是多个相邻软件实体相互之间的接口(本质上测试的是多个相邻软件实体呈现的整体功能)。集成测试聚焦于软件功能,一般在软件开发部分或全部完成后进行。

  • 系统测试: 测试对象是包含了所有软件实体的真实系统。系统测试从用户的角度设计测试步骤,目的是检验系统是否满足用户需求。一般在系统所有软件都开发完成后进行。

在谷歌,测试的分类更多地强调测试范围,而不是测试阶段。具体来说,谷歌把软件测试分为:

  • Small Tests(小范围测试): 通常对应单元测试和组件测试。

  • Medium Tests(中等范围测试): 通常对应集成测试。在谷歌,Medium Tests强调的测试对象是相互之间有直接接口或互操作(Interoperation)关系的相邻软件模块/软件实体。

  • Large Tests(大范围测试): 通常对应系统测试。

在长期的测试实践中,谷歌发现,不同的测试范围或阶段中发现的软件Bug(即缺陷、漏洞,下同),其解决成本(Fixing Cost)具有极其显著的差别。举例来说,解决一个小范围测试(单元测试)中发现的软件Bug需要花费的成本是5美金左右,解决一个中等范围测试(集成测试)中发现的软件Bug的成本在500美金左右,而解决一个大范围测试(系统测试)中发现的软件Bug的花费则高达5000美金。

title

谷歌的这一经验数据在软件行业中引起了广泛共鸣、得到了许多人的认同。在这里,笔者以更加科学的方式来描述谷歌的这一发现,并将其命名为谷歌测试定律

[谷歌测试定律]. 随着测试阶段的推进(Small Tests -> Medium Tests -> Large Tests,或单元测试 -> 组件测试 -> 集成测试 -> 系统测试),测试中所发现的软件Bug的解决成本呈指数级增长。

为什么谷歌测试定律成立?

软件Bug一旦被发现,我们需要做的事情是确定的,那就是找到软件Bug产生的原因、修改软件代码、然后验证代码的修改是否确实解决了Bug。因此:

Bug解决成本 = Bug定位成本 + 代码修改成本 + 修改验证成本

  • Bug定位成本: 一旦发现Bug,首先需要回答的是, 引起Bug的原因是什么?谁负责解决Bug? 不同的测试阶段最大的区别就是被测对象(Tested Object)不同。被测对象既可以小到一个函数,也可以大到整个系统。从技术角度来说,被测对象的范围越广,可能引起Bug的嫌疑模块就越多,精确地找到真正引起Bug的模块就越困难;从组织角度来说,被测对象的范围越广,牵涉到的部门和个人就越多,针对Bug产生原因和Bug责任人的反复讨论和沟通所耗费的成本就越高。根据经验,随着测试阶段的推进,被测对象的范围将成倍扩大,牵涉到的人员也将成倍增加,因此通常来说Bug定位的成本也是成倍增加的

  • 代码修改成本: 一般来说,只要精确地找到了产生Bug的软件代码,那么解决Bug所带来的代码改动量是确定和一致的。因此,不同的测试阶段所发现的软件Bug,其需要的代码修改成本可以认为是相等的。

  • 修改验证成本: 软件Bug的解决意味着软件代码的改动(Change)。一切代码改动都需要被充分地验证。我们需要确保: (1)代码的改动确实解决了我们发现的Bug,(2)代码的改动没有破坏任何已有的功能。在执行层面,最基本的一个要求就是,修改后的软件包需要被拿到发现软件Bug的测试环境中去验证。如果依然存在问题,那么代码修改无效,需要重新修改;只有测试用例通过了,才能认为修改是有效的。一般来说,越往后期的测试阶段,测试的环境越复杂,测试的执行时间越长,测试花费的人力成本越高。举例来说,单元测试可能只要数秒钟就能完成并且一定是自动化的,而系统测试则可能需要消耗人力并要一天甚至几天才能完成。因此,随着测试阶段的推进,软件改动的验证所花费的成本是成倍增长的

综合Bug定位成本、代码修改成本和修改验证成本,我们发现,软件Bug的解决成本确实是随着测试阶段的推进成倍增加的。从数学角度看,总的趋势就是指数级增长的。至于这个指数曲线的底数的大小(决定指数曲线增长幅度),虽无法精确地给定,但可以确定的是,当软件项目越大型、软件架构越复杂、参与人员越分散时,指数曲线的底数就越大,Bug解决成本的增长幅度就越快

谷歌测试定律的启示

  • 测试资源要向前期测试阶段倾斜。为何要把有限的测试资源更多地投入到前期测试阶段?笔者从可行性和必要性两个方面给出回答。在讨论可行性之前,我们明确:

    [测试追溯定律]. 软件测试的各个不同阶段,凡是在当前测试阶段发现的软件Bug,一定可以在前一个测试阶段或更早的测试阶段,通过修改或者增加一个测试用例来重现。

    在实际中,由于各种因素(测试覆盖度不够高、测试力度不够强、测试工具不够可靠、测试样本不够可信等),软件Bug可能会遗漏到后续的测试阶段。但是从理论上说,每个测试阶段都是有可能发现全部潜在软件Bug的。通过加大前期测试的投入、优化前期测试的过程、提升前期测试的效果,来减少遗漏到后期测试阶段的Bug数量,这条路是可行的。另外,根据谷歌测试定律,同一个软件Bug,在后期测试阶段被发现,相比在前期测试阶段被发现,其解决成本可能要高一个数量级。为了节省公司成本、提高产品质量,我们应该尽可能地在前期测试阶段发现更多的Bug。为此,我们务必要确保前期测试的有效性和覆盖度。前期测试阶段的高度自动化,有助于实现这样的目标。在总的测试资源有限的情况下,将更多的测试资源投入到前期测试阶段是必要的。反过来说,如果前期阶段的测试不充分,导致大量本该在前期测试阶段被发现的Bug遗漏到后期测试阶段才被发现。到时候,我们可能需要投入巨量的人力物力去解决这些Bug。这对部门和公司来说,将是难以承受之重。

  • 测试工作要尽可能早地开展。在敏捷时代,测试无须等待软件开发完成之后才展开,而是与软件开发同步进行。具体来说,在每个迭代周期,软件开发致力于交付一个或多个可供用户使用的功能点。这有助于测试工作的提早介入。测试开展得越早,软件Bug发现得也就越早,解决软件Bug的成本也就越低。在实际中,测试工作的开展不仅受制于软件开发进度,还受制于测试自身所依赖的外部软件和工具。通过使用模拟器技术(即Mock),我们可以减少对外部的依赖,不仅避免测试进度受制于人,而且将测试更多地聚焦在被测对象身上。

  • 千方百计缩短测试时间。狭义的测试时间指测试步骤的执行时间,广义的测试时间指从开发人员提交代码到获得测试反馈结果的时间间隔。缩短测试时间,不仅有利于提升软件测试的生产力(单位时间执行更多的测试),而且有利于提升软件开发的生产力。很多时候,软件开发是一个反复提交代码的过程。如果测试的验证速度很快,那么代码的提交就会更频繁,软件开发的效率也就得到了提高。任何一个测试阶段,无论是单元测试还是系统测试,加快测试速度、缩短反馈时间,都是很重要的。在实际中,通过改进系统的可测性、并行或分布式执行测试用例等,可以有效地提高测试速度、缩短测试时间。

  • CBRT: 基于代码改动的回归测试。所谓CBRT(Change-Based Regression Testing),指的是每次代码改动均执行回归测试用例。在软件开发中,代码的改动(Change)是常态。新功能实现、Bug修复、代码重构等都会带来代码的修改。回归测试(Regression Testing)是确保代码改动不破坏已有功能的重要举措。然而,回归测试能不能发挥更大的作用,与回归测试的执行时间有关系。是代码每次改动就执行回归测试,还是许多改动合在一起后再执行回归测试,有很大差别。前者,回归测试一旦发现Bug,责任人是清楚的,解决Bug也更容易;而后者,回归测试一旦发现Bug,单单排查原因、找到责任人就需要耗费大量的时间。因此,代码一旦发生改动就立即执行回归测试是很有必要的。在谷歌,考虑到每次代码改动均执行所有回归测试(测试集可能非常大)带来的开销较大。为此,基于对代码模块和测试用例的关联度分析,在谷歌,每次代码改动只执行回归测试子集,即只执行那些可能受到被改动代码影响的测试用例的集合。

  • 对测试遗漏出去的每一个Bug进行EDA。无论前期测试做得如何好,我们都不能百分之百保证不会遗漏Bug到后期测试阶段。也就是说,只要后期测试阶段发现了软件Bug,那就意味着前提测试阶段具有改进的空间。那么,如何持续地改进前期测试呢? 笔者认为,针对每一个遗漏到后期测试阶段的软件Bug,至少有两件事情是可以做的。首先,开发人员需要做代码改动,而前期测试人员也应该针对测试用例做改进。根据测试追溯定律,后期测试发现的软件Bug一定可以通过修改或增加一个前期测试用例来复现。这样,我们可以基于改进后的前期测试用例对代码改动进行验证。另外,前期测试人员需要进行EDA(Escaped Defect Analysis),即遗漏问题分析。不仅要分析为什么问题被遗漏了,更要给出具体和切实可行的改进措施,以举一反三,避免此类错误再次发生。只有持续地改进,我们才能把前期测试工作做得越来越好,从而最大程度减少遗漏到后期测试阶段的Bug数量。

2015-04-30 00:20:28 u010028869 阅读数 3492
  • 机器学习之概率与统计推断

    本课程讲解机器学习算法所需概率和统计推断知识。概率部分包括概率公理及推论、条件概率、贝叶斯公式、随机变量及其概率函数(CDF/pdf)、常用概率分布及其均值、方差;统计推断部分包括大数定律和中心极限定理、极大似然估计、贝叶斯估计,估计的评价、偏差-方差平衡。课程还会讲解假设检验的基本概念。

    20303 人正在学习 去看看 AI100讲师

最近一直在学习测试方面的知识,也浏览了许多博客,通过这些博客也了解到了许多未曾接触过的关于测试方面的理

论和原则以及一些常识性的东西,比如测试的不完全性,测试中的二八定律,缺陷的必然性等。这篇文章做下整理,

分享给大家。了解这些将对于我们在进行软件测试时把握软件测试尺度很有帮助。


测试的不完全性

很显然,由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素,哪怕是一个极

其简单的程序,要想穷尽所有逻辑路径,所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例

子,比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试

的话,从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的。为此作为软件测试,我们一般采用等

价类和边界值分析等措施来进行实际的软件测试,寻找最小用例集合成为我们精简测试复杂性的一条必经之道。


测试具有免疫性(软件缺陷免疫性)

软件缺陷与病毒一样具有可怕的“ 免疫性 ” ,测试人员对其采用的测试越多,其免疫能力就越强,寻找更多软件缺

陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000行的程序中有 500 个软件缺陷并且这些

软件错误分布时均匀的,则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力

为 X小时 /100 行。照此推算,软件存在 500 个缺陷时,我们查找一个软件缺陷需要 X 小时,当软件只存在 5 个错

误时,我们每查找一个软件缺陷需要 100X小时。实践证明,实际的测试过程比上面的假设更为苛刻,为此我们必须

更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺

陷,因此软件测试应该尽可能的多采用多种途径进行测试。


测试是泛型概念 ” (要全程测试)

软件测试仅存在于程序完成之后?现在这个概念恐怕难以立足了。因为如果单纯的只将程序设计阶段后的阶段称之为

软件测试的话,需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺

陷也是软件缺陷,记住“ 软件缺陷具有生育能力 ”。软件测试应该跨越整个软件开发流程。需求验证(自检)和设计验

证(自检)也可以算作软件测试的一种。软件测试应该是一个泛型概念,涵盖整个软件生命周期,这样才能确保周期的

每个阶段禁得起考验。同时测试本身也需要有第三者进行评估(信息系统审计和软件工程监理),即测试本身也应当被

测试,从而确保测试自身的可靠性和高效性。否则自身不正,难以服人。


另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件,软件测试是提高产品质量最直接、最快捷

的手段,但决不是一个根本手段。


二八定律

二八定律,这里感觉非常亲切,原来二八定律也可以用在测试里,80%的软件缺陷常常生存在软件 20% 的空间里。

这个原则告诉我们,如果你想使软件测试有效地话,记住常常光临其高危多发 “ 地段 ”。在那里发现软件缺陷的可

能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个

原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。


二八定律的另外一种情况是,我们在系统分析、系统设计、系统实现阶段的复审,测试工作中能够发现和避免 80% 

的软件缺陷,此后的系统测试能够帮助我们找出剩余缺陷中的 80% ,最后的 5%的软件缺陷可能只有在系统交付使

用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷,却无法保证

能够发现所有的软件缺陷。


二八定律还能反映到软件测试的自动化方面上来,实践证明 80%的软件缺陷可以借助人工测试而发现, 20% 的软件

缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分,因此尚有5% 左右的软件缺陷需要通过其他

方式进行发现和修正。


为效益而测试

为什么我们要实施软件测试,是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施

软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们

在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来,在软件测试中我

们应该尽量地保持软件测试简单性,切勿将软件测试过度复杂化,拿物理学家爱因斯坦的话说就是:Keep it simple 

but not too simple 。


缺陷的必然性

软件测试中,由于错误的关联性,并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复

的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的,一个矛盾的消失必然会引发另外一个矛盾

的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中,我们常常还会

受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围,选

择一个折中的方案或是从非软件的因素(比如提升硬件性能)考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的

事实。

 


这些常识性的理论原则我觉得非常有必要了解一下,因为这些都是前辈们经过无数次尝试总结出来的,站在巨人的肩

膀上能使我们少走一些弯路,关于测试的学习仍在继续!

 

参考: <http://www.ltesting.net/ceshi/ceshijishu/rjcsgcsrm/2013/1023/206738.html

2008-06-01 08:34:00 ooyyee11 阅读数 762
  • 机器学习之概率与统计推断

    本课程讲解机器学习算法所需概率和统计推断知识。概率部分包括概率公理及推论、条件概率、贝叶斯公式、随机变量及其概率函数(CDF/pdf)、常用概率分布及其均值、方差;统计推断部分包括大数定律和中心极限定理、极大似然估计、贝叶斯估计,估计的评价、偏差-方差平衡。课程还会讲解假设检验的基本概念。

    20303 人正在学习 去看看 AI100讲师

接口调用定律与测试驱动接口设计

2.5  测试驱动接口设计

2.5.1  接口调用定律与测试驱动接口设计

敏捷软件开发的原则里,有一条原则是朝着稳定的方向依赖的原则,在作者的博客里有一篇文章探讨了接口关系稳定原理,主要的意思是应该让接口稳定性低的模块调用接口稳定性高的模块。有关接口关系稳定原理的详细情况请看作者博客http://blog.csdn.net/ drzhouweiming

在面向对象的思想里,一个重要的思想就是数据的封装与隐藏,也就是说一个模块要操作另外一个模块时需要使用它的接口来操作它的内部数据,而不能绕过接口直接去操作它的内部数据。

面向对象的这个思想,其实可以由接口关系稳定原理推导出来:

接口覆盖定理:一个模块必须通过另外一个模块的稳定接口去操作(使用)它的可变数据。换句话说,一个模块的稳定接口集合必须覆盖所有其他模块需要操作的可变数据。

如果一个模块直接操作另一个模块的可变数据,相当于使用可变数据作为接口,由于可变数据存在变化的可能,因此接口是不稳定的,这和接口关系稳定原理产生冲突,因此一个模块不能直接去操作另一模块的可变数据,而需要通过另一模块的抽象接口来操作它的可变数据。

关于接口覆盖定理,最常遇到的情况就是类的成员变量要提供Get()、Set()方法来进行操作,不能直接去访问类的成员变量。

根据接口覆盖定理,外部模块操作模块内部的可变数据时,必须由模块提供的稳定接口来进行操作。设计模块的稳定接口时,必须知道模块有哪些可变数据,而可变数据的寻找工作属于测试的范畴,因此稳定接口的设计可以通过测试来驱动。

一个模块的接口实际上就是对模块的可变数据进行解释的方法,可变数据的变化本质上都是由外部原因引起的,模块接口层的可变数据是由外部输入层的可变数据驱动的,因此设计接口时,首先需要分析外部输入层的可变数据。

2.5.2  测试驱动设计的步骤

采用测试驱动设计时,应按以下步骤来进行。

(1)找出可变数据,根据测试数据构造出测试空间。

(2)将测试空间抽象成编程语言的基本数据类型或由基本数据类型组合成的数据结构类型。其实这和《设计模式解析》一书中所说的根据可变数据的共性创建抽象是一回事。

(3)如果需要给外部模块提供输出结果,那么还需要分析测试空间中的对应输出结果集合,将结果集合也抽象成编程语言的基本数据类型或由基本数据类型组合成的数据结构类型。

(4)分析其他模块对本模块的需求,根据需求分解出各个操作,合并共性的操作,得出操作集合。

(5)分析各个操作所设计的可变数据,设计出对应接口来处理抽象的数据类型,将抽象的数据类型作为接口的输入和输出参数。

(6)检查是否有遗漏未被接口覆盖的可变数据,如果有,表明接口有遗漏需要重新分析需求中涉及的操作。

下面以文件操作的接口设计为例讲解测试驱动设计。为方便讲解起见,假设需求中只考虑文件的二进制读写需求,不考虑文件的其他操作需求。

读操作中,牵涉到的可变数据有文件名、文件系统数据(文件头等)、文件内容、要读取数据的文件位置和读取数据的长度等。读操作需要将读取的数据输出给其他模块使用,因此可能还需要做一些校验。

写操作中,牵涉到的可变数据有文件名、文件系统数据、写入文件的数据、写入数据的长度和写入的位置等。

文件名抽象成一个字符串或字符串指针,所需用到的文件系统数据可以抽象成一个文件描述符,文件位置抽象成一个整型变量,长度也可抽象成一个整型变量,写入数据可抽象成一个void指针。

读操作的处理过程需要先从文件系统中找到对应文件,然后读取文件头数据进行分析,再从文件中读取指定位置的数据,最后将处理过程中所需的内存等资源释放掉。写操作的处理过程和读操作类似,不同的只是将读数据改为写数据,另外如果找不到文件时可能需要创建一个空文件。

根据处理过程中所涉及的操作,可以设计出4个基本操作来满足上面的处理过程:

(1)打开文件操作:负责从操作系统中找到对应文件或创建空文件,读取文件头数据进行分析,打开文件操作需要,输出文件描述符。

(2)读文件操作:负责从文件的指定位置读取指定长度的数据,输出读取的数据,并输出实际读取的长度和读取是否成功的信息。

(3)写文件操作:负责将指定长度的数据写入文件的指定位置,需要输出写入是否成功的信息。

(4)关闭操作:释放处理过程中分配的各种资源。

这样在将操作分解完后,打开文件操作涉及的可变数据为文件名和文件头数据等。

读文件操作涉及的可变数据有文件描述符、文件位置、读取长度。

写文件操作涉及的可变数据有文件描述符、文件位置、写入数据、写入数据的长度。

关闭操作涉及的可变数据主要是文件描述符。

这样可以设计出如下4个基本接口:

u         int FileRead(HANDLE hFile, int nPos, void *pBuf, int nReadLen);

u         HANDLE FileOpen(char *pszFileName);

u         int FileWrite(HANDLE hFile, int nPos, void *pData, int nDataLen);

u         void FileClose(HANDLE hFile);

当然,这里也可以像C标准函数一样设计fseek()函数来操作nPos可变数据,FileRead和FileWrite接口中就不需要nPos参数了,接口使用起来更符合使用要求。

2.5.3  命令行程序接口设计实例

为了加深对测试驱动设计的理解,这里再讲一个命令行程序接口设计实例。以一个Unix命令行程序为例,Unix提供了许多的命令如ls、cd、mkdir、ps等命令供用户使用,有些命令属于内部命令,有些属于外部命令,如何来设计命令行程序提供给其他模块使用的接口呢?

在命令行程序中,外部输入的可变数据就是用户在命令行中输入的命令和参数字符串,它的测试空间是用户输入的各种可能的字符串集合。因此可以用一个字符串指针来表示用户输入的可变数据。

当然命令行程序中的可变数据并不只是用户在命令行中输入的数据,它还包括各种命令,由于各种命令在未来的操作系统版本中可能发生变化,因此这些命令的程序执行代码对命令行程序来说也是可变数据。例如ls、cd等内部命令,将来可能会增加或修改内部命令,这些内部命令的函数实体是可变的,所构成的测试空间为一系列函数实体的集合,对于这些可变数据,可以将其抽象成一个可查找的数据结构,数据结构的每个节点里包含一个指向函数实体的函数指针和命令名字。

因此命令行程序里需要提供操作用户输入字符串及不同命令函数实体可变数据的接口。根据命令行程序的功能,一个接口用来执行命令,操作用户输入的字符串可变数据。另外一个接口用来操作不同命令函数实体可变数据,用来将命令注册到内部可变数据的抽象上。

这样就可以设计出命令程序的两个接口——

n      执行接口

int Execute(char *pszCmdLine);

n      命令注册接口

typedef int (*RUNCMD)(char *pszCmdLine);

int RegCmd(char *pszCmdName, RUNCMD RunCmdFunc);

如果使用类作为接口,那么将这两个接口放入类中,并用虚函数的多态性来取代回调函数,就可以看到它和设计模式中的命令模式是一致的。由此也可以发现设计模式实质上是对可变数据创建抽象的一些具体方法。

2019-07-01 19:49:11 pingsha_luoyan 阅读数 2972
  • 机器学习之概率与统计推断

    本课程讲解机器学习算法所需概率和统计推断知识。概率部分包括概率公理及推论、条件概率、贝叶斯公式、随机变量及其概率函数(CDF/pdf)、常用概率分布及其均值、方差;统计推断部分包括大数定律和中心极限定理、极大似然估计、贝叶斯估计,估计的评价、偏差-方差平衡。课程还会讲解假设检验的基本概念。

    20303 人正在学习 去看看 AI100讲师
  • 所有的测试要追溯到用户的需求

    • 简单说,一切从用户角度出发
  • 测试应尽早地介入

    • 软件缺陷存在放大趋势,越往测试后期发现缺陷,修复缺陷的代价就越大
  • 测试无法穷举

  • 避免测试者自测

    • 为了达到效果应由独立的测试小组,第三方来完成测试
  • 集群现象:

    • 二八定律:80%的错误集中在20%的程序模块中。

  • 杀虫剂悖论

    • 测试用例需要进行定期评审和修改。
  • 不存在缺陷的谬论

  • 测试活动依赖于测试背景

    • 银行等金融系统:安全性放在首位
    • 电商平台:兼容性和性能放到首位

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2010-09-29 09:38:09 iamxieyu 阅读数 32
  • 机器学习之概率与统计推断

    本课程讲解机器学习算法所需概率和统计推断知识。概率部分包括概率公理及推论、条件概率、贝叶斯公式、随机变量及其概率函数(CDF/pdf)、常用概率分布及其均值、方差;统计推断部分包括大数定律和中心极限定理、极大似然估计、贝叶斯估计,估计的评价、偏差-方差平衡。课程还会讲解假设检验的基本概念。

    20303 人正在学习 去看看 AI100讲师

软件测试七大戒律


软件要控制人的思维,但思维是不可控的。这决定了没有BUG的软件是不存在的。“测试是要被终止的”,这是测试圈内一条原则性的定律,意思是说软件测试要适度,不能不问代价一测到底,过分追求没有BUG的完美软件。通过大量的采访,受到业内多位专家的启发,记者认为当前我国软件测试领域有七个趋势:

  一、不只是为了测试,软件测试工作应有更高的定位,那就是提升软件质量。测试人员的工作目标不仅仅是找BUG,而是与开发人员、业务人员协作,以得到质量更高的软件。

  二、对任何类型的执行主体而言,软件测试都是一项需要衡量投入产出、成本收益的工作,因此测试团队的建立、测试环境的搭建、测试工具的选择、测试过程的管理、外包与否,企业都要根据自己的需求衡量决定。

  三、开发与测试是对立统一的整体,二者的工作内容和考核都不可能严格分开。企业可以从管理学和心理学的角度加强对测试管理的研究和实践。

  四、测试工作的专业分工将更加细化,测试工程师岗位分工和测试机构行业分工趋势将显现。

  五、当前我国测试人员的能力有待提升。我们除了需要熟练的找BUG高手,还需要能站到更高层面,从开发、测试的整体层面掌握测试需求、设计、流程和结果展现的人才。这要求测试工程师掌握更新的测试理念、更高的测试技能,具备更深的业务积累。

  六、已经渗透至整个软件开发生命周期的测试管理工作是一个有机的整体,缺陷管理、测试需求管理、测试环境管理、测试用例管理、测试执行管理是组成木桶的木板,任何一块都不能短。

  七、如何对测试工作进行考核评估是当前业界的一个难题,有待进一步研究、实践。

详解28定律

阅读数 28

软件测试基础知识

阅读数 154

没有更多推荐了,返回首页