软件白盒测试流程也逐渐融入到研发流程中。 典型例子：将软件白盒测试中发现的问题纳入统计，并以缺陷密度（每千行代码发现多少个Bug）作为软件白盒测试是否进行的衡量标准在研发过程中就足够了。 除了覆盖率指标之外，还可以作为检查个人是否经过充分测试的基础。 个体行为很难转化为组织行为。
开始意识到单元测试应该由开发人员完成
大多数还处于混乱状态的公司认为单元测试应该由测试人员来完成。 他们可能会觉得自己编码、测试的开发人员会陷入惯性思维，测试效果不会好。 但让测试人员在实际操作中多次操作，就会出现几个难以克服的问题。 首先是测试效率。 测试人员不熟悉代码。 他会阅读源代码并尝试进行测试。 有许多琐碎的功能，随机的开发人员可以在一天内编写一堆新功能。 因此，如果测试人员在单元测试方面做得很好，他通常要付出比开发人员自测试多10倍的精力。 这种情况是致命的。 测试注定是不可持续的。 其次，测试人员在进行单元测试时往往无法确定某种现象是否是问题。 浪费在重复的沟通中。
会发现仅仅通过覆盖率来评价测试的充分性是不够的
引入行业工具来实施覆盖率测试。 当企业软件白盒测试达到一定水平时，就会陷入一个困惑：是否足以评价测试是否足够覆盖率？ 覆盖为了覆盖，这个目标太容易实现了，跑一两个高层业务电话，覆盖率就会快速提升，也就是说，如果有人想作弊，他只需要让覆盖率达到要求就可以了。一些用例。 有人进一步思考这个问题，又产生了另一个困惑：软件白盒测试到底测试什么？ 你能看到代码吗？ 代码覆盖率直观地表达了可见代码是否已经运行，但如果规范要求，它却忘记执行。 ，覆盖率是什么意思？
不同的员工做软件白盒测试，结果差别很大。
这种现象每个公司都会遇到，尤其是在软件白盒测试的初期。 能力强的人很少会错过测试，也很少会错过后续阶段的问题。 那些能力差的人，尽管努力把每件事做好，但还是有很多漏考的情况。
软件白盒测试理论将毫无用处
软件白盒测试无用论大多不是在理论上反对软件白盒测试，而是在实践中反对软件白盒测试。 做了很多单元测试，但结果并不好。 看到表面问题，再发现深层次的逻辑问题或者界面问题。 不，所以我认为软件白盒测试不是很有用。
软件白盒测试的成功很大程度上取决于有才华的经理或有才华的 QA
在软件白盒测试的初始阶段，执行力较强的管理者或QA能够成功实施软件白盒测试，但执行力较弱的管理者或QA则不会成功。 很多公司因为单元测试多次失败而彻底放弃白盒，只做黑盒测试。
有的公司坚持下来，在一两个项目组取得成功，然后有针对性地优化组织架构，比如成立专门的工作推进组、建设软件白盒测试专家资源库、为软件白盒测试提供测试指导等。每个项目，进一步优化流程，将软件白盒测试的监控点纳入流程进行控制。 当企业的组织架构和流程逐渐完善时，软件白盒测试的成功对个人人才的依赖就更少了。
分阶段实施软件白盒测试，测试用例无法维护
集中精力编码一段时间，编码后集中一段时间进行单元测试，单元测试结束后开始集成，这时候集中时间进行集成测试。 这是大多数企业实施软件白盒测试的模式。 在这种模式下，单元测试或集成测试只是在特定时间段内（例如一个版本周期的一两周）实施的活动，但产品修改代码却一直在进行。 这就带来了一个深刻的问题：用例维护与产品代码维护不同步！ 因此，你经常会看到一个产品的第一个版本可以完全实现单元测试，然后时不时地更改代码来解决问题，或者更改代码添加功能而难以继续进行单元测试，这往往导致V1版本只做了一次单元测试，之后V2、V3等版本就无法进行单元测试了。
可能有人认为，为了让软件白盒测试在版本周期中持续进行下去，是不是一定要引入持续集成呢？ 试想一下，从编码到版本维护，开发者有多少独立、互不干扰的编码时间？ 而从两人开始融合到融合需要多长时间？ 毫无疑问，后者占据了大部分时间。 如果集成开始后每次版本修改都有测试跟进，那大家不是每天都写测试用例吗？ 这不就是持续集成吗？ 如果您不想每天、每隔一周、每月或每个其他版本添加用例，您怎么知道？ 添加的用例将涵盖所有更改的代码？
嵌入式产品的单元测试应该在板上吗？ 这个问题更多地可以归结为实践中是否可行。 理论上，没有人规定单元测试不能上板。 但在实际运行中，通信产品中的单板单元测试大多失败。
根据实践推断，通信软件的单元测试应该在模拟环境中以纯软件的方式进行，但集成测试可以在单板上进行，在真实环境中进行。
