关键词：自动化测试    测试框架    组件

        做功能自动化测试都会不约而同的遇到一个比较棘手的问题－测试框架的搭建。这也是直接影响功能自动化测试成功与否的关键。框架做的好可以使测试事半功倍，反之轻则很难看到工作的成果重则会使整个测试失败。目前网上有很多关于测试框架的讨论，其中也有成型的测试框架，其中有很多好的思想在里边，很值得借鉴。但今天要讨论的不是网上已有的，而是HP已经为我们设计好的一个测试体系，业务组件测试。他是利用QTP与QC的完美结合组成的一个体系架构。它可以轻易实现目前比较流行的三层测试架构：脚本层，业务层，数据层相分离，为开展功能自动化测试提供一个高效、稳定、容易的测试实现。

        一．概述

        1．1业务组件（Bussiness ProcessTesting）简介

        业务组件是组成流程测试的基本单元，组合不同的业务组件可以实现不同的业务流程测试。如将fligt系统的登录最为一个组件，选择航班最为一个组件等。这样可以实现组件的复用，提高开发效率。

         1．2 Bussiness Process Testing的优点

        1）   相关业务人员可以在没有脚本的环境下组合业务组件，实现业务流程。

        2）   对业务人员的编程能力没有要求，业务人员只需了解系统的业务流程，不用关心具体的脚本实现。这一点也实现了业务层和脚本层的分离。

        3）   一旦某个组件开发完毕，即可在不同的流程中使用该组件，实现高可复用性，从而加快业务流程测试的速度。

        4）   明确的角色分工，业务人员负责流程的开发、组织；QTP工程师负责脚本的开发、维护以及相应函数库的开发、维护。

        5）   因为实现了脚本的复用，提高了自动化开发的效率，无形中就降低了测试过程中维护的时间和成本。

        1．3 Bussiness Process Testing的简易流程

        如图所示，整个过程分为2条线：第一个是由业务测试人员划分组件并组合不同的组件实现不同的流程测试；其次QTP专家负责组件的脚本具体实现并负责调试成功，上传到QC供业务测试人员调用。

        注：测试数据的组织后边介绍，以便实现三层的测试架构；此过程需要QC有Bussiness Process Testing组件许可的支持，也就是需要单独向HP购买。

        下边以QTP自带的示例程序演示整个流程的开发过程

        2．1划分组件

        本次将系统划分为：登录；选择航班并插入；打开订单；更新订单；删除订单；注销。这样划分仅为演示之用，不用在实际的测试之中。

        2．2组织业务测试流程

        本次只是用于演示，所以流程不会100％覆盖，在实际的测试过程中要达到100％的流程覆盖。本次测试流程如下：

        流程1：登录－选择航班并插入－注销

        流程2：登录－选择航班并插入－更新订单－注销

        流程3：登录－选择航班并插入－更新订单－删除订单－注销

        流程4：登录－打开订单－更新订单－删除订单－注销

        下边需要根据划分的组件来实现组件脚本的实现。

        2．3创建应用程序区域

        在开发脚本之前首先要做的是要创建一个应用程序区域。应用程序区域提供创建业务组件所需的所有资源和设置，每个业务组建都居于一个应用程序区域，并从这些应用程序区域集成这些资源和设置。在此创建一个名为“订票系统流程测试”的区域，如图所示。

        创建过程:依次选择:file－New－Function library。保存后自动上传至QC默认目录。

        在此也可以加载自己的函数库，对象库，恢复场景等，这样以后创建的组建都可以共享该应用程序区域的资源。同时也方便维护，这也是一个优点所在，例如一旦函数库改变在此从新加载新的函数库即可，不用在脚本理修改。总之这个应用程序区域很重要，以后所有的脚本均是基于这个区域。应用程序路径一定要加载正确，否则录制时不能生成脚本。

        2．4创建脚本

        在创建脚本之前最好在QC中组织好目录树，方便保存及调用。关于脚本的开发过程，每个人、每个公司都有自己的方法。在此源代码也没法一一贴出。所以在此只列出输入参数和输出参数，方便后边的参数化以及数据组织。本次也采用最通用的方式即对象库解决对象识别问题。脚本的开发规范以及参数命名也以我自己惯用方式。

注：“－”为无相应参数。
        在QTP中创建组件脚本有2中模式：Bussiness Component和Scripted Component。区别：Bussiness Component只能见关键字视图，QC中亦可见关键字视图；Scripted Component可以看见专家视图，在QC中脚本代码不可见。一般创建后者，本次也是采用后者，方便编辑脚本，控制脚本结构。
        注意：参数一定要合理设置并对代码中的输入项做参数化与参数关联，否则测试数据传不到脚本，导致脚本运行失败。参数可以在QTP中创建，也可以在QC中创建，效果等同。
        脚本开发完保存至QC，如图:

        至此脚本开发完毕。也实现了脚本和业务层、数据层的脱离，现在单个组件脚本实现业务流程中的某一个功能且脚本中不会涉及具体的测试数据，从而为实现三层结构打下基础。接下来的工作就是在QC中组织需要测试的业务流程以及需要的测试数据。
        这里有一个需要注意的地方，就是在QTP创建脚本如果选择Bussiness Component类型，在“设计步骤”选项卡可以看到QTP中的关键字视图，相关人员可以像在QTP操作一样，但是看不到代码。这也是为何上边为何创建脚本组件的原因。
        2．5业务流程的组织
        业务流程的组织主要是在“测试计划”模块中实现。这的主要工作是由业务测试人员完成。规划好目录结构以后，根据需要测试的业务流程拖拽需要的组件即可。这一步和在“测试计划”中拖拽测试用例很相似，区别就是这个是组合业务流程，而且可以自动执行。组织好后的效果如图：

        需要注意的是，创建用例是请选择“BUSINESS-PROCESS”测试类型，否则组件脚本拖拽不过来。拖拽脚本是在“测试脚本”选项卡中进行，如上图。限于篇幅，在此创建目录和拖拽等动作不再详述，请参见QC的用户手册。另外，根据实际的系统，可以把组件分组，以组的形式控制流程。例如，选择如图的2到4的组件，然后选择工具栏叉号旁边的图标，即可把组件分成一组。这样可以更好的控制流程。
