处理异常值

异常值的定义是与均值的偏差超过两倍标准，但是在脏数据中，异常值的情况不止这一种：

1）比如一列数据你打开看全部是数字，当你把它当数值型处理，它会报错；那就得仔细查找原因，遇到比较多的情况是一列数字中夹杂了几个奇怪的字符串或者符号等元素，如果几万条数据中只有一两个这种字符，即使认真从前到后仔细查看也很难发现还浪费大量时间，效率极低。

还有一种情况比较常见，就是看起来是数字，实际上都是字符串的形式，但是以表格查看的时候是看不到字符串的引号；这两种情况可以通过查看特征类型来提前发现，在python中用type()或者dtypes()函数，两者使用对象有差别，可自行了解；

2）几种常用异常值检测方法：

3σ探测方法

3σ探测方法的思想其实就是来源于切比雪夫不等式。

对于任意ε>0，有：

当时，如果总体为一般总体的时候，统计数据与平均值的离散程度可以由其标准差反映，因此有：

一般所有数据中，至少有3/4（或75%）的数据位于平均2个标准差范围内。

所有数据中，至少有8/9（或88.9%）的数据位于平均数3个标准差范围内。

所有数据中，至少有24/25（或96%)的数据位于平均数5个标准差范围内。

所以如果我们一般是把超过三个离散值的数据称之为异常值。这个方法在实际应用中很方便的使用，但是他只有在单个属性的情况下才适用。

z-score

Z-score是一维或低维特征空中的参数异常检测方法。该技术假定数据是高斯分，异常值是分布尾部的数据点，因此远离数据的平均值。距离的远近取决于使用公式计算的归一化数点z i的设定阈值Zthr：

其中xi是一个数据点，μ是所有点xi的平均值，δ是所有点xi的标准偏。

然后经过标准化处理后，异常值也进行标准化处理，其绝对值大于Zthr：

Zthr值一般设置为2.5、3.0和3.5。该技术是使用KNIME工作流中的行过滤器节点实现的。

这种异常值处理需要结合最终需求来决定怎么处理，常见的是不处理或者按缺失值的方法处理，但是在实际场景中，异常值有时候会有非常突出的表现，比如在现金贷业务中，异常值中的坏账率远高于整体坏账水平或其他区间坏账水平，这时候异常值就得保留并作为决策阈值的参考值。

IQR

观察箱型图，或者通过IQR（InterQuartile Range）计算可以得到数据分布的第一和第四分位数，异常值是位于四分位数范围之外的数据点。

这个方法真的很简单，因为只需要给数据排个序就行了，显然过于笼统，但在实际场景中，观察箱型图仍然是一个很好的探索数据分布的方法。

毕竟，所有复杂的探索，都是从最开始简单的探索一步步得来的嘛！

回答这个问题，先解释一下金工为啥就出现了。其实很简单，就是金融要跟计算机联系在一起，但是只做金融的不懂计算机，只学计算机的不懂金融，怎么办呢？来一个金融工程吧，所以金融工程是一个综合性学科。类似于商业数据分析，商业数据分析结合的是统计、计算机和商科；金融工程集合的是高数类、计算机和金融。所以你从这个专业包含的元素就可以看出来金融工程和金融的课程设计肯定有很大的区别。

我先说一下金融专业的课程设置，你也许觉得百度就可以啦，还用的到你？哈，你用得到。我想说的不是百度随便找找的那些，而是很真实的故事。不同的学校开设的金融课程不！一！样！而且有些学校说开设的是金融，课程设计的根本就是经济！（虽然金融肯定要学经济，但是经济课不应该为主；就像CFA里面，经济只是一个模块）尤其对于一些排名不高的金融学校（我说是金融专业的排名），你别看它是985和211，你就感觉它高大上了，其实没有，课程设计烂成狗，而且对于一些高级计量的课，根本没有能讲的老师。

我有个去厦大交流的朋友说，他们用的都是国外教材，而且本科讲到了中级宏观经济学，跟她自己的985和211大学完全不是一个级别，现在她考研了，然后说到感觉有好多需要自己补的，因为她考上的那个大学也默认本科教到中级宏观。所以，我要说，你如果选择金融专业，真的去一个以金融为强项的学校，不然以后你有的是需要自学的。

然后补一下都能查到的课程设置：

保险学、财政学、国际金融、国际贸易、证券投资学、货币银行学、计量经济学、投资银行学、宏观经济学、统计学、中央银行学、政治经济学、微观经济学、会计学、金融法、线性代数、概率论与数理统计、微积分、投资风险管理等

