黑盒测试并不是一无所知的测试
测试组长(我)：小秋啊，来了快两年了，测试还是点,点,点吗？
比卡丘：嗯…是啊…领导，我们系统测试不应该就是站在用户视角测试吗？用户就是点点点啊？
测试组长(我)：呃…
解读
没错，系统测试这样的黑盒测试强调测试人员要具备用户视角，了解用户的环境和知识，像用户使用产品一样去操作产品。但这并不代表系统测试人员不可以去了解系统实现。更不能将这种一无所知或者所谓的“用户视角”作为自己躺平、拒绝成长的借口。
策略
“测试已SI”的论调喊了多年，SI的只是老旧的角色定位，一个“入得厅堂进的厨房”的测试人员,依然是如今团队期盼。独立的测试视角与过硬的测试能力为核心，并向需求、方案、实现方向拓展实现自身的价值是必然的要求。当年开发通过TDD、CI 这套东西抢测试人员的”饭碗“，现在是否该讨要回来呢？
1.深入，夯实自身测试能力：
打开更多的窗户
当你在UI界面点点点的同时，后台log日志中可能已经暗流涌动，打出各种断言、Error。这些错误信息中可能包含：模块信息、代码行数、函数名、已经相关操作…这些错误信息可能当前没有直接用户功能层面产生直接影响。但会给你的测试思路的扩展提供极大的帮助。除此之外，产品各个模块的计数器、状态打印、配置打印、诊断接口…等等各种偏实现层面，开发人员维测手段，都可以有意识的积累并善用，让很多的不可见变为可见、很多的不可测变为可测。为你自己开启测试Idea的窗户。
人与动物的本质区别就是工具
用户视角并不是真的让你构造弱网场景时拔网线、跑地库。又如，早年做接口健壮性测试，我们会利用报文构造工具，发送异常报文。但慢慢发现，靠测试人员的这类发散性思维去做反向测试很好，但是成本和效率不允许。所以后来才有黑盒或白合的模糊（Fuzz）测试工具。你需要用技术手段去解决用户视角、用户场景中的一些难点。
当然我们也需要避免另外一个极端，就是只会使用工具无脑跑用例的，工具小子、脚本小子。
2.拓展，为团队提供更多价值：
向缺陷预防方向拓展
例如，测试人员应主动参与需求研讨、需求澄清的相关工作。借助自己独特的视角帮忙项目区识别伪需求、不合理的需求、缺失的实例化场景，甚至是提出自己的可测试性需求。
向实现与技术方向拓展
深入了解产品技术栈、领域知识、业务逻辑。参与方案、设计、编码的相关评审和研讨活动，为开发提供宝贵意见，甚至自己参与一些TDD工作，辅助产品构建（很多开发是不懂测试设计的，这就是你的机会点）。同时也为自己系统测试或者集成测试打开思路，为什么不呢？
当你报残守旧的同时众包测试悄然兴起，你有你的用户视角，人家有他的黑眼圈…卷嘛，平均10块左右一个严重Bug，总还会有人乐此不疲。大家该怎么做？不言而喻…