至此，所有的业务流程均以实现。可以在QC中选择运行（绿色箭头），进行相关的调试。
        这里实现的是三层结构中的业务层。这里进行的业务流程组织和脚本没有任何关系，相关人员不用关心脚本如何实现，只要保证所有的流程均已覆盖即可。
        接下来就是要实现数据层的工作了，从而实现三层的测试架构。
        2．6测试数据的组织
        测试数据的组织也是在“测试计划”模块中实现。选择某一个流程，在“测试脚本”选项卡中右击要设计数据的组件，在弹出窗口中选择“迭代”，弹出组件迭代设置窗口，如图：

        在此可以根据测试需求设置组件要迭代的次数，以及每次迭代的参数值。如上图，设置了3次迭代每次迭代输入的订单信息均不相同。同时可以设置输入参数选择上一个组件的输出参数（在复选框中打勾，按提示操作即可），如下图。是流程4中的“打开订单”组件，orderNo参数使用的是“选择航班并插入”组件的输出参数。注意，此流程的“选择航班并插入”设置了三次迭代，所以“打开订单”也要对应三次迭代，否则会提示错误。

 
        在组织数据时，可以在单个组件中设置每次迭代的数据，由于组件的重用次数很多，所以这样做还是有些麻烦。解决方法就是在外部组织好数据后，批量导入。QC默认是txt文本文件，格式可以把现有参数导出，参照它给的格式设计自己数据即可。
        至此，数据层的设计也已完毕。同时也实现了测试数据和具体的业务流程相分离。
        其实，这里的数据和业务层的分离并不是很彻底，不能根据自己的想法去设计，所以还有很大的改进空间，还需要进一步研究。
        通过以上几个步骤，开发工作基本结束。以后就是需要相关的维护即可。当然，最后还是要执行测试。

2．7执行测试
        测试的执行是在“测试实验室”中进行的。这里和操作QC执行用例很相似。也是组织目录，拖拽相应的测试流程即可，这里也不在累述。可参见用户手册执行测试用例部分。当然执行测试可以选择本机执行，也可以选择在远程机器上执行测试，但要注意要安装相应组件和设置主机。执行效果如下图：

        QC会记录每次执行的结果，包括流程中每个组件的执行状态，执行时间等信息。这也是QC的强大之处，它会给出一个很人性化的结果，方便我们后续的分析工作，以及对系统给出一个量化的指标。这一点QC做的相当完善，从需求开始到最后的缺陷分析以及测试报告，都会有一个图形的界面供我们参考，这对我们写测试报告提供了极大的方便，给我们提供了强有力的，可靠的数据支持。
        注：以上全部工作在WinXP（sp3）＋QTP9.5＋QC9.0环境下完成。
        三．总结
        本文只是针对业务组件测试给出了一个简单叙述，QTP以及QC的强大之处远不及这些。对于QTP和QC的其他功能本文没有提及，其他功能在自动化测试中起到的作用，是有些工具不能代替的，也许这也是现在很多公司、很多人都在学习、使用的原因之一吧！前一段时间51的调查文件就是一个很好的证明，HP（Mercury）的所有产品都是遥遥领先其他工具。当然有很多公司也有自己的测试框架，也有自己开发的测试工具。但不可否认QTP确实是一个很好的测试工具，虽然它很贵。
需要提到的是，QTP和QC是一个开放式的架构，HP（也就是以前的MERCURY）为我们提供了很多接口，我们完全可以利用这些接口开发出自己的框架，实现三层乃至更高的框架结构。这些接口以及函数说明都能在QTP的帮助文档中找到。
        最后希望国内的测试发展越来越好，中国的软件越做越好。

　　（1）常常没有方向感，不知道自己要做哪些事；

　　（2）学习时，不知道哪些要先学，哪些后学；

　　（3）当学到一定程度时，不知道还要学习哪些东西；

　　希望能有一个总体流程或思路做参考，所以编写了如下内容；

　　以下只是个人的一些想法，仅供参考，希望大家发表自己的看法，共同探讨，共同进步；

　　1、准备知识

　　（1）什么是性能测试；

　　（2）为什么做性能测试；

　　（3）选择一款适合的工具；——推荐LR；

　　2、LR的学习

　　（1）了解LR能够做些什么；

　　（2）了解LR整体流程，有个大概认识；

　　选择协议——录制脚本——调试脚本——场景设置——运行场景——分析结果

　　（3）了解流程中的每一步应该怎么做；

