对拟合趋势的K值的分析

　　这篇文章将会介绍到对S型曲线的渐近值K值的分析。在之前介绍S型曲线的文章中，已经对K值进行了介绍：S型曲线会趋近一条渐近线（K值），即“S”型增长曲线的最大值会接近K，但不会超过K；增长率会不断下降直至为零。以软件缺陷预测为例，有了K值，我们就能得到该软件系统最终应当发现的缺陷数目。这样在发布软件之前，根据已经检测到的缺陷的数目，就可以得到还有多少个缺陷未被发现。因此，为我们是否可以发布这个软件、或者说我们发布这个软件的原因提供了依据。

　　大家都明白渐近线的含义，K值就相当于渐近线。那还有什么可讨论的呢？实践证明，在缺陷预测时，用9个实际数据预测得到的曲线，与用15个实际数据预测得到的曲线并不相同，它们的趋近值，即K值也不相同。那么，到底哪个模型更为拟合？已经有了9个数据时预测得到的模型，是否还需要用更多的数据去重新预测呢？那如果有了20个实际数据，是否还有必要用25个实际数据重新预测呢？

　　在曲线预测中，预测的结果使得我们能够得到曲线在每个时间的分布情况以及曲线最终的逼近情况。所以，对渐近值K的预测是我们预测的目的之一。

　　从上述曲线模型的预测过程中可以看出，预测的结果是最终会得到一个K值。如果使用不同数目的样本数据进行预测能够得到相同的K值，那么就说明K值是稳定的。但在实际项目中，多次实验得到的结果却是K的值并不是唯一不变的，它也是一个随时间趋势、遵循一定的规律不断发展变化的值。

　　那么，K值会如何变化呢？下面是我们针对这个问题，在实际项目中所作的实验。

　　◆ 将预测出的数值用同样的预测方法重新预测，比较将预测值用作样本值进行预测得到的结果与之前的预测值之间的差别

　　◇ 结果：两次结果并不相同，但差别很小，K值的接近度近似于100%

　　◆ 针对三点法进行实验。普通三点法所取三点分别为起点、中点和“终点”，三点之间相距分别为M；通过比较所取的三点若稍有差别时得到的结果来分析K值，所以取三点分别为第二点、中点的后一点和“终点”（或者是类似的取法），它们之间同样相距分别为M（这里是对Gompertz曲线和Logistic曲线做的实验）

　　◇ 结果：两次结果也并不完全相同，但差别同样很小，K值的接近度近似于99%

　　上面这两个实验虽然得到了相近的结果，看起来几次实验K值也是接近的，但并不能得到K值是稳定的这一结论，要想对K值稳定度进行分析，还需要继续针对K值进行不同的实验来分析研究，或利用大量数据进行验证。

　　● 预测监控

　　预测的一个十分重要的理论基础是：一定形式的需求模式过去、现在和将来都起着基本相同的作用，即过去起作用的模型现在依然是有效的，那么如何来判断实际情况呢，这就需要进行预测监控。

　　检验预测模型是否仍然有效的一个简单方法是将最近的实际值与预测值进行比较，看偏差是否在可以接受的范围之内，另一种方法是应用跟踪信号（Tracking Signal，TS）。

　　所谓跟踪信号，是指预测误差滚动和与平均绝对误差的比值，公式为：

　　TS=RSFE/MAD=∑（At-Ft）/MAD

　　各符号的含义见上篇文章。每当有实际需求发生时，就应当计算TS。如果预测模型仍然有效，TS应该比较接近于0。只有TS在一定范围内（设定上下限），才认为预测模型可以继续使用，否则，就应该重新选择模型，如图1。

图1 TS范围

　　图1中，两条红色的线代表的是TS的上下限范围，黑色曲线代表的是TS，TS不断变化，但只有在上下限的范围之内的TS才可以看作是有效的，可以继续使用，否则，TS不再有效，不应继续使用。

　时间就像驰骋在辽阔草原上的骏马，丝毫没有一点喘息的片刻。不知不觉，工作快3个年头了。从早期的JAVA软件开发到目前的软件测试，一路可谓是“艰辛”的度过。

　　回首过去，所有的事都是无心插柳，正应了那句：life is like a box of chocalate......浮躁和贪嗔，总让人不断营营役役，终其一生，却往往又一事无成，到死都未必明白自己活着是为了什么？！

　　以前，当然也包括现在，时常感到迷惘，不知道该做什么，不知道以后的路该怎么走！

　　每当看电影《阿甘正传》时，我都不由自主的对生活充满激情：阿甘在风中毫无意义奔跑的时候，他究竟在想什么？当那么多人跟着阿甘在阳光下奔跑时，又是怎样的迷惘？当我们走在生活的路上时，我们又在想什么？

　　付出，终究会有回报的。人的一生也是如此。

　　从一名普通的测试员到测试精英，以下是个人的一点体会，如果不妥，敬请指正！

　　对于从事IT研发的人来说，无论是开发者、测试者甚至产品者，“思维”是非常重要的。思想的高度决定事物价值的体现。因此，作为产品质量的把关者，测试人员应培养以下思维模式：

