防护式编程和开发者测试

　　《代码大全》第8章介绍了防护式编程，这是一种提升软件质量技术的有益辅助手段，其核心思想是：程序不该该传入错误数据而被破坏。第22章介绍了开发者测试，测试是最多见的改善质量的活动，有些测试须要开发人员进行，例如单元测试、组件测试和集成测试。

1、防护式编程

1）检查全部来源于外部的数据（输入参数）

一、对数据进行合法性校验，例如确保数字在可接受的范围内，确保字符串不超长，过滤注入的SQL命令、HTML或XML代码等。

二、在输入数据时将其转换为恰当的类型

2）处理错误输入数据

一、返回中立值，继续执行操做并简单地返回一个没有危害的数值，例如数值能够返回0，字符串返回空等。

二、换用下一个正确的数据，继续读下去直到又找到一条正确记录为止。

三、返回与前次相同的数据。

四、换用最接近的合法值。

五、把警告信息记录到日志文件中，再用电子邮件提醒你。

六、返回一个错误码，例如用语言内建的异常机制抛出一个异常。

七、把错误处理集中在一个全局的子程序或对象中。

八、当错误发生时显示出错消息。

九、用最稳当的方式在局部处理错误。

十、关闭程序。

 

2、开发者测试

1）测试方法

一、对每一项相关的需求进行测试，以确保需求都已经实现。

二、对每个相关的设计关注点进行测试，以确保设计已经被实现。

三、用基础测试和数据流测试对代码进行完全的考验。

四、使用一个检查表，其中记录着你在本项目迄今为止所犯的，以及过去所犯的错误类型。

2）测试先行

一、假如你首先编写测试用例，那么你将更早发现缺陷，也更容易修正它们。

二、首先编写测试用例，将迫使你在开始写代码以前至少思考一下需求和设计。

三、更早地把需求上的问题暴露出来，对于一个糟糕的需求来讲，很难写出测试用例。

3）基础测试

　　思想就是测试程序中的每一条语句至少一次，例如if语句须要根据其表达式的复杂程序来修改测试，以确保这个语句彻底通过了测试。确保覆盖率最简单的方法就是算一算有多少条经过程序的路径，而后据此开发出能经过程序里每条路径的最少数据的测试用例。下面是基础测试用例的数量计算方法：

一、对经过子程序的直路，开始的时候记1。

二、遇到下面的每一个关键字或等价物时，加1：if、while、repeat、for、and以及or。

三、遇到每个case语句就加1，没法case语句没有缺省状况，则再加1。

4）数据流测试

　　所有代码至少有一半是数据声明和初始化，数据的状态有3种：

一、已定义，数据已经初始化，但尚未使用。

二、已使用，数据已经用于计算或其它用途。

三、已销毁，数据曾经定义过，但如今经过某种途径取消了它的定义。

　　对变量进行某种操做以前或以后的状态有：

一、已进入，控制流已经进入一个子程序，但尚未使用该变量。

二、已退出，对变量产生影响以后，控制流当即退出子程序。

　　正常的数据状态的组合是变量已定义，已经一次或屡次使用，而且可能已经销毁。下面是搭配形式：

已定义-已定义，已定义-已退出，已定义-已销毁，已进入-已销毁

已进入-已使用，已销毁-已销毁，已销毁-已使用，已使用-已定义

　　编写数据流测试用例的关键是要对全部可能的定义-使用路径进行测试。测试每个变量的每个定义，对每个变量测试全部在某处定义而在另外一处使用的组合。

5）测试锦囊

一、猜想错误，基于直觉或过去的经验，猜想程序会在哪里出错。

二、边界值分析，测试边界值条件，例如小于、等于或大于。

三、几类坏数据，包括数据太少、太多、无效、长度错误、未初始化等。

6）错误的分类

一、大多数错误的影响范围是至关有限的。

二、许多错误发生在构建的范畴以外，例如频繁变更且相互矛盾的需求，以及沟通和协调的失效。

三、笔误是一个常见的问题根源。

四、程序员错误理解了这条设计。

五、大多数错误很容易修正。

7）预期错误的范围

一、业界的经验，在已发行的软件中平均1000行代码发现1~25个错误。

二、微软的经验，大约每1000行代码有10~20个缺陷，而对于已发布产品则大约是每1000行代码0.5个缺陷。

三、净室开发技术，可得到低至每1000行代码3个缺陷，每1000行代码0.1个缺陷的错误率。

四、团队软件开发过程的开发小组，可达到大约每1000行代码0.06个缺陷。

8）保留测试记录

一、缺陷的描述，包括报告日期、报告人、标题、编号以及修正日期等。

二、问题的完整描述。

三、复现错误所须要的步骤。

四、绕过该问题的建议。

五、相关的缺陷。

六、问题的严重程序，例如致命的、严重的或代表的。

七、缺陷根源：需求、设计、编码仍是测试。

八、对编码缺陷的分类：错误赋值、错误数组下标、子程序调用错误等。

九、修正错误所改变的类和子程序。

十、缺陷所影响的代码行数。

十一、查找该错误所花的小时数。

十二、修正错误所花费的小时数。