小时候对测试不很重视，比如让你做一件事，你会考虑其风险，别的因素吗。当你埋头只顾自己写软件代码，发布软件，就完事啦。但事实并非如此，对方说你的网站有漏洞，或者软件注册码容易破解，这些你并不知道。跟客户打交道，客户不是说做完项目就完事啦，往往要一个月维护。或者测试一下。意外的情况也很多，这些你绝对没想到。软件的bug如何产生的，在你写之前就产生。人的思维并非绝对的。往往是相对的，人们总喜欢自以为是，"I,M GOOD......"但测试离不开实践，不犯错误是不可能的。
软件测试就像给人诊断
软件测试的过程其实很像给人看病的过程
并且最好把全身都检查一遍，以确保没有影响到整个人
软件测试就像是向上帝祷告
你究竟有罪没有，牧师有时会问你有没有罪，求上帝宽恕
按照上帝说：“世人皆有罪，唯有上帝是洁净的”
软件产品代码bug，是存在的。
软件测试就像测试人生
如，一个故事----我为什么没升职
“老板，我有过迟到、早退或乱章违纪的现象吗？”我问。
老板干脆地回答“没有”。
那是公司对我有偏见吗？”老板先是一怔，继而说“当然没有。”
“为什么比我资历浅的人都可以得到重用、而我却一直在微不足道的岗位上？”
老板一时语塞，然后笑笑说：“你的事咱们等会再说，我手头上有个急事，要不你先帮我处理一下？”
一家客户准备到公司来考察产品状况，老板叫我联系他们，问问何时过来。
“这真是个重要的任务。”临出门前，我不忘调侃一句。
一刻钟后，我回到老板办公室。
“联系到了吗？”老板问。
“联系到了，他们说可能下周过来。”
“具体是下周几？”老板问。
“这个我没细问。”
“他们一行多少人。”
“啊！您没问我这个啊！”
“那他们是坐火车还是飞机？”
“这个您也没叫我问呀！”
老板不再说什么了，他打电话叫朱政过来。
朱政比我晚到公司一年，现在已是一个部门的负责人了，他接到了与我刚才相同的任务。
一会儿功夫，朱政回来了。
“哦，是这样的一一”
朱政答道：“他们是乘下周五下午3点的飞机，大约晚上6点钟到，他们一行5人，由采购部王经理带队，我跟他们说了，我公司会派人到机场迎接。另外，他们计划考察两天时间，具体行程到了以后双方再商榷。为了方便工作，我建议把他们安置在附近的国际**，如果您同意，房间明天我就提前预订。还有，下周天气预报有雨，我会随时和他们保持联系，一旦情况有变，我将随时向您汇报。”
朱政出去后，老板拍了我一下说：“现在我们来谈谈你提的问题。”
“不用了，我已经知道原因，打搅您了。”
我突然明白，没有谁生来就担当大任，都是从简单、平凡的小事做起，今天你为自己贴上什么样的标签，或许就决定了明天你是否会被委以重任。
能力的差距直接影响到办事的效率，任何一个公司都迫切需要那些工作积极主动负责的员工。
优秀的员工往往不是被动地等待别人安排工作，而是主动去了解自己应该做什么，然后全力以赴地去完成。
下面谈谈对软件，网站的项目测试
SQL注入测试用例
Drop table. Guess table name and drop it, note the next flowing SQL language
| Select * from A where A.a = ‘testdata’; drop table A---’; |
2. 2. If a field only allow number, give it a String or others
3. Use ‘OR 1=1’, get all records in query function
| Select * from A where A.a = ‘testdata’ OR ‘1’=’1’; |
4. 3. In login function, give user name field like ‘username’--’, “--’ and A.password = ‘’” is commented
| Select * from user A where A.username = ‘username’--’ and A.password = ‘’; |
5. 4. Adding records function, if there is 4 fields in this table, add 5 fields, eg.
| Normal: Insert into table A values(‘’,’’,’’,’’); Test Data: Insert into table A values(‘’,’testdata’,’’,’’,’’); |
6. 5. Input test data in or out of this field data
7. 6. Add single quotation marks and semicolon, and break off string splicing, this is similar with point 4
| Update table A set A.a = ‘testdata’;--’ |
Yellow partis test data we input
web测试--安全性：
（1）表单验证
（2）sql注入
（3）跨站点攻击
（1）表单验证
对所输入的用户名 密码 邮箱@ 手机号（11位）进行验证
（2）sql 注入
如果攻击者的登录的用户名和密码分别是： 空格or 1=1# 密码是 空
select * from users where username=' or 1=1#’ and password=md5('')
在sql中#是注释语
等价与
select * from users where username=' or 1=1
1=1是 true
简单说来就是
select * from users
这样就可以从数据库中提出所有的用户的信息
(3)跨站点攻击
XSS跨站脚本攻击的分类
反射型XSS跨站脚本攻击
源码变成了“<p>欢迎您, <script>alert(/我的名字是张三/)</script>!</p>”，从源代码中我们发现，用户输入 的数据中，<script>与</script>标签中的代码被浏览器执行了，而这并不是网页脚本程序想要的结果。这个例子正是 最简单的一种XSS跨站脚本攻击的形式，称之为反射型XSS。
存储型XSS跨站脚本攻击
存储型XSS脚本攻击最为常见的场景就是在博客或新闻发布系统中，黑客将包含有恶意代码的数据信息直接写入文章或文章评论中，所有浏览文章或评论的用户， 都会在他们客户端浏览器环境中执行插入的恶意代码。如流行的Bo-Blog程序的早期版本中存在对用户提交评论数据过滤不严导致的XSS跨站脚本攻击漏 洞，黑客可以在文章评论中提交插入恶意数据的UBB代码，提交后，Bo-Blog程序会将数据保存至数据库中，当用户浏览该日志时，就会执行插入的恶意代 码，
基于DOM的XSS跨站脚本攻击。
Android项目应用测试
|
/**
* Android Application Testing Guide
*/
package com.example.aatg.test;
import JUnit.framework.TestCase;
/**
*
@author diego
*/
public class MyUnitTests extends TestCase {
private int mFixture;
/**
*
@param name test name
*/
public MyUnitTests(String name) {
super(name);
}
/* (non-Javadoc)
*
@see JUnit.framework.TestCase#setUp()
*/
protected void setUp() throws Exception {
super.setUp();
mFixture = 1234;
}
/* (non-Javadoc)
*
@see JUnit.framework.TestCase#tearDown()
*/
protected void tearDown() throws Exception {
super.tearDown();
}
/**
* Preconditions
*/
public void testPreconditions() {
}
/**
* Test method
*/
public void testSomething() {
fail("Not implemented yet");
}
}
|
因此，在Android应用中，你若测试使用了额外的、有限的资源，比如Services服务或者contentProvides，那么，你应该注意要及时释放掉。在tearDown方法中，严格遵守将对象设置成null的规则，以便及时回收，避免一直占用资源，一直到所有用例跑完才释放。
渗透测试
银行网站测试
银行是网络信息技术应用最密集、应用水平最高的行业之一，基于计算机网络的各类银行信息系统已经成为银行产品的开发推广、银行业务的展开、银行日常管理和决策的所依赖的关键组成部分。这种依赖性使得银行面临着由于网络信息系统本身所带来的银行信息技术风险。
银行信息技术风险的主要挑战来自于基础网络信息技术的复杂性和变化，其中面对互联网主要有以下几个方面风险：
基于网络的电子银行，需要有完善的安全体系架构；
面向Internet的银行业务面临着各种各样的互联网威胁；
远程移动用户接入和内部用户接入Internet，都可能引入不同类型的威胁源；
钓鱼网站对于银行网上业务和企业信誉的损害。
伴随银行业务的发展，原有的网上银行、门户网站等都进行了不同程度的功能更新和系统投产，同时，行内系统安全要求越来越高，可能受到的恶意攻击包括：信息篡改与重放、信息销毁、信息欺诈与抵赖、非授权访问、网络间谍、“黑客”入侵、病毒传播、特洛伊木马、蠕虫程序、逻辑炸弹等。这些攻击完全能造成信息系统瘫痪、重要信息流失。
二、渗透测试的目标
本项目通过渗透测试的方式，模拟黑客的攻击思路与技术手段，达到以下目标：
从攻击者角度，发现网银系统、信用卡网站、门户网站和中间业务等应用系统及网关入口设备存在的安全隐患；
检测对外提供服务的业务系统（如网银系统、信用卡网站、门户网站等）以及行内重要业务系统的威胁防御能力。
深度挖掘渗透测试范围内应用系统各个层面（应用层、网络层、系统层）的安全漏洞；
检验当前安全控制措施的有效性，针对发现的安全风险及时进行整改，增强系统自身防御能力，提升安全保障体系的整体健壮性。
三、渗透测试原则与风险控制原则
遵循规范
渗透测试通过可控的安全测试技术对限定范围内的应用系统进行渗透测试，同时结合以下业界著名的测试框架组合成最佳实践进行操作：
ISECOM制定的开源安全测试方法OSSTMM-v2.2
开放Web应用安全项目OWASP-v3
风险控制
渗透测试过程最大的风险在于测试过程中对业务产生影响，为此我们在实施渗透测试中采取以下措施来减小风险：
● 双方确认
进行每一阶段的渗透测试前，必须获得客户方的书面同意和授权。对于任何渗透测试的对象的变更和测试条件的变更也都必须获得双方的同意并达成一致意见，方可执行。
● 工具选择
为防止造成真正的攻击，在渗透性测试项目中，启明星辰会严格选择测试工具，杜绝因工具选择不当造成的将病毒和木马植入的情况发生。
● 时间选择
为减轻渗透性测试对用户网络和系统的影响，安排在不影响正常业务运作的时间段进行，具体时间主要限制双方协调和商定的时间范围内。
● 范围控制
启明星辰承诺不会对授权范围之外的网络设备、主机和系统进行漏洞检测、攻击测试，严格按照渗透测试范围内限定的应用系统进行测试。
● 策略选择
为防止渗透性测试造成用户网络和系统的服务中断，启明星辰在渗透性测试中不使用含有拒绝服务的测试策略，不使用未经许可的方式进行渗透测试。
● 操作过程审计
为保证测试过程可审计，启明星辰将在测试过程中开启测试工具的审计日志功能，阶段性测试目标测试结束后，会将审计日志提交用户，以便用户监控测试过程。
● 项目沟通
启明星辰建议：在项目实施过程中，除了确定不同阶段的测试人员以外，还要确定各阶段的客户方配合人员，建立双方直接沟通的渠道；项目实施过程中需要客户方人员同时在场配合工作，并保持及时、充分、合理的沟通。
● 系统备份和恢复措施
为避免实际渗透测试过程中可能会发生不可预知的风险，因此在渗透测试前相关管理人员应对系统或关键数据进行备份、确保相关的日志审计功能正常开启，一旦在出现问题时，可以及时的恢复运转。
黑客测试工具
比如 有一个登陆页面， （假如上面有2个textbox, 一个提交按钮。 请针对这个页面设计30个以上的testcase.）
最后的测试，老板会检测你对公司的忠诚度，会不会给你重任，你肯定面临这一测试，否则你干不下去啦。
test，test
其实测试无处不在，比如进入婚姻圣殿前，妻子会对你进行婚姻忠诚度测试，还有牧师的表白。。。。。
你也将又面临一项测试。
好累呀。
I don't know who hold tomorrow
耳边响起徐志摩的诗《再别康桥》
悄悄的来我又悄悄的走了。
adiOS
来源：oschina
链接：https://my.oschina.net/u/183102/blog/637406