　　【全局思维模式】

　　古语云：“不识庐山真面目，只缘身在此山中”，恰好体现出全局思维模式的重要性。世间的事物往往存在多面性，在软件领域更具有抽象性，我们只有从多个角度去度量、分析，才能掌握其本质。在日常的软件项目活动中，需求、测试用例以及其他文档评审，就是借助全局思维模式，让更多相关人员参与以补查项目解决方案的正确性，从而，可以降低或者避免风险的发生。

　　【逆向思维模式】

　　逆向思维，也称“求异思维”。是数学领域的一个支柱。逆向思维模式在测试活动中是不可缺少的一种指导。作为测试员，当发现Bug时，进一步定位问题的所在，通过日志或者其他信息工具进行逆流而上排查，进一步分析。从而为开发人员查找、解决问题节约一定的时间。除此之外，由于开发人员思维模式定型，因此，测试人员的逆向思维可以弥补开发人员在项目中的思维漏洞。

　　【换位思维模式】

　　换位思维模式，顾名思义，就是换个空间、角度去剖析问题。在认识某一事物时，人们总是会通过和头脑中的某些概念进行比较，找出相同、相异之处，或者归类，从而将其加入大脑中的知识体系，可能的话，再建立好的搜索方式，以便以后使用，最明显的例子就是“经验”的运用。对于新的项目，某个细节，我们都会采用以往经验去分析、处理。实际项目中，针对某个问题，我们会站在不同的角度去体验，用户、开发以及产品的使用者。只有通过这种方式，我们的产品才能得到市场的认可，社会的接受。

　　【极端思维模式】

　　随着软件产业在中国的日益成熟，越来越多的企业、用户对产品的质量更为关注，由最初的功能，渐渐涉及性能、安全性以及其他方面。

　　在测试活动中，非功能性缺陷也越来越引起市场、用户的重视。为了保证系统的稳定，我们引入性能测试；为了验证系统的账户安全性，我们采用边界值分析以确保产品是否满足用户最终需要。极端思维模式，就是在两极条件下，验证系统是否存在缺陷。

　　以上是测试活动中最主要的、最常用的思维模式。由于时间关系，今天先谈到这里。后续有时间，续叙！

　　其实这些思维方式，大家都在有意识或者无意识的运用着，它们各自都有自己的妙处，将我们的思维发散，有意识的将他们用在问题的思考上，有时可以给我们一种“柳暗花明又一村”的感觉。

　　最后想补充一下，只知道这些原则意义不是很大，如果真想能让它们成为思考的血液，发挥它们的真正价值，那需要很多的历练。其实想成为一名测试精英，远没有那么简单，需要的是一种坚持、一种毅力、一种（不断学习＋不断经历＋不断思考）的精神。

　一些有意义的条目：

　　1、考虑自动化是否能发现有价值的缺陷，是否经得起时间的考验，是否值得付出维护费用

　　2、决定需要测试什么和何时测试

　　*对于每一个被发现的缺陷，明确的讨论它应该在什么时候被发现

　　3、决定如何测试

　　*是否有一种特殊的路径引导人员找到这个缺陷

　　*这种功能或特许最好用哪种给定的方法来测试

　　*知道当前已经进行了哪些测试，以及我们目前和将要进行的测试如何才能增加总体测试效果

　　*发现软件问题，需要实际用户在实际的环境中，用实际的数据，去做实际的工作

　　*简单重复的工作实现测试自动化

　　4、测试中最困难的部分是：决定测什么，决定测试的完整性，确认用户场景等

　　5、哪些是好的测试，哪些是不好的测试；完成测试后，团队学会了什么？

　　测试修行：（很重要）

　　1、将测试分为两部分，即“测试今天的项目，准备明天的项目”

　　*保证当前的测试项目获得成功

　　*学习应该做些什么以便下一个测试项目更紧容易

　　2、警惕重复做一件事情，尝试能不能自动化

　　3、思考：

　　*我们用什么技术找到了那个缺陷？

　　*我们是否可以创建一种方法来找到更多这类缺陷？

　　*是否可以记住一些实际的测试经验并不断加以应用来提高测试效率？

　　*软件的哪些症状可以提示我们它有缺陷？

　　*我们将来能否从那些症状中得到更多的警示？

　　*这个缺陷教会了我们什么？

　　因而总结一系列的测试技术、建议和工具

　　4、反思：

　　*自己的测试流程是否有问题？

　　*测试流程里有没有缺陷？

　　*这里面是否存在妨碍我提高效率的障碍

　　*例如：

　　1）收集我们发布给用户的所有缺陷（特别是安全漏洞或者数据缺陷）：

　　反思我们是否有流程问题，思路是否有方向性错误，或者是否犯了错误

量化项目管理案例：缺陷趋势预测利器（1）

　不知身为软件工程师的你，在写代码时是不是有过这样的经历：一方面对自己写的代码信心满满，一方面又非常希望知道自己开发的代码的质量到底多高。如果代码真的没被测出bug来或者测出的bug较少时，反而有点担心——会不会还有隐藏的更深的bug没被发现？或者身为测试工程师的你，可能比开发人员担心的会更多：这些代码该不该再继续测试了？怎么就能断定当前的版本算是通过验收标准了，继而可以被客户和用户认可？是不是就可以把这个版本交付使用了呢？

