联想集团CEO杨元庆近日谈及这一变革时表示，互联网的时代，要更加积极，更加进取，不能被动，不能保守。

　　杨元庆说，这些方面，陈旭东也都是强项，他喜欢尝鲜，喜欢尝试，喜欢冒险，他有开放的心态，能够拥抱互联网，这些都是联想移动需要有的精神。

　　杨元庆对联想移动原有团队的不满很明显。杨元庆说，现在需要的竞争力已经完全不同。“我去年跟你们说了几次，要醒一醒，我甚至还说了你们拿榔头敲都敲不醒，你们太慢了，在错失机会。”

　　杨元庆对陈旭东团队提出了要求：不能固步自封，要有更强烈的互联网思维和基因。

　　权力是春药，即使旁观人事变动、权力更迭也能让人血脉偾张。

　　2015年6月1日晚，联想集团发布了人事变更声明：联想执行副总裁、移动业务集团总裁及摩托罗拉管理委员会主席刘军，将离开现在的岗位，在一段时间内担任移动业务及战略方面的集团CEO特别顾问。同时宣布陈旭东出任移动业务集团领导人及摩托罗拉管理委员会主席，任命从即日起生效。

　　这是一场蹊跷的离职，要知道离职者可是被认为是联想集团的二号人物，在刚刚结束的联想tech world大会上，他还详解了联想手机的下一步规划和安排。关于离职原因，甚至在官方声明中也未做解释。

　　我们可以认为是最高层对他几年业绩的不满吗?

　　刘军被派去接管手机时，当时联想手机的市场份额只有0.9%，而且还是在联想重金推出一代乐phone刚刚铩羽而归，完全失去方向和节奏之时。

　　刘军上任后设定的最主要目标是规模。他认为，“如果没有规模，就无法在行业里立足。因为规模决定了采购成本，决定了上游厂商的支持力度”。

　　当时智能手机市场主流价格在2000元左右， 刘军决定以1000块可能将引爆市场，于是联想和联发科合作，只用了大概5个月时间，就完成了产品定义到产品上市，率先推出双卡双待的千元智能手机A60，而且在长达一个季度的时间内，联想独占了这个市场。A60是联想的明星机型。

　　在规模至上的理念中，联想很长时间里在手机渠道战略中有70%份额依赖于运营商渠道。这导致的后果是不断压低成本、机海战术以及对其他渠道的弱化。而这些，都在运营商渠道生变之后，对联想的发展形成重重压力。

　　相较其他品牌，联想的互联网手机品牌一直没有特别亮眼表现，而差不多同样基础的华为荣耀，则短短一年多时间，完成初步积累。

　　在手机厂商都在致力完成“软件+硬件+服务”三位一体的流行趋势中，联想也没有落下。而且还推出过茄子快传等明星应用，但由于观念没有“软化”，这些应用并没有投入更好地服务支持。联想软件的适配和优化都与一流国产厂商存在巨大差距。以至于在友盟的统计中，互联网服务应用最活跃的机型仍然来自三星、小米等热门机型。

　　而受累于运营商渠道的过分依赖，数据显示，联想移动业务的总销售收入占集团整体收入约20%，但移动业务集团仍亏损3.7亿美元。

　　这些都说明，虽然联想一直在追求转型，但还是非常彻底的一家硬件厂商。

　　但这一切，很难说是刘军的错，他根植于联想，他的思路根本就是联想集团在PC时代思路延续。规模、成本、供应链管理。。。不就是联想PC成功的关键吗?如果联想移动要成功，那势必是要从联想的最根部做革命性改变，这恐怕是个一把手工程。

　　刘军高大，帅气，与著名模特姜培琳结婚。作为清华同学，他还在高晓松的书《如丧》中出现过，书中刘军作为清华篮球队队员，是个被女生仰慕着的形象，这些都让人觉得他与联想的固有形象会有不同，但他是个地道联想人。

　　刘军1993年清华毕业后进入联想，曾经是联想最年轻的部门总经理、“联想十八棵青松”之一，是联想内部“专门来打硬仗的人物”。加入联想的第二年，刘军就开始与杨元庆一起工作，到1996年，开始直接向杨元庆汇报工作，一直是他的得力干将，两人一起度过很多艰难时刻。杨元庆的办公桌上曾经长期有一张照片，是他和刘军等人十多年前在美国拍下的。当时抱着取经心态到硅谷参观过英特尔等公司之后，激情澎湃的几个人，在那里立下远大志向：要让联想十年成为国际品牌。#p#分页标题#e#

　　联想收购IBM PC之后，一度引入以戴尔系阿梅里奥作为CEO，这位CEO认为当时主管供应链的刘军表现不佳，当时以杨元庆为首的中国人在董事会话语权不高，刘军被迫下课。

　　对于这件事，柳传志曾回忆道，“专项战略委员会汇报的时候给刘军打的分数很低，我当时差一点流眼泪，……一员大将的培养真的不知道经过多少磨难。”后来2009年，柳传志复出，刘军再次进入联想最高经营8人管理团队“联想执行委员会”。

　　2013年，联想宣布重组业务部门，分拆成Lenovo业务集团和Think业务集团，刘军成为Lenovo业务集团负责人。大概就是在这个时候，联想内部传出刘军将成为接班人的传闻，毕竟他掌管代表未来的移动业务。而在此之前另外一位大将陈绍鹏已被调到联想控股负责农业板块，陈本来是另外一位接班候选，将陈绍鹏调走外界多认为这是柳传志的安抚之举。

　　附：杨元庆与移动业务管理团队内部沟通会讲话速记

　　很多人都很惊讶，也都很想知道为什么做这个变化。这当然跟我们现在的业务状况有关系，但我相信每个人都知道，业务状况是种什么瓜，得什么果，是长期积累的结果。我们的个人电脑业务，在过去这些年突飞猛进，并不是一日之功，也是经过很长时间的准备，积蓄能量，把核心竞争力建立起来之后，才有后来的腾飞(take off)。

　　这次的调整，无关乎责任，而关乎机遇。当然我们应该从过去吸取经验和教训，但我们更要关心未来怎么做，未来有什么样的机会。如果大家要记住一个理由，一个原因，一个词，那就是CHANGE(改变)。今天的状况，很大的原因就是我们用过去做事情的经验来做新的业务，我们在PC上的成功经验，想用在手机上;我们传统的经验，想用在互联网时代……

　　正是这些根深蒂固的mindset(意识)的东西，这些深入到基因的东西，造成了今天的结果和状况。所以，不变化，肯定不会看到成功的结果。这就是最重要的，最根本的原因。

　　我们过去做PC，产品比较简单，所谓用户体验，更多不是由我们掌控，而是由微软掌控，所以我们只要把硬件跟操作系统弄顺了就行。但现在，用户体验每一家都不同，它不是由Android掌控，谷歌掌控，而是由我们掌控，尤其是在中国，这对我们做产品提出了更高的、更苛刻的要求。

　　互联网提供了直接接触用户的方式。今天我们可以跟用户直接互动，了解他们的需求，响应他们的反馈，对产品做快速的开发和迭代，让用户体验最优。

　　过去我们的销售方式也是很传统的，从分销商、代理商、零售商，再到用户，手机渠道，40%多的利润+费用，而小米们没有这些，我们怎么跟他们竞争?

　　营销也一样，这已经不是大把撒钱的时代了，而是靠脑子、靠智慧营销的时代。我们现在开始用微博、用微信，才意识到过去有多吃亏。如果今天有上千万的粉丝，只要发一个微博，那就是广告，一分钱都不用花。

　　在此之前，别人已经做了多少免费的广告?过去我们是有变化，但只是把传统媒体转到了数字化媒体(网络媒体)，没想到社交媒体已经如火如荼，让竞争对手们占了那么大的便宜!直到开始做了，才有所体会，做的好，做的差，确实是天壤之别。

　　所有的环节，昨天和今天都已经不同。所以我们需要CHANGE。但是我们这支团队，大家可以反省一下，想一想，你们觉得变了吗?你们觉得变得够了吗?

　　这已经不是PC时代，只要靠运营，加上渠道和品牌的优势就能取胜。现在需要的竞争力已经完全不同。

　　我去年跟你们说了几次，要醒一醒，我甚至还说了你们拿榔头敲都敲不醒，你们太慢了，在错失机会。当然，从今年年初开始看到了一些变化的迹象，比如做精品，建on line模式，上微博等等。但是肯定不够，不够到位，也不够快。

　　这就是我们这次调整的意义所在，我们希望能够给这个团队，给这个业务带来更多的变化。这个变化要从头开始，所以首先要从领导人开始，从调整一把手开始。我们希望通过这样的调整，给这个团队注入更多活力，让变革来得更彻底，更到位，更猛烈些。

　　我相信旭东能给这个团队，给这个业务带来很多新的经验、新的能力。他在中国开展业务转型，已有相当一段时间。当然，PC和手机不一样，旭东也不能固步自封。

　　如何从传统模式转向on line和off line结合，在这些方面他还是很有想法的。他在神奇已有半年，在如何把产品做精，与用户互动上，也有更多、更深的体验。他有更强烈的互联网思维和基因。#p#分页标题#e#

　　现在这个互联网时代，尤其是在中国，一方面是要把产品做精做好，但是市场端，如果不能拉住粉丝，不能让粉丝帮着推广，是不可能把产品推广好、销售好的。相信旭东在市场端的优势，会给团队非常多的启发和经验的输入。

　　而且在这个互联网的时代，要更加积极，更加进取，不能被动，不能保守。这些方面，旭东也都是强项，他喜欢尝鲜，喜欢尝试，喜欢冒险，他有开放的心态，能够拥抱互联网，这些都是我们需要有的精神。

　　另外，旭东比较open，国际化的经验也相对丰富，和国际团队的沟通没有什么障碍和芥蒂，容易沟通，容易合作。

　　这点之所以重要，是因为此时，除了要给中国团队注入新的基因，寻求变化和突破以外，还有很重要的一条，是下一步要让MOTO和联想的业务有更深入的整合，更好地实现协同效应。我们相信在旭东的带领下，你们能够把这件事情做好。

　　这也给大家提出了更高的要求，以更开放的心态接受调整、配合调整，以使得两个业务合起来不仅有更多的协同效应，还能为未来建立更扎实的基础。

　　最后一点，我们这个团队，在过去两年里，业绩都是跟预算有差距的，没有达成目标，去年尤为低，造成士气不高，这种情形不能再继续下去了。要想建立一个成功的业务，就必须建立一支有求胜心、并且不断去赢的团队。

　　所以我们要认真做组织整合的方案，要认真地去重定战略、策略，认真做业务计划和目标设定。

　　在做了新的调整之后，就要重新启动，在重新启动之后，就要本着联想说到做到的文化，一步一个脚印地，每一步都踩到点子上，达成目标，真正成为胜利之师!

　　你们都经历过联想的成功。大家都知道2009年，我重新担任CEO之后，给董事会提交了4年计划，之后的每一年，都打超了目标，从而不仅让业务成功，更让士气大振。

　　大家不但想到更高的目标，而且能实现，能打超，然后在这样的情况下，大家再讨论战略也好，再讨论目标设定也好，才会更加火花四溢，激情飞扬，这才是一个胜利之师应该有的情况。我们希望这支团队，从现在开始，能够重新看到这样的精神头和士气。

　　所以说，求变，跟MOTO实现深入整合，以及要建立赢的文化，这就是我们这次做调整的意图所在。

　　在座都是联想的精英，有的久经考验，有的新加入联想，是冲着我们的品牌、文化和机会而来，我们在一起，所要从事的工作，其实是一个非常神圣，非常了不起的事，不仅是联想的战略重点，而且从技术发展趋势看，也是产业发展、技术突破的重要方向，我们要把握这个机会，一起努力配合旭东，把这个事情做漂亮，做成功!

　　人和机器人PK，谁能赢?如果放在新闻媒体这个领域上，最近进行的一场比赛或许能给你一个答案。

　　近日，NPR(美国国家公共电台)向一台可以写新闻的机器人“WordSmith”发起了挑战，NPR派出的选手是驻白宫记者Scott Horsley，他是国外媒体公认的写作能手。

　　在Dennys餐饮公司的财报公布后，Scott Horsley用了7分钟写完了这条新闻，而WordSmith只花了2分钟，但是在稿件质量上，依旧是Scott Horsley获得了更多人的支持。

　　好了，比赛结束，回到现实。

　　此前人们对机器人用途的印象还停留在代替人类从事简单机械的重复劳动上，随着人工智能化程度越来越高，机器人可从事的工作领域也越来越广。

　　去年7月，美联社与Automated Insights公司合作，引入其WordSmith平台自动生产财报报道，此后美联社每季度报道的财报新闻数量从之前的300多篇增长到4400篇，几乎可覆盖美国所有上市公司。

　　此举不光引起了新闻界哗然一片，也使得人们开始密切关注这个会写新闻的机器人。

　　使用机器人写作的媒体有哪些?

　　其实美联社并非是第一家使用机器人写作的媒体，《洛杉矶时报》曾用由其记者兼程序员Ken Schwenck开发的Quakebot系统写作了关于一场4.4级的地震的报道，整个过程耗时仅3分钟，《洛杉矶时报》由此成为最快报道这一突发事件的媒体。此外，《洛杉矶时报》还有另一套报道犯罪新闻的程序。

　　Automated Insights公司表示，除美联社之外，WordSmith合作媒体还有美国最大的有线电视运营商康卡斯特，雅虎也曾用WordSmith生产“梦幻橄榄球(Fantasy Football)”报道。

　　Automated Insights的竞争对手Narrative Science也有一套自动撰写新闻系统，包括《福布斯》在内的20多家媒体都是这套系统的客户，《福布斯》曾使用Narrative Science的服务制作收益预览，还有许多体育网站也使用该公司提供的技术生成实时赛事回顾。

　　机器人如何写新闻?

　　由于机器人有极强的信息抓取和数据处理能力，为提高工作效率，越来越多媒体雇佣起“机器人员工”，让其着手体育赛事、突发事件、财经、数据分析等报道工作。

　　由于财报、体育报道、突发事件等新闻的写作模式相对固定，机器人接收到新闻数据信息后可瞬间反应，将其填入模板，大大加快了写作速度。并且据美联社称，Wordsmith撰写的文章错误率比人工撰写的文章更低，现在已无需人工干预。据悉，Wordsmith平台每周可以撰写数百万篇新闻报道，系统每秒甚至能生产2000篇文章。

　　机器人记者的出现不光缩短了从事件发生到稿件出炉之间的时间差，还能大大降低媒体报道成本。据《纽约时报》证实，美国十大体育电视网在2009年到2010年赛季期间，使用电脑软件写作简要报道占据足球赛事报道的40%，每篇500字左右的新闻报道仅耗资10美元。

　　当人们担心机器人会不会抢了记者、编辑们的饭碗时，业界却有不少人士对于二者间“各司其职”的关系乐观看待。

　　对于记者们来说，整理、编辑枯燥乏味的体育赛事综述、财经报道等简单事实类新闻，无异于对智力和时间的浪费。

　　美联社的执行总编费拉拉表示，自动写稿的机器人可以将记者解放出来，撰写更有深度的稿件。当然，美联社对苹果、谷歌(微博)等受市场高度关注企业的财报新闻还是谨慎地选择人工操作。

　　《纽约》杂志商业与科技版撰稿人凯文•罗斯也非常欢迎“机器人新同事”，并表示从长期来看，启用自动化的报道对新闻记者来说是最大的好消息。

　　人工写作还有未来吗?

　　尽管机器人写作耗时短、成本低、产量高，但并不意味着机器人能超越人类，因为“机器人记者”们本身就存在着难以克服的成长障碍。

　　首先，机器人可操作的新闻题材有限，只能进行需要数据信息转述和简单分析体育赛事、财经类等报道，对于需要运用记者亲身采访和经历的内容的深度报道无能为力;

　　其次，从目前来看，机器人整理好数据之后进行简单归纳，尽量用正确的语法使语句通顺，但难免措辞生硬，连美联社的费拉拉也不得不承认机器人撰写会因内容生硬和重复影响稿件质量。#p#分页标题#e#

　　最后，机器人无法按照人类阅读的喜好和习惯来生产可读性高的文字，只能按照“预设的逻辑规则”来辨认数据中的事实和关键趋势，然后从词库中选取恰当的词汇进行描述，相比人工写作运用灵活的逻辑组织稿件和用生动的语言风格来打动读者，“机器人记者”们只能自叹不如。

　　因此，从整体来看，机器人参与创作的新闻偏于事实类报道，而对于分析、解读、抒情题材类的新闻，仍需要大量的人工编辑。

　　机器正在取代人类的工作。IBM的深蓝曾经打败过世界棋王。在这个智能时代，即使是最有创造性的工作之一：写作，也是可以由机器完成的。

　　雅虎和美联社的相当一部分财报和体育新闻都是机器人写的。它们使用的都是一家叫做Automated Insights的公司开发的软件WordSmith。只要导入最新的数据，1分钟最快可以生成2000篇报道。

　　为了测试机器人和记者谁能写出更好的报道，NPR的驻白宫记者，前任商业记者Scott Horsley和 WordSmith 进行了一场比赛。

　　比赛规则是： Horsley和WordSmith一起等Denny’s餐饮公司出财报，两“人”同时开写一篇短报道，比的主要是速度和质量。

　　Horsley开始很得意： 他是Denny家的常客，甚至有熟识的侍应生知道他喜欢吃什么，他以为能在熟悉的题材中占上风。然而在速度上遭到了挫败：机器人两分钟就写完了，他花了整整7分钟。

　　不过质量上的结果相反。NPR在Polar上发起了投票。截至发稿时，机器人写的文章获得了912票，人类写的获得了9916票。Horsley的文章虽然更长一些，但语言更简明易懂。

　　NPR的报道称，机器可以通过学习写得更好。通过学习一家媒体上的几千篇文章，它能够大致掌握语言风格，甚至玩些常见的梗。如果我司有一个WordSmith，它大概很快就能get到黄姓编辑和刘姓编辑是怎么回事。

　　而对媒体人来说，更理想的报道方式可能是， 让机器人和记者打配合，前者负责快速、全面、准确地发消息，后者负责后续跟进和深入分析。

　　那么，在这个机器入侵的时代，最难被机器人取代的工作是什么?NPR给出的答案是精神健康和社工类的工作。这类工作只有0.3%的可能会被机器取代，因为它需要运用人的智力、协调沟通能力、还有最重要的人性的力量。而最容易被机器取代的工作则是电话推销员，而且这已经成为了现实——现在连10086都自动打电话来催你交话费办业务了。

　　常常觉得我司还是挺需要几台机器人的，只是不知道它们学不学得会中文。

　　一、问题：

　　许多测试类的书籍都有大幅篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图，判定表等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法真正有效的提高测试效率，并且我们也没有足够的时间和资源编写完备的用例。通常我们只能依靠以前项目的用例编写经验(或习惯)，希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。

　　当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

　　* 从此几乎很少被执行

　　* 已经与程序的实现发生了冲突(界面变动，功能变动)

　　* 执行用例发现的bug很少

　　* 根本没有时间为新的功能需求增补用例

　　* 有时间补充，但用例结构越来越乱

　　* 特性的用例与通性用例之间联系不明确(以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化)

　　知道怎样执行这个用例，但它要说明什么呢?(多数用例给我们的感觉是只见树木，不见森林，只说明某一功能的实现，无法串起)

　　通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。

　　但没有用例或简略用例的编写我们又会舒服很多么?不言自明，谁也不想倒退发展。

　　二、原因：

　　事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

　　1、没有适合的规范

　　“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、指导步骤和书本上的定义，但它适合我们当前的项目么?

　　每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好?

　　在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。我们有太多经验，但却没有形成适合的规范。

　　2、功能与业务的分离

　　我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

　　边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

　　复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)，只能自己添加note向开发人员指出可能出错的源头。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的 bug不多。#p#分页标题#e#

　　用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

　　3、测试未能跟上变化

　　变化!想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢?当地区特性，软件版本越来越多的时候，测试是否在积极响应呢?变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

　　对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

　　疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法及时发现。

　　永远是变化决定我们的下一步工作，这也是混乱的开始。

　　三、可能的解决办法：

　　上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。分析错误并不能给我们带来成功，而成功的特质也不会尽为相同。所以在这里我希望以探讨的方式提出一些可能的解决办法，不拘泥形式，以结果来确定，最适合的就是最好的。

　　1、测试驱动开发，用例指导结果，数据记录变化

　　“测试驱动开发”(TDD)是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效(Work)更洁净(Clean)，“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

　　首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80%以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。

　　如何在黑盒测试中做到测试驱动开发?我认为可以从用例级别做起，以业务用例指导实现的结果。

　　开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很全面的指出应该实现怎样的结果，这就使得从业务到功能出现一个“阅读上的障碍”，如果最后发现程序错了还需返工，这样耗费的人力物力就非常大了。测试人员和最终用户不用过分关心软件实现的细节，所以以业务用例驱动开发，就是一个比较好的方法。给出一个明确的预期结果，指导开发人员如何界定是否达成目标，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。

　　业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会出错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

　　我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段(业务段与程序中以窗体或页面的划分是不一样的)，使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。#p#分页标题#e#

　　再进一步的话“数据库”就开始涉及到程序内部的接口，属于单元和集成测试，这需要开发人员的配合。

　　2、为用例标明时间(版本)和优先级

　　为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

　　为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

　　3、功能用例与业务用例分开组织

　　为业务用例单独开辟出一种分类，将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作(例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理?)。

　　4、审核用例，结对编写

　　测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例(前提是你有两个以上的测试人员)，内部审核。

　　测试用例不是自己编写自己执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理负担，提高组员的参与积极性。

　　四、发展

　　上面的这些解决方法只是一种建议，具体如何实施到项目中还需根据情况而定。同时即使我们正在积极的寻求改变，我们还是会碰到无数的新问题和新苦恼，也许会比以前更为众多，这是我们必须付出的。

　　可以看到测试的发展方向很多很广，即使传统的黑盒测试并不是毫无新意，高级的测人员必须同时在测试技巧和专业领域方面都有很高的“修为”。测试工作怎样更适合我们而发展，将给予我们更多的思考。

　　测试经理不知道性能测试人员在做什么

　　不知道性能测试进展如何

　　不知道性能测试是否有效

　　不知道如何协助性能测试人员

　　本文目的

　　了解性能测试的进展，更好的控制整个测试流程

　　了解性能测试的质量

　　十问

　　性能测试何时介入

　　性能测试的过程是怎样的

　　是否有必要提起性能测试

　　性能测试有哪些类型

　　如何分析性能需求

　　如何衡量性能

　　性能测试(不)能做什么

　　如何检验性能测试的质量

　　…

　　Q1、性能测试何时介入

　　开发生命周期中的性能测试

　　单元测试

　　代码层面的测试。写完一块代码，对代码的执行效率、内存使用、资源占用等情况进行测试，由开发人员完成。

　　组件/服务/接口测试

　　此层面的测试，通常是针对一个已完成的公用功能，此功能向外提供服务或者接口。既可以是代码级别的测试，也可以是不涉及代码的调用测试(如webservice接口)，应由测试人员完成。

　　系统测试

　　整个系统已经实现，通过模拟用户的使用对系统进行测试。我们做的性能测试主要就是这个，由测试人员完成。

　　生产环境测试

　　在系统测试通过的基础上，构建出更完整的生产环境。比如一个生产环境，部属多个系统，这些系统共同使用时可能会相互影响，需要考虑到此种情况进行测试。

　　系统测试中，何时介入呢

　　稳定版

　　→ 进入太晚，进度无法保证

　　→ 可能会影响到功能测试

　　这是测试负责人最害怕的，即测试晚期发现性能问题，修改涉及面较大，造成功能测试返工。

　　尽早

　　→ 流程可跑通

　　→ 数据无严重问题

　　等到稳定版再进入是不靠谱的，要尽早。

　　尽早到什么时候，性能测试需要哪些流程和数据呢?关注性能方案中的用户模型。

　　Q2、性能测试的过程是怎样的

　　敏捷方式的最大特点就是不断确认、不断修正、多次迭代。

　　在传统方式的测试过程中，经常出现的问题恰恰是缺少了敏捷思想中的确认过程，导致了测试方向偏离、测试有效性不够

　　当前进展到哪个阶段?

　　文档

　　步骤1～3

　　执行

　　步骤4～7

　　在传统方式中，可以很简单的将过程分为文档和执行两部分。文档过程很容易被检查，问题主要是在执行过程，这个过程有可能对测试经理是不可见的。

　　考虑这个问题：如果一次性能测试，没有提起任何问题，是否在性能报告之前的执行过程是不可知的?

　　如果现有的工作方式确实存在这个问题，该如何解决呢?

　　这就需要依靠性能测试执行过程规范和检查制度，请继续往后看。

　　Q3、是否有必要提起性能测试?

　　新项目

　　目前基本都需要进行性能测试。

　　新版本(哪些变化可能涉及性能)→ 用户量

　　用户数的增加，如推广使用、知名度提高。

　　→ 数据量

　　数据量的增加，如分布式部属变成集中式部属。

　　→ 实现改变

　　架构实现的变化，如音视频点播系统更换了流媒体服务器。

　　测试负责人的疑问主要是新版本需不需要再做一次性能测试?比如只新增加了一个功能。

　　抛开上面提到的3个方面，新增功能或模块可能会引起性能测试用户模型的变化。如果经过确认，用户模型无需变化，那自然也没必要重新测试。如果用户模型确实发生了改变，其实我觉得是有必要再次执行测试的，毕竟性能测试也算是一种自动化的测试，就应该能够持续性的运行。

　　只不过我们现在的问题是，性能测试的复用性太低，基于HTTP请求的脚本很容易失效，测试环境也总需要重新搭建，这些因素导致了性能测试的成本和投入变大，即使只是增加了一个小功能，可能也需要重头来做一次性能测试。如果有办法改变这个状况，那么每次新版本只要补充一下相关的测试代码就可以了。#p#分页标题#e#

　　我的想法是，性能测试要向组件/服务/接口级别靠近(见Q1)，越接近底层，可复用性也就越高。另外，企业级虚拟化的建设一定要跟上，这样才不会在测试环境上浪费时间。

　　Q4、性能测试有哪些类型

　　基准测试

　　比如单用户的测试或者在无数据条件下的测试，目的是提供一个标准供后续测试比对。

　　负载测试

　　向系统施加一定的压力，一般最大压力的20%或者日常使用压力即可，确保系统可正常运转。

　　压力测试

　　向系统施加预期最大压力，测试系统在繁忙状态下的性能表现。

　　容量测试

　　不断的增大对系统的压力，直至出现瓶颈。用于探测系统的瓶颈，为系统的发展提供重要信息。

　　稳定性测试

　　长时间运行的稳定情况。

　　还有很多其他类型的测试，这里只是列出了几种最常用到的，术语的定义可能也和其他资料有些差别，比如负载和压力，不过无关紧要。

　　这里需要注意的一点，在负载、压力和容量测试中，测试的依据都是用户模型，只有用户模型准确，测试的结果才会有意义。

　　提起性能测试，需要做那种测试呢?

　　一般来说，除了容量测试，其他几种都是要做的，这是得到有效测试结果的必备过程。容量测试，属于获取“额外信息”的测试，不过这种测试其实是非常有价值的，很多资料都把它列为了必做之一。

　　稳定性测试需要运行多长时间?

　　之所以会有这个疑问，其实是因为测试人员提供的结果数据没有说服力，不是证明了系统可以长期稳定运行，而只是下了个系统稳定的结论。

　　我也总和性能测试人员强调，测试的结果是要用数据来证明的，不是说测完了下一个通过的结论就可以了，这样自然要被测试经理、开发经理怀疑(尤其是你是一个新人)。

　　如果能够提供各种详尽的数据，比如测试运行12小时内，操作系统的资源利用情况、应用中间件内部的资源利用情况、甚至是程序内部的一些性能指标等等，如果这些指标足够代表系统的性能，且它们的表现是非常平稳的，那么完全可以从这个趋势推断出，即使系统运行更长的时间也将是稳定的。

　　反之，如果不提供数据，而只是描述测试运行了3天，那么自然会有“3天够不够长”的疑问，只有通过“足够长”的运行时间才能减少人们的顾虑。

　　Q5、如何分析性能需求

　　性能相关需求一般由需求人员提供，测试负责人是这些需求的第一个把关人。针对这些需求，测试负责人可以分析哪些内容呢?

　　是否全面

　　用户角度

　　→ 能不能

　　→ 快不快

　　业务角度

　　→ 吞吐量、TPS、每小时完成工作量

