如何做好软件系统自动化测试？

spasvo

系统级测试一般指对交付的系统进行端到端的测试，验证系统是否满足所有功能和非功能需求。
　　一般而言，系统测试是整个测试实践最重要的，但也是成本最大的测试。为了让系统测试能够有效并且低成本，我们先来看看系统测试在整个测试象限中的位置和分类。
如上在敏捷测试四象限，将所有测试实践分为四大类。上图中横轴从支持团队变化到评价产品，纵轴从面向技术变化到面向业务。
Q1：面向技术和支持团队；这一象限中主要包含单元测试和组件测试。该象限中的测试帮助团队获得代码级别的快速反馈，一般借助xUnit测试框架，要求完全自动化。
O2：面向业务和支持团队；这一象限中包含功能测试，原型测试和仿真测试等。该象限中的测试大多也可以自动化，但是需要借助面向领域专门的软件测试工具。一般是否自动化，取决于是否有低成本的系统级别自动化功能测试工具。
Q3：面向业务和评价产品；这一象限中包含探索性测试、可用性测试等等。探索性测试指靠测试人员的主观发挥去探索系统潜在的故障，该象限中其它的则测试偏重于客户主观感受，所以以手工测试为主。
Q4：面向技术和评价产品；该象限一般包括非功能测试，例如性能测试、压力测试等。非功能测试一般需要依靠专门的测试工具，能否自动化取决于性能工具天生是否对自动化有效的支持。
　　从上面的分类可见，系统级别测试包含上图中的Q2、Q3、Q4象限中的所有测试。还可以将系统级别测试按如下维度划分：
测试类型
　　功能测试原则上需要针对系统要完成的功能点逐一进行遍历测试，一般我们称其为验收测试。当代码发生修改，功能验收测试需要做回归，以确保修改的代码没有破坏系统功能。
　　由于功能验收测试需要频繁的运行和回归，所以这类测试需要尽快通过自动化来降低测试成本。取代人工回归测试的自动化测试可以释放人力，让测试人员把主要精力放在非机械性的需要创造性的探索性测试上。
　　由于越偏向业务，测试的独特性就越强，所以自动化功能测试工具一般需要自行开发。
　　好的消息是对于功能测试来说，测试用例编写、调度、报表生成的部分基本是通用的，所以可以找到不少开源的功能测试框架。但是这类测试框架一般不面向任何领域，只是完成通用的功能并且为扩展留好了接口，由使用者根据自己的领域对工具进行扩展。
　　常用的功能验收测试框架有Cucumber和Robot Framework。这两款工具对比如下：
　　如上，两款常用的功能验收测试框架使用都很广泛。Robot Framework相比较重量一些，但是支持的扩展方式多，而且测试用例风格不局限于BDD（行为驱动测试）风格，对传统测试人员比较友好。而大量的新的web应用开发者则更钟情于Cucumber，具体需要根据自己项目的实际情况进行选择。
　　无论是选择上述哪种测试框架，针对领域进行扩展是避免不了的。
　　如上图，从测试框架到被测系统之间，需要使用者去编写测试支撑库。这些支撑库和使用者的测试具体特征有关。例如对需要通过收发消息来测试的系统，就要根据消息协议开发具体的测试支撑库，以支持访问被测系统。对于常用的功能，都可以直接找到别人开发好的测试支撑库。例如Robot Framework就已经自带了常用的telnet，ssh，xml等库，而使用者特殊的产品功能一般都需要自行开发支撑库。
　　另外为了让测试用例容易编写可读性强，还需要编写支撑测试用例编写的库。框架在这方面会提供一些基本的支撑机制。例如Robot Framework支持关键字驱动的测试用例编写，框架已经提供了常用的关键字，但是和使用者领域相关的关键字还需要自行开发。
　　如上可见，系统级别的自动化功能测试是需要花一些精力的。但是以作者的经验，一旦在这方面取得突破，整个组织的敏捷性会提高一大步，这些付出还是值得的。
非功能测试
　　通过前面的介绍我们看到，非功能测试一般是需要借助专门的工具进行。例如性能测试，一般需要由专门的工具来制造负荷和压力。对于成熟常见的领域，一般可以找到免费的工具使用。例如对于互联网web服务器的性能和压力测试，可以找到一些免费工具。而对于专门的领域，则很难找到免费的工具，大多需要自行开发或者购买专门的仪表进行测试。
　　如果购买专门的性能测试工具的话，对自动化的支撑只能看工具本身的能力了。但是通过封装也能把一些测试过程自动化掉，但是由于专有工具的使用成本，一般自动化的意义未必很大。
　　对于性能测试，除去对系统做端到端的测试外，对代码级别进行profiling（性能打点统计）也是有价值的。一般出现性能问题后，需要找到代码的性能瓶颈进行代码修改，这时如果直接有数据指出哪里是可能的性能瓶颈，可以有效的指导代码修改。
　　自动化测试不能取代人工测试，事实上两种测试的定位是不同的。自动化测试是为了回归，而人工测试是为了探索。一旦探索测试中的一部分开始变得常规化，则可以将其编写成自动化测试用例后续自动执行回归，而让测试人员重新投入更有创造性的测试工作。
　　另外，自动化的系统测试也不能取代自动化的单元测试。从前面的四象限可以看到，系统测试是帮助产品的，而单元测试为了帮助开发团队的，两者的定位和价值方向不同。