测试方法总结范文（精选9篇）
测试方法总结 第1篇
报表测试方法总结
1.提高对业务的熟悉程度
和功能测试以及其他测试一样，报表测试也需要熟悉业务，包括业务流程、业务规则以及数据存储，不同点是报表测试要理解每个指标的算法、数据来源以及要明白具体的业务动作和指标之间的关系，例如：要统计保费收入，首先要考虑正常保单，其次要考虑批增、批减以及注销、全单退以及其他特殊批改，这些业务类型都可以对此指标的统计结果产生影响。所以如果不能分析业务动作和指标之间的关系，那就无法验证报表中数据的准确性。
2.数据准备
数据对报表测试来说是非常重要的问题，因为报表的基本功能就是通过各种查询统计分析的方法为用户提供准确的数据，帮助用户进行决策以及分析，所以在报表测试前要保证准备足够多准确、有效的数据。在实际测试的时候一定要覆盖到报表所要求的每个维度,要保证所有的指标都要有对应的数据，不能出现指标为零的情况，当然也不需要过多，只要覆盖了所有的类型就可以了。一下总结了两种数据准备的方法：
1> 对测试后期比如冻结测试时产生的数据进行备份，用于报表测试，前提一定要保证数据的原始性，不允许对任何人对数据进行修改；
2> 自己手工对数据进行准备并且精心设计，要分析影响所测指标的各种因素，以及每个因素可能出现的不同变化，这样才有可能覆盖各种查询统计方法，并且要考虑需要考虑的是对各种正常的、异常的业务流程和业务规则的组合的遍历或覆盖,从而来验证报表是否取到的该取的数据、没有取不该取的数据，并且最后计算出了正确的结果。最后要将自己准备的数据用excel保存，并对数据的特点进行记录，以提高测试时的效率，并可以减少回归测试工作量；
3.数据正确性验证
对于客户来说，使用报表就是期望通过报表系统这个平台能够快速简单的查到自己所需要的数据，所以测试报表最主要的内容就是要验证数据的正确性，总结方法如下：1 > 要弄清楚数据的来源，来源于哪张表、哪个字段；> 时间条件：统计区间具体应该以业务中的什么时间在卡，并且考虑需求中是否包括统计区间的边界值；
3> 要弄清楚所测表以及所测指标的特定条件，比如要统计2009-01-01——2009-01-31 这个月份所有代理业务，那特定条件就是将保单的业务来源要限制在代理业务中； 4> Sql准备，这个过程是将上面三个过程进行总结，也是后续和开发人员进行分析数据的基础，所以提高自己编写sql的能力。另外当测试时间不充裕的情况下，对一
5>
6>
7>
8> 些简单的报表，如清单之类的报表就可以不用自己遍写sql语句，直接选出各种业务类型的单子进行单独分析； 数据核对以及分析，用sql查询出的数据要和开发人员的进行核对，由于有些数据量很大，所以最好借助对比工具（推荐：BCompare此软件），对于核对不上的数据要单独进行分析，分析的过程往往是发现问题主要环节，在这个过程中，如果自己实在分析不出来，则可以让开发人员协助； 数据的显示格式：小数位、千分符，百分号等是否与报表设置的一致，单位、汇率等是否进行转化，将有些代码是否转换成文字，比如被保险人性别，是否将系统中的0、1转化成男或女； 明细与合计的一致性:各部分明细值的和是否和总和一致等； 要覆盖所有的查询统计方式，在时间充分的条件下，要根据条件（筛选项、维度）
通过等价类划分和排列组合设置各种条件组合，每种都要测试到，千万不能按照自己的习惯为准；
4.报表格式的显示
在数据验证之后，要关注的就是输出报表的显示格式是否符合客户需求。报表的格式主要有两大类：
一、保险行业标准中规定的报表使用固定格式，如：保监会上报的一些报表，二：按照企业或者用户的需求定制的报表，所以对这两大类报表则需要从以下几个方面去测试：
1> 报表的整体显示格式是否符合客户提供的表样
2> 报表的标题或者表名是否正确
3> 报表页面的时间段是否是用户选择的时间段
4> 当输出的内容过多时，分页方式是否正确，翻页时，是否有与上页相同的样式（如
表头），第2页的输出是否正确
5> 需要特别提醒的数据（一些异常数据）是否突出显示，有些指标计算方法特别复杂
或者有几个指标容易混淆时是否在页面有加注释
5.报表之间的可比性
在纵向的测试完成后，我们要将所测试的报表进行横向联系，因为有些报表虽然名称不一样，但是有些指标是一样的，这样我们就需要将这两张报表哪起来进行比较，看在相同的时间段内是否统计出的结果都是一样的。另外不同报表的不同指标之间也是有联系的，如：业务中的应收保费清单和财务中的应收保费科目余额，当两者统计口径一致的时候，清单中的应收保费的合计则等于财务应收科目的余额，还有保费收入、实收保费、应收保费在同一统计区间总保费收入 = 实收保费 + 应收保费（未实收到的），所以在测试过程中，一定要理清它们之间的层次、顺序，这就需要加强对业务的理解和知识的积累！
6.其他
1> 报表的输出以及打印
报表在系统中生成后,并没有结束.报表一般都需要打印出来供客户使用用,例如开会或者提交审批之类.所以报表的打印功能也是非常重要的.在打印之前,用户一般都需要导出报表做进一步的分析或用于和其他报表的比较.所以也要验证报表的导出功能.一般可以导出的主要格式是Excel,pdf格式,然后要验证导出的内容是否正确,与生成的报表相一致.2> 报表的性能
尽量要求开发人员采用最优的查询语句，避免客户在使用过程中等待时间过长 3> 报表的权限
对于有权限控制的系统,报表当然也应该和用户所具有的权限相一致.需要从两方面校验权限的控制.报表的条件定义:在条件选择区域,有些下拉框中应该不能显示用户权限范围外的数据.备注：目前这部分内容测试比较少，之前客户没有提出权限这方面的需求，但是最近在使用过程中，客户提出过，要求分公司人员只能查出自己分公司的清单，允许总公司查出所有的符合要求的清单，估计在后续还会提出类似这样的要求，所以这部分后续要需要加强测试。
测试方法总结 第2篇
测试人员介入时机
对于SIT测试，测试人员最佳介入时间为需求分析阶段，在需求分析阶段就介入测试可以使测试人员更高效充分的了解需求，从而提高后面测试用例编写及测试用例执行的效率。
制定测试方案
测试人员进入项目后首要任务是制定测试方案。制定测试方案的目的： 1.明确测试目的。2.制定本次测试范围。3.阐述本次测试的策略。
4.罗列测试过程中可能遇到的风险及应对措施。5.安排测试人员的任务。
6.确定测试实施过程中需要准备的数据。
7.确定测试阶段的轮次及各项测试工作的时间节点。8.制定缺陷分级的级别描述以及缺陷修复的时效。以上8点作为测试方案的重要内容。测试方案编写后，与项目组其他人员以及客户方一起参与测试方案的评审工作；对测试方案评审完成后测试方案正式定稿。
案例对需求的覆盖
测试案例对需求的覆盖率直接关系到测试质量，如果覆盖率不够则系统中隐藏的缺陷无法被发现，存在严重的质量风险。提高案例的覆盖率有效的方法：
1.提高测试人员对需求的理解，对需求进行逐字逐句的分析将显性与隐性的功能点充分挖掘出来。
2.测试人员在编写测试用例之前先编写测试大纲，罗列出功能点并与需求人员一同对测试大纲进行评审，找出遗漏的测试点。
3.测试大纲评审完成后根据测试大纲所罗列的测试点进行测试案例编写，编写完成后与开发人员、需求人员一同对案例进行评审，找出潜在的遗漏部分。
案例编写策略（易读易执行优先级等）
1.测试用例编写遵循以下大体分类：界面及字段显示，字段取值规则，模块功能，上下游模块功能关联。2.用例应包括以下内容：功能，子功能，优先级，用例类型，测试点，操作步骤，预期结果。
编写是功能子功能描述清晰，一条用例对应一个测试点和唯一的预期结果。操作步骤编写是简单易懂具有很好的可操作性，测试点、预期结果需言简意赅可读性强。
3.案例优先级的确定规则一般为：模块功能＝上下游模块功能关联＞字段取值规则＞界面及字段显示。
制定测试计划及测试资源分配（工作量轮次）
1.测试用例编写完成后对测试实施制定测试计划，计划按照单个测试人员每日预估执行案例数，测试人员数量，测试用例总量计算出需要的测试实施时间，如测算出的时间超过测试方案中计划时间时需要与项目负责人沟通延长测试时间或者增加测试资源。（每个人每天的工作量是有限的所以不可以通过总量/时间/人数来倒退每人每日需执行的数量）。
2.测试实施过程需经过三个阶段：准入测试阶段，第一轮测试阶段，第二轮测试阶段。
第二轮测试阶段在第一轮测试的案例中选取，选择策略：在一轮测试中该模块测试情况不良好，缺陷较多则在二轮中着重测试；系统的重要功能需在二轮中着重测试；一轮中缺陷优先级高的再二轮中着重测试。
3.测试用例在执行时有难易之分，为了保证测试人员可以完成计划中的工作量，在分配时要综合考虑有所区分。
实施过程中的策略
1.测试用例的难易程度存在两个维度：用例所属模块，用例优先级；当用例的所属模块功能操作较易时则可不考虑用例的优先级；当用例的所属模块功能操作以及需要准备的数据比较复杂时则需要优先执行用例优先级较高的用例。
2.测试人员被分配需执行的用例后首先要做的是纵览一遍需要执行的用例，对用例需要的数据进行整合，使用最少的数据来覆盖所需执行的用例。
3.在测试中遇到阻碍性问题导致后续功能测试进度延迟，此时需组织复杂该模块开发的骨干人员联合测试人员在该模块进入测试阶段之前进行调通，以便于测试人员按照测试计划开始该模块测试时不会发生严重的阻碍性缺陷，可以有效的提高测试效率。
缺陷的处理
1.使用测试工具提交缺陷时需填写完整功能模块，问题描述简单易懂并附上截图，标明使用的数据编号，使用的用户。
2.提交缺陷时缺陷级别严格按照测试方案中所制定的缺陷等级标准。
3.开发人员将缺陷状态指为已解决后测试人员在关闭时需复测，同时将复测通过的截图记录在测试工具中。
4.对于缺陷修复的时效需要实时关注，特别对于优先级高且影响测试进度的缺陷需要重点跟踪直到被解决。附件：
1.测试方案与计划：测试方案与计划.xlsx
单元测试中非公有类型方法的测试 第3篇
关键词：测试,保护类型,私有类型,派生,反射机制,透明性
软件测试的单元测试又称为模块测试，是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
作为一个类中最小单元的protected和private方法，是否也需要进行单元测试值得讨论，虽然对protected和private方法进行测试显然违背了OOP程序设计的初衷，但是对这两类方法进行测试的理由显而易见，基本可以总结如下：
(1)私有方法包含复杂的逻辑，测试私有方法可以增加测试的覆盖范围以及直接访问内部数据的能力，而非间接地通过公有方法访问。
(2)单元测试是关于最小功能模块代码的测试，私有方法当然也是最小功能模块代码之一。
在相当多的文档及资料当中，都有对一个设计良好的单元测试应当满足的条件进行了描述：
(1)自动化(automatic)
(2)彻底 (thorough)
(3)可重复 (repeatable)
(4)独立(independent)
(5)专业(profession)
而在测试非公有类型方法的时候，还得满足下面的条件：
透明(Transparency) ：不能改变原代码，既要测试的程序代码，比如在源代码中添加一个封装类。
作用域 (Scope) ：在debug或者release模式下都能进行测试。
简单(Simplicity) ：简单并易于修改，并且类型安全。
为了满足上述条件，可以很容易地想到以下几种策略，如表1所示但这些策略的问题显示易见。那么，到底有没有更好的方法解决这个问题呢?下面分开来讨论两种类型的测试方法
1 测试protected类型的方法
在面向对象编程中，一个保护类型的方法只能被派生类使用，所以保护类型的方法不能直接用于单元测试，如：假设在Project1.MyClass类中有如下方法需要测试：
该方法非常简单，但是符合上面提到的所有要求。既没有在产品源代码中添加任何代码，又非常简单安全，与debug或release时都无关。
该方法的优点：面向对象，类型安全，对源代码没有任何改动，简单易于实现。
2 测试private类型的方法
在面向对象的编程中，私有方法只能在类的内部使用，所以测试私有方法要做到以上几点非常麻烦，但是可以通过C#中的反射机制去间接地实现这样的功能。
反射：是指提供了封装程序集、模块和类型的对象(Type类型)。可以使用反射动态创建类型的实例，将类型绑定到现有对象，或从现有对象获取类型并调用其方法或访问其字段和属性。
在使用反射时，需要注意用户需要ReflectionPerssion权限，不过好在单元测试一般都是由开发人员做，所以这个权限一般是没有问题的。
要测试这样一个私有方法，可以新建一个测试工程，并在测试工程中添加一个帮助类MyTestProject.Util，在该类里面通过反射机制调用私有方法。定义如下：
私有方法ExecMethod用来传递给反射调用的私有方法的必要参数，并且返回调用方法的返回值。
公有方法ExecStaticMethod和ExecInstanceMethod封装了ExecMethod方法，暴露给客户分别用来调用静态的或者动态方法。
写好之后，就可以在测试工程中使用并进行测试了，使用方法的代码可以是这样：
看看上面的整个方法是不是符合单元测试非公有方法的要求：
透明：添加的Util类并没有在产品代码中出现。
范围：无论Debug或者Release时，都不影响测试。
简单：可以通过该方法调用任何非公有方法，唯一需要变化的是调用时需要传进去正确的参数(需要调用的方法名，方法的参数)。
3 结论
虽然是否要对非公有方法进行测试值得讨论，但是至少提供一个非常好的方法对非公有方法进行测试。可以通过派生来实现对保护类型的方法进行测试，可以通过MyTestProject.Uti类来实现对私有方法的调用。
参考文献
[1]Andy Hunt, Dave Thomas Pragmatic.Unit Testing in C#with NUnit[M].2edition Pragmatic Bookshelf.August30, 2007.
[2]朱少民.软件测试方法和技术[M].北京:清华大学出版社.
新方法测试天才宝宝 第4篇
埋点测试方法总结 第5篇
（相应的环境变量配置好，如有请忽略）
2.打开Eclipse 启动DDMS
找到logcat，如果当前视图中没有，通过以下方式找到 windows-show view-logcat 4.埋点检查
1.使用数据线将手机和电脑相连，登陆58 app 进行操作，查看logcat中的日志，logcat中日志会比较多，可以创建一个过滤器，Filter Name 随意填，bylog tag用的是new_actionlog,保存
2.观察log中的日志，与PM提供的埋点excel文档对比，是否一致
主要看3个值 pagetype、actiontype、params，不同的埋点，这3个参数对应的值不同，以excel为准
二、IOS 1.将ios_test_src.rar解压放到D盘跟目录下（可根据自己需要调整盘符，无中文目录）2.手机连接PC的共享wifi热点（不需要手动设置代理）
3.D:ios_test_srcsrc双击埋点监听端口7891.bat或埋点监听端口7890.bat”
4.打开APP包，切换到APP测试环境：个人中心-更多-右上角【测试界面】（只有测试包有）log开关打开”输入本机IP，输入脚本监听端口7890或7891
5.可以测试了
App测试方法总结 第6篇
1）扣费风险：包括短信、拨打电话、连接网络等。
2）隐私泄露风险：包括访问手机信息、访问联系人信息等。
3）对App的输入有效性校验、认证、授权、数据加密等方面进行检测 4）限制/允许使用手机功能接入互联网 5）限制/允许使用手机发送接收信息功能 6）限制或使用本地连接
7）限制/允许使用手机拍照或录音 8）限制/允许使用手机读取用户数据 9）限制/允许使用手机写入用户数据
10）限制/允许应用程序来注册自动启动应用程序 2.安装与卸载安全性
1）应用程序应能正确安装到设备驱动程序上
2）能够在安装设备驱动程序上找到应用程序的相应图标 3）安装路径应能指定
4）没有用户的允许，应用程序不能预先设定自动启动 5）卸载是否安全，其安装进去的文件是否全部卸载 6）卸载用户使用过程中产生的文件是否有提示 7）其修改的配置信息是否复原 8）卸载是否影响其他软件的功能 9）卸载应该移除所有的文件 3.数据安全性
1）当将密码或其它的敏感数据输入到应用程序时，其不会被存储在设备中，同时密码也不会被解码。2）输入的密码将不以明文形式进行显示。
3）密码、信用卡明细或其他的敏感数据将不被存储在它们预输入的位置上。4）不同的应用程序的个人身份证或密码长度必须至少在4-8个数字长度之间。
5）当应用程序处理信用卡明细或其它的敏感数据时，不以明文形式将数据写到其他单独的文件或者临时文件中。以防止应用程序异常终止而又没有删除它的临时文件，文件可能遭受入侵者的袭击，然后读取这些数据信息。
6）党建敏感数据输入到应用程序时，其不会被存储在设备中。7）应用程序应考虑或者虚拟机器产生的用户提示信息或安全警告
8）应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告，更不能在安全警告显示前，利用显示误导信息欺骗用户，应用程序不应该模拟进行安全警告误导用户。
9）在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作。10）应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况。
11）当进行读或写用户信息操作时，应用程序将会向用户发送一个操作错误的提示信息。12）在没有用户明确许可的前提下不损坏删除个人信息管理应用程序中的任何内容。13）如果数据库中重要的数据正要被重写，应及时告知用户。14）能合理的处理出现的错误。15）意外情况下应提示用户。4.通讯安全性
1）在运行软件过程中，如果有来电、SMS、蓝牙等通讯或充电时，是否能暂停程序，优先处理通信，并在处理完毕后能正常恢复软件，继续其原来的功能。2）当创立连接时，应用程序能够处理因为网络连接中断，进而告诉用户连接中断的情况。3）应能处理通讯延时或中断。
4）应用程序将保持工作到通讯超时，进而给用户一个错误信息指示有链接错误。5）应能处理网络异常和及时将异常情况通报用户。6）应用程序关闭网络连接不再使用时应及时关闭，断开。5.人机接口安全测试
1）返回菜单应总保持可用。2）命令有优先权顺序。
3）声音的设置不影响使用程序的功能。4）声音的设置不影响应用程序的功能
5）应用程序必须能够处理不可预知的用户操作，例如错误的操作和同时按下多个键。
二、安装、卸载测试
验证App是否能正确安装、运行、卸载、以及操作过程和操作前后对系统资源的使用情况 1.安装
1）软件安装后是否能够正常运行，安装后的文件夹以及文件是否写到了指定的目录里。2）软件安装各个选项的组合是否符合概要设计说明。3）软件安装向导的UI测试
4）安装后没有生成多余的目录结构和文件。2.卸载
1）测试系统直接卸载程序是否有提示信息。
2）测试卸载后文件是否全部删除所有的安装文件夹。3）卸载是否支持取消功能，单击取消后软件卸载的情况。4）系统直接卸载UI测试，是否有卸载状态进度条提示。
三、UI测试
1）测试用户界面（如菜单、对话框、窗口和其他控件）布局、风格是否满足要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。
2）UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。1.导航测试
1）按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航。2）是否易于导航，导航是否直观。3）是否需要搜索引擎。4）导航帮助是否准确直观。
5）导航与页面结构、菜单、连接页面的风格是否一致。2.图形测试
1）横向比较，各控件操作方式统一。
2）自适应界面设计，内容根据窗口大小自适应。3）页面标签风格是否统一。4）页面是否美观。
5）页面的图片应有其实际意义而要求整体有序美观。3.内容测试
1）输入框说明文字的内容与系统功能是否一致。2）文字长度是否加以限制。3）文字内容是否表意不明。4）是否有错别字。5）信息是否为中文显示。
四、功能测试
根据软件说明或用户需求验证App的各个功能实现，采用如下方法实现并评估功能测试过程： 1）采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准。2）根据被测功能点的特性列出相应类型的测试用例对其进行覆盖，如：设计输入的地方需要考虑等价、边界、负面、异常、非法、场景回滚、关联测试等测试类型对其进行覆盖。
3）在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。1.运行
1）App安装完成后的试运行，可正常打开软件。2）App打开测试，是否有加载状态进度提示。3）App页面间的切换是否流畅，逻辑是否正确。4）注册
同表单编辑页面 用户名密码长度 注册后的提示页面
前台注册页面和后台的管理页面数据是否一致 注册后，在后台管理中页面提示
5）登录
使用合法的用户登录系统
系统是否允许多次非法的登录，是否有次数限制 使用已经登录的账号登录系统是否正确处理 用户名、口令（密码）错误或漏填时能否登陆 删除或修改后的用户，原用户名登陆
不输入用户口令和重复点“确定/取消”按钮，是否允许登录 登陆后，页面中登录信息 页面中有注销按钮 登录超时的处理
2.应用的前后台切换
1）App切换到后台，再回到App，检查是否停留在上一次操作界面。2）App切换到后台，再回到App，检查功能及应用状态是否正常。
3）App切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
4）手机锁屏解锁后进入App注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
5）当App使用过程中有电话进来中断后再切换到App，功能状态是否正常。6）当杀掉App进城后，再开启App，App能否正常启动。
7）出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。
8）对于有数据交换的页面，每个页面都必须要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。3.免登陆
很多应用提供免登陆功能，当应用开启时自动以上一次登录的用户身份来使用App。1）考虑无网络情况时能否正常进入免登录状态。
2）切换用户登陆后，要校验用户登录信息以及数据内容是否相应更新，确保原用户退出。
3）根据Mtop的现有规则，一个账户只允许登陆一台机器。所以，需要检查一个账户登录多台手机的情况。原手机里的用户需要被退出，给出友好提示。4）App切换到后台，在切换回前台的校验。5）切换到后台，再切换回到前台的测试。
6）密码更换后，检查有数据交换时是否进行了有效身份的校验。
7）支持自动登录的应用在进行数据校验时，检查系统是否能自动登录成功并且数据操作无误。8）检查用户主动退出登录后，下次启动App，应停留在登录界面。4.离线浏览
很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。1）在无线网络情况可以浏览本地数据。2）退出App再开启App时能正常浏览。3）切换到后台再回到前台可以正常浏览。4）锁屏后再解锁回到应用前台可以正常浏览。
5）在对服务器段的数据有更新时回给予离线的相应提示。5.App更新
1）当客户端有新版本时，有更新提示。
2）当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动App时，仍出现更新提示。
3）当版本为强制升级版时，但给出强制更新后用户没有做更新时，退出客户端。下次启动App时，仍出现强制升级提示。4）当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。
5）当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。6）当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。6.定位、照相机服务
1）App有用到相机，定位服务时，需要注意系统版本差异。
2）有用到照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。3）测试照相机服务时，需要采用真机进行测试。7.PUSH测试
1）检查Push消息是否按照指定的业务规则发送。
2）检查不接收推送消息时，用户不会在接收到Push消息。
3）如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到Push。在非免打扰时间段内，用户能正常收到Push。
4）当Push消息是针对登录用户的时候，需要检查收到的Push与用户身份是否相符，没有错误的将其他人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。5）测试Push时，需要采用真机进行测试。
五、性能测试
1）响应能力测试：测试App中的各类操作是否满足用户响应时间要求。
App安装、卸载的响应时间 App各类功能性操作的响应时间
2）压力测试，反复/长期操作下，系统资源是否占用异常。
App反复进行安装卸载，检查系统资源是否正常 其他功能反复进行操作，检查系统资源是否正常
六、交叉事件测试
针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。如：App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。交叉事件测试非常重要，能发现很多应用中潜在的性能问题。1）多个App同时运行是否影响正常功能。2）App运行时前/后台切换是否影响正常功能。3）App运行时拨打/接听电话。4）App运行时发送/接收信息。5）App运行时发送/收取邮件。6）App运行时浏览网络。
7）App运行时使用蓝牙传送/接收数据。
8）App运行时使用相机、计算器等手机自带设备。
七、兼容测试
主要测试内部和外部兼容性 1）与本地及主流App是否兼容
2）与各种设备是否兼容，若有跨系统支持则需要检验是否在个系统下，各种行为是否一致。
不同手机屏幕分标率的兼容性 不同手机品牌的兼容性
八、回归测试
1）Bug修复后且在新版本发布后需要进行回归测试。2）Bug修复后的回归测试在交付前、要进行大量用例的回归测试。
九、用户体验测试
以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性，提出修改意见提升产品的潜在客户满意度。
1）是否有空数据界面设计，引导用户去执行操作。2）是否滥用用户引导。
3）是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导。4）菜单层次是否太深。5）交互流程分支是否太多。6）相关的选项是否离的很远。7）一次是否载入太多的数据。8）界面中按钮可点击范围是否适中。
9）标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换。10）操作应该有主次从属关系。
11）是否定义Back的逻辑。涉及软硬件交互时，Back键应具体定义。12）是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计。
十、手势操作测试
1）手机开锁屏对运行中的App的影响。2）运行中的App前后台切换的影响。3）多个运行中的App的切换。4）App运行时关机。5）App运行时重启系统。6）App运行时充电
7）App运行时Kill掉进程再打开
十一、客户端数据库测试 1）一般的增、删、改、查测试。
2）当表不存在时是否能自动创建，当数据库表被删除后能否再自建，数据是否还能自动从服务器中获取回来并保存。
3）在业务需要从服务器端取回数据保存到客户端的时候，客户端能否将数据保存到本地。
4）当业务需要从客户端取数据时，检查客户端数据存在时，App数据是否能自动从客户端数据中取出，还是仍然会从服务器端获取？检查客户端数据不存在时，App数据能否自动从服务器端获取到并保存到服务器端。
软件测试做事方法总结 第7篇
中医讲究望闻问切，我觉得我们做事的方式方法也可以按照这四点进行归纳。
望（细心观察、多留心）
1、看现象，特别是偶然问题，细心观察，留意步骤
a.对测试过程中只出现过一次的异常现象，可以先记录下来，或者与研发沟通，宁可错杀不可放过。b.对bug保持敏感度，相信自己的眼睛，针对偶然现象反复推敲，从自己的网络环境，拓扑结构入手，尝试复现。
c.低概率问题难以复现，需要先搭好抓包环境，遇到问题保存log，并记住时间点。
2、看用例，认真阅读，细心执行
a.测试过程用例在不断完善，执行用例要到位，认真阅读用例的预置条件、测试步骤、预期结果，有疑问要及时提出，用例结果要备注。b.执行用例的步骤不能遗落，结果要每条都对应。
c.预期结果不符要同需求、软件一起确认，并将结果告知三方。有变更时需要同步修改用例，并将bug提至mantis，评审bug时需要关注。
3、看mantis，经常查看mantis上bug状态
a.看自己的bug，对开发人员的备注多关注。研发人员备注的bug原因自己要搞懂。不清楚的一定要问。对概率问题研发备注未重现的，要问清楚log分析结果，是否需要协助重现等。
a.看别人提交的bug，一是避免bug重复提交，二是可以学习和思考，为什么别人可以发现这个bug，我没发现；或者我是不是也遇到同样问题，但是忽略了等等。b.评审过后的bug备注认真看。评审后的bug会备注一些专业意见可以学习，评审后的bug也会备注一些需要测试后续进行的工作要关注并执行。
4、看版本发布记录
a.版本发布后详细阅读版本发布记录，确认修改的每个点是否同计划一一对应，同研发确认是否修改点都一一列出。未列出的点会带来哪些影响。b.版本修改点影响范围是否列出，需重点测试模块是否有写明。
闻（认真倾听，反复思考）
1、听信息
a.项目前期反复讨论需求、方案时，是不是所有信息有掌握了，通过反复思考提出自己的意见或建议。
b.需求有变更时，要详细的了解清楚变更点。
c.认真倾听测试代表的版本计划，版本范围及版本测试中应重点关注的地方。
2、听经验
a.对自己不清楚的问题，认真听别人的分析讲解，从而思考从这个点拓展到面。b.Bug评审时认真听每个bug的分析情况，进而思考自己遇到这个问题如何处理，反思自己的测试方法。
c.听听别人同研发人员如何沟通，学学沟通方式和技巧，沟通的过程我要了解哪些信息，掌握哪些关键点和关键路径。
d.分享时听其他人的经验，进行借鉴。
问（不懂就问、不耻下问）
1、问bug a.遇到无法判断是不是bug的问题，问有经验的同事，问测试代表，问测试经理。b.遇到偶然问题，先问问其他同事是否也有遇到，可以一起思考一起找茬，尽快突破。c.同研发意见不一致时及时反馈测试代表，协商解决。
d.对研发备注的原因，大胆提出质疑，多问几个为什么，多对比，了解来龙去脉，不要被研发带偏。
e.Bug评审时需要测试人员跟踪压力的bug要多问，问问是否有可复现的路径，研发是否可以协助。
2、问方法
a.对自己无法解决的或者要花很长时间消化的，要多问，多学习，可以提高效率，避免不必要的时间浪费。
b.对自己不熟悉的模块，要多问经验丰富的同事，借鉴好的测试方法。
c.对流程不熟悉的，多问问研发人员，详细的了解流程，才能制定对应的测试方案。
切（找出问题、对症下药）
1、多看多听多问，相信大部分问题都能准确定位。针对少数不能定位的问题，bug评审给出结果，需要压力的进行压力，需要观察的进行观察。可以同研发人员一同协商制定方法。
2、已解决的问题也要多思考，解决这个问题是否会影响到其他模块，验证时要考虑全面。
测试方法总结 第8篇
1. 软件测试的概念。
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能的测试, 甚至根据需要编写不同的测试工具, 设计和维护测试系统, 对测试方案可能出现的问题进行分析和评估。执行测试用例后, 需要跟踪故障, 以确保开发的产品适合需求。可以说, 软件测试是发现软件错误的过程, 所以对软件要尽早测试和充分测试。
2. 黑盒测试。
大体上分, 软件测试方法可分为白盒测试和黑盒测试2种。黑盒测试也称功能测试或数据驱动测试。它在已知产品应具有的功能条件下, 通过测试来检测每个功能是否都能正常使用。在测试时, 把程序看作1个不能打开的黑盒子, 在完全不考虑程序内部结构和内部特性的情况下, 测试者在程序接口进行测试。常用的黑盒测试的测试方法包括等价类测试法、边界值测试法、决策表、因果图、场景法和正交试验法。
3. 白盒测试。
白盒测试则只根据程序的内部结构进行测试, 而不考虑外部特性, 如果程序结构本身有问题, 比如说程序逻辑有错误或是有遗漏, 则无法被发现。白盒测试可全面了解程序内部的逻辑结构, 无法对所有逻辑路径进行测试。在使用这一方案时, 测试者必须检查程序的内部结构, 从检查程序的逻辑着手, 得出测试数据。常用的白盒测试方法包括逻辑覆盖测试、基本路径测试、分支条件测试、循环测试和数据流测试等。
二、面向对象特征对软件测试的影响
类的封装性和继承性给面向对象软件的开发带来了很多好处, 但却给软件测试带来了不少负面影响。一方面, 面向对象测试用例设计的目标是类, 类的属性和操作是封装的, 而测试需要了解对象的详细状态。另一方面, 继承也给测试用例的设计带来了不少麻烦。继承并没有减少对子类的测试, 相反使测试过程更加复杂。
1. 类和对象对功能模块测试的影响。
在面向对象系统中, 系统的基本构造单元是封装了数据和方法的类和对象, 而不再是一个个能完成特定功能的功能模型。每个对象都有自己的生存期和状态。消息是对象之间相互请示或协作的途径, 是外界使用对象方法及获取对象状态的唯一方式。对象的功能是在消息的触发下, 由对象所属类中定义的方法与相关对象的合作共同完成, 并且对象在不同状态下对消息的响应也可能完全不同。
2. 系统功能实现对测试的影响。
在面向对象系统中, 系统的功能体现在对象间的协作上, 而不再是简单的过程关系调用。面向对象程序的执行实际上是执行一个由消息连接起来的方法序列, 方法的实现与所属对象本身的状态有关, 各方法之间可能有相互作用。为实现某一特定的功能, 可能要激活和调用属于不同对象类的多个成员函数, 形成成员函数的启用链。因此, 基于功能分解的自顶向下或自底向上的集成测试策略不适用于面向对象软件系统的测试。
3. 封装对测试的影响。
封装是指在词法单位之中或之间决定名字可见性的访问控制机制。它支持信息的隐蔽和模块化, 有助于防止全局变量的访问问题。尽管封装不会直接促成错误的发生, 但它却给测试带来了障碍。封装使对象的内部状态隐蔽, 如果类中未提供足够的存取函数来表明对象的实现方式和内部状态, 则类的信息隐蔽机制将给测试带来很多困难。
4. 继承对测试的影响。
继承也是面向对象语言中的一个本质特征。继承可用于一般与特殊关系, 并且方便编码。但继承削弱了封装性, 产生了类似于非面向对象语言中全局数据的错误风险。由于继承的作用, 一个函数可能被封装在具有继承关系的多个类中, 子类中还可以对继承的特征进行覆盖或重定义。
5. 多态对测试的影响。
多态是指一个引用可以与多个对象绑定的能力。多态能减少代码的复杂性和规模, 同时还可以实现动态绑定。但依赖于不规则类层次的动态绑定可能会产生编程人员想象不到的结果。虽然, 某些绑定能正确地运行但并不能保证所有的绑定都能正确地运行。以后绑定的对象可能很容易地将消息发送给错误的类, 执行错误的功能, 还可能导致出现一些与消息序列和状态相关的错误。
三、面向对象软件测试的层次划分
1. 方法测试。
主要考虑封装在类中的1个方法对数据进行的操作。可以采用传统的模块测试方法, 但方法是封装在类中的, 并通过向所在对象发消息来执行, 它的执行与状态有关, 特别是在操作多态性时, 设计测试用例时要考虑设置对象的初态, 并且要设计一些函数来观察隐蔽的状态值, 使它在收到消息时执行指定的路径。
2. 类测试。
在测试过程上等同于传统的单元测试, 面向对象的类测试主要考察封装在1个类中的方法和类的状态行为。进行类测试时要把对象与其状态结合起来, 进行对象状态行为的测试, 因为工作过程中对象的状态可能被改变并产生新的状态。测试范围主要是类定义之内的属性和服务, 以及有限的对外接口部分。在类测试过程中, 不能仅仅检查输入数据产生的结果是否与预期的相吻合, 还要考虑对象的状态, 整个过程应涉及对象的初态、输入参数、输出参数以及对象的终态。
3. 类簇测试 (集成测试) 。
把一组相互有影响的类看做一个整体称为类簇。类簇测试主要根据系统中相关类的层次关系, 检查类之间相互作用的正确性, 即检查各相关类之间消息连接的合法性、子类的继承性、父类的一致性、动态绑定执行的正确性和类簇协同完成系统功能的正确性等特性。其测试有2种不同策略:基于类间协作关系的横向测试和基于类间继承关系的纵向测试。
4. 系统测试。
是对所有程序和外部成员构成的整个系统进行整体测试, 检验软件和其他系统成员配合工作是否正确。另外, 还包括确认测试内容, 以验证软件系统的正确性和性能指标是否满足需求规格说明书的要求。
四、面向对象测试用例设计
1. 测试用例设计。
面向对象的软件测试用例则着眼于适当的操作序列, 以实现对类的说明。黑盒测试不仅适用于传统软件, 也适用面向对象的软件测试。白盒测试也可用于面向对象软件类的操作定义。但面向对象的软件中许多类的操作结构简单明了, 所以有人认为在类层上测试可能要比传统的软件中白盒测试更加方便。
2. 测试用例设计要点。
测试应该唯一地标识每一个测试案例, 并且与被测试的类明显地建立关联, 并陈述测试对象的一组特定状态。对每一个测试建立一组测试步骤, 需要思考或确定的问题包括:对被测试对象的一组特定状态, 一组消息和操作, 可能产生的一组异常, 一组外部条件, 辅助理解和实现测试的补充信息。
五、设计类测试用例
1. 基于故障的测试。
在面向对象软件中, 基于故障的测试具有较高的故障发现能力。基于故障的测试与传统的错误测试推测法类似。首先, 推测软件中可能有的错误。然后, 设计出可能发现这些错误的测试案例。为了推测出软件中可能存在的错误, 应该仔细研究分析模型和设计模型, 这在很大程度上要依靠测试人员的经验。
2. 基于脚本的测试。
基于脚本的测试主要关注用户需要做什么, 而不是产品能做什么, 即从用户任务 (使用用例) 中找出用户要做什么并去执行。这种基于脚本的测试有助于在一个单元测试情况下检查多重系统。所以基于脚本的用例测试比基于故障测试更加接近用户, 而且更复杂。
3. 随机测试。
如果一个类有多个操作功能, 这些操作功能序列有多种排列。而这种不变化的操作序列可随机产生, 用这种可随机排列的序列来检查不同类的实例, 叫做随机测试。随机测试是针对软件在使用过程中随机产生的一系列不同的操作序列设计的测试案例, 可以测试不同的类实例。
4. 划分测试。
划分测试方法与传统软件测试采用的等价划分方法类似, 它减少了测试类所需要测试用例的数量。首先, 用不同的划分方法 (包括基于状态的划分方法、基于属性的划分方法和基于功能的划分方法) 把输入和输出分类。然后, 针对划分出来的每个类别设计测试用例。
六、设计类间测试用例
1. 基于场景的测试。
基于场景的测试关注的是用户需要做什么, 这正是基于故障测试所忽略的。当与不正确的规约发生错误关联时, 软件就可能不执行用户所设定的工作, 这时软件质量就会受到影响。当一个子系统所建立的环境使得另一个子系统失效时, 子系统间的交互错误便会发生。
2. 行为测试。
测试方法总结 第9篇
摘要：FDR编码方法有效地降低了测试数据量，但其测试集中的无关位全部填充为0，平均每个测试向量检测的故障数目较少，测试质量较低.为了提高测试质量，并进一步提高测试数据压缩率，本文基于FDR方法提出了一种利用上一个测试向量的响应填充该测试向量中无关位的测试压缩方法.该填充方法提高了测试向量中无关位填充的随机性，从而提高了测试集的测试质量.提出方法的压缩效率与测试向量的顺序有关，基于最近邻居算法对测试集进行排序，降低了测试响应与下一个测试向量之间不相同的位数，对测试响应和测试向量差分处理后再进行FDR编码，从而降低了测试数据量.ISCAS89电路中几个大电路的实验结果表明，与FDR相比该方法的测试质量平均提高了5.9%，测试数据压缩率平均提高了2.5%，而只需要增加一个异或门的硬件开销.
关键词：测试质量；测试数据压缩；无关位；FDR编码
中图分类号：TP302文献标识码：A
随着超大规模集成（VLSI）电路制造工艺的不断进步，越来越多的知识产权（IP）核被集成到一个芯片上，测试数据量急剧增长.庞大的测试数据对昂贵自动测试设备（ATE）的存储性能、I/O通道数和频率提出更高的要求，同时增加了测试应用时间，提高了测试成本.因此，如何降低测试成本成为集成电路（IC）测试的一个重要研究课题.
测试数据压缩方法能够有效地减少测试数据量，降低存储和测试设备数据传输通道数量的需求.同时，经过适当设计，还可以降低测试应用时间和测试功耗.目前，测试数据压缩技术主要有3大类：1）线性解压方案[1-2]；2）基于广播式扫描的方案[3]；3）基于编码的压缩方案[4-7].
许多编码压缩方法利用测试集中的无关位X.FDR [4]是一种0游程编码，X都被填充为0以增加0游程的长度.文献[5]提出了一种EFDR编码，通过添加一个区分位，同时对0游程和1游程编码.文献[6]提出了交替游程编码，不需要添加区分位，对0游程和1游程交替编码，不仅能降低测试数据量还能减少测试功耗.在文献[7]中，测试集被分成等长的数据块，使用动态参考向量机制，利用前一块的信息对后一块数据进行编码.
在FDR编码中，无关位X都被填充为0，虽然提高了测试数据压缩率，但这种填充方式，使得测试向量中0的比率很高，平均每个测试向量检测的故障数目较少，降低了测试集的测试质量[8].
1测试压缩方案和解压缩结构
通常测试集中无关位X的比率较高，而测试质量与测试向量无关位填充方式有关.通常来说，测试向量中无关位的填充值随机性越好，测试质量越高.为了提高测试质量，我们考虑到测试向量和测试响应的相关性较弱，在新的测试压缩方案中，测试向量的无关位不再全部填充为0，而是根据前一个测试向量的响应值来填充下一个测试向量的无关位.
例1在图1（a）中有3个测试向量和对应的测试响应，首先倘若把第一个测试向量无关位填充为0，故障模拟后得到测试响应r1′，然后根据r1′填充测试向量t2中的X，故障模拟后得到测试响应r2′，再根据r2′填充测试向量t3中的X，故障模拟后得到测试响应r3′.填充无关位后的测试向量和测试响应如图1（b）所示.与图1（a）中测试向量的无关位全部填充为0相比，图1（b）中测试向量每位的取值随机性较好，通常可以获得更高的测试质量.
2测试向量/响应重排序方法
本节针对带无关位的测试集进行排序.对于相邻的测试向量和每个触发器，我们将测试响应和测试向量对RTP用（rik，tjk）表示，其中k为触发器编号.差分向量中对应的位为RTP中rik与tjk的差分.如果RTP为（0，0）， （1，1） ，则差分向量中对应的位为0；而如果为（1，0）， （0，1），对应的位为1.对于 （0，X） ，（1，X）通过填充X为其对应的响应值，其差分向量对应的位为0；而对于 （X，0）， （X，1），如果同时将多个响应中的X填为其测试向量值，有可能产生矛盾.因此，我们不能简单地用它们之间不相容的位数来计算差分向量中1的个数.如果RTP为（X，X），可以先确定测试响应中的X，再用该值将测试向量中的X填充，其差分向量对应的位为0.注意到，虽然RTP为（0，0）， （1，1）和 （0，X）， （1，X）， （X，X）时其差分向量对应的位为0，在排序中若优先考虑（0，0）， （1，1）的情况，可以获得较好的压缩效果，应该为其分配更佳的权值.表1为权值表，R代表响应值，T代表测试向量值，表中为具体RTP的权值.如，w0，1是为（0，1）分配的权值.
不排序测试向量得到的差分向量用FDR编码压缩后为00 1000 110011 1010 1001 1010，共计24位；而对测试向量排序后得到的差分向量用FDR编码压缩后为00 1001 11100000 110001，总计20位.从本例中可以看出，使用距离排序可获得更高的压缩率.
3实验结果
我们对提出的测试压缩方法进行了实验，用Synopsys公司的TetraMAX生成测试向量，实验电路为ISCAS89电路中最大的几个电路.在实验过程中分别取几组不同的权值，取结果最优的一组权值.最优的权值与例3中的相同.
表2为不同测试集中无关位填充方式测试质量的实验结果.第1列为电路名称，第2列为随机填充每个测试向量平均能检测的故障数，第3，4列分别为用0填充和提出填充方案平均每个测试向量检测的故障数与随机填充方法的比值.由实验结果可以看出，用提出填充方案填充的测试集可以获得与随机填充相当的测试质量，与0填充方式相比，提出方案平均每个测试向量多测5.9%的故障.
FDR编码的压缩率，第6列为本文方法的压缩率.实验结果表明与FDR编码方法相比，本文方法平均压缩率要高2.5%.其中计算压缩率如式（2）所示.
压缩率=（TD-TE）×100%/TD （2）
其中TD为原测试集的大小，TE为压缩后的测试集大小.
4结论
本文提出了一种利用前一个测试向量的响应填充当前测试向量无关位的方法，增加了填充的随机性，提高了测试质量.为了进一步提高测试压缩率，利用最近邻居算法对测试集进行排序.研究结果表明，本文方法简单可行，提高了测试质量和测试压缩率，而增加的硬件开销可以忽略不计.许多用来提高FDR方法压缩率的技术同样适用于本方法，这些改进将在下一步工作中体现.
参考文献
[1]XIANG D， LI K， SUN J， et al. Reconfigured scan forest for test application cost， test data volume and test power reduction[J]. IEEE Transactions on Computers， 2007， 56（4）： 557-562.
[2]XIANG D， CHEN Z， WANG L T. Scan flipflop grouping to compress test data and compact test responses for LauconCapture delay testing[J]. IEEE Transactions on Design Automation of Electronic Systems， 2012， 17（2）： 18.
[3]YOU Z Q， WANG W Z， LIU P， et al. A scan disablingbased BAST scheme for test cost and test power reduction[J]. IEICE Electronics Express， 2012， 9（2）： 111-116.
[4]CHANDRA A， CHAKRABARTY K. Test data compression and test resource partitioning for systemon achip using frequencydirected runlength（FDR） codes[J]. IEEE Transactions Computers， 2003， 52（8）：1076-1088.
[5]EIMALCH A H. Test data compression for systemonachip using extended frequencydirected runlength code[J]. IET Computers & Digital Techniques， 2008， 2（3）： 155-163.
[6]YE B， LUO M. A new test data compression method for systemonachip[C]//Proc IEEE International Conference on Computer Science and Information Technology （ICCSIT）. Chengdu， 2010：129-133.
[7]YI M X， LIANG H G， ZHANG L， et al. A novel Xploiting strategy for improving performance of test data compression[J]. IEEE Transactions on Very Large Scale Integration（VLSI） System， 2010， 18（2）： 324-329.