记录督促学习历程4

第八章

第八章到了，软件测试环节，这一章主要介绍软件测试过程和一些测试技术，需要了解从开发过程到系统客户的验收测试，通过案例介绍帮助客户发现程序缺陷，了解，测试优先的开发，是在写代码之前设计好测试案例，然后自动地运行这些用例。掌握组件 测试、系统测试和发布测试的主要差异，以及了解用户测试过程和技术，测试的目的是视图说明一个程序可以做做我们期望它所做的工作和在投入使用之前发现程序的缺陷，审查测试运行的结果，找出关于程序的非功能属性的错误、异常或其他信息。
关于这一段描述，我认为需要关注的是，是指非功能属性的错误，这点是为什么，需要后续解决，打一个问号。
测试过程有两个既然不同的目标：1向开发者和用户展示软件满足了需求，2为了找出软件中的缺陷和不足。测试大概可以分为，有效性测试和缺陷测试，在有效性测试过程中，我们将会发现系统的缺陷，在缺陷测试过程中一些测试案例将会表明这个程序满足它的要求。

在下面这里，提到了黑盒测试，书中附录了一个测试输出模型，需要注意，在缺陷测试中，优先去发现输入端的输入，因为会暴露系统的问题，但是有效性测试需要正确的输入来进行测试，所以这些输入必须是在于错误数据集合之外，这些模拟系统产生所期望的正确结果，测试不能够证明软件没有缺陷或者是它在每个环境中都能够按指定的方式执行，我们忽略的某个测试往往能够发现系统其它的一些问题。这一段文字很重要，基本上概括了黑盒测试的特性，我看了几遍才看懂。

测试只能够证明存在错误，而不能证明它们不存在，测试是一个软件更广泛的检验和有效性验证过程的一部分，检验和有效性验证是不一样的，它们之间的区别就是，1检验负责确定建立正确的产品与否，而有效性验证是证明建立的产品正确与否。检验和有效性验证过程是关于审查被开发的软件是否满足它的描述和复合购买用户所需要的功能，这些审查过程在有需求时就开始并持续到最后。

有效性验证的目的是审查软件满足它的所规定的的功能和非功能性需求，检验的目的是确保软件符合用户的期望，由于需求描述不一定真实反映用户和使用者的真实愿望和系统需求，所以检验是必要的。检验和有效性验证目的是确定项目的信心，这种信心主要取决于：1软件目的、用户期望、市场环境。这里必须提一下，之前对于V&V没有重视记忆，导致这里看到没有第一时间反应出来是什么意思，需要强调记忆一下，是指有效性验证，

审查主要关心一个系统的源代码，除此之外也设计任何可读的软件表示，例如它的需求，或是设计模型。当我们审查一个系统时，我们用系统知识、它的应用领域、编程或建模语言来发现它的错误。
这里需要注意的是，目前我对于审查和测试之间的关系不是很清楚，需要学习后归纳一下，见详情课后笔记。
相比软件测试，软件审查有三个优势：1在测试期间，一个错误可能掩盖其他错误，当一个错误导致不希望的输出结果时，我们永远不能确信后来的输出异常是由于一个新的错误造成的，还是原来的错误的副作用而导致的，因为审查是一个静态的过程，我们不必关心错误之间的相互作用，所以，一个单个审查阶段可以发现系统中的许多错误。2审查一个系统的不完整版本不需要额外的代价，如果一个程序不完整，我们需要开发特殊测试工具来测试可用的部分，这明显增加了系统的开发成本，3，除了搜索程序缺陷，审查也可以考虑一个程序更广泛的质量属性，如符合标准、可移植性和可维护性，我们可以寻找系统抵消的维护和更新，不恰当的算法，以及差的编程风格。

这里我已经明白审查和测试是两种方法，其概念是并列的，程序审查能比程序测试更有效地发现缺陷，但是审查不能代替软件测试，审查不擅长发现几种错误，比如，缺陷是由于程序不同部分之间的未预料到的交互而造成的，或因为时序问题所产生的，或因为系统性能问题而导致的。此外，尤其是在小公司或开发组中，把独立的审查小组这个起来非常困难和昂贵的，因为所有潜在的团队成员也可以是软件开发人员。这里的意思就是，审查是凭借理论认知对不同阶段进行校验，但是有一些问题是需要测试来实践，才能发现问题，

