单元测试浅析[2] 软件测试
以上三种用例所用的数据又可分为正常数据、边缘数据和错误数据。
· 正常数据：在测试中所用的正常数据的量是最大的，而且也是最关键的。少量的测试数据不能完全覆盖需求，但我们要从中提取出一些具有高度代表性的数据作为测试数据，以减少测试时间。
· 边缘数据：边缘测试是界于正常数据和错误数据之间的一种数据。它可以针对某一种编程语言、编程环境或特定的数据库而专门设定。例如若使用SQL Server数据库，则可把SQL Server关键字(如：';AS;Join等)设为边缘数据。其它边缘数据还有：HTML的HTML;<>等关键字以及空格、@、负数、超长字符等。边缘数据要靠测试人员的丰富经验来制定。
· 错误数据：显而易见，错误数据就是编写与程序输入规范不符的数据从而检测输入筛选、错误处理等程序的分支。
由于执行测试用例的数据量巨大以及还要进行回归测试，所以可以考虑使用自动测试工具，但提取测试数据仍要依靠编写测试用例人员的经验。并且，我们还要注意到自动测试也许不能找到程序中所有错误，手动测试所找到的错误会比自动测试所找到的要多。
有了测试用例，我们就可以进行测试了吧?许多公司也是这样做的，但在这里我建议大家最好要先进行代码的审议。通过代码审议找到的错误可以比测试用例测试所能找到的错误更加深入，并且发现错误的时间也比测试用例要早。代码审议要以代码标准(根各公司具体情况自行制定)为依据，一般情况下要检查以下几点：
· 代码风格和规则审核
· 程序设计和结构的审核
· 业务逻辑的审核
代码风格和规则的审核是在每个程序员完成一个模块或类的 时候要进行编码规范的检查。要召开审核会议让所有的项目组人员都参加。在会前项目经理要做一个检查表，以表的内容为检查依据，检查表的内容主要是检查的要点。在审核会上项目组的每一个人员都能看到自己和其他人员的编码问题，从而起到预防的作用。这些问题都要被解决，并且解决的结果要在审议会上被确认。
进行程序设计和结构的审议是因为开发工具的不同和项目时间的限制而造成设计不详细。比较深入的设计通常是在编码阶段完成的，但由于程序人员和设计人员的经验是不同的，所以会出现很大的问题。我们引入了程序设计和结构审核来保证质量。审核人员要有先进的技术开发经验。在审核之前也要一个审核列表，列出主要几项，如：程序的概要、详细设计。但仅局限于列表是不够的，审议人员 还要审议程序的精巧度和具有创造力的方面，这只能靠经验而不能只靠列表中的内容来审议。对于不同的程序员所检测代码的宽度和深度也是不同的。项目经理可以根据程序员经验的不同制定被审议人员的宽度和深度。例如：年轻的程序员要审议所有代码。但有经验的就可适当减少。
业务逻辑性审议必须要在代码完成后审议。业务逻辑审议实际上是审议单元模块的功能。这些功能是以系统说明为依据的。审议人员要有开发的经验并且对系统也要熟悉。审议人员通过执行程序从而了解底层代码的状态。这阶段的审议实际也包含了前两种审议，因为审议者也可以通过最后的结果检测单元模块设计和结构的准确性。
以上三种审议都要耗费一定的时间和资源，但是它却能更早地发现和解决不易显现的错误。
审议通过后，我们终于可以使用用例来进行代码测试和调试了。代码的调试是用来保证程序能按照系统需求正常运行的一种手段。但是我所提到的这种代码调试并不是简单的调试，它要包括以下两部分：
文章来源于领测软件测试网 https://www.ltesting.net/