　　--------------------------------------------------------------------------------

　　相信这是很多开发和测试人员都曾经经历过的。无论是开发人员、测试人员，还是项目经理、高层管理人员，都已经为版本的交付日以继夜的加班工作，可不能在交付的时刻功亏一篑。打击心情不说，加班加点不说，而且，谁该来为可能的返工和无休无止的变更买单呢。

　　所以，软件版本在发布时需要有一个判定的标准——没有预先定义的判定标准，就无法去判断版本是否已经达到了客户的要求。不进行判断，或者是错误的判断，都很有可能会造成该项目资源安排的不合理，甚至造成资源的浪费，那么不管是精神上还是体力上，甚至进度上、成本上，都会给项目团队带来不小的打击。

　　CMMI四级的一个要求是量化的管理项目（详见量化项目管理QPM中文版）。映射到缺陷预测活动中，也就是量化的管理缺陷。量化的退出标准就是将类似“这个版本是否能够通过”这样的问题，形象地转变为“已经测出的bug数是否已经足够多，遗留的bug是否已经少到不会影响软件的交付”等等这样的表述。这样，无论是理解上还是判断上都更加容易，版本发布标准也就变得不难理解了。

　　在决定发布版本之前，需要去统计这样几件事：我们已经发现了多少个bug；用量化的方法进行管理时，我们还有多少个bug没有发现；我们统计到的未发现的bug数是否能达到客户的要求；如果无法满足客户的要求，那我们至少还需要发现多少个bug。当这一系列问题都解决了以后，开发、测试人员是终于可以“收”工拿项目奖，还是需要返工加班、继续努力，也就一目了然了。

　　知道了要做什么，接下来要考虑的就是“怎么做”。出于这样的原因，方正国际软件有限公司（以下简称方正国际）几年来一直都在内部实施着利用统计学的原理对软件缺陷进行管理和监控。用统计学的方法监控和预测缺陷的发展情况，从而对发现的缺陷进行管理，确定还未发现的缺陷情况、为了按时交付每一个阶段应当发现的缺陷情况，以此相应调整测试工作的时间和进度。

　　这就是方正国际近两年来一直在内部实施的基于Gompertz模型的缺陷预测与管理，以及在此基础上开发的缺陷预测与管理的工具。在已经采集到的多个项目数据的基础上，现在该工具已经在公司内部使用。应用这个工具，让测试人员在测试初期就对自己大致的工作量有了比较准确的估计，并对测试的每个阶段发现的bug实施分析和监控；根据预实对照的目标达成情况来调整开发、测试的进度；而且在最终交付时，给客户一个高质量的、可靠的工作产品。简单用个例子来说明吧。在项目A还未进入但即将进入测试阶段时，测试经理就会根据历史的情况、经验等方法，估计出进入测试阶段后的第一周，大概可以发现多少件缺陷；同样，再估计出版本交付时可能出现的缺陷数目，以及版本交付后会出现的缺陷的数目。利用这三个数据的信息，就大致可以得到：要达到预定的目标，在进入测试阶段后，每周、甚至每天大概需要发现多少缺陷。以此为依据，测试经理就可以对团队中的测试人员的任务进行分配、对工作进行评价。当然，这仅仅是Gompertz模型使用的场景之一。

　　统计学是很强大的，统计学知识的应用也是很广泛的。那么，在缺陷预测中的统计学原理，或者说是理论依据是什么呢？基于Gompertz模型的缺陷预测工具到底是怎样对测试活动和质量进行监控的呢？接下来，我们会逐步与大家分享。

　　未完待续......

趋势预测、基于时间信息的预测相关基础知识

　　在展开Gompertz模型趋势预测的说明前，首先给关注统计学知识在软件行业应用的网友介绍趋势预测的基础知识。

　　如何理解预测技术呢？简单来说，预测（prediction）是根据事物发展的历史资料及当前情况，运用一定的理论和方法，对未来趋势做出的一种科学推测。再简单点，就像传说中或是童话里的占卜师一样，当你想知道将来的事情时，你需要告诉占卜师你的出生情况，他就能将你的一生预测出来。不同的是，他只能告诉你，你的一生是顺利或是不顺，或再详细点告诉你可能在哪段时间会发生不寻常的事情；而我们所说的预测技术却可以详细到周，甚至详细到天。当然，这里还有个本质的区别，那就是我们这里说的预测是有科学基础的，而占卜师的预测只是常常出现在童话里或者传说中罢了。

