处理该语句时，SQL Server将首先选择OrdersTable中的所有记录（其中ShipCity为Redmond）。然后，SQL Server将删除OrdersTable。
只要注入的SQL代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造SQL命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。 验证所有输入:
始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：
如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个10 MB的MPEG文件，应用程序会做出什么反应？
如果在文本字段中嵌入了一个DROP TABLE语句，应用程序会做出什么反应？ 测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。
输入字符 在Transact-SQL中的含义 ; 查询分隔符。
' 字符数据字符串分隔符。 -- 注释分隔符。
/* ... */ 注释分隔符。服务器不对/*和*/之间的注释进行处理。 xp_ 用于目录扩展存储过程的名称的开头，如xp_cmdshell。
9. Web测试中书写用例时要考虑的检查点 通常书写Test Case时需要考虑的检查点. 对于屏幕显示来说包括： 检查显示的布局； 检查域和按钮的顺序； 检查域的尺寸；
检查字体的大小和风格； 检查文本的含义； 检查拼写错误； 检查屏蔽域； 检查只读域； 检查图片；
检查按钮的状态； 检查按钮的尺寸；
检查按钮的图标和名字； 检查是否有重复的图标；
检查指针是否在第一个可输入域； 检查TAB键的次序； 对于域来说包括： 检查可编辑性； 检查域间的移动； 检查分界条件； 检查有效分界符；
11
检查无效分界符；
检查连续多个有效分界符； 检查仅一个分界符输入； 检查多余空格的截取；
检查只读域和屏蔽域在TAB时的状态； 对于数字域来说包括： 检查正数值； 检查负数值； 检查零值； 检查小数点；
检查特殊字符加数字； 检查字母加数字； 检查ASCII值； 检查重复值； 检查空值；
对于字符域来说包括： 检查仅有字母； 检查仅有数字； 检查字母数字；
检查允许的特殊字符； 检查禁止的特殊字符；
检查包含特殊字符的字母数字； 检查ASCII值；
对于字母域来说包括： 检查字母； 检查数字值； 检查字母数字值； 检查特殊字符； 检查ASCII值；
对于时间域来说包括： 检查字符?和/；
检查其他特殊字符； 检查字母数字值； 检查正确的格式； 检查错误的格式； 检查错误的日期数字； 检查正确的日期数字； 检查日历表；
10. 手机电子邮件测试用例 序号 测试项目 测试方法 测试标准 12
1 电子邮件设置 IP地址设置 拨号设置(GSM)\\ 节点设置(GPRS) 用户名设置 用户密码设置 默认的为010.000.000.172，自己设置必须设置为010.000.000.172 默认为17266，手动设置必须设置成17266 必须设置为cmwap 如果设置，必须设置为WAP 如果用户名做了设置，此项必须设置为wap 如果需要手动设置必须设置成010.000.000.172 手动设置必须设置成17266 必须设置为cmwap 如果设置必须设置为WAP 如果用户名做了设置，此项必须设置为wap 如果有这两项可选择，必须能够使用。 一般选择不安全 能够成功设置 上网数据模式设置(GPRS/GSM) 端口类型选择 2 用户设置 帐户设置 选择GPRS或GSM方式 可以选择安全和不安全。 将用户的邮箱地址、接收邮件服务器（POP3）、发送邮件服务器（SMTP）、邮箱帐户名以及密码设置完成 下载设置 设置好各个限制项目：如单个信件下能够成功设置 载最大字节、全部信件下载最大字节等等 3 编写新邮件 4 发送邮件 编辑好邮件后，输入对方的电子邮件，按确认键进行发送 选择输入法编写文本，并选择插入的附件（格式为txt/gif/jpg/bmp等） 所有的输入法都能实现，插入附件功能必须实现 邮件能够成功发送并要有保存提示或自动进入已发信箱（如果此功能已经设定） 5 6 回复邮件 7 转发邮件 删除邮件 在邮件列表中，选择某条邮件，按选项菜单，选择删除项，再按确认键。 在邮件列表中选择某条邮件，在选项中选择回复，然后进行编辑，确认后发送。 在收件箱中选择某条邮件，在选项中选择转发，然后进行编辑，并输入第三方的邮箱地址或者从地址簿中选择号码，按确认键进行发送。 能够实现邮件的转发。 能够删除所选邮件 能够实现邮件的回复操作。 11. 记事本与日历的测试用例 序号 测试项目 新建 编辑 测试方法 在记事本中新建一个文本文档。 判定标准 必须能够正常新建一个文档。
1 记事本测试 对新建文档或者已有的文档进行编辑。 必须能够编辑文档，编辑时13
必须能够正确输入汉字、英文、数字、字母、标点符号等。 保存 保存已经编辑的文档。 编辑完成后必须能够保存已编辑的内容。 必须能够删除已经保存的删除 删除已经保存的文档。 文档，删除前必须有确认信息，删除成功与否必须有相应的提示。 新建 在记事本中新建一个日程安排。 必须能够正常新建一个日程。 必须能够编辑文档，编辑时编辑 必须能够正确输入汉字、英对新建文档或者已有的日程进行编辑。 文、数字、字母、标点符号等。 保存 保存已经编辑的日程。 编辑完成后必须能够保存已编辑的内容。 必须能够删除已经保存的删除 2 日程表测试 日程提示设定 设定提示时间、提示模式。 删除已经保存的日程。 文档，删除前必须有确认信息，删除成功与否必须有相应的提示。 必须能够设定日程提示的时间和提醒模式，设定完成后必须能够准时提醒。 必须能够设定当前的时间 和日期，必须保证日程表里的万年历时间准确无误，至时间、日期设定 设定当前时间、日期。 少保证日程表中每年的每个月（阳历与农历）的第一天与最后一天的正确性，另外对应的星期也必须准确。特别需要关注闰年。
12. Web测试总结
13. 让web站点崩溃最常见的七大原因 磁盘已满
导致系统无法正常运行的最可能的原因是磁盘已满。一个好的网络管理员会密切关注磁盘的使用情况，隔一定的时间，就需要将磁盘上的一些负载转存到备份存储介质中（例如磁带）。
日志文件会很快用光所有的磁盘空间。Web服务器的日志文件、SQL*Net的日志文件、JDBC日志文件，以及应用程序服务器日志文件均与内存泄漏有同等的危害。可以采取措施将日志文件保存在与操作系统不同的文件系统中。日志文件系统空间已满时Web服务器也会被挂起，但机器自身被挂起的几率已大大减低。 C指针错误
14
用C或C++编写的程序，如Web服务器API模块，有可能导致系统的崩溃，因为只要间接引用指针（即，访问指向的内存）中出现一个错误，就会导致操作系统终止所有程序。另外，使用了糟糕的C指针的Java模拟量（analog）将访问一个空的对象引用。Java中的空引用通常不会导致立刻退出JVM，但是前提是程序员能够使用异常处理方法恰当地处理错误。在这方面，Java无需过多的关注，但使用 Java对可靠性进行额外的度量则会对性能产生一些负面影响。 内存泄漏
C/C++程序还可能产生另一个指针问题：丢失对已分配内存的引用。当内存是在子程序中被分配时，通常会出现这种问题，其结果是程序从子程序中返回时不会释放内存。如此一来，对已分配的内存的引用就会丢失，只要操作系统还在运行中，则进程就会一直使用该内存。这样的结果是，曾占用更多的内存的程序会降低系统性能，直到机器完全停止工作，才会完全清空内存。
解决方案之一是使用代码分析工具（如Purify）对代码进行仔细分析，以找出可能出现的泄漏问题。但这种方法无法找到由其他原因引起的库中的泄漏，因为库的源代码是不可用的。另一种方法是每隔一段时间，就清除并重启进程。Apache的Web服务器就会因这个原因创建和清除子进程。
虽然Java本身并无指针，但总的说来，与C程序相比， Java程序使用内存的情况更加糟糕。在Java中，对象被频繁创建，而直到所有到对象的引用都消失时，垃圾回收程序才会释放内存。即使运行了垃圾回收程序，也只会将内存还给虚拟机VM，而不是还给操作系统。结果是：Java程序会用光给它们的所有堆，从不释放。由于要保存实时（Just In Time，JIT）编译器产生的代码，Java程序的大小有时可能会膨胀为最大堆的数倍之巨。
还有一个问题，情况与此类似。从连接池分配一个数据库连接，而无法将已分配的连接还回给连接池。一些连接池有活动计时器，在维持一段时间的静止状态之后，计时器会释放掉数据库连接，但这不足以缓解糟糕的代码快速泄漏数据库连接所造成的资源浪费。 进程缺乏文件描述符
如果已为一台Web服务器或其他关键进程分配了文件描述符，但它却需要更多的文件描述符，则服务器或进程会被挂起或报错，直至得到了所需的文件描述符为止。文件描述符用来保持对开放文件和开放套接字的跟踪记录，开放文件和开放套接字是Web服务器很关键的组成部分，其任务是将文件复制到网络连接。默认时，大多数shell有64个文件描述符，这意味着每个从shell启动的进程可以同时打开64个文件和网络连接。大多数shell都有一个内嵌的 ulimit命令可以增加文件描述符的数目。 线程死锁
由多线程带来的性能改善是以可靠性为代价的，主要是因为这样有可能产生线程死锁。线程死锁时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。我们来想像这样一种情形：在人行道上两个人迎面相遇，为了给对方让道，两人同时向一侧迈出一步，双方无法通过，又同时向另一侧迈出一步，这样还是无法通过。双方都以同样的迈步方式堵住了对方的去路。假设这种情况一直持续下去，这样就不难理解为何会发生死锁现象了。
解决死锁没有简单的方法，这是因为使线程产生这种问题是很具体的情况，而且往往有很高的负载。大多数软件测试产生不了足够多的负载，所以不可能暴露所有的线程错误。在每一种使用线程的语言中都存在线程死锁问题。由于使用Java进行线程编程比使用C容易，所以 Java程序员中使用线程的人数更多，线程死锁也就越来越普遍了。可以在Java代码中增加同步关键字的使用，这样可以减少死锁，但这样做也会影响性能。如果负载过重，数据库内部也有可能发生死锁。
15