　　选择协议：了解几个常用协议，一个一个来学习；（目前最常用的是WEB的HTTP协议；这个是重点学习对象，以后有时间时，再学习win socket协议及其它协议）主要还是根据自己公司的被测系统类型来选择；

　　录制脚本：如何录制、录制时参数怎么配置等；

　　调试脚本：运行时设置、集合点、事务、脚本参数化、关联等；

　　场景设置：了解不同场景设置的区别；

　　运行场景：如何查看运行日志，分析错误，各种监控器的使用（事务响应时间、系统资源等等）

　　分析结果：对各种监控器监控的数据进行分析；（这个较多要靠个人经验，不同的项目有自己的特殊性，不能一概而论）；

　　这个阶段，很考查个人知识的全面性；知识越全面，分析的越到位；

　　需要了解的知识：网络知识、操作系统知识、硬件知识、软件知识（WEB服务器配置、数据库知识、底层架构使用到的各软件）等等；

　　一开始我们只能做一个粗略的分析，后面再慢慢的积累经验；通常会由项目经理或系统配置管理人员来配合做结果分析；

　　（4）推荐一些资料：

　　LoadRunner文档资料大全.chm

　　LR 227个问题.chm

　　比较全面的学习资料；

　　其它大部份为一些针对性的资料，根据当前学习的进度来选择查看；

　　3、最最最重点的是：多操作

　　有操作才会遇到各种各样的问题；解决问题是一种很好的积累经验的方法；

　　遇到问题时：

　　（1）首先自己先尝试解决（这个就是一个摸索的过程，可以发现很多以前没注意到的东西）；

　　（2）自己确实无法解决时（不要一个人闷着头在那想半天），网上查找资料；

　　大部份你会遇到的问题，别人也会遇到，网上可能已有解决方案；

　　查找的过程，也会学到很多东西；

　　（3）还是没解决的话，问身边的同事，朋友；吸收别人的经验；

　　4、有一定的理论和实践基础后，可以考虑学习别的性能测试工具

　　LR不是万能的，单单靠它来实现所有的性能测试是不可能的；使用多了，会发现很多力不从心的时候；

　　所以需要了解别的性能测试工具，不同的时候使用不同的工具，选择适合的才是最好的。

粉色题板
1. 在干净的床上裸睡
2. 生理期不吃巧克力，因为会加重痛经
3. 养成记录生理周期的习惯
4. 通过运动而非调整型内衣来塑造曲线
5. 不翘二郎腿，以免压迫神经
6. 贴身衣物不干洗
7. 拉风的丁字裤不适宜日常穿着
8. 去年的衣服要进行曝晒后才可以穿
9. 如非必要，不使用卫生护垫
10. 定期检查化妆品的保质期
11. 洗浴后一小时再化妆
12. 即使爱美，也不要在耳朵上部的外缘软骨部位穿耳洞
13. 了解自己的家庭病史，特别是母亲和外婆的病史

蓝色题板
1. 每天踏进办公室，先将窗户打开透气，再坐下来工作
2. 如果一天要接听5小时电话，使用无线耳机
3. 复印文件时，与复印机保持至少一米
4. 只在非常必要时才使用滴眼液
5. 不趴在办公桌上午睡
6. 在办公室为自己准备小靠垫，放在腰部
7. 不要将笔记本电脑放在膝上使用
8. 在办公桌上养一盆仙人掌，帮助吸收辐射
9. 阅读完报纸后，记得清洗掉沾在手上的油墨
10. 每30分钟伸一次懒腰
11. 办公室地毯定期清洗杀虫
12. 用完电脑后要清洁面部及手部，清除辐射微尘
13. 单肩的短带挎包会加重肩周炎症状
14. 公文包里的口红与签字笔分格存放
15. 每天保证有2小时以上的时间，让脚从高跟鞋时解放出来
16. 每周晚过22：00的加班不超过一次

绿色题板
1. 浴室保持干燥，防止霉菌滋生
2. 沐浴不超过10分钟
3. 用温水刷牙，同时刷刷舌头
4. 用冷热水交替洗脸
5. 不用塑料器皿盛装热水
6. 定期清理冰箱
7. 微波炉在工作时，请离开厨房
8. 使用抽油烟机
9. 晚餐时关掉电视机
10. 尽量避免使用厚绒布窗帘
11. 杀虫剂和清洁剂要放在远离起居场所的储物间
12. 用天然的花香或果香代替芳香剂
13. 冬天居室里的加湿器使用纯净水
14. 不要贪图方便将电脑带进卧室
15. 不要把手机放在枕边充当闹钟
16. 头发没干时，别急着入睡
17. 卧室的房间要用柔和色彩

黄色题板
1. 在牛奶和豆浆之间，选择后者
2. 觉得还可以再吃半碗饭时，离开餐桌
3. 如果身体不感到饥渴，每天只需饮用4杯水
4. 多喝酸奶
5. 无论什么原因，都别抽烟
6. 在食谱里添加杂粮和蔬菜
7. 饮绿茶胜过红茶
8. 重视早餐多过晚餐
9. 控制盐的用量
10. 起床后先刷牙，再喝水
11. 经常嚼口香糖
12. 一早一晚，两个苹果可以有效改善便秘
13. 纯素食可能导致荷尔蒙分泌异常，造成不孕
14. 每周至少吃一次鱼
15. 远离可乐等碳酸饮料
16. 不喝久煮的火锅汤
17. 没有果汁牛奶这回事，它们是天生的冤家
18. 饭前吃水果胜过饭后
19. 睡前可以来一杯红葡萄酒
20. 喝咖啡可能引起女性骨质疏松