因为我自己是申请美国和加拿大量化金融和商业数据分析的，所以也从国外大学的网站上copy 了他们的课程设置。下面是普林斯顿大学设置的金融学课程（普林斯顿大学，金融专业排名，全美第一）【如果你看的排名跟我有出入，别喷我，谁不知道排名是玄学，大家心里有个数就得了】

项目的核心课程有5门：

Asset Pricing I: Pricing Models and Derivatives（资产定价I：定价模型与衍生品）

Statistical Analysis of Financial Data（金融数据统计分析）

Corporate Finance and Financial Accounting（公司金融与财务会计）

Asset Pricing II, Stochastic Calculus and Advanced Derivatives（资产定价II：随机微积分与高级衍生品）

Financial Econometrics（金融计量经济学）。

项目还有3个分支：【这个意思大概就是学生需要从这几个角度，在选一些选修】

Financial Engineering and Risk Management（金融工程与风险管理）

Quantitative Asset Management and Macroeconomic Forecasting（定量资产管理与宏观经济预测）

Data Science &Financial Technologies（数据科学与金融技术）。

然后说一下金融工程。金融工程除了金融基础还要能够建立数学模型和编程，但其实根据不同学校的水平不同和培养学生的方向不同（反正我是觉得跟学校的出身有关，工科类出身设金工，基本上就是偏向金融码农；如果是商科类开金融，基本就是偏向金融产品设计）设置的金工的课也有区别。

因为金工出来不仅可以变成还可以做金融产品设计，就是跟那种程序员与产品经理的感觉差不多。所以，有些学校可能侧重的是金融+数学模型，培养出来的就是以产品设计为主；有些学校可能侧重的是代码编程，培养出来的就是金融界的码农。自己到底对哪个方向感兴趣自己心里要有个数。

我这里给大家补充一下纽约大学的金融工程课程设置（金融工程全美排名第六）【如果你看的排名跟我有出入，别喷我，谁不知道排名是玄学，大家心里有个数就得了】

核心课(15学分) 

Financial Accounting【金融会计】

Economic Foundations in Finance【金融经济基础】

Quantitative Methods in Finance【金融量化方法】

Corporate Finance【公司金融】

Financial Risk Management and Asset Pricing【金融风险管理与资产定价】

选修课(6学分) 

Money, Banking and Financial Markets【货币、银行和金融市场】

Investment Banking and Brokerage【投资银行和经纪业务】

Applied Derivative Contracts【应用衍生合约】

Derivatives Algorithms【衍生品算法】

Asset-Backed Securities and Securitization【资产支持证券和证券化】

Basel 3 &Banking Assets Management【巴塞尔协议3和银行资产管理】

Special Topics in Financial Engineering【金融工程专题】

Topics in Finance and Financial Markets I 【金融和金融市场专题I】

Topics in Risk Finance I 【金融风险专题I】

Topics in Financial and Risk Engineering I 【金融与风险工程专题I】

Topics in Financial and Risk Engineering 2【金融与风险工程专题2】

总结一下，现在国内的金工，好像，emm，因为貌似还是以研究为导向，我就不评论了哈，当然现在也有学硕。国外的很多金融，也开始要求学生学python，学量化，但是不深入，核心还是以金融为主；金融工程除了基础的金融，还有大量的数学模型和编程课。

大家如果有什么疑问欢迎评论，平时因为学习R和python，可能回复比较慢，大家见谅。

【一些图片来自网络，如果有侵权，麻烦告知删除】

好的测试用例，在执行的步骤(Step）的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：

1) 密码正确的登录

2) 密码错误的登录

3) 密码输入三次错误，卡被锁定

4) 取少于余额的款项

5) 尝试取大于余额的款项

6) 尝试取等于余额的款项（考虑手续费）

6) 取款额度大于当次的限制

7) 取款额度大于当天的限制

8) 取款次数大于限制次数

等等

不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下（此处只列出了操作的步骤，略去了系统的交互中的反馈结果）：

1) 插入卡->A:输入密码->B:按“确定”键->重复A-B

2) A:选择取款功能->B:填写取款金额->C:点击“确定取款”的按钮->D:取现金->重复A-D

因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢？

2. 单独的测试基础数据准备工作

第一个例子中的输入数据比较简单，但我们同样需要考虑的一个问题是：在测试中究竟我们输入什么样的具体数据呢？什么是”正确的密码“？什么又是”大于余额的款项“呢？

