Hyphy，不亚于Paml的选择压力分析的优秀软件，使用指北

Posted 2023-05-16

参考技术A

近几年来，Hyphy的使用人数越来越来多，虽然不及paml，但这款软件的一些优秀特性使得它值得受到使用和关注。
首先相比paml，hyphy有以下几大优点：

接下来介绍的一系列东西，实际上是对Hyphy官方网站的一系列教程的总结，很多东西官网都写得很清楚，官网地址为 https://www.hyphy.org/ 。

如果你不想看长篇大论，直接跳到最后的总结部分，那里有最简练的总结

关于Hyphy的不同版本 ,hyphy的网页版即是datamonkey，并且还有GUI版本，这里介绍的主要是命令行版本，并且命令行版本也可以分为交互式运行和一行命令运行，这里不介绍交互式方法的使用。

关于hyphy的安装 ,只需要用conda就可以安装了

关于hyphy的输入文件 ，要求一颗newick格式（只能是此格式）系统发育树以及相对应的fasta序列比对文件（可以是FASTA, phylip, 等等），标注foreground branch，即前景支的方法和paml略微不同，即在newick文件中在分支名和支长（如果有的话）之间加上Foreground来标注，或者你可以去hyphy官网的phylotree来在线标注，地址为 http://phylotree.hyphy.org/ 。

关于多线程支持方面 ，2.4.0版本当中，软件中的命令 hyphy 和 HYPHYMPI 已经等同，都是调用多线程，在这个版本之前， hyphy 调用的是单核，而 HYPHYMPI 则对应的是多线程版本命令。

关于具体使用方法 ，hyphy的使用非常简单，以2.2.0版本为例，如果你要使用多线程命令，则如下有两种方法，分别对应位点模型slac以及指定了前景支的支位点模型absrel,它们都需要openmp支持

不同的模型，只需要改相应的模型名称就可以调用了(替换上面命令的slac或者absrel)，用法非常简单,如果不特别用branches指定Foreground，那么则会默认对整个系统发育应用模型。

关于输出结果及结果可视化 ，Hyphy运行的时候，默认打印到屏幕上的结果是以markdown格式输出的，这个结果还是很直观的，而保存到本地文件的结果是以json格式输出的，并不是很直观( 但json格式可以很方便的用python的json模块提取各种信息，例如pvalue和正选择位点，在多个任务批量操作的时候，非常的方便，这种保存的格式非常具有通用性，其实是件好事 )，默认是输出到和多序列比对文件相同的文件夹，可以用 --output 来改变输出位置，可以去官网 http://vision.hyphy.org/ 来可视化输出结果，具体的格式介绍，详见 https://www.hyphy.org/resources/json-fields.pdf 。

关于Hyphy的各种模型，基本上都可以分为不指定foreground和指定foreground运行的两种方式，前者对应的是检测 pervasive (across the whole phylogeny) positive or purifying selection ，即整个系统发育中的普遍的正选择/纯化选择，而后者对应的是检测 episodic (at a subset of branches) positive or purifying selection ，即检测一部分branches的独立正选择/纯化选择。

①FEL 固定效应似然法(FEL, Fixed Effects Likelihood)
使用最大似然(ML)方法来推断每个位点上的非同义(dN)和同义(dS)替换率，用于给定的编码比对和相应的系统发育。该方法假设在整个系统发育过程中，每个位点的选择压力是恒定的。 注意，FEL适合小到中型数据

②SLAC (Single-Likelihood Ancestor Counting)
对于给定的编码比对和相应的系统发育使用最大似然(ML)和计数方法的结合来推断每个位点上的非同义(dN)和同义(dS)替换率。像FEL一样，该方法假设在整个系统发育过程中，每个位点的选择压力是恒定的。 SLAC和FEL精准度相似，但适合更大的数据，并且不适合高度分歧的序列

③⭐FUBAR(Fast, Unconstrained Bayesian AppRoximation)⭐
使用贝叶斯方法来推断给定编码比对和相应系统发育的每个位点上的非同义(dN)和同义(dS)替换率。该方法假设在整个系统发育过程中，每个位点的选择压力是恒定的。 FUBAR适用于中到大数据集，预计在检测位点的普遍选择方面比FEL更有效。FUBAR是推断pervasive selection的首选方法。

