手工测试
将xml文件内容正常解析并导入JCR只是第一步，第二步我们需要在Bundles里为该类型的报表编写模板使之正常展现。由于涉及到报表样式，这个测试我们采用手工测试，这个工作也是QA工作的重要一部分。
在最开始的开发中，我们没有导入所有报表数据进行测试。这带来了问题，由于客户遗留数据跨越10多年，各种数据形式都可能存在（特别是04年以前数据，给UI带来了很大挑战），而最开始的开发中，我们只是使用了部分数据（09、10年数据）进行测试，这个导致了建立UAT环境时程序的很多返工以及QA的测试压力。
2、Bundles的测试
自动化测试
对领域模型，我们采用了TDD的方式进行单元测试；在本地Jackrabbit实例里建立数据，领域模型封装数据测试行为。
对servlet，我们采用了TDD的方式进行集成测试（同时测试了servlet和领域模型），在测试中对request和response进行mock； 对JS，我们使用数据驱动的selenium功能测试进行覆盖。
我们最后的自动化测试结构：
手工测试
手工测试内容主要是功能测试。
自动化测试价值低的部分我们采用手工测试，这部分内容包括报表模板，相对独立，内容不多，一次测试处处通过；
自动化测试成本高的部分我们采用手工测试，这部分内容包括报表展现组件的编辑功能，因为采用了Ext JS，所以自动化测试困难；
无法自动化的测试：报表在线生成PDF，报表样式，WEBDEV批量上传图片等;
我们与QA的约定：
每完成一个用户故事，我们会与QA、BA一起mini showcase；
QA验收完成后编写功能测试用例；
我们对QA编写的功能测试用例进行自动化，共同维护一个功能测试列表；
对于不能自动化或自动化价值不高的测试用例QA继续使用手工测试。
四、我们感受到的自动化测试价值
1、通过自动化功能测试，我们使得需求对客户可视化；
2、QA的回归测试成本降低，尽管目前频繁的向客户实际使用环境部署，但QA每次部署只需要做一些简单的冒烟测试；
3、测试即需求，这点在TDD的开发过程中感觉非常明显，今天开发的目的就是使这个测试通过，避免了频繁部署到应用中进行测试，最快的电梯不是速度最快的电梯，而是中间停的楼层最少的电梯；
4、与持续集成一起，及时反馈。这点在进行JS代码编写时，心理上都非常依赖于selenium测试，对于没有测试覆盖的地方，没有安全感；
5、足够的单元、集成测试保证了频繁重构，没有人愿意引入BUG，没有足够的测试，没人愿意重构；
6、测试即文档，良好的测试和命名，使得新加入的成员非常容易理解当前代码的功能。
五、思考和讨论
1、自动化功能测试做到多少才合适？
当然是越多越合适，问题在于自动化功能测试成本要大大高于单元测试和集成测试，这些成本反映在测试环境的搭建、数据的准备，需要准备其他很多关联数据例如用户信息和权限信息、自动化功能测试的运行时间长、稳定性（随机成功/失败）、编写等等，需要权衡成本与收益。
个人认为，自动化功能测试需要考虑的着重点包括：页面是否包含大量功能交互性JS（与展现性JS相对）？当前功能是否与其他功能共享一些代码？即独立性，独立性越低越需要着重覆盖（这里又涉及到另外一个问题，即从各个模块里重构出共用代码是否总是合适？）。QA每次冒烟测试时是否需要重复回归（重复回归次数越多，自动化越有价值）？经常失败的测试一定比不失败的测试价值更高？或者从未失败过的测试就没有价值？
2、单元测试？功能单元测试？
TDD的测试粒度多大才合适？从我个人而言，几乎天然的反对mock，为了满足测试覆盖率的追求，强制将两个联系很紧密的类分开，做出各式各样mock，这真让人气馁；stub也不是什么好东西，在一个曾经的spring项目里，在测试目录里，一堆一堆的测试xml配置文件让人有种呕吐的感觉。那就做集成测试吧，两个类关系很好，那么就整体测试它们的输入和输出，看起来很不错，功能实现了，测试也没多写，也不用准备太多其他东西，但是打开实现代码，你就发现那个丑陋，到处是复制和粘贴，是啊，不管黑猫白猫抓住老鼠就是好猫，只关注了当前结果，完全失去了TDD驱动简单设计的好处。
3、测试的重点是测试用例的设计，它反映出对需求的理解
那么结论就很明显，我们如果连需求就没有理解，如何进行实现，所以测试驱动是很自然的。
文章来源于领测软件测试网 https://www.ltesting.net/
