选择测试用例进行自动化的标准

如果不考虑时间和人力成本，忽略技术门槛，大部分人都希望对整个项目进行自动化测试。但事实并非如此。因此，所谓“选择测试用例进行自动化”，就是根据每个用例“实现自动化的难易程度”和“重要性”两方面进行优先级的排序。

下面，将结合测试用例的类型、项目所在阶段，进一步讨论。

项目中涉及到的测试用例大部分是以下几类：

• 流程测试

可能会涉及多个角色，通过一系列的输入输出、各种窗口跳转，来验证业务逻辑或规则。

• 功能测试

检验某个功能是否可用，如，是否可以创建表单，是否可以上传文件

• 属性测试

查看被测系统的元素属性。如，图片的大小和排列；按钮的可用和不可用

• 输入数据测试

检验被测系统接受有效数据、拒绝无效数据的能力。如，HTML、SQL脚本注入，提交超长字符串

当然，兼容性测试也经常会遇到，但从另一个角度来说，系统的兼容性测试也好，浏览器的兼容性测试也好，执行测试的工作还是要在某个平台或浏览器上进行流程、功能等几个方面的测试。

那么，对于以上四类测试的用例，我们在进行自动化时，应该如何考量呢？

先说实现自动化的难易程度。有一些系统是无需登陆的，直接以Windows帐号的用户名、密码访问。对于涉及到多个角色的流程测试而言，就不仅仅是调用测试框架的类库那么简单的事情了（当然，这是可以用Runas命令解决的）。但这与功能测试中一些简单的打开网页，点击按钮的工作相比，的确是麻烦一些。根据工具的使用经验，从“实现自动化的难易程度”来说，个人认为，属性测试<输入数据测试<功能测试<流程测试。

再说不同类型测试用例的重要性。单纯地只考虑测试用例本身，显然是不行的。因为我们不能脱离项目的开发阶段，正如在设计测试用例的时候，项目处于不同的阶段，需要编写的测试用例也是不一样的。类似地，位于不同的阶段，我们会选择不同的用例进行自动化。况且，建立自动化测试项目比建立手工测试项目前期花费的时间要多得多，这是没有捷径的。自动化是在一个版本构建之后进行，在它开始之前，你已经执行了手工测试。

项目开发的早期，发布的待测系统往往只包含基本功能，也恰恰是待测系统的核心。此时，不必急于对诸如非正常登陆、用户配置或其他语言选项之类的进行自动化测试，尽管它们也是基本功能，但它们可能不是系统最关键的部分；也无须对状态栏、提示的内容，这些后期才会确定和注意的部分进行自动化。在这个阶段的有限时间里，应该把握相对稳定的、与客户日常工作关联紧密的功能。比如，在某个用于市场调研的办公系统中，调研问卷是系统的基础数据，对它的增、删、改、查是系统的基本功能，在这一点上，不太会有变更。尽管调研问卷是系统用户经常用到，也是非常关心的，但是与它相关的流程，可能涉及多个部门，很难在早期就完全确定。因此，如果具备了自动化测试的条件，我们应该先对调研问卷的增、删、改、查功能进行自动化。

项目开发的中期，发布的待测系统应该具备了大部分的功能，也具备了一定的数据校验能力。此时，大家最关心的是功能的实现，所以从“重要性”的角度来说，功能测试>输入数据测试>属性测试。但是如果某一功能还存在未关闭的Bug，就不应该为它创建自动化测试脚本，因为它是不稳定的。

项目开发的后期，发布的待测系统已基本稳定，开发人员的工作主要是修复Bug，而不是新增功能。此时，在完善功能测试自动化之外，可以尝试对流程测试进行自动化。需要说明的是，如果一个流程不能通过自动化测试达到100%准确测试，就不要进行自动化了，除非它能节省大量的手工测试时间。

综上所述，自动化测试是用来验证曾经正确工作的部分仍然在正确工作。选择测试用例进行自动化的原则是：

• 如果测试用例未通过手工测试，不要自动化

• 如果不能通过自动化对这个用例进行100%准确测试，不要自动化

• 结合项目情况，分析用例“实现自动化的难易程度”和“重要性”，按优先级进行自动化