第一次作业（个人作业）：阅读教材，提五个问题

这个作业的要求是：https://bbs.csdn.net/topics/608340750

问题一：我阅读了教材p50回归测试的相关内容在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那么这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。在微软的实践中，在一个项目的最后稳定阶段，所有人都要参加全面的测试工作，把所有以前发现并修复的Bug找出来，一个一个验证，以保证所有已经修复过的Bug的确得到了修复，并且没有在最后一个版本中“复发”，这是一个大规模的、全面的“回归测试”。 有这个问题，如果每一次软件更新都需要大规模全面的“回归测试”，那么更新软件的工作量我认为过于庞大，且每一次更新工作量都会大幅提高，想知道在软件开发流程中如何解决这个问题。

我查了资料（https://blog.csdn.net/catch_dreamer/article/details/109472775），有这些说法：在这种情况下（显而易见的是，随着软件的开发和迭代，以前测过的测试用例也会越来越多，也就是说回归测试的人力和时间成本会越来越大，而现在对于工作的效率和有效性要求都比较高。），我们就需要有针对性的进行回归测试，也就是说有策略的进行回归测试。

完全回归(Retest all)： 完全回归是指测试时选择基线测试用例库中的所有用例进行回归测试，这是一种最为保险的策略，相对于部分回归策略，其可以将遗漏回归bug(regression bug)的概率降到最低，但这种方式同时也是所有策略中成本最高的一种方式，尤其是越往后，随着测试用例的不断增多，最后完全回归所需要的时间和成本往往超出了预算。

部分回归： 部分回归是指在回归测试时选择基线测试用例库中的一部分用例进行回归测试，而不是所有用例全部执行，相对于完全回归测试，这种测试策略效率很高，并且所需要的时间和成本比较少，但也没有完全回归覆盖率高(或者说遗漏回归bug的概率比完全测试高)。

根据我的实践，我得到这些经验在实际的软件项目中，项目组会将测试编写的测试用例放在一起，形成一个测试用例库，这样就可以在后续的回归测试中更方便一点，比如自动化测试脚本用例。在进行回归测试的时候，就可以根据回归测试中测试用例的选择策略，从基线测试用例库中提取合适的测试用例组成回归测试的用例包，通过运行回归测试的用例包来实现回归测试。但是我还是不太懂，我的困惑是，虽然建立用例库可以在一定程度上简化回归测试的工作量。但维护用例库本身的工作量又该如何解决，或者说这部分工作量是不是导致回归测试并没有更方便？

问题二：我阅读了教材p87代码规范相关内容，在命名这一部分看到了“匈牙利命名法”程序中的实体、变量是程序员昼思夜想的对象，要起一个好的名字才行。大家都知道，用单个字母给有复杂语义的实体命名并不可取，也是经过了实践检验的方法叫“匈牙利命名法”。之前并没有对命名有系统化的认识，所以对此比较感兴趣。我查了资料（https://so.csdn.net/so/search/s.do?q=%E4%B8%89%E7%A7%8D%E5%91%BD%E5%90%8D%E8%A7%84%E5%88%99%E4%B9%8B-----%E5%8C%88%E7%89%99%E5%88%A9%E5%91%BD%E5%90%8D%E8%A7%84%E5%88%99&t=blog&o=vip&s=&l=&f=&viparticle=）匈牙利命名法是微软推广的一种关于变量、函数、对象、前缀、宏定义等各种类型的符号的命名规范。匈牙利命名法的主要思想是：在变量和函数名中加入前缀以增进人们对程序的理解。匈牙利命名法关键是：标识符的名字以一个或者多个小写字母开头作为前缀；前缀之后的是首字母大写的一个单词或多个单词组合，该单词要指明变量的用途。

根据我的实践，这种系统化的命名方法确实可以让变量、实体更直观的体现其实际意义，从而使整个程序更有逻辑，且一目了然。最主要的是可以让其他人阅读你的代码时更易懂。但我困惑的是，这个命名法并不简单，而且命名法也不止一种，难道写代码和读代码的时候还需要对照各种命名法吗？