下面是关于软件测试抽象模型，我再看的时候在想测试用例中的用例是例子的例还是，之前模型中所讲的用例脚本，这个需要好好理解学习一下。

典型地，一个商业软件系统要经过3个阶段的测试1开发测试，即在开发中进行系统测试来表现故障和缺陷，在测试过程中很可能涉及系统设计师和程序员，2发布测试，即一个测试小组对一个系统的完整版进行测试，然后发布给拥护。发布测试的目的是审查系统是否满足系统信息持有者的要求，3拥护测试，即系统的拥护或是潜在的拥护在他们自己的环境中测试这个系统，在实践中，测试过程通常既包含手工测试也包含自动测试，在手工测试中，测试人员用一些测试数据来执行程序，然后将结果和预期结果进行比较，，他们记录下来并报告给程序开发人员有差异的地方，在自动测试中，测试是通过一个程序去执行的，该测试程序会一遍遍地执行正在开发的系统。这就是所谓的自动化测试和手工 测试的差异，这里引入了一个概念叫做回归测试，我记在了笔记本上，表示重新运行先前的测试以检测对程序的变更没有引入新的故障。自动测试很好，但是不能是完全的自动测试，因为自动测试只能检测一个程序做了它应该做的事，或者是对于焦放在程序没有不希望的负效应的测试，自动测试就不能代替手动测试。

开发测试包括系统开发团队所进行的所有测试活动，软件的测试人员通常是开发这个软件的编程人员，同时也可以是开发和测试配对，在开发过程中在三个粒度级别进行测试，1单元测试2组件测试3系统测试，开发测试是一个缺陷测试的过程，测试的目的是发现系统中的错误，通常和调试交错执行，调试是定位有问题的代码。然后修改代码。单元测试是测试程序组件的过程，测试对象类时，要对所有对象类特征进行覆盖。这里需要注意一个专业术语，自动化框架JUnit，单元测试可以用自动化测试。自动化测试有三个部分：1准备部分，2调用部分3断言部分。由于测试是非常昂贵和费时的，所以选择有效的单元测试案例是非常重要的，选择测试案例可以有两种策略：1划分测试，即识别具有共同特性和以同样的方法处理的一组数据，2基于准则测试，即使用测试准则来选择测试案例，这些准则反映程序员在开发组件时经常犯的各种错误的经验。这一节主要是讲方法性内容，做着重符号，以便后面再看和查阅。
当我们使用系统描述来确定系统描述来确定等价划分，这被称为黑盒测试，不必了解系统是如何工作的，然而白盒测试是对黑盒测试的补充，白盒测试时，我们可以看到程序代码来发现可能的测试，这里又一些原则：1选择能够迫使系统产生所有错误信息的输入，2设计能够使系统的输入缓冲溢出的输入，3重复相同的输入或一系列输入很多次，4迫使产生无效的输出，5迫使输出结果太大或太小。软件组件通常是由许多彼此交互的对象组合的复合组件，在程序组件之间又各种接口类型，有一些接口错误：1参数接口2共享内存接口3程序接口4消息传递接口5接口误用，6接口无解，7时序错误。测试接口缺陷很困哪，原因在于接口缺陷往往在不寻常的条件下出现，接口测试有一些准则，1审查要测试的代码并明确地列出对外部组件的每个调用，2当有指针从接口传递时，总用指针参数来测试接口，3挡组件通过程序接口被调用时，设计一些容易引起组件失败的测试，4在消息传递系统中进行强度测试5当组件间通过共享内存来交互时，可以设计一种测试，使其对激活组件的次序有所改变，开发中的系统测试包括集成组件来形成一个新版本的系统，然后测试集成后的系统。系统测试确保组件时兼容的，能正确地进行交互，以及通过它们的接口在适当的时候传送正确的数据。这个和组件测试有区别，文中有提到，需要注意一下。

自动化系统测试比单元和组件测试困难。

测试驱动开发是一只程序开发方法，测试驱动开发的引入是作为极限编程这样的敏捷方法的一部分。这里再一次提到敏捷开发，重复记忆一下计划驱动和敏捷开发。之后介绍了关于测试驱动的几个步骤，需要注意一下下面的示意图。测试驱动的开发理由是帮助程序员弄清楚代码段实际上应该作甚， 除了对于问题的理解有帮助，还有其他优势：1代码覆盖2回归测试3简化调试4系统文档。测试驱动开发的最重要优势是减少了回归测试的代价。需要再次理解一下回归测试的定义。

