测试之道、

发布新日志

  • 软件测试管理和测试流程

    2008-09-16 11:07:18

    软件测试管理和测试流程

    软件测试管理
    正确的方式对公司的测试工作进行管理。而“正确的方式”就是在工作中不断摸索和改进后的管理方式,探索并发现这些方式也是测试管理工作的重要任务之一。
    软件测试管理还要评估风险、规划资源、不断地提高团队能力,最终形成一个高效的团队来完成对质量的管理。
    测试管理的目标是在进度、成本、质量三者之间做出平衡,使产品能够符合客户需求。
    软件测试流程
    第一步:对要执行测试的产品/项目进行分析,确定测试策略,制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策略和指导方针,这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚,才能决定测试资源的投入。
    第二步:设计测试用例。设计测试用例要根据测试需求和测试策略来进行,进度压力不大时,应该设计的详细,如果进度、成本压力较大,则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。
    第三步:如果满足“启动准则”(EntryCriteria),那么执行测试。执行测试主要是搭建测试环境,执行测试用例。执行测试时要进行进度控制、项目协调等工作。
    第四步:提交缺陷。这里要进行缺陷审核和验证等工作。
    第五步:消除软件缺陷。通常情况下,开发经理需要审核缺陷,并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后,进入到回归测试阶段。如果满足“完成准则”(ExitCriteria),那么正常结束测试。
    第六步:撰写测试报告。对测试进行分析,总结本次的经验教训,在下一次的工作中改。

  • Bug管理流程

    2008-09-16 11:02:21

    软件测试的重要环节:Bug管理流程


    软件测试的主要目的在于发现软件存在的错误(Bug),对于如何处理测试中发现的错误,

    将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误,才能消除软件错误,保证
    要发布的软件符合需求设计的目标。在实际软件测试过程中,对于每个Bug都要经过测试、确
    认、修复、验证等的管理过程,这是软件测试的重要环节。
    错误跟踪管理系统
    为了正确跟踪每个软件错误的处理过程,通常将软件测试发现的每个错误作为一条条记录
    输入制定的错误跟踪管理系统。
    目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件(商业软件)、
    Mozilla公司的Buzilla软件(免费软件),以及国内的微创公司的BMS软件,这些软件在功能
    上各有特点,可以根据实际情况选用。当然,也可以自己开发缺陷跟踪软件,例如基于Notes
    或是ClearQuese开发缺陷跟踪管理软件。
    作为一个缺陷跟踪管理系统,需要正确设计每个错误的包含信息的字段内容和记录错误的
    处理信息的全部内容。字段内容可能包括测试软件名称,测试版本号,测试人名称,测试事
    件,测试软件和硬件配置环境,发现软件错误的类型,错误的严重等级,详细步骤,必要的附
    图,测试注释。处理信息包括处理者姓名,处理时间,处理步骤,错误记录的当前状态。
    正确的数据库权限管理是错误跟踪管理系统的重要考虑要素,一般要保证对于添加的错误
    不能从数据库中删除。
    软件错误的状态
    新信息(New):测试中新报告的软件缺陷
    打开 (Open):被确认并分配给相关开发人员处理;
    修正(Fixed):开发人员已完成修正,等待测试人员验证;
    拒绝(Declined):拒绝修改缺陷;
    延期(Deferred): 不在当前版本修复的错误,下一版修复
    关闭(Closed):错误已被修复;
    Bug管理的一般流程
      测试人员提交新的Bug入库,错误状态为New。
      高级测试人员验证错误,如果确认是错误,分配给相应的开发人员,设置状态为Open。如
    果不是错误,则拒绝,设置为Declined状态。
    开发人员查询状态为Open的Bug,如果不是错误,则置状态为Declined;如果是Bug则修复
    并置状态为Fixed。不能解决的Bug,要留下文字说明及保持Bug为Open状态。
    对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过某种会议(评审
    会)通过才能认可。
    测试人员查询状态为Fixed的Bug,然后验证Bug是否已解决,如解决置Bug的状态为
    Closed,如没有解决置状态为Reopen。
    软件错误流程管理要点
    为了保证错误的正确性,需要有丰富测试经验的测试人员验证发现的错误是否是真正的错
    误,书写的测试步骤是否准确,可以重复。
    每次对错误的处理都要保留处理信息,包括处理姓名,时间,处理方法,处理意见,Bug
    状态。
    拒绝或延期错误不能由程序员单方面决定,应该由项目经理,测试经理和设计经理共同决
    定。
    错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭错误。
    加强测试人员与程序员的交流,对于某些不能重复的错误,可以请测试人员补充详细的测
    试步骤和方法,以及必要的测试用例。  
  • 测试设计中需要考虑的22种测试类型

    2008-09-16 10:28:18

       测试设计中需要考虑的22种测试类型


         黑盒测试:不基于内部设计和代码的任何知识,而是基于需求和功能性。

       白盒测试:基于一个应用代码的内部逻辑知识,测试是基于覆盖全部代码、分支、路径、条件。

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

       累积综合测试:当一个新功能增加后,对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作,或当需要时那些测试驱动器已被开发出来; 这种测试可由程序员或测试员来做。

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

       功能测试:用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做,这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。

       系统测试:基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件。

       端到端测试:类似于系统测试;测试级的“宏大”的端点;涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。

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

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

       接受测试:基于客户或最终用户的规格书的最终测试,或基于用户一段时间的使用后,看软件是否满足客户要求。

       负载测试:测试一个应用在重负荷下的表现,例如测试一个 Web 站点在大量的负荷下,何时系统的响应会退化或失败。

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

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

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

       安装/卸载测试:对软件的全部、部分或升级安装/卸载处理过程的测试。

       恢复测试:测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。

        安全测试:测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。

       兼容测试:测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。

       比较测试:与竞争伙伴的产品的比较测试,如软件的弱点、优点或实力。

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

       Beta 测试:当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成
  • 软件测试之系统测试设计的层次分析

    2008-09-16 10:24:04

       软件测试之系统测试设计的层次分析


       随着国内软件行业的不断发展,国内软件公司也越来越注重于软件的质量,越来越关注软件的可靠性,因此,做为质量保证的重要手段,软件测试过程的实施与管理成为一个热点,其中系统测试是整个测试活动的一个重要的阶段,系统测试的设计也就成为了关注点之一。以下是本人从事系统测试工作中的一些体会。

      1、系统测试的定义:

      系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不相符合或与之矛盾的地方。

      2、系统测试的对象:

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

      3、系统测试的设计

      系统测试过程包含了测试计划、测试设计、测试实施、测试执行、测试评估这几个阶段,而整个测试过程中的测试依据主要是产品系统的需求规格说明书、各种规范、标准和协议等。在整个测试过程中,首先需要对需求规格进行充分的分析,分解出各种类型的需求(功能性需求、性能要求、其他需求等),在此基础之上才可以开始测试设计工作,而测试设计又是整个测试过程中非常重要的一个环节,测试设计的输出结果是测试执行活动依赖的执行标准,测试设计的充分性决定了整个系统过程的测试质量。因此,为了保证系统测试质量,必须在测试设计阶段就对系统进行严密的测试设计。这就需要我们在测试设计中,从多方面来综合考虑系统规格的实现情况。通常需要从以下几个层次来进行设计:用户层、应用层、功能层、子系统层、协议层

      3.1、用户层:

      主要是面向产品最终的使用操作者的测试。这里重点突出的是在操作者角度上,测试系统对用户支持的情况,用户界面的规范性、友好性、可操作性,以及数据的安全性。主要包括:

    3.1.1、用户支持测试

      用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。

      3.1.2、用户界面测试

      在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下,测试用户界面的风格是否满足用户要求,例如:界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。

      3.1.3、可维护性测试

      可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来的影响。例如:对支持远程维护系统的功能或工具的测试。

      3.1.4、安全性测试

      这里的安全性主要包括了两部分:数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问系统,其他不符合规格的数据不能够访问系统;核实只有规格规定的操作权限才可以访问系统,其他不符合规格的操作权限不能够访问系统;

      3.2、应用层:

      针对产品工程应用或行业应用的测试。重点站在系统应用的角度,模拟实际应用环境,对系统的兼容性、可靠性、性能等进行的测试。

      3.2.1、系统性能测试

      针对整个系统的测试,包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程;强度测试是在资源情况低的情况下,找出因资源不足或资源争用而导致的错误;破坏性测试重点关注超出系统正常负荷N倍情况下,错误出现状态和出现比率以及错误的恢复能力。

      3.2.2、系统可靠性、稳定性测试

      一定负荷的长期使用环境下,系统可靠性、稳定性。

      3.2.3、系统兼容性测试

      系统中软件与各种硬件设备兼容性,与操作系统兼容性、与支撑软件的兼容性。

      3.2.4、系统组网测试

      组网环境下,系统软件对接入设备的支持情况。包括功能实现及群集性能。

      3.2.5、系统安装升级测试

      安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如,正常情况下,第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。还有一个目的是核实软件在安装后可立即正常运行。另外对安装手册、安装脚本等也需要关注。

      3.3、功能层

      针对产品具体功能实现的测试。

      3.3.1、业务功能的覆盖

      关注需求规格定义的功能系统是否都已实现。

      3.3.2、业务功能的分解

      通过对系统进行黑盒分析,分解测试项及每个测试项关注的测试类型。

      3.3.3、业务功能的组合

      主要关注相关联的功能项的组合功能的实现情况。

      3.3.4、业务功能的冲突

      业务功能间存在的功能冲突情况。比如:共享资源访问等。

      3.4、子系统层

      针对产品内部结构性能的测试。关注子系统内部的性能,模块间接口的瓶颈。

      3.4.1、单个子系统的性能

      应用层关注的是整个系统各种软、硬件、接口配合情况下的整体性能,这里关注单个系统。

      3.4.2、子系统间的接口瓶颈

    例如:子系统间通讯请求包的并发瓶颈。

      3.4.3、子系统间的相互影响

      子系统的工作状态变化对其他子系统的影响。

      3.5、协议/指标层

      针对系统支持的协议、指标的测试。

      3.5.1、协议一致性测试

      3.5.2、协议互通测试

  • 软件度量中应避免的十个陷阱

    2008-09-16 10:22:05

    软件度量中应避免的十个陷阱

    作者: Michael 来源: 网络转载

    看了这样一篇论文《Software Metrics: Ten Traps To Avoid》,文中说明了十个在作软件度量时应该注意的问题,而这些问题也是实际工作中大家容易掉入的陷阱。

    1.度量缺乏管理者的支持和承诺,没有管理者的支持和承诺,度量工作很难进行。

    2.度量指标太多,度量太快。这样的度量计划往往让人望而却步,很难成功。

    3.度量指标太少,度量介入太迟。度量指标太少很难说明问题,度量介入太迟很难跟踪到项目的整体实际情况。

    4.度量了错误数据,如果度量的数据不是度量目标所需要的数据,那么只能是浪费时间,白费辛苦。

    5.不准确的度量指标定义。不准确的度量指标定义会导致收集错误的数据,得到错误的结论。

    6.利用度量数据来考核员工绩效。这是一种很不明智的做法,只能使度量数据不真实。

    7.利用度量数据来激发而不是理解项目的真实情况。度量数据是用来评价理解项目的实际进展情况,为过程改进提供依据的,而不是用这些数据来激发行动的。

    8.收集无用的数据。度量中收集的数据应进行分析,为下一步行动提供依据,而不是放在数据库中的无人理会的无用数据。

    9.缺乏沟通和培训。

    10.对度量数据进行错误解释。不能从一个度量指标得出武断的结论,应从各方面度量指标综合进行分析。
  • Web 应用系统性能测试

    2008-08-31 16:08:50

       性能测试是 Web 应用系统的一项重要质量保证措施。在现实中,很多 Web 性能测试项目由于性能测试需求定义不合理或不明确,导致性能测试项目不能达到预期目标或进度超期。本文针对 Web 应用系统的技术架构和系统使用特点,探讨如何有效实施性能测试过程,并重点介绍如何分析获得合理的性能测试需求,最终对 Web 应用系统性能进行科学、准确的评估。
     

    1、 引言
    基于Web服务器的应用系统由于提供浏览器界面而无须安装,大大降低了系统部署和升级成本,得以普遍应用。目前,很多企业的核心业务系统均是Web应用,但当Web应用的数据量和访问用户量日益增加,系统不得不面临性能和可靠性方面的挑战。因此,无论是Web应用系统的开发商或最终用户,都要求在上线前对系统进行性能,科学评价系统的性能,从而降低系统上线后的性能风险。
    在很多性能测试项目中,由于不能合理定义系统的性能测试需求,不能建立和真实环境相符的负载模型,不能科学分析性能测试结果,导致性能测试项目持续时间很长或不能真正评价系统性能并提出性能改进措施。
    本文在总结许多Web应用系统性能测试实践经验和教训的基础上,从与性能测试工具无关的角度介绍Web应用系统性能测试的方法和实施过程,以及如何定义合理的性能测试需求。
     

    1.1 术语定义
    性能测试:通过模拟大量浏览器客户端同时访问Web服务器,获得系统的性能数据。
    虚拟用户:模拟浏览器向Web服务器发送请求并接收响应的一个进程或线程。
    响应时间:浏览器向Web服务器提交一个请求到收到响应之间的间隔时间。
    思考时间:浏览器在收到响应后到提交下一个请求之间的间隔时间。
    请求成功率:Web服务器正确处理的请求数量和接收到的请求数量的比。
    吞吐量:单位时间内Web服务器成功处理的HTTP页面或HTTP请求数量。
    在线用户:用户通过浏览器访问登录Web应用系统后,并不退出该应用系统。通常一个Web应用服务器的在线用户对应Web应用服务器的一个Session。
    并发用户数:Web服务器在一段时间内为处理浏览器请求而建立的HTTP连接数或生成的处理线程数。当所有在线用户发送HTTP请求的思考时间为零时,Web服务器的并发用户数等于在线用户数。

    1.2 Web应用系统技术架构
    Web应用系统的前端为浏览器,后台为Web服务器(如Apache,Microsoft Internet Information Server),浏览器和Web服务器之间的交互基于HTTP协议。HTTP协议本身是无连接的,Web服务器通过Session机制来建立一个浏览器所发出的先后连接之间的关联。通过实验证明,当浏览器客户端在首次访问Web服务器后,如果该浏览器客户端不发送后续请求,服务器维持该浏览器客户端的Session变量所消耗的系统资源非常小。

    2、 Web应用系统性能测试过程
    标准的Web应用系统性能测试过程包括确定性能测试需求,开发性能测试脚本,定义性能测试负载模型,执行性能测试和形成性能测试报告。本章将分别介绍上述过程,并通过举例说明如何完成每一环节。
     

    2.1 确定性能测试需求
    科学定义Web应用系统性能测试需求对一个成功的性能测试非常重要。通常,Web应用系统的性能测试需求有如下两种描述方法。

    2.1.1 基于在线用户的性能测试需求
    该需求描述方法主要基于Web应用系统的在线用户和响应时间来度量系统性能。当Web应用系统在上线后所支持的在线用户数以及操作习惯(包括操作和请求之间的延迟)很容易获得,如企业的内部应用系统, 通常采用基于在线用户的方式来描述性能测试需求。以提供网上购物的Web应用系统为例,基于在线用户的性能测试需求可描述为:10个在线用户按正常操作速度访问网上购物系统的下定单功能,下定单交易的成功率是100%,而且90%的下定单请求响应时间不大于8秒;当90%的请求响应时间不大于用户的最大容忍时间20秒时,系统能支持50个在线用户。

    2.1.2 基于吞吐量的性能测试需求
    该需求描述方法主要基于Web应用系统的吞吐量和响应时间来度量系统性能。当Web应用在上线后所支持的在线用户无法确定,如基于Internet的网上购物系统,可通过每天下定单的业务量直接计算其吞吐量,从而采取基于吞吐量的方式来描述性能测试需求。以网上购物系统为例,基于吞吐量的性能测试需求可描述为:网上购物系统在每分钟内需处理10笔下定单操作,交易成功率为100%,而且90%的请求响应时间不大于8秒。

    2.2 开发性能测试脚本
    在确定Web应用系统性能测试需求后,就要根据性能测试需求中确定的功能开发性能测试脚本。比如,针对前面定义的网上购物系统的性能测试需求,将开发下定单功能的性能测试脚本。
    性能测试脚本是描述单个浏览器向Web服务器发送的HTTP请求序列。每个性能测试工具(如IBM Rational Performance Tester, LoadRunner)所提供的测试脚本语法是不同的。测试人员利用性能测试工具可从头手工编写测试脚本,也可以通过录制浏览器和Web服务器之间的网络通信数据而自动形成测试脚本。
    任何性能测试工具都不能保证录制形成的性能测试脚本的正确性,测试人员应通过在单用户下运行性能测试脚本对其正确性进行验证。测试脚本不正确的一个重要原因就是脚本的数据关联不正确,也就是并没完全建立一个测试请求和前面的响应内容之间的关联。测试脚本HTTP请求和响应之间的数据关联是否正确的一个重要标准是单用户运行脚本,脚本能完成期望的功能。
    在完成性能测试脚本的数据关联后,需要对脚本进行参数化,也就是把脚本中的某些请求数据替换成变量,变量的值来于一个独立的数据文件,从而保证在多虚拟用户运行脚本的情况下,每个虚拟用户所提交的数据是不同的。
    此外,为了测试Web应用的可靠性,还需要对请求所收到的响应进行验证(比如验证响应的HTTP返回码或验证响应的内容),便于性能测试完成后统计请求成功率。

    2.3 建立性能测试负载模型
    性能测试负载模型定义了测试工具如何向Web应用系统提交请求,包括向Web应用系统发送请求的虚拟用户数,每个虚拟用户发送请求的速度和频率。针对前面介绍的网上购物系统的性能测试需求,在性能测试工具中定义的性能测试负载模型应包括如下信息:
    虚拟用户数:性能测试不仅仅是执行一次,而且每次执行时虚拟用户数也不固定,因此在性能测试负载模型中定义的虚拟用户数将在测试执行时进行设置。
    虚拟用户发送请求的思考时间和迭代次数:虚拟用户发送请求的思考时间长短是决定Web应用系统负载量的重要因素之一,而迭代次数将决定性能测试的执行持续时间。对基于在线用户的性能测试需求,将基于录制脚本时记录的思考时间,而且由于现实中不同用户访问系统的思考时间不同,可把思考时间设置为在一定范围内的随机值。对于基于吞吐量的性能测试需求,将把思考时间设置为零,此时Web应用系统的在线用户数量将等于并发用户数。同时,为了避免性能测试压力的随机性,将增加请求的迭代次数来增加测试执行持续时间,从而获得系统在稳定压力下的性能数据。
    虚拟用户启动模式:在现实中,Web应用系统的用户不太可能同时做相同的操作,因此为了让Web应用系统所承担的压力随时间均匀分布,建议虚拟用户依次启动,同时也避免大量用户同时登录造成系统阻塞。以10个虚拟用户模拟下定单为例,可设置每个虚拟用户间隔30秒启动,这样10个虚拟用户可在5分钟后完成启动,并保证10个虚拟用户不会在同一时刻下定单,从而更符合实际情况。

    2.4 执行性能测试
    执行性能测试是指通过多次运行性能测试负载模型,获得系统的性能数据。在执行过程中,需利用测试工具、操作系统、系统软件(如Web Server或DB Server)提供的资源监控手段对资源进行监控和分析,帮助发现资源瓶颈,并在系统层面进行优化。同时,还需对应用进行性能分析,帮助定位应用代码中的性能问题,切实解决系统的性能问题。

    2.5 形成性能测试报告
    性能测试项目的最后阶段就是向相关人员提交性能测试报告,汇报性能测试结果。在向相关人员汇报性能测试结果时,并不是性能测试报告越丰富、性能数据越多越好。好的性能测试报告是能准确、简单地传递性能测试结论,而不需太多的技术细节。
    针对基于在线用户数的性能测试需求,可通过下图总结性能测试结论。其中横轴是在线用户数,纵轴是响应时间,如40在线用户访问网上购物系统时,90%的下定单请求响应时间不超过10秒。
    图一:在线用户数和响应时间时间的趋势图
    针对基于吞吐量的性能测试需求,可通过下图的曲线来描述性能测试结果。以网上购物系统为例,下图描述下定单的并发用户、下定单响应时间以及吞吐量(服务器每秒处理定单笔数)之间的关系,从而快速判断系统是否能满足性能测试需求。从下图中可看出,并发用户增加,请求的响应时间也增加。服务器的吞吐量是先随并发用户数增加而增加,当吞吐量到达一定峰值后,再增加并发用户数,吞吐量会减少。原因在于当并发用户数少时,向Web服务器提交的请求量不大,服务器处理能力还有富余,所以吞吐量逐步增大;但当并发用户数超过某一值时,由于向服务器提交的请求太多,造成服务器阻塞,反而导致吞吐量减少。
    图二:响应时间、吞吐量和并发用户数的趋势图
     
     
    3 如何获取合理的性能测试需求
    前一章介绍了Web应用系统的性能测试过程,确定性能测试需求是整个性能测试的起点和成功的重要因素。性能测试需求定义得过高,虽然确保系统上线后能满足性能需求,但可能会造成硬件资源的浪费;性能测试需求定义得过低,系统上线后可能会出现性能问题。如何通过分析系统上线后可能的用户访问行为,来获得合理的性能测试需求指标呢?
    假设现有一个基于Web的办公自动化系统(简称OA系统),该系统提供公文收发和查询功能。在部署该系统前,将对该系统进行性能测试。下面将详细介绍如何分析该OA系统的使用情况,定义合理的性能测试需求。
     

    3.1 如何获得OA系统的在线用户数量
    在线用户数量是指在特定时间区间内,有多少用户访问Web应用系统(对应到Web服务器的Session数),根据系统可能访问用户数以及每个用户访问系统的时间长短来确定。
    对于将要部署的OA系统,通过分析获得该系统有8000个注册用户,基本上所有的用户每天(8小时工作时间)都会访问OA系统,平均在线时间(从登录OA系统到退出OA系统之间的时间间隔,也可以是多次在线时间的合计)为12分钟,那么该OA系统的平均在线数(也就是Web应用Session变量数)为200个(8000 * 0.2 / 8),假设峰值在线用户数是平均在线用户数的3倍(该倍数可根据实际情况调整),则性能测试需求的在线用户数为600。

    3.2 如何确定OA系统的性能测试用例
    由于时间和资源限制,不可能对Web应用系统的所有功能进行性能测试,而是从业务的角度(如某一功能操作的用户多)和技术的角度(如某一功能虽然访问用户不多,但内部处理逻辑复杂或处理数据量大)来选择Web应用系统的特定功能作为性能测试用例。
    以OA系统为例,由于所有用户都经常公文查询功能,因此确定的性能测试用例为公文查询。

    3.3 如何确定OA系统的响应时间
    响应时间的快慢直接影响了系统使用用户的满意度,采用平均响应时间来描述系统系统性能测试需求是不科学的,因为无法直接和客户的满意度挂钩。而且,在做性能测试,如果某一请求的响应时间过长或过短,将导致平均响应时间和实际情况偏离。
    以OA系统为例,定义的响应时间需求为:90%(该百分比和要求的系统用户满意度相关)的查询请求响应时间不超过8秒(该时间可根据实际情况确定)。

    3.4 如何确定OA系统的交易吞吐量
    单位时间内Web应用系统需处理多少笔特定的交易可通过统计获得。以OA系统为例,假设每个用户每天(一天按8小时计算)平均会查询公文4次,那OA应用的Web服务器平均每分钟要能处理8000 * 4 / ( 60 * 8 ) = 66.67笔查询公文交易,考虑到峰值因素,要求每分钟能处理66.7 * 3=200笔查询公文交易。

    3.5 OA系统性能测试需求描述
    通过前面的分析,能明确定义合理的性能测试需求。OA系统性能测试需求定义如下:
    基于在线用户数的性能测试需求:600个在线用户按正常操作速度访问OA系统的查询公文功能,所有查询请求的成功率是100%,而且90%的查询请求响应时间不大于8秒。
    基于吞吐量的性能测试需求:OA系统在每分钟内需处理200笔查询公文操作,交易成功率为100%,而且90%的请求响应时间不大于8秒。
     

    4 总结
    Web应用性能测试项目成功的关键不在于性能测试工具,而在于有效的性能测试分析方法和实践。只有切实掌握性能测试需求分析方法,性能测试实践经验,才能保证一个Web应用性能测试的成功。
  • windows下PHP+MYSQL+APACHE配置详细解析

    2008-08-24 17:18:16

    一、使用软件: 
         Apache_2.0.52-win32-x86-no_ssl  
         php-5.0.2-Win32
         mysql-4.0.21-win
         phpMyAdmin-2.6.0
    配置环境:
    Windows Xp sp2
    二、具体步骤

    注意事项:安装过程,任何目录和文件名都不要使用空格,

    不要使用D:\Program Files 而要使用
    D:\ProgramFiles 
    1. apache_2.0.52-win32-x86-no_ssl  
    apache
    服务器软件,我下载的是win版本,2.0系列的配置都是相似的。

    双击安装apache2.0.52,我把它安装到D:\ApacheGroup 注意,目录名不要包含空格,否则下面设置php会出错。安装结束后,apache自动运行,在浏览器里输入http://127.0.0.1是不是显示出了默认的网页,如果你不希望看到这个页面,可以到D:\ApacheGroup\Apache2\conf 目录下找到 httpd.conf 打开编辑,并查找 DocumentRoot " 2.0系列的版本中,只会找到一个 DocumentRoot " ,把引号内的路径改为你自己的路径就可以了,比如 DocumentRoot "D:/php" 现在默认的根目录就是 D:/php 注意这里用的是“/”。

    2
    、安装
    php5.0.2
    下载过来的php-5.0.2-Win32一般是个zip格式的压缩包,解压缩到D:\ApacheGroup 目录下,并使文件都在一个文件夹下,改文件夹名为php5 ,这样方便接下来的工作。现在我们看到 D:\ApacheGroup 下面已经有两个文件夹了, 一个是 apache2(安装apache2.0.52自动生成的一个文件夹另一个是 php5 ,我的方式是每一个软件一个文件夹,并且这些文件夹在同一目录下, 这样便于查找。 好了,我们现在开始配置apache 使它支持
    php5 .
    首先,找到 D:\ApacheGroup\php5 目录下的php.ini-dist 重命名为php.ini 并复制到C:\WINDOWS 目录下,

    然后,复制 D:\ApacheGroup\php5 目录下的php5ts.dll,libmysql.dll 
    C:\windows\system 
    接下去,我们开始配置 D:\ApacheGroup\Apache2\conf 下的 httpd.conf文件,打开httpd.conf (可用记事本打开
    )
    ①找到 AddDefaultCharset ISO-8859-1 将其改为 AddDefaultCharset GB2312 (让默认语言编码为简体中文)

    ②找到DirectoryIndex index.html index.html.var 在后面加入
     index.htm index.php index.php3
     --------------
    模块化安装配置
    ------------------------------------ 
    找到 #LoadModule ssl_module modules/mod_ssl.so 这行,在此行后加入一行
     
    LoadModule php5_module D:/ApacheGroup/php5/php5apache2.dll 
    其中D:/ApacheGroup/php5/ 为你php目录

    查找
    #AddEncoding x-gzip .gz .tgz 
    在下面的行中加入
    AddType application/x-httpd-php .php .phtml .php3 .php4
    即增加解析文件类型为
    php.phtml.php3.php4

    这里要做的主要有两个,一个是复制php.ini到系统盘,另一个就是配置httpd.conf使其支持php5,这里要求绝对路径中,例如D:/ApacheGroup/php5/ 中间不能出现空格,否则apache2.0.52将出错!

    好了,现在看看你的apache是不是已经支持php了呢,呵呵,成功了吧!


    3
    、安装
    mysql-4.0.21-win
    因为在win环境下配置apache所以,这里用的mysql也是win版本的。解压缩之后,安装mysql4.0.21D:/ApacheGroup/ 目录下,并使mysql完整的安装到 mysql目录下(可以在选择安装路径的更改文件夹名字),好了,装mysql没什么具体要求,主要是下一步的配置。首先启动mysql(如果已经启动自然不用再去启动了,看看任务栏有没有小绿灯就知道了)再提一下,现在我的mysql已经安装到 D:\ApacheGroup\Mysql 目录下了, 那么进入 D:\ApacheGroup\Mysql\bin 找到winmysqladmin.exe 双击,mysql自动启动运行。好了。开始配置php.ini了。进入C:\WINDOWS 打开 php.ini 找到extension_dir = "./" 改为
    extension_dir = "D:/ApacheGroup/php5/ext" 
    找到
     
    ;extension=php_mysql.dll 
    ';'去掉改为
     
    extension=php_mysql.dll 
    找到
     
    ;session.save_path = "/tmp" 
    ';'去掉 设置你保存session的目录,如
     
    session.save_path = " D:/ApacheGroup/php5/session_temp"; 
    好了,到这里已经成功了!

    4
    phpMyAdmin-2.6.0的配置

    phpMyAdmin-2.6.0.zip解压到自己定义的 查看(505) 评论(0) 收藏 分享 管理

  • QA和QC的区别

    2008-08-20 11:45:29

    QA=Quality Assurance, 质量保证
    QC=Quality Control,质量控制

    区别:

    1.QA偏重于质量管理体系的建立和维护,客户和认证机构质量体系审核工作,质量培训工作等;QC主要集中在质量检验和控制方面。
    QA的工作涉及公司的全局,各个相关职能,覆盖面比较宽广,而QC主要集中在产品质量检查方面,只是质量工作的其中一个方面。

    2.QA并不是立法机构
    立法机构应该是R&D,或工艺工程部门
    QA主要是保证生产过程受控或保证产品合格,着重于维护,
    而QC一般是实际质量控制,如检验,抽检,确认,很多公司只有质量部只包括QA的职责,把QC的工作放入生产部门
  • MySQL新增的复制特性的测试

    2008-08-19 09:18:34

        通过测试我们发现,可以使用它新增的复制特性来与备份数据库服务器保持数据同步,这样当主服务器因为某种原因处理失效时,能够使用备份机处理所有的查询。对于这样的要求,配置两台服务器并不困难。我将详细讨论整个处理过程,同时讨论一下当主服务器失效时,如何使用PHP来重定向查询。

      MySQL内部复制功能是建立在两个或两个以上服务器之间,通过设定它们之间的主-从关系来实现的。其中一个作为主服务器,其它的作为从服务器。我将详细讨论如何配置两台服务器,将一个设为主服务器,另一个设为从服务器。并且描述一下在它们之间进行切换的处理过程。我是在MySQL的3.23.23版本上进行的配置设置过程,并且也是在这个版本上进行的测试。MySQL开发人员建议最好使用最新版本,并且主-从服务器均使用相同的版本。同时MySQL 3.23版本仍然是beta测试版,而且这个版本可能不能向下兼容。所以因为这个原因,在实际的网站中,我现在还没有使用这个版本。拥有容错能力具有一个好处是,在不需中断任何查询的情况下,对服务器进行升级。

      第一步:配置主服务器

      在这篇文章的剩下篇幅中,我将指定两台服务器。A(IP为10.1.1.1)作为主服务器(简称为主机)。B(IP为10.1.1.2)作为后备服务器(简称为备机)。

      MySQL的复制功能的实现过程为:备机(B)与主机(A)连接,然后读出主机的二进制更新日志,再将发生的变化合并到自已的数据库中。备机需要一个用户帐号来与主机连接,所以在主机上创建一个帐号,并只给它FILE权限,如下操作:

      GRANT FILE ON *.* TO replicate@10.1.1.2 IDENTIFIED BY password;

      为了备机能够与主机连接,要在主机上运行FLUSH PRIVILEGES,不过不要担心,因为我们将在下面的步骤中停掉服务器。

      现在我们需要主机数据库的一个快照,并且对主机进行配置,允许生成二进制的更新日志。首先编辑my.cnf文件,以便允许二进制更新日志,所以在[mysqld]部分的下面某个地方增加一行:log-bin。在下一次服务器启动时,主机将生成二进制更新日志(名为:<主机名>-bin.<增量序号#>)。为了让二进制更新日志有效,关闭MySQL服务程序,然后将主机上的所有数据库目录到另一个目录中,接着重新启动mysqld。

      请确定得到了所有数据库,否则在进行复制时,如果一个表在主机上存在但在备机上不存在,将因为出错而退出。现在你已经得到了数据的快照,和一个从建立快照以来的二进制日志,上面记录着任何对数据库的修改。请注意MySQL数据文件(*.MYD,*.MYI和*.frm)是依赖于文件系统的,所以你不能仅仅进行文件传输,如从Solaris到Linux。如果你处于一个异种的服务器环境,你将不得不使用mysqldump实用程序或其它的定制脚本来得到数据快照。


      第二步:配置备机

      让我们继续。停掉备机上的MySQL服务程序,并且把从主机上拷贝来的数据库目录移到备机上的data目录下。请确认将目录的拥有者和属组改变为MySQL用户相应值,并且修改文件模式为660(只对拥有者和属组可读、可写),目录本身为770(只对拥有者和属组可读、可写和可执行)。

      继续。在备机上启动MySQL服务程序,确认MySQL工作正常。运行几个select查询(不要update或insert查询),看一看在第一步中得到的数据快照是否成功。接着,在测试成功后关掉MySQL服务程序。

      在备机上配置需要访问的主机,以便接收主机的更改。所以需要编辑务机上的my.cnf文件,在[mysqld]部分中增加下面几行:

      master-host=10.1.1.1 master-user=replicate master-password=password

      在启动备机服务程序后,备机服务程序将查看在my.cnf文件中所指定的主机,查看是否有改变,并且将这些改变合并到自已的数据库中。备机保持了主机的更新记录,这些记录是从主机的master.info文件中接收下来的。备机线程的状态可以通过sql命令SHOW SLAVE-STATUS看到。在备机上处理二进制日志中如果发生错误,都将导致备机线程的退出,并且在*.err的日志文件中生成一条信息。然后错误可以被改正,接着可以使用sql语句SLAVE START来重新启动备机线程。线程将从主机二进制日志处理中断的地方继续处理。

      至此,在主机上所发生的数据改变应该已经复制到备机上了,要测试它,你可以在主机上插入或更新一条记录,而在备机上选择这条记录。

      现在我们拥有了从A机到B机的这种主-从关系,这样当A机可能当机的时候,允许我们将所有的查询重定向到B机上去,但是当A机恢复时,我们没有办法将发生的改变恢复到A机中去。为了解决这个问题,我们创建从B机到A机的主-从关系。

      第三步:创建相互的主从关系

      首先在B机上的my.cnf文件中,在[mysqld]部分中加入log-bin,接着重新启动mysqld,然后创建可在它的上面执行复制功能的用户帐号,使用:

      GRANT FILE ON *.* TO replicate@10.1.1.1 IDENTIFIED BY password;

      在B机上运行FLUSH PRIVILEGES命令,以便装入在加入复制用户后的新的授权表,接着回到A机上,在它的my.cnf中加入下面几行:

      master-host=10.1.1.2 master-user=replicate master-password=password

      在重启A机的服务程序之后,现在我们一拥有了在A机与B机之间的相互主-从关系。不管在哪个服务器上更新一条记录或插入一条记录,都将被复制到另一台服务器上。要注意的是:我不敢确定一个备机合并二进制日志变化的速度有多快,所以用这种方法来进行插入或更新语句的负载平衡可能不是一个好办法。

      第四步:修改你的数据库连接程序

      既然你已经在A机和B机之间建立了一个相互的关系,你需要修改数据库连接程序,以便从这种方式中得到好处。下面的函数首先试图与A机连接,如果不能建立连接则与B机连接。

      /******************************************************** function db_connect() returns a link identifier on success, or false on error ********************************************************/ function db_connect(){ ?$username = "replUser"; ?$password = "password"; ?$primary = "10.1.1.1"; ?$backup = "10.1.1.2"; # attempt connection to primary if(!?$link_id = @mysql_connect(?$primary, ?$username, ?$password)) # attempt connection to secondary ?$link_id = @mysql_connect(?$secondary, ?$username, ?$password) return ?$link_id; } ?>


      我在两种情况下对使用了上面技术的数据库连接建立过程进行了测试,一种是主MySQL服务程序关闭了,但是服务器还在运行,另一种情况是主服务器关闭了。如果只是mysqld关闭了,连接会马上转向备机;但是如果整个服务器关闭了,就出现了无限地等待(两分钟后我放弃了跟踪 -- 很短的注意跨度),因为PHP在查找一个不存在的服务器。不幸地是,不象fsockopen函数,mysql_connect函数没有一个超时参数,然而我们可以使用fsockopen来模拟一个超时处理。

      第五步:一个改进的数据库连接程序

      /******************************************************** function db_connect_plus() returns a link identifier on success, or false on error ********************************************************/ function db_connect_plus(){ ?$username = "username"; ?$password = "password"; ?$primary = "10.1.1.1"; ?$backup = "10.1.1.2"; ?$timeout = 15; // timeout in seconds if(?$fp = fsockopen(?$primary, 3306, &?$errno, &?$errstr, ?$timeout)){ fclose(?$fp); return ?$link = mysql_connect(?$primary, ?$username, ?$password); } if(?$fp = fsockopen(?$secondary, 3306, &?$errno, &?$errstr, ?$timeout)){ fclose(?$fp); return ?$link = mysql_connect(?$secondary, ?$username, ?$password); } return 0; } ?>

      这个新改进的函数向我们提供了一个可调的超时特性,这正是mysql_connect函数所缺少的。如果连接立即失败,这种情况如机器"活"着,但mysqld"当"掉了,函数立即移到第二个服务器。上面的函数相当健壮,在试图进行连接之前先测试一下,查看服务程序是否在指定端口进行监听,让你的脚本在一段可接受的时间段后超时,允许你适当地对出错情况进行处理。如果你修改了缺省端口3306,请保证对端口号进行修改。

      结论和意见

      首先,要确定得到了一个完整的数据快照。如果忘记拷贝一个表或数据库将导致备机线程序停止。生成快照的时刻是很关健的。你应该确保在拷贝数据文件之前二进制日志功能是无效的。如果在得到快照之前就允许了二进制日志功能,备机的线程可能会停止,原因就是当线程试图导入重要的记录时,可能会由于主键重复而停止。最好就是接照第二部分所讨论的处理办法来做:关闭-拷贝-允许二进制日志功能重启。

      你可能想要按照最初的一种方式来配制复制处理,并且在合适的时间关注备机,确保备机与主机保持同步。

      我没有测试过一个使用了复制特性的系统的负载平衡处理性能,但是我会灵活地使用这样系统来平衡插入和更新。例如,如果在两台服务器上两条记录都给出了同一个auto_increment值,这种情况备机线程会在哪一条记录上停掉呢?象这样的问题将会让负载平衡作为只读的处理,一台服务器处理所有的插入和更新,同时一组备机(是的,你可以有多个与主机分离的备机)处理所有的选择。

      我非常高兴,MySQL已经具备了复制系统的某些功能,并且配置很简单。使用它,你就可以开始针对失控的事件提供额外的安全措施了。我仅仅涉及了复制特性,这个我已经测试并且使用了,但是在MySQL的在线文档中的第11部分有中更详细的说明。

      译者的话:

      由于我原来使用的是3.22版的MySQL,所以为了测试一下我只好下载了3.23.24版的最新程序。而且因为只有一台机器,我只是增加了二进制日志的设置。不过,正如本文所说,的确有文件生成。如果大家对此感兴趣只好请自行测试了。另外,在最新的MySQL的使用手册中,我发现这个复制功能是在3.23.15版以后才有的,请大家检查自已的MySQL的版本。同时,文中关于二进制日志的设置是说在my.cnf中设置的。在我使用的3.23.24版本中,手册上说可以有三个文件进行参数设置,分别为windows目录下的my.ini文件,c:my.cnf和c:mysqldatamy.cnf中可以设置。我在设置log-bin时(不需要先设log参数)是使用mysql自带的WinMySQLadmin软件进行设置的,并且在my.ini中设定的,与文中不同,请大家自行测试。

  • 软件测试相关内容

    2008-08-15 11:01:03

    一、 Java编程技能
    1. Java编程基础:Java面向对象编程、Java API、Java异常处理、Java流等
    2. Java Web编程:JSP/Servlet编程、Java Bean、Struts等
    3. Java EE应用部署:WebLogic、JBoss应用服务器、Java EE企业级应用的部署

    二、 搭建测试环境-操作系统
    1. Windows操作系统的安装、维护;Windows操作系统的安全管理、用户管理;使用ghost进行备份和恢复
    2. AIX系统介绍/系统安装;系统管理工具的使用;软件安装与维护;系统的启动与关闭;存储管理;安全管理;任务与进程管理;系统备份与恢复
    3. Linux系统介绍/系统安装;系统管理工具的使用;软件安装与维护;系统的启动与关闭;存储管理、安全管理、任务与进程管理;系统备份与恢复

    三、 搭建测试环境-数据库系统
    1. SQL语言及开发技术:DDL、DML、DCL、DQL;子查询、多表查询、游标、存储过程、用户定义函数、触发器、数据库设计等
    2. SQL Server数据库:Microsoft SQL Server数据库的安装、管理;SQL Server数据库备份和恢复
    3. Oracle数据库安装配置:Oracle数据库基础知识;Windows/Linux上的数据库的安装、卸载;用户管理、网络连接、数据库备份与恢复;Oracle数据库中的函数和存储过程
    4. MySQL数据库:MySQL数据库的安装、配置;MySQL数据库的备份和恢复等软件工程 : Rational Unified Process(RUP)

    四、 软件工程
    1. 软件生命周期
    2. 软件工程目标和过程
    3. RUP(Rational Unified Process)

    五、 软件测试基础
    1. 单元测试、集成测试、外部功能测试、回归测试、系统测试、安装测试、验收测试
    2. 版本控制方法、源代码管理工具VSS/CVS;
    3. 软件缺陷管理:Bugzilla工具的使用
    4. 测试计划编写
    5. 测试文档书写
    6. 测试用例的编写

    六、 测试工具
    1. JUnit:单元测试工具
    2. Quick Test Professional:功能测试工具
    3. Load Runner:压力测试工具
    4. Test Director:测试管理工具

    七、 IT职业技能素养
    职业规划、沟通技巧、团队合作、专业技术规范、面试技巧等职业技能培训

    八、 项目实战。

  • 软件测试流程

    2008-08-13 02:16:46

        软件测试流程的方法很多了,我在一年的工作经验中归纳了一下,现归纳一些如下:功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。常用的测试方法如下:
    1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。
    2. 相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。
    3. 检查按钮的功能是否正确:如update, cancel, delete, save等功能是否正确。
    4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
    5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
    6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
    7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
    8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
    9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
    10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
    11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
    12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
    13. 重复提交表单:一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。
    14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
    15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
    16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
    17. 上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。
    18. 必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*
    19. 快捷键检查:是否支持常用快捷键,如Ctrl+C Ctrl+V Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。
    20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

Open Toolbar