Cookies 验证如果系统使用了cookie，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于cookie的使用可以参考浏览器的帮助信息。如果使用B/S结构cookies中存放的信息更多。功能易用性测试完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。
l 单元测试和白盒测试是不同的,虽然单元测试和白盒测试都是关注功能虽然他们都需要代码支持,但是级别不同,白盒测试关注的是类中一个方法的功能是更小的单位,但是完成一个单元测试可能需要N多类,所以说作单元测试需要什么写驱动和稳定桩,比如查询单元是一个查询包包N多的测试类,测试数据,运行他需要提供数据的部分,输入参数和发出命令的驱动等等.是比类大的一个整体进行的.
l 另一个明显的区别是白盒测试不会关注类接口,但是单元测试主要的内容就是类接口测试.
l 不过很多时候是很少区分的,因为这两种技术实现起来有很多相互关联的部分.不过要看你对质量的关注程度来决定.
2.2.2 功能测试边界测试\越界测试技术详述
边界条件
边界条件是指软件计划的操作界限所在的边缘条件.
如果软件测试问题包含确定的边界,那么数据类型可能是:
数值速度字符地址位置尺寸数量
同时,考虑这些类型的下述特征:
第一个/最后一个最小值/最大值
开始/完成超过/在内
空/满最短/最长
最慢/最快最早/最迟
最大/最小最高/最低
相邻/最远
越界测试
通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:
第一个减1/最后一个加1
开始减1/完成加1
空了再减/满了再加
慢上加慢/快上加快
最大数加1/最小数减1
最小值减1/最大值加1
刚好超过/刚好在内
短了再短/长了再长
早了更早/晚了更晚
最高加1/最低减1
l 另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.
2.2.3 状态测试技术
软件可能进入的每一种独立状态;
从一种状态转入另一种状态所需的输入和条件;
进入或退出某种状态时的设置条件及输入结果.
l 具体测试方法可以参考如下:
每种状态至少访问一次;
测试看起来最常见最普遍的状态转换;
测试状态之间最不常用的分支
测试所有错误状态及其返回值
测试随机状态转换
2.2.4 竞争条件测试技术
l 竞争条件典型情形参考如下:
两个不同的程序同时保存或打开同一个文档
共享同一台打印机,通信端口或者其他外围设备
当软件处于读取或者修改状态时按键或者单击鼠标
同时关闭或者启动软件的多个实例
同时使用不同的程序访问一个共同数据库
2.3 负载\压力测试(StressTest)
l 在这里的负载\压力和功能测试中的不同,他是系统测试的内容,是基本功能已经通过后进行的.可以在集成测试阶段,亦可以在系统测试阶段进行.
l 使用负载测试工具进行,虚拟一定数量的用户看一看系统的表现,是否满足定义中的指标.
l 负载测试一般使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的内容都是编写出测试脚本，脚本中一般包括用户一般常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。
l 负载测试技术在各种极限情况下对产品进行测试 (如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。例如，使用压力测试工具对web服务器进行压力测试. 本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用J2EE实现的系统很少但是并不是没有内存问题.
l 覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。
l 该技术可以用在任何测试阶段，包括单元测坏死、集成测试、系统测试。
l 使用该技术时可以使用以上的任何测试方法和测试技术。
3.2 白盒测试和黑盒测试技术
l 白盒测试技术 (White Box Testing)该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用Xunit系列工具进行测试，可以包括很多方面如功能性能等。
l 黑盒测试 (Black Box Testing)测试的主体部分黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行,包括的不同测试类型请参考以上内容。
3.3 手工测试和自动化测试
l 手工测试（Manual Testing）：即依靠人力来查找Bug。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。
l 自动测试（Automation Testing）使用有针对工具实行。可以作出自动化测试的计划,对可以进行自动化测试的部分编写或者录制相应的脚本,可以加入功能,容错,表单提交等,可以参考MI,Rational或者其他类测试工具说明.
l 根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程80％还是手工完成。
l 自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。
3.4 根据RUP标准按阶段区分测试
l 单元测试在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。
l 集成测试分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。
l 系统测试在功能实现的基础上，可以加入兼容性，易用性，性能等等
l 验收测试可以包括Alpha和Beta测试，在这里就不再详述。
4. 存在风险及解决方法
说明：测试不能找出所有的问题，只是尽量将问题在开发阶段解决大多数的问题而已。
测试风险如下：
l 软硬件的测试环境提供上也对测试结果有很大的影响。
l 测试团队的水平，经验，合作效果等
l 整个开发流程对测试的重视程度，测试的进入时间等
l 由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。
5. 软件缺陷的原则
l 软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等