　　预测技术的应用主要针对未来的趋势，即是经常讲的趋势预测？这里我们也来个“顾名思义”。“趋势”一词在词典里的解释是“事物发展的动向”，也就是会呈现出某种规律。简单点，某一事物未来是好是坏，是多是少，是升是降，或者先好后坏，先多后少，先升后降等等，也就是对未来进行预测。再用上面的例子来说明，小李急切地想知道自己的未来，并求助于占卜师，而占卜师则预测到他在40岁时会有场灾祸，那么恐怕小李紧接着要问的就是“我该怎样做才能化解我的灾祸”。趋势预测就是要解决类似的问题。预测并不是最终目的，而是一种手段，当预测到的趋势不符合规定的标准时，就应当及时采取措施来进行调整或缓解，这也是趋势预测的目标之一，通过分析预测的结果，揭发它的发展趋势，从而使得人们能够尽早地发现问题，或得到一个科学论断和标准。现在从童话回到现实中来。在软件领域，缺陷的趋势预测是预测技术应用较为广泛的领域之一，它是利用统计的手段来预测产品或解决方案中的遗留缺陷、测试阶段的单位时间内应当查出的缺陷等，因此对软件质量的提高和测试阶段的管理起着重要作用。

　　在软件领域中，一条重要的原则就是“do it right the first time”。这条原则告诉软件行业的工作人员：应当在第一次就将事情做对。然而实际中的情况是，软件开发完成后总还是存在缺陷，所以才需要测试，才需要品质保证；考虑业务的复杂性、开发工具的更新、需求的不稳定性、开发人员的能力经验欠缺等因素，几乎不能在第一次就将事情完全的做对，取而代之的是不断的验证、测试、修改再确认，才能最终确保软件产品或服务的正确性。然而有一件事可以确定，某个软件系统中的缺陷数目应当是一定的，随着软件系统生命周期的推进，发现的缺陷数应当由少到多，再从多到少并趋近于零。那么，如果无法做到“第一次将事情做对”，也要“尽早将事情做对”，在缺陷可能带来巨大的风险之前，就将它“扼杀在摇篮里”。如果没有预测，不知道未来趋势，也就无法判断当前处于怎样的状态下，更无法知道，在当前阶段，是不是已经有缺陷遗留到了下一阶段。这一点其实很容易理解，本来需要在2周内每天完成30项任务，但第一周只完成了10项，那接下来的一周内就需要加班加点完成剩下的50项任务；如果未能完成，那就可能导致无法交付任务，带来足以让你后悔的结果。

成长曲线

　　终于要介绍到预测方法啦。有了前面两篇文章的基础，大家应该都对预测有了认识。还是那句话，知道了要做什么，接下来就该想要“怎么做”。明白了预测的重要性，那就该去想想，怎么去预测？不过别心急，我们一步一步来，这篇文章会介绍预测工具的基础知识——成长曲线。

　　什么是成长曲线？成长曲线就是描绘观测样本从初始阶段不断发展壮大所经历的全部过程的曲线。在软件领域的成长曲线的过程中，要观测的样本值会经历萌芽、发展、稳定等阶段。成长曲线在很多方面都有应用，比如在报纸上、经济类刊物上常常能看到的经济成长曲线、品牌成长曲线；再比如细心的妈妈都会把宝宝出生后的成长情况记录下来，绘成儿童成长曲线等等。

　　在软件领域中同样有成长曲线，软件领域中的成长曲线反映了软件系统中的要观测的某个属性随着各种因素（如时间、成本等）变化发展的情况。成长曲线可以拟合事物发展的趋势，曲线拟合（Curve fitting）就是用连续曲线近似地刻画或比拟平面上离散的点表示的坐标之间的函数关系的一种数据处理方法。在数值分析中，曲线拟合就是用解析表达式逼近离散数据，即离散数据的公式化，就是选择适当的曲线类型来拟合观测数据，并用拟合的曲线方程分析两变量间的关系。

　　接着回到软件领域中的成长曲线上。对于一个系统来说，进入开发阶段后，开发人员每天都要完成一定量的代码行，而代码行的总数在项目计划阶段就应当是估算好的，那么，开发人员应当按照怎样的速度完成这些代码；已经完成了一部分代码后，能否判断出这样的速度是否合理、能否按期完成任务；前期完成过多代码可能会造成后期工作量太小，而前期完成太少代码又可能会带来后期的工作繁重。也许这时，你就会迫切需要一个工具来对开发人员的工作进行监控。进入测试阶段也是一样。所以这里提到的软件领域中的成长曲线的预测，就是针对软件的开发阶段和测试阶段的。再以测试为例，成长曲线能够反映缺陷从最初的测试出的缺陷较少，到中期不断发展增多，再到最终测出的缺陷数稳定不变的全部过程。成长曲线应当是连续的，它能够表示一段时间内事物持续发展的情况，能够表示事物在一个持续的时间段内发展的全过程。

　　成长曲线有很多种形式。常见的线性曲线也可以看作是成长曲线的一种，只是在现实中，线性曲线的使用不如非线性曲线广泛。下面将几种常见的成长曲线归纳介绍，希望对大家的理解有所帮助。

　　1、Rayleigh模型

　　Rayleigh模型是Weibull分布的一种特殊形式，是一种常用的模型。Weibull分布最重要的一个特征是它的概率密度函数的尾部逐渐逼近0，但永远达不到0，在许多工程领域都使用了很多年。Rayleigh模型既可以对软件开发全生命周期进行预测，也可以仅对测试阶段的缺陷分布进行预测，得到所期望的时间间隔t与所发现缺陷的关系。对于成熟的组织，当项目周期、软件规模和缺陷密度已经确定时，就可以得到确定的缺陷分布曲线，并可以据此控制项目过程的缺陷率。如果项目进行中实际的缺陷值与预估的缺陷值有较大差别时，说明中间出现问题，需要加以控制。

