白盒测试实施简介概要.pptxVIP

白盒测试简介 目录页 1.简介 2.提交文档 3. 测试策略 4.白盒测试与黑盒测试切入 5.代码覆盖讲解 1.简介 1.1 测试目的： 1).通过对源代码的单元测试，便于我们更早的发现 隐藏在代码中的错误 对代码的测试进行较彻底，也可以更快有助于开发部门更快更精准的修code的缺陷。 2).可以与黑盒测试一起起到相辅相成的作用，黑盒测试不能测试程序内部特定部位， 如果程序未执行的代码无法发现其中的缺陷，没有清晰的和简明的规格，测试用例很难被设计， 不易进行充分性测试，而白盒测试刚好能够弥补这些缺陷。 1.2. 白盒测试简称： 白盒测试也叫单元测试，简称为CTP(Component test procedure). 2. 提交文档 2.1 文档简述 文档名称 文档作用 TDF（Test definition file） 测试case脚本文件 TRS(Test Results Summary) 测试结果文件 TCA(Test Coverage Analyzer) 代码覆盖率收集文件 CUL（Compilation unit list） 需要被收集覆盖率的目标函数 RTT（Requirement to test） 测试用例与需求之间的追朔关系 DRV（Drive） 测试驱动模块，指模拟被测模块的上级模块 STB（Stub） 桩文件，指模拟被测模块所调用的模块 DSP（Description） 对于测试结果文件（RST,RPT）的一些补充说明，还有一些测试bug的记录,所有的解释补充说明都可以写在这里。 测试驱动模块 桩文件 桩文件 被测模块 桩文件 测试case脚本文件 ,需要被收集覆盖率的目标函数 测试结果文件，覆盖率收集文件 2.2 文档关系图 根据需求和code之间的追朔关系，找到需求对应的code 分析需求，设计测试用例，包括TDF,DRV,CUL,DRV, STB文件的编写 运行测试脚本 获取到测试结果文件（TRS,TCA）,并分析这些文件，如果有TRS中有Failed的测试项，TCA中有Coverage hold，应分析是否是代码或者需求的缺陷导致的。 在bug系统上提出测试中的测到的缺陷，和开发组协商，达到一致的解决方案，完善DSP文件。 上传测试文档（TDF,DRV,CUL,DRV, STB,TRS,TCA,RTT） 收到新的需求或者是需求变更 3. 测试策略 3.1 初步测试流程 3.2 建立“需求与代码之间的追朔关系RTC（Requirement to code），需求与CTP之间的追朔关系 RTT”的文档， 1).需求与ctp之间的追朔关系则可以从RTT中查找到 2).需求与代码之间的追朔关系 比如A需求是是实现在B代码中的，C代码是实现D需求，那么通过追朔关系文档，可以清楚明白A需求对应的是B代码，C代码对应的是D需求。 建议方法：每个需求和代码都编码，如 A需求 编码为：Req_01, B代码编码为：Code_01,然后建立如下表RTC文件。 最后把RTT,RTC文件上传至服务器端，和开发架构组协商开发一个trace tool，可以更方便的查找code,req,ctp三者之间的追朔关系。 Requirement docx Requirement anchor Code anchor Code name 01.docx Req_01 Code_01 B.java RTC FILE 4.白盒测试与黑盒测试的切入 需求级别分类： low level的需求：逻辑结构清晰，可以看出清晰的input，output的的需求。 比如说：涉及到 具体数值的，条件判断的 high level的需求：逻辑结构不清晰，无法看出清晰的input，output的的需求。 测试类型 切入阶段 作用 白盒测试 开发前期阶段，测试以白盒为主跟进开发进度，但前期需要投入比较大的人力资源 及早的帮助开发解决代码中的bug，以及发现不合理不清晰的需求 黑盒测试 开发完成后介入黑盒 收到测试需求之后进行首轮需求的粗略分析，high level的需求由黑盒测试进行，low level的需求由白盒测试。黑盒测试主要从业务层面对产品测试以及补充白盒测试一些无法测试到的需求。 5.代码覆盖讲解 假设一段code如下： if A=true and B=true then Action1; if C=true or D=true then Action2; 执行流程图如下： A = TRUE AND B= TRUE Action1 C = TRUE OR D = TR