橙色题板
1. 多享受早晨8－9点的阳光
2. 跑步、骑脚踏车等运动可以保持优美的腿部线条
3. 热水泡脚可有效预防静脉曲张
4. 精神极度疲倦时并不适宜以运动减压，休息更重要
5. 冬季少做户外运动
6. 10层以下，不乘坐电梯
7. 每三个月改变一次你的健身菜单
8. 每天运动半小时，而非周末运动3小时
9. 边看电视边做柔软体操
10. 经常散步
11. 午休也是健身的好时间，不一定非等到晚上
12. 光脚穿运动鞋固然舒服，却对健康不利
13. 睡半硬的床铺更有利于颈椎健康
14. 去正规的医院而非美容院接受按摩
15. 非运动状态下不喝功能性饮料
16. 运动后休息半小时再入浴
17. 不在过吵的健身房中锻炼
18. 正确的姿势比专程去健身更有效 （来源）

Web网站测试技术要领集合

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

　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于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应用系统的转变。

　　网站测试流程、要求及测试报告

　　一个网站基本完工后，需要通过下面三步测试才可以交活。

　　一、 制作者测试，包括美工测试页面、程序员测试功能。在做完后第一时间内有制作者本人进行测试。

　　a) 页面 包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;图片上有没有错别字;各连接是否是死连接;各栏目图片与内容是否对应等

　　b) 功能 达到客户要求;数据库连接正确;各个动态生成连接正确;传递参数格式、内容正确;试填测试内容没有报错;页面显示正确

　　二、 全面测试 根据交工标准和客户要求，由专人进行全面测试

　　也是包括页面和程序两方面，而且要结合起来测，保证填充足够的内容后不会导致页面变形。另外要检查是否有错别字，文字内容是否有常识错误。

　　三、 发布测试 网站发布到主服务器之后的测试，主要是防止环境不同导致的错误

软件缺陷的原则

　　软件缺陷区别于软件bug，它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等；
　　软件未达到产品说明书标明的功能；
　　软件出现了产品说明书指明不会出现的错误；
　　软件功能超出产品说明书指明范围；
　　软件未达到产品说明书虽未指出但应达到的目标；
　　<a href="http://www.51testing.com/" target="_blank">软件测试</a>员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

　　测试的主要方面：

　　一、功能测试

　　对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》，对于应用程序模块需要设计者提供基本路径测试法的测试用例。

　　1、链接测试

　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面：

　　1)测试所有链接是否按指示的那样确实链接到了该链接的页面;

　　2)测试所链接的页面是否存在;

　　3)保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

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

　　Xenu------主要测试链接的正确性的工具

　　可惜的是对于动态生成的页面的测试会出现一些错误。

　　2、表单测试

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

　　要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

　　B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。

　　我们对UM子系统中各个功能模块中的各项功能进行逐一的测试，主要测试方法为：边界值测试、等价类测试，以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入，以确保测试输入的全面性。

　　3、Cookies测试

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

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

　　4、设计语言测试

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

　　5、数据库测试

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

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

二、性能测试

　　网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做的不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。

　　网站的性能测试主要从三个方面进行：连接速度测试、负荷测试(Load)和压力测试(Stress),

　　连接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃。

　　1、连接速度测试

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

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

2、负载测试

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

　　3、压力测试

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

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

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

　　采用的测试工具：

　　性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具

　　ab -----Apache 的测试工具

　　OpenSTA—开发系统测试架构

三、接口测试

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

　　验证数据或提交订单。

　　1、 服务器接口

　　第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器

　　记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

　　2、 外部接口

查看(366) 评论(0) 收藏 分享 管理

对于一些业务比较复杂的中型以上项目来说，准备正确、真实的测试数据对于成功的测试项目是至关重要的。很庆幸在网站上看到了一些关于这方面的帖子总结的都非常好。这里综合了一下，以备日后的参考！

不管是自动测试还是手动测试，都会涉及到基础数据的准备问题。通常情况下，可以根据系统实际情况，按照如下顺序来准备数据：

　　1. Production Data 生产数据

　　如果系统前一版本已经发布，我们能够拿到这些生产数据来测试，那是最为理想的，最能反映最终用户环境，是需要优先考虑的。

　　2. Legacy System Data 遗留系统数据

　　虽然当前系统还没有发布任何版本，但是有一个遗留系统，那就应该利用数据迁移，尽量拿到遗留系统相对比较真实的数据，这样的数据跟最终用户环境也比较接近，也是比较理想的。

　　3. UI Input UI输入创建数据

　　如果既没有发布任何版本，也没有遗留系统，那么就要考虑从UI上输入相关数据，这种数据跟真实数据比较接近，较为可信赖。

　　4. Script. create 用脚本创建数据

　　最后，对于不符合一二两种情况，而且没有UI，或者需要的数据量太大，没法一条一条的通过UI输入创建。这时候，就要考虑用脚本来产生，尽量模拟用户的真实数据。

　　总之，测试过程中数据的真实性很重要，有些缺陷并不是程序本身的问题，而是一些脏数据引起的，因此我们在进行测试数据准备的时候，要按照上述优先顺序来准备数据。