发布测试是为开发组意外的拥护使用的系统的一个特殊版本所做的测试过程，注意发布测试和系统测试的区别，发布测试通常是一个黑盒测试过程，测试从系统描述导出。后面需要注意是需求测试是按需求进行测试，情景测试是按照特定发生场景进行测试。性能测试是在系统已经完全继承后，测试总体特性，一般是性能和可靠性测试，性能测试必须设计以保障系统可以处理预期的负荷，可以关注一下压力测试。用户测试主要分三种类型1阿尔法测试2贝塔测试3接受测试需要关注一下本章节最后的要点和问题。

第九章

主要是了解软件进化是软件工程的一部分，理解进化过程，学习不同类型软件维护方法，以及影响费用因素，如何对遗留系统进行评估。这一章有点难理解花了很多时间。

软件的开发不会因为系统的交付而停止，在系统开发完成后，如果要使其继续有用，那么对它进行修改是不可避免的。变更的拥护需求，软件的错误报告，或者软件系统环境中其他系统的更改都有可能称为软件进化的原因，令人满意的系统有很长的周期，软件工程师一个贯穿系统生命周期的有需求、设计、实现、测试组成的螺旋过程。

软件进化过程依赖于所维护的软件的不同类型和参与开发过程的机构和人，有的公司有结构化文档，有些没有，系统变更建议都是系统进化的动力，同时要考虑成本和影响。可以把变更实现的过程看成一个开发过程的迭代过程，其实我自己也是这么理解的。通常情况下，有时需要快速变更主要由于可能是严重的系统缺陷，可能是系统操作环境变更，可能是系统上运行业务有没有预料的改变发生，，敏捷方法和过程也许会在程序进化和开发中用到，要做到开发团队之间关于计划驱动和敏捷之间的统一性。

程序进化的动态特性就是对系统变更的研究，需要注意的是，大型系统自身的动态特性是在开发过程早期阶段监理的，决定了系统维护过程的总的趋势以及系统变更可能此书的极限，这里需要记一下，lehman的几个结论，很有代表性。

对于软件的维护，有三种类型的软件维护，1修补软件缺陷，2使软件适应不同的操作环境3增加或修改系统功能。这里有一个概念就是附录里的，遗留系统是仍能使用的旧系统，需要记一下这个概念。需要注意，在系统投入使用之后增加功能，较之在开发期间实现相同的功能代价要高得多，预测有什么样的系统变更和系统哪些部分可能是最难维护的时候，同时要去估计在给定时间内的系统总维护成本，具体要评估下面几点，1系统接口的数目以及复杂性2固有的易变性系统需求的数目3系统所处的业务过程。

对于一些旧系统，要采取再工程进行改善结构性和可理解性，再工程相较于直接替换有风险和成本上的优势，同时，软件再工程的缺点是系统经过再工程能改善的范围受到限制。

重构是提升程序以减缓其由于更改而退化的过程，意味着通过修改程序来改进程序结构性，降低程序复杂性，让程序变得更加易于理解。在重构时不应该增加功能，注重程序的改进，再工程和重构不是一回事，再工程发生在系统已经维护了一段 时间并且维护费不断上升的情况下，通过使用自动化工具来处理并再工程一个遗留的系统，这里再次提到遗留系统，这个概念要记住 ，产生一个更具有可维护性的新系统，重构是一个连续不断的改进过程，贯穿于开发和进化的整个过程，重构是避免导致成本上升和维护困难的结构以及代码的退化问题。

能够被重构改进的地方有1冗余代码2长方法，3选择语句4数据聚集5假设的一般性。重构在程序开发期间实现，是一项有效的降低成都长期维护成本的途径。

用增量开发和CBSE开发的新软件系统，可以规划如何把系统开发和进化结合，对于遗留系统，必须拓展和调整适应变化中的环境。下面主要是论述，对于选择遗留系统上的一些细分项目，对于量化系统质量，可以1请求系统变更数目，2用户界面数目3系统使用的数据量，来进行量化，简单来讲留不留，不仅要考虑量化，还要考虑高层意见。

第八章内容相当多，已经记下要点，要时刻进行重复记忆。第九章一般，了解主要概念之后，细分概念比较好理解。