　　1）Rayleigh模型的函数形式

　　Rayleigh模型的累积分布函数（CDF）：F（t）=K*（1-exp^（-（t/c）^2））；

　　Rayleigh模型的概率密度函数（PDF）：f（t）=2*K*t/（c^2）*（ exp^（-（t/c）^2））。

　　上面两个函数中，t是时间自变量，c是一个常量（c=2^（1/2）tm，tm是f（t）到达峰值对应的时间），K是曲线与坐标形成的面积（总缺陷数），也是我们要估计的参数。多年的预测经验得到缺陷在tm时间的比率（F（tm）/K）约等于0.4，即在f（t）到达最大值时，已出现的缺陷大约占总缺陷的40%。按照这个推导，在某一时间就可以估算出总的缺陷数以及具体的Rayleigh分布参数，从而将缺陷的计算过程简化。

　　2）Rayleigh函数对应的图

图1 Rayleigh模型的CDF图

图2 Rayleigh模型的PDF图

　　由图1——CDF图可以看出，累积密度最终趋近一个最大值（K）；由图2——PDF图可以看出，缺陷随时间逐渐降低最终趋向于0。

）使用Rayleigh曲线来建模软件开发质量涉及两个假设：

　　在开发过程中观察到的缺陷率与应用中的缺陷率成正比关系。对应于图1来说，也就是如果开发过程中观测到的缺陷率越高，CDF中图的幅度越高，K值越大；

　　给定同样的错误植入率，假如更多的缺陷被发现并更早将其移出，那么在后期阶段遗留的缺陷就更少，应用领域的质量就更好。对应于图2来说，曲线与X、Y轴围成区域的面积是一定的（总的缺陷数是确定的），如果在前期移除较多缺陷，即曲线的峰值点前移，那么后期曲线的面积就会小，代表后期遗留的缺陷数减少。

　　4）使用场景：收集数据应当越早越好；且需要持续的追踪缺陷数。

　　5）优势：随时间信息的缺陷密度可预测，因此在测试阶段使得找到并验证缺陷的估计成为可能。

　　6）Rayleigh模型没有考虑到变化调整的机制，所以可能会影响到缺陷的预测。

　　2、指数模型

　　指数模型是针对测试阶段，尤其是验收类测试阶段的缺陷分布的模型，其基本原理是在这个阶段出现的缺陷（或者失效模式，我们这里讨论的是缺陷）是整个产品可靠性的良好指证。它是Weibull系列的另一个特例。指数模型是许多其他可靠性增长模型的基础。指数模型可分为故障/失效计数模型（fault/failure count model）和失效间隔时间模型（time between failures model）。基本的指数模型的累积缺陷分布函数（CDF）为y=K*a*b^t，修正指数模型在基本指数模型曲线函数上加一个常数因子。

　　1）指数模型的函数形式

　　指数模型的累积缺陷分布函数（CDF）：F（t）=K*（1-exp（-λ*t））；

　　指数模型的缺陷概率密度函数（PDF）：f（t）=K*（λ*exp（-λ*t））。

　　其中，t是时间，K是总缺陷数，λ与K是需要估计的两个参数。

　　2）指数模型对应的函数图

图3 指数模型的CDF图

图4 指数模型的PDF图

2）指数模型的关键假设：测试工作量在测试阶段中是均匀的。

　　3）使用：指数模型预测缺陷时是基于正式的测试阶段的数据的，因此它主要适用于这些阶段，最好在开发过程后期——例如最后的测试阶段。但在交付用户使用后，用户发现的缺陷模型，与交付用户之前的模型往往有很大差别，这是由于交付客户后影响客户的测试的不确定因素更多。

　　4）优势：最简单最有用的模型之一，易于使用和实现。

　　5）缺陷：假设测试的工作量在整个测试阶段是均匀的。

　　3、NHPP模型（非齐次泊松过程模型）

　　NHPP模型是对在给定间隔内观察到的故障数建模，它是指数模型的一个直接应用。

　　1）NHPP模型的函数形式：其中，参数的含义与指数模型相同

　　NHPP模型的累积缺陷分布函数（CDF）：F（t）=K*（1-exp（-λ*t））；

　　NHPP模型的缺陷概率密度函数（PDF）：f（t）=K*λ*c^（-λ*t）。

　　2）NHPP模型对应的函数图：见指数模型

　　3）由于NHPP模型是指数模型的应用，所以NHPP 模型的特征与指数模型的特征相同。

　　4）缺陷：大多数NHPP模型都基于这样的假设：每个缺陷的严重性和被监测到的可能性相同，在排除一个缺陷时不引入另一个新的缺陷，但实际情况并非如此。缺陷之间是存在着关联关系的。

　　4、S型可靠性增长模型

　　S型增长模型是软件领域应用较为广泛的模型之一，下一篇，将会详细进行介绍。

　　未完待续。。。

