软件基础个人工程——数独4

标签：href   概念   函数   人工   覆盖率测试   dfs   自己的   目的   代码分析   

GITHUB项目地址：

https://github.com/hhz-hhz/Sudoku_software_engineer.git

软工基础个人项目——数独1

软工基础个人项目——数独2

软件基础个人工程——数独3

四、测试阶段

1、同测试设计文档一样对程序进行了测试：

但SolvingSudoku.cpp中：

由于inline bool CheckingForDFS(int n, int key)和inline int SolvingByDFS(int n)都是用了全局数组，所以没有办法对它们单独进行测试。

GeneratingSudoku.cpp中：

inline void MovingStep()也是同上述一样的情况，所以也没有办法测试。

由此可以看出全局变量对于软件开发的弊端。

2、单元测试：测试代码见UnitTest文件夹

 3、测试代码覆盖率测试：

 4、进行完单元测试后的性能测试：

1）-c 1000000：对生成终局进行测试

2）-s D:\sudoku\Debug\sudokutest.txt：求解1000个终局

 五、总结和优化阶段

1、后续的优化

关于求解终局，求解1000个数独需要耗时与生成1000000个终局的时间几乎相同，但是当求解1000000个终局的时候还是需要花费很长一段时间，所以从性能分析表上看，需要对求解数独的方式进行优化，可能需要一个更为简便的求解数独的方式。以及文件的读取方式也有待改进。

2、PSP表格

 3、事后总结

1）、对于项目进度的设计

因为这次自己用VS进行单元测试的了解不够深入，因此对于时间的预估有些紧迫，所以对于时间的提前准确估计是有必要的。

2）、对于项目的体验

经过这一次的体验，认识到编程并不是全部，提前的准备和后期的设计对于项目而言都是必要的。前期对于需求进行一个足够的分析，后期才能够不去花费力气。就像这次，我在测试的时候一度不明白怎么进行单元测试，看到的例子都是由C++完成的，虽然中间有用到C++的函数，但是最终的形式并不是对象，所以中途想将它变成C++的对象的方式，但是这时发现再想改它很困难，由于时间紧张，就并没有将其进行修改，但是中间有经过数次的尝试，所以在前期分析好需求，制定好计划，是对于项目而言一件重要的事。

3）、对于代码规范

在进行前的代码规范设计的时候，有很认真的去查过资料，所以这次是按照代码规范来的，虽然有些地方不够规范，但是对于重要的函数、变量，都提前进行了命名的设计，所以再此后的代码实现的时候会很轻松的找到自己书写的函数和变量，命名规范也很容易让我联想起它们的作用。

之后又进行了代码分析，之前的概念里warning不是一件重要的事，但是经过这次的代码分析，可以看出不够严谨的代码可能会对程序带来安全隐患。所以对于warning还是需要去理睬的。

4）、对于编译器的用法

经过这一次的项目开发，我对于编译器的认识又上了一个层次，像性能分析、单元测试等，之前也都是没操作过的，并且在这一次的实验中几乎是每一个关于操作这些新东西的错误都遇到过，所以对于以后的使用也有了一个较大的帮助。

5）、关于代码托管

由于不够熟练使用github，前期都是通过自己的备份，后期看到要求后，慢慢地去使用，发现代码托管对于代码的备份，代码的一致性都有很大的帮助

4、运行结果图

1）生成终局

2）、求解简单数独

3）、求解多个数独

软件基础个人工程——数独4

标签：href   概念   函数   人工   覆盖率测试   dfs   自己的   目的   代码分析   

原文地址：https://www.cnblogs.com/picaqiu/p/12216012.html