MEME(Mixed Effects Model of Evolution)
MEME(混合效应进化模型)采用混合效应最大似然方法来检验个别位点是否受到episodic positive或多样化选择的影响的假设。换句话说，MEME的目的是检测在一定比例的分支下正选择下进化的位点。
对于每个位点，MEME推测两种ω值，以及在给定的分支下，以此ω进化的概率。为了推断ω，MEME会推断α(dS) 和两个不同的β(dN),β−和β+。在空模型和备择模型中，MEME强制β−≤α。因此β+是空模型和备择模型不同的关键：在空模型中，β+被限制为≤α，但在备择模型中不受限制。最终，当β+>α时，位点被推断为正选择，并使用似然比检验显示显著。

FADE(FUBAR Aproach to Directional Evolution)
是一种基于FUBAR引入的贝叶斯框架(Bayesian framework)的方法，用来测试蛋白质比对中的位点是否受定向选择的影响。具体地说，FADE将系统地测试，对于比对中的每个位点，与背景分支相比，一组指定的前景分支是否显示对特定氨基酸的替代偏向。该偏差参数的高值表明该位点对特定氨基酸的取代作用大大超过预期。使用贝叶斯因子(BF)评估FADE的统计显著性，其中BF>=100提供了强有力的证据，表明该位点正在定向选择下进化。
重要的是，与HyPhy中的大多数方法不同，FADE不使用可逆的马尔可夫模型，因为它的目标是检测定向选择。因此， FADE分析需要一个有根的系统发育。在使用FADE进行分析之前，可以使用基于浏览器的交互工具“Phylotree.js”来帮助建立树的根。