在软件测试过程中，测试数据的准备是一个工作量很大而且也是一个技术活。因此如何准备大量的测试数据，而且如何准备高质量的测试数据，满足测试的需求，就是一个重要的话题。
        首先看数据的来源，数据的来源一般来讲有三个个，一个是根据被测系统需求的分析，针对正常业务，异常情况，边界情况等来构建完整的数据，又称为“造”数据。这不仅仅包括最基本的基础数据，比如：用户、权限、配置、基础编码、原数据等，还包括上面提到的业务数据。这对于比较小型的系统来说还是可行的，对于大型的系统来说可能就是一个巨大的工程了。
        第二种方式就是利用现有系统，这适合已有类似系统，测试是针对升级或者增加功能的产品化的系统。这种情况把已经在生产环境中运行的数据导出。在此基础上再进行数据的整理、加工为测试数据。
        还有一种方式就是将现有非电子化的业务数据录入到系统中，在验证业务的同时也完成了测试数据的积累。即边测试边积累数据。但是这种情况积累的数据往往有一定局限性，因为已经发生的业务数据基本是正确的、一致的，而且可能缺少某些特定业务的数据（不常发生的业务）。这样就需要根据对测试需求的分析，追加新的测试数据，以便能完整覆盖业务类型。
        确定好数据来源后，还需要对已有数据进行分析、验证、检查，保证数据的质量，数据的质量一般要满足测试需求、覆盖被测业务、覆盖测试边界，以及要满足完整性、一致性等要求。检查完后要整理和完善数据，清除无用和冗余的数据、补录不完整的数据，修改一些错误的数据。
        经过整理好的数据要纳入配置管理，以后根据需求和变更要进行数据的维护和更新，以保证满足系统测试的要求。

　　首先，我们可以有两条路发展，技术和管理。管理就是做team lead， manager， director这么走。因为我没有走这条路，所以，我这里也只谈技术。而且，即使走管理，也是应该具备很强的技术能力才行，所以技术是我们的发展之本。我个人不喜欢技术不精通的领导，也不喜欢被这种人管理。

　　技术的发展是分阶段的，基本上你要是能发展到最后的阶段，工作，钱，房子，车子，老婆都不用发愁了。当然要一步一步走，不可能一步升天，而且一路走过来也不是很容易，应该说大部分人可能都达不到。不过只要你肯努力，坚持不懈，就一定能达到。

　　第一阶段：就是基本功的问题。这个阶段从大学入学就开始了，我接触不少人工作几年都没有达到要求。这个要求是一定要达到的，不然以后没法往高发展。大学的一些课程一定要学好，主要是数据结构，算法，数据库，操作系统，计算机网络。争取精通两门。数据结构，算法对软件开发非常的重要，很多大公司面试就考这些。你不过关，根本通过不了面试，一两道算法题一下就把你难住了。另外，我可以告诉你，顶尖公司的面试80%都是考算法，你有没有经验不要紧，做没做过项目不要紧。关键是考察你的基本功，基本功打好了，其他工作就都容易很多了，基本功打不好，什么都白说。操作系统，争取要精通windows或者linux内核，看你走哪条路了，我是搞windows的，不过他们之间很多地方也是相通的。计算机网络，争取精通TCP/IP协议。数据库我不怎么懂，我的理解是要精通oracle， sqlserver， 还有sql编程。

　　另外就是编程技术了。C，C++，面向对象一定要搞懂，搞熟。大公司面试的算法就是要你用C/C++实现的。这些搞熟了，学习其他语言就是几个小时的事情。（我指的是上手，不是精通）。这些东西搞不透，不管你其他语言用多少年，回来学他们还是难。

　　再有就是英语水平了，听说读写，各个方面都要达到要求。技术到了一定程度，英语对你的发展就起到了非常决定性的作用了。你英语好，就可以去外企，就可以外派出国，甚至国外发展。

　　以上这些都是在大学应该掌握好的。当然了，能在大学掌握好这些的毕竟是少数。这些少数人就是去了微软，google的那些，一毕业就拿到月薪上万工资的。大部分人都是达不到要求的，这没关系，毕业后一定要找时间把这些基本功补上。不然的话，在下个阶段的发展就很受限制了。

　　第二阶段：计算机知识的扩展，行业知识的精通。这个阶段从你大学毕业走向第一个工作岗位开始。工作之后，发现计算机的世界比大学的知识要博大精深很多。一开始工作，就要拼命吸收以前没有接触过的，新的知识。这个就不多说了，大家都会有很多感受的，会觉得很多东西都不会，不会就学。以后你跳槽去面试，人家就会看你工作几年，这几年干什么了。工作1，2年之后，很重要的一件事情就是要选择一个行业了。也许是你现在正在从事的行业，也许是一个新的行业。总之，你自己要为自己规划，选择一个适合自己，而且又热门，以后有发展的行业。无论是现在的行业，还是跳槽到一个新的行业，都需要你开始积累在这个行业的经验了，要精通这个行业。有这个基础之后，就要去这个行业里top的公司了，国企，外企都可以，一定要有名气，大公司。比如，通信的华为，搜索的百度，等等。如果你精通了这个行业，去这些公司不是很难。

