自动化测试，我们在路上
上一篇 /
下一篇 2012-11-02 15:19:09
本文将结合业软产品线长期以来的编码现状提出我们到底应该如何去改善代码质量、提高编码效率，内容包括编码的过程、静态检查、自动化测试、代码Review、持续集成在业软的实践、以及持续集成推行的意义和推行策略。本文的最大特点是我们没有照搬别人的做法，而是结合我们的开发现状、正视我们当前的问题，寻求逐步通过每一步的小改进以最终提升我们编码过程的自动化水平。
1、 自动化测试
包括单元测试、集成测试（也称组件测试，如测试Action同时连数据库、测试Spring的Bean同时连数据库）、系统测试、功能测试、负载测试等，自动化测试技术一般不严格区分这些测试属于哪种类型，只要是为了尽早地发现代码缺陷而且是自动化的都可，有时我们也把这些自动化测试统称为开发者测试（Developer Test），测试的基础框架是Xunit（如JUnit、CPPUnit，称单元测试工具是不准确的），虽然自动化测试工具和测试技术有许多（如DBUnit、StrutsTestCase、EasyMock、Spring组件测试、Cactus等），但一般都基于Xunit框架，都能实施对测试用例的统一管理和测试执行。
2、 Review现状
Review活动相信是所有人都认可的质量保证活动，几乎每个项目都会去做，但效果不一定很好，这其中一个重要问题是Review的入口没有把关好，代码写完就匆匆提交Review，于是我们看到大家提交的问题很多都是些低级问题，其实这些问题本可以通过工具来自动发现，于是就造成了大量的人工劳动都消耗在本可以通过工具发现的缺陷上。另外一个值得大家注意的方面是Review的投入存在不足，很多专家要么出差，要么很忙，即使review，匆匆看看。
两个字概况Review的现状：低效。
3、 提升自动化测试水平
自动化测试一直是我们所向往的，其实我们都很清楚它的好处，它不仅避免了繁琐的、不断重复的手工测试，提升了测试效率，而且还可以获得以下好处：
（1）自动化测试可以有效驱动设计更加的完善，也就是所谓的测试驱动设计。
（2）自动化测试是软件重构的基础，没有测试代码的重构将是极其危险的。
（3）测试代码是一种无价的文档形式。
u 看设计文档不如去看测试代码。
u 测试代码反映了你的设计思路。
u 测试代码为你演示了如何调用一个函数（API）、如何创建一个对象等。
u 测试代码与产品代码肯定是同步更新的，但设计文档我们则未必能做到。
注：关于自动化测试请参看我的其它文档，本文不再详述。
4、自动化测试
关于自动化测试我在其它文档中已经说的很多了，这里要特别强调两点：
1 自动化测试是持续集成的重要内容，很多推行持续集成的项目组仅仅满足于每天能通过编译、或能通过静态检查就自豪地宣称她们已经做到持续集成了，这是非常片面的。
2 自动化测试能否做起来，一方面在于你是否已经掌握了足够多的测试技术或工具，另外一方面也在于我们是否有足够多的测试经验，包括用例设计、被测对象如何选择等。所以对于那些没有自动化测试基础的项目组，我们不建议一下子要求项目组把自动化测试做的非常完美，但一定要做起来，哪怕只做很小的一部分，万事开头难，只要有一个良好的开端，逐渐积累经验，相信在以后的项目中会趋于完美的，Cisco能够做到Source Code Test自动化100%覆盖，我相信我们也能。以下是来自我们的两个项目的自动化测试覆盖率报告，Java代码自动化测试覆盖率分别达到了88%和45%，我认为这已经是一个不小的进步了。
收藏
举报
TAG:
