Web应用程序的整体测试
cwj007 yesky论坛
随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。
B/S下的功能测试比较简单，关键是如何做好性能测试。目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。
首先我们从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE,都是多层构架，有界面层，业务逻辑层，数据层。而从测试的流程上来说，首先是发现问题，分析问题，定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做？
如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的常识，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：
1、通用指标（指Web应用服务器、数据库服务器必需测试项）:
* ProcessorTime: 指服务器CPU占用率，一般平均达到70%时，服务就接近饱和；
* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
* Physicsdisk Time : 物理磁盘读写时间情况；
2、Web服务器指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间/ 秒数；
* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数,有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
3、数据库服务器指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Butter Cache hit ：数据库Cache的命中情况；
上面的指标只是一些通用的指标,起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各个工具有它的使用范围，其中我各个认为LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试,ACT则是与.NET集成比较好，支持ViewState （.NET 下控件缓存的支持）的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧。
在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阀值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阀值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。
这个我们要对子系统进行详细测试，由于B/S 结构下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行，一、非程序部分，即图片等等;二、应用程序本身。通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。
对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常，死锁，网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。
上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种：
一、性能达不到目标；
二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大；
三、服务器稳定性的问题，比如内存泄漏……。
要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与Quantify,主要是他对.net 与java ,C++都有支持，而且分析效果特别专业，我们先了解一下Rational Purify, Rational Purify 能自动找出Visual C/C++ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C++ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面；Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。
我们先说性能优化与异常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显，比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒,提升了29.7秒，而如果它的执行时间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显，而且写过程序的人都知道，后者性能优化的代价更大。在性能优化的过程中，一般是先数据库，后程序，因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用Quantity 时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，
SqlCmd.ExecuteNoQuery等等数据库执行函数,这时你就需要分析数据库。
数据库的分析原则是先索引，后存储过程，最后表结构视图的优化，索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱，SQLProfile,SQL查询分析器，Precise,SQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL 语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。
同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事，测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情。
内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常C++ 内存问题比较多，Java与.NET比较少，一般由GC不合理引起。C++的内存错误就比较多了，主要常见的有:
1、Array Bounds Read (ABR) ：数组越界读
2、Array Bounds Write (ABW)：数组越界写
3、Beyond stack Read (BSR)：堆栈越界读
4、Free Memory Read(FMR)：空闲内存读
5、Invalid pointer Read(IPR)：非法指针阅读
6、Null Pointer Read(NPR)：空指针阅读
7、Uninitialized Memory Read(UMR)：未初始化内存读写
8、Memory Leak：内存泄漏
注：如果需要更多的信息，可以参见Purify的帮助信息。
顺便提一句，为什么我要说单元测试时做这个比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具PureCoverage 来做就更完美了。
注：本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍,你也可使用你比较熟悉的工具达到相同的目标。
软件测试试题 一、判断题 1. 软件测试就是为了验证软件功能实现的是否正确，是否完成既定目标的活动，所以软件测试在软件工程的后期才开始具体的工作。（?）分析：软件测试人员应在需求阶段就加入到开发过程中。因为软件的质量问题会随着软件开发周期的不断展开而不断放大的，而更正质量问题的成本也是不断放大的，也就是说在需求阶段出现的小问题，到开发完成后缺陷可能成几何倍数放大，而修改所需要的成本也会不断的放大，如果测试工程师能够尽早的加入其中的话可以尽早的找出问题，及时发现，避免问题最后放大到不可收拾。 2. 发现错误多的模块，残留在模块中的错误也多。（??） 分析：开发人员能力参差不齐，当发现某模块bug数越多，修改的bug越多，则引入新的bug就会越多，那么这些新的bug发现的难度要比修改前发现bug要大的多，其隐藏未发现的bug数量就越多，那么相应的模块质量也就越差。代码复用也可能造成该模块的bug比较多。 3. 测试人员在测试过程中发现一处问题，如果影响不大，而自己又可以修改，应立即将此问题正确修改，以加快、提高开发的进程。（?）分析：正确流程应提交错误缺陷，此时开发组人员会有记录，并修改此问题。如果测试人员自己修改，会导致开发人员无记录，容易出现冗余系统版本，并不清楚哪个为最终版本。 4. 单元测试通常应该先进行“人工走查”，再以白盒法为主，辅以黑
盒法进行动态测试。（??） 5. 功能测试是系统测试的主要内容，检查系统的功能、性能是否与需求规格说明相同。（??） 6. 软件质量管理即QM是由QA和QC构成，软件测试属于QC的核心工作内容。（??） 补充： QA（Quality Assurance）品质保证； QC（Quality Conterller）品质控制员 7. 软件测试只能发现错误，但不能保证测试后的软件没有错误。（??） 8. 软件就是程序。（?） 概念：软件是计算机程序，程序所用的数据以及相关文档资料的结合。软件又分为系统软件和应用软件两大类。 9. 测试只要做到语句覆盖和分支覆盖，就可以发现程序中的所有错误。（?） 分析：白盒测试用例设计6种覆盖方法： a. 语句覆盖 b. 判定覆盖 c. 条件覆盖 d.判定/条件覆盖 e. 组合覆盖 f. 路径覆盖 软件测试的目的是发现软件中的错误，但不能保证软件没有错误。10. I18N测试是指对产品做出具有国际性的规划，而L10N测试则是指软件做出符合本地的工作。（??） 补充：
在运维工作中，压力测试是一项非常重要的工作。比如在一个网站上线之前，能承受多大访问量、在大访问量情况下性能怎样，这些数据指标好坏将会直接影响用户体验。 但是，在压力测试中存在一个共性，那就是压力测试的结果与实际负载结果不会完全相同，就算压力测试工作做的再好，也不能保证100%和线上性能指标相同。面对这些问题，我们只能尽量去想方设法去模拟。所以，压力测试非常有必要，有了这些数据，我们就能对自己做维护的平台做到心中有数。 目前较为常见的网站压力测试工具有webbench、ab（apache bench）、tcpcopy、loadrunner 软件名称简介优缺点 webbench 由Lionbridge公司开发，主要测试每秒钟请求数和每秒钟数据传输量，同时支持静态、动态、SSL 部署简单，静动态均可测试。适用于小型网站压力测试（单例最多可模拟3万并发） ab（apache bench）Apache自带的压力测试工具，主要功能用于测试网站每秒钟处理请求个数 多见用于静态压力测试，功能较弱，非专业压力测试工具 tcpcopy 基于底层应用请求复制，可转发各种在线请求到测试服务器，具有分布式压力测试功能，所测试数据与实际生产数据较为接近后起之秀，主要用于中大型压力测试，所有基于tcp的packets均可测试 loadrunner 压力测试界的泰斗，可以创建虚拟用户，可以模拟用户真实访问流程从而录制成脚本，其测试结果也最为逼真模拟最为逼真，并可进行独立的单元测试，但是部署配置较为复杂，需要专业人员才可以。 下面，笔者就以webbench为例，来讲解一下网站在上线之前压力测试是如何做的。 安装webbench #wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz #tar zxvf webbench-1.5.tar.gz #cd webbench-1.5 #make && make install进行压力测试 并发200时 # webbench -c 200 -t 60 https://www.doczj.com/doc/ee16080706.html,/index.php参数解释：-c为并发数，-t 为时间（秒） Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET https://www.doczj.com/doc/ee16080706.html,/index.php 200 clients, running 60 sec. Speed=1454 pages/min, 2153340 bytes/sec. Requests: 1454 susceed, 0 failed.当并发200时，网站访问速度正常
渗透测试的两大阶段 渗透测试不能测试出所有可能的安全问题，它只是一个特定环境下才合适的WEB应用安全测试技术。OWASP的渗透测试方法是基于墨盒方法的，测试人员在测试前不知道或只知道很有限的关于被测试应用的信息。 渗透测试被分成两大阶段： ■ 被动模式阶段 在这个阶段，测试人员试图去理解被测应用的逻辑，并且去使用它。可以使用工具去收集信息，例如，可以用HTTP代理工具去观察所有请求与响应。本阶段结束后，测试人员应该理解了应用的所有访问点（如，HTTP报头、参数和COOKIE）。信息收集一节将介绍如何进行被动模式的测试。 ■ 主动模式阶段 这个阶段里，测试人员将利用后述的9大类66种方法主动地去测试。 被动模式阶段 信息收集 安全评估的第一步是收集尽可能多的关于被测应用的信息。信息收集是渗透测试的必要步骤。通常使用公共工具（搜索引擎）、扫描器、发送简单或特别的HTTP请求等来迫使被测应用泄漏信息。 ◆使用蜘蛛、机器人和爬虫 目标是浏览和捕获被测应用相关的资源。 ◆搜索引擎发现与侦察 类似GOOGLE这样的搜索引擎可以用来发现被测应用中已经被公开的错误页面或WEB应用结构问题。 ◆识别应用入口点 枚举被测应用及其攻击面是展开任何攻击的的一个关键性前提。 ◆测试WEB应用指纹 应用指纹是信息收集的第一步。知道正在运行的WEB服务器的版本和类型后，测试人员可以确定已知的漏洞和测试过程中的相应攻击方法。获取WEB应用指纹的自动化工具Httprint和在线工具Netcraft。 ◆应用发现 应用发现是一项面向驻留在WEB/应用服务器中的WEB应用识别的活动。这种分析很重要，因为没有一个链接直接连接到主要应用的后端。分析可以发现有助于揭示诸如用于管理目的的WEB应用程序的细节。此外，它可以揭示诸如取消删除的，过时的脚本文件，这些文件通常是在测试、开发或维护过程产生的。可能使用到的工具： 1、DNS查询工具，如nslookup，dig等。
摘要软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件开发过程的重要组成部分，是软件质量保证的关键步骤。软件测试的方法可分为人工测试和机器测试，人工测试包括个人复查、走查和会审，机器测试可分为白盒测试和黑盒测试。软件测试虽然是一个独立的阶段，但在实际工作中，测试的流程主要包含单元测试、组装测试、确认测试、系统测试四个阶段。 关键词软件测试；白盒；黑盒；单元测试；组装测试；确认测试；系统测试 一、软件测试的常用方法 软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件开发过程的重要组成部分，是软件质量保证的关键步骤。采用面向对象技术进行软件开发产生了两个结果一是开发出功能更强大更便于用户使用的软件产品，二是生成规模庞大的程序代码和文档，这也必然导致更大规模的软件测试和维护工作。因此，规范化的软件测试势在必行。规范化不只是测试的需求（有效代码量、结构/逻辑的复杂性、高性能/高精确性/高可靠性需求）和消耗资源（人力/时间/测试频度）规模化，更要求在面对规模庞大的软件测试需求，在合理的资源消耗基础上，实施有效的测试。 下图描述的是常用的一些测试方法
1、人工测试的方法 （1）个人复查 个人复查是指程序员自行设计测试用例，对源代码、详细设计进行仔细检查，并记录错误、不足之处等。个人复查主要包括检查变量的正确性、检查标号的正确性、检查子程序、宏、函数、常量检查、标准检查、风格检查、比较控制流、选择、激活路径、对照详细说明书，阅读源代码和补充文档等方面的测试内容。 （2）走查 走查是指测试人员先阅读相应的文档和源代码，然后人工将测试数据输入被测试程序，并在纸上跟踪监视程序的执行情况，人工沿着程序的逻辑走查运行一遍，跟踪走查运行的进程来发现程序的错误。走查的具体测试内容包括模块特性、模块接口、模块的对外输入或输出、局部数据结构、数据计算错误、控制流错误、处理出错和边界测试等方面。 （3）会审 会审是指测试人员在会审前仔细阅读软件的有关资料，根据错误类型清单（根据以往的经验、对源程序的估计等，并在以后测试中给以丰富补充）填写检测表，提出根据错误类型要提出的问题。会审时，由程序设计人员讲解程序的设计方法，
用S o a p U I进行W e b s e r v i c e的性能压 力测试 Company number：【0089WT-8898YT-W8CCB-BUUT-202108】
用S o a p U I进行W e b s e r v i c e的性能压力测试1. 新建测试工程 选择在一个测试用例中测试多个方法，并为测试生成压力测试： 2. 为测试 Step 添加变量： 右键选中 Test Step ，添加一个 Grooy Script Step ；添加一个变量 count 并设置初始值为0 3. 添加一个随机变量： 右键选中 Test Step ，添加一个 Grooy Script Step ；名称为 rand ，用下面的代码产生一个随机值 view plaincopy to clipboardprint rand = new Random() = "test_" + (100) Random rand = new Random() result = "test_" + (100) 4. 使用动态参数： 打开 init 操作的 SOAP 请求，将输入参数用上面步骤产生的随机替换 view plaincopy to clipboardprint 02.
摘要:软件测试就是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件开发过程的重要组成部分,是软件质量保证的关键步骤。软件测试的方法可分为人工测试和机器测试,人工测试包括个人复查、走查和会审,机器测试可分为白盒测试和黑盒测试。软件测试虽然是一个独立的阶段, 但在实际工作中,测试的流程主要包含单元测试、组装测试、确认测试、系统测试四个阶段。 关键词:软件测试;白盒;黑盒;单元测试;组装测试;确认测试;系统测试 一、软件测试的常用方法 软件测试就是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件开发过程的重要组成部分,是软件质量保证的关键步骤。采用面向对象技术进行软件开发产生了两个结果:一是开发出功能更强大更便于用户使用的软件产品,二是生成规模庞大的程序代码和文档,这也必然导致更大规模的软件测试和维护工作。因此, 规范化的软件测试势在必行。规范化不只是测试的需求 (有效代码量、结构 /逻辑的复杂性、高性能 /高精确性 /高可靠性需求和消耗资源(人力 /时间 /测试频度规模化,更要求在面对规模庞大的软件测试需求,在合理的资源消耗基础上,实施有效的测试。 下图描述的是常用的一些测试方法 : 1、人工测试的方法 (1个人复查 个人复查是指程序员自行设计测试用例 ,对源代码、详细设计进行仔细检查,并记录错误、不足之处等。个人复查主要包括检查变量的正确性、检查标号的正确性、检查子程序、宏、函数、常量检查、标准检查、风格检查、比较控制流、选择、激活路径、对照详细说明书,阅读源代码和补充文档等方面的测试内容。 (2走查
走查是指测试人员先阅读相应的文档和源代码,然后人工将测试数据输入被测试程序,并在纸上跟踪监视程序的执行情况,人工沿着程序的逻辑走查运行一遍,跟踪走查运行的进程来发现程序的错误。走查的具体测试内容包括模块特性、模块接口、模块的对外输入或输出、局部数据结构、数据计算错误、控制流错误、处理出错和边界测试等方面。 (3会审 会审是指测试人员在会审前仔细阅读软件的有关资料,根据错误类型清单(根据以往的经验、对源程序的估计等,并在以后测试中给以丰富补充填写检测表,提出根据错误类型要提出的问题。会审时,由程序设计人员讲解程序的设计方法,由程序编写人员逐个讲解程序代码的编写,测试人员需要逐个审查, 提问,讨论可能出现的问题。会审对程序的功能、结构、逻辑和风格都要进行审定。会审的测试内容与“ 走查” 的内容相同。 2、机器测试 (1定义 机器测试的目的是检查程序的动态性能,检查程序在执行过程中存在的错误。尤其是发现程序在实现功能、逻辑通路、数值计算、数据处理、边界处理、错误处理等方面存在的错误。机器测试分为白盒测试和黑盒测试。 (2黑盒测试 黑盒测试即功能测试 ,这种方法是把软件看成一个看不见里面内容的黑盒,在完全不考虑程序内部结构和特性的情况下,测试软件的外部特性。根据软件的需求规格说明书设计测试用例,从程序输入和输出特性上检查程序是否满足设定的功能。黑盒测试常采用的方法是设计适量有效和无效的输入数据进行测试, 以期用最小的代价发现最多的错误。 (3白盒测试
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应用系统的页面结构、导航、菜单、连接的风格一致
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源代码，易读性比较高。
软件测试基本流程与要求（提纲） 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试--测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
web软件测试用例 一、界面测试公共测试用例 界面测试一般包括页面文字,控件使用，少图，CSS，颜色等。 1、文字 内容一致性： 1）公司要求文字的一致性，例如各种宣传文字、注册的协议条款、版权信息等； 2）各处相同含义文字的一致性，例如标题栏文字、页面主题文字、弹出窗口文字、菜单名称、功能键文字等。 样式一致性 1）（通常分类包括）各类文字字体、字号、样式、颜色、文字间距、对齐方式； 2）按钮的文字间距，按钮长度一定前提下，2个字的按钮，需要中间空一格（或者其它约定，需要统一）； 3）链接文字，同一类，菜单、小标题、页角文字链接，在点击时颜色变化要相同； 4）对齐方式，页面上文字的对齐，例如表单、菜单列、下拉列表中文字的对齐方式（左、右、居中等要统一） 语言习惯： 1）中文：文字简单，含义明确，无歧异，无重复，无别字，正确运用标点符号。 2）英文。 3）日文。 2、按钮 1）button的样式整体要统一，例如突出、扁平、3D效果等只能选其一； 2）采用的图片表述相同功能，要采用单一图标。 3、文本框 1）录入长度限制，根据数据库的设计，页面直接限定录入长度（特殊处屏蔽复制、粘贴）； 2）文本框自身的长度限制，主要考虑页面样式。 4、单选框 1）默认情况要统一，已选择，还是未选。 5、日期控件 1）图标、控件颜色、样式统一； 2）点击控件、文本框均应弹出日期选择框。 6、下拉选择框 1）默认是第一个选项，还是提示请选择一个。 7、提示信息 1）静态文字与它的提示信息一致性，例如静态文字为‘ID’，出错信息显示‘用户ID’； 2）空值时，出错信息需要统一，例如可以采用“静态文字”+不能为空； 3）出现录入错误时，例如可以统一采用“静态文字”+格式不符合要求； 4）提示信息标点符号是否标识；点击上一步，返回的页面上不应残留出错信息； 5）静态提示信息，在录入框右侧，应有录入信息的相应要求的提示文字，达到方便操作的目的；
WEB服务器性能测试基本指标 1说明 随着公司业务的发展，公司网站、管理后台、app服务器的访问量在不断增加，但通常在软件设计开发的时候很难模拟出大量用户同时访问系统的实际情况，因此，当Web网站遇到访问高峰时，容易发生服务器响应速度变慢甚至服务中断。为了避免这种情况，需要一种能够真实模拟大量用户访问Web应用系统的性能测试工具进行压力测试，来测试静态HTML页面的响应时间，甚至测试动态网页（包括PHP、JSP 等）的响应时间，为服务器的性能优化和调整提供数据依据。 Web性能测试的部分概况一般来说，一个Web请求的处理包括以下步骤： （1）客户发送请求 （2）web server接受到请求，进行处理； （3）web server 向DB获取数据； （4）web server生成用户的object(页面)，返回给用户。给客户发送请求开始到最后一个字节的时间称为响应时间（第三步不包括在每次请求处理中）。
2网络拓扑图 3系统配置
4主要指标 4.1事务（Transaction） 在web性能测试中，一个事务表示一个“从用户发送请求->web server接受到请求，进行处理-> we b server向DB获取数据->生成用户的object(页面)，返回给用户”的过程，一般的响应时间都是针对事务而言的。 4.2请求响应时间 请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为“TTLB”，即"time to last byte"，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则： （1）在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”； （2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”； （3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”； （4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去； 4.3事务响应时间 事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间是直接衡量系统性能的参数. 4.4并发用户数 并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。 另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。 可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发生性能问题，后果很可能是致命的。严格意义
测试人员考试试卷（考试时间90分钟，满分100分） 一、判断题（每题1分，12 分，正确的√，错误的╳） 1．软件测试的目的是尽可能多的找出软件的缺陷。（√） 软件测试的目的就是为了发现软件中的缺陷，从这个意义上面说上面的这个论断是正确的。不少人会认为软件测试可以保证软件的质量，其实这个观点是错误，测试只是软件质量控制中的一个角色，其活动并不能达成软件质量保证的效果。所以不要认为一个公司里面如果有了软件测试人员，产品的质量就会好起来。 2．Beta 测试是验收测试的一种。（╳） Beat测试和验收测试是两种不同的测试。验收测试的目的是为了以发现”未实现的需求”为目的，以评估”适合使用”为目标，该类测试的不是以发现缺陷为主要目的。beta测试是一模拟真实的使用环境从而发现缺陷的一种测试。所以两者之间的是非包容关系。 3．验收测试是由最终用户来实施的。（╳） 上面说到了验收测试的目的和目标，所以验收测试也可是是软件生产的企业内部人员来实施。例如产品经理。当软件以项目的形式出现，那么验收测试由最终用户来实施的情况是比较长见的。但是对于产品形式的软件，生产企业内部的验收测试会更多。 4．项目立项前测试人员不需要提交任何工件。（） 应该说这道题目没有明确的答案，在项目立项前测试人员是不是要把一些准备工作以工件的形式给记录下来是完全取决于该企业的软件开发过程的要求。同时不同企业，立项前要达成的一些必要条件也是大相径庭的。应该说这一题目出的不是很好，如果你是出题人这家企业的测试工程师，那么就应该有一个明确的答案。 5．单元测试能发现约80%的软件缺陷。（） 同样这一题目也没有标准答案。因为该数据的来源和其统计的方法，样本都没有一个工业标准。这样出来的数据同样不具有权威性。这里我可以说一个简单的例子，在用ASP,php这类脚本语言开发网页的时候是根本没有复杂的单元测试。那么这样的数字应用在网站开发上面是否有意义，还是值得商榷的。所以这道题目出的不好，没有明确的答案 6．代码评审是检查源代码是否达到模块设计的要求。（） 代码审查是一种静态技术，从这个意义上说代码复查是需要和其他的一些动态测试技术配合才能检查代码是否符合设计的要求 7．自底向上集成需要测试员编写驱动程序。（） 这道题目大家看下top-down 和 down-top的集成测试示意图就能得出明确的答案。这里需要了解的是什么是驱动测试程序，什么是桩程序。如果集成组件数量众多，多关系层次，那么不论是什么类型的集成测试。驱动程序和桩程序都是需要开发的。 8．负载测试是验证要检验的系统的能力最高能达到什么程度。（） 9．测试人员要坚持原则，缺陷未修复完坚决不予通过。（） 10．代码评审员一般由测试员担任。（x） 如果测试员有这个水平，那么当然是可以参加的。不过大多数的企业不会让普通的测试人员参与代码的评审。 11．我们可以认为的使得软件不存在配置问题。（x） 首先大家先搞清楚什么是配置管理什么是软件配置，从这道题目中看不出出题人想问的是关键工程中的配置管理还是单纯的软件配置。但是可以肯定的是不论是何种情况，答案均是否定的。
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
软件开发与测试配合 工作流程 XXX软件股份有限公司质量部 目录 1．简介 本流程文件旨在规定一个简单的可使开发人员和测试人员在软件开发的编码阶段相互配合工作的工作流程，其中包括测试与开发的配合、送测单和BUG单的填写、测试循环的结束等部分。开发阶段与测试循环的关系、测试模块的组合与测试原则、BUG的分类评级原则等也在本流程文件中有相关的描述。 鉴于公司的技术要求，目前质量部的测试人员不仅要完成黑盒测试工作，而且还要进行白盒测试中的“代码走查”工作。其它的白盒测试工作，目前还不在测试人员的工作职责之内。 由于公司已经为质量管理部开发完成“辅助测试系统1.0”，因此本测试流程的制定就建立在辅助测试系统之上，如果辅助测试系统有了新的版本，质量部将根据其变化适当调整测试流程。 2．适用范围 本流程文件适用于公司开发软件并需要测试服务的任何软件开发项目组、软件开发人员，以及任何测试人员。
当项目组在辅助测试系统中注册以后，公司领导可以使用本系统查询了解所有在本系统中注册的项目的测试信息，项目的质量管理员可以使用本系统查询了解项目的当前测试进展情况。程序员和测试员都可以使用本系统查询到自己产生的送测单和BUG单。 3．术语、名词定义 3.1 送测软件 送测软件包括一切软件执行必须的文件、数据、数据库配置等。开发人员必须提供所有的详细的资料以保证测试人员可以像客户一样的运行被测软件。 3.2 开发文档 开发人员提供给测试人员的开发文档至少包括以下几种：用户需求，概要设计，详细设计，用户手册等。开发人员应当在开发每阶段完成后三天内就向测试人员传送本阶段完成的开发文档，以利于测试人员的工作。 3.3 测试文档 测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护，也属于开发文档的一部分。
Web应用软件测试(一) (总分：56.00，做题时间：90分钟) 一、选择题 (总题数：28，分数：56.00) 1.在Web应用软件的基本结构中，客户端的基础是 ______。 （分数：2.00） A.HTML文档√ B.客户端程序 C.HTML协议 D.浏览器 解析： 2.扫描漏洞是保证系统安全的一个重要措施，下列不属于漏洞扫描范畴的是 ______。 （分数：2.00） A.接口漏洞√ B.操作系统漏洞 C.数据库漏洞 D.网络漏洞 解析： 3.Web应用软件的程序都是部署在 ______。 （分数：2.00） A.客户端 B.服务器端√ C.数据库 D.浏览器 解析： 4.常用的安全策略有 ______。 （分数：2.00） A.访问安全策略和安全管理策略 B.物理安全策略 C.信息加密策略 D.以上全部√ 解析： 5.以下不属于内容测试范畴的是 ______。 （分数：2.00） A.测试数据库中的内容
B.测试服务器端程序是否在数据处理过程中引入错误内容 C.Cookie测试内容√ D.测试客户器端程序是否在数据处理过程中引入错误内容 解析： 6.关于Web应用软件，说法不正确的是 ______。 （分数：2.00） A.Web应用软件的系统测试不仅包括按照大纲检查其能否满足需求，还得针对Web应用软件的特点对薄弱环节进行测试 B.Web应用软件的开发可以根据需求有开发人员设定结构√ C.Cookie测试是功能测试的重要组成部分 D.复杂的Web应用软件不仅是一个Web站点，还需要与其他系统协作完成所需的功能 解析： 7.在Web应用软件的系统安全检测与防护中，下面不属于入侵检测技术的是 ______。 （分数：2.00） A.基于主机的检测 B.基于网络的检测 C.基于完整性的检测 D.基于数据库的检测√ 解析： 8.CGI程序可以根据用户的不同输入而生成不同HTML页面，最常使用的CGI编程语言是 ______。 （分数：2.00） A.C语言 B.PERL语言√ C.C++语言 D.汇编语言 解析： 9.下列不属于易用性测试检查范畴的是 ______。 （分数：2.00） A.检查生成部分的字体类型、色彩是否美观 B.检查系统在压力下的稳定性√ C.检查生成部分与页面上其他排版元素是否一致 D.检查下载图片时间对易用性的影响 解析： 10.在非对称加密算法中，涉及到的密钥个数是 ______。 （分数：2.00） A.一个 B.两个√ C.三个 D.三个以上
测试方法 传统的测试方法包括某种形式的简单单元测试，通常由开发人员执行。设计这些测试需要了解软件的内部知识，并且这些测试几乎总是针对产品的非常小的、特定的部分。这些类型的测试非常适合与其他代码组件极少交互，甚至没有交互的简单 Web 服务。 功能验证（Functional Verification）也是一种测试过程，在这个过程中，对产品源代码了解有限的设计者进行测试以确认产品或服务的核心功能。设计这种测试是为了证明这个核心功能符合某个规范。举个例子，我的在线拍卖显示的是输入的正确出价吗？我的保险经纪人系统找到最便宜的报价了吗？如果这些测试失败，通常就意味着检测到了产品的一个基本问题（这个问题通常是可以直接修复）。这种测试也是适合简单的 Web 服务，使您可以检查服务是否能够正确执行它的各个功能。 系统测试（System Test）通常是在功能验证阶段完成，验证了核心功能后进行。它倾向于把整个系统作为一个整体来查找问题—弄清 Web 服务作为系统的一部分怎样运作，以及Web 服务相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行，所以通常不能给它分配足够的时间来完成。又因为紧张的发行日程安排以及开发的各个重要阶段的后移，系统测试阶段经常被忽略，并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误，这时也来不及确定错误的原因并设法修复它们了。因此，在查找代码错误时，必需把系统测试应用设计得尽可能高效。系统测试通常由三部分组成，它们是： 1.性能（Performance）：这涉及到确定相关的产品统计数据的过程。例如：每秒有多 少条消息？一个服务可同时接受多少个用户？
超实用！手把手教你如何3步进行Web渗透测试！ 一个偶然的机会，有幸邀请到了一家国外专门做web安全的公司来对自己的web系统做安全测试。4周下来，我与几位安全专家多次沟通，完成了对自己系统的威胁建模，渗透测试，白盒测试，一共发现了28个漏洞。经验宝贵，因此有必要好好总结下。 现在，随着企业信息化建设的开展，越来越多的重要数据会以电子媒介的形式存放，这在方便企业办公的同时，也造成了极大的安全隐患。近年来，随着APT攻击的蔓延，使得越来越多的企业遭受不可挽回的重大损失。 在目的明确、装备精良、经验丰富的“雇佣军”式的攻击者面前，传统的安全设备已显得力不从心，企业需要做的是定期开展专业的渗透测试，来降低风险，加固安全。 那么，什么是渗透测试？ 渗透测试，是渗透测试工程师完全模拟黑客可能使用的攻击技术和漏洞发现技术，对目标网
络、主机、应用的安全作深入的探测，发现系统最脆弱的环节。 如果说安全检测是“横向地毯式自动化扫描”，那么渗透测试就是“纵向深度人工化入侵”。可见渗透测试的目的是发现目标系统潜在的业务漏洞风险。 安全问题都体现在输入输出的问题上，能够分析数据流就有迹可循了。先知道渗透测试的流程，用工具找到漏洞，了解并且复现它。 如何进行Web渗透测试？ 1、完整web渗透测试框架 当需要测试的web应用数以千计，就有必要建立一套完整的安全测试框架，流程的最高目标是要保证交付给客户的安全测试服务质量。 立项：项目建立，时间安排，人力分配，目标制定，厂商接口人确定； 系统分析&威胁分析：针对具体的web应用，分析系统架构、使用的组件、对外提供的接口等，以STRIDE为威胁模型进行对应的安全威胁分析，输出安全威胁分析表，重点关注top3威胁； 制定测试用例：根据威胁分析的结果制定对应的测试用例，测试用例按照模板输出，具备可执行性； 测试执行&漏洞挖掘：测试用例执行&发散测试，挖掘对应的安全问题or漏洞； 问题修复&回归测试：指导客户应用开发方修复安全问题or漏洞，并进行回归测试，确保安全问题or漏洞得到修复，并且没有引入新的安全问题； 项目总结评审：项目过程总结，输出文档评审，相关文档归档。