aBSREL (adaptive Branch-Site Random Effects Likelihood)
是常见的“Branch-Site”类模型的改进版本。aBSREL既允许分支的先验指定（即指定foreground branches)来测试选择，也可以以探索性的方式测试每个谱系以进行选择( p-value将自动进行BH校正，为什么叫探索性的方法呢，因为你可以先不指定foreground，来看看哪个支的pvalue更低，然后来针对那一支进行进一步的选择压力分析 ）。请注意，探索性的方法将牺牲功效。 ⭐aBSREL是在各个分支检测正选择的首选方法⭐，需要注意一点的是，aBSREL是多次独立对指定的每一支进行检验的，也就是说，你指定了许多的branches，实质上和多次指定不同一个branch来多次运行，效果是一样的，而并非将这些branches视为一个整体去做检测

BUSTED(Branch-Site Unrestricted Statistical Test for Episodic Diversification)
通过测试一个基因是否在至少一个分支的至少一个位点上经历了正选择，BUSTED(分支位点无限制统计检验)提供了一个全基因(非位点特异性)正选择的测试。当运行BUSTED时，用户可以指定一组前景支来测试正选择(其余分支被指定为“背景”)，或者用户可以测试整个系统发生的正选择。在后一种情况下，整个树被有效地视为前景，正选择的检验考虑整个系统发育。这种方法对于相对较小的数据集(少于10个分类单元)特别有用，在这些数据集中，其他方法可能没有足够的功效来检测选择。 这种方法不适用于确定有正选择的特定位点。
对于每个系统发育分区（前景和背景分支位点），BUSTED拟合了一个具有三个速率类的密码子模型，约束为ω1≤ω2≤1≤ω3。与其他方法一样，BUSTED同时估计每个分区属于每个ω类的位点的比例。这种模型作为选择检验中的替代模型，被称为无约束模型。然后，BUSTED通过比较这个模型与前景分支上ω3=1（即不允许正选择）的空模型的拟合度来测试正选择。这个零模型也被称为约束模型。如果零假设被拒绝，那么就有证据表明，至少有一个位点在前景枝上至少有一部分时间经历了正选择。重要的是，一个显著的结果并不意味着该基因是在整个前景的正选择下进化的。

RELAX
RELAX是一种假设检验框架，它检测自然选择的强度是否沿着一组指定的测试分支被放松或加强。因此，RELAX不是明确检测正选择的合适方法。相反，RELAX在识别特定基因上自然选择严格程度的趋势和/或变化方面最有用。K>1表示选择强度加强，K<1表示选择压力放松。
RELAX需要一组指定的 "测试 "分支与第二组 "参考 "分支进行比较（注意，不必分配所有的分支，但测试集和参考集各需要一个分支）。RELAX首先对整个系统发育过程拟合一个具有三个ω类的密码子模型（空模型）。然后，RELAX通过引入作为选择强度参数的参数k（其中k≥0）作为推断ω值的指数：ωk来测试放松/强化选择。具体来说，RELAX固定推断的ω值（都是ωk<1,2,3>），并对测试分支推断出一个将比率修改为ωk<1,2,3>的k值（替代模型）。然后，RELAX进行似然比检验，比较替代模型和空模型。

用法来说，以我用的2.2.0版本为例子，（2.4.0直接用hyphy命令即可）

模型上来说：
如果你要检测类似paml中的M8位点模型，最好用FUBAR，如果是小数据，则用FEL，大数据并且分歧度不是很高用SLAC。
如果你要检测某个前景支当中正选择位点，最好用MEME。
如果你要检测单独的某个branch是否存在正选择，最好用aBSREL。
如果你要检测一系列的branches的正选择，即检验你的这个基因，在指定的branches的任意一个位点是否在某段时间经历过正选择，则用BUSTED，BUSTED是不适合检测单独位点的正选择的。
如果你要检测选择压力的放松/加强，用RELAX。
如果你要用蛋白序列来检测氨基酸位点正选择/定向选择，用FADE。

最后再提一下，几乎所有模型(还有一些没常用的模型没有提到)都可以分为指定前景和不指定前景的模式运行，但不是都适合，就像官方说的那样，根据你的目的不同，会有最优选择，当然你也可以把某种模型都跑一遍，比如各种位点模型都走个流程，并且你也可以结合paml的模型，例如，对于检测Pervasive selection的位点模型，你可以结合paml的M8、M2a来分析。对于检测episodic selection的branch-site，你可以结合paml的branch-site modelA和BUSTED/aBSREL来比较分析。

以上的所有文字，都是笔者根据官方以及一些文献当中对于hyphy的使用总结、翻译，如有错误使用之处，还请各位多多指正。

优秀软件测试工程师必备的8个能力！-（附思维导图）

结合自己以往的工作经验，自己梳理出来一些材料，绝对原创，绝对干货。

优秀的软件测试工程师必备的“8个能力”

作为一名软件工程师，需要的能力并不多，但是要成为一名优秀的软件测试工程师，需要的能力就比较多了，自己整理出来8个方面，每个方面都会分成很多细小的方便并进行举例说明。同样的，文章的思维导图放在文末，需要原图直接找我。

文章一共4500字左右，预计阅读时间9分钟

不废话，上干货！

一、业务分析能力

1.分析整体业务流程

不了解整个公司的业务，根本就没办法进行测试

2.分析被测业务数据

了解整个业务里面所需的数据有哪些？哪些是需要用户提供的？哪些是自己提供的？有哪些可以是假数据？有哪些必须是真数据？添加数据的时候可以用哪个库？

明白了整个软件的数据库架构，才能知道哪一个数据是从哪一个表里头带出来的，它的逻辑是什么，有没有连带关系。

3.分析被测系统架构

用什么语言开发的？用的是什么服务器？测试它的话需要用什么样的环境进行测试？整体的测试环境是什么样的？

如果缺少了，需要进行环境搭建，架构搭建。一般去一家新公司之后，架构是搭建好的，了解它即可，熟悉之前的这些老员工们使用什么样的架构去做的。

4.分析被测业务模块

整个软件有哪些模块，比如说首页面、注册页面、登录页面、会员页面、商品详情页面、优惠券页面等等

明白有多少个模块需要测试，每个模块之间的连带关系，进而怎样进行人员分工

5.分析测试所需资源

我需要几台计算机，需要几部手机，手机需要什么样的系统，什么样的型号。

比如测一个网站的性能的时候，电脑的配置达不到测试并发5000人的标准，要么升级电脑的硬件配置，要么多机联合，多机联合时需要几台电脑，都需要提前筹划。

6.分析测试完成目标

我的性能目标是什么样的？我的功能目标是什么样的？我要上线达到的上线标准是什么样的？

性能目标，比如我要达到并发5000人的时候，CPU占用率不能高于70%，内存占用率不能高于60%，响应时间不能超过5秒

功能目标，比如整体的业务流程都跑通，所有的分支流程都没有问题，所有的接口都能够互相调用，整体的UI界面没有问题，兼容性没有问题等

把这些问题都弄清楚，测试的思路会非常的清晰

二、缺陷洞察能力

1.一般缺陷的发现能力

至少你要满足一般缺陷的发现能力，这个是最基本的，如果要连最简单的一般的缺陷都发现不了的话，别说优秀测试工程师了，你说你是测试我都不信

2.隐性问题的发现能力

在软件的测试过程当中有一些缺陷藏的比较深，有的是性能方面的问题，有的是功能方面的问题，它需要有一些设定特定的条件的情况下才会出现这样的问题。

比如说买双鞋必须选择的是什么品牌，必须选择是红颜色，必须选择44号，而且必须选择用特定的支付方式才会出现这样的bug的时候，那么这种就属于特别隐性的bug，对于这样的问题的发现能力一定要比别人更强，要找到一些别人可能发现不了的bug

3.发现连带问题的能力

当发现了一个缺陷之后，能够想到通过这个缺陷可能会引发其他哪个地方出现问题，这就叫做连带的问题。而不是说发现这一个bug之后提了这一个就算完了，一定要有一个察觉，可能其他地方也存在这样的问题。

4.发现问题隐患的能力

有些软件里边可能有一些操作模块，或者是代码写的接口，表面上没有什么问题，但是它是有隐患的，比如说这个接口写的不稳定，当他传的数据有一些问题的时候，可能它最后返回的结果就是报错就是报404或者报乱码。

5.尽早发现问题的能力

如果你只能停留在界面级别的话，那你根本就没有办法达到尽早发现问题的这个能力

你必须要等到前端人员把每个界面都做好了之后才能进入测试，而我能比你早一个月进入测试了，然后我比你结束测试时间快一个月，而你又比我晚一个月，那么咱俩的薪资一下就拉开了

6.发现问题根源的能力

需要知道这个缺陷它到底是由什么原因产生的，是属于什么类型的缺陷，是ui前端人员做的问题，还是后台接口人员做的问题？

不仅要找到这个bug，还要知道这个bug产生的原因，这样的测试人员是非常棒的，而且很是受人尊敬，提bug的方式也就不一样了

三、团队协作能力

1.合理进行人员分工

合理的进行人员分工是提高效率的重要保证

2.协助组员解决问题

比如说测试在赶进度，或者这个软件项目的质量把控是一个团队来把控的，协助组员解决问题就显得尤为关键

3.配合完成测试任务

一个团队里边的人员分工，他们的任务都是不一样的，这就是咱们说的配合。你的东西做完了，要轮到我了，我的性能测完了之后该轮到你了，所以整个的一个流程下来之后，大家应该是各司其职，配合得非常紧密的一个过程

4.配合开发重现缺陷

我给你提bug，你改我的bug，咱们的目的只有一个，就是让这个软件变得更好，所以在这样的情况下，咱们就一定要配合开发

5.督促项目整体进度

既然是一个团队协作的过程，就一定要互相的去督促对方，包括督促开发去改bug，因为开发人员他们有时候工作很忙，他们不知道要先改哪些问题，要后改哪些问题，但是往往有一些缺陷，它影响了测试的这个时间，影响了测试的进度，那么这个时候就需要测试员去督促开发人员，让他尽快的去解决你棘手的问题。这个东西能够提高咱们的测试效率

6.出现问题勇于承担

愿意背锅的最后都成为了领导，不愿意背锅的最后依然是员工

四、专业技术能力

1.掌握测试基础知识

基础知识就是根基，根基打好了，你才能够更有效地往后期发展，也就是为了以后的学习做一个铺垫。如果根基都没打好，功能测试不会，就想直接学性能，那性能是做不好的

2.娴熟运用测试工具

熟悉工具和熟练使用工具完全是两个概念，熟悉工具基本上等同于不会，遇到过很多简历上写会使用什么什么工具，都没有实际能力。比如loadrunner只会一个简单的录制，增强一下脚本，觉得会用了，那知识会用了1/5，其他4/5 都不会。

3.了解工具操作原理

它是怎么样给服务器发送请求的，是用什么样的方式去发送请的，是用什么样的方式去监控的，它的操作原理是什么样的，咱们要把这件事情搞清楚，这样的话能有助于更好的去使用这些东西。包括一些请求的协议，每个协议代表什么意思，它是用来干什么的。

4.自主完成测试任务

一定要能够自己完成一个独立的内容，独立的工作，这件事情领导你交给我好了，放心我能给你搞定，要的是这样的人

5.找出问题出现原因

找出缺陷的时候，不仅要看它的表面，还要看它的本质

6.提供问题解决方案

发现问题不是能力，发现问题并提出解决方案才是真的能力

7.提供完整测试报告

测试报告能够说明你表达的清不清楚？领导能不能看懂？还有就是能不能够把你整个测试的过程给它梳理得非常详细，人家能够通过你的报告，能够了解到整个的项目的情况，而不是只了解一个片面的情况

8.了解相关技术领域

触类旁通

五、逻辑思考能力

1.判断逻辑的正确性

面试官也经常会给测试人去出一些逻辑题，逻辑题能够分析出来你这个人思维有没有？活跃不活跃？还有他的维度，包括他想的问题的全面性，都能够判断得出来。

比如说去买一样商品，它的里边逻辑就会经常会出现很多问题，比如说它的会员的级别，什么样的级别去买什么样的商品，它的价格不一样，什么情况下会给优惠券，什么样的情况下不给优惠券？达到多少钱的情况下才能够使用优惠券？如果说这里边的逻辑出现了问题的话，那么整个的业务不用再测了

2.对可行性逻辑分析

要去测一个网站的逻辑的时候，一定要先思考这一个业务流程可能会涉及到哪些逻辑，这些逻辑哪些是可行的，有些是正向逻辑，有些是逆向逻辑，都要考虑全面，而不是说只是把正向的逻辑测试全面了，逆向逻辑不考虑。其实往往更容易出错的地方就是逆向逻辑

3.思维导图梳理思路

思维导图工具能够起到什么作用，能够让你更有效的进行测试，能够让你的思路更清晰

4.站在客观角度思考

去测试的时候，不要仅仅只是站在测试人员的角度上去对整个网站进行测试，还更多的要站在用户的角度，要替用户考虑

六、问题解决能力

1.技术上的问题

把自己的个人能力提升起来，多跟别人虚心请教，多去自己想办法解决问题

2.工作中的问题

在任何的企业里边去工作，肯定会遇到一些工作当中的一些不愉快的事情，而不是什么事情都会让你很顺心。所以要去处理工作上的一些不顺心的事情，不要把它带到你的工作上，或者是你的生活上，尽可能的去跟别人沟通，去解决这个工作上遇到的麻烦

3.同事间的问题

在工作当中可能会涉及到跟开发人员的沟通，跟产品人员的沟通，跟ui人员的沟通，跟这三方的人员去沟通的时候，就要用不同的沟通方式

4.领导层的问题

如果你觉得你的领导不好，或者说你觉得对你的领导一些建议，不要的去跟同事之间去说他坏话或者怎么样的，领导需要的是解决问题的人，而不是制造问题的人

七、沟通表达能力

1.和技术人员的沟通

跟开发人员阐述缺陷时要简洁明了、清晰易懂。当发现严重缺陷时，也不要大惊小怪，要站在开发人员的角度思考如何解决问题。而不是踩在开发头上，炫耀自己发现问题的能力。

2.和产品人员的沟通

当对产品提出意见时，要站在用户的角度去说明自己的想法，而不要主观认为不好而要求产品进行修改。

3.和上级领导的沟通

跟领导沟通时要有大局观，不能只考虑自己部门的情况。并且与领导沟通时，尽量直奔主题，不要拐弯抹角，当与领导意见不一致时，也不要直接反驳，应该先给予认可，再阐述自己的想法。

4.在集体会议中沟通

在集体会议中不要一味的突出自己的个人能力，不要当话痨，也不要默默无闻。适当的提出一些自己的见解，有助于让大家更加重视你的存在。切记不要在多人会议中，去指责别人和推卸问题。各个部门的同事，都要面子~

5.与下级员工的沟通

与下级沟通时不要摆高姿态，不要让下级产生畏惧感，应该更多的为下级解决问题。服务好部门的同事，才能更好的产生凝聚力。

八、宏观把控能力

1.有效控制测试时间

测试周期的时间控制，应当采取多种方法去衡量，例如人员能力，人员数量，项目复杂程度，同类项目的测试经验等多方面去衡量。

2.有效控制测试成本

测试成本指的是人员成本跟时间成本，不要浪费每个人的时间跟劳动力，要让每个人充分发挥最大的价值。

3.有效制定测试计划

测试计划对于一个项目是核心关键，它的存在为了让测试进行中有依据可查。所以测试计划，一定要切合实际情况，要经过思考和衡量最后得出计划安排。

4.有效控制组员情绪

组员的情绪可以直接影响测试进度跟测试的质量，当有组员出现思想问题时，应当及时沟通，采取一些必要的措施去解决问题。而不能装看不见。

5.有效进行风险评估

任何项目在进行期间都存在许多潜在的风险，例如，人员离职，生病请假，业务变更，需求变更，服务器或其他组件故障等。应当提前做出相应的解决方案，以免到时候手忙脚乱。

6.有效控制测试方向

测试的方向是指测试的目标和测试的范围，很多项目的测试是有针对性的，例如性能测试，所以在测试中，一定要随时清楚测试的目标和目的是什么，以免把时间浪费在无关紧要的业务上。

码字不易，临走点个赞撒！