软件测试
静态测试
软件测试管理
测试文档总结
动态测试
测试方法:源代码分析
测试过程管理
测试文档管理
需求可追溯
节点监控
0:编码规范
1:总览的测试需求
2:总览的测试计划
3:静态测试的测试需求
4:编码规范的checkList
5:静态测试报告
6:动态单元测试的测试需求及计划
7:动态单元测试的测试报告
8:动态集成测试的测试需求和计划
9:动态集成测试的测试报告
10:附录:工具生成的单元测试报告
11:系统测试需求与计划
单元测试
集成测试
资源配置
利用工具完成代码的静态测试
人工交叉的方式完成静态测试
C++TEST设定好编码规范,工具可以自动完成静态测试
利用软件编程规范CheckList完成代码的静态分析
系统测试
真实环境下的系统测试
故障插入测试
软件的故障插入测试
硬件的故障插入测试
源码分析的标准:MISRA标准:21个类别 147条
模块的性能测试
模块的功能测试
测试方法
测试方法:根据模块的区别分别测试,具体的后续需求中会描述
测试方法:根据模块不同,选用不同的测试策略,依托实际平台测试
资源需求
测试方法
测试文档
测试需求:
测试报告
附录类:如果使用测试工具,单元测试部分的内容可以通过工具生成
文档1:单元测试需求
文档2:集成测试需求
文档3:单元测试报告
文档4:集成测试报告
测试文档:
文档1:系统测试需求:测试前提条件、具体操作步骤、期望的结果、
文档2:故障插入测试需求::测试前提条件、插入的故障、期望的结果
文档3:系统测试报告:测试前提条件、具体操作步骤、期望的结果、实际的结
果、测试通过与否
文档4:故障插入测试报告:测试前提条件、插入的故障、期望的结果、实际的结
果、测试通过与否
12:系统测试报告
13:故障插入测试需求与计划
14:故障插入测试报告
15:各种测试需求与计划的评审记录
测试文档
文档1:静态测试的测试需求
文档2:编码规范的CheckList
文档3:静态测试报告::编码规范、不符合规范的条目、需要背离的原因
理论基础:Fema分析,做各种器件以及电路的失效分析
测试方法:故意破坏硬件电路的某一块电路或者某一个电阻,致使该块电路失效,
预估失效电路对整体电路的影响,观察模块整体的工作情况。
资源需求
资源需求
人员:软件工程师
平台:C/C++ 软件测试工具
时间:可根据代码量预估
测试内容
圈复杂度测试
覆盖率测试
行覆盖率/分支覆盖率/语句覆盖率/块覆盖率
边界值测试
借助工具,编写测试用例,插入桩函数,利用C++TEST完成自动化测试
人工方法:参考软件测试的原理与方法,将函数进行分析解剖应用各种方法完成测
试计算《白盒和黑盒测试方法》 缺点:耗时,工作量巨大
需求资源
人员:软件工程师
平台:C/C++ 软件测试工具
时间
自动测试:在完全掌握了测试工具使用方法,学会编写测试用例和插入桩函数后,
根据代码量可以预估
人工计算:在掌握软件测试的方法与计算原理后,根据代码量预估,但一定会比自
动测试使用时间长
测试内容:通讯速率、压力测试、响应时间
人员:软件工程师,有时需要硬件协助
平台:实际的测试模块
ADC模块
定时器模块
通讯模块:IIC SPI UART等
测试内容:根据模块的功能不同,设计各种测试用例验证模块的功能
OLED显示
按键测试
输入输出测试
子主题
在测试需求阶段需要详尽的编写功能的验证流程:
资源需求
人员:软件工程师
资源:实际测试模块
测试内容
功能验证:整体模块的功能
性能验证:时间参数、电流参数、电压参数、温度参数等
每一个功能的验证需要具体的测试流程指导
资源需求
人员:软硬件工程师配合完成
平台:产品模块
测试方法:利用软件的手段或者硬件电路破坏的方法造成故障,然后观察某一个模
块失效对产品整体影响的效果
资源需求
人员:硬件工程师
准备:学习Fema分析
平台:实际产品
人员:软件工程师,需要硬件支持
平台:实际产品
验收测试
测试方法:根据需求的要求来一一验证产品的实际实现
资源需求
文档
人员:产品经理
平台:最终的产品
验证需求和计划文档
验收报告
评论5