1.2 一个例子引发的思考

1.2.1 准备

使用IDE（笔者使用的是IntelliJ IDEA）创建一个Maven工程，并在其pom.xml文件中加入TestNG和Selenium的依赖，如下所示。

再创建一个Maven模块用于存放本章的示例代码。

笔者创建的Maven工程名为“automated-testing-advanced”，Maven模块名为“chapter-01”，读者可根据实际情况命名为其他名称。

另外，笔者将在后续每章创建一个Maven模块，并依次命名为“chapter-02”“chapter-03”等。

1.2.2 编写登录测试用例

以Chrome浏览器为例，以下是一个登录IMS的自动化测试用例。

以上测试用例由打开登录页面、输入用户名、输入密码、单击登录按钮和校验结果等步骤组成，是一种“线性化”的测试用例组织形式，其类似于使用工具直接录制生成的代码。

1.2.3 如何优化测试用例

1.2.2节的登录测试用例粗略看起来没有任何问题，但仔细琢磨之后，其存在以下缺点。

（1）代码复用率低

对IMS的所有操作都必须建立在已登录的条件下，如果每个操作都需要编写登录代码，那么将产生大量的重复代码，因此代码复用率低。另外，一旦登录逻辑改变（比如：增加验证码）则需要修改所有测试用例，测试用例的维护工作量很大。第2、4和5章将会探讨多种方案来提高代码复用率、降低维护工作量。

（2）数据之间存在耦合

测试数据被硬编码在了代码中，如果换一个用户或换一个测试环境（即换一个IP地址或端口号）都需要重新修改代码，因此数据耦合也不利于测试用例的维护。第3章将介绍使用数据驱动测试的方法来对数据进行解耦。

（3）硬编码的等待时间不合理

为了防止首页还未加载成功就开始查找元素，从而导致抛出NoSuchElementException异常，因此测试用例中加入了3s的等待时间。但是问题是：假如1s就登录成功了，那么白白浪费了2s；假如5s才登录成功，显然等待的时间还不够，测试用例仍然会执行失败。第6章将介绍更为合理的等待方式。

（4）断言的可读性差

虽然TestNG的断言功能非常强大，但是可读性差。比如用例中的断言方法有两个参数，哪个参数是期望结果，哪个参数又是实际结果，并不是一目了然的。第7章将介绍多种断言方式，建议使用其中可读性好的断言方式。

（5）没有测试报告

默认情况下，使用IDE执行TestNG测试用例是不生成测试报告的，仅仅在控制台显示测试结果，但即使使用了TestNG的测试报告，其无论从信息量还是美观度来说都显得差强人意。第8章将介绍多种测试报告。

除了以上显而易见的缺点外，还有几个方面是需要在自动化测试的实施过程中考虑的。

（1）测试替身

当测试依赖不存在、不完整、不稳定或受限（调用次数、调用频率或费用限制）时，可以使用测试替身来简化测试工作。第9章将介绍5种测试替身，并重点介绍Mock。

（2）执行效率

当测试用例达到一定规模时，其执行的效率高低变得至关重要，因为如果不能在较短的时间内反馈测试结果，那么自动化测试存在的价值将会受到质疑。第10章将介绍提高执行效率的多种方案。

（3）持续集成、持续交付和持续部署

持续集成、持续交付和持续部署已经成为当今软件开发生命周期中不可或缺的一部分。第11章将介绍自动化测试是如何融入这个过程的。