　　→ 处理压力的方式

　　如12306购票，当压力太大的时候，是让所有人都能得到非常慢的服务，还是保证一部分人可以正常使用、另外的人停止服务?

　　技术角度

　　→ 是否使用了某些有潜在风险的技术

　　→ 系统内部的一些资源

　　其他角度

　　→ 比如系统拥有者，要求服务器资源利用率60%左右，想想为什么?

　　是否有效

　　可行性

　　要求发送短信后能即时到达。这就是不可行的需求，因为涉及到运营商的网络。

　　可量化

　　邮件发出后，较短的时间内到达。

　　是否灵活

　　需求vs.期望

　　→ 需求是必须要达到的。比如发送即时消息，必须保证没有丢失，这时可能就要有一个到达率的指标，如果达不到100%，那就是不合格。

　　→ 期望是灵活的，比如页面响应时间3s以内，这就是一个期望，不会因为最后是3.2s而影响结论或者导致延期发布。

　　Q6、如何衡量性能

　　性能的评价标准

　　用户感受

　　用户实际的感受是最权威的评价标准。

　　明确的性能指标

　　但大多数情况无法用实际感受来进行衡量，所以我们需要能够有效代替“感受”的数据，也就是各种性能指标。

　　性能指标一般有哪些

　　响应时间

　　业务类web系统一般主要耗时在服务端，所以通常获取请求的响应时间即可，这是不涉及到客户端展现的。#p#分页标题#e#

　　页面展现时间

　　互联网网站通常最关注展现时间，一般有更具体的指标如首屏展现时间。大家用一用淘宝或者京东就能理解了。

　　吞吐量

　　TPS

　　业务上的需求，比如百度一定会有每秒钟处理多少万次搜索请求这类的指标。

　　特定需求的评估标准

　　如上面举的例子，消息到达率。

　　这些对性能的评价标准，应该在测试设计时就明确下来，测试负责人可对此进行检查。

　　有一点需要注意的是，性能指标是否可检测。通用的指标如页面响应时间很容易获取，所有的测试工具都可以做到。但一些特殊的指标，尤其是涉及到客户端的，可能会存在技术上的问题。比如即时通讯软件的测试中，要求最大压力时，发送信息能够在1s内到达。那么这个到达时间如何获取呢?如果没有提前做好准备，在测试执行时很可能会遇到问题，而测试人员遇到这个问题，很有可能会选择忽视它，只顾把压力加上去就算测完了。

　　Q7、性能测试(不)能做什么

　　web系统性能测试

　　最常见的目的是模拟用户的实际行为，获取用户的感受。

　　如何模拟用户的实际行为

　　建立用户模型。即用户做什么操作、操作路径是什么、操作频率……

　　如何建立用户模型

　　常用业务

　　性能敏感业务

　　关键业务

　　特殊关注

　　这里只是用户模型覆盖度的问题，实际使用的用户模型还需要很多其他信息才能建立起来。

　　测试负责人需要重点关注和确认用户模型的建立。

　　性能测试的覆盖率

　　由上可知，性能测试只能覆盖系统的一部分功能。不要指望所有和性能相关的问题都由性能测试来发现。

　　性能测试最最想发现的是瓶颈，而不是缺陷。

　　我比较害怕听到这样的话，“生产环境的一个操作很慢，去做下性能测试吧”。

　　Q8、如何检验性能测试的质量

　　执行过程

　　建立执行规范

　　明确定义执行过程各检查点需要的输出物

　　指派检查人员

　　根据执行规范进行检查

　　输出执行记录

　　测试人员都知道，设计的用例和实际的执行总是不一样的。性能测试更是如此，调整参数重新运行脚本也是一次执行，这些信息必须有清晰的记录。

　　持续交互确认

　　性能报告

　　让数据证明结论，而不是下结论

　　随着我国加入WTO，各行各业都面临更多的机遇和挑战。如何提高产品的质量，增强市场竞争力，日益成为企业发展必须解决的迫切问题，对软件企业来说尤为重要。软件企业要直接参与国际软件市场的竞争，首要问题就是要保证软件的质量，同时要加快软件产品的发布与交付使用。因此，如何提高软件质量，越来越成为当前软件产业发展中一个迫在眉睫的问题。本文只针对软件质量的性能方面，做一些探讨。

　　2、软件质量

　　质量保证能力的强弱直接影响着软件业的发展和生存。那么，到底什么是软件的质量呢?《GB/T 16260 信息技术 软件产品评价 质量特性及其使用指南》明确定义：软件质量是软件产品具有满足明确的或隐含需求能力的特征和特性总和。具体包括以下六个方面的质量特性：

　　1)功能性

　　与一组功能及其指定的性质有关的一组属性。这里的功能是指满足明确或隐含的需求的那些功能。

　　2)易用性

　　与一组规定或潜在的用户为使用软件所需作的努力和对这样的使用所作的评价有关的一组属性。

　　3)可靠性

　　与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性。

　　4)效率

　　与在规定的条件下，软件的性能水平与所使用资源量之间关系有关的一组属性。

　　5)可维护性

　　与进行指定的修改所需的努力有关的一组属性。

　　6)可移植性

　　与软件可从某一环境转移到另一环境的能力有关的一组属性。

　　因此，为了评价软件产品的质量，需要对软件质量的每个特性实施和执行测试. 随着现代软件构架技术的发展，特别是WEB技术的发展，与软件可靠性、效率质量特性相关的软件性能问题越来越受到包括软件从业人员、专家学者以及软件使用者的重视，软件的性能指标的好坏已直接影响到软件的质量。

　　3、软件性能测试技术

　　软件性能的测试一般包括三个方面，即性能评测、负载测试和强度测试。每一方面的测试都有其不同的测试目标、测试技术、完成标准，具体如下：

　　3.1 性能评测

　　针对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。目标是验证性能需求是否都已满足。

　　测试目标：

　　验证所指定的事务或业务功能在以下情况下的性能行为：

　　(1)正常的预期工作量

　　(2)预期的最繁重工作量

　　测试技术：

　　使用为功能或业务周期测试制定的测试过程。

　　(1)通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。

　　(2)脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准)，并在多个客户机(虚拟的或实际的客户机)上重复。

　　完成标准：

　　(1)单个事务或单个用户：在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障。

　　(2)多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。

　　注意事项：

　　综合的性能测试还包括在服务器上添加后台工作量。 可采用多种方法来执行此操作，其中包括：

　　(1)直接将“事务强行分配到”服务器上，这通常以“结构化查询语言”(SQL) 调用的形式来实现。

　　(2)通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户机。此负载可通过“远程终端仿真”(Remote Terminal Emulation) 工具来实现。此技术还可用于在网络中加载“流量”。

　　(3)使用多台实际客户机在系统上添加负载。

　　(4)性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。

　　(5)性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。

　　3.2 负载测试

　　负载测试通过使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行，以及软件的性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

　　测试目标：

　　验证所指定的事务在不同的工作量条件下的性能行为时间。#p#分页标题#e#

　　测试技术：

　　使用为功能或业务周期测试制定的测试。通过修改数据文件来增加事务数量，或通过修改测试来增加每项事务发生的次数。

　　完成标准：

　　多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。

　　注意事项：

　　(1)负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测

　　(2)负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。

　　3.3 强度测试

　　强度测试目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

　　测试目标：

　　验证测试对象能够在以下强度条件下正常运行，不会出现任何错误：

　　(1)服务器上几乎没有或根本没有可用的内存(内存和磁盘空间)

　　(2)连接或模拟了最大实际(实际允许)数量的客户机

　　(3)多个用户对相同的数据或账户执行相同的事务

　　(4)最繁重的事务量或最差的事务组合

　　注：强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的的情况或条件。

　　测试技术：

　　(1)使用为性能评测或负载测试制定的测试。要对有限的资源进行测试，就应该在一台计算机上运行测试，而且应该减少或限制服务器上的内存和磁盘空间。

　　(2)对于其他强度测试，应该使用多台客户机来运行相同的测试或互补的测试，以产生最繁重的事务量或最差的事务组合。

　　完成标准：

　　所计划的测试已全部执行，并且在达到或超出指定的系统限制时没有出现任何软件故障，或者导致系统出现故障的条件并不在指定的条件范围之内。

　　注意事项：

　　(1)如果要增加网络工作强度，可能会需要使用网络工具来给网络加载消息或信息包。

　　(2)应该暂时减少用于系统的磁盘空间，以限制数据库可用空间的增长。

　　(3)使多个客户机对相同的记录或数据账户同时进行的访问达到同步。

　　4、结束语

　　软件质量的保证，不仅需要科学的测试策略，更要处理好整个软件生命周期中其他如需求、分析、设计、实现各阶段中出现的问题。只有对软件质量进行全面、全过程的质量控制，才能最终保证软件产品的质量，提高企业的竞争力。

　　与性能计数器相关的另一个术语是“资源利用率”。该术语指的是系统各种资源的使用状况。为了方便比较，一般用“资源的实际使用/总的资源可用量”形成资源利用率的数据，用以进行各种资源使用的比较。

　　性能测试之内存篇(windows)

　　要监视内存不足的状况，请从以下的对象计数器开始：

　　· Memory\ Available Bytes

　　· Memory\ Pages/sec

　　Available Bytes剩余的可用物理内存，单位是兆字节(参考值：>=10%)。表明进程当前可使用的内存字节数。Pages/sec 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。

