需求分析——采用技术——理论支持
1.需求分析
1.1团队代码开发工作流
1.规约、文档、需求分析原型设计
2.架构与编码 (代码版本管理系统Git/SVN)
3.代码审查、测试与调试【本篇主要任务】
4.发布、部署
1.2需要的功能
参考我上一篇博客收集到的现有工具来进行分析：
代码检查、评审、单元测试工具 大搜集
软件测试对象的6种分类:
单元测试（静态检查、动态测试）
集成测试
压力测试
回归测试
Alpha测试（系统测试）
Bete测试（交付测试）
- IDE界面
让使用者可以粘贴或修改代码，提供语法高亮和检查 - 导入工程 配置编译器
为方便使用和整体测试，提供可以全工程导入的方法
为适应不同编译环境的系统，让代码跑起来的环境应该可以自定义，对新手提供路径方法提示 - 生成测试用例
可以手动输入用例、可以自动按类型生成测试用例、可以按规则设置用例、可以导入导出用例 - 静态测试、动态测试，回归测试
可以进行回归测试，判断按照断言机制，生成驱动函数并返回正确率 - 性能测试（时间、内存，类似在线判题系统）
对运行各个模块所消耗的时间和内存进行记录 - 生成报表
可以生成征提的测试报告 - 桩函数 覆盖率分析
为解决不便测又存在于其他模块流程中的模块的运行问题，进行桩函数处理
对控制语句进行白盒测试的覆盖率分析
2.采用技术（功能模块）
-
IDE界面
使用现有开源的IDE作为基础，并对其进行精简和二次开发，测试的反馈页显示在它上面 -
导入工程 配置编译器
貌似是调用系统命令行惊醒自动处理，配置改的就是其调用参数 -
生成测试用例 断言与回归测试
用例进行扩充，包括名字、电话等类型的自动生成
使用现有开源测试框架，自动生成其基础之上的驱动函数再运行
C++ 的单元测试工具 —— Catch
google test -
桩函数 覆盖率分析
不懂 -
性能测试（时间、内存，类似在线判题系统）
google benchmark -
生成报表
不懂
3.理论支持
- 单元测试（Unit Testing）
颗粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”；是指对软件中的最小可测试单元进行检查和验证。 - 集成测试
介于单元测试和系统测试之间，一般由开发小组采用白盒+黑盒的方法来测试，即验证“设计”又验证“需求”。主要用来测试模板与模板之间的接口，同时还要测试一些主要的业务功能。 - 系统测试
颗粒度最大，一般由独立的测试小组采用黑盒的方式来测试，主要测试系统是否符合“需求规格说明书”。在经过以上各阶段测试确认后，把系统完整的模拟客户环境来进行测试。
以上摘自：什么是：单元测试、集成测试、系统测试
其中，集成测试对象是由通过了单元测试的各个模块所集成起来的构件；系统测试对象则除了软件之外，还包括计算机硬件及相关的外设、数据采集和传输机构、支持软件、系统操作人员等整个系统。
所以此处我们着重讨论单元测试
以下摘自：
软件测试概念及分类整理汇总（真大佬，很全面）
单元测试(自顶向下，自底向上，静态测试)
单元(Unit)指一个可独立运行的代码段，独立运行指这个工作不受前一次或接下来的程序运行的结果影响。
单元测试的内容包括对最小单元进行功能、性能、接口和设计约束等正确性检验，主要- 测试其在语法、格式和逻辑上的错误。
3.1单元测试重点内容
- 白盒测试
语句覆盖测试
判定覆盖测试
条件覆盖测试
判定—条件覆盖测试
条件组合测试
路径覆盖测试 - 黑盒测试
等价类划分方法
边界值分析方法
错误推测方法 - 静态测试
代码走查
代码审查
代码评审
3.2单元测试的内容
-
模块接口测试
对通过被测模块的数据流进行测试，检查进出模块的数据是否正确。
调用本模块的输入参数是否正确；
本模块调用子模块时输入给子模块的参数是否正确；
全局量的定义在各模块中是否一致；
外部输入、输出。
模块局部数据结构测试 -
检查局部数据结构能否保持完整性。
不正确或不一致的数据类型说明
变量无初值
变量初始化或默认值有错
不正确的变量名或从来未被使用过
出现上溢或下溢和地址异常
模块边界条件测试 -
检查临界数据是否正确处理
普通合法数据是否正确处理
普通非法数据是否正确处理
边界内最接近边界的(合法)数据是否正确处理
边界外最接近边界的(非法)数据是否正确处理
模块独立执行路径测试 -
对模块中重要的执行路径进行测试。检查由于计算错误、判定错误、控制流错误导致的程序错误。
运算符优先级
混合类型计算
精度不够
表达式的不正确符号
循环变量的使用错误
模块内部错误处理测试 -
检查内部错误处理设施是否有效。
输出的出错信息难以理解
记录的错误与实际不相符
程序定义的出错处理前系统已介入
异常处理不当
未提供足够的定位出错信息
3.3单元测试的环境
基本单元本身不是一个独立的程序，自己不能运行，要靠其它部分来调用和驱动。
驱动模块的设计比桩模块简单
- 驱动模块(driver)
被测基本单元的主程序，它接收测试数据，并把数据传送给被测单元，最后输出实测结果。 - 桩模块(stub) ──存根模块
用来代替被测基本单元调用的其他基本单元。
3.4其他补充
4.撸起袖子加油干！
基本思路就是——IDE+调用分析+编译运行+结果记录。
4.1搜集养料
先进行顶层设计，搭好框架，要用什么做出有什么功能的东西？
不同功能之间的代码低耦合，最好能以插件形式存在（静态、动态、录制……）
C++ 动态链接库的两种调用方式
开源一个代码规范检测工具
基于动态输入追踪的模糊技术研究
下图来自论文“基于动态输入追踪的模糊技术研究”，这是个逆向的漏洞测试。
还有 Cppcheck分析报告里的处理流程和功能组成
4.2编辑界面+编译选项——简单的IDE
在VS code中使用MSVC+命令行编译生成C++程序
Cppcheck的命令行使用
我采用qt框架和c++语言，先搭出编辑器的架子
开发自己的IDE（十），我终于搞定了智能提示了哇哈哈
4.3调用cppcheck进行静态分析
通过命令行进行调用？
4.4使用googletest框架进行动态测试
如何使用googletest？
4.5性能测试
记录并显示
4.6覆盖率分析、生成报表
如何使用googletest？
4.7操作录制，自动化测试
这又是另一种问题