1. 概述
随着web应用的增多，新的模式解决方案中以web为核心的应用也越来越多，很多公司各种应用的架构都以B/S及web应用为主，但是有关WEB测试方面的内容并没有相应的总结，所以我在这里对web的测试方法和采用的测试技术进行总结，便于内部交流。
测试方法尽量涵盖web程序的各个方面，测试技术方面在继承传统测试技术的技术上结合web
应用的特点。
相关的测试和实现技术也有着很大的关系，由于本公司使用J2EE体系，也许例子中只有JAVA 平台可以使用，.NET平台测试技术暂时不涉及，如果你有请与我联系。
2. 测试方法
说明：测试方法的选择取决你的测试策略。
一般的web测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。
当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意、。
有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。
2.1界面测试
现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很
重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为
这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你
会明白的。
方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的HTML CSS等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面/框架。注意不要靠程序员的美术素养形成你的web风格, 那样可能会很糟糕。
主要包括以下几个方面的内容：
站点地图和导航条位置、是否合理、是否可以导航等内容布局布局是否合理，滚动条等简介说明
说明文字是否合理，位置，是否正确
背景/色调是否正确、美观，是否符合用户需求；
页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式
大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等
连接连接的形式，位置，是否易于理解等web测试的主要页面元素
页面元素的容错性列表（如输入框、时间列表或日历）
页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
页面元素的容错性是否存在
页面元素的容错性是否正确
页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
页面元素是否显示正确（主要针对文字、图形、签章）
元素是否显示（元素是否存在）
页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
测试技术
通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显
示效果，如果有影响应该交给设计人员提岀解决方案。
可以结合数据定义文档查看表单项的内容，长度等信息。
对于动态生成的页面最好也能进行浏览查看。如Servelet部分可以结合编码规范，进行代码走
查。是否支持中文，如果数据用XML封装要做的工作会多一点等等。
界面测试要素：
符合标准和规范，灵活性，正确性，直观性，舒适性，实用性，一致性
1. 直观性：
用户界面是否洁净，不唐突，不拥挤.界面不应该为用户制造障碍.所需功能或者期待的响应应该
明显，并在预期岀现的地方.
界面组织和布局合理吗？是否允许用户轻松地从一个功能转到另一个功能？下一步做什么明显吗？
任何时刻都可以决定放弃或者退回，退岀吗？输入得到承认了吗？菜单或者窗口是否深藏不露？有多余功能吗？软件整体抑或局部是否做得太多？是否有太多特性把工作复杂化了？是否感到信息太庞杂？
如果其他所有努力失败,帮助系统真能帮忙吗？
2. 一致性
快速键和菜单选项.在Windows中按F1键总是得到帮助信息
术语和命令.整个软件使用同样的术语吗？特性命名一致吗？例如,Find是否一直叫Find,而不是
有时叫Search?
软件是否一直面向同一级别用户？带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的
错误提示信息.
按钮位置和等价的按键.大家是否注意到对话框有0K按钮和Cancle按钮时，0K按钮总是在上方
或者左方，而Cancle按钮总是在下方或右方？同样原因,Cancle按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter.保持一致.
3. 灵活性
状态跳转.灵活的软件实现同一任务有多种选择方式
状态终止和跳过，具有容错处理能力.
数据输入和输岀.用户希望有多种方法输入数据和查看结果.例如，在写字板插入文字可用键盘输入，粘贴，从6种文件格式读入,作为对象插入，或者用鼠标从其他程序拖动.
4. 舒适性
恰当.软件外观和感觉应该与所做的工作和使用者相符
错误处理.程序应该在用户执行严重错误的操作之前提出警告，并允许用户恢复由于错误操作导
致丢失的数据.如大家认为undo /redo 是当然的.
性能.快不见得是好事.要让用户看得清程序在做什么，它是有反应的.
2.2功能测试
对功能测试是测试中的重点主要包括一下几个方面的内容连接这个连接和界面测试中的连接不同那里注重的是连接方式和位置，如是图像还是文字放置的
位置等，还是其他的方式。这里的连接注重功能。如是否有连接，连接的是否是说明的位置等。
表单提交应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务
器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。B/S结构实现的功能可能主要的就在这里，提交数据，处
理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。
Cookies验证如果系统使用了cookie，测试人员需要对它们进行检测。如果在cookies 中保存
了注册信息，请确认该cookie 能够正常工作而且已对这些信息已经加密。如果使用cookie 来
统计次数，需要验证次数累计正确。关于cookie的使用可以参考浏览器的帮助信息。如果使用
B/S结构cookies中存放的信息更多。功能易用性测试完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满
意度也是很有帮助的。
测试技术功能测试的测试技术可是很多的，我们可以结合实际环境选择使用
白盒测试技术(White Box Testing) 深入到代码一级的测试，使用这种技术发现问题最早，效果
也是最好的。该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟
悉程度，对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在JAVA平台使用Xunit系列工具
进行测试，Xunit测试工具是类一级的测试工具对每一个类和该类的方法进行测试。
黑盒测试技术(Black Box Test ing )黑盒测试的内容主要有以下几个方面，但是主要还是功能
部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面
面，可以考虑以下方面
正确性(Correctness):计算结果，命名等方面？
可用性(Usability) :是否可以满足软件的需求说明。
边界条件(Boundary Condition) 输入部分的边界值，就是使用一般书中说的等价类划分，试试最大最小和非法数据等等.
性能(Performanee) 正常使用的时间内系统完成一个任务需要的时间，多人同时使用的时候响
应时间，在可以接受范围内.J2EE技术实现的系统在性能方面更是需要照顾的，一般原则是3秒以下接受，3-5秒可以接受,5秒以上就影响易用性了.如果在测试过程中发现性能问题，修复起来
是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开
发的开始阶段，就要考虑到软件的性能问题。
压力测试(Stress) 多用户情况可以考虑使用压力测试工具，建议将压力和性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具，查看服务器CPU使用率，内存占用情况，如果有必要可以模拟大量数据输入，对硬盘的影响等等信息.如果有必要的话必须进行性能优化
(软硬件都可以).这里的压力测试针对的是某几项功能.
错误恢复(Error Recovery) 错误处理，页面数据验证,包括突然间断电，输入脏数据等.
安全性测试(Security) 这个领域正在研究中，不过防火墙，补丁包.杀毒软件等的就不必说了，不过可以考虑破坏性测试时任意.看了一些资料后得知，这里面设计到的知识“内容可以写本书了，不是一两句可以说清的，特别是一些商务网站，或者跟钱有关，或者和公司秘密有关的web更是，需要这方面的测试，在外国有一种专门干这一行的人叫安全顾问，可以审核代码，提出安全建议，岀现紧急事件是的处理办法等，在国内没有听说哪里有专门搞安全技术测试的内容兼容性(Compatibility) 不同浏览器，不同应用程序版本在实现功能时的表现，不同的上网方式如果你测试的是一个公共网站的话.
兼容性测试内容详述
硬件平台
浏览器软件和版本：浏览器插件，浏览器选项，视频分辨率和色深.文字大小，调制解调器速率. 软件配置(Configuration) 如IE浏览器的不用选项-安全设定最高，禁用脚本程序，等等，你们的程序在各种不用的设
置下表现如何
单元测试技术（Unit Test）:
221下面是对白盒测试和单元测试的区别的论述：
单元测试和白盒测试是不同的，虽然单元测试和白盒测试都是关注功能虽然他们都需要代码支持但是级别不同，白盒测试关注的是类中一个方法的功能是更小的单位，但是完成一个单元测试可
能需要N多类，所以说作单元测试需要什么写驱动和稳定桩，比如查询单元是一个查询包包N多的测试类，测试数据，运行他需要提供数据的部分，输入参数和发出命令的驱动等等.是比类大的一
个整体进行的.
另一个明显的区别是白盒测试不会关注类接口，但是单元测试主要的内容就是类接口测试
不过很多时候是很少区分的，因为这两种技术实现起来有很多相互关联的部分.不过要看你对质
量的关注程度来决定.
2.2.2 功能测试边界测试“越界测试技术详述
边界条件
边界条件是指软件计划的操作界限所在的边缘条件
如果软件测试问题包含确定的边界，那么数据类型可能是：
数值速度字符地址位置尺寸数量
同时，考虑这些类型的下述特征：
第一个/最后一个最小值/最大值开始/完成超过/在内空/满最短/最长
最慢/最快最早/最迟最大/最小最高/最低相邻/最远越界测试
通常是简单加1或者很小的数（对于最大值）和减少1或者很小的数（对于最小值），例如：第一个减1/最后一个加1
开始减1/完成加1 空了再减/满了再加慢上加慢/快上加快最大数加1/最小数减1 最小值减1/最大值加1 刚好超过/刚好在内短了再短/长了再长早了更早/晚了更晚最高加1/最低减1
另一些该注意的输入：默认，空白，空值,零值和无；非法，错误,不正确和垃圾数据.
2.2.3 状态测试技术
软件可能进入的每一种独立状态；
从一种状态转入另一种状态所需的输入和条件；
进入或退岀某种状态时的设置条件及输入结果
具体测试方法可以参考如下：
每种状态至少访问一次；测试看起来最常见最普遍的状态转换；
测试状态之间最不常用的分支 测试所有错误状态及其返回值 测试随机状态转换 224 竞争条件测试技术 竞争条件典型情形参考如下
：
两个不同的程序同时保存或打开同一个文档 共享同一台打印机，通信端口或者其他外围设备 当软件处于读取或者修改状态时按键或者单击鼠标 同时关闭或者启动软件的多个实例 同时使用不同的程序访问一个共同数据库 2.3负载“压力测试(StressTest)
在这里的负载“压力和功能测试中的不同，他是系统测试的内容，是基本功能已经通过后进行的 .
可以在集成测试阶段，亦可以在系统测试阶段进行
.
使用负载测试工具进行，虚拟一定数量的用户看一看系统的表现 ，是否满足定义中的指标.
负载测试一般使用工具完成，
loadrunner ，webload ，was, ewl ，e-test 等，主要的内容都是编
写岀测试脚本，脚本中一般包括用户一般常用的功能，然后运行， 得岀报告。所以负载测试包括
的主要内容就不介绍了。
负载测试技术在各种极限情况下对产品进行测试
(如很多人同时使用该软件，或者反复运行该软
件)，以检查产品的长期稳定性。例如，使用压力测试工具对 web 服务器进行压力测试.本项测
试可以帮助找到一些大型的问题，如死机、
崩损、内存泄漏等，因为有些存在内存泄漏问题的程
序，在运行一两次时可能不会岀现问题，但是如果运行了成千上万次， 内存泄漏得越来越多， 就
会导致系统崩滑。用 J2EE 实现的系统很少但是并不是没有内存问题 无论什么工具基本的技术都是利用线程技术模仿和虚拟用户， 在这里主要的难点在与测试脚本的
编写，每种工具使用的脚本都不一样， 但是大多数工具都提供录制功能就算是不会编码的测试人
员同样可以测试。
对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用 72小时测试的程序一般不会岀现稳定性的问题。
Bug 重新进行测试，看该 Bug 是否会重新岀现。 无论是单元测试还是集成测试还是系统测试。 是对以 Bug 不会再岀现。实际上，许多Bug 都是在回归测试时
发现的，在此阶段，我们首先要检查以前找到的 Bug 是否已经更正了。值得注意的是，已经更
正的Bug 也可能又回来了，有的
Bug 经过修改之后可能又产生了新的
Bug 。所以，回归测试可
保证已更正的 Bug 不再重现，不产生新的 Bug 。
2.5 Alpha 和 Beta 测试(Alpha and Beta Test):
在正式发布产品之前往往要先发布一些测试版，让用户能够反馈岀相关信息，或者找到存在的 Bug ，以便在正式版中得到解决。
特别是在有客户参加的情况下， 对系统进行测试可能会出现一些我们没有考虑的情况，
还可以解
决一些客户实际关心的问题
100 的 Load Size 连续
使用24小时，微软定义的通过准则是通过 2.4 回归测试(Regression Test)
过一段时间以后，再回过头来对以前修复过的 回归测试技术可以在测试的各个阶段岀现， 前问题进行验证的过程。
回归测试的目的就是保证以前已经修复的
3不同的测试技术区分
3.1覆盖测试技术
说明：测试覆盖率可以看出测试的完成度，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。
覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖(可以理解成流程图的
路径覆盖)。
该技术可以用在任何测试阶段，包括单元测坏死、集成测试、系统测试。
使用该技术时可以使用以上的任何测试方法和测试技术。
3.2白盒测试和黑盒测试技术
白盒测试技术(White Box Testi ng) 该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码
的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用Xu nit 系列工具进行测试，可以包括很多方面如功能性能等。
黑盒测试(Black Box Testi ng)测试的主体部分黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，包括的不同测试类型请参考以上内容。
3.3手工测试和自动化测试
手工测试(Manual Testing ):即依靠人力来查找Bug。方法可以参考上边的测试，也可以根据
对实现技术及经验等进行不同的测试。
自动测试(Automation Testi ng )使用有针对工具实行。可以作岀自动化测试的计划，对可以进行自动化测试的部分编写或者录制相应的脚本，可以加入功能，容错，表单提交等，可以参考
MI,Ratio nal 或者其他类测试工具说明.
根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。
微软的测试过程80 %还是手工完成。
自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。
3.4根据RUP标准按阶段区分测试
单元测试在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。
集成测试分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调
用的影响等，使用方法可以任意选用上面的内容。注重功能方面。
系统测试在功能实现的基础上，可以加入兼容性，易用性，性能等等
验收测试可以包括Alpha和Beta测试，在这里就不再详述。
4. 存在风险及解决方法
说明：测试不能找岀所有的问题，只是尽量将问题在开发阶段解决大多数的问题而已。
测试风险如下：
软硬件的测试环境提供上也对测试结果有很大的影响。
测试团队的水平，经验，合作效果等
整个开发流程对测试的重视程度，测试的进入时间等
由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。
5. 软件缺陷的原则
软件缺陷区别于软件bug,它是在测试过程中岀现的对系统有影响的，但是在设计中没有的或者
对修改后的bug测试和开发人员有不同意见等
软件未达到产品说明书标明的功能。 软件出现了产品说明书指明不会出现的错误。 软件功能超出产品说明书指明范围。
软件未达到产品说明书虽未指出但应达到的目标。
软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 6. 文档测试
产品说明书属性检查清单
完整.是否有遗漏和丢失？完全吗？单独使用是否包含全部内容 ？
准确.既定解决方案正确吗 ？目标明确吗？有没有错误？
精确，不含糊，清晰.描述是否一清二楚？还是自说自话？容易看懂和理解吗？ 一致.产品功能能描述是否自
相矛盾
，与其他功能有没有冲突 ？
贴切.描述功能的陈述是否必要 ？有没有多余信息？功能是否原来的客户要求 ？ 合理.在特定的预算和进度下，以现有人力，物力和资源能否实现 ？ 代码无关.是否坚持定义产品，而不是定义其所信赖的软件设计 ，架构和代码？ 可测试性.特性能否测试？测试员建立验证操作的测试程序是否提供足够的信息
产品说明书用语检查清单
明书上找岀这样的用语，仔细审视它们在文中是怎样使用的 也可能含糊其词----无论是哪一种情况都可视为软件缺陷 总是，每一
种，所有，没有,从不.如果看到此类绝对或肯定的 着手设计针锋相对的案例.
当然，因此，明显，显然，必然.这些话意图诱使接受假定情况 .不要中了圈套
某些，有时，常常，通常，惯常，经常，大多,几乎.这些话太过模糊."有时“发生作用的功能无法测 试. 等等，诸如此类，依此类推.以这样的词结束的功能清单无法测试 .功能清单要绝对或者解释明确
，
以免让人迷惑，不知如何推论.
良好，迅速，廉价,高效，小，稳定.这些是不确定的说法，不可测试.如果在产品说明书中岀现 ，就必 须进一步指明含义.
已处理，已拒绝，已忽略，已消除.这些廉洁可能会隐藏大量需要说明的功能
如果… 那么...（没有否则）.找岀有“如果… 那么…"而缺少配套的"否则“结构的陈述.想一想- 如果"没有发生会怎样.
说明对问题的描述通常表现为粉饰没有仔细考虑的功能
----可归结于前文所述的属性 .从产品说
.产品说明书可能会为其掩饰和开脱 ,切实认定的叙述，软件测试员就可以
XXX项目测试总结报告 目录 1.项目测试结果 (2) 1.1 BUG严重程度 (2) 1.2 BUG问题分布状况 (3) 2.测试结论 (4) 2.1界面测试 (4) 2.2功能测试 (4) 2.3兼容性测试(Windows下) (4) 2.4易用性 (4) 2.5 负载/压力测试 (5) 3.软件问题总结与分析 (6) 4.建议 (7)
1.项目测试结果 1.1 BUG严重程度 测试发现的bug主要集中在次要功能和轻微，属于一般性的缺陷，但测试的时候出现了37个主逻辑级别的bug,以及严重级别的2个.
1.2 BUG问题分布状况 由上图可以看出，主要为代码错误占36%,以及标准规范的问题占35%,界面优化占17%,设计缺陷占9%,其他占2%
2.测试结论 2.1界面测试 网站系统实现与设计稿一致。站点的导航条位置，导航的内容布局，首页呈现的样式与需求一致。网站的界面符合标准和规范，直观性强。 2.2功能测试 分不同账号总权限账号,以及店长账号分别进行功能测试。 1:链接测试无问题,不存在死链接,测试链接都存在. 2:对页面各个不同数据的测试,主要的出入库,销售报表,订单查看管理等一一对应,不存在数据有误差的问题. 2.3兼容性测试(Wind ows下) 测试总的浏览器包括:360极速浏览器,火狐浏览器,谷歌浏览器,IE浏览器,测试通过,主要逻辑以及次要功能都没问题,因为浏览器的不同,导致界面浏览不一定相同,例如有的界面浏览页面显示正常,有的界面显示不一样 。 2.4易用性 网站实现了如下易用性： 1. 输入限制的正确性 2. 输入限制提示信息的正确性，可理解性，一致性 3. 界面排版美观 4. web应用系统易于导航，直观 5. web应用系统的页面结构、导航、菜单、连接的风格一致
Web测试技巧 一.目的： web测试是测试组最频繁接触的工作类型，本文档会从测试案例的分析入手，通过一些比较常见的案例分析，达到了解web测试的基本思想。 分析的测试案例主要包括一下几个方面：普通注册页面，跳转注册页面，用户权限和安全性，碎片，cache，ie相关置对测试的影响。 二. 测试案例分析 1. 普通注册页面： a. 不填写任何的信息，提交，查看提示信息 这个步骤是输入判断测试中第一个要写测案例，这个案例有几个方面的意义 a)这个页面上所有的输入框有必填的选项，比如用户的名称，用户的验证码，用户 密码等，这些信息在数据库中不能为空，如果为空可能会对相关的程序带来问题， 比如 b)不填写用户名和密码，这样就在数据库中存了一条空记录，导致在登陆的时候， 不能正确的验证用户的身份。 c)一些输入框在本页可以不填写不会出错，但是他的数据要被其他的程序调用，比 如cms中的媒体管理，建立的媒体会在建立新闻的时候被调用，如果在媒体管理 里没有做输入判断，那创建时就不能正确的取到数据（逻辑相关性） d)webmail页面中，地址簿可以保存地址，发信页面也可以调用地址簿的信息进行发 信，在测试的时候就需要注意测试相关性。 b. 依次只填写每一个框，提交，查看提示信息 1. 这个案例主要是考察非空判断的每一个框的提示信息是不是按顺序提示，比如三个 必填输入框，不填写第一个和第二个输入框，提示应该是第一个输入框没有填写，不会提示第二个输入框没有填写。填写第二个，不填写一，三输入框，应该提示第一个没有填写，不会提示第三个输入框没有填写，这个提示一般以js check的方式表示 2. 也有例外的情况，就是所有的输入框在一起判断，在一个页面上对没有输入的必 填框在一起显示提示信息，俱乐部的注册页就是这个模式，在每一个没有填写的输入框后面都有提示 c. 依次不填写每一个输入框，提交，查看提示信息 1. 这个是对每一个输入框，一个个的做非空判断，查看是否正确，要一个一个的考察 提示信息是否正确 2. 要注意的是有一些提示信息是假的，比如提示的信息是不能为空，但是确定后确提 交了这个表单。
渗透测试的两大阶段 渗透测试不能测试出所有可能的安全问题，它只是一个特定环境下才合适的WEB应用安全测试技术。OWASP的渗透测试方法是基于墨盒方法的，测试人员在测试前不知道或只知道很有限的关于被测试应用的信息。 渗透测试被分成两大阶段： ■ 被动模式阶段 在这个阶段，测试人员试图去理解被测应用的逻辑，并且去使用它。可以使用工具去收集信息，例如，可以用HTTP代理工具去观察所有请求与响应。本阶段结束后，测试人员应该理解了应用的所有访问点（如，HTTP报头、参数和COOKIE）。信息收集一节将介绍如何进行被动模式的测试。 ■ 主动模式阶段 这个阶段里，测试人员将利用后述的9大类66种方法主动地去测试。 被动模式阶段 信息收集 安全评估的第一步是收集尽可能多的关于被测应用的信息。信息收集是渗透测试的必要步骤。通常使用公共工具（搜索引擎）、扫描器、发送简单或特别的HTTP请求等来迫使被测应用泄漏信息。 ◆使用蜘蛛、机器人和爬虫 目标是浏览和捕获被测应用相关的资源。 ◆搜索引擎发现与侦察 类似GOOGLE这样的搜索引擎可以用来发现被测应用中已经被公开的错误页面或WEB应用结构问题。 ◆识别应用入口点 枚举被测应用及其攻击面是展开任何攻击的的一个关键性前提。 ◆测试WEB应用指纹 应用指纹是信息收集的第一步。知道正在运行的WEB服务器的版本和类型后，测试人员可以确定已知的漏洞和测试过程中的相应攻击方法。获取WEB应用指纹的自动化工具Httprint和在线工具Netcraft。 ◆应用发现 应用发现是一项面向驻留在WEB/应用服务器中的WEB应用识别的活动。这种分析很重要，因为没有一个链接直接连接到主要应用的后端。分析可以发现有助于揭示诸如用于管理目的的WEB应用程序的细节。此外，它可以揭示诸如取消删除的，过时的脚本文件，这些文件通常是在测试、开发或维护过程产生的。可能使用到的工具： 1、DNS查询工具，如nslookup，dig等。
5.4.2测试结果分析 LoadRunner性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web服务器资源、数据库服务器资源等几个方面分析，如图5- 1所示。性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向。我们回顾一下本次性能测试的目的，正如错误！未找到引用源。所列的指标，本次测试的要求是验证在30分钟内完成2000次用户登录系统，然后进行考勤业务，最后退出，在业务操作过程中页面的响应时间不超过3秒，并且服务器的CPU 使用率、内存使用率分别不超过75%、70%，那么按照所示的流程，我们开始分析，看看本次测试是否达到了预期的性能指标，其中又有哪些性能隐患，该如何解决。 图5- 1性能测试结果分析流程图 结果摘要 LoadRunner进行场景测试结果收集后，首先显示的该结果的一个摘要信息，如图5- 2所示。概要中列出了场景执行情况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Responses Summary（HTTP响应摘要）”等。以简要的信息列出本次测试结果。 图5- 2性能测试结果摘要图
场景执行情况 该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图5- 3所示。从该图我们知道，本次测试从15:58:40开始，到16:29:42结束，共历时31分2秒。与我们场景执行计划中设计的时间基本吻合。 图5- 3场景执行情况描述图 Statistics Summary（统计信息摘要） 该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图5- 4所示。从该图我们得知，本次测试运行的最大并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。 图5- 4统计信息摘要图 Transaction Summary（事务摘要） 该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况，如图5- 5所示。从该图我们得到每个Action的平均响应时间与业务成功率。
APP渗透测试方案 2016-7-29 XXXXX公司
目录 1 App渗透简介 (3) 2 APP渗透测试所用工具 (3) 2.1 代理抓包工具 (3) 2.2 反编译工具 (3) 2.3 其他针对服务端的web渗透工具 (4) 3 APP渗透测试的方法 (5) 3.1 数据包分析、测试 (5) 3.2 APP反编译还原代码 (5) 4 APP渗透测试流程 (5) 4.1 项目启动 (5) 4.1.1 项目启动准备 (5) 4.1.2 实施方案制定 (6) 4.2 项目实施 (6) 4.2.1 信息收集 (6) 4.2.2 平台使用不当的测试 (6) 4.2.3 不安全的数据存储的测试 (6) 4.2.4 不安全的通信的测试 (7) 4.2.5 不安全的身份验证的测试 (7) 4.2.6 加密不足的测试 (7) 4.2.7 不安全的授权的测试 (7)
4.2.8 客户端代码质量问题的测试 (7) 4.2.9 代码篡改的测试 (7) 4.3 项目收尾 (8) 4.3.1 报告编写 (8) 4.3.2 问题复查 (8)
1App渗透简介 移动app大多通过web api服务的方式跟服务端交互，这种模式把移动安全跟web安全绑在一起。移动app以web服务的方式跟服务端交互，服务器端也是一个展示信息的网站，常见的web漏洞在这也存在,比如说SQL注入、文件上传、中间件/server漏洞等。 2APP渗透测试所用工具 2.1代理抓包工具 ?Burpsuit ?Fiddler 代理抓包工具主要用于抓取、分析、篡改APP与服务端之间的交互数据包。 爆破、解编码、执行会话令牌等作用。 2.2反编译工具 APP的反编译有两种反编译方式，dex2jar和apktool，两个工具反编译的效果是不一样的，dex2jar反编译出java源代码，apktool反编译出来的是java 汇编代码。 ?工具1：dex2jar+jdgui ?工具2：apktool 工具1反编译出来的是java源代码，易读性比较高。
软件测试之Web测试和App测试重点总结 随着互联网发展，web与APP的快速发展，使得各个互联网公司都想通过APP与web 结合，开发适合大家使用的软件，同时使得公司壮大及发展，然而一个好的app和web 离不开好的测试，现在我将web与app的测试点总结如下，供大家参考： 一、WEB测试重点 1.功能测试： 所实现的功能是否和需求一致； 2.界面测试： 界面是否美观，风格是否一致，文字内容是否正确； 3.链接测试： 打开链接速度是否合理；是否链接到正确的页面；是否有空白页面； 4.性能测试： 系统能支持多少用户同时在线；超过这些用户数，系统会给出什么样的反映； 5.兼容性测试： 项目在不同操作系统，不同浏览器上功能是否能正常使用； 6.安全性测试： 用户的登录名和密码在传输过程中是否是加密传输的； 用户长时间未操作页面，session会话是否会过期，要求用户重新登录； 日志文件cookies里的用户名和密码是否是加密的； 登录次数和登录设备是否有限制，是否支持一个账号多个设备登录； 二、APP测试重点 1.安装卸载测试： app在不同的操作系统（安卓和ios），不同的版本，不同的机型上是否都能安装成功； 在安装过程中，突然断网或网络不好，是否给出有好的提示，网络恢复之后是否能正常下载； 在安装过程中，突然内存不足，是否有相应的提示； 在安装过程中，是否支持取消操作； 在安装过程中，突然死机，断电，卡死，手机恢复正常后，是否能正常安装； 安装成功后能否正常运行 卸载时在不同系统，不同版本上能够卸载成功； 在卸载过程中是否支持取消操作； 在卸载过程中，突然死机，断电，卡死，手机恢复正常后，是否能正常卸载； 卸载完成之后，查看文件是否卸载干净； 2.运行测试： 运行过程中，是否有加载提示； 运行速度是否流畅；
一、测试流程 所有测试的流程大体上是一致的：开始测试前准备-->需求分析-->测试设计（测试计划，测试用例）-->执行测试--> 提交BUG-->测试总结。 对于web测试，较之其他软件测试又有所不同，这是细节的不同，这个不同需要我们在不停的测试中去总结 web测试正式测试之前，应先确定如何开展测试，不可盲目的测试。一般网站的测试，应按以下流程来进行： 1）使用HTML Link Validator将网站中的错误链接找出来； 2）测试的顺序为：自顶向下、从左到右； 3）查看页面title是否正确。（不只首页，所有页面都要查看）； 4）LOGO图片是否正确显示； 5）LOGO下的一级栏目、二级栏目的链接是否正确； 6）首页登录、注册的功能是否实现； 7）首页左侧栏目下的文章标题、图片等链接是否正确； 8）首页中间栏目下的文章标题、图片等链接是否正确； 9）首页右侧栏目下的文章标题、图片等链接是否正确； 10）首页最下方的【友情链接】、【关于我们】等链接是否正确； 11）进入一级栏目或二级栏目的列表页。查看左侧栏目名称，右侧文章列表是否正确； 12）列表页的分页功能是否实现、样式是否统一； 13）查看文章详细页面的内容是否存在乱码、页面样式是否统一； 14）站内搜索（各个页面都要查看）功能是否实现； 15）前后台交互的部分，数据传递是否正确；
16) 默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。 二、UI测试 UI测试包括的内容有如下几方面： 1）各个页面的样式风格是否统一； 2）各个页面的大小是否一致；同样的LOGO图片在各个页面中显示是否大小一致；页面及图片是否居中显示； 3）各个页面的title是否正确； 4）栏目名称、文章内容等处的文字是否正确，有无错别字或乱码；同一级别的字体、大小、颜色是否统一； 5）提示、警告或错误说明应清楚易懂，用词准确，摒弃模棱两可的字眼； 6）切换窗口大小，将窗口缩小后，页面是否按比例缩小或出现滚动条；各个页面缩小的风格是否一致，文字是否窜行； 7）父窗体或主窗体的中心位置应该在对角线焦点附近；子窗体位置应该在主窗体的左上角或正中；多个子窗体弹出时应该依次向右下方偏移，以显示出窗体标题为宜； 8）按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置；避免空旷的界面上放置很大的按钮；按钮的样式风格要统一；按钮之间的间距要一致； 9）页面颜色是否统一；前景与背景色搭配合理协调，反差不宜太大，最好少用深色或刺目的颜色； 10）若有滚动信息或图片，将鼠标放置其上，查看滚动信息或图片是否停止； 11）导航处是否按相应的栏目级别显示；导航文字是否在同一行显示； 12）所有的图片是否都被正确装载，在不同的浏览器、分辨率下图片是否能正确显示（包括位
Appium环境搭建 随着人类消费观念转变，企业巨头间的无硝烟战场从互联网转移到移动端，为了抢占移动端用户，企业们更是绞尽脑汁，想方设法提高产品质量和增强用户体验，赢得此场战役的关键是产品质量，高质量产品更能捕获用户的芳心。但高质量产品保证的根源是高质量的测试，因此测试时关键。移动应用自动化测试是一个新的领域，移动端平台多样化（Andriod、Ios、FirefoxOS）为自动化测试带来了挑战与困难，随着Appium框架的推出，移动自动化测试进入一个崭新的阶段，自动化入门容易、上手快，轻轻松松测试多个移动平台。因Appium，移动自动化测试更加容易，现在让我为大家揭开Appium神秘面纱吧。 Appium is an open source test automation framework for use with native and hybrid mobile apps. It drives iOS and Android apps using the WebDriver JSON wire protocol. 摘自http://appium.io/ 从上面那句话我们可以窥探出Appium整个轮廓。Appium是一个开源、免费的移动端自动化测试框架，可以用来测试原生和混合移动应用，同时支持测试多种平台（Ios、Android、FirefoxOS）下应用，底层是采用WebDriver JSON Wire协议去实现的。 Appium测试环境搭建步骤： ?下载、安装JDK&配置Java环境变量 ?下载、安装SDK、ADT&配置Android环境变量 ?下载、安装AppiumForWindow ?创建安卓模拟器 ?在线安装Testng、SVN、Maven等插件 ?Appium简单案例 1、下载、安装JDK&配置Java环境变量 JDK（Java Development Kit）即Java开发工具集，一堆Java开发基本工具比如Javac.exe、Jar.exe、Javadoc.exe etc.同时JDK包含了JRE（Java Runtime Environment）即Java运行环境，因此要进行使用Java编写Appium脚本，前提是安装JDK。 Java语言以前是Sun公司推出，之前可以在Sun主页中下载JDK，但现在Sun公司被Oracle收购了，因此现在想下载JDK最好去Oracle官网下载。 JDK下载地址:https://www.doczj.com/doc/5f9938345.html,/technetwork/java/javase/downloads/index.html 安装（略），傻瓜式安装，关键是Java_Home 配置环境变量： 1、右键我的电脑--属性--高级--环境变量 2、新建系统变量JAVA_HOME 和CLASSPATH 变量名：JAVA_HOME 变量值：C:\Program Files\Java\jdk1.7.0 变量名：CLASSPATH 变量值：.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar; 3.、选择“系统变量”中变量名为“Path”的环境变量，双击该变量，把JDK安装路径中bin目录的绝对路径，添加到Path变量的值中，并使用半角的分号和已有的路径进行分隔。 变量名：Path 变量值：%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin; 验证配置是否成功：重新打开控制台输入：java -verison，如果显示Java版本信息表示安装成功。 2、下载、安装ADT&配置Android环境变量 ADT（Android Development Kit，即安卓开发工具包）属于SDK（Software Development Kit, 即软件开发工具包）
XXX 职业技术学院 毕业设计（论文） 题目： Web 网站渗透测试技术研究 系 (院) 信息系 专业班级 计算机网络 学 号 1234567890 学生姓名 XXX 校内导师 XXX 职 称 讲师 企业导师 XXX 职 称 工程师 企业导师 XXX 职 称 工程师 ----------------------------------------------装 订 线 ----------------------------------------------
Web网站渗透测试技术研究 摘要： 随着网络技术的发展和应用领域的扩张，网络安全问题越来越重要。相对于传统的系统安全，Web网站的安全得到了越来越多的重视。首先，越来越多的网络业务不再用专门的客户机/服务器模式开发，而是运行在Web网站上用浏览器统一访问；其次，和比较成熟的操作系统安全技术比较，Web网站的安全防护技术还不够完善，当前黑客也把大部分注意力集中在Web渗透技术的发展上，使Web网站安全总体上面临相当严峻的局面。 为了确保Web网站的安全，需要采用各种防护措施。在各种防护措施中，当前最有效的措施是先自己模拟黑客攻击，对需要评估的网站进行Web渗透测试，找到各种安全漏洞后再针对性进行修补。 本文在对Web网站渗透测试技术进行描述的基础上，配置了一个实验用Web网站，然后对此目标网站进行了各种黑客渗透攻击测试，找出需要修补的安全漏洞，从而加深了对Web 安全攻防的理解，有利于以后各种实际的网络安全防护工作。 关键词： 网络安全；Web网站；渗透测试 Web site penetration testing technology research Abstract： With the expansion of the network technology development and applications, network security issues become increasingly important. Compared with the traditional system security, Web security has got more and more attention. First, more and more network applications no longer develop with specialized client / server model, but run on the Web site and accessed by browser; Secondly, operating system security technology is relatively safe, but secure Web site protection technology is still not perfect, so the most of the curr ent hackers’attention focused on the development of Web penetration technology, the Web site is facing serious security situation in general. To ensure the security Web site, you need to use a variety of protective measures. In a variety of protective measures, the most effective measure is to own hacking simulation, the need to assess the Web site penetration testing, to find a variety of security vulnerabilities before specific repair. Based on the Web site penetration testing techniques described, the configuration of an experimental Web site, then this target site penetration of various hacker attack test, identify areas that need patching security holes, thereby deepening of Web security offensive understanding, there is conducive to future practical network security protection work. Keywords： Network Security, Web sites, penetration testing
Xxxx 性能测试报告 文档编号： 密级： 版本信息：Vxxxx 建立日期：2017-06 创建人：XXX
1引言 1.1编写目的 根据性能测试方案，给出结果和分析以及结论和建议。 测试方案预期读者：开发人员、测试人员、和项目相关人员。 1.2项目背景 1.3术语定义 虚拟用户：通过执行测试脚本模仿真实用户与被测试系统进行通信的进程或线程。 测试脚本：通过执行特定业务流程来模拟真实用户操作行为的脚本代码。 场景：通过组织若干类型、若干数量的虚拟用户来模拟真实生成环境中的负载场景。 集合点：用来确定某一步操作由多少虚拟用户同步执行（并发）。 事务：设置事务是为了明确某一个或多个业务或者某一个按钮操作的响应时间。 HPS:每秒点击数，一般情况下，与TPS成正比。 TPS：每秒事务数，是指每秒内，每个事务通过、失败以及停止的次数，可以确定系统在任何给定时刻的实际事务负载。 系统资源利用率：是指在对被测试系统执行性能测试时，系统部署的相关应用服务器、数据库等系统资源利用，比如CUP，内存，网络等。
2测试业务及性能需求 服务器配置如下： Web服务器： 操作系统：Windows7 旗舰版64位； 处理器：Intel(R) Xeon(R) CPUI5 -5200U@2.20GHz 2.20GHz 3场景设及计执行结果 3.1场景设计
3.2测试结果 3.2.1“提交”事务情况汇总 3.2.2每秒点击量（hps） 1、CJ-TJ_001和CJ-TJ_004点击率在大概维持在13-15左右的点击率 2、CJ-TJ_003和CJ-TJ_004点击率在场景持续变发60或者80个用户时，hPS会有明显的下降
超实用！手把手教你如何3步进行Web渗透测试！ 一个偶然的机会，有幸邀请到了一家国外专门做web安全的公司来对自己的web系统做安全测试。4周下来，我与几位安全专家多次沟通，完成了对自己系统的威胁建模，渗透测试，白盒测试，一共发现了28个漏洞。经验宝贵，因此有必要好好总结下。 现在，随着企业信息化建设的开展，越来越多的重要数据会以电子媒介的形式存放，这在方便企业办公的同时，也造成了极大的安全隐患。近年来，随着APT攻击的蔓延，使得越来越多的企业遭受不可挽回的重大损失。 在目的明确、装备精良、经验丰富的“雇佣军”式的攻击者面前，传统的安全设备已显得力不从心，企业需要做的是定期开展专业的渗透测试，来降低风险，加固安全。 那么，什么是渗透测试？ 渗透测试，是渗透测试工程师完全模拟黑客可能使用的攻击技术和漏洞发现技术，对目标网
络、主机、应用的安全作深入的探测，发现系统最脆弱的环节。 如果说安全检测是“横向地毯式自动化扫描”，那么渗透测试就是“纵向深度人工化入侵”。可见渗透测试的目的是发现目标系统潜在的业务漏洞风险。 安全问题都体现在输入输出的问题上，能够分析数据流就有迹可循了。先知道渗透测试的流程，用工具找到漏洞，了解并且复现它。 如何进行Web渗透测试？ 1、完整web渗透测试框架 当需要测试的web应用数以千计，就有必要建立一套完整的安全测试框架，流程的最高目标是要保证交付给客户的安全测试服务质量。 立项：项目建立，时间安排，人力分配，目标制定，厂商接口人确定； 系统分析&威胁分析：针对具体的web应用，分析系统架构、使用的组件、对外提供的接口等，以STRIDE为威胁模型进行对应的安全威胁分析，输出安全威胁分析表，重点关注top3威胁； 制定测试用例：根据威胁分析的结果制定对应的测试用例，测试用例按照模板输出，具备可执行性； 测试执行&漏洞挖掘：测试用例执行&发散测试，挖掘对应的安全问题or漏洞； 问题修复&回归测试：指导客户应用开发方修复安全问题or漏洞，并进行回归测试，确保安全问题or漏洞得到修复，并且没有引入新的安全问题； 项目总结评审：项目过程总结，输出文档评审，相关文档归档。
一次WEB服务器渗透测试笔记 作者：佚名文章来源：网络点击数：78 更新时间：2008-11-17 渗透测试是最能直接的反映系统的安全性的一种手段了。现整理了前段时间进行的一次渗透测试的笔记，整个过程中所使用的工具和思路都比较简单，本文也正是为了您的系统不被这些“简单”的东西所击败而作 此次渗透测试的已知条件只有一个：目标IP地址211.***.***.114。 首先当然是常规的扫描nmap -v -sS -O 211.***.***.114，得到的结果如下： (The 1641 ports scanned but not shown below are in state: filtered) Port State Service 80/tcp open http Device type: general purpose Running: FreeBSD 4.X OS details: FreeBSD 4.7-RELEASE （注意：渗透测试需要有对方授权，任何未经许可的扫描和渗透都有可能受到起诉。） 这个结果让人比较郁闷，只开了80一个端口，而且是freebsd的系统，并用IPFW 或其他firewall进行了严格的过滤，看来这次的渗透要费点脑筋了。
但打开页面看了一下，更加让人丧气情况出现了：所有的连接都是静态的html页面！这意味着没有sql注入可利用，没有脚本漏洞可发掘！只是通过指纹验证httprint知道了web服务器是apache。 嗯，好吧，看来只能扫一下80端口试一下了。拿出RetinaApacheChunked... ... 当扫描结果出现在我眼前的时候，我想我有必要联系一下拉登大叔了，直接把这服务器炸掉算了！！！ 放弃？！当然不！“一条铁链的强度取决于其最薄弱的一环”，安全也从来都不是单点的安全，所以，扩大扫描的范围说不定会有收获。当然这个扩大也不是随意的，最好先估算一下对方的地址段的长 度，比如这个211.***.***.114，假设掩码是240，则该段地址即为：211.***.***.112－211.***.***.127 。这个不用解释了吧！ 拿出nmap，扫描从211.***.***.113－211.***.***.126的地址。得到的结果中最另人感兴趣的是一台开放了80端口的windows2000的主机211.***.***.116。一种直觉告诉我这台主机就是突破口！ http://211.***.***.116 出现在我眼前的是一个asp论坛的首页，但奇怪的是该论坛没什么分论坛也没几个注册用户，很可能是一个用来测试的系统。看了下论坛底部的版本信息“Powered by China Power Board v1.2”，原来是CPB的论坛，而且印象里这个v1.2好像是有注入漏洞，（窃喜）。 用google搜索到一个cpbv1.2研究了一下，原来数据库用的是ACCESS，储存管理员用户名和密码的表名为admin，这是我们最关心的东西，该表有四列：a_id admin password a_grade，其中passoword是使用md5加密过的。好了知道了这些基本信息，就可以进行下一步了：
web安全渗透测试培训安全测试总结 跨站点脚本攻击（Xss） Burpsuite探测反射型xss问题请求的值没有做处理就在响应中返回 越权访问定义：不同权限账户之间的功能及数据存在越权访问。 测试方法： 1.抓取A用户功能链接，然后登录B用户对此链接进行访问。 2.抓取用户A的uesrid，用用户B登录时替换为用户A的userid。 3.抓取用户A的cookie，用用户B登录时替换用户A的cookie。 文上传漏洞定义：没有对上传文扩展名进行限制或者限制可以被绕过。 测试方法：找到系统中可以上传文的地方，抓取功能链接，修改文扩展名，看响应包的状态。 关键会话重放攻击定义：可以抓取包固定账号破解密码、固定密码破解账号和重放提交投票数据包。 测试方法：
使用抓包工具抓取系统登录请求，获得用户和密码参数，使用用户或密码字典替代登录请求会话中对应的用户或密码参数，暴力破解。 中间weblogic命令执行漏洞定义：weblogic反序列化漏洞，可以执行系统命令。 测试方法： 使用CVE-20XX-2628漏洞检测工具，对目标主机进行检测。在url.txt中填入目标主机的“ip:port”，这里填入 192.168.2.103:7001。在windows主机打开命令行运行CVE-20XX-2628-MultiThreading.py开始检测。 敏感信息泄露定义：系统暴露系统内部信息，包括网站绝对路径泄露、SQL语句泄露、中间泄露、程序异常回显。 测试方法： 1.使用抓包工具对系统中的参数进行篡改，加入特殊符号“’、--、&;”，查看返回数据包。 2.查看系统前端js代码。 SQL语句泄露中间版本泄露程序异常回显程序异常回显后台泄露漏洞中间后台泄露定义：weblogic后台地址过于简单，攻击者很容易猜测和破解到后台地址。 测试方法： 1.不允许使用默认地址 2.不允许只修改控制台访问地址的端口号
软件测试技术 案例库
案例一：错误报告与管理 一、案例目的 1．熟悉错误报告的编写内容 2．熟悉错误管理的工作流程 3．了解测试管理的内容 二、案例内容： 1.测试酒店管理系统，编写有一定质量的错误报告 2.使用TestDirector测试管理软件，熟悉需求管理、测试计划、执行测试、错误管理 三、案例步骤： ?任务一：提交软件测试中发现的错误 1、安装酒店管理系统，测试该系统，针对所发现的错误，记录并提交错误以便开发 人员修改。 ?任务二：寻找软件测试中错误的触发条件，并编写有一定质量的错误报告。 1、1、测试酒店管理系统，根据任务一中提交错误报告存在的问题，重新编写错误报 告，错误报告的内容必须包括如下： 3、测试中需要考虑错误重现 4、错误报告通过TestDirector软件进行管理 ?TestDirector使用： ●●使用前设置 1、断开网络连接。在屏幕底部的工具栏上选择“本地连接”图标，右键点击，选择 “禁用”。 2、把计算机名改为“JF82-55”。控制面板—〉系统—〉网络标识—〉属性，修改计算 机名，重启机器。 3、启动TestDirector的相应服务。在控制面板中选择管理工具—〉组件服务—〉“本地 计算机上的服务”—〉选中“Advanced TestDirector Startstop Servic4e”—〉点右键选“启动”。 4、启动TestDirector。在屏幕底部的工具栏上出现粉红色图标TestDirector，右键选中 并点击，在弹出菜单中选择“Start TestDirector”。 5、从开始菜单中选择程序—〉TestDirector7.6，出现屏幕如图3-1。
如果Web服务中的SSL和TLS协议出现安全问题，后果会如何?很明显，这样的话攻击者就可以拥有你所有的安全信息，包括我们的用户名、密码、信用卡、银行信息……所有的一切。本文将向读者详细介绍如何针对Web服务中的SSL和TLS协议进行安全渗透测试。我们首先对这两种协议进行了概述，然后详细介绍了针对加密信道安全性的黑盒测试和白盒测试。最后列出了一些常用的安全测试工具。 一、简介 目前，许多重要的Web服务都使用了SSL和TLS协议对通信进行保护。我们知道，http协议是使用明文进行传输的，但是像网络银行之类的web应用如果使用http协议的话，那么所有的机密信息都会暴露在网络连接中，这就像银行用一个透明的信封给我们邮寄信用卡帐号和密码一样，在从银行到达用户之间任何接触过这封信的人，都能看到我们的帐号和密码。为了提高其安全性，经常需要通过SSL或者TLS隧道传输这些明文，这样就产生了https通信流量。例如网络银行之类的应用，在服务器和客户端之间传输密码，信用卡号码等重要信息时，都是通过https协议进行加密传送的。 SSL和TLS是两种安全协议，它们通过加密技术为传输的信息提供安全信道、机密性和身份验证等安全功能。我们知道由于对高级密码技术的出口限制，会造成遗留系统使用的是弱加密技术。如果系统采用了弱密码，或者说密码强度过低的话，攻击者可以在有效的时间内破解密钥，而攻击者一旦得到了密钥，就像小偷得到了我们家的钥匙一样，所有的锁都会形同虚设。但是，新Web服务器就不会使用弱加密系统了吗?答案是否定的，因为许多新Web服务器也经常被配臵成处理虚密码选项。为了实现这些安全特性，协议必须确保使用的密码算法有足够的强度，并且密码算法得到了正确的实现。即使服务器安装使用了高级的加密模块，但是如果配臵不当的话，也有可能为安全特性要求较高的通信信道的设臵了较弱的加密技术。下面，我们将详细介绍如何对这两种协议的配臵进行安全审计。 二、测试SSL/TLS的密码规范 我们知道，http协议是使用明文进行传输的，为了提高其安全性，经常需要通过SSL或者TLS隧道传输这些明文，这样就产生了https通信流量。除对传输的数据进行加密处理之外，https(安全超文本传输协议，HTTPS)还能利用数字证书为服务器或客户端提供身份标识。 过去，美国政府对加密系统的出口有许多限制，如密钥长度最大为40位，因为密钥长度越短，它就越容易破解。后来，密码出口条例已经放宽了许多，但是，检查服务器的SSL配臵仍然十分重要，因为它有可能配臵使用了弱加密技术。基于SSL的服务不应该提供选择弱密码的机会。 注意，我们这里所说的弱密码，指的是加密强度不够、容易破解的加密系统。不同的加密算法具有不同的密码强度，但是在算法一定的情况下，密钥的长度越长，加密强度越高。 技术上，选择加密技术的过程如下所示：在建立SSL连接的初期，客户端向服务器发送一个Clien t Hello消息，以告知服务器它支持哪些加密技术等。一般情况下，客户端通常是一个Web浏览器，所以浏览器是目前最常见的SSL客户端;然而，任何支持SSL的应用程序都可以作为SSL客户端使用。比如，有时候SSL客户端是些SSL代理(如stunnel)，它们使得那些不支持SSL的工具也能与SSL服务通信。同理，SSL服务器端通常为Web服务器，但是其他应用程序也可以充当SSL服务器端。加密套件规定了具体的密码协议(DES、RC4、AES)、密钥长度(诸如40、56或者128位)和用于完整性检验的散列算法(SHA、MD5)。收到Client Hello消息后，服务器以此确定该会话所使用的加密套件。当然，通过配臵可以规定服务器能够接受哪些密码套件，这样的话，我们就能够控制是否跟仅支持40位加密的客户端通话 三、黑盒测试 为了检测可能支持的弱密码，必须找出与SSL/TLS服务相关的端口。通常情况下，要检查端口443，因为它是标准的https端口;不过运行在443端口上的却未必是https服务，因为通过配臵，https服务可以运行在非标准的端口上，同时，Web应用程序也许使用了其它利用SSL/TLS封装的服务。一般而言，为了找出这些端口，必须找出使用了哪些服务。
Web测试有以下几点需要关注： UI测试 UI测试包括的内容有如下几方面： 1）各页面的风格是否统一 2）各页面的大小是否一致；同样的LOGO图片在各个页面中显示是否大小一致；页面及图片是否居中显示 3）各页面的title是否正确 4）栏目名称、文章内容等处的文字是否正确，有错别字或乱码；同一级别的字体、大小、颜色是否统一 5）提示、警告或错误说明应该清楚易懂，用词准确，摒弃模棱两可的字眼 6）切换窗口大小，将窗口缩小后，页面是否按比例缩小或出现滚动条；各个页面缩小的风格是否一致（按比例缩小或出现滚动条，不可二者兼有） 7）父窗体或主窗体的中心位置应该在对角线交点附近；子窗体位置应该在主窗体的左上角或正中；多个子窗体弹出时应该依次向右下方便宜，以显示出窗体标题为宜8）按钮大小基本相似，忌用太长名称，免得占用太多的页面位置；避免空旷的页面放置很大的按钮；按钮的样式风格要统一；按钮之间的间距要一致9）页面颜色是否统一；前景色与背景色搭配合理协调，反差不宜太大，最好用深色或刺目的颜色 10）若有滚动信息或者图片，将鼠标放置其上，查看滚动信息或图片是否停止 11）导航处是否按栏目相应的级别显示；导航文字是否在同一行显示 12）所有的图片是否被正确装载，在不同的浏览器，分辨率下图片是否能正常显示（包括位置、大小） 13）文章列表页，左侧的栏目是否与一级、二级栏目的名称、顺序一致 14）调整分辨率验证页面风格是否有错误现象 15）鼠标移动到Flash焦点特效上是否实现，移出焦点特效是否消失 链接测试 链接测试主要分为以下几个方面 1）页面是否有无法连接的内容；图片是否能正常显示，有无冗余图片，代码是否规范，页面是否存在死链接（可用HTML Link Validator工具查找） 2）图片是否有无用链接；点击图片上的链接是否跳转到正确页面 3）页面点击LOGO下的一级栏目或二级栏目名称，是否可进入相应的栏目 4）点击首页或列表页的文章标题的链接，是否可进入相应的文章详情页 5）点击首页栏目名称后的【更多】链接，是否正确跳转到相应页面 6）文章列表页、左侧栏目的链接，是否可正确跳转到相应的栏目页面 7）导航链接的页面是否正确；是否可按栏目级别跳转到相应的页面 （例，【首页-服务与支持-客服中心】，分别点击“首页”，“服务与支持”，“客服中心”，查看是否可跳转到相应页面） 搜索测试 搜索测试主要分为以下几个方面 1）搜索按钮功能是否实现 2）输入网站中存在的信息，能否正确搜索出结果 3）输入键盘中的特殊字符，是否报错：特别关注 :_? ’ . \ /--；特殊字符 4）系统是否支持快捷键回车键，Tab 5）搜索出的结果页面是否与其他页面风格一致
网站渗透测试报告-模板
____________________________ 电子信息学院渗透测试课程实验报告____________________________ 实验名称：________________________ 实验时间：________________________ 学生姓名：________________________ 学生学号：________________________
目录 第1章概述 (3) .测试目的 (3) .测试范围 (3) .数据来源 (3) 第2章详细测试结果 (4) .测试工具 (4) .测试步骤 (4) 预扫描 (4) 工具扫描 (4) 人工检测 (5) 其他 (5) .测试结果 (5) 跨站脚本漏洞 (6) 盲注 (7) 管理后台 (10) .实验总结 (11)
第1章概述 .测试目的 通过实施针对性的渗透测试，发现XXXX网站系统的安全漏洞，保障XXX业务系统安全运行。 .测试范围 根据事先交流，本次测试的范围详细如下： .数据来源 通过漏洞扫描和手动分析获取相关数据。
第2章详细测试结果 .测试工具 根据测试的范围，本次渗透测试可能用到的相关工具列表如下： .测试步骤 预扫描 通过端口扫描或主机查看，确定主机所开放的服务。来检查是否有非正常的服务程序在运行。 工具扫描 主要通过Nessus进行主机扫描，通过WVS进行WEB扫描。通过Nmap进行端口扫描，得出扫描结果。三个结果进行对比分析。
人工检测 对以上扫描结果进行手动验证，判断扫描结果中的问题是否真实存在。 其他 根据现场具体情况，通过双方确认后采取相应的解决方式。 .测试结果 本次渗透测试共发现2个类型的高风险漏洞，1个类型的低风险漏洞。这些漏洞可以直接登陆web管理后台管理员权限，同时可能引起内网渗透。获取到的权限如下图所示： 可以获取web管理后台管理员权限，如下步骤所示： 通过SQL盲注漏洞获取管理员用户名和密码hash值，并通过暴力破解工具破解得到root用户的密码“mylove1993.” 利用工具扫描得到管理后台url，使用root/mylove1993.登陆后台如图：