3.1.19 URL栏的测试探索
URL是浏览器上的一个重要控件。通过URL，可以做如下测试探索：
案例3-19：404 Error网页。
http://www.mywebsite.com是一家公司的网站，测试工程师在浏览器地址栏中输入http://www.mywebsite.com显示网站的首页。然后输入一个该域内肯定不存在的页面：http://www.mywebsite.com/aaaaa.html，发现网站没有对不存在的页面（404 Error）进行设计。
案例3-20：地址栏中的SQL注入测试。
测试工程师得知在www.mywebsite.com网站中有个数据表叫customer，于是他在浏览器URL中输入“http://www.mywebsite.com/file/index.htm?name=&page=123;’drop table customer;”，发现表customer被无情删除了。
案例3-21：需要登录的网站URL测试。
http://www.mywebsite.com/market/index.html页面需要登录后才可访问，测试工程师不登录，直接在浏览器URL中输入http://www.mywebsite.com/market/index.html，发现该网站直接跳转到登录页面，没有发现缺陷。
案例3-22：需要特别权限的网站URL测试。
http://www.mywebsite.com:8080/index.html是网站管理员登录后的首页，不登录系统，直接粘贴http://www.mywebsite.com:8080/index.html到浏览器URL中，出现提示信息：你的身份不合法。于是，测试工程师用普通用户的账号登录，然后试图再粘贴http:// www.mywebsite. com:8080/index.html到浏览器URL中竟然登录成功了，一个很严重的缺陷被发现。
3.1.20 突发事故的测试探索
若一个程序正在进行工作：或许是在备份数据；或许通信系统正在进行通话；或许一个用户正在浏览一个网站…，就在这个时刻，事故发生了，比如事故是停电或者断网，当事故被解除后，系统重新运行，这个时刻要仔细检查整个系统是否仍旧可以启动？各个功能是否可以正常运行？是否存在数据或业务丢失的现象？
案例3-23：支付过程中断网。
这是一个真实的案例：Mr. Smith在某网站用信用卡支付刚买的商品时突然断网，当网络重新连接后，发现$50已经从银行卡上扣除，但是网站上显示商品没有被支付，这$50就无缘无故消失了。
3.1.21 界面链接的测试探索
一个复杂的系统往往存在数十个，甚至上百个页面，这些页面存在互相链接依赖的关系，在浏览某个网站时，点击一个链接，若系统告诉我们这个页面不存在，则是由于界面链接测试没有做好所导致。为了避免这种情形的产生，可以采用如下做法：把所有的页面画在一张纸上，如果A页面有链接，可以链接到B页面中，就从A画一条直线链接到B，在直线B处画一个箭头；同样，如果B页面有链接，可以反向链接到A页面中，就从B再画一条平行于上述直线的直线链接到A，在直线A处画一个箭头。直线、箭头都画好后，选择一个起点页面、一个终点页面，然后设计一条路径，在软件上一步一步地按照计划好的路径进行操作。经过几个这样的路径操作后，图中所有的路径都会被覆盖，软件测试结束。也可以使用目前市场上存在的检查Web页面是否存在空链接的工具，如xenu link sleuth、HTML Link Validator、Web Link Validat等。但是在页面相对少的情况下，建议采用手工的方式比较好，因为经过手工操作，可能会发现另外一些问题。
3.1.22 需要多步操作来完成一个事务的测试探索
有些操作往往需要进行多步操作才可以完成，如提交一份求职简历，第一页填写基本信息、第二页填写教育经历、第三页填写工作经历、最后一页填写其他信息。测试这样的软件产品时，可以尝试提交第一、二、三步后回退到第一步重新输入，观察软件会出现什么情况？再尝试提交第一、二步后放弃提交，退出，然后再一次进入，输入和上次相同的信息，观察软件会出现什么情况？
案例3-24：用户信息的多步骤填写。
如图3-5所示，填写电子商务网站信息分为4步，对应4个页面，原先的顺序应该是：填写基本信息、填写辅助信息、填写收货信息、填写支付信息。通过浏览器上的【回退】键或者其他方式更改输入顺序步骤，如变为填写基本信息、填写辅助信息、返回填写基本信息、填写收货信息、返回填写辅助信息、填写收货信息、填写支付信息。最后看程序会不会有问题，信息是不是会遗漏？
图3-5 用户信息的多步骤填写
3.1.23 老功能的测试探索
产品中旧的功能，很容易被忽视，有人认为这些旧功能早就被测试很多遍，用不着再测试。设想，当其他功能的接口、框架、结构等都进行调整、变化，包括数据库的结构也可能做过相应的调整，这些调整或许会对老功能造成一定程度的影响，所以还需要不时地对老功能进行测试。以便发现一些意想不到的问题。
案例3-25：用户注册。
用户注册功能是产品的旧功能，测试小组成员对这个功能近一年多没有进行全面的测试。上个月刚招了一个新员工小赵，测试经理考虑到小赵刚刚毕业又是测试新手，所以让小赵从基本的模块入手，两天后小赵竟然在注册模块发现了一个缺陷，后经分析发现这个缺陷的引起是由于半年前修改另一个关于用户权限缺陷引起的，修复这个缺陷，加长了数据库表结构，而用户注册页面没有做相应变化。
顾翔凡言：
敏捷具有适用性，即使用了敏捷，也不要做成假敏捷，掌握敏捷的真谛。
