优点:对于业务手工测试人员，由面向代码或配置的开发转化为面向自然语言(测试描述)的开发，最大程度的降低了开发难度与维护成本，同时提高了测试用例的易扩展性、易组织性，实现了自动化代码不随用例的增长而增多。缺点:对测试人员的测试开发能力以及业务了解程度要求很高。适用场景:被测对象包含复杂业务流程(逻辑)，当然复杂的能做简单的更ok。
测试框架选择仅仅从实现上讲，很多种自动化测试框架(或工具)都可以开展自动化，或者说任意一种也不是很勉强， 所以在自动化框架(或工具)的选择上，不是人为核心的(我会什么， 或有哪种框架比较好掌握)，而是以被测对象为本来选择自动化框架(或工具)。两个场景：场景一:多维度的查询功能，类似于某宝商品的筛选查询。
场景二:较为复杂的业务流程，类似于某逐级审批流程系统。思考:关于这两种场景，我们如何选择自动化测试框架(或工具) ?场景一特点:类似于某宝WEB端， 不同关键词(衣服、足球)的多维度(品牌、发货地)组合查询，查询逻辑单一、复用性强。推荐使用:测试库架构框架 数据驱动框架。场景二特点:类似于审批申请流程，包含复杂的业务逻辑和多用户角色。
推荐使用:测试库构架框架 数据驱动框架(配置解耦） 关键词驱动框架测试用例开发两个注意规范性和契合性：开发规范性以及开发过程一定要与其自动化测试框架思想相契合，比加选择测试库构架框架，那么在用倒编写的时候，发现还有需要进行封装的功能操作时，需要在测试库中开发，在用例中调用，而不是随手在用例中进行开发。
开发成本和维护成本：开发设计一定要考虑开发成本和维护成本问题，开发成本决定效率，维护成本决定这个自动化能否长明有效的运行下去，同时注意关于成本问题的解决思路是在对被则对象进行有效覆盖的前提下，通过框架设计和优化方案来降低成本，而不是靠少做一些做的粗一些来降低成本。在自动化测试开展的过程中若注意上述的内容并加以实施，自动化测试的稳定性、可扩展性、可维护性可以得到进一步的保障。
代码里充斥着if-else分支有什么不好吗？除了可维护性，对程序运行效率有什么影响吗？
你问了两个问题。第一个问题的答案如下：电脑本身对大量的if-else分支毫不在意。然而， 对于阅读或者维护代码的人类来说，代码中充斥大量的if-else分支，导致代码难读，难懂，难维护，难修改，易出现逻辑错误等。换一句话说，正确性、可维护性堪忧，可靠性堪忧。针对性对策是重构代码，消灭if-else分支。
举一个例子, 一个用Haskell实现的一个函数。给定一个数，大于0则返回1，等于0返回0，小于0则返回-1。重构函数如下：通过重构，利用Haskell的模式匹配，去除了嵌套if-else分支。代码变得简单，易懂。越简单的代码，越容易理解，读懂，出错的概率越低。第二个问题的答案如下：对于程序运行效率，没有显著的负面影响。
文章TAG：程序 可维护性 维护 程序维护是指什么 什么是程序的可维护性