对

于大的应用系统，数据之间的关系和准备过程都会很复杂，甚至也有其他外部系统导入、传输或计算出的数据。一个比较好的做法是，将这些测试数据提前准备好，

在每个阶段性测试前导入到系统中。一个比较典型的例子，假设要求你单独去测试几张复杂的财务报表，用其他的模块和外部系统，自己逐一的去创造数据，那会非

常耗时耗力。这时，基础数据的准备就显得尤为重要，以此才能保证测试工作是高效的、测试结果是精确的。

如果有可能，复杂的测试基础数据最好是提前准备好的，类似这里例子中简单的

一个帐号为1234567890，密码为66666的有效银行卡，里面有人民币1000元正，等等。将这些内容预先准备好（可以用自动化工具来准备，或导

出已有的数据为一个SQL的脚本），写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。

3. 测试用例的前置条件和后置条件

除

了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。比如准备一个初始设置条件下的IE

浏览器和已安装过老版本该软件的XP系统。这些可重用的准入条件，可以考虑不作为特定用例的Step，而是把它提取出来，作为Setup

Section或叫Pre-Condition。

对于后置条件或Post-

condition，往往我们用它来做一些处理或恢复，比如在上面的取款例子中，如果我们要用相同的帐号重复测试，在正好取完所有金额，余额为零的情况

下，可以通过一些步骤或数据库脚本重置帐号余额。同样，您为某个用例设置浏览器禁用了Cookie，执行完该用例后，是不是也是需要回复到默认设置的状态

呢？

集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。

顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。

4. 常用业务操作(Knowledge Base)

对于一个大型的应用，比如银行系统，开发和测试工作是长期的，持续的一个过程，这样的系统很适合引入自动化测试。它业务逻辑复杂，测试技术性要求高，往往使用了不同厂商的工具和多种脚本语言（如Shell，Python等），也存在了很多可用的遗留脚本。

这些完成一些预定业务操作的脚本单元，是可以直接借用的。为了在公司和产品层面，管理好这些可复用的资源，一种好的方式是给它们标上号，如KB_PRJ01_Module02_XXX，集中管理起来，以后的用例中只要调用即可。

举

例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试帐号向外汇款，取得响应信息，并保存结果，这可能是个复杂而底层的处理过程，对一般员工是不

需要，也没有权限去深入掌握的。这时，将他们包装成一个个Shell脚本或小工具，做好使用说明和统一建档，在以后的项目测试中，只要调用就可以了。如

此，可以大大提高各个有相关接口的模块的自动化测试工作效率。

根据以往工作中常见的一些问题，对于如何写好测试用例（不仅针对自动化测试），做以下做几点补充：

推荐

不推荐

将用例的内容描述清楚，强调怎么操作，验证什么，然后期待的结果是什么。

Copy需求和设计文档中的内容；描述成：什么条件下，逻辑会是怎样。这样对测试用例的阅读和执行人员，不具有可操作性。

期待的结果要写具体，如：系统反应是什么；结果数字是多少；用户被带到什么页面；显示什么成功信息；后台或数据库中该记录的修改后结果是怎么样的。

描述成：”验证系统返回正确结果“；”页面元素显示跟SPEC一致“；”操作成功“等 比较抽象的说法。

业务逻辑性较强的应用软件，做到以业务流为主线，来组织用例。

以页面形式组织用例。

以Module、Function、测试类型、基本业务流、备选业务流的树状结构形式，分层次组织用例；使用用例管理工具。

Word格式的扁平组织结构，不利于管理和阅读。

用一个属性字段，建立用例和Spec等文档的某个章节间的映射。

无法和需求对应，以后难以计算 用例覆盖率，测试执行覆盖率。

每个Module、Function、特定业务的一组测试用例，之间做到独立、没有耦合。

用例之间有依赖，无法做到：挑选30%的用例做回归测试。

在时间和成本允许的情况下，尽量做到：用例粒度为“一种不同的操作，得到不同的结果，就单独写一个用例“。

在用例中的操作步骤中，甚至期待结果中，仍然存在条件分支。

对于复杂的业务操作过程，如”一次顺序的表单签核过程“和”一次完整的信贷手续“，单独增加一些贯穿整个业务流的大型测试用例。

对于一个长业务操作，只存在比较零散的细节用例。

将用例分优先等级，便于在回归测试时挑选核心业务或用户操作密集的用例。

用例 没有优先级和重要程度的定义。