测试员应该自动化可接受性测试，使用与开发环境一样的编程语言来编写可接受性测试的代码，重用单元测试的框架，使软件更加可测。
利用“灰盒”测试。设法弄清楚系统各模块之间的关系，分析变更的影响，看什么是需要测试的，什么是可以不测试的。弄清楚bug，bug的表面现象是什么?产生bug的根本原因是什么?弄清楚风险，使用解决风险的测试策略，调整测试目标。
敏捷测试的挑战之六：我们还需要bug跟踪系统吗?
有些人说敏捷团队不需要跟踪bug，只需要把发现的bug尽快修正就行了。
这种做法只适用于开发过程的测试，如果是一个完整迭代的测试，你就需要bug跟踪系统，因为有些bug不是在这个迭代马上修改的。
其中一个最好的质量标准是发布后逃逸的bug数量。不辛的是，这是个事后的衡量标准。
采用每个迭代后计算逃逸bug数量的方法能标识代码的质量。
我们还可以从bug学习到很多东西：
1、 是否有些类型的bug在可接受性测试中发现的，其实是可以在单元测试就发现呢?如果是，把它加入到单元测试。
2、 我们是否能让bug的发现过程或bug的诊断更简单?
3、 我们是否能让程序员不那么容易犯这种普通的错误?
敏捷测试的挑战之七：回归测试
伴随着频繁的迭代，我们需要频繁地重新测试，单元测试是不足够的。我们怎样有效地进行用户层面的回归测试呢?
你不一定需要在每次的迭代都做完整的回归测试。可以每个迭代运行一部分的测试。需要某种程度上的用户层次的自动化回归测试。
敏捷测试的挑战之七：回归测试工具
大部分的商业测试工具在敏捷环境下都不是很好用。大部分有这些缺点：
1、 指定的语言
大部分商业测试工具会指定某种语言，例如：WinRunner(TSL)、SilkTest(4test)、Robot(Test Basic)，但是一些新的工具也开始使用标准语言，例如：Astra QuickTest(VB Script)，XDE Tester(Java)
文章来源于领测软件测试网 https://www.ltesting.net/