问题三：我阅读了教材p90代码设计规范相关内容，在goto这一函数使用方面函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。有这个问题，在以往的学习中，我了解到尽量乃至不使用goto语句是一个程序是否结构化的判断，很好奇作者为什么鼓励或者说同意使用goto。

我查阅了资料(https://blog.csdn.net/qq_35683626/article/details/78263379)goto用法，可以跳出多重循环，标号只是标号，程序到标号位置正常执行。1：goto语句有啥毛病，goto来回这么跳，在程序庞大后，在调试时很难找到错误，所以E.W.Dijikstra在1965年提出结构化程序设计来规避这种错误，也使得代码更容易阅读。2：goto容易出错，但其仍然有存在的价值，在单个函数中使用goto基本不可能出错，goto在程序反操作上很好用。

根据我的实践，goto在短程序或者单个函数内还是比较好用的，但是要是在整个程序中滥用，恐怕会导致整个程序不具有结构化的特性，无论是阅读还是功能都会很不好。

问题四：我阅读了教材p255文学化编程（Literate Programming）程序员在写程序的时候，要理解在文档中的需求，同时还要在程序里写相关的注释，这些不同目的的“写作”各有价值，但是一旦需求或程序发生变化，这些不同的文档很难保持同步。更不用说程序员最常见的毛病“我以后会加上注释的……”Donald Knuth在20世纪70年代末开始尝试并提倡Literate Programming的思想并在自己的软件项目中身体力行。这一方法和常见的“写程序，时不时加上一些注释”相反，它是“写文档，时不时有些代码”。它使用了宏（Macro）来进行抽象和信息隐藏。我的问题是利用文学然后计算机提取出编译的部分，那是不是指文字的使用也有语法的限制，这算不算学一门新语言？

我查阅了资料（https://blog.csdn.net/c03424/article/details/79615309）文学编程元语言提供了两个重要特征；第一个是，能够把散文与源代码混合起来。该功能使程序的注释和它的实际源代码一样重要，鼓励精心设计和文档编制。其次，语言提供以完全不同于编译输入的顺序机制方式展示程序代码。因此，该程序可以以逻辑方式描述，每个命名块代码称为片段，每个片段都可以通过名称引用其他片段。可以使代码更富有逻辑性并容易理解，在文档中，我们可以依次介绍每个片段及其实现。这种分解使我们每次呈现几行代码，从而使代码更容易理解。另一个优点是，这种编程风格以逻辑片段分离函数，每个都有一个单一且明确的目的，每个都可以独立地写、验证或阅读。总的来说，我们将尽力使每一个片段不到10行。但我仍然不懂的是，需要按照某种排版编写文档，不知道这个所谓的排版是什么要求，是否像一门新语言一样复杂。

问题五：我阅读了教材p320我听说在软件项目中，有这样一个拐点存在——在这一点之前，新的Bug产生的数量大于Bug解决的数量；在这一点之后，Bug的解决数量大于新的Bug产生的数量。这样Bug的曲线就向下移动。我的问题是，为什么会出现新bug产生的数量大于bug解决的熟练，以及这样的拐点出现之后要怎样解决？

我查阅了资料，建议提出了对bug进行更详细分类的方式，找出影响提测质量的关键类型bug，找出有异议的bug，找出需求不清晰的bug等，在一个迭代结束后拿来分析，挨个突破，提高整个团队的工作效率和质量。上线前：1.自测用例未通过2.代码错误3.需求不清晰4.需求变更5.测试遗漏6.历史遗留7.改动波及8.覆盖升级。上线后：线上故障-新增、生产环境Bug-新增。并没有查阅到“拐点”相关的具体资料，似乎是因为某个必须修复的bug未被解决，导致剩下的开发都通过了这个bug，导致后续的bug越来越多。解决方法则是bug有更清晰的认知，合理安排，及时解决等等。