夜深了，有这个想法不是一天两天了，但一直没有大胆的说出来，今天说出来是觉得需要一位行动者，自己的经验、技术、思想已经接受过时间和挫折的洗礼，此乃天时；很高兴能认识这个平台，把测试从业者、爱好者、引领着聚集到一起，此乃地利；最重要的还是需要得到各行业各背景测试从业者的经验和反馈，这是人和。立贴为证，明年的今天第一版的期限。
白盒测试：以传统 MVC 下的 M 和 C 为例，直接对代码进行测试。管理和流程混乱的公司，开发不会自觉、负责的的进行单测，Bug 满天飞，版本迭代循环死。客观条件很难改变的情况下，只能测试介入，问题是如何介入，如何做好？
黑盒测试：UI 测试目前市场上有很多框架供选择，但是对付稳定且业务流简单的项目尚可，在崇尚敏捷和业务流复杂的项目中表现如何，自动化产出的数据有参考价值吗？维护成本高吗？个人觉得大多数 e2e 的测试框架的技术的确牛逼，但未真正解决 UI 测试的维护成本（别提页面、业务、脚本、数据分离这么 low 的解决方案）和稳定性问题（别提智能等待、健壮性处理等治标不治本的解决方案）。
接口测试，请求参数形式多样，有简单的、有 json 格式、xml 格式、也有包含在 URI 的，返回结果形式也多样，有 json 的、xml 的、也有自定义结构的。。。有需要登陆态的、接口之间有依赖关系的。。。如果自己写框架如何实现其通用性、灵活性？虽然第三方工具基本都支持，但扩展性、断言等不如自己写的框架去方便实现。例如，我要加个需求。
以上，只是一部分，我相信大家还遇到好多情况。
能解决问题的测试框架是建立在好的测试经验和失败的测试实践，以及先进又实用的思想之上的，闭门造车不行，所以衷心希望各位能分享自己成功的案例、失败的实践、以及对自动化要解决你关心的哪些问题提出宝贵建议。