- A+
显示不全请点击全屏阅读
1、问题：没有被验证的输入
测试方法：
数据类型（字符串，整型，实数，等）
允许的字符集
最小和最大的长度
是否允许空输入
参数是否是必须的
重复是否允许
数值范围
特定的值（枚举型）
特定的模式（正则表达式）
2、问题：有问题的访问控制
测试方法：
主要用于需要验证用户身份以及权限的页面，复制该页面的url地址，关闭该页面以后，查看是否可以直接进入该复制好的地址
例：从一个页面链到另一个页面的间隙可以看到URL地址
直接输入该地址，可以看到自己没有权限的页面信息
3、错误的认证和会话管理
分析：帐号列表：系统不应该允许用户浏览到网站所有的帐号，如果必须要一个用户列表，推荐使用某种形式的假名（屏幕名）来指向实际的帐号。
浏览器缓存：认证和会话数据不应该作为GET的一部分来发送，应该使用POST。
4、问题：跨站脚本（XSS）
分析：攻击者使用跨站脚本来发送恶意代码给没有发觉的用户，窃取他机器上的任意资料
测试方法：
HTML标签：<…>…
转义字符：&(&)；<(<)；>(>)； (空格) ；
脚本语言：
特殊字符：‘ ’ < > /
最小和最大的长度
是否允许空输入
例：对Grid、Label、Tree view类的输入框未作验证，输入的内容会按照html语法解析出来
5、缓冲区溢出
分析：用户使用缓冲区溢出来破坏web应用程序的栈，通过发送特别编写的代码到web程序中，攻击者可以让web应用程序来执行任意代码。
6、注入式漏洞
例：一个验证用户登陆的页面， 如果使用的sql语句为：
Select * from table A where username＝’’ + username+’’ and pass word …..
Sql 输入 ‘ or 1＝1 ―― 就可以不输入任何password进行攻击
7、不恰当的异常处理
分析：程序在抛出异常的时候给出了比较详细的内部错误信息，暴露了不应该显示的执行细节，网站存在潜在漏洞，
8、不安全的存储
没有加密关键数据
例：view－source：http地址可以查看源代码
在页面输入密码，页面显示的是 *****, 右键，查看源文件就可以看见刚才输入的密码，
9、拒绝服务
分析：攻击者可以从一个主机产生足够多的流量来耗尽狠多应用程序，最终使程序陷入瘫痪。
需要做负载均衡来对付。
10、不安全的配置管理
分析：Config中的链接字符串以及用户信息，邮件，数据存储信息都需要加以保护
程序员应该作的： 配置所有的安全机制，关掉所有不使用的服务，设置角色权限帐号，使用日志和警报。
每个项目每个Build测试执行过程中如何把握测试主线？
问题，看起来很简单，但是执行起来不容易，有时即使对于有经验的测试人员也很容易在测试过程忽略掉每一轮测试的重点，陷入一个小模块进行详细测试，而忽略了对这轮测试总体测试侧重点的把握。所谓测试主线就是该轮测试我们的测试重点，如冒烟测试我们主要看测试模块主要功能在正常情况下能不能实现，影不影响项目进入系统测试；本地化测试时，当主要功能较稳定时，我们关注的更多的是字符，乱码，拼写，提示信息，标点等等是否已本地化；测试后期我们更多的是验证bug，而不是进行详细的系统测试。实际测试中，我经常看到同事对每轮的测试主线把握的不是太好，如我们公司对每个项目每轮测试都要进行冒烟测试，在冒烟测试问题反馈中，经常看到上报的有些小的控件问题，如按钮没有完全展示出来，输入框对特殊字符及快捷键没有做处理等，这些确实是问题，但是这不是我们进行冒烟测试的初衷；一个项目的最后一个Build有时会看到同事会提好多建议，提建议固然很好，但是我们应该清楚，最后一个Build测试重点一般主要放在验证上轮Bug上，对于建议应该在前几个Build来提，而不是最后一轮，因为最后一轮意味着项目要投向市场，面临着市场压力，即使提了建议，开发人员为了保持主要功能的稳定性及降低风险，一般也不会修改这些建议的。
那么我们如何知道每轮测试的侧重点？拿我们公司来说，每轮测试都会有更新文档和本轮测试重点描述的相关文档；如果没有这方面的文档，这时候就可以去询问测试项目负责人或测试执行负责人。当我们知道该轮测试重点后，结合测试时间，大致划分下每个时间段测试哪些模块，具体执行中牢记本来测试重点，从负责的整个测试模块来把握测试主线，尽量避免被一个小模块拖累了整个项目的测试进度。
哪些属于测试模块的主要功能？对于测试人员有哪些途径去积累判断测试模块的主要功能？
直接与用户接触了解用户使用习惯，了解用户主要关注哪些模块，这些模块这些点就是我们所说的主要功能。（对于我们公司很少有这种机会）
关于1是个很理想的状态，但是大多数情况下，我们测试人员是很少有机会接触到用户的。这个时候可以间隔性的请技术支持或者销售人员给我们介绍用户主要关注哪些模块及哪些问题的出现会使用户非常恼火以及现场问题收集等等，技术支持和销售人员对于用户的了解一般会比我们测试人员多。（这个途径也像老大建议过，但是一直没有做起来，导致现在对现场问题及用户习惯处在模模糊糊的状态）
看需求，这里的需求有产品需求说明书和用户需求说明书，通过需求说明书我们就可以知道用户的需求，优先级等，这些也是我们判断是否是主要功能的依据。
经验，这个主要就看我们对测试模块的熟悉程度。大家可能有这个经验，就是一个模块测试久了，对这个模块的总体把握，哪些相对重要在心里会有大致的区分，这个就要求我们在测试执行过程中，其他时间多了解我们的测试项目，哪些是主线，哪些是次线。（这种途径个人感觉存在一定风险，有时只是自我感觉是不是主要功能，实际上是不是—–）
向以前测试该模块的测试人员学习，询问；向小组领导请教，一般测试领导对模块主要功能的把握比较准
看产品使用说明书，当我们刚接手一个新模块时，还没有对该模块形成所谓的经验，这时候我们可以看看使用说明书，了解该模块，使用说明书一般是技术支持人员来写（我们公司如此，其它公司不太清楚），写的角度也可能是从用户角度出发，对我们对一个模块主要功能的判断有一定的启示意义。
总结：测试过程中，也遇到对主要功能把握不准的情况，请教老员工，老员工说过最多的就是：经验。其实我很反感这句话，对于新人能不能告诉我们掌握主要功能的途径，或者说经验积累的方法，通过哪些途径去积累这些经验，而不是动不动就那经验来显摆，这样才能让新员工快速积累这方面的经验，抓住主要功能，少走些弯路，快速成长起来，这里谴责下这些不负责任的老员工，呵呵
Tags：
如果您喜欢我的博客，欢迎点击图片定订阅到邮箱
也可以点击链接【订阅到鲜果】
如果我的想法或工具帮助到了你，也可微信扫下方二维码打赏本人一杯咖啡
