一、防御式编程

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

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

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

2）处理错误输入数据

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

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

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

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

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

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

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

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

9、用最妥当的方式在局部处理错误。

10、关闭程序。

 

二、开发者测试

1）测试方法

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

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

3、用基础测试和数据流测试对代码进行彻底的考验。

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

2）测试先行

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

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

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

3）基础测试

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

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

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

3、遇到每一个case语句就加1，无法case语句没有缺省情况，则再加1。

4）数据流测试

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

1、已定义，数据已经初始化，但还没有使用。

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

3、已销毁，数据曾经定义过，但现在通过某种途径取消了它的定义。

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

1、已进入，控制流已经进入一个子程序，但还没有使用该变量。

2、已退出，对变量产生影响之后，控制流立即退出子程序。

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

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

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

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

5）测试锦囊

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

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

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

6）错误的分类

1、大多数错误的影响范围是相当有限的。

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

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

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

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

7）预期错误的范围

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

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

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

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

8）保留测试记录

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

2、问题的完整描述。

3、复现错误所需要的步骤。

4、绕过该问题的建议。

5、相关的缺陷。

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

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

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

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

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

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

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