说起自动化测试，在这个软件吞噬世界的时代里，早不是什么高端技术了。从基本的单元测试，到复杂的系统测试，几乎都可以使用自动化测试来代替原本的手动测试。
随着软件规模的增大，软件的速度开始提升，特性也越来越丰富，测试的要求就逐渐变得高了起来。曾经那些不能够自动化的测试场景，如今也可以利用各种软硬件技术来实现自动化，就像是为了打败更强大的对手，越来越多的武功秘籍被开发了出来。
但就算最终练成了绝世高手，当我们面对的事一支军队的时候，那注定会毫无招架之力……
同样，即便我们有再强大的自动化测试技术来测试某个产品特性（比如JMeter的性能测试，Selenium的Web图形测试，RobotFramework的关键字驱动等等），想要测试好一个完整的产品，仅仅使用单一的一个框架是无法胜任的！
怎么办
虽然自动化测试技术已经发展到人工智能的阶段，但是很多企业和团队由于成本或者其他因素，依旧在自动化测试工具、平台的选择和开发上苦苦摸索和前进。
我们需要一个测试平台去统一集成这些框架，在这些框架的基础上发展出适合自己业务的平台，就好比带领武林高手去打仗，通过排兵布阵赢得胜利！
兵者，国之大事，死生之地，存亡之道，不可不查也。
既然如此，我们不妨先来接受下几个灵魂拷问——
问题1：你的自动化测试用例足够灵活吗？对于一个功能测试，这个测试用例是否能适应不同的测试环境？
问 题 背 景
很多团队开发的测试脚本业务和技术代码耦合得非常紧密，甚至对测试场景也有严格规定，所以往往不能够自动匹配不同的测试环境，甚至在环境做了一些修改之后，测试用例也需要相应进行修改。
问题2：你的测试用例扩展性足够强大吗？如果有新的测试技术和工具引入，能够快速扩展测试用例来支持新的技术和工具？
问 题 背 景
如果对于一个功能的测试，有了更可靠有效的测试工具支持，往往需要修改现有测试用例，或者修改现有的工具库来对新工具进行支持，在不修改或者少量修改测试用例的情况下很难完成扩展。
问题3：你的自动化测试报告是不是适合团队不同的使用者分析使用？你能否在测试报告中快速找到测试Failed的原因？
问 题 背 景
目前有大量的实践还是将测试结果以log日志的形式进行输出，没有很好地将测试结果分类和结构化，所以导致测试执行者在分析测试结果的时候需要花大量的实践去定位问题。
问题4：你能否根据不同的测试需求，来灵活组织和配置现有的测试用例？
问 题 背 景
一般在软件测试中，测试会分为不同的阶段，不同阶段的测试用例要求也不同。所以一些团队往往会去重复开发测试用例来满足不同阶段的需求，这个问题还涉及到自动化测试用例管理，如何高效管理现有的测试用例也是一个需要解决的问题。
问题5：如果你所在公司的其他团队也需要类似的测试平台，你是否能快速让他们部署你的测试平台？
问 题 背 景
如果把测试平台作为一个产品来看待，部署和安装是用户对该产品的第一次接触，如果一个产品的部署和安装非常复杂，那么会大大减少用户使用该产品的兴趣。但是往往很多测试团队不注重这一点，整个自动化测试项目以源代码形式托管在代码仓库中，没有规范化的部署文档，一个新手很难独自将整个测试平台执行起来。