DT10如何帮助用户有效达成灰盒测试目标.docxVIP

What is gray box testing and how can DT10 be seen as a product thatcan do gray box testing?前言：在1999年，美国洛克希德马丁公司发表了灰盒测试的论文，提出灰盒测试方法，是一种介于白盒测试和黑盒测试的一种新的测试方法。2000年洛克希德马丁公司在之前灰盒测试基础上，完整论述在真实环境中，以实时方式对嵌入式设备进行灰盒测试的方法（《Graybox Software Testing in the Real World in Real-Time》），进一步完善了灰盒测试理论，不单从覆盖角度验证软件功能正确性和测试完整性，同时从时间维度测试嵌入式设备的性能指标是否满足实时系统性能需求。黑盒、白盒、灰盒测试比较我们都知道黑盒测试一般根据系统的需求文档、设计文档，来设计测试用例，从系统的角度验证功能是否能否满足需求。黑盒测试的优点：由于其面向系统级别，不涉及代码，测试人员只需了解需求文档，根据系统功能描述设计测试用例，执行测试用例，简单易行，基本上只需要对测试有一定了解，对产品功能需求由较深的理解，即可实施黑盒测试。黑盒测试的缺点：由于只关注系统外部输入输出，而不会深入到系统内部，因此测试不够深入，容易造成测试遗漏，同时发现功能问题后，难以定位问题原因。白盒测试也即单元测试，一般由开发人员自己针对所写代码进行测试，其测试对象一般函数单元或者文件单元。白盒测试的优点：针对每个函数进行测试，测试粒度足够细，测试足够充分，通过单元测试用例的回归，发现问题时，很容易定位到具体的出错函数，同时测试用例一旦建立完成，可以通过命令行的方式自动化的实施回归测试。白盒测试的缺点：对测试人员要求较高，需要具备较强的阅读、编写代码能力；测试粒度细，因此需要花费大量的测试用例编写以及维护时间；测试对象是单元级别，主要验证函数的功能逻辑是否正确，没法覆盖系统级的验证，即使做了单元测试，仍需进行系统测试；同样由于其面向函数级别，单元测试也没办法实施性能测试。上面我们梳理了白盒测试、黑盒测试的优缺点，那么灰盒测试是否能够兼顾白盒、黑盒测试的优点，尽量避免白盒和黑盒的缺点，取长补短呢？灰盒测试从验证系统功能正确性的角度，以常规黑盒测试方式，同时结合程序内部逻辑结构设计用例，执行程序并采集程序执行路径信息和外部输入输出结果。灰盒测试的优点：灰盒测试对程序内部逻辑的关注不像白盒测试那样细致，是兼顾测试效果和效率的测试方法；能够进行基于需求的覆盖测试和基于程序路径覆盖的测试；测试结果可以对应到程序内部路径，便于bug的定位、分析和解决；能够保证设计的黑盒测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组合； 能够分析需求或设计不详细或不完整对测试造成的影响；由于面向系统级测试，能实施性能测试；当然灰盒测试也有其自身面临的挑战，文章后面部分会专门论述。灰盒测试流程概述：灰盒测试主张测试人员早期介入测试，无需等待开发人员代码开发成型后，才介入测试。开发团队、测试团队相互协作，共同推进项目。下图描述了整个软件开发生命周期的各个阶段中灰盒测试的框架图：这里重点对测试用例设计以及灰盒测试过程中的挑战加以探讨：测试用例设计灰盒测试的测试用例设计，除了来自于需求规格说明书、设计说明书外，同时来自于对代码结构化的了解。首先，开发团队根据客户需求，进行项目需求分析，并制定需求规格说明书，此时测试团队可同步参与需求分析工作，根据需求规格说明书，深入理解并审核需求，一方面对需求文档中不完善的地方加以改进，另外一方面进行测试需求分析，设计基于需求的测试用例。然后，开发团队根据需求分析，从系统架构层面进行系统设计，将整个系统分模块设计，定义各模块接口；此时测试团队需了解和研究系统各模块架构，关系，各个接口定义输入、输出。设计基于模块的测试用例；其后，开发团队进行编码，测试团队了解和浅阅读代码（注： 浅阅读，即重点关注代码中重要常量，宏定义，核心函数等，无需对代码完整深入分析），提取功能实现用到的主要常量、变量，挖出边界值，对照这些边界的功能，设计测试用例，然后在集成环境中进行功能测试。这样通过代码浅阅读的方式，进一步完善黑盒测试用例。因为有些边界值，开发人员在编码过程中会通过宏定义的方式在头文件中界定，只有通过代码走读的方式，才能更好的确定边界值范围。这样经过这一系列的工作，测试团队积累了整个系统所需的测试用例。待系统成型后，就进入到具体执行测试用例阶段。灰盒测试挑战上述我们梳理了灰盒测试的流程，可以发现对于灰盒测试而言，测试用例的设计与传统黑盒测试相比较，多出的工作部分主要在于：需从设计文档入手了解模块设计，接口输入输出，同时结合代码浅阅读方式，设计更为完善的测试用例。从这个层面讲，灰盒测试似乎与黑盒测