在上一篇里，已经介绍了如何选择曲线模型，这一篇里，将会介绍怎样预测出该模型下符合实际数据的曲线，选择合适的模型。（模型的拟合算法将单独介绍）

　　给定一组实际数据，要让你预测出今后的一段时间，该数据的发展趋势，很多情况下，你并不能一下子就找到符合这组数据发展趋势的模型。而实际上，又有太多模型可以选择，每一个模型都会得到一个不同的发展趋势。好比买衣服，琳琅满目、各式各样，可是，到底哪一件适合你要出席的场合呢？所以，到底是指数合适，还是Gompertz合适，又或者是Logistic合适呢？

　　这个时候，就迫切的需要一个评判的标准，这种标准称为拟合度。拟合度的评价也有几种方法，本文列出了几种常用的拟合度判断方法，并对这几种方法进行总结、对比。

　　◆ 利用相关系数R2来进行拟合度判断

　　相关系数R2是一种常见的拟合度的判断方法，常用于判断线性曲线的拟合度，然而在许多非线性曲线的拟合度判定过程中使用的依然是判断R2的方法，这个判断标准在实践中也被证明是符合实际的。实际中，R2较大的曲线模型，往往也是拟合较好的模型。

　　● 计算残差平方和Q=∑(y-y*)^2，其中，y代表的是实测值，y*代表的是预测值

　　● 计算相关系数R2=1-Q/∑(y-ya)^2，其中，y代表的是实测值，ya代表的是实测值的平均数

　　● 判断方式：R2越大、越接近1，认为拟合度越好

　　◆ 利用变换的R2来进行拟合度判断——以Gompertz曲线和Logistic曲线为例

　　Gompertz曲线和Logistic曲线的预测过程（无论是三点法还是三和法）首先都需将模型的函数进行变换（对Gompertz模型进行对数变换，对Logistic模型进行倒数变换），然后再运用三和法或者三点法的原理进行计算。所以这里提出一种运用变换的相关系数R2来进行拟合度判断。

　　● Gompertz曲线

　　◇ 分别将实测值和预测值进行对数变换

　　◇ 将对数变换后的实测值记作y，将对数变换后的预测值记作y*

　　◇ 根据相关系数的计算方法，计算变换后的残差平方和Q和相关系数R2

　　● Logistic曲线

　　◇ 分别将实测值和预测值进行求倒数变换

　　◇ 将求倒变换后的实测值记作y，将求倒变换后的预测值记作y*

　　◇ 根据相关系数的计算方法，计算变换后的残差平方和Q和相关系数R2

　　◆ 利用实测数据与拟合数据来进行拟合度判断

　　由于R2是用于判断线性模型的拟合程度的，对于非线性曲线，似乎不具有什么理论上的支持，所以，出现了许多针对非线性曲线进行的拟合度判定。下面的方法是其中的一种。

　　● 同样，计算残差平方和Q=∑(y-y*)^2和∑y^2，其中，y代表的是实测值，y*代表的是预测值

　　● 计算新的拟合度指标RNew=1-(Q/∑y^2)^(1/2)

　　● 判断方式：RNew越接近1，认为拟合度越好

　　◆ 利用余弦函数进行辅助判断

　　从上一种方法中可以看出，在参数个数相同的前提下，拟合值越接近实测值，则认为拟合得越好。由此出现了根据几何意义得到的方法：若把实测值和预测值视为N维空间中的向量，若它们之间的夹角Θ越小，则可以认为拟合得越好。这里，计算角余弦系数FR=cosΘ=∑(yy*)/((∑y^2)^(1/2)* (∑y*^2)^(1/2))。

　　经实验证明，RNew的分辨率和灵敏度都较高，计算简单。实际中，可先用FR初选，再用RNew精选，可能会得到较好的结果。

好像所有带有‘管理’字样的东西都变得不那么具体了。

　　一般这个东西就要对症下药了，所以首先得知道有什么样的风险。在实际的工作中主要遇到过以下的风险类型：

　　1、需求变更，这个是最大的风险，因为最后期限是不变的，需求变了，就意味着更多的工作要在已计划好的日程表中做完。风险可排老大

　　2、人员变动，在一个可以持续2，3个月的项目中，中途可能有人离职

　　3、需求理解问题，由于缺少行业知识，业务背景，有可能对需求的认识不够透彻

　　4、复查工作没做好

　　5、需求覆盖率不高

　　6、测试用例执行没有达到100%

　　7、测试环境和实际环境有偏差

　　8、测试缺陷很难重现，导致无法定位根源从而没有修复

　　针对第一条：估计每个公司都在这上面吃过亏吧。所以才有那么多的软件开发模型。我所经历过的一些比较大的项目，采用的都是增量迭代的开发模式，所以在每一个小的阶段，需求是相对稳定的。但是也有变更的时候，这种时候，我们一般是要求走需求变更流程，根据变更的大小来确定策略：如果变更造成的工作量小于3天/人，作为一个ADHOC项目，如果大于3天/人，就作为另一个新的项目。这个当然要和客户达成一致。

　　针对第2条：最好是每个岗位培养备份的人员

