灰盒测试流程概述：

　　灰盒测试主张测试人员早期介入测试，无需等待开发人员代码开发成型后，才介入测试。开发团队、测试团队相互协作，共同推进项目。下图描述了整个软件开发生命周期的各个阶段中灰盒测试的框架图：


　　这里重点对测试用例设计以及灰盒测试过程中的挑战加以探讨：

测试用例设计：

　　灰盒测试的测试用例设计，除了来自于需求规格说明书、设计说明书外，同时来自于对代码结构化的了解。

　　首先，开发团队根据客户需求，进行项目需求分析，并制定需求规格说明书，此时测试团队可同步参与需求分析工作，根据需求规格说明书，深入理解并审核需求，一方面对需求文档中不完善的地方加以改进，另外一方面进行测试需求分析，设计基于需求的测试用例。

　　然后，开发团队根据需求分析，从系统架构层面进行系统设计，将整个系统分模块设计，定义各模块接口；此时测试团队需了解和研究系统各模块架构，关系，各个接口定义输入、输出。设计基于模块的测试用例；

　　其后，开发团队进行编码，测试团队了解和浅阅读代码（注： 浅阅读，即重点关注代码中重要常量，宏定义，核心函数等，无需对代码完整深入分析），提取功能实现用到的主要常量、变量，挖出边界值，对照这些边界的功能，设计测试用例，然后在集成环境中进行功能测试。这样通过代码浅阅读的方式，进一步完善黑盒测试用例。因为有些边界值，开发人员在编码过程中会通过宏定义的方式在头文件中界定，只有通过代码走读的方式，才能更好的确定边界值范围。

　　这样经过这一系列的工作，测试团队积累了整个系统所需的测试用例。待系统成型后，进入到具体执行测试用例阶段。

灰盒测试挑战：

　　上述我们梳理了灰盒测试的流程，可以发现对于灰盒测试而言，测试用例的设计与传统黑盒测试相比较，多出的工作部分主要在于：需从设计文档入手了解模块设计，接口输入输出，同时结合代码浅阅读方式，设计更为完善的测试用例。从这个层面讲，灰盒测试似乎与黑盒测试区别不大，但灰盒与黑盒相较，更大的差异在于测试用例执行和评估等方面。根据洛克希德马丁公司对于灰盒测试的论述，实践层面，灰盒测试面临如下挑战：

　　·需要有判断测试覆盖的能力，评判测试的充分性

　　如何验证测试是否充分？如何评判测试用例是否存在遗漏？测试覆盖率是软件业界公认的评判标准。当测试人员在设计测试用例时，基于需求文档，设计文档，代码，可以通过需求与测试用例的矩阵图，来判断基于需求的测试覆盖，同时借助一些代码覆盖的工具，比如语句覆盖率，分支覆盖率等验证代码覆盖情况，通过代码覆盖率亦可评判代码是否有冗余？需求设计是否完整有效；

　　·灰盒测试需要有记录程序执行的详细日志信息，便于定位分析程序问题

　　灰盒测试既关注系统外部表现，也关注软件内部执行情况，如何通过有效手段，使得软件执行时外部表现与内部代码相结合，深层次剖析代码执行情况，对于定位和分析问题非常有帮助

　　·灰盒测试包含实时系统的性能测试，这对于实时嵌入式系统而言尤其重要，因为功能的输出正确仅仅是逻辑层面正确，还需要在时间维度上满足性能需求

　　2000年洛克希德马丁公司在之前灰盒测试基础上，提出系统层级的灰盒测试加入时间维度的测量，也即对系统性能进行评估和测试，这对于灰盒测试的提出了新的要求。实践角度出发，对于嵌入式系统而言，性能评估和测试也是必不可少的。