zhouxin / pubhg

== '''一、内容测试''' ==

1.信息的正确性，指网页上的信息是可靠的。

2.信息的准确性，主要指专业术语，比如网站上的各项用户协议、在线支付的各种文本都要符合相关规定标准。

3.信息的时效性，主要保证信息的有效时间处于最近的时期内。

== '''二、界面测试''' ==

常用winsows界面检查单[[BR]] ||编号||测试项|| ||1||软件窗口的长度和宽度接近黄金比例，使用户赏心悦目|| ||2||窗口上按钮的布局要与界面协调，不要过于密集和空旷|| ||3||界面上的字体一般为宋体，字号为8-12号|| ||4||颜色的搭配要赏心悦目，不要使用大红大绿的颜色，应与Windows标准窗体的颜色风格一致|| ||5||菜单的深度不要超过3级，快捷键没有重复，应采用“主要-次要-帮助”的布局形势|| ||6||无错别字，无中英文字混合|| ||7||字体样式统一，无全角半角混用|| ||8||测试窗体在常用分辨率下的显示情况，包括800×600，1024×768|| ||9||屏幕对角线交点的上方是最容易吸引用户的位置，要重点测试|| ||10||公举栏上的图表简洁美观，尽量符合其真实含义|| ||11||状态栏上要实时显示操作后窗体发生的变化||

== '''三、功能测试''' ==

首先要了解测试模块的具体需求，编写相应的测试用例，测试后以文字或者截图方式记录每一个测试出的BUG以及相应的测试用例，并及时反馈给开发人员，待开发人员修改后需要进行回归测试！[[BR]]（所有测试工作都需要在各个主要浏览器（Chrome、Firefox、IE6、7、8、9）下分别测试）[[BR]]（对于测试IE浏览器可以选择IETester工具）

'''1、注册'''[[BR]] 1）各种字段重复注册功能是否正常[[BR]] 2）各种字段过长、过短注册功能是否正常[[BR]] 3）各种字段不符合格式注册功能是否正常（如邮箱、邮政编码等）[[BR]] '''2、登录'''[[BR]] 1）帐号不存在却能登录[[BR]] 2）密码错误却能登录[[BR]] 3）各种字段过长、过短功能是否正常[[BR]] '''3、搜索框'''[[BR]] 1）什么也不填是否正常[[BR]] 2）正常填写是否正常[[BR]] 3）填写过长是否正常 '''4、按钮是否功能正常'''[[BR]] 1）提交、查询、添加、删除、打印、翻页等按钮功能是否正常 '''5、表单填写'''[[BR]] 1）表单项未填写完整是否提交正常[[BR]] 2）各种字段过长过短是否提交正常[[BR]] 3）各种字段不符合格式是否提交正常（如邮箱、邮政编码等）[[BR]] '''6、添加删除'''[[BR]] 1）添加删除项是否功能正常[[BR]] 2）主键是否可以重复添加[[BR]] '''7、附件上传'''[[BR]] 1）上传大文件、错误格式文件功能是否正常[[BR]] 2）显示、编辑是否正常[[BR]] '''8、网上缴费'''[[BR]] 1）测试是否信息未全不能缴费[[BR]] 2）缴费页面是否可以正常弹出（某些浏览器可能设置了广告过滤）[[BR]] 3）缴费之后是否立即提示（可能因为第三方通信原因而有显示延迟）[[BR]] '''9、信息表导出'''[[BR]] 1）信息表导出名称是否正确[[BR]] 2）信息表导出格式是否正确[[BR]] 3）信息表导出内容是否正确[[BR]]

== '''四、配置测试''' ==

如果所有人使用相同的计算机，相同的外设，或许我们就可以不提配置测试了，可是显然这是不可能事件，所以配置测试成为了测试中一向不可缺少的内容。[[BR]]配置测试的测试对象在于硬件，可是对于硬件，我们所要考虑的内容也不少:[[BR]]> 计算机(品牌机)，各个厂家的品牌机的配置是千差万别的，所以要小心[[BR]]> 配件，在兼容机大行其道的今天，我们不得不考虑各种配置的问题，这要比仅仅考虑计算机来得更加麻烦，这个时候得靠等价类划分来考虑这些问题了[[BR]]> 接口 USB，PCI，ISA这些都属于考虑范围[[BR]]> 外部设备 打印机等等[[BR]]> 设备驱动程序

== '''五、安全测试''' ==