　　3，4，5条其实可以归结为一条，我们尽量在需求分析阶段就把自己所有不明白，不清晰的问题提出来，整理成一个文档，先内部回答，这个内部可以包含开发，然后发给需求方请求答案。测试用例评审会要组织好，在开始之前，要求每个人所设计的用例至少被2个不同级别的人员评审过，然后再评审会上确定最终的问题和解决方案，会后跟踪这些评审会上出现问题的状态。

　　第6条是完全可以避免的。如果时间确实很紧，按优先级别选择最重要的CASE去跑。

　　第7条嘛，一般是在搭建测试环境之前，列出一些需要检查的项，搭好后，让人按这个检查项一项一项的去检验。

　　第8条，还真没什么好办法，如果你有，麻烦告诉我下。我们一般遵循的是只要是出现过的，哪怕一次也是缺陷，都要记录在案的。也可以在交付客户时说明并一同交付。

　　说在最后的，做测试肯定要得到老大的支持和重视，否则风险控制都是空谈啦。尽量每个阶段都要文档化，规范化。

　　做任何事情都有风险，风险管理无非就是消除，消除不了就减少，减少不了就降低。降低到一定程度就不再有威胁，或者短时间没威胁，没威胁就不是风险了。

　　针对测试的各种风险，还是建立一种“防患于未然”或“以预防为主”的管理意识比较靠谱。

　　此文为个人经验，不对之处请指教。

题外话

　　最近有点心浮气躁，在几个群里发过牢骚，有过埋怨，有过稚嫩，有过冲动，也砸了一个键盘，一个人晚上散过心，呵呵倒是让不少朋友见笑了，仔细想想也许是一种蜕变，觉得自己还是很幼稚，不够成熟，总是想留住年轻，不想这么快老掉，所以无时无刻的都在表现自己，仿佛向所有人说，我还小一样，呵呵。

　　难得静下来，整理下思路写下这篇博文实属不易，困境从不缺少，能走出困境的人，必有其过人之处，如果能将困境变为利境的人，必有其独特的见解，或者是人生观，或者是生活观，或者是价值观，总有和人不一样的观念。

　　古人云：达者，一日三省吾身。我不是什么达者，但却能做到三日一省吾身，三日不能醒悟，四日或许就能恍然大悟，四日不能，五日也许就醍醐灌顶了，呵呵。非常感谢侯老师的提醒，也很感谢很多群友，同行的开导，若非如此，也许我还在泥足深陷。

　　原本计划写两篇博文，一为用专业的眼光看待自己的工作，一为我个人的困境，既然现在困境有转变的趋势，不如一起写了下来，作为新人之路系列博文的第五篇博文吧，我相信我的生活和工作都很普通，自然我所遇见的事情，会有很多人也会遇见，这也算是我将自己的一些心得共享吧，别人的始终是别人的，不要试图完全照搬我的心得，只有自己的才是最好的，吸取百家所长，总结出自己的经验，写出自己的心得，那时才是提高了，一味的模仿永远不能超越。

　　正文

　　最近的工作其实挺忙的，工作确实是测试，但是却没有用到测试上的技术，不管是工具，还是用例都没有用到，只是测试，很多人都是如此，测试，只是测试。

　　其实测试不只是测试。

　　大家都知道测试的两个发展方向，一为管理，一为技术，如果你发现你所在的测试工作没有技术的影子，那你是否尝试过从管理的角度来理解呢？

　　昨日将手上的一个项目从头到尾测了一遍，整整8个小时，没有测完，但确实很累，不断的针对同一个功能点的不同可能性，晚上到家心里疲惫不堪，一点点不顺心就大发脾气，把一个外接键盘砸得稀烂还不解气，又做了几个俯卧撑，力气发泄出去了，头脑慢慢冷静了，决定出去散散心，专往人少的地方走，环境安静下来了，心也静了下来，开始试着分析自己这段时间的情况，那是相当糟糕。

　　问题一，为什么如此急躁，怎么能不急躁

　　太过急躁，因为一些事情，我对自己的要求很严格，对自己的职业规划也很严格，有个很明确的目标，最多5年达到什么什么程度，最好3年达到什么程度，仔细想一想其实，真的太急躁了。

　　针对这个问题，我告诉自己，“现在要做的，只是学习和积累，学习什么，学习技术，理论上的知识只能通过自己体会，学是学不来的，并且相对于理论，我的技术已经跟不上理论的成长脚步了，为了让技术和理论平衡，所以应该学习技术，积累工作的经验，工作的每一分每一秒都是一种经验，如何安排工作的空闲时间，如何安排工作，不至于工作量分布不均匀一会强度很大一会强度很小，在和开发人员对Bug进行定位时也可以吸收相关经验，比如，在界面删除一个数据，但是数据库中这条数据还存在，这时就可以根据经验来判断有可能该功能是虚拟删除不是物理删除，可以说每一个BUG都是一份经验，区别只是你看见没有，想到没有。”如此想来，其实我要学的要做得还有很多，远远不是自己所想的没有可以学的了，自己很厉害了，呵呵现在觉得这种想法很幼稚，学无止境啊，何况自己还是个初出茅庐的菜鸟呢。