　　如果 Available Bytes 的值很小(4 MB 或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。如果 Pages/sec 的值为 20 或更大，那么您应该进一步研究页交换活动。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。

　　操作系统经常会利用磁盘交换的方式提高系统可用的内存量或是提高内存的使用效率。下列四个指标直接反映了操作系统进行磁盘交换的频度。

　　Page Faults/sec

　　当处理器在内存中读取某一页出现错误时，就会产生缺页中断，也就是 page Fault。如果这个页位于内存的其他位置，这种错误称为软错误，用Transition Fault/sec 来衡量;如果这个页位于硬盘上，必须从硬盘重新读取，这个错误成为硬错误。硬错误会使系统的运行效率很快将下来。Page Faults/sec这个计数器就表示每秒钟处理的错误页数，包括硬错误和软错误。

　　Page Input/sec

　　表示为了解决硬错误而写入硬盘的页数(参考值：>=Page Reads/sec)

　　Page Reads/sec

　　表示为了解决硬错误而从硬盘上读取的页数。(参考值： <=5)

　　Pages/sec

　　表示为了解决硬错误而从硬盘上读取或写入硬盘的页数(参考值：00~20)

　　必须同时监视 Available Bytes、Pages/sec 和 Paging File % Usage，以便确定是否发生这种情况。如果正在读取非缓存内存映射文件，还应该查看缓存活动是否正常。

　　Cathe Bytes

　　文件系统的缓存(默认为50%的可用物理内存)

　　内存泄露

　　· Memory\Available Bytes

　　· Memory\ Committed Bytes

　　如果您怀疑有内存泄露，请监视 Memory\Available Bytes 和 Memory\ Committed Bytes，以观察内存行为，并监视你认为可能在泄露内存的进程的 Process\ Private Bytes、Process\ Working Set 和Process\ Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\ Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process(process_name)\ Pool Nonpaged Bytes。

　　private Bytes

　　进程无法与其他进程共享的字节数量。该计数器的值较大时，有可能是内存泄露的信号

　　检查过于频繁的页交换

　　由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足，这容易与导致页交换的磁盘瓶颈混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：

　　· Physical Disk\ % Disk Time

　　· Physical Disk\ Avg.Disk Queue Length

　　例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

　　要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。

　　研究程序的活动

　　接下来，检查正在运行的程序导致的过多的页交换。如果可能，请停 止具有最高工作集值的程序，然后查看页交换速率是否有显著变化。如果您怀疑存在过多的页交换，请检查 Memory\ Pages/sec 计数器。该计数器显示由于页面不在物理内存中而需要从磁盘读取的页面数。(注意该计数器与 Page Faults/sec 的区别，后者只表明数据不能在内存的指定工作集中立即使用。)#p#分页标题#e#

　　性能测试之处理器篇(windows)

　　监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。需要包含下列内容：

　　Processor\ % Total Processor Time 获得处理器整体使用情况。

　　该计数值用于体现服务器整体的处理器利用率，对多处理器的系统而言，该计数值体现的是所有CPU的平均利用率。如果该值的数值持续超过90%，则说明整个系统面临着处理器方面的瓶颈，需要通过增加处理器来提高性能。

　　要注意的是，由于操作系统本身的特性，在某些多CPU系统中，该数据本身并不大，但此时CPU之间的负载状况极不均衡，此时也应该视作系统产生了处理器方面的瓶颈。

　　监视 Processor\ % Processor Time、Processor\ % User Time 和 % Privileged Time 以获得详细信息。

　　Processor\ % User Time是指系统的非核心操作消耗的CPU时间，如果该值较大，可以考虑是否通过优化算法等方法降低这个值。如果该服务器是数据库服务 器，Processor\ % User Time大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。

　　System\ Processor Queue Length 用于瓶颈检测。

　　%Total Processor Time

　　系统中所有处理器都处于繁忙状态的时间百分比，对于多处理器系统来说，该值可以反映所有处理器的平均繁忙状态，该值为100%，如果有一半的处理器为繁忙状态，该值为50%

　　File Data Operations/sec

　　计算机对文件系统进行读取和写入操作的频率，但是不包括文件控制操作

　　Process Queue Length

　　线程在等待分配CPU资源所排队列的长度，此长度不包括正在占有CPU资源的线程。如果该队列的长度大于处理器个数+1，就表示处理器有可能处于阻塞状态(参考值：<=处理器个数+1)

　　%Processor Time

　　CPU利用率，该计数器最为常用，可以查看处理器是否处于饱和状态，如果该值持续超过 95%，就表示当前系统的瓶颈为CPU，可以考虑增加一个处理器或更换一个性能更好的处理器。(参考值：<80%)

　　%Priviliaged Time

　　CPU在特权模式下处理线程所花的时间百分比。一般的系统服务，进城管理，内存管理等一些由操作系统自行启动的进程属于这类

　　%User Time

　　与%Privileged Time计数器正好相反，指的是在用户状态模式下(即非特权模式)的操作所花的时间百分比。如果该值较大，可以考虑是否通过算法优化等方法降低这个值。如果该服务器是数据库服务器，导致此值较大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。

　　%DPC Time

　　处理器在网络处理上消耗的时间，该值越低越好。在多处理器系统中，如果这个值大于50%并且%Processor Time非常高，加入一个网卡可能会提高性能。

　　观察处理器使用情况的值

　　要测量处理器的活动，请查看 Processor\ % Processor Time 计数器。该计数器显示处理器忙于执行非空闲线程所耗时间的百分比。

　　检查处理器使用时，请考虑计算机的角色和所完成工作的类型。根据计算机进行的工作，较高的处理器值意味着系统正有效地处理较重的工作负载或正在努力维持。例如，如果正在监视用户的计算机，并且该计算机用于计算，计算程序可能容易使用 100% 的处理器时间。即使这会造成该计算机中其他应用程序的性能受到影响，但可以通过改变负载来解决。

　　另一方面，在处理许多客户请求的服务器计算机中，100% 左右的值表示这些过程在队列中，正在等待处理器时间，并且造成瓶颈。如此持续高层次的处理器使用对服务器而言是无法接受的。

　　考察处理器瓶颈

　　进程的线程所需要的处理器周期超出可用周期时，处理器瓶颈将逐步显示出来。可以建立较长的处理器队列，并且系统响应会受到影响。处理器瓶颈两种常见的原因是 CPU 限制程序和产生过多中断的驱动程序或子系统组件。

　　要决定是否由于对处理器时间的要求较高而存在处理器瓶颈，请查看 System\ Processor Queue Length 计数器。队列中包含两个或更多的项目则表明存在瓶颈。如果多个程序进程竞争大多数处理器时间，安装更快速的处理器会提高吞吐量。如果正在运行多线程的进程，附加处理器会有所帮助，但是请注意，附加处理器可能只有有限的益处。#p#分页标题#e#

　　此外，跟踪计算机的服务器工作队列当前长度的 Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。

　　要决定中断活动是否造成瓶颈，请观察 Processor\ Interrupts/sec 计数器的值，该计数器测量来自输入/输出 (I/O) 设备的服务请求的速度。如果此计数器的值明显增加，而系统活动没有相应增加，则表明存在硬件问题。

　　也可以对生成中断的磁盘驱动器、网卡和其他设备活动的间接指示器监视 Processor\ % Interrupt Time 时间。

　　注意

　　要检测可能影响处理器性能的硬件问题，例如 IRQ 冲突，请观察 System\ File Control Bytes/second 的值。

　　监视多处理器系统

　　要观察多处理器计算机的效率，请使用下列附加计数器。

　　计数器

　　说明

　　Process\ % Processor Time

　　过程的所有线程在每个处理器上的处理器时间总和。

　　Processor(_Total)\ % Processor Time

　　计算机中所有处理器的处理器活动的度量。

　　“N[{y8_0此计数器采样间隔期间的所有处理器平均非空闲时间的总和，并用处理器数目除以该和。51Testing软件测试网

　　t#e_5I：N2y8@"a：X：Y

　　例如，如果所有处理器平均忙半个采样间隔，则显示 50%。如果半数处理器忙整个间隔，而其他的处理器空闲，则也显示 50%。

　　Thread\ % Processor Time

　　线程的处理器时间数

　　性能测试之磁盘篇(windows)

　　监测对象：PhysicalDisk

　　如果分析的计数器指标来自于数据库服务器、文件服务器或是流媒体服务器，磁盘I/O对这些系统来说更容易成为瓶颈。

　　每磁盘的I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈。

　　下表给出了每磁盘I/O的计算公式：

　　表示磁盘驱动器为读取或写入请求提供服务所用的时间百分比，如果只有%Disk Time比较大，硬盘有可能是瓶颈

　　Average Disk Queue Length

　　表示磁盘读取和写入请求提供服务所用的时间百分比，可以通过增加磁盘构造磁盘阵列来提高性能(<=磁盘数的2倍)

　　Average Disk Read Queue Length

　　表示磁盘读取请求的平均数

　　Average Disk write Queue Length

　　表示磁盘写入请求的平均数

　　Average Disk sec/Read

　　磁盘中读取数据的平均时间，单位是s

　　Disk Bytes/sec 提供磁盘系统的吞吐率。

　　决定工作负载的平衡

　　要平衡网络服务器上的负载，需要了解服务器磁盘驱动器的繁忙程度。使用 Physical Disk\ % Disk Time 计数器，该计数器显示驱动器活动时间的百分比。如果 % Disk Time 较高(超过 90%)，请检查 Physical Disk\ Current Disk Queue Length 计数器以查看正在等待磁盘访问的系统请求数量。等待 I/O 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到 2 倍。

　　Average Disk sec/Transfer

　　磁盘中写入数据的平均时间，单位是s

　　计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。一般来说，定义该值小于15ms最为优异，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或硬盘的 RAID方式#p#分页标题#e#

　　Average Disk Bytes/Transfer

　　值大于 20 KB 表示该磁盘驱动器通常运行良好;如果应用程序正在访问磁盘，则会产生较低的值。例如，随机访问磁盘的应用程序会增加平均 Disk sec/Transfer 时间，因为随机传送需要增加搜索时间。

　　性能测试之网络篇(windows)

　　监测对象：Network Interface

　　网络分析是一件技术含量很高的工作，在一般的组织中都有专门的网络管理人员进行网络分析，对测试工程师来说，如果怀疑网络是系统的瓶颈，可以要求网络仍有来写真进行网络方面的检测。

　　Network Interface\Bytes Total/sec为发送和接收字节的速率(包括帧字符在内)。可以通过该计数器的值判断网络连接速度是否是瓶颈，具体操作方法是用该计数器的值与目前的网络带宽进行比较。

　　Byte Total/sec

　　表示网络中接受和发送字节的速度，可以用该计数器来判断网络是否存在瓶颈(参考值：该计数器和网络带宽相除，<50%)

　　性能测试之进程篇(windows)

　　查看进程的%Processor Time值

　　每个进程的%Processor Time反映进程所消耗的处理器时间。用不同进程所消耗的处理器时间进行对比，可以很容易的看出具体是哪个进程在性能测试过程中消耗了最多的处理器时间，从而可以据此针对应用进行优化。

　　查看每个进程产生的页面失效

　　可以用每个进程产生的页面失效(通过Process\Page Failures/sec计数器获得)和系统的页面失效(可通过Memory\Page Failures/sec计数器获得)的比值，来判断哪个进程产生了最多的失效页面，这个进程要么是需要大量内存的进程，要么是非常活跃的进程，可以对其进行中的分析。

　　了解进程的Process\Private Bytes

　　Process\Private Bytes是指进程所分配的无法与其他进程共享的当前字节数量。该计数器主要用拉判断进程在性能测试过程中有无内存泄漏。

　　例如：对于一个IIS之上的web应用，我们可以重点监控inetinfo进程的Private Bytes，如果在性能测试过程中，该进程的Private Bytes计数器值不断增加，或是性能测试停止后一段时间，该进程的Private Bytes仍然持续在高水平，则说明应用存在内存泄漏。

　　(备注：进程分析方法用到的计数器主要有：Process\%Processor Time、Page Failures/sec、Page Failures/sec、Private Bytes)

　　相关链接：

　　内存映射文件机制

　　内存映射文件是利用虚拟内存把文件映射到进程的地址空间中去，在此之后进程操作文件，就像操作进程空间里的地址一样了，省去了读和写I/O的时间。

　　比如使用memcpy等内存操作的函数。这种方法能够很好的应用在需要频繁处理一个文件或者是一个大文件的场合，这种方式处理IO效率比普通IO效率要高。

　　利用内存映射文件您可以认为操作系统已经为您把文件全部装入了内存，然后您只要移动文件指针进行读写即可了。这样您甚至不需要调用那些分配、释放内存块和文件输入/输出的API函数，另外您可以把这用作不同的进程之间共享数据的一种办法。运用内存映射文件实际上没有涉及实际的文件操作，它更象为每个进程保留一个看得见的内存空间。至于把内存映射文件当成进程间共享数据的办法来用，则要加倍小心，因为您不得不处理数据的同步问题，否则您的应用程序也许 很可能得到过时或错误的数据甚至崩溃。

　　内存映射文件本身还是有一些局限性的，譬如一旦您生成了一个内存映射文件，那么您在那个会话期间是不能够改变它的大小的。所以内存映射文件对于只读文件和不会影响其大小的文件操作是非常有用的。当然这并不意味着对于会引起改变其大小的文件操作就一定不能用内存影射文件的 方法，您可以事先估计操作后的文件的可能大小，然后生成这么大小一块的内存映射文件，然后文件的长度就可以增长到这么一个大小。我们的解释够多的了，接下来我们就看看实现的细节：

　　1、调用CreateFile打开您想要映射的文件。

　　2、调用CreateFileMapping，其中要求传入先前CreateFile返回的句柄，该函数生成一个建立在CreateFile函数创建的文件对象基础上的内存映射对象。

　　3、调用MapViewOfFile函数映射整个文件的一个区域或者整个文件到内存。该函数返回指向映射到内存的第一个字节的指针。用该指针来读写文件。

　　4、调用UnmapViewOfFile来解除文件映射。#p#分页标题#e#

　　5、调用CloseHandle来关闭内存映射文件。注意必须传入内存映射文件的句柄。

　　6、调用CloseHandle来关闭文件。注意必须传入由CreateFile创建的文件的句柄。

　　在开发人员完成他们的测试之后，我将会出于两个具有代表性的原因来审查他们的工作。第一，我想要在和客户交流时能够说出应用软件是什么样子和它如何工作。第二，我想要看一看有没有什么显而易见的错误可以在客户看到结果之前得到更正。

　　我知道有我在中间会让我的开发人员感觉受到挫折。这种挫折并不是因为我是一个瓶颈，而我通常试图在开发人员告诉我应用软件已经完成的当天之内就开始我的测试工作。真正使他们感到受挫的是他们可以对应用软件进行测试并认为他们已经找到了所有的东西。然而，通常在我开始测试之后的30分钟之内，我就会在一张纸上记录下来我有疑问或是看起来不正常的事情。

　　通常这种测试方式也会使我感到受挫。有时，我奇怪开发人员如何能够说应用软件已经完成，而他们所忽视的内容我在几分钟之内就能够找到。然而，一般来说，出现的错误通常是由对测试理念的缺乏所导致。开发人员关注于提供正常工作的应用软件，而我倾向于从一个用户的角度看一看是否能打破它。我还会寻找其中的一些矛盾和直觉性的缺乏，这些反映出了使用者的经验。

　　提供正确的应用软件

　　测试工作具有一些不同的方面。一方面就是去验证最终的产品达到所认可的要求。测试工作要求测试人员确保所有所要求的功能和特性都已经给出并可用。然后，确保这些功能和特性以所期望的方式工作。这种测试方式并没有错，但是你还需要更进一步。

　　试着作为一个用户去打破应用软件

　　很多开发人员所欠缺的地方是，他们以他们所期望的用户的反应方式为基础进行测试工作。他们没有进行足够的思考，离开惯常的途径进行测试。例如，比方说你有一个Web应用软件，其中有大量的在线处理过程，如果第一个页面要求输入用户名和密码，那么我一开始就什么值都不输入，然后看一看会发生什么。我能不能进入?有没有错误出现?有些时候是不是屏幕会静止不动?这时，应用软件就应该将其视为一个非法的响应并返回恰当的错误信息。

　　用户会向所有可能位置输入任何值

　　当我进入应用软件界面时，我会输入各种各样奇怪的值。如果这里需要输入的是字母，那么我就输入一个数字，然后我会输入类似于“(*&%$’的特殊字符。很多次，应用软件都会发生问题，真是让我感到惊异。我对所有的区域都做了相同的测试，如果一个区域包含一个drop-down列表，我就会试着键入一个值。如果某些区域是事先制定的，我就会改变他们。如果一些值是数据库的关键字而不能动，我就会改变他们。我还试着通过在区域中加入页面所允许的足够多的数字或字符，让他们溢出。然后我就会点击可选的按钮和链接看一看会发生什么。

　　同样的，我还试着搞乱所有的预制定区域。我总是告诉我的开发人员说，如果你不希望一个区域被改变，那么你就不要允许用户将指针放在上面和键入。我向你保证，如果你将一个区域设置为开放的可以输入，那么就一定会有某些人在某些时候，出于某种原因试图向其中键入数值。

　　用户为什么会向一个需要输入数字的区域键入特殊字符呢?问题在于他们或许不会有意去这样做，然而，键入错误去却随时都会发生。如果你向用户给出一个数字区域，那么随着时间的过去，错误的键入就会导致在任何的区域之中输入任何的字符。我认为这样的问题应该现在就找出来，而不是让一个Web应用软件在用户手中出问题。

　　用户会尝试逻辑流的所有组合

　　除了一些简单的编辑性错误之外，我还会尝试每一个逻辑流的组合。当我看到一个Web页面时，我会尝试每一个超链接看一看结果是什么。开发人员会看着我纳闷为什么用户会这样做。再说一次，问题是他们可能不是有意去这么做，然而，你应该设想每一个逻辑组合都可能会在某个时间被尝试。

　　看一看外观

　　我着眼的最后一件事就是整体的视觉和感觉。我试图确保屏幕有一个漂亮的外观，漂亮的字体，而且他们是协调一致的。例如，如果你在列表中一些项目的最后放置一个句号，那么他们都应该带有句号，否则就都没有，这取决于你的编辑上的习惯。同样，字体也应该保持一致，如果在一个区域的标题的字体是14，那么他们都应该是这个大小。这样做都是为了使应用软件看起来具有专业性。#p#分页标题#e#

　　做最坏的准备

　　在我所管理的团体之中，开发人员做出了很好的工作，确保他们的应用软件以所指定的方式工作。但在很多情况下，他们没有从一个用户的角度做出足够的测试工作。他们应该关注于确保应用软件的坚固可靠。用户在百分之九十的时间之内，会像你所期望的那样对应用软件进行操作，然而，剩下的百分之十的时间里，他们就会做一些奇怪的事情。当发生这样的事情时，你的应用软件就需要对其妥当并成功地进行处理。你不希望一个很棒的应用软件在用户第一次输入12位数字的社会保障号码而不是9位数字时就垮掉。你要确保进行了测试工作保证你的应用软件如宣传的那样进行工作。还有，尽可能地对意外因素的组合进行多种测试。你需要确保没有任何的错误数据或处理流程致使用户得到任何意料之外的系统信息。

　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

　　随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。

　　Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它" 使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。

　　在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

　　一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

　　一、功能测试

　　1、链接测试

　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面;其次，测试所链接的页面是否存在;最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

　　2、表单测试

　　当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

　　3、Cookies测试

　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

　　4、设计语言测试

　　Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。#p#分页标题#e#

　　5、数据库测试

　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

　　在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

　　二、性能测试

　　1、连接速度测试

　　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟)，用户就会因没有耐心等待而离开。

　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

　　2、负载测试

　　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线?如果超过了这个数量，会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

　　3、压力测试

　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

　　压力测试的区域包括表单、登陆和其他信息传输页面等。

　　三、可用性测试

　　1、导航测试

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。

　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。

　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

　　2、图形测试

　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

　　(1)要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

　　(2)验证所有页面字体的风格是否一致。

　　(3)背景颜色应该与字体颜色和前景颜色相搭配。

　　(4)图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

　　3、内容测试

　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。#p#分页标题#e#

　　4、整体界面测试

　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

　　对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　对所有的可用性测试来说，都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与，最好是最终用户的参与。

　　四、客户端兼容性测试

　　1、平台测试

　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

　　2、浏览器测试

　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

　　五、安全性测试

　　Web应用系统的安全性测试区域主要有：

　　(1)现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

　　(2)Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内(例如15分钟)没有点击任何页面，是否需要重新登陆才能正常使用。

　　(3)为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

　　(4)当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

　　(5)服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

　　六、总结

　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

　　基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

　　七、参考文献

　　[1] N. Zelnick. Nifty Technology and Nonconformance: The Web in Crisis. Computer， 1998(10): 115-119

　　[2] W. Gibbs. Software's chronic crisis. Scientific American. 1994.9

　　[3] Yogesh Deshpande and Steve Hansen. Web Engineering: Creating a Discipline among Disciplines. IEEE Software，2001(2): 82-87

　　[4] A. Ginige. Web Engineering: Methodologies for Developing Large and Maintainable Web Based Information Systems. Proc IEEE International Conference on Networking， the India and the World CNIW'98，Ahmedabad， India， 1998，12

　　[5] Internet Testing: Keeping Bugs Off the Web. http://www.stlabs.com/bugs_off.htm

　　[6] J. Bach. Testing Internet Software.

　　http://www.stlabs.com/testnet/docs/inet.htm

　　[7] Tongren.Compatibility and Security Testing of Web-Based Applications. TTN Online，1999，3

　　本文将 web 测试分为 6 个部分：

　　1. 功能测试

　　2. 性能测试(包括负载/压力测试)

　　3. 用户界面测试

　　4. 兼容性测试

　　5. 安全测试

　　6. 接口测试

　　本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。

　　1 功能测试

　　1.1 链接测试

　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面;其次，测试所链接的页面是否存在;最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

　　采取措施：采用自动检测网站链接的软件来进行。

　　推荐软件：

　　Xenu Link Sleuth 免费 绿色免安装软件

　　HTML Link Validator 共享(30天试用)

　　1.2 表单测试

　　当用户通过表单提交信息的时候，都希望表单能正常工作。

　　如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

　　当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

　　1.3 数据校验

　　如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。

　　在测试表单时，该项测试和表单测试可能会有一些重复。

　　1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner(QTP)脚本;回归测试以及升级版本主要靠WinRunner(QTP)自动回放测试。

　　1.4 cookies测试

　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。

　　采取措施：

　　1 采用黑盒测试：采用上面提到的方法进行测试

　　2 采用查看cookies的软件进行(初步的想法)

　　可以选择采用的软件

　　IECookiesView v1.50

　　Cookies Manager v1.1

　　1.5 数据库测试

　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。#p#分页标题#e#

　　在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

　　采取措施：暂时没有更好的测试方法

　　考虑结合到1.2和1.3的测试中

　　1.6 应用程序特定的功能需求

　　最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。

　　采取措施：深刻理解需求说明文档

　　1.7 设计语言测试

　　Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、javascript、 ActiveX、VBScript或Perl等也要进行验证。

　　暂时没有方法测试，可以多参考一点讨论组内的更新信息

　　2 性能测试

　　2.1 连接速度测试

　　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟)，用户就会因没有耐心等待而离开。

　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

　　2.2 负载测试

　　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线?如果超过了这个数量，会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

　　2.3 压力测试

　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

　　压力测试的区域包括表单、登陆和其他信息传输页面等。

　　负载/压力测试应该关注什么

　　测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。

　　瞬间访问高峰

　　如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。

　　每个用户传送大量数据

　　网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?

　　长时间的使用

　　如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。#p#分页标题#e#

　　采取措施：采用测试工具WAS、ACT协助进行测试

　　3 用户界面测试

　　3.1 导航测试

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。

　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。

　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

　　3.2 图形测试

　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

　　(1)要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

　　(2)验证所有页面字体的风格是否一致。

　　(3)背景颜色应该与字体颜色和前景颜色相搭配。

　　(4)图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到 30k 以下

　　(5)最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

　　通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

　　3.3内容测试

　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

　　对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。

　　3.4 表格测试

　　需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格?把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行?是否有因为某一格的内容太多，而将整行的内容拉长?

　　3.5 整体界面测试

　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?#p#分页标题#e#

　　对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　对所有的用户界面测试来说，都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与，最好是最终用户的参与。

　　采取措施：手动测试，参与人员最好有外部人员

　　4 兼容性测试

　　4.1 平台测试

　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

　　4.2 浏览器测试

　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、javascript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，javascript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

　　4.3 分辨率测试

　　页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

　　4.4 Modem/连接速率

　　是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。

　　4.5 打印机

　　用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

　　4.6 组合测试

　　最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。

　　采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵

　　5 安全测试

　　即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。

　　5.1 目录设置

　　Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。

　　5.2 SSL

　　很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制?超过限制时间后出现什么情况?#p#分页标题#e#

　　5.3 登录

　　有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面?

　　Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内(例如15分钟)没有点击任何页面，是否需要重新登陆才能正常使用。

　　5.4 日志文件

　　在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?

　　5.5 脚本语言

　　脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。

　　6 接口测试

　　在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。

　　6.1服务器接口

　　第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

　　这种测试可以归到功能测试中的表单测试和数据校验测试中

　　6.2 外部接口

　　有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。

　　这种情况在远程抄表中可能会体现到

　　6.3 错误处理

　　最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况?订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误?是否已对信用卡进行收费?如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。

　　采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。

　　7 结论

　　无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。

　　(1) 页面清单是否完整(是否已经将所需要的页面全部都列出来了)

　　(2) 页面是否显示(在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示)

　　(3) 页面在窗口中的显示是否正确、美观(在调整浏览器窗口大小时，屏幕刷新是否正确)

　　(4) 页面特殊效果(如特殊字体效果、动画效果)是否显示

　　(5) 页面特殊效果显示是否正确

　　2 页面元素部分

　　(1)页面元素清单(为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等)

　　(2)素是否显示(元素是否存在)

　　(3)页面元素是否显示正确(主要针对文字、图形、签章)

　　(4)页面元素的外形、摆放位置(如按钮、列表框、核选框、输入框、超连接等)

　　(5) 页面元素基本功能是否实现(如文字特效、动画特效、按钮、超连接)

　　(6) 页面元素的容错性列表(如输入框、时间列表或日历)

　　(7) 页面元素的容错性是否存在

　　(8) 页面元素的容错性是否正确

　　3 功能部分

　　(1) 数据初始化是否执行

　　(2) 数据初始化是否正确

　　(3) 数据处理功能是否执行

　　(4) 数据处理功能是否正确

　　(5) 数据保存是否执行

　　(6) 数据保存是否正确

　　(7) 是否对其他功能有影响

　　(8) 如果影响其他功能，系统能否作出正确的反应

　　(9) 其他错误

　　(10) 对模块的具体功能进行测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况

　　如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试

　　单项功能测试(增加、修改、查询、删除)

　　增加——>增加——>增加 (连续增加测试)

　　增加——>删除

　　增加——>删除——>增加 (新增加的内容与删除内容一致)

　　增加——>修改——>删除

　　修改——>修改——>修改 (连续修改测试)

　　修改——>增加 (新增加的内容与修改前内容一致)

　　修改——>删除

　　修改——>删除——>增加 (新增加的内容与删除内容一致)

　　删除——>删除——>删除 (连续删除测试)

　　(11)查询功能分为两种情况，验证操作结果。

　　一、打开页面时自动显示结果，则不特别强调;

　　二、需要手工操作进行查询，则每次在其他功能完成后进行。

　　4 提示信息

　　(1) 成功、失败提示

　　(2) 操作结果提示

　　(3) 确认提示

　　(4) 危险操作、重要操作提示

　　(5) 返回页面 提示后显示的页面

　　5 容错性

　　注意以下几种情况

　　(1) 为空、非空

　　(2) 唯一性

　　(3 )字长、格式

　　(4) 数字、邮政编码、金额、电话、电子邮件、ID号、密码

　　(5) 日期、时间

　　(6) 特殊字符 (对数据库)英文单、双引号，&符号

　　6 权限部分

　　功能权限： 指定用户可以使用那些功能，不能使用那些功能

　　数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可以合并到功能测试

　　操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合并到功能测试

　　权限变化： 可以合并到功能测试

　　(1) 功能权限是否存在

　　(2)功能权限是否正确

　　(3) 数据权限是否存在

　　(4) 数据权限是否正确

　　(5)操作权限是否存在

　　(6) 操作权限是否正确

　　(7) 引起权限变化的功能列表

　　(8) 功能权限变化还是数据权限变化，或两者兼有

　　(9) 权限变化是否正确

　　7 键盘操作

　　(1) Tab键的使用

　　(2) 上下方向键的使用

　　(3) Enter键的使用

　　(4) 系统设定快捷键的使用(如果设置有快捷键)

　　8 测试中还应注意的其他事项

　　(6) 完整性：是否是一个整体，没有功能缺损

　　(7) 易用性：使用是否方便#p#分页标题#e#

　　(8) 一致性：类似的问题用类似的方法处理

　　(9) 提示信息：提示信息是否完整、正确、详细

　　(10) 帮助信息：是否提供帮助信息，帮助信息的表现形式(页面文字、提示信息、帮助文件)，帮助信息是否正确、详细

　　(11) 兼容性：包括操作系统兼容和应用软件兼容，可能还包括硬件兼容

　　(12) 可扩展性：是否由升级的余地，是否保留了接口

　　(13) 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护

　　(14) 运行速度：运行的快慢，带宽占用情况

　　有几点：

　　1.功能点测试：是否满足需求所要求的功能

　　2.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

　　3.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

　　4.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

　　5.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

　　6.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

　　7.界面测试：界面的正确性、一致性、友好性、易用性。

　　用户界面测试是从最终的使用者用户的角度来看软件，软件难以理解，不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面：

　　1.易用性检查：确保软件易于理解，方便使用。

　　2.一致性检查：

　　a.注意系统页面的风格是否一致，如字的大小、颜色、字体要相同。

　　b.提示信息的表达方式是否一致。

　　c.按钮排列顺序是否一致。

　　d.back, cancel等按钮跳转页面处理是否一致。

　　e.各字段的名称，位置、长度、类型是否和设计文档要求一致，如Employee No和LoginName不一致。

　　3.正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。

　　4.友好性检查：

　　a.提示信息是否友好.

　　b.系统应该在用户执行错误的操作之前提出警告，提示信息.

　　c.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。

　　5.合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。

　　6.检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。

　　7.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理。

1.1 CUnit简要描述

CUnit是一个编写、管理及运行c语言单元测试的系统。它使用一个简单的框架来构建测试结构，并为普通数据结构的测试提供丰富的断言。此外，CUnit为测试的运行和结果查看提供了许多不同的接口，包括自动测试模式和可交互的控制台模式。

其常用的数据类型和函数在以下头文件中声明：

头文件 内容描述

<CUnit/CUnit.h> 包括测试用例中常用的宏定义和框架中其它头文件

<CUnit/CUError.h> 错误处理函数及错误编号

<CUnit/TestDB.h> 测试注册簿、测试包和测试用例的操作及数据类型

<CUnit/TestRun.h> 测试运行及结果检索的操作及数据类型

<CUnit/Automated.h> 输出Xml结果相关的自动模式接口

<CUnit/Basic.h> 非交互模式的基本模式接口

<CUnit/Console.h> 交互模式的接口

1.2 测试框架结构

CUnit核心框架为测试注册簿、测试包和测试用例的管理提供了基本支持，它提供的接口可以使用户和测试框架交互，方便测试的运行和测试结果的查看。CUnit被组织成一个常见的单元测试框架，其结构如下：

测试用例被打包成测试包，并被注册到当前活动的测试注册簿中。测试包的装载和卸载函数在测试执行前后被自动调用。所有的测试包和测试用例可以一键运行，也可以选择相应的测试包或测试用例来执行测试。

1.3 基本使用方法

使用CUnit框架的常用流程如下：

编写测试用例，如果有必要须对测试包进行初始化或者清理

初始化测试注册簿 CU_initialize_registry()

向注册簿中注册测试包 CU_add_suite()

向测试包中添加测试用例 CU_add_test()

使用合适的测试模式执行测试CU_automated(basic/console/curses)_run_tests()

清理测试注册簿 CU_cleanup_registry()

1.4 Linux下CUnit的安装

The usual sequence of steps should succeed in building and installing CUnit:
aclocal  (if necessary)
autoconf (if necessary)
automake (if necessary)
chmod u+x configure (if necessary)
./configure --prefix <Your choice of directory for installation>
make
make install
What's installed:
libcunit.a (Library file)
CUnit Header files
DTD and XSL files supporting xml output files in share directory
Man Pages in relevant man directories under the installation path.
HTML users guide in the doc subdirectory of the installation path.
Example & test programs in the share subdirectory of the install path.

2. 编写CUnit测试用例

2.1 测试用例函数的命名

CUnit中对于测试函数的定义没有严格的规范，一个常用的示例如下：

int maxi(int i1, int i2)
　　{
　　return (i1 > i2)  i1 : i2;
　　}
　　void test_maxi(void)
　　{
　　CU_ASSERT(maxi(0,2) == 2);
　　CU_ASSERT(maxi(0,-2) == 0);
　　CU_ASSERT(maxi(2,2) == 2);
　　}

2.2 CUnit中的断言

CUnit为逻辑条件测试提供了一系列的断言。测试框架会跟踪这些断言的通过或失败，当测试执行完成时便可看到结果。

每一个断言测试一个逻辑条件，条件的值为CU_FALSE表示断言失败。对于测试失败，测试将会继续执行，除非用户选择“xxx_FATAL”类型的断言，这种情况下该测试函数将会失败并立即返回。FATAL类型的断言应该和警告一块使用！一旦FATAL类型的断言导致测试失败，测试函数将没有机会做清理工作，普通的清理函数不会起任何作用。

另外一些特殊的断言被注册为“pass”或“fail”，它们不是用来做逻辑测试，而是用来测试流程控制或者其他条件测试的。例如：#p#分页标题#e#

void test_longjmp(void)
{
jmp_buf buf;
int i;
i = setjmp(buf);
if (i == 0) {
run_other_func();
CU_PASS("run_other_func() succeeded.");
}
else
CU_FAIL("run_other_func() issued longjmp.");
}

所有的断言被定义在<CUnit/CUnit.h>

3. 测试注册簿

3.1 常用相关函数

#include  <CUnit/TestDB.h>
typedef struct CU_TestRegistry
typedef CU_TestRegistry* CU_pTestRegistry
CU_ErrorCode CU_initialize_registry(void)
void CU_cleanup_registry(void)
CU_BOOL CU_registry_initialized(void)
CU_pTestRegistry CU_get_registry(void)
CU_pTestRegistry CU_set_registry(CU_pTestRegistry pTestRegistry)
CU_pTestRegistry CU_create_new_registry(void)
void CU_destroy_existing_registry(CU_pTestRegistry* ppRegistry)

3.2 注册簿内部结构体

测试注册簿是测试包和相关测试用例的仓库。当用户添加测试包或测试用例时，CUnit维护当前活动的测试注册簿的状态更新，当用户选择运行所有测试用例时，当前活动的注册簿中所有的测试包均被执行。

测试注册簿结构在<CUnit_TestDB.h>中定义，它包括所有测试包的数量、所有测试用例的数量以及一个指向该注册簿中测试包链表的指针：

typedef struct CU_TestRegistry
{
unsigned int uiNumberOfSuites;
unsigned int uiNumberOfTests;
CU_pSuite    pSuite;
} CU_TestRegistry;
typedef CU_TestRegistry* CU_pTestRegistry;

3.3 与注册簿相关的其它函数

CU_pTestRegistry CU_get_registry(void)
CU_pTestRegistry CU_set_registry(CU_pTestRegistry pTestRegistry)
CU_pTestRegistry CU_create_new_registry(void)
void CU_destroy_existing_registry(CU_pTestRegistry* ppRegistry)

4. 测试包及测试用例的管理

4.1 相关函数及结构

#include <CUnit/TestDB.h>
typedef struct CU_Suite
typedef CU_Suite* CU_pSuite
typedef struct CU_Test
typedef CU_Test* CU_pTest
typedef void (*CU_TestFunc)(void)
typedef int (*CU_InitializeFunc)(void)
typedef int (*CU_CleanupFunc)(void)
CU_pSuite CU_add_suite(const char* strName,CU_InitializeFunc pInit,CU_CleanupFunc pClean);
CU_pTest   CU_add_test(CU_pSuite pSuite,const char* strName,CU_TestFunc pTestFunc);
typedef struct CU_TestInfo
typedef struct CU_SuiteInfo
CU_ErrorCode CU_register_suites(CU_SuiteInfo suite_info[]);
CU_ErrorCode CU_register_nsuites(int suite_count, ...);
CU_ErrorCode CU_set_suite_active(CU_pSuite pSuite, CU_BOOL fNewActive)
CU_ErrorCode CU_set_test_active(CU_pTest, CU_BOOL fNewActive)
CU_ErrorCode CU_set_suite_name(CU_pSuite pSuite, const char *strNewName)
CU_ErrorCode CU_set_suite_initfunc(CU_pSuite pSuite, CU_InitializeFunc pNewInit)
CU_ErrorCode CU_set_suite_cleanupfunc(CU_pSuite pSuite, CU_CleanupFunc pNewClean)
CU_ErrorCode CU_set_test_name(CU_pTest pTest, const char *strNewName)
CU_ErrorCode CU_set_test_func(CU_pTest pTest, CU_TestFunc pNewFunc)
CU_pSuite CU_get_suite(const char* strName)
CU_pSuite CU_get_suite_at_pos(unsigned int pos)
unsigned int CU_get_suite_pos(CU_pSuite pSuite)
unsigned int CU_get_suite_pos_by_name(const char* strName)
CU_pTest CU_get_test(CU_pSuite pSuite, const char *strName)
CU_pTest CU_get_test_at_pos(CU_pSuite pSuite, unsigned int pos)
unsigned int CU_get_test_pos(CU_pSuite pSuite, CU_pTest pTest)
unsigned int CU_get_test_pos_by_name(CU_pSuite pSuite, const char *strName)

4.2 注册测试包

CU_pSuite CU_add_suite(const char* strName, CU_InitializeFunc    pInit, CU_CleanupFunc pClean)

创建一个测试包，该测试包拥有自己特定的名字、初始化函数及清理函数。该测试包被注册到一个测试注册簿，该注册簿在添加任意测试包之前须初始化。当前版本不支持独立于注册簿之外的测试包的创建，该函数不应该在测试执行期间被调用。

在注册簿中，推荐每个测试包有唯一的名字，这样可以通过名字查找测试包。在上述函数中，测试包的初始化函数和清理函数是可选的，如果不需要这些函数可以传参数NULL。

该函数返回值分为五种：

CUE_SUCCESS suite creation was successful.

　　CUE_NOREGISTRY Error the registry has not been initialized.

　　CUE_NO_SUITENAME ErrorstrName was

　　NULL.CUE_DUP_SUITE Warning the suite's name was not unique.

　　CUE_NOMEMORY Error memory allocation failed.

4.3 添加测试用例到测试包

CU_pTest CU_add_test(CU_pSuite pSuite, const char* strName, CU_TestFunc pTestFunc)

创建一个测试用例，该测试包拥有自己特定的名字、初始化函数及清理函数。该测试用例被打包到一个测试包，当前版本不支持独立于测试包之外的创建，该函数不应该在测试执行期间被调用。

在单个测试包中，推荐每个测试用例有唯一的名字，这样可以通过名字查找测试用例。参数接受一个测试函数的函数指针，不可以为空，当执行测试时，该函数将被调用。测试函数没有参数也没有返回值。

该函数返回值分为7种：

CUE_SUCCESS suite creation was successful.

　　CUE_NOREGISTRY Error: the registry has not been initialized.

　　CUE_NOSUITE Error: the specified suite was NULL or invalid.

　　CUE_NO_TESTNAME Error: strName was NULL.

　　CUE_NO_TEST Error: pTestFunc was NULL or invalid.

　　CUE_DUP_TEST Warning: the test's name was not unique.

　　CUE_NOMEMORY Error: memory allocation failed.

4.4 测试包及测试用例管理的快捷方法

CUnit定义了许多类似如下的宏：

#define CU_ADD_TEST(suite, test) (CU_add_test(suite, #test, (CU_TestFunc)test))

这些宏可以针对测试函数名字，自动生成拥有惟一名字的测试用例，并将该测试用例添加到指定的测试包，用户应该验证返回值以保证正常添加。

CU_ErrorCode CU_register_suites(CU_SuiteInfo suite_info[])

　　CU_ErrorCode CU_register_nsuites(int suite_count, ...)

对于拥有很多测试包和测试用例的大型测试结构，管理测试包和测试用例的关联和注册是相当乏味和易出错的。CUnit提供了一个特殊的注册系统来帮助用户管理测试包和测试用例。这个系统将测试包的注册和测试用例的关联集中起来，以缩减用户的代码量。

CU_TestInfo实例可以将许多测试用例集中放到一个数组，以便于关联到一个测试包。每个数组元素包括一个惟一的名字和测试函数。该数组必须以CU_TEST_INFO_NULL结尾。

CU_TestInfo test_array1[] = {
{ "testname1", test_func1 },
{ "testname2", test_func2 },
{ "testname3", test_func3 },
CU_TEST_INFO_NULL,
};

同样的，CU_SuiteInfo也提供类似的封装功能，它将测试包名字、测试包初始化函数、清理函数和其关联的测试用例封装起来。#p#分页标题#e#

CU_SuiteInfo suites[] = {
{ "suitename1", suite1_init-func, suite1_cleanup_func, test_array1 },
{ "suitename2", suite2_init-func, suite2_cleanup_func, test_array2 },
CU_SUITE_INFO_NULL,
};

这样，我们将整个注册流程简化为：

CU_ErrorCode error = CU_register_suites(suites);

或者

CU_ErrorCode error = CU_register_nsuites(2, suites1, suites2);

这些函数的返回值和包注册函数、测试用例关联函数相同

4.5 设置当前活动测试包和测试用例

CU_ErrorCode CU_set_suite_active(CU_pSuite pSuite, CU_BOOL fNewActive)

　　CU_ErrorCode CU_set_test_active(CU_pTest pTest, CU_BOOL fNewActive)

这些函数被用来测试包测试用例为当前活动包和当前活动测试用例，一个测试包或者测试用例在执行测试时不会被执行，除非用户将它设置为是当前活动的。所有的测试包和测试用例在创建时被默认设置为活动的。当前活动状态可以通过pSuite->fActive或pTest->fActive获取。这样，客户端就有能力动态地选择测试用例去执行测试。如果参数对应的包或者用例不存在则返回CUE_NOSUIT或CUI_NOTEST。

4.6 修改测试包和测试用例的属性

CU_ErrorCode CU_set_suite_name(CU_pSuite pSuite, const char *strNewName)
CU_ErrorCode CU_set_test_name(CU_pTest pTest, const char *strNewName)
CU_ErrorCode CU_set_suite_initfunc(CU_pSuite pSuite, CU_InitializeFunc pNewInit)
CU_ErrorCode CU_set_suite_cleanupfunc(CU_pSuite pSuite, CU_CleanupFunc pNewClean)
CU_ErrorCode CU_set_test_func(CU_pTest pTest, CU_TestFunc pNewFunc)

4.7 测试包和测试用例的查询

大多数情况下，客户端可以通过注册测试包和关联测试用例获取它们的引用。有时候客户端可能需要有能力去检索某个测试包或测试用例的引用。CUnit提供给客户端获取某个测试包或测试用例信息的能力。

CU_pSuite CU_get_suite(const char* strName)
CU_pSuite CU_get_suite_at_pos(unsigned int pos)
unsigned int CU_get_suite_pos(CU_pSuite pSuite)
unsigned int CU_get_suite_pos_by_name(const char* strName)

这些函数使用户查询注册到当前活动注册簿中的测试包。可以通过传入名字、位置参数来获取测试包，如果该测试包不存在，则返回NULL。位置参数从1开始到注册簿中的测试包数。按名字查询的方式只返回测试包链表中的第一个测试包。如果注册簿没有初始化则错误码为CUE_NOREGISTRY，相应的，如果按名字查找的包不存在，错误码为CUE_NO_SUITENAME且返回NULL。

CU_pTest CU_get_test(CU_pSuite pSuite, const char *strName)
CU_pTest CU_get_test_at_pos(CU_pSuite pSuite, unsigned int pos)
unsigned int CU_get_test_pos(CU_pSuite pSuite, CU_pTest pTest)
unsigned int CU_get_test_pos_by_name(CU_pSuite pSuite, const char *strName)

如上函数和测试包查询类似。

5. 运行测试

5.1 常用相关函数

#include 
void         CU_automated_run_tests(void)
CU_ErrorCode CU_list_tests_to_file(void)
void         CU_set_output_filename(const char* szFilenameRoot)
#include 
typedef enum     CU_BasicRunMode
CU_ErrorCode     CU_basic_run_tests(void)
CU_ErrorCode     CU_basic_run_suite(CU_pSuite pSuite)
CU_ErrorCode     CU_basic_run_test(CU_pSuite pSuite, CU_pTest pTest)
void             CU_basic_set_mode(CU_BasicRunMode mode)
CU_BasicRunMode CU_basic_get_mode(void)
void             CU_basic_show_failures(CU_pFailureRecord pFailure)
#include 
void CU_console_run_tests(void)
#include 
void CU_curses_run_tests(void)
#include 
unsigned int CU_get_number_of_suites_run(void)
unsigned int CU_get_number_of_suites_failed(void)
unsigned int CU_get_number_of_tests_run(void)
unsigned int CU_get_number_of_tests_failed(void)
unsigned int CU_get_number_of_asserts(void)
unsigned int CU_get_number_of_successes(void)
unsigned int CU_get_number_of_failures(void)
typedef struct CU_RunSummary
typedef CU_Runsummary* CU_pRunSummary
const CU_pRunSummary CU_get_run_summary(void)
typedef struct CU_FailureRecord
typedef CU_FailureRecord*  CU_pFailureRecord
const CU_pFailureRecord CU_get_failure_list(void)
unsigned int CU_get_number_of_failure_records(void)
void CU_set_fail_on_inactive(CU_BOOL new_inactive)
CU_BOOL CU_get_fail_on_inactive(void)

5.2 自动模式

CUnit支持运行注册簿中所有的测试用例，它同时支持单独运行某个测试包或测试用例。 CUnit框架会在每个测试运行期间跟踪测试包、用例、断言以及断言通过和失败的数量。需要注意的是，每次测试初始化（即便是初始化失败）前次的测试结果都会被清空。，如果客户端想排除某些用例以做某个特殊测试，单个测试包或测试用例可以被设置为非活动。

自动模式接口提供非交互模式测试，用户初始化测试并运行，结果被导出到一个XML文件，所有的测试注册簿和测试包均可以被导出到XML文件。自动模式接口包括如下函数：

void CU_automated_run_tests(void) 该函数运行注册簿中所有活动的的测试包，测试结果被输出到一个名字为ROOT-Results的XML文件。ROOT可以通过 CU_set_output_filename()设置，否则使用默认文件名 CUnitAutomated-Results.xml。需要指出的是，如果不设置一个独特的名字，测试结果会被覆盖。

CU_ErrorCode CU_list_tests_to_file(void) 该函数在文件中列出所有注册的测试包及相关联的测试用例。列表文件名为ROOT-Listing.XML。名字ROOT可以通过 CU_set_output_filename()设置，否则默认文件名CUnitAutomated便被启用，同样的，如果不区分名字，该列表文件将会被覆盖。需要指出的是，如果用户需要一个列表文件，他必须显示地去调用该接口函数。

void CU_set_output_filename(const char* szFilenameRoot) 这个函数用于设置输出结果或列表文件的文件名，该参数后面会相应的追加-Results.xml或-Listing.xml。

　　常见的 XSS 输入

　　XSS 输入通常包含 JavaScript 脚本，如弹出恶意警告框：<script>alert("XSS");</script>

　　XSS 输入也可能是 HTML 代码段，譬如：

　　网页不停地刷新 <meta http-equiv="refresh" content="0;">

　　嵌入其它网站的链接 <iframe src=http://xxxx width=250 height=250></iframe>

　　XSS (Cross Site Scripting) Cheat Sheet 维护了一份常见的 XSS 攻击脚本列表，可用来作为检测 WEB 应用是否存在 XSS 漏洞的测试用例输入。初次接触 XSS 攻击的开发人员可能会对列表提供的一些 XSS 输入不是很理解，本文第二部分将会针对不同代码上下文的 XSS 输入作进一步的解释。

　　测试工具

　　很多工具可以在浏览器发送 Get/Post 请求前将其截取，攻击者可以修改请求中的数据，从而绕过 JavaScript 的检验将恶意数据注入服务器。以下是一些常用的截取 HTTP 请求的工具列表。

Paros proxy (http://www.parosproxy.org)
Fiddler (http://www.fiddlertool.com/fiddler)
Burp proxy (http://www.portswigger.net/proxy/)
TamperIE (http://www.bayden.com/dl/TamperIESetup.exe)

　　笔者曾经使用 TamperIE 对 WEB 应用进行安全性测试。TamperIE 小巧易用，能够截取 IE 浏览器发送的 Get/Post 请求，甚至能绕过 SSL 加密。不过 TamperIE + IE7 工作不稳定。IE7 提供了对 IPV6 的支持，如果你并不计划测试你的 Web 应用对 IPV6 的支持，建议还是使用 TamperIE + IE6 的组合。

　　如图2所示: TamperIE 绕过客户端浏览器 JavaScript 的校验，在 POST 请求提交时将其截取，用户可以任意修改表单输入项 name 和 message 的值，譬如将 message 的值修改为 "<script>alert(“XSS hole!!”);</script>"，然后点击 ”Send altered data” 按钮，将修改后的恶意数据发送给 Web 服务器。

　　图 2. 使用 TamperIE 截取 Post 请求

　　在输出端对动态内容进行编码

　　对一个 Web 应用而言，其动态内容可能来源于用户输入、后台数据库、硬件状态改变或是网络信息等。动态内容特别是来自用户输入的动态内容很有可能包含恶意数据，从而影响网页的正常显示或是执行恶意脚本。将动态内容安全地显示在浏览器端与动态内容所处的上下文背景有关，譬如动态内容处在 HTML 正文、表单元素的属性、或是 JavaScript 代码段中。对于一个基于 PHP 语言的 Web 应用，当执行"echo"、"print"、"printf"、"<?=" 等语句时表示正在处理动态内容。本节将首先介绍 PHP 提供的库函数 htmlspecialchars()的用法，此函数能将 5 个 HTML 特殊字符转化为可在网页显示的 HTML 实体编码;然后将介绍一些常见背景下的 XSS 攻击输入，以及如何在输出端对动态内容进行转义、编码从而避免 XSS 攻击。

　　使用 PHP 的 htmlspecialchars() 显示 HTML 特殊字符

　　从上文列举的 XSS 恶意输入可以看到，这些输入中包含了一些特殊的 HTML 字符如 "<"、">"。当传送到客户端浏览器显示时，浏览器会解释执行这些 HTML 或JavaScript 代码而不是直接显示这些字符串。< > & “ 等字符在HTML语言中有特殊含义，对于用户输入的特殊字符，如何直接显示在网页中而不是被浏览器当作特殊字符进行解析?

　　HTML字符实体由 & 符号、实体名字或者 # 加上实体编号、分号三部分组成。以下为 HTML 中一些特殊字符的编码。有的字符实体只有实体编号，没有对应的实体名字，譬如单引号。

　　PHP 提供了htmlspecialchars()函数可以将 HTML 特殊字符转化成在网页上显示的字符实体编码。这样即使用户输入了各种 HTML 标记，在读回到浏览器时，会直接显示这些 HTML 标记，而不是解释执行。htmlspecialchars()函数可以将以下五种 HTML 特殊字符转成字符实体编码：#p#分页标题#e#

& 转成 &
“ 转成 "
< 转成 <
> 转成 >
‘ 转成 '

　　当直接调用 htmlspecialchars($str)时, & " < > 被转义。

　　当设置 ENT_QUOTES 标记时, 即调用htmlspecialchars($str, ENT_QUOTES)时，单引号也被转义。

　　当设置 ENT_NOQUOTES 标记时，单引号和双引号都不会被转义。即调用 htmlspecialchars($str, ENT_NOQUOTES)时，只有& < > 被转义。

　　不同背景下的动态内容的 XSS 攻击及解决方案

　　XSS 攻击输入与动态内容所处的代码背景相关，譬如动态内容为表单元素属性的值、位于 HTML 正文、或是 Javascript 代码段中等等。

　　HTML标记的属性为动态内容

　　Web 应用中，"input"、"style"、"color" 等 HTML 标记的属性都可能为动态内容，其中"input" 标记的 "value" 属性通常为动态内容。

　　例子1

<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 value="<?= $msg?>"></form>

　　攻击XSS输入

Hello"><script>evil_script()</script>

　　将动态内容替换

　　将 $msg 替换为恶意 XSS 输入:

<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 
value="Hello"><script>evil_script()</script>"></form>

　　例子2

<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 value=<?= $msg?>></form>

　　攻击 XSS 输入

Hello onmouseover=evil_script()

　　将动态内容替换

　　将 $msg 替换为恶意 XSS 输入:

<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 
value=Hello onmouseover=evil_script()></form>

　　分析

　　从例子 1 可以看到其 XSS攻击输入中包含了 HTML 特殊字符 < > "

　　从例子 2 可以看到其 XSS 攻击输入中没有包含上节中提到的五种 HTML 字符， 但是 "value"属性值没有使用双引号包围。

　　解决方案

　　调用htmlspecialchars($str, ENT_QUOTES)将以下 5 种 HTML 特殊字符 < > &‘ “ 转义;同时使属性值被双引号包围。譬如：

<form…><INPUT type=text name="msg" id="msg" size=10 maxlength=8 
value="<?= htmlspecialchars($msg, ENT_QUOTES))?>"></form>

　　注意事项

　　将 input 的 value 进行转义，必须考虑显示和存储数据的一致性问题，即显示在浏览器端和存储在服务器端后台的数据可能因为转义而变得不一致。譬如存储在服务器端的后台原始数据包含了以上 5 种特殊字符，但是没有转义，为了防止 XSS 攻击，在浏览器端输出时对 HTML 特殊字符进行了转义：#p#分页标题#e#

　　1. 当再度将表单提交时，存储的内容将会变成转义后的值。

　　2. 当使用 JavaScript 操作表单元素，需要使用到表单元素的值时，必须考虑到值可能已经被转义。

　　HTML文本为动态内容

　　例子

<b> 欢迎：<?= $welcome_msg?></b>
攻击XSS输入
<script>evil_script()</script>
将动态内容替换
将$welcome_msg 替换为恶意 XSS 输入:
<b>欢迎：<script>evil_script()</script></b>

　　分析

　　在 HTML 正文背景下，< > 字符会引入 HTML 标记，& 可能会认为字符实体编码的开始，所以需要将 < > & 转义

　　解决方案

　　为简洁起见，直接使用 htmlspecialchars()将 5 种 HTML 特殊字符转义，如：

<b>欢迎：<?= htmlspecialchars($welcome_msg,, ENT_NOQUOTES)?></b>

　　URL的值为动态内容

　　Script/Style/Img/ActiveX/Applet/Frameset… 等标记的 src 或 href 属性如果为动态内容，必须确保这些 URL 没有指向恶意链接。

　　例子1

<script src=<?= "$script_url>">
攻击XSS输入
http://evil.org/evil.js
将动态内容替换
将$script_url替换为恶意 XSS 输入:
<script src="http://evil.org/evil.js">

　　例子2

<img src=”<?= $img_url>”>
攻击XSS输入
javascript:evil_script()
将动态内容替换
将$img_url替换为恶意XSS输入:
<img src=” javascript:evil_script()”>

　　分析

　　一般情况下尽量不要让 URL 的值被用户控制。如果用户需要自己定义自己的风格及显示效果，也不能让用户直接控制整个 URL 的内容，而是提供预定义好的风格供用户设置、装配，然后由后台程序根据用户的选择组合成安全的 URL 输出。

　　字符集编码

　　浏览器需要知道字符集编码才能正确地显示网页。如果字符集编码没有显式在 content-type 或meta 中定义，浏览器会有算法猜测网页的字符集编码。譬如<script>alert(document.cookie)</script> 的 UTF-7 编码为：

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

　　如果+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-作为动态内容位于网页的顶端并传送到浏览器端，IE 会认为此网页是 UTF-7 编码，从而使网页不能正常显示。

　　解决方案

　　显式定义网页的字符集编码，譬如

<meta http-equiv=content-type content="text/html; charset=UTF-8">

　　动态内容为JavaScript事件处理函数的参数

　　JavaScript 事件处理函数如 onClick/onLoad/onError/onMouseOver/ 的参数可能包含动态内容。

　　例子

<input type="button" value="go to" onClick='goto_url("<?= $target_url>");'>
攻击XSS输入
foo");evil_script("
将动态内容替换
HTML 解析器会先于 JavaScript 解析器解析网页，将$target_url 替换为恶意 XSS 输入:
<input type="button" value="go to" onClick='goto_url("foo");evil_script("");'>
动态内容位于 JavaScript 代码段中

　　例子

<SCRIPT language="javascript1.2"> var msg='<?= $welcome_msg?> '; // … </SCRIPT>
攻击XSS输入1
Hello'; evil_script(); //
将动态内容替换
将 $welcome_msg 替换为恶意 XSS 输入:
<SCRIPT language="javascript1.2"> var msg='Hello'; evil_script(); //'; // … </SCRIPT>
攻击XSS输入2
Hello</script><script>evil_script();</script><script>
将动态内容替换
将$welcome_msg 替换为恶意 XSS 输入:
<script> var msg = 'Hello</script> <script>evil_script();</script> <script>'
 // ... // do something with msg_text </script>

　　分析

　　如上文所示，在 JavaScript 背景中使用动态内容需要非常谨慎。一般情况下，尽量避免或减少在 Javascript 的背景下使用动态内容，如果必须使用动态内容，在开发或代码审计时必须考虑这些动态内容可能的取值，是否会导致 XSS 攻击。

　　建立PHP库函数校验输入

　　Web 开发人员必须了解，仅仅在客户端使用 JavaScript 函数对非法输入进行检测过滤对于构建安全的 WEB 应用是不够的。如上文所述，攻击者可以轻易地借助工具绕过 JavaScript 校验甚至 SSL 加密输入恶意数据。在输出端对动态内容进行编码也只能起到一种双重保护的作用，更重要的应该在服务器端对输入进行校验。PHP 提供了strpos()、strstr()、preg_match()等函数可用于检测非法字符和字符串;preg_replace() 函数可用于替换非法字符串。OWASP PHP Filters 开源项目提供了一些 PHP 库函数用于过滤非法输入可作为参考。一些常见的检测和过滤包括：

　　输入是否仅仅包含合法的字符;

　　输入如果为数字，数字是否在指定的范围;

　　输入字符串是否超过最大长度限制;

　　输入是否符合特殊的格式要求，譬如email 地址、IP 地址;

　　不同的输入框在逻辑上存在的耦合和限制的关系;

　　除去输入首尾的空格;

　　总结

　　Web 应用的安全性是一个很重要、覆盖范围很广泛的主题。为了防止常见的 XSS 的攻击，Web 开发人员必须明白不能仅仅只在客户端使用 JavaScript 对输入进行检测、过滤;同时还应建立服务器端的输入校验、输出编码库函数;在服务器端检测、过滤输入;根据动态内容所处的背景将特殊字符进行编码后再传送给浏览器端显示。

　　5月6日消息，《华尔街日报》从知情人士处获悉，百度联合宝马、奥迪、奔驰向芬兰诺基亚发出了收购后者HERE地图业务的邀约，目前谈判已进入最后阶段，有望在两周内达成协议。

　　宝马、奥迪和奔驰在豪车市场通常是激烈竞争的对手，但如今他们因担心硅谷掌控汽车产业而决定抱团收购诺基亚的地图业务，以避免谷歌、苹果或Facebook取得一项在自动驾驶汽车和车内数字服务领域的关键技术。

　　知情人士透露，由德国三大豪华汽车制造商牵头的财团准备协同中国科技公司百度，正式就收购诺基亚公司HERE地图业务的多数股权发出收购提议，并给予HERE远高于20亿欧元的价值。

　　知情人士说，谈判已进入后期阶段，可能在未来两周内达成协议，但包括交易价格与股份配置等细节仍有可能改变。

　　这三大德国汽车制造商希望取得控制股权。百度与一名未透露的财务投资者则将取得少数股份。诺基亚也会保留少数股份。

　　诺基亚拒绝就此事置评。

　　据经济之声《天下财经》报道，诺基亚公司董事长昨天表示，在完成对HERE地图业务的评估后，公司最终可能决定不出售这项业务。目前，这项业务已经吸引了来自汽车制造商和零部件供应商的目光，而社交网站Facebook和打车软件公司Uber也很感兴趣。

　　根据诺基亚最新财报显示，今年一季度，HERE地图业务营收比去年同期增长了25%，达到了2.61亿欧元，而诺基亚还将这项业务的全年运营利润率预期从此前的7%到12%上调到9%到12%。

　　另据外媒消息称，芬兰诺基亚董事长Risto Siilasmaa本周二在诺基亚年度股东大会上表示，公司还未在是否出售HERE地图业务上做出最后决定。

　　据《华尔街日报》报道，百度现在也向诺基亚发出了收购Here地图的邀约，同时联合的还有宝马、奔驰和奥迪，都是有钱的主。

　　据悉，这次的联合收购出价有可能超过诺基亚报出的32亿美元，那这么一来Here几乎就真有可能成了百度家的了。至于宝马、奔驰和奥迪为何也想掺一脚，有解释称是这德系三雄担心硅谷掌控汽车产业。

　　而百度的目的就更明显了，百度地图目前在国内正与高德竞争，但苦于没有自己强大图资团队而有些被动。百度目前负责地图服务的团队显然不如Here强大。

　　诺基亚出售Here地图的目的是希望能够缓解财政压力，将地图业务出售后全力进攻移动网络业务。现在已经有多家公司进行接洽，包括FaceBook、Sirius XM、百度、亚马逊、阿里巴巴、Uber等等。

　　诺基亚Here地图，是由诺基亚推出的地图服务。已于2012年11月20日正式登陆苹果商城。这款地图在上市后短短15分钟时间内已从原来的101名上升至32名。该款软件的功能是提供免费turn-by-turn语音导航，公共交通信息，以及丰富的道路交通信息等。但是也存在缺陷，比如在公共汽车以及地铁等重要公共交通信息提供上经常性的设置一些无意义的导航。

　　Here for Android提供了一线地图应用所需的各种功能，包括语音导航、交通信息、离线地图(包括离线导航)，以及将自己的位置与家人好友分享等。

　　2014年12月11月，诺基亚的地图应用Here for Android在谷歌Play商店中上线。2014年10月，这款应用首先出现在三星Galaxy系列产品中。[1]

　　2014年12月，诺基亚与百度达成一项合作协议，诺基亚地图及导航业务Here将向百度提供中国内地以外的地图数据服务。[2]

　　其中的缺陷和测试用例管理，发现很多思路和做法跟目前我们在进行的也颇为相似，总结如下：

　　缺陷管理和用例管理是一个软件测试项目的必备，无论是数千人的国际化大企业，还是三五人的小软件作坊。这都是测试队伍的两大工作成果。其中，测试用例描述测试过程的意图，缺陷则描述这些测试用例的结果，今天谈谈缺陷工作流程。

　　缺陷工作流程为：

　　文字描述如下：

　　产品代码-》运行测试用例-》创建缺陷报告-》三方会审讨论缺陷

　　如果缺陷没有批准-》把缺陷当作不修正来解决-》关闭缺陷

　　如果缺陷批准了要调查-》研究是代码错误还是设计错误

　　如果是代码错误，提议修正代码错误-，在提交三方会审-》如果修正批准了-》修改代码-》解决缺陷-》重现缺陷-》通过了则关闭缺陷;不通过，则重新激活-》重新调查是代码错误还是设计错误

　　如果是设计错误，修正错误直到批准-》再进行三方会审。其他后续流程和以前类似。

　　在这里需要注意的是，有些缺陷需要综合考虑优先级别，产品发布周期等因素，标注为不予修复。也就是说虽然承认该缺陷，但不会修正，或者决定推迟修正，即该缺陷会在未来的版本修正。这些不予修正的缺陷应该在releasenotes中予以注明。

　　这里所说的三方会审，一般意义上指的是开发测试和项目管理。

　　缺陷报告中应该经常避免的几个错误：

　　1、电子邮件讨论

　　电子邮件和缺陷系统是大多数的工程师常用的工具，所以很多时候两者被混用就不足为怪了。然后除了开发工程师和测试工程师之外，缺陷报告还有其他的广泛用途，所以和缺陷不直接相关的信息不应该被写入报告。

　　2、缺陷渐变

　　缺陷渐变是说在同一个缺陷的报告中，缺陷从一个问题演变成另外一个不相关的问题。这种现象有时候发生很快，有时候过几天或者几个月。不管怎么样，都要极力避免缺陷渐变。对于已经变形的缺陷，通常很难分析其中根本原因，产品支持工程师在搜索相关问题时候还会发生混淆。如果一个缺陷报告开始演变，要及时停止，并就新问题重新报告一个新的缺陷。

　　3、对个缺陷

　　如果测试人员很忙碌，他们可能会相关的缺陷记录放在一个缺陷报告中。尽管我们尽力避免这类问题，在一个缺陷报告中报告几个问题从来就不是好主意。这会带来一系列的问题，比如：

　　(1)缺陷的优先级别不能单独设置

　　(2)缺陷的决定不能单独设置，比如立即修复还是推迟到下一版本

　　(3)虽然缺陷在类似领域，但是可能需要分配给不同的开发工程师

　　(4)在分析产品缺陷的根本原因时候，同一缺陷报告中的每个缺陷可能有不同的错误根源。

　　关于缺陷报告的时候

　　这似乎是管理层最喜欢干的事情，这些报告发掘和代表了各种各样的数据。比如下面的一些度量：

　　(1)修复的缺陷/所有解决了的缺陷：可以衡量缺陷修正和其他决断的比例

　　(2)缺陷发现率

　　(3)缺陷修正率：当缺陷会审标准提高时候，修正的百分比下降

　　(4)每个组件的缺陷数：根据功能排序可以影响哪些领域需要更多的测试

　　(5)如何发现缺陷：了解缺陷如何发现可以帮助根源分析和实现缺陷防止技术

　　(6)每个测试活动发现的缺陷：分析测试类别包括结构化测试，发布前测试，测试用例开发，自动化测试等

　　(7)平均解决缺陷的时间：跟踪开发团队对输入的缺陷的响应速度

　　(8)平均关闭缺陷的时间：跟踪缺陷的平均反应时间

　　缺陷数据唯一不能使用的时候：绩效衡量

　　缺陷数据具有太多的可变量，比如：

　　(1)所测试功能的复杂性

　　(2)开发人员的编程能力

　　(3)规格完整性

　　(4)缺陷预防和缺陷发现

　　(5)报告的及时性

　　使用的是： Apache 2.0.53 + PHP 4.3.10 + MySQL 4.0.23 + Mantis 0.19.2

　　由于服务器数据需要升级到MySQL 5.0.67，而4.*l和5.*有一些不兼容，导致，无法将旧的

　　Mantis的Mysql4.*库导入到MySQL 5.*中，索性，全面升级Mantis，重新配置。

　　新的配置是： Apache 2.2.10 + PHP 5.2.6 + MySQL 5.0.67 + Mantis 1.1.4

　　配置总体手顺如下：【以下内容转载】

　　最近要搭建一个Bug跟踪管理系统，开源免费的Mantis自然首当其冲。要运行Mantis，有两种主流的环境配置：IIS+PHP+MySQL+Mantis和Apache+PHP+MySQL+Mantis，本文主要介绍后一种。

　　首先介绍如何在Apache上运行PHP：

　　1.安装Apache

　　首先下载Apache服务器的windows版本，网址为：http://httpd.apache.org/download.cgi，最新版本为Apache2.2，下载完后安装。

　　注意：检查80端口有没有被占用，本人安装时就由于打开IIS，导致apache无法启动。如果要查看80端口被哪个程序占用，可以在命令行窗口中输入netstat -o -an，找到占用该端口的程序的PID，然后在任务管理器中点"查看"->"选择列..."，勾选"PID"，找到该PID的程序，结束任务。 测试apache是否是否工作，安装后可以打开浏览器，输入http://localhost/验证Apache是否成功，如果成功则显示：It works 字样。

　　2.安装PHP

　　首先下载PHP，网址为：http://www.php.net/downloads.php，最新版本为PHP5.2.6，注意下载有两种版本：.zip版本和 安装版。先执行安装版，安装中选择支持apache 2.2.x，那么会自动配置apache的http.conf文件、mime.types文件和产生PHP的php.ini文件。注意：在安装中我遇到过问题，如果选择默认安装，则很顺利没有错误，如果选择自定义安装且将所有的组件都选择安装，那么会发生错误，原因我现在也没搞清楚。

　　由于，安装版本内容不全，没有ext和pear等目录，所以，安装完后，将解压版解压到刚才的安装目录下。

　　3.apache与PHP整合

　　安装版的PHP安装后，apache2.2的httpd.conf，会自动添加以下两行(如果没有要添加上)：

　　PHPIniDir "G:/JCDevTool/PHP5/"

　　LoadModule php5_module "G:/JCDevTool/PHP5/php5apache2_2.dll"

　　mime.type文件自动增加如下两行：

　　application/x-httpd-php php

　　application/x-httpd-php-source phps

　　注意：G:/JCDevTool是PHP的安装目录，如果是apache2.2，必须写"php5apache2_2.dll"。

　　PHP已apache模块的方式与Apache结合。是你的WEB网站具有支持PHP服务器脚本程序的能力。

　　4.测试是否配置成功

　　测试PHP是否加载成功：

　　编写一个PHP文件(hello.php)：

　　将该文件复制到C:\apache2.2\htdocs中，然后浏览器中输入http://localhost/hello.php，如果显示"hello,php"，则表示加载成功。

　　接下来介绍如何安装MySQL：

　　这个比较简单，首先下载MySQL，网址为：http://dev.mysql.com/downloads/，最新的稳定版本为5.0.67，下载完后按照安装向导一步一步就可以完成安装了。

　　最后介绍如何安装配置Mantis：

　　1.安装Mantis

　　首先下载Mantis，网址为：http://www.mantisbt.org/download.php，最新的稳定版本为Mantis1.1.4，下载完后解压到C:\mantis-1.1.4。

　　2.配置Apache

　　也就是向Apache暴露Mantis的位置。修改%APACHE_HOME%\conf\httpd.conf，在文件末尾添加以下文字，以配置mantis目录的访问权限：

　　Alias /mantis "c:/mantis-1.1.4/"

　　Options Indexes

　　AllowOverride None

　　Order allow,deny

　　Allow from all

　　注意：这里特别注意，必须写成UNIX路径的/，不能写成Window路径的\,否则会无法正确显示mantis。

　　可选配置：如果希望在浏览器中直接输入目录名(即http://localhost/mantis)就可以访问Mantis主页(如果不添加，则每次都显示Mantis目录下的文件和子目录列表，又安全隐患)，可以在dir_module标签中添加上index.php：

　　DirectoryIndex index.html index.php

　　这样就可以在浏览器中直接输入目录名了(当然，这时候访问还会出错，因为mantis数据库还没建立呢，不要急，我们一会马上去创建。)#p#分页标题#e#

　　3.配置PHP

　　因为我们需要使用基于PHP的应用程序Mantis,而Mantis本身的特性需要(如使用MySQL数据库等)，就要求我们去修改php.ini文件：

　　(1)包含Pear库(Mantis中用到了Pear库)

　　查找include_path，改为include_path=".;C:\php5.2\PEAR"，并去掉前面的分号

　　(2)包含外部PHP库(因为需要知道php_mysql.dll动态库的路径)

　　查找extension_dir，改为extension_dir="C:\php5.2\ext"，并去掉前面的分号

　　(3)包含PHP-MySQL库(因为需要支持MYSQL)

　　查找php_mysql.dll，去掉前面的分号,这样PHP就能调用mysql模块了

　　4.为Mantis创建表、数据

　　访问http://localhost/mantis/admin/install.php，输入MySQL的用户名和密码，然后点击Install/Upgrade Database，就会自动建立Mantis所需要的数据库和所有数据表。(这里注意，这是和以前的mantis比较大的不同，以前的mantis，如 mantis-0.19.4.tar.gz版本，会提供一个db_generate.sql数据库脚本来创建mantis需要的数据库，而新版 mantis则通过install界面来自动创建。，还需要注意的是，这里的内容多是从mantis/config_inc.php中获取，特别需要注意的是Hostname一栏，默认值为localhost，而MySQL安装时变动了端口，则应该写成 localhost:端口号，别忘同时修改config_inc.php文件)

　　这里还要注意一个问题，有时创建时会失败，提示：【Checking PHP support for database type 】的错误：BAD database is not supported by PHP. Check that it has been compiled into your server.查看apache的log发现有如下错误：PHP Warning: PHP Startup: Unable to load dynamic library 'd:\\Program Files\\PHP\\ext\\php_mysql.dll' - \xd5\xd2\xb2\xbb\xb5\xbd\xd6\xb8\xb6\xa8\xb5\xc4\xc4\xa3\xbf\xe9\xa1\xa3\r\n in Unknown on line 0 这是因为不能正确加载php_mysql.dll库，导致php与mysql不能连携，请检查环境变量中path是否有：【安装路径】\PHP和【安装路径】\PHP\ext 类似的配置。如果没有请将该路径添加到path中。特别再注意，添加后请务必重启OS，才能生效。

　　5.启动Mantis

　　访问http://localhost/mantis/，出现登录界面，(注意，mantis的默认用户名为administrator，默认密码为root。)

　　6.邮件服务器配置

　　在Mantis中注册新用户时，会给你指定的邮箱发一封邮件，点开邮件中的链接才可以设定密码，因此需要给Mantis添加邮件功能。

　　使用phpmailer作为邮件服务器，首先下载phpmailer，网址为：http://phpmailer.codeworxtech.com，下载完后解压到c:\phpmailer。

　　修改C:\mantis-1.1.4\config_inc.php，添加以下内容：

　　$g_smtp_host = 'smtp.sina.com.cn';

　　$g_smtp_username = 'xinqian3607';

　　$g_smtp_password = '123456';

　　$g_use_phpMailer = ON;

　　$g_phpMailer_path = 'c:/phpmailer/';

　　$g_phpMailer_method = 2;

　　$g_return_path_email = 'xinqian3607@sina.com'

　　把其中的内容修改为你自己的邮箱信息就可以了，赶紧点击修改密码，试一试能不能收邮件吧~

　　【-------转载完毕-----------】

　　心得：

　　由于是第一次配置，以前都是其他人负责，所以，重新配置时很多概念都没有，就看手顺来配置，感觉很混乱，所以，去补充了一些周边知识，了解了这些知识后，再来看上面看似很繁琐的手顺，其实就很容易理解了。

　　知识1：WAMP=windows+Apache+MySQL+PHP，是一个开发网络应用程序的网络开发平台(全是开源软件)，因为mantis就是 PHP应用，即Mantis就是PHP脚本语言写出来的程序。所以，要使用mantis，先搭建好mantis运行的环境是必须的步骤。

　　知识2：mantis是需要数据库来管理用户登陆的BUG的，所以，我们还需要使用MySQL，当然，不是必须使用MySQL(插一句：mantis是希望实现与具体数据库系统无关的更通用的bug管理系统。从现在的数据库创建方式就很明确了。)

　　知识3：所以，配置的思路就是，apache(http.conf)支持PHP，PHP(php.ini)支持MySQL，apache(http.conf)支持Mantis;Mantis创建MySQL数据库;