自动化功能测试
上一篇 /
下一篇 2014-04-11 21:39:47
/ 个人分类：悟
无需事事自动化，自动化花费很多，所以你应该主要测试应用程序的主要功能。某些测试可以快速轻松地手动完成，且潜在脚本可能难以实现。
值得用到自动化的是那些繁琐的需要被重复很多次的，和那些需要大量数据验证的测试
工作
可读性方面
源代码应该是自我记录的，而写下以下几行代码的每个利益相关者应该明白测试在做什么，为什么它被这么写。尽量避免在源代码注释，因为它也必须被更新。这值得花比平常多一点的时间来命名方法，从而使你的代码更易读。
再看看行为驱动开发技术，每个测试方法都应以单词“应该”开始，而不是“测试”。
根据这一惯例，我们马上就可以明白一个特定的方法测试什么内容了，它在分析测试报告时特别有用。
在我看来，我们应该尽量减少源代码的注释，可以在命名上面做更多的优化，非要注释不可的话，就应该使注释变得简练。
测试效率方面
自动化测试要快，自动化
功能测试应该是应用程序质量的一个指标。连续传递过程中的每一步都应指明最长持续时间；并且根据这个概念，开发团队应该尽快获得有关软件质量的反馈。自动化功能测试的持续时间应不超过几分钟。
对一个非常全面的测试集来说，有必要并行运行测试（经常在不同的机器上）。虚拟化在这里可能是非常有帮助的。
在一个或多个测试失败的情况下，开发团队的任何成员都应该能够轻松地找到错误的原因。
写短测试，出于这个原因，每个测试方法里应该最多有5个断言，并且每个方法都必须提供的测试操作的完整记录。
明智的做法是使用BDD（行为驱动开发）技术，但是当你没有用一个特定的测试框架时，你应该把接下来的测试步骤放comments //given //when //then下
创建独立测试，在测试类中的每个方法应该是一个独立的实体，而不是依赖于其他测试。我们应该能够在任何时间运行单个测试。否则，这样的
测试用例集将来维护起来就会很贵——必须定期跟踪和更新测试之间的联系。
很多时候，测试需要一定的前提条件来满足。这些条件不应该用外部方法，应该在试验开始时运行。如果这些条件和测试类的所有方法一样，它们就可以被放在一开始进行的方法里（例如：在
JUnit中被标记为@ BeforeClass）。
收藏
举报
TAG:
