编码就是把软件设计结果翻译成用某种程序设计语言书写的程序，是对设计的进一步具体化

程序的质量主要取决于软件设计的质量。软件测试是保证软件质量的关键步骤，是对软件规格说明、设计和编码的最后复审

编码 

选择程序设计语言

程序设计语言是人和计算机通信的最基本的工具，会影响人的思维和解题方式，影响人和计算机通信的方式和质量，影响其他人阅读和理解程序的难易程度。

选择适宜的程序设计语言的原因：

• 根据设计去完成编码时，困难最少；
• 可以减少需要的程序测试量；
• 可以得到更容易阅读和更容易维护的程序（极端重要）

高级语言优于汇编语言：

• 汇编语言编码需要把软件设计翻译成机器操作的序列， 既困难又容易出差错；
• 高级语言写程序比用汇编语言写程序生产率可以提高好几倍；
• 用高级语言写的程序容易阅读、容易测试、容易调试、 容易维护。

理想标准：

• 应该有理想的模块化机制，以及可读性好的控制结构和数据结构；
• 使编译程序能够尽可能多地发现程序中的错误；
• 应该有良好的独立编译机制。

实用标准：

• 系统用户的要求；
• 可以使用的编译程序；
• 可以得到的软件工具；
• 工程规模；
• 程序员的知识；
• 软件可移植性要求；
• 软件的应用领域

编码风格（逻辑清晰、易读易懂）

源程序代码的逻辑简明清晰、易读易懂是好程序的一个重要标准，为了做到这一点，应该遵循下述规则。  

1.程序内部的文档
所谓程序内部的文档包括恰当的标识符、适当的注解和程序的视觉组织等。

• 标识符：含义鲜明的名字、缩写规则一致、为名字加注解；
• 注解：正确性，简要描述模块的功能、主要算法、接口特点、 重要数据以及开发简史或解释包含这段代码的必要性；
• 视觉组织：适当的阶梯形式使程序的层次结构清晰明显。

2.数据说明     
数据说明的原则：

• 数据说明的次序应该标准化；
• 当多个变量名在一个语句中说明时，应该按字母顺序排列这些变量/行业内的约定标准；
• 如果设计时使用了一个复杂的数据结构（能不用就不用），则应该用注解说明用程序设计语言实现这个数据结构的方法和特点。

3.语句构造
下述语句构造的原则有助于使语句简单明了：

• 不要为了节省空间而把多个语句写在同一行；
• 尽量避免复杂的条件测试,不主张多个逻辑条件复用；
• 尽量减少对“非”条件的测试（数据库中）；
• 避免大量使用循环嵌套和条件嵌套；
• 利用括 使逻辑表达式或算术表达式的运算次序清晰直观（避免程序难读）

4.输入输出 
在设计和编写程序时需考虑有关输入输出风格的规则：

• 对所有输入数据都进行检验； （如：某省某市谋县）
• 检查输入项重要组合的合法性；
• 保持输入格式简单；
• 使用数据结束标记，不要要求用户指定数据的数目；
• 明确提示交互式输入的请求，详细说明可用的选择或边界数值；
• 程序设计语言对格式有严格要求时，应保持输入格式一致；
• 设计良好的输出 表；
• 给所有输出数据加标志

5.效率   效率主要指处理机时间和存储器容量两个方面。

• 效率是性能要求，因此应该在需求分析阶段确定效率方面的要求；
• 效率是靠好设计来提高的；
• 程序的效率和程序的简单程度是一致的，不要牺牲程序的清晰性和可读性来不必要地提高效率（不要炫技）。

 (1) 程序运行时间    
写程序的风格会对程序的执行速度和存储器要求产生影响，应遵循的规则如下：

• 写程序之前先简化算术的和逻辑的表达式；
• 仔细研究嵌套的循环，以确定是否有语句可以从内层往外移；
• 尽量避免使用多维数组；
• 尽量避免使用指针和复杂的表；
• 使用执行时间短的算术运算；（有意识研究风格，优化）
• 不要混合使用不同的数据类型；
• 尽量使用整数运算和布尔表达式

(2) 存储器效率

• 在大型计算机中必须考虑操作系统页式调度的特点，一般说来，使用能保持功能域的结构化控制结构，是提高效率的好方法。
• 在微处理机中如果要求使用最少的存储单元，则应选用有紧缩存储器特性的编译程序，在非常必要时可以使用汇编语言。
• 提高执行效率的技术通常也能提高存储器效率。提高存储器效率的关键同样是“简单”。

(3) 输入输出的效率     
简单清晰是提高人机通信效率的关键。从写程序的角度看，却有些简单的原则可以提高输入输出的效率。

• 所有输入输出都应该有缓冲，以减少用于通信的额外开销;
• 对二级存储器(如磁盘)应选用最简单的访问方法；
• 二级存储器的输入输出应该以信息组为单位进行；
• 如果“超高效的”输入输出很难被人理解，则不应采用这种方法。 

软件测试基础  

软件测试的目标

关于测试的一些规则如下：

• 测试是为了发现程序中的错误而执行程序的过程。
• 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
• 成功的测试是发现了至今为止尚未发现的错误的测试。

测试的正确定义是“为了发现程序中的错误而执行程序的过程”。
测试决不能证明程序是正确的。即使经过了最严格的测试之后， 仍然可能还有没被发现的错误潜藏在程序中。
另外，在综合测试阶段通常由其他人员组成测试小组来完成测试工作（心理学角度）。

软件测试准则

• 所有测试都应该能追溯到用户需求；
• 应该远（需求分析）在测试开始之前就制定出测试计划；
• 应该从“小规模”测试开始，并逐步进行“大规模”测试；
• 穷举测试是不可能的；（时间、人力、其他资源）
• 为了达到最佳的测试效果，应该由独立的第三方从事测试工作（承担模块测试工作）

测试方法

黑盒测试（又称功能测试—>接口）把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。
黑盒测试是在程序接口进行的测试， 检查：
程序功能是否能按照规格说明书的规定正常使用；
程序是否能适当地接收输入数据并产生正确的输出信息；
程序运行过程中能否保持外部信息（例如数据库或文件）的完整性。

白盒测试（又称结构测试） 是把程序看成装在一个透明的白盒子里，测试者完全知道程序结构和处理算法。
这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求（详细设计）正确工作。

测试步骤

测试过程也必须分步骤进行，后一个步骤在逻辑上是前一个步骤的继续。

大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成，因此，大型软件系统的测试过程基本上由模块测试、子系统测试、系统测试、验收测试和平行运行等五个步骤组成。

1.模块测试（单元测试）
在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。模块测试的目的是保证每个模块作为一个单元能正确运行， 所以模块测试通常又称为单元测试。模块测试所发现的往往是编码和详细设计的错误。

2.子系统测试   
子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的要解决的主 要问题，因此，这个步骤着重测试模块的接口。

3.系统测试   
系统测试是把经过测试的子系统装配成一个完整的系统来测试。 在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。系统测试发现的往往是软件设计中的错误，也可能发现需求说明中的错误。      

子系统测试和系统测试，都兼有检测和组装两重含义，通常称为集成测试。

4.验收测试(确认测试）
验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主
要使用实际数据(系统将来要处理的信息)进行测试。验收测试的目的是验证系统确实能够满足用户的需要，验收测试发现的往往是系统需求说明书中的错误。

5.平行运行  
所谓平行运行就是同时运行新系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。   
这样做的具体目的有如下几点。  
(1)可以在准生产环境中运行新系统而又不冒风险。   
(2)用户能有一段熟悉新系统的时间。  
(3)可以验证用户指南和使用手册之类的文档（软件配置）。  
(4)能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。

测试阶段的信息流

测试阶段的输入信息有两类：
    (1)软件配置，包括需求规格说明书、设计说明书和源程序清单等；
    (2)测试配置，包括测试计划和测试方案

1、简单循环   
应该使用下列测试集（测试用例集合）来测试简单循环， 其中n是允许通过循环的最大次数。

• 跳过循环。
• 只通过循环一次。
• 通过循环两次。
• 通过循环m次，其中2
• 通过循环n-1,n,n+1次。

(2) 嵌套循环   
如果把简单循环的测试方法直接应用到嵌套循环，测试数就会随嵌套层数的增加按几何级数增长，B.Beizer提出了一种能减少测 试数的方法,跳过循环。

• 从最内层循环开始测试，把所有其他循环都设置为最小值。
• 对最内层循环使用简单循环测试方法，而使外层循环的迭代参数（例如，循环计数器）取最小值，并为越界值或非法值增加一些额外的测试。
• 由内向外，对下一个循环进行测试，但保持所有其他外层循环为最小值，其他嵌套循环为“典型”值。
• 继续进行下去，直到测试完所有循环。

(3) 串接循环
如果串接循环的各个循环都彼此独立，则可以使用前述的测试简单循环的方法来测试串接循环。
如果两个循环串接，而且第一个循环的循环计数器值是第二个循环的初始值，则这两个循环并不是独立的。当循环不独立时
，建议使用测试嵌套循环的方法来测试串接循环

黑盒测试技术 

黑盒测试着重测试软件功能。黑盒测试并不能取代白盒测试， 它是与白盒测试互补的测试方法，它很可能发现白盒测试不易发现的其他类型的错误。   
黑盒测试力图发现下述类型的错误：
(1) 功能不正确或遗漏了功能；
(2) 界面错误；
(3) 数据结构错误或外部数据库访问错误；
(4) 性能错误；

(5) 初始化和终止错误。

白盒测试在测试过程的早期阶段进行，而黑盒测试主要用于测试过程的后期。  
设计黑盒测试方案时，应该考虑下述问题。
（1）怎样测试功能的有效性br>（2）哪些类型的输入可构成好测试用例br>（3）系统是否对特定的输入值特别敏感br>（4）怎样划定数据类的边界br>（5）系统能够承受什么样的数据率和数据量br>（6）数据的特定组合将对系统运行产生什么影响r>

应用黑盒测试技术，能设计出满足下述标准的测试用例集。   
（1）所设计出的测试用例能够减少为达到合理测试所需要设计的测试用例的总数。   
（2）所设计出的测试用例能够告诉人们，是否存在某些类型的错误，而不是仅仅指出与特定测试相关的错误是否存在

等价划分

       等价划分把程序的输入域划分成若干个数据类，据此导出测试用例。等价划分法力图设计出能发现若干类程序错误的测试用例，从而减少必须设计的测试用例的数目。
       如果把所有可能的输入数据(有效的和无效的)划分成若干个等价类，则可以合理地做出下述假定：每类中的一个典型值在测 试中的作用与这一类中所有其他值的作用相同。因此，可以从每个等价类中只取一组数据作为测试数据。这样选取的测试数据最 有代表性，最可能发现程序中的错误。
       使用等价划分法设计测试方案首先需要划分输入数据的等价类，为此需要研究程序的功能说明，从而确定输入数据的有效等 价类和无效等价类。
       划分等价类需要经验，下述的启发式规则可能有助于等价类划分：   
        (1) 如果规定了输入值的范围，则可划分出一个有效的等价类(输入值在此范围内)，两个无效的等价类(输入值小于最小值或大于最大值)。
        (2) 如果规定了输入数据的个数，则类似地也可以划分出一个有效的等价类和两个无效的等价类。
        (3) 如果规定了输入数据的一组值，而且程序对不同输入值做不 同处理，则每个允许的输入值是一个有效的等价类，此外还有一个无效的等价类(任一个不允许的输入值)。
        (4) 如果规定了输入数据必须遵循的规则，则可以划分出一个 有效等价类(符合规则)和若干个无效等价类(从各种不同角度违反规则)。
        (5) 如果规定了输入数据为整型，则可以划分出正整数、零和负整数3个有效类。
        (6) 如果程序的处理对象是表格，则应该使用空表，以及含一项或多项的表。

       划分出等价类以后，根据等价类设计测试方案时主要使用下面两个步骤。
       (1)设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止。   
       (2)设计一个新的测试方案，使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都 被覆盖为止

边界值分析

       经验表明，处理边界情况时程序最容易发生错误。例如，许多程序错误出现在下标、数据结构和循环等等的边界附近。因此 ，设计使程序运行在边界情况附近的测试方案，暴露出程序错误的可能性更大一些。
       使用边界值分析方法设计测试方案首先应该确定边界情况， 通常输入等价类和输出等价类的边界。选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值。
       通常设计测试方案时总是联合使用等价划分和边界值分析两种技术。

错误推测

       错误推测法在很大程度上靠直觉和经验进行。它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们选择测试方案。
       经验表明，在一段程序中已经发现的错误数目往往和尚未发现的错误数成正比。例如，在IBM OS/370操作系统中，用户发现的全部错误的47%只与该系统4%的模块有关。因此，在进一步测试时要着重测试那些已发现了较多错误的程序段。
       等价划分法和边界值分析法都只孤立地考虑各个输入数据的测试功效，而没有考虑多个输入数据的组合效应，可能会遗漏了输入数据易于出错的组合情况。
       选择输入组合的一个有效途径是利用判定表或判定树为工具，列出输入数据各种组合与程序应作的动作(及相应的输出结果)之间的对应关系，然后为判定表的每一列至少设计一个测试用例。
       选择输入组合的另一个有效途径是把计算机测试和人工检查代码结合起来

调试

调试过程

       调试（也称为纠错）作为成功测试的后果出现，即调试是在测试发现错误之后排除错误的过程。       
       软件错误的外部表现和它的内在原因之间可能并没有明显的联系。调试就是把症状和原因联系起来的尚未被人深入认识的智力过程。

       调试不是测试。
       调试过程从执行一个测试用例开始，评估测试结果，如果发现实际结果与预期结果不一致，则这种不一致就是一个症状，它表明在软件中存在着隐藏的问题。调试过程试图找出产生症状的原因，以便改正错误。
       调试过程总会有以下两种结果之一：
            ①找到了问题的原因并把问题改正和排除掉了；
           ②没找出问题的原因。 在后一种情况下，调试人员可以猜想一个原因，并设计测试用例来验证这个假设，重复此过程直至找到原因并改正了错误
       调试工作如此困难，软件错误的下述特征也是相当重要的原因   
            (1)症状和产生症状的原因可能在程序中相距甚远，也就是说，症状可能出现在程序的一个部分，而实际的原因可能在与之相距很远的另一部分。紧耦合的程序结构更加剧了这种情况。   
            (2)当改正了另一个错误之后，症状可能暂时消失了。   
            (3)症状可能实际上并不是由错误引起的（例如，舍入误差）。   
            (4)症状可能是由不易跟踪的人为错误引起的。
            (5)症状可能是由定时问题而不是由处理问题引起的。   
            (6)可能很难重新产生完全一样的输入条件（例如，输入顺序不确定的实时应用系统）。   
            (7)症状可能时有时无，这种情况在硬件和软件紧密地耦合在一起的嵌入式系统中特别常见。   
            (8)症状可能是由分布在许多任务中的原因引起的，这些任务运行在不同的处理机上

调试途径

1.蛮干法

• 蛮干法可能是寻找软件错误原因的最低效的方法。仅当所有其他方法都失败了的情况下，才应该使用这种方法。
• 蛮干法按照“让计算机自己寻找错误”的策略，这种方法印出内存的内容，激活对运行过程的跟踪，并在程序中到处都写上 WRITE（输出）语句，希望在这样生成的信息海洋的某个地方发现错误原因的线索。
• 在更多情况下这样做只会浪费时间和精力。在使用任何一种调试方法之前，必须首先进行周密的思考，必须有明确的目的，应该 尽量减少无关信息的数量

 2.回溯法

• 回溯是一种相当常用的调试方法，当调试小程序时这种方法是有效的。具体做法：从发现症状的地方开始，人工沿程序的控制流往回追踪分析源程序代码，直到找出错误原因为止。
• 随着程序规模的扩大，应该回溯的路径数目变得越来越大，回溯法不适用于这种规模的程序。

3.原因排错法   
       对分查找法、归纳法和演绎法都属于原因排除法。

• 对分查找法的基本思路是，如果已经知道每个变量在程序内若干个关键点的正确值，则可以用赋值语句或输入语句在程序中点附近“ 注入”这些变量的正确值，然后运行程序并检查所得到的输出。
• 归纳法是从个别现象推断出一般性结论的思维方法。使用这种方法调试程序时，首先把和错误有关的数据组织起来进行分析，以便发现可能的错误原因。然后导出对错误原因的一个或多个假设，并利用已有的数据来证明或排除这些假设。
• 演绎法从一般原理或前提出发，经过排除和精化的过程推导出结论。采用这种方法调试程序时，首先设想出所有可能的出错原因，然后试图用测试来排除每一个假设的原因

软件可靠性

       软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
       一般说来，对于任何其故障是可以修复的系统，都应该同时使用可靠性和可用性衡量它的优劣程度。
       软件可用性是程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。
      可靠性和可用性之间的主要差别是，可靠性意味着在0到t这段时间间隔内系统没有失效，而可用性只意味着在时刻t，系统是 正常运行的。