?
????????大家应该经常看到“烂尾”建筑，整座建筑空荡荡的，附近长满了草，堆满了垃圾，严重破坏了城市形象。
????????烂尾的原因有很多，比如资金链断裂、验收不通过，其最根本原因还是在项目实施过程中，没有做好项目计划、项目监控、风险分析和评估。
????????我曾经也遇到过“烂尾”的毕业设计，情况是这样的
????????这是一名技术不错的研究生，他写的课题是大数据方面，用户行为分析系统，开题报告写的非常好，导师也同意开题了，但是在系统实现时，写了非常多的功能，大概有上百个，可视化界面也非常绚丽。很多功能在实现时，遇到难题就转入下一个功能，想最后再深入解决，想法是不错的。可系统各个功能开发完成后，他发现没有一个可以拿的出手的功能，每个功能都是浅尝辄止，根本没法写到毕业设计中。这名同学很聪明，论文中编造，说他功能都实现了，效果图也是通过编造数据展示的，很多功能的实现细节基本没有描述出来。那结果大家自然也就猜到了，论文整体不合格，写了大概三万字，七八十页的论文，最后导师给他当头一棒，论文整体不合格，导师给的建议是挑一个核心功能，然后“重写”。
????????这名学生的毕业设计，就跟上面给出的图一样，烂尾了。主要原因分析一下：
????????1. 没有跟导师实时沟通和交流。你的目的很简单，就是让导师满意，顺利毕业。遇到问题时，你要及时跟导师沟通，从导师那获取论文的”验收标准“。
????????2. 系统实现时，没有进行测试。每个功能实现时，要进行单元测试，保证当前开发的功能是正常的，此外还要进行集成测试，测试各个功能模块之间是否能正确的交互。
????????你的项目，要经过多轮的单元测试、集成测试，才能达到导师的“验收标准”，如果测试中发现问题、遇到难题，要及时向导师请教，让导师知道你的困难在哪里，这个困难有没有必要解决。如果从论文的开到到结束，一直按导师的标准来做，也就是做好项目的监控，就不会导致论文烂尾。那监控的手段是什么呢？其实就是今天要讲的主题，系统测试。
目录
????????毕业论文的系统测试这一章该写哪些内容呢？下面给出一个导图，供你参考。
?测试方法介绍
????????下面的这些理论概念，内容比较“干”，你用自己的语言进行描述，融入到你的毕业设计中即可。
????????白盒测试 ： 知道软件的内部结构后，进行测试。也就是具体到了代码层面，测试if-else、while、for等分支结构和循环结构。白盒测试中常用的是逻辑覆盖测试，其中又包括语句覆盖、判断覆盖和条件覆盖。
????????语句覆盖，所有的语句都覆盖一遍，这是最低层次的覆盖，语句都覆盖了，那通过if-else、while嵌套组合的各个分支，还需要测试，那就是接下来的判断覆盖和条件覆盖。
????????判定覆盖， 所有判定的真假分支都要覆盖一遍，比如下图，测试逻辑A和逻辑B。
?????????条件覆盖， 多个条件拼成一个判定，每个条件都覆盖一次，比判定覆盖覆盖率高。比如这里的 sources == null 和 sources.length() == 0 分别进行测试，这两个条件一个为真，都会执行 sources = VERIFY_CODES， 主要是为了测试逻辑是否写错，比如本来要用||，实际代码写成了 &&。
????????黑盒测试 ： 把软件模块作为黑盒子，只知道软件的输入和输出、软件的功能，不知道内部结构，黑盒测试又分为“等价类划分”、“边界值分析”等测试方法。
????????等价类划分， 考虑程序模块的功能是什么，哪些输入数据可以归为一类，比如考试成绩成绩分等级， A/B/C，不同的等级，对应不同的分数范围。
????????边界值分析，已经知道了程序的功能， 选取边界值进行测试， 测试边界值，端点上和端点之外的数据作为边界值。比如你的程序只允许输入正数，那么你测试的时候，0和负数，都要进行测试。
? ? ? ? 如果第一次听这些概念，可能看着能入睡，这很正常，如果以后工作了，会慢慢体会到这些方法的重要性。之前我也提到过，我们做事情，一定要有理论支撑，在这里我简称KPT（K为知识，P为实践，T为天赋，MIT大学教授温斯顿的“How To Speak”建议大家去看一看）
测试用例
????????本节主要以表格的形式展示，写你的测试用例描述、输入数据、预期结果和实际结果，但是注意的是，要写核心功能的测试用例，一些登录、页面效果展示等的非核心功能，不要在这里写。
????????这里我给一个范例，供你参考。
?测试结论
????????这一节，你可以这样写，通过白盒测试、单元测试、集成测试等测试方法，对哪几个核心功能进行了详细地测试，一些非核心功能也进行了测试，测试结果都符合预期。
????????希望通过本篇文章，让大家明白一点，测试并非在系统开发完成之后才需要考虑的，对于一个严谨的系统来说，在软件需求分析阶段，就需要考虑测试。
????????今天无意看到了一篇文章，吐槽一下，某大厂的首席架构师，在博客分享他作为架构师的工作经历，说当时自己不懂前端、测试，“架构师”这顶高帽子，真的不配戴。作为架构师不懂系统需求分析？不懂系统设计？需求分析和设计的时候不考虑测试？那这架构师，是架构了一个“学校图书馆管理系统”吗？
????????一些测试的原则，给大家分享一下，不仅是写毕业论文，在以后的工作中也会受益。对于我来说，工作多年了，对这些原则，体会越来越深。好了，本篇文章就到这里，希望能帮到你。
尽早、不断地进行测试，在需求分析阶段就要考虑测试
验收测试时，程序员避免测试自己设计的程序，潜意识按自己思路测试，是不全面、不可行的
既要选择有效合理的数据，也要选择无效不合理的数据
系统修改后进行回归测试
尚未发现的错误数量与该程序已发现的错误数成正比
好了，本篇文章到此结束了，你学会其中的套路了吗？如有需要，可以在左侧边栏联系我。