所谓黑盒测试，就是只测功能，不了解实现，从用户角度来测试功能，如果是专业的功能，那么测试人员是不懂用户的，就没法通过用户角度来测试了，因为测试人员对专业不了解，例如：财务系统，某功能的sdk。那么测试人员能测试的内容就非常有局限性，我所在的公司目前就有好些功能，例如：apm链路，rum sdk（用户访问采集），我也只能测试非常少的内容，只能算是小白入门了。

那么碰到此类情况，一般怎么办呢？ 我相信大部分是由开发自己测试，或是投放到线上，发布beta版本，有问题，线上反馈，然后再修复。开发测试的话，虽然也是可以测试，但是测试思维不一定全，但开发有深度。会培养测试人员吗，答案是不会，在如今的快速发布周期，是等不起的，而且投入大产出小，没人这么做。

那么开发有必要和测试讲讲他是怎么实现某些功能的吗？，大家所在的公司会不会与测试讨论这些，或者是让测试参与到其中，再其次让测试也了解了解，旁听一下？，我觉得大部分公司会的，让测试了解多一点，虽然测试不写代码，但好歹测试也是能学到一点东西的，说不定听多了，触类旁通，产生些火花思维呢？

当然，如果了解了白盒，一定是有好处的吗，也不一定，因人而异，有的人了解了白盒，会顺势而为，这样就不能发挥自己的作用了，只是顺着白盒的逻辑分之来测试。有的人了解了白盒，会发现其中的不足，很多的情况没有考虑到，会帮助其改正。看经验，看专业，看技术，看思维。

那么大家所在公司会把代码权限给测试放开吗？，这个我觉得给测试放开代码权限的公司，可能占少数，比较庆幸我所在公司给测试放开了权限，我有的时候会去瞄一瞄，虽然很多看不懂，但有的时候，还真发现了问题，例如有一次，我碰到了程序会产生很多僵尸进程，我就去就代码里面搜索exec调用的地方，还真找到了，这块业务调用正是会产生僵尸进程的地方。

大家作为测试，会写单元测试吗，最小颗粒度函数级别的测试，不是问你会不会的能力问题，而是你工作中有没有实践执行，我所在公司都是开发自己写的，如果你参与到其中，那么你所发挥的作用，可能不如做功能测试。毕竟功能测试是能贯通整个业务逻辑的。

如果公司的测试资源过剩，我觉得有测试来做单元（白盒）测试，那自然最好，如果测试资源紧张，那么让测试做功能（黑盒）测试最好