安全性（security）测试。它是指在测试软件系统中对危险防止和危险处理设施进行的测试，以验证其是否有效[[BR]] 全面检验软件在软件需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应[[BR]] 对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案，进行针对性测试[[BR]] 在异常条件下测试软件，以表明不会因可能的单个或多个输入错误而导致不安全状态[[BR]] 用错误的安全性关键操作进行测试，以验证系统对这些操作错误的反应[[BR]] 对安全性关键的软件单元和软件部件，要单独进行加强的测试，以确认其满足安全性需求[[BR]]

'''安全性测试的方法[[BR]]'''

1.白/灰盒测试[[BR]] 对软件工程文档/源代码/二进制代码进行静态分析/审核[[BR]] 对运行时系统进行动态监测[[BR]]

2.功能验证[[BR]] 功能验证是采用软件测试当中的黑盒测试方法，对涉及安全的软件功能，如：用户管理 模块、权限管理、加密系统、认证系统等进 行测试，主要验证上述功能是否有效[[BR]]

3.漏洞扫描[[BR]] 安全漏洞扫描主要是借助于特定的漏洞扫描器完成的。通过使用漏洞扫描器，系统管理员能够发现系 统存在的安全漏洞，从而在系统安全中及时修补漏 洞的措施[[BR]] 分为两种类型：主机漏洞扫描器是指在系统本地运行检测系统漏洞的程序；网络漏洞扫描器是指基于网络远程检测目标网络和主机系统漏洞的程序[[BR]]

4.模拟攻击[[BR]] 对于安全测试来说，模拟攻击测试是一组特殊的极端的测试方法，以模拟攻击来验证软件系统的安全防护能力[[BR]] 例子：Fuzzing，使用大量半有效的数据作为应用程序的输入，以程序是否出现异常为标志，来发现应 用程序中可能存在的安全漏洞[[BR]]

== '''六、性能测试''' ==

性能测试的目的，简单说其实就是为了获取待测系统的响应时间、吞吐量、稳定性、容量等信息。而发现一些具体的性能相关的缺陷（如内存溢出、并发处理等问题），只是一种附加结果。从更高的层次来说，性能测试最想发现的，是瓶颈。在实际工作，一般的应用系统会从这么几个方面进行性能测试。[[BR]]

1、基准测试[[BR]] 　　Benchmark或者Baseline测试。一般为单用户测试，或者是零数据量环境下的测试。目的在于建立一个可度量的参考标准，为其他测试场景或者调优过程提供对比参考。也可认为是最基础的性能测试，如果基准测试的结果都不能达到预期要求，那么后续场景也就没必要测试了。

2、日常压力测试[[BR]] 　　在基准测试通过后，应该先进行较小压力下的测试，首先对系统在日常压力下的表现进行测试。此压力需要根据系统使用相关数据得出，如系统平均每天访问量、平均在线人数、每日完成事务数等。通过此测试，发现一些较表面的性能问题并进行处理。

3、峰值压力测试[[BR]] 　　在日常压力测试通过后，需要进行更大压力的测试。此处压力同样需要相关数据的支持，一般为未来几年后的预期压力。可根据历史日均压力、日最高压力等信息，估算出未来几年的日均以及日最高压力。再通过一些通用估算方法、如二八原则（80%的工作在20%时间内完成，相当于2小时完成一天8小时的工作量），将日压力转换成峰值压力。 　　峰值压力为可预期到的最大负载压力，通过了此测试，则认为系统有能力满足未来增长的压力。

4、容量测试[[BR]] 　　验证了系统是否可满足预期的压力后，还需要知道系统能够承受的最大压力，也就是容量。一般通过“拐点法”进行测试，逐步增大系统的压力，直到性能指标不可接受或者出现了明显的拐点。

5、稳定性测试 　　验证系统是否可长期稳定的运行，是否存在一些短时间内可能无法发现的缺陷（如内存溢出、数据库连接不释放等）。为了缩短测试工期，一般可将预期一天的压力集中在2小时内完成（二八原则），这样持续加压10小时，便相当于系统运行5天。注意监控各种性能指标是否平稳，有无下降。[[BR]]