　　另外有一点很重要，如果你本科不是一所名校毕业的话，争取能上一个名校的研究生，全职，兼职都可以。这样可以为下一阶段做好充分的准备，否则的话会有比较大的困难。总之了，是自己的短处都要想办法去弥补，不然发展总会受限制。

　　第三阶段：国际著名大公司。有了前两个阶段的积累，加上自己的英文水平，就要找机会进入国际的大公司了。相信这个时候就会有很多猎头来联系你了。选择你这个行业的世界前3，最好是第一或者第二。进去之后要学习两个方面，一是英文，中国人可以学一辈子英文的。另外一个就是大公司的管理。可以这样说，国际大公司的管理有很多类似的地方，因此他们的招聘非常愿意招其他国际大公司的职员。这就是为什么，你一旦踏上一家公司，一辈子都不用愁工作了，可以在这些大公司跳来跳去，工资节节高。到了这个阶段，你基本上可以有个比较不错的生活了，房子，车子都不会是太大的问题。

　　第四阶段：向国际化发展。如果你还不满足，觉得自己还有能力更进一步，那我就建议你向国际化发展了。中国的工资毕竟有限，到了第三阶段也不过就是20万左右，你可能还不满足。那么你就可以联系国外的公司了，有了你的英文，你的经验，你的背景，到时候就是水到渠成了。我相信国际的猎头也会盯上你的。

　　最后说一下，如果你现在已经具备了我所说的各个阶段的能力，那么你的简历是任何公司都很难拒绝的了。因为目前的情况，具有这些素质的测试人员在世界都紧缺。很多公司都招不到人，即使连google，MS也不列外。他们都在到处寻找这种人。

　　最后说一下测试。我一直没有讨论测试的问题，因为我一直没有把测试当作一个难得东西来看待。我认为测试是表面上的，我前边提到的东西要比它重要的多。欢迎大家一起来讨论。我也是进入测试才2年多的时候，其中大多数的时间也像大家一样的迷惘，很多时候也很悲观。不过通过自己的努力，最后终于得到了一个满意的结果。我发现自己对测试这个行业的理解和很多人都不同，希望我的理解能给大家一点帮助。

　　那我说一下各阶段掌握的知识吧：

• 大学主要是C，C++，VC。
• 工作第一年就是VC编程，TCP/IP编程。
• 后来的半年主要是C编程。
• 研究生搞了很多，不过都不算精通，Java，Linux，并行计算，分布式计算。
• 做测试以后搞了.net， C#， 开发自动化测试系统。
• 另外，英文水平可以和外国人直接沟通。

β测试_Beta测试

　　β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。

　　β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

　　当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

　　α测试_Alpha测试

　　α测试，英文是Alpha testing。又称Alpha测试.

　　Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。

　　在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。

　　可移植性测试

　　可移植性测试，英文是Portability testing。又称兼容性测试。

　　可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。

　　用户界面测试-UI测试

　　用户界面测试，英文是User interface testing。又称UI测试。

　　用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。

　　用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

　　用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。

　　冒烟测试

　　冒烟测试，英文是Smoke testing。

　　冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。

　　冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

　　随机测试

　　随机测试，英文是Ad hoc testing。

　　随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

　　随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试 (Regressive testing)一起进行。

　　本地化测试

　　本地化测试，英文是Localization testing。

　　本地化就是将软件版本语言进行更改，比如将英文的windows改成中文的windows就是本地化。本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试，安装/卸载测试，当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量，包含软件、文档和联机帮助等部分。

　　本地化能力测试

　　本地化能力测试，英文是Localizability testing。

　　本地化能力测试是指不需要重新设计或修改代码，将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本，提高测试效率，本地化能力侧是通常在软件的伪本地化版本上进行。

　　本地化能力测试中发现的典型错误包括：字符的硬编码（即软件中需要本地化的字符写在了代码内部），对需要本地化的字符长度设置了国定值，在软件运行时以控件位置定位，图标和位图中包含了需要本地化的文本，软件的用户界面与文档术语不一致等。

　　国际化测试

　　国际化测试，英文是International testing。又称国际化支持测试。

　　国际化测试的目的是测试软件的国际化支持能力，发现软件的国际化的潜在问题，保证软件在世界不同区域都能正常运行。国际化测试使用每种可能的国际输入类型，针对任何区域性或区域设置检查产品的功能是否正常，软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语（可选）的混合字符。

　　国际化支持测试是指验证软件程序在不同国家或区域的平台上也能够如预期的那样运行，而且还可以按照原设计尊重和支持使用当地常用的日期，字体，文字表示，特殊格式等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串?又比如，日文版的Microsoft Excel对话框是否显示正确翻译的日语?一旦来说执行国际化支持测试的测试人员往往需要基本上了解这些国家或地区的语言要求和期望行为是什么。

　　安装测试

　　安装测试，英文是Installing testing。

　　安装测试是确保软件在正常情况和异常情况下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装的测试。异常情况包括磁盘空间不足、缺少目录创建权限等场景。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。

　　白盒测试-结构测试-逻辑驱动测试

　　白盒测试，英文是White Box Testing。又称结构测试或者逻辑驱动测试。

　　白盒测试是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。

　　白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

　　白盒测试是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

　　白盒测试常用工具有：Jtest、VcSmith、Jcontract、C++ Test、CodeWizard、logiscope。

　　黑盒测试-功能测试-数据驱动测试

　　黑盒测试，英文是Black Box Testing。又称功能测试或者数据驱动测试。