　　测试行业所需要学习的东西实在太多太多，如何选择学什么，单从工作角度来讲，目前我工作的内容是WEB测试，工作的内容是功能黑盒测试，并且，接触不到数据库，这时，很明确了，我在前面的一篇博文中提及过，要向自动化提高，加之对QTP有一定的了解，但是不够，那么很自然的选择了QTP，不怕大家笑话，我只会QTP，但不会用QTP测试，好了，这是我的一个学习方向了。

　　第一个问题解决了，心也静下来了，对以后至少2，3个月的日子不会再这般迷茫了，为什么是2，3个月？呵呵因为我自信啊，我认为2，3个月我能够学会用QTP测试，当然不是精通。。。。第二个问题来了。

　　第二个问题，工作这么段时间，自己有没有得到提高

　　相信也是大家闲暇时常常想起的，测试到底有木有前途，看看人家开发的工作，都是技术上的，项目完了人家的代码能力实实在在提高了，技术水平实实在在掌握了，再看看自己，这个项目完了，自己了解的业务就都没用了，虽然不是什么都没学到，但是和开发一笔却觉得自己学的太少，因为测试的基础是业务，是需求，一个项目完了也就意味着你了解的业务没用了，你了解的需求没用了，即使你说再做相同的业务能够容易上手，但假若业务跨度很大呢，这个项目是做管理的，下个项目是做商务的，对比看看现下的招聘内容，熟悉各种自动化工具，熟悉各种数据库，熟悉各种语言，各种各样的优先考虑，再来看看自己花了很多时间很多心力做完了一个项目，即使做得很好，你也会觉得自己还是没有多大的提高，还是不能去应聘薪资高点的工作，你们有这种感觉吗？

你是否对它有一种责任感

　它，指开发人员对开发出的产品；它是测试人员所面对的测试产品。你是否对它有一种责任感，是指开发人员是否对它开发出来的产品有责任感，为它骄傲，为它而开心；你是否对它有一种责任感，是指测试人员是否对它测试人产品有责任感，是指测试人员更多的站在用户角度考虑问题，尽量减少要发布产品中的缺陷，达到用户满意的程度。

　　如果你（开发或测试）对它有一种责任感，你就会发现，开发和测试之间，本质上是一个合作的过程，我们的目标是一致的，都是为了尽量减少发布产品中的错误，提高用户满意度。你对它有一种责任感 ，我们就无须进行太多太严格的版本控制要求，无须很多的中间环节，我们的产品研发过程将更快捷，质量更好。可是事实上并非如此，我们需要很多的管理环节来约束我 开发和测试过程，因为我们的团队中并不是每个人都对它有一种责任感。并不是每个人对它的责任感目标是一致的。

　　就我们测试人员来讲，作为一个测试人员，一般要经历过一些成长阶段才能做到一个真正对”它”有责任感。

　　一、学习需求＋验证的过程

　　刚刚涉入测试，往往踏不下心来，感觉测试是件没完没了的事情，且简单重复，枯燥乏味，没有有激情，没有成就感。这时候，所做的事，往往是学习所测产品的每个功能，弄清每个功能的最终结果是什么？然后尝试验证它，这种测试往往发现的是一些肤浅的表面的问题。

　　二、经历测试和开发是对立的过程

　　到第二阶段，渐渐认识到，测试就是找出产品的缺陷，是证明产品不可用的一种行为。这时候，感觉测试和开发的行为是对立而矛盾的，测试是为了证明产品是有问题的，开发是创造产品的。这实际上是一种误区。这个时候，会发现一些较严重的缺陷。

　　三、学会与开发主动的配合

　　随着经验的积累和对工作的深入认识，会发现，开发和测试的目标是共同的，一致的。都是为了减少产品的错误，为用户提供更加满意的产品。所以，测试人员更多的站在用户的立场（角度）发现问题，帮助开发析和解决问题。

　　四、责任感＋验证

　　经过多个项目的需求、开发、测试、维护以及升级的循环过程，逐渐认识到测试介入越早，风险越小；测试投入的时间上更多的会在需求方面，而不仅仅是测试过程本身。通过和最终用户的多交交流，对用户体验有了新的认识，会油然而生一种责任感（如：在公司五周年的活动中，看到我们的用户对我们的尊敬、感激还有那份热爱。会让我们进一步体验用户在使用产品时的感受，同时，会对我们的提供产品产生一种成就感。对测试的理解也随之成为一种对产品的质量意识、产品意识，有时候感觉自己精心”待弄”的是自己的孩子。

　　测试和开发工作实际上是一种荣誉与共的关系，取得的成绩和造成的失误，共荣誉和责任是平等的。与此同时，在遇到问题时，就会尽可能的帮助研发尽快定们bug原因，尽快把问题解决掉。

　　上面几点是我就测试的一点认识，我想开发的应该也是一样，也会经历这样一系列过程。

　　对它有一种责任感，让我们的产品更加实用，易用。

　　对它有一种责任感，看大一点，就是要做一个有责任心的人，无论对谁（爱人，父母，孩子，朋友），对事，对物，对社会都有一份责任心。