以上几种类型的测试，是性能测试过程中最多用到的。当然也也其他一些比较常用的类型，如绝对并发测试，测试多用户对某一功能的瞬时请求，主要用于验证系统是否存在并发逻辑上的处理问题。此测试也可划分到不同的压力测试场景中去，根据不同的用户压力，测试相应的绝对并发，一般取在线用户数的10%进行测试；突发压力测试，对一些不在预期内的突然压力进行测试（其实既然想到了，就应该是在预期内了）。以银行门户网站为例，可能会由于发布了一条重要消息（政策调整）而导致访问量激增，这种压力是否会导致系统宕机或者暂时无法提供服务，就是突发压力测试需要考虑的了。也有人将此压力定义为峰值压力，这就无所谓了，只要考虑到会有这么一个问题就够了。[[BR]] 　上面主要说的是测试内容的划分，也就是说做性能测试时要考虑到的几个方面。从实际执行层面来看，测试的过程一般分为这么几个阶段：[[BR]]

1、测试确认[[BR]] 　　理解被测系统、寻找测试点、确认测试范围、测试环境等。一些重要信息需要同PM、需求人员、设计人员讨论确认，如用户最常用哪些功能、最关注哪的性能，程序上哪可能是压力点，哪些数据需要模拟到真实的量级，大体上需要使用哪种测试方法。

2、确定通过标准[[BR]] 　　性能是好是坏、测试是否通过，必须有明确的标准。这个标准，主要从客户的期望和业务上的需求两方面来考虑，客户的期望一般指页面上的响应时间，业务需求则是系统的处理能力，一般为吞吐量或TPS（每秒完成事务数）。标准制定的不合理，测试结果可能无法反映系统真实的性能表现，或者会让客户无法接受我们认为通过的软件。 　　至于具体如何去设定，是需要同业务负责人（一般为PM）和技术负责人（一般为设计人员）共同确认的，业务负责人了解用户的实际需求和期望，技术负责人了解具体的实现，可以判断哪些是不可达到的要求。 　　一旦达成了共识，那么测试就要严格的按照标准去执行。

3、测试设计 　　主要从上面提到的几个方面进行分析，针对系统的特点设计出合理的测试场景。为了让测试结果更加准确，这里需要很细致的工作。如建立用户模型，只有知道真实的用户是如何对系统产生压力，才可以设计出有代表性的压力测试场景。这就涉及到很多信息，如用户群的分布、各类型用户用到的功能、用户的使用习惯、工作时间段、系统各模块压力分布等等。只有从多方面不断的积累这种数据，才会让压力场景更有意义。最后将设计场景转换成具体的用例。[[BR]] 　　测试数据的设计也是一个重点且容易出问题的地方。生成测试数据量达到未来预期数量只是最基础的一步，更需要考虑的是数据的分布是否合理，需要仔细的确认程序中使用到的各种查询条件，这些重点列的数值要尽可能的模拟真实的数据分布（数据统计信息、执行计划相关的内容，此处就不细说了），否则测试的结果可能是无效的。[[BR]] 　　此外，性能测试执行过程中，需要监控收集的各种指标数据，也需要明确下来。

4、测试环境准备[[BR]] 　　部署测试环境，生成测试数据，环境预调优等等。

5、测试执行、监控[[BR]] 　　准备测试脚本，执行之前设计好的各个用例，监控并收集需要的数据。

6、问题分析定位、调优[[BR]] 　　发现问题或者性能指标达不到预期，及时的分析定位，处理后重复测试过程。[[BR]] 　　性能问题通常是相互关联相互影响的，表面上看到的现象很可能不是根本问题，而是另一处出现问题后引起的反应。这就要求监控收集数据时要全面，从多方面多个角度去判断定位。[[BR]] 　　调优的过程其实也是一种平衡的过程，在系统的多个方面达到一个平衡即可。[[BR]]

7、性能报告[[BR]] 　　将测试过程中记录的各种数据汇总成报告，将各方面需要的结果清楚的展现出来。[[BR]]

上面所有内容中，如果排除技术上的问题，性能测试中最难做好的，就是用户模型（或者叫系统使用模型）的分析。它直接决定了压力测试场景是否能够有效的模拟真实世界压力，而正是这种对真实压力的模拟，才使性能测试有了更大的意义。可以说，性能测试做到一定程度，差距就体现在了模型建立上。[[BR]] 　　至于性能问题的分析、定位或者调优，很大程度是一种技术问题，需要多方面的专业知识。数据库、操作系统、网络、开发都是一个合格的性能测试人员需要拥有的技能，只有这样，才能从多角度全方位的去考虑分析问题。[[BR]] 　　当然，对于测试人员来说，技术能力只是辅助手段，测试思想才是最根本的。敏锐的嗅觉、严谨的逻辑、合理的推测、大胆的实践是一个合格测试工程师的必备要素。

lam created at 12 years, 11 months ago