您现在的位置：
& &&敏捷测试是否写测试用例
敏捷测试是否写测试用例天极网 15:59
　　敏捷测试是否写测试用例?答案多种化如果是你,你会选用写还是不用写呢?
　　软件测试时代风起云涌,问题虽小,意义却大,让大家一起学习一起探讨!
　　经过大家的水深火热的探讨答案出来了,但是各有各的想法各有各的不同,但我想他们的所想和所论对于大家都是有帮助的,大家可以看一下这个讨论题,希望在技术上能帮到大家一些。
　　LoveTT : 我觉得敏捷测试不需要写测试用例;
　　所谓敏捷，就是要快准狠，快速的找到系统中存在的问题，高效率的完成测试任务!
　　谁来跟我辩论?
　　傲气凌云 : 我认为需要写，因为所有的用例都是人类靠思维来编写的，不是凭空出现的。就算是敏捷性测试，也是需要记录的。
　　tigerbbs : 在敏捷开发中，测试管理者不可能像传统的项目测试一样制定详细的测试计划，那怎样执行测试呢?以下是我总结的一些琐碎经验： 在敏捷开发中整个团队都是测试人员，一起需要对产品质量负责，测试管理人员需要指引大家共同测试，需要发动起大家一起执行测试，而不仅仅是测试人员的事情，这同时也要求整个团队中每个成员对自己的产品了如指掌，测试人员需要共同参与产品的设计和需求分析，在敏捷开发中需求在不断变化，你不可能等着完整的需求文档进行测试需求分析，当产品定义和需求不断的细化时，测试分析也要不断的细化，我很喜欢让测试人员去绘制业务流程图，以及整理功能列表进行测试分析，因为在绘制业务流程图中你可以发现很多的逻辑问题，和产品定义问题，可以即时的和产品定义人员、需求人员进行沟通，立马改进产品设计，敏捷测试中，根据业务流程图或测试分析图书写主要测试用例就行了，你根本就没有时间能面面俱到去维护那么的测试用例，更何况需求和产品定义一直在变化一定要自动化测试，自动化测试脚本中要写好注释，这是测试用例的体现，也便于读取在测试之前制定好测试方案，但测试执行的时间很难控制，一定要熟知数据库。
　　LoveTT : 楼上的傲气凌云 有点狡辩了，混淆视听，人类的精髓很多，马克思主义毛泽东思想，都是人类的精华，但是这些老前辈都还说，具体问题具体分析呢，而你一概而论，我觉得站不住脚!我觉得阁下还是好好看看什么是敏捷开发，和敏捷测试再来发表见解吧!否则贻笑大方就不好了!
　　test110 : 肯定得写哈，那是测试的依据。
　　敏捷宣言：
　　个体和交互比过程和工具更有价值;
　　能工作的软件比全面的文档更有价值;
　　顾客的协作比合同谈判更有价值;
　　及时响应变更比遵循计划更有价值。
　　并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认为很多方法、很多地方都可以敏捷的思想，实现敏捷的管理。
　　测试用例的设计是其中一项。
　　测试用例的粒度
　　测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试(Exploratory Testing)中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。
　　测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
　　测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
　　大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
　　软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。
　　基于需求的测试用例设计
　　基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
　　要把测试用例当成“活”的文档(Effective Software Testing : 50 Specific Ways to Improve Your Testing C Elfriede Dustin)，因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。
　　不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。
　　测试用例的评价
　　测试用例设计出来了，质量如何，如何提高测试用例设计的质量?就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。
　　测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
　　除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。
　　因此，参与到测试用例设计和评审中来的人除了测试人员自己和管理层外，还应该包括最终用户或顾客代表，还有开发人员。
　　测试用例数据生成的自动化
　　在测试用例设计方面最有希望实现自动化的，要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现，但是数据则不同，数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。
　　很多时候，测试用例的输入参数有不同的类型、有不同的取值范围，我们需要得到测试用例的输入参数的不同组合，以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛，我们又需要科学地筛选出一些有代表性的数据，以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。
　　可利用一些工具，例如TConfig、PICT等来产生这些数据。
　　在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。大量数据的准备可以使用多种方式：编程生成、SQL语句生成(基于数据库的数据)、利用工具生成。
　　工具未必能生成所有满足要求的数据，但是却是最快速的，编程能生成所有需要的数据，但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具，例如DataFactory等。
　　seanhe : 先抛观点：需要写测试用例
　　先看测试用例是什么，也就是我们打算进行的测试执行的具体内容
　　测试用例可以分级别：如大纲型、方案型、具体操作数据型，但是根本一点就是要使测试过程有序的进行，尽量少做无必要的重复。
　　敏捷宣言是什么?拥抱变化
　　拥抱变化不代表着杂乱无章，代码即文档，不代表着代码没有注释，所有人都靠代码去看逻辑。
　　敏捷下测试是需要规划的，用例是需要书写的，但是书写的用例并不应该是我们通常意义上非常详尽的测试用例，而可能演变成单元测试框架或者功能自动测试框架，或者测试大纲。
　　总之，测试过程是需要规划的，在有效规划的前提下，尽量少的做无用工作
　　LoveTT : 楼上的Test110写了很多关于测试用例设计的东西，写道粒度问题!我不知道这些你是从哪里抄来的，但是我觉得用例这样写没有问题，但是敏捷测试作为一种特殊的测试类型如”tigerbbs“所说 因为敏捷开发和测试的快捷性和多变性，导致测试的设计变得困难，或者根本就没办法实现”你根本就没有时间能面面俱到去维护那么的测试用例，“正如文章中提到，所以我觉得楼上的论据站不住脚，如果说一般的测试类型，应该没有问题的!
　　魅力 : 我认为测试用例是一定要的，没有用例怎样做到快和准?请问LOVETT一个系统中你能记住那里测过那里没有测过?等到新的版本出来，恐怕就会乱套了吧，何来快准狠?敏捷有从何体现?
　　test110 : CASE也有简单和复杂呀~~`针对不同的项目也可以具体考虑的，但是肯定是必须写的
　　LoveTT : 楼上的说道用例设计过程中的跟踪，说道那些是测试了那些是没有测试，这个我们完全可以通过功能点，或者流程图等跟踪方式进行跟踪，只要我所有的需求被覆盖被测试，就可以了!
　　shinnoshi : 敏捷测试需要写测试用例，既然是敏捷测试，就应有与其相衬的敏捷测试用例。
　　敏捷测试同样需要合理的分析，快速、准确并不应建立在毫无条理的测试中。敏捷不是抛弃所有只注重效率。
　　test110 : 其实我们在这里说的都是理论的，老大弄个模拟环境吧 我们实际做下就得了的 我很现实的，实践才是真知
　　LoveTT : 楼上的又在教条主义，和本本主义，你为什么说测试必须写测试用例呢!
　　另外敏捷测试作为一种快速的测试方式，我们没有必要把时间花费到用例设计的过程中，但是我们当然需要设计，但设计的不是测试用例，而是细化的需求!
　　test110 : 设计case都是测试流程中的一部分的，我们平时测试项目也是按照流程去测试的，也就是说流程制约着我们去测试的，如果我们把测试流程做得很细化了的，那我们的测试就是很精确的，我们得一步一步的走，设计case必须是测试流程中的一部分
　　实际还有一个问题的，就是时间!我们在前期就把时间放在case的设计上的，到我们实际测试的时候就会节约很多时间的;如果你一边测试一边在自己大脑中设计case肯定会浪费时间的，而且还会造成自己和项目组内的人一种紧张的气氛。 大家可以对比下的，case在前期设计和在测试过程中设计，那个更节约时间!那个 效率更高的
　　pi_pi : 个人觉得不管是为了告诉领导你做了那些东东，还是自己记录分析自己的测试思路和策略也好，暂且不管用例的简易复杂程度有多少，这个用例肯定是需要写的。
　　魅力彩虹 : 没有用例的测试是不可行的，首先你的测试是不是有效的验证了需求呢?要有一个测试的执行步骤和执行数据，通过评审之后才能够成为可行的测试。否则只是个人进行的测试怎样判定是系统真的有缺陷还是测试的过程或测试的理解存在问题?总不能等到发现问题后再来讨论测试步骤及测试数据你是否合理吧?即使可以，又怎样能够正确的描述出当时的操作步骤呢?
　　angel0527 : 在对一个系统进行测试之前，都会去找测试点，再从测试点整理出测试用例。只是所整理用户的简单复杂程度不同。
　　如果不去整理测试用例，就没有办法明确是否将该进行测试的点都已经测试完。有可能会做许多重复的工作。这样就谈不上敏捷了。
　　shinnoshi : 如果说没有必要写测试用例，其实最终想说的就是时间，写测试用例需要时间，需要大量的时间。
　　其实不然，清晰的了解需求，用简洁的语言，可以是符号语言，从代码级出发，与开发同步，直到最终的组件完成。如果说你在开发人员写代码的时候都无法利用，那你所谓的时间真的很不够。随着开发的继续，反复的回归测试，如若不是记忆力超群，测试已经达到什么程度，你能给出一个准确的答案吗?
　　LoveTT : 请16楼的朋友注意，你说的一你们平常的工作，第一点，你们做的不是敏捷开发，当然你们也不是敏捷测试，你们按部就班没有问题，但是我们今天的辩题是”敏捷测试“作为现在一个新的概念，或者一种新的方法，正在为大家研究，所以你的经验主义不值得一提
　　appoint : 测试肯定要用到测试用例。敏捷开发是靠测试来驱动开发，测试通过了开发就完成了。所以支持正方观点
　　LoveTT : to魅力彩虹
　　一看你就是科班出身，是做质量管理的吧!
　　什么事情都看得这个规矩，我觉得规矩没有错，但是规矩制约了发展就是错误了，你所谓的评审，审核，在一般的测试过程中是没有问题的，而在敏捷测试过程中，他的测试团队覆盖面很广，可以快速的识别问题并且修改问题，要是等待你的评审恐怕黄花菜都凉了!
　　魅力彩虹 : 楼上LOVETT的观点我不同意，你老说这个教条，那个是平时的工作，不是做敏捷测试。那请问一下你做过敏捷测试吗?你的观点依据又是什么呢?
　　LoveTT : 根据我这个测试新手孜孜不倦的学习，倒是接触过一些，记得前几天IBM刚开了一个什么大会好像这个论坛中也有报道，我演戏了他的整个敏捷开发的过程，以及他的质量控制方法，所以我以此为依据说出上述论断，大家要是有争议，可以看IBM关于敏捷开发的文章
　　魅力彩虹 : TO LOVETT
　　评审用例不仅是规矩的问题，用例不去评审就盲目的执行，怎样保证执行的正确性?发现了BUG怎样反应给开发人员?有些用例你认为覆盖了需求，你有怎样知道自己执行的用例真正体现了需求的定义?如果根据个人临时在大脑中想到的用例来测试系统，测试的有效性和以体现
　　LoveTT : 《Agile Testing - What it? Can it work?》和《Agile Testing Challenges》
　　大家可以看一下这个两本书!
　　所以我觉得敏捷测试有没有设计测试用例，要不要评审，这个是两个概念，楼上的跑题了
　　大家可以看一下，以前本论坛的一个版主的博客关于敏捷测试的文章：
　　http://blog.csdn.net/Testing_is_believing/category/333219.aspx
　　傲气凌云 : 34# LoveTT
　　但是在你工作中，你可以这么做吗?即便是公司就你一个测试人员，也是需要编写测试用例的。同样，也就伴随着评审等一系列活动。
　　shinnoshi : 敏捷是少文档，少流程，多沟通，使开发与测试更加紧密。不是不需要文档，不需要流程，不需要测试用例。
　　请问你提及的测试通过，开发完毕是用什么来衡量的?
　　ash : 敏捷的不是反文档的。
　　测试用例最终生成也会以文档数据方式存在，并且是显性知识，是可以传播、共享和继承的。(不清楚看下面解释)
　　我们应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。
　　因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。
　　new.bug : 个人觉得，敏捷测试只是相对而言的，比如让你测试一个比较复杂的系统，功能很多，那你说不用测试用例怎么比较有条理的进行测试?
（作者：zhengzhong责任编辑：郑重）
欢迎在新浪微博上关注我们
办公软件IT新闻整机Advertisement
测试人员在敏捷过程中的挑战
导读：Lam是一位资深的敏捷测试专家，他最近撰文分析了测试人员在敏捷过程中的挑战，指出现在许多敏捷实践忽视了测试人员的处境和压力，并提出了自己的一些解决办法。关键词：&&&
Lam是一位资深的敏捷测试专家，他最近撰文分析了测试人员在敏捷过程中的挑战，指出现在许多忽视了测试人员的处境和压力，并提出了自己的一些解决办法。他说，Agile宣言已经诞生十多年了，从那时起，越来越多的开发人员投入到敏捷的怀抱，如今，敏捷方法已经主宰了软件开发领域，从而取代了瀑布式方法的领导地位。但是在实现敏捷的过程当中，有一些人被忽视了——测试人员。关注于交付高质量产品、无需太多的文档记录，对于开发人员来说是一种积极的转变。通过时刻谨记最终用户的需求、积极地建立用户反馈过程，项目通常会交付更快更好地交付软件。有时候开发人员会以为敏捷方法就是针对开发者自身的，从而忽视了测试人员。正如敏捷指南所说的，敏捷团队必须邀请测试人员参与。 Vu表示，很显然，会完全地颠覆传统测试实践，但是很多公司在帮助测试人员处理这些新挑战方面无动于衷。他举了一个例子： 假设一个典型的敏捷团队，由五位开发人员和两位测试人员组成。从开发的角度来看，五位开发人员能够以一种稳定、可衡量的速度工作，在新版本中加入新特性。但是对于测试人员来说，事情没有这么简单。 起初，测试每一个冲刺（Sprint）不是问题，因为此时测试人员面对的特性数量有限，并不多。但是随着开发过程前进，测试人员需要测试新特性、验证bug修复，同时还要执行回归测试。一切都要在单个冲刺中测试完毕。冲刺周期越短，回归测试的次数就越多。很多，测试团队就不堪重负了。 自动化单元测试可以提高代码的质量，缓解测试人员的压力，但是他们的负担还是很重。两位测试人员如何同时测试所有新特性同时还做验证和回归测试？答案就是No。 为了确保高质量的产品，Vu指出，管理层可能会考虑随着开发进度扩大测试团队的规模，但是还有其他更有效率的解决方案。回归测试可以做文档记录并且自动化。在代码交付之前，测试人员是无法完成这些测试用例和脚本的。新功能测试和Bug验证是测试人员应该重点关注的地方。 对于来说，Vu表示，测试人员需要和开发人员一样采纳相同的敏捷思想，但是抛弃传统的瀑布式过程需要引入一些规划。在敏捷之前，测试人员的工作包括阅读和理解用户需求，编写测试用例，然后测试软件。对于敏捷项目来说，测试人员无法在构建产生之前完成测试用例，因为需求不是很详细。 因此，测试人员必须做出改变——利用探索性测试来处理新功能，同时编写一定数量的核心测试用例用于以后的回归测试，并且尽早自动化。 Vu建议，因为缺乏详细的需求和文档，敏捷模式下的测试人员必须尽量理解最终用户的需求，这包括了解他们需求什么和如何使用软件。这意味着测试人员需要参加Scrum会议、研究用户故事、提出问题。理想情况下，测试人员应该是最终用户的代言人。 测试人员需要具备怎样的敏捷思想？测试专家Janet在“敏捷测试指南”一书中对敏捷测试思想做了详细的描述。 如何使一个团队变得“敏捷”？对我们而言，敏捷团队持续关注如何最出色地工作并发布最优秀的产品。根据我们的经验，这需要大量的训练、学习、时间、实验和协同工作。这并不适合所有人，但是对那些希望自己团队充满活力并关注持续改进的人来说非常适合。成功的项目总是因为优秀的人才完成了出色的工作。在敏捷团队中做一名成功的测试人员所需要的特质可能与在任何团队做一名高水平的测试人员所需要的相同。 敏捷测试人员不会把自己看作是质量管理办公室的主管以保护客户避免受到缺陷代码的伤害。她会乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自己的需求，从而得到他们需要的功能，同时向所有人提供项目进展的反馈。 正如Janet所述，敏捷测试人员，可能包括其他拥有正确技能和思想的测试人员，都在不断想办法使团队能够更好地生产高质量的软件。对个人来说，这可能意味着需要出席本地用户组会议或者圆桌会议看看其他团队在做什么，同时寻找新的工具以帮助团队通过测试描述、执行和自动化用户需求。基本要求就是敏捷测试人员和其他敏捷团队成员一样，乐于学习新技能和面对新挑战，不会仅仅局限于测试问题。这不只是测试人员的特征，所有敏捷团队人员都具有。敏捷测试人员帮助开发人员和客户团队解决可能出现的任何问题。测试人员提供信息以帮助团队回顾和了解哪些方案有效、哪些无效。创造力、接受新思想、乐于承担任何任务或角色、重视客户和持续关注全局只是敏捷测试思想的组成部分。优秀的测试人员都有一种直觉和理解力：软件可能在何处失败？如何定位失败？测试人员可能在测试领域拥有特殊的技能和经验，但是一名优秀的测试人员并不惧怕参与一场设计讨论，提供有助于测试性或者构建更良好方案的建议。敏捷测试思想是面向结果的、技术性的、协作的、乐于学习的、勇于不断生产业务价值的。
测试人员在敏捷过程中的挑战
原文出处：q.com/cn/news/2013/09/agile-testing-challenge
LoopBack是一个基于Node.js、开源的API框架，可以使基于Node.js的应用与各种移动设备通过API进行互联。
本文给出了一些在Python初学者中很常见的反模式，反模式通常是指那些不符合习惯或者会导致糟糕后果的用法。
根据一个非盈利的软件解决方案提供商的主管的说法，对于非营利组织来说，开源软件/自由软件可能不是最佳的解决方案。
开源项目如今可谓无处不在，从Web到个人计算机再到智能手机，我们似乎随处可见它的身影。在今天的文章中，我们将共同探讨开源的三个话题。
Molecule是专为游戏开发爱好者构建的一个HTML5框架，兼容所有主流浏览器，且在移动设备方面也有着很大的优化。目前最轻量级以及高效的HTML5游戏引擎之一，而且完全免费。
TechTarget中国官方微信
热门技术手册
本专题分六部分探讨SOA设计模式，当初设计面向服务架构的一大初衷就是降低服务间耦合度，由此提高服务的灵活性和自由度。
ESB（Enterprise&Service&Bus，企业服务总线）是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。
TOAGF是一个架构框架，简而言之，TOGAF是一种协助发展，验收，运行，使用，和维护架构的工具。它是基于一个迭代（Iterative）的过程模型，支持最佳实践和一套可重用的现有架构资产。
业务流程管理（business&process&management，bpm）不是一个新概念，甚至不是一个新名词。它是从相关的业务流程变革领域，如业务流程改进（bpi）、业务流程重组（bpr）、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、eai、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。
近一年来，大数据的热潮席卷全球，我们无时无刻不在听着关于大数据的事情。大数据时代带来更理性、更可靠的决策，但究竟是什么魔力让大数据这一概念得到全球各国的普遍关注？如此巨大量的数据如何进行管理，分析，找到价值所在？SOA又能帮助大数据做一些什么？Web安全测试 _百度百科
特色百科用户权威合作手机百科 收藏 查看&Web安全测试本词条缺少名片图，补充相关内容使词条更完整，还能快速升级，赶紧来吧！
在你对Web应用所执行的测试中安全测试可能是最重要的但它却常常是最容易被忽略的Web安全测试中的秘诀演示了开发和测试人员在进行单元测试回归测试或探索性测试的同时如何去检查最常见的Web安全问题与即兴的安全评估不同的是这些秘诀是可重复的简洁的系统的可以完美地集成到你的常规测试套装中因此本书对开发人员和测试人员具有重要的指导价值外文名Web security testing作　者：霍普(PacoHope)
书 名: Web安 全测试
作　者霍普(PacoHope)
出版时间 日
定价: 39.00元
Web安全测试内容简介　Web安全测试中的秘诀所覆盖的基础知识包括了从观察客户端和服务器之间的消息到使用脚本完成登录并执行Web应用功能的多阶段测试在Web安全测试的最后你将能够建立精确定位到Ajax函数的测试以及适用于常见怀疑对象跨站式脚本和注入攻击的大型多级测试Paco Hope是Cigital公司的一名Mastering FreeBsD and 0penBsDsecurity 由OReilly出版的合著者之一他也发表过有关误用滥用案例和PKI的文章他曾被邀请到会议就软件安全需求Web应用安全和嵌入式系统安全等话题发表演讲在Cigital他曾担任MasterCard Internationa在安全策略方面的主题专家而且曾协助一家世界500强的服务业公司编写软件安全策略他也为软件开发和测试人员提供软件安全基础方面的培训他还曾为博彩业和移动通信行业中的几家公司提出过软件安全方面的建议Paco曾在主修计算机科学和英语并从获得计算机科学方面的理学硕士学位
Ben Waltller是Cigital公司的一名顾问Edit C00kies工具的开发者之一他同时参与标准质量保证和软件安全方面的工作他日复一日地设计和执行测试一一因此他理解忙碌的QA领域对简单秘诀的需求他也曾对开放式Web应用程序安全项目0WAsP的成员就w曲应用测试工具发表过演讲你还能赢得荣誉序 1
第1章 绪论 13
1.1 什么是安全测试 13
1.2 什么是Web应用 17
1.3 Web应用基础 21
1.4 Web应用安全测试 25
1.5 方法才是重点 26
第2章 安装免费工具 29
2.1 安装Firefox 29
2.2 安装Firefox扩展 30
2.3 安装Firebug 31
2.4 安装OWASP的WebScarab 32
2.5 在Windows上安装Perl及其软件包 33
2.6 在Linux, Unix或OS X上安装Perl和使用CPAN 34
2.7 安装CAL9000 35
2.8 安装ViewState Decoder 36
2.9 安装cURL 36
2.10 安装Pornzilla 37
2.11 安装Cygwin 38
2.12 安装Nikto 2 39
2.13 安装Burp Suite 40
2.14 安装Apache HTTP Server 41
第3章 基本观察 43
3.1 查看网页的HTML源代码 44
3.2 查看源代码高级功能 45
3.3 使用Firebug观察实时的请求头 48
3.4 使用WebScarab观察实时的POST数据 52
3.5 查看隐藏表单域 55
3.6 使用TamperData观察实时的响应头 56
3.7 高亮显示JavaScript和注释 59
3.8 检测JavaScript事件 60
3.9 修改特定的元素属性 61
3.10 动态跟踪元素属性 63
3.11 结论 65
第4章 面向Web的数据编码 66
4.1 辨别二进制数据表示 67
4.2 使用Base-64 69
4.3 在网页中转换Base-36数字 71
4.4 在Perl中使用Base-36 71
4.5 使用以URL方式编码的数据 72
4.6 使用HTML实体数据 74
4.7 计算散列值 76
4.8 辨别时间格式 78
4.9 以编程方式对时间值进行编码 80
4.11 解码多重编码 83
第5章 篡改输入 85
5.1 截获和修改POST请求 86
5.2 绕过输入限制 89
5.3 篡改URL 90
5.4 自动篡改URL 93
5.5 测试对URL长度的处理 94
5.6 编辑Cookie 96
5.7 伪造浏览器头信息 99
5.8 上传带有恶意文件名的文件 101
5.9 上传大文件 104
5.10 上传恶意XML实体文件 105
5.11 上传恶意XML结构 107
5.12 上传恶意ZIP文件 109
5.13 上传样例病毒文件 110
5.14 绕过用户界面的限制 111
第6章 自动化批量扫描 114
6.1 使用WebScarab爬行网站 115
6.2 将爬行结果转换为清单 117
6.3 减少要测试的URL 120
6.4 使用电子表格程序来精简列表 120
6.5 使用LWP对网站做镜像 121
6.6 使用wget对网站做镜像 123
6.7 使用wget对特定的清单做镜像 124
6.8 使用Nikto扫描网站 125
6.9 理解Nikto的输出结果 127
6.10 使用Nikto扫描HTTPS站点 128
6.11 使用带身份验证的Nikto 129
6.12 在特定起始点启动Nikto 130
6.13 在Nikto中使用特定的会话Cookie 131
6.14 使用WSFuzzer测试Web服务 132
6.15 理解WSFuzzer的输出结果 134
第7章 使用cURL实现特定任务的自动化 137
7.1 使用cURL获取页面 138
7.2 获取URL的许多变体 139
7.3 自动跟踪重定向 140
7.4 使用cURL检查跨站式脚本 141
7.5 使用cURL检查目录遍历 144
7.6 冒充特定类型的网页浏览器或设备 147
7.7 以交互方式冒充另一种设备 149
7.8 使用cURL模仿搜索引擎 151
7.9 通过假造Referer头信息来伪造工作流程 152
7.10 仅获取HTTP头 153
7.11 使用cURL发送POST请求 154
7.12 保持会话状态 156
7.13 操纵Cookie 157
7.14 使用cURL上传文件 158
7.15 建立多级测试用例 159
7.16 结论 164
第8章 使用LibWWWPerl实现自动化 166
8.1 编写简单的Perl脚本来获取页面 167
8.2 以编程方式更改参数 169
8.3 使用POST模仿表单输入 170
8.4 捕获和保存Cookie 172
8.5 检查会话过期 173
8.6 测试会话固定 175
8.7 发送恶意Cookie值 177
8.8 上传恶意文件内容 179
8.9 上传带有恶意名称的文件 181
8.10 上传病毒到应用 182
8.11 使用Perl解析接收到的值 184
8.12 以编程方式来编辑页面 186
8.13 使用线程化提高性能 189
第9章 查找设计缺陷 191
9.1 绕过必需的导航 192
9.2 尝试特权操作 194
9.3 滥用密码恢复 195
9.4 滥用可预测的标识符 197
9.5 预测凭证 199
9.6 找出应用中的随机数 200
9.7 测试随机数 202
9.8 滥用可重复性 204
9.9 滥用高负载操作 206
9.10 滥用限制性的功能 208
9.11 滥用竞争条件 209
第10章 攻击AJAX 211
10.1 观察实时的AJAX请求 213
10.2 识别应用中的JavaScript 214
10.3 从AJAX活动回溯到源代码 215
10.4 截获和修改AJAX请求 216
10.5 截获和修改服务器响应 218
10.6 使用注入数据破坏AJAX 220
10.7 使用注入XML破坏AJAX 222
10.8 使用注入JSON破坏AJAX 223
10.9 破坏客户端状态 224
10.10 检查跨域访问 226
10.11 通过JSON劫持来读取私有数据 227
第11章 操纵会话 229
11.1 在Cookie中查找会话标识符 230
11.2 在请求中查找会话标识符 232
11.3 查找Authentication头 233
11.4 分析会话ID过期 235
11.5 使用Burp分析会话标识符 239
11.6 使用WebScarab分析会话随机性 240
11.7 更改会话以逃避限制 245
11.8 假扮其他用户 247
11.9 固定会话 248
11.10 测试跨站请求伪造 249
第12章 多层面的测试 251
12.1 使用XSS窃取Cookie 251
12.2 使用XSS创建覆盖 253
12.3 使用XSS产生HTTP请求 255
12.4 以交互方式尝试基于DOM的XSS 256
12.5 绕过字段长度限制XSS 258
12.6 以交互方式尝试跨站式跟踪 259
12.7 修改Host头 261[1]
12.8 暴力猜测用户名和密码 263
12.9 以交互方式尝试PHP包含文件注入 265
12.10 制作解压缩炸弹 266
12.11 以交互方式尝试命令注入 268
12.12 系统地尝试命令注入 270
12.13 以交互方式尝试XPath注入 273
12.14 以交互方式尝试服务器端包含SSI注入 275
12.15 系统地尝试服务器端包含SSI注入 276
12.16 以交互方式尝试LDAP注入 278
12.17 以交互方式尝试日志注入 280
新手上路我有疑问投诉建议参考资料 查看}