　　黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。

　　软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。

　　黑盒测试常用工具有：AutoRunner、winrunner、loadrunner。

　　自动化测试

　　自动化测试，英文是Automated Testing。

　　使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试和功能测试中用得较多。通过录制测试脚本，然后执行这个测试脚本来实现测试过程的自动化。国内领先的自动化测试服务提供商是泽众软件。自动化测试工具有AutoRunner和TAR等。

　　回归测试

　　回归测试，英文是Regression testing。

　　回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。

　　根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围时是比较困难的，特别当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码，因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。因此应当鼓励对所有回归测试用例进行自动化测试。

　　验收测试

　　验收测试，英文是Acceptance testing。

　　验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

　　验收测试一般有三种策略：正式验收、非正式验收活Alpha 测试、Beta 测试。

　　动态测试

　　动态测试，英文是Moment Testing。

　　动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。

　　根据动态测试在软件开发过程中所处的阶段和作用，动态测试可分为如下几个步骤：

　　1、单元测试

　　2、集成测试

　　3、系统测试

　　4、验收测试

　　5、回归测试

　　探索测试

　　探索测试，英文是Exploratory Testing。

　　探索测试是指通常用于没有产品说明书的测试，这需要把软件当作产品说明书来看待，分步骤逐项探索软件特性，记录软件执行情况，详细描述功能，综合利用静态和动态技术来进行测试。探索测试人员只靠智能、洞察力和经验来对bug的位置进行判断,所以探索测试又被称为自由形式测试。

　　单元测试

　　单元测试，英文是Unit Testing。

　　单元测试是最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易做好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。

　　集成测试

　　集成测试，英文是Integration Testing。

　　集成测试是指一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前，单元测试需要完成。

　　集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。

　　集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元，并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别

　　系统测试

　　系统测试，英文是System Testing。

　　系统测试是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。

　　系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。

　　端到端测试

　　端到端测试，英文是End to End Testing。

　　端到端测试类似于系统测试，测试级的“宏大”的端点，涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用网络通讯，或与外部硬件、应用系统或适当的系统对话。端到端架构测试包含所有访问点的功能测试及性能测试。端到端架构测试实质上是一种"灰盒"测试，一种集合了白盒测试和黑盒测试的优点的测试方法。

　　健全测试

　　健全测试，英文是Sanity testing。

　　健全测试是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。

　　衰竭测试

　　衰竭测试，英文是Failure Testing。

　　衰竭测试是指软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

　　接受测试

　　接受测试，英文是Accept Testing。

　　接受测试是基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。一般从功能、用户界面、性能、业务关联性进行测试。

　　负载测试

　　负载测试，英文是Load testing。

　　负载测试是测试一个应用在重负荷下的表现。例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。

　　负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

　　强迫测试

　　强迫测试，英文是Force Testing。

　　强迫测试是在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。

　　压力测试

　　压力测试，英文是Stress Testing。和负载测试差不多。

　　压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。

　　性能测试

　　性能测试，英文是Performance Testing。

　　性能测试是在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。性能测试一般包括负载测试和压力测试。

　　通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会流失(memory leak)。比如，验证程序保存一个巨大的文件新版本不比旧版本慢。

　　可用性测试

　　可用性测试，英文是Practical Usability Testing。

　　可用性测试是对“用户友好性”的测试。显然这是主观的，且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

　　卸载测试

　　卸载测试，英文是Uninstall Testing。

　　卸载测试是对软件的全部、部分或升级卸载处理过程的测试。主要是测试软件能否卸载，卸载是否干净，对系统有无更改，在系统中的残留与后来的生成文件如何处理等。还有原来更改的系统值是否修改回去

　　恢复测试

　　恢复测试，英文是Recovery testing。

　　恢复测试是测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。恢复测试指通过人为的让软件（或者硬件）出现故障来检测系统是否能正确的恢复，通常关注恢复所需的时间以及恢复的程度。

　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

　　安全测试

　　安全测试，英文是Security Testing。

　　安全测试是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如：

　　①想方设法截取或破译口令；

　　②专门定做软件破坏系统的保护机制；

　　③故意导致系统失败，企图趁恢复之机非法进入；

　　④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

　　兼容性测试

　　兼容测试，英文是Compatibility Testing。

　　兼容测试是测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。向上兼容向下兼容，软件兼容硬件兼容。软件的兼容性有很多需要考虑的地方。

　　比较测试

　　比较测试，英文是Compare Testing。

　　比较测试是指与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。来取长补短，以增强产品的竞争力。

　　可接受性测试

　　可接受性测试，英文是Acceptability Testing。

　　可接受性测试是在把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求。比如不会很容易程序就挂起或崩溃。如果一个新版本没通过可测试性的验证，就应该阻拦测试部门花时间在该测试版本上测试。同时还要找到造成该版本不稳定的主要缺陷并督促尽快加以修正

　　边界条件测试

　　边界条件测试，英文是Boudary Testing。又称边界值测试。

　　一种黑盒测试方法，适度等价类分析方法的一种补充,由长期的测试工作经验得知，大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。

　　边界条件测试是环绕边界值的测试。通常意味着测试软件各功能是否能正确处理最大值，最小值或者所设计软件能够处理的最长的字符串等等。

　　强力测试

　　强力测试，英文是Mightiness Testing。

　　强力测试通常验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。或者说是验证软件的性能在各种极端环境和系统条件下的承受能力。比如，在最低的硬盘驱动器空间或系统记忆容量条件下，验证程序重复执行打开和保存一个巨大的文件1000次后也不会崩溃或死机。

　　装配/安装/配置测试

　　装配/安装/配置测试是验证软件程序在不同厂家的硬件上，所支持的不同语言的新旧版本平台上，和不同方式安装的软件都能够如预期的那样正确运行。比如，把英文版的 Microsoft Office 2003安装在韩文版 的Windows Me 上，再验证所有功能都正常运行。

　　静态测试

　　静态测试，英文是Static Testing。

　　静态测试指测试不运行的部分，例如测试产品说明书，对此进行检查和审阅.。静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

　　静态测试常用工具有：Logiscope、PRQA；

　　隐藏数据测试

　　隐藏数据测试在软件验收和确认阶段是十分必要和重要的一部分。程序的质量不仅仅通过用户界面的可视化数据来验证，而且必须包括遍历系统的所有数据。

　　假设一个应用程序要求用户两条信息-----用户名和密码来创建帐户。这个用户输入这两条数据后保存。最后，一个确认窗口将通过数据库中找到这条数据来显示用户名和密码给用户。为了验证所有的数据保存是否正确，一个QA测试人员会在这个确认窗口简单的查看下用户名和密码。如果他们成功了？假设数据库记录了第三条信息----创建日期，它可能不会出现在确认窗口，而只在存档中才出现。如果创建日期保留的不正确，而QA测试人员只验证屏幕上的数据，那么这个问题就不可能被发现。创建日期可能就是一个bug，由于一个用户帐户保存了一个错误的日期到数据库中，这个问题也不可能会被引起注意，因为它被用户界面所隐藏。这只是一个简单的例子，但是它却演化出了一点：隐藏数据测试的重要性。

测试时间在什么阶段要评估出来？

　　个人认为：最迟在申请测试资源时要评估出来，测试资源包括时间、人力、工具等。

　　而测试时间体现在什么文档中以便作为测试依据呢？

　　个人认为在测试计划中需要阐明。测试计划中至少要写明，要测试什么（即范围），谁来测试（即测试中的人力资源），怎么测试（测试策略），什么时间测试（测试中的时间资源），风险评估，然后就是一些约定和术语解释避免歧义。

　　测试资源中用多少人力和时间资源是互相牵制的，都是依据这个项目或者产品按单位人需要的时间来计算的。

　　测试时间如何估算呢？

　　经验所得：开发的coding的时间和项目环境下测试的时间是1:1，前提是开发和测试的比例是3:1。

　　那麽这个时间的估算有些受到开发估算coding时间的牵制，那麽最好再结合：项目需要测试的范围来评估，根据测试范围大概会有多少用例产出，以及有多少牵扯到的用例需要回归，测试的平均执行效率来大概估算测试时间。

　　在上面大的估算时间上，个人认为还要综合以下几点来保证测试时间比较靠谱：

　　1、测试中由于需求与代码实现差异而产生的用例维护时间，以及和开发沟通，和需求方确认的时间。

　　2、测试环境的稳定性，有时候测试环境宕掉，影响测试进度。

　　3、开发人员的编码质量

　　4、开发人员修复bug的速率

　　5、开发人员中新人的比例，一般新人对业务不熟悉，编码考虑会欠周到。

　　6、测试人员对执行测试用例的效率

　　7、测试用例的复杂度，可能一个case里面有很多的step。

　　8、测试数据对项目的影响，如果项目本身测试过程中对数据的依赖很大，而数据的重用性不好

　　9、测试中因为bug和开发人员的沟通时间，以及不断帮助开发人员重现bug的时间。

　　10、项目中如果需要UI和UED等其他部门资源的支持，这些资源的配合沟通时间。

职场树

发现一张图，当时还没看懂什么意思，结果发现第二张带备注的版本，最上面那个叫经理，下面的就不说了，大家自己去思考吧。

注：
manager:经理
executives：主管
departments:部门
the rest:其余者

1.技术类
基础：
（1）精通测试理论知识
（2）精通1，2种测试类型及工具（性能测试，自动化测试，安全类测试）（Loadrunner+Jmeter；WVS+APPSCAN+其他工具）
中级：
（3）熟练掌握2，3种编程语言（C#+VBS+php）
（4）熟练掌握数据库知识（MSSQL+MYSQL）
（5）熟练掌握windows和Linux（能搭建各类测试环境）（testlink+bugzilla+WordPress+公司产品）
（6）熟练掌握应用服务器及中间件知识（IIS,Apache）
高级：
（7）熟悉各个平台下的系统架构及本公司的产品技术架构（petshop+PHP架构）
（8）熟悉各类算法，数据结构等
（9）独立建立完善的自动化测试架构（QC+QTP+Loadrunner）
2.管理类
基础：
（1）精通测试理论知识
（2）项目管理知识
中级：
（3）熟练掌握质量管理，流程管理和控制，配置管理的知识
（4）熟悉掌握各种测试类型
（5）非常熟悉公司的产品及产品的发展策略
高级：
（6）职业经理人

好久没来自己的空间了，今天进来后，心中不免有种久违了的感觉。不禁打扮了一下自己的小窝，同时希望自己在今年也有新貌新气象！为自己加油一下！