软件测试

1、常用测试工具对比1、loadrunner 性能稳定，压测结果及细粒度大，可以自定义脚本进行压测，但是太过于重大，功能比较繁多 2、apache ab(单接口压测最方便) 模拟多线程并发请求,ab命令对发出负载的计算机要求很低，既不会占用很多CPU，也不会占用太多的内存，但却会给目标服务器造成巨大的负载, 简单DDOS攻击等 3、webbench webbench首先fork出多个子进程，每个子进程都循环做web访问测试。子进程把访问的结果通过pipe告诉父进程，父进程做最终的统计结果。2、Jmeter目录文件讲解bin:核心可执行文件，包含配置 jmeter.bat: windows启动文件： jmeter: mac或者linux启动文件： jmeter-server：mac或者Liunx分布式压测使用的启动文件 jmeter-server.bat：mac或者Liunx分布式压测使用的启动文件 jmeter.properties: 核心配置文件 extras：插件拓展的包 lib:核心的依赖包 ext:核心包 junit:单元测试包3、Jmeter基础功能组件介绍线程组和Sampler1、添加->threads->线程组（控制总体并发） 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程 准备时长（Ramp-Up Period(in seconds)）：全部线程启动的时长，比如100个线程，20秒，则表示20秒内100个线程都要启动完成，每秒启动5个线程 循环次数：每个线程发送的次数，假如值为5，100个线程，则会发送500次请求，可以勾选永远循环 2、线程组->添加-> Sampler(采样器) -> Http （一个线程组下面可以增加几个Sampler） 名称：采样器名称 注释：对这个采样器的描述 web服务器： 默认协议是http 默认端口是80 服务器名称或IP ：请求的目标服务器名称或IP地址 路径：服务器URL Use multipart/from-data for HTTP POST ：当发送POST请求时，使用Use multipart/from-data方法发送，默认不选中。 3、查看测试结果 线程组->添加->监听器->察看结果树4、Jmeter的断言基本使用增加断言: 线程组 -> 添加 -> 断言 -> 响应断言 apply to(应用范围):Main sample only: 仅当前父取样器 进行断言，一般一个请求，如果发一个请求会触发多个，则就有sub sample（比较少用）要测试的响应字段：响应文本：即响应的数据，比如json等文本 响应代码：http的响应状态码，比如200，302，404这些 响应信息：http响应代码对应的响应信息，例如：OK, Found Response Header: 响应头模式匹配规则：包括：是响应文本的一个子集，是包含关系，可以用正则表达式 匹配：使用正则表达式匹配 equals：完全与响应文本相同，不能使用正则表达式 substring：也是包含关系，但是不能使用正则表达式2、断言结果监听器: 线程组-> 添加 -> 监听器 -> 断言结果里面的内容是sampler采样器的名称 断言失败，查看结果树任务结果颜色标红 通过结果数里面双击不通过的记录，可以看到错误信息)3、每个sample下面可以加单独的结果树，然后同时加多个断言，最外层可以加个结果树进行汇总5、结果聚合报告分析新增聚合报告：线程组->添加->监听器->聚合报告（Aggregate Report）lable: sampler的名称 Samples: 一共发出去多少请求,例如10个用户，循环10次，则是 100 Average: 平均响应时间 Median: 中位数，也就是 50％ 用户的响应时间 90% Line : 90％ 用户的响应不会超过该时间 （90% of the samples took no more than this time. The remaining samples at least as long as this） 95% Line : 95％ 用户的响应不会超过该时间 99% Line : 99％ 用户的响应不会超过该时间 min : 最小响应时间 max : 最大响应时间 Error%：错误的请求的数量/请求的总数 Throughput： 吞吐量——默认情况下表示每秒完成的请求数（Request per Second) 可类比为qps KB/Sec: 每秒接收数据量6、Jmeter用户自定义变量1、线程组->add -> Config Element(配置原件)-> User Definde Variable（用户定义的变量） 2、引用方式${XXX}，在接口中变量中使用7、CSV数据文件使用1、线程组->add -> Config Element(配置原件)-> CSV data set config (CSV数据文件设置) 2、如果是多个参数需要同时引用，则在CSV数据文件里面设置加多个字段 Variabled names(comma-delitited): csv_name,csv_pwd8、数据库压测操作配置讲解：1、Thread Group -> add -> sampler -> jdbc request 添加数据库请求 2、jar包添加 mysql-connector-java-5.1.30.jar 添加连接数据库的jar包 3、JDBC connection Configuration 配置JDBC request->add -> config element -> JDBC connection configuration核心配置Max Number of connections : 最大连接数MAX wait :最大等待时间 Auto Commit: 是否自动提交事务DataBase URL : 数据库连接地址 jdbc:mysql://127.0.0.1:3306/blogJDBC Driver Class : 数据库驱动，选择对应的mysqlusername:数据库用户名password:数据库密码数据库语句：1、Debug Sampler使用（结果树中查看） Thread Group -> add -> sampler -> debug sampler 2、参数讲解：(sql结尾不要加";") 1、variable name of pool declared in JDBC connection configuration（和配置文件同名） 2、Query Type 查询类型 3、parameter values 参数值 4、parameter types 参数类型 5、variable names sql执行结果变量名 6、result variable names 所有结果当做一个对象存储 7、query timeouts 查询超时时间 8、 handle results 处理结果集9、Jmeter非GUI界面参数-h 帮助 -n 非GUI模式 -t 指定要运行的 JMeter 测试脚本文件 -l 记录结果的文件 每次运行之前，(要确保之前没有运行过,即xxx.jtl不存在，不然报错) -r Jmter.properties文件中指定的所有远程服务器 -e 在脚本运行结束后生成html报告 -o 用于存放html报告的目录（目录要为空，不然报错）官方配置文件地址 http://jmeter.apache.org/usermanual/get-started.html10、Jmeter压测接口的性能优化1、使用非GUI模式：jmeter -n -t test.jmx -l result.jtl 2、少使用Listener， 如果使用-l参数，它们都可以被删除或禁用。 3、在加载测试期间不要使用“查看结果树”或“查看结果”表监听器，只能在脚本阶段使用它们来调试脚本。 4、包含控制器在这里没有帮助，因为它将文件中的所有测试元素添加到测试计划中。 5、不要使用功能模式,使用CSV输出而不是XML 6、只保存你需要的数据,尽可能少地使用断言 7、如果测试需要大量数据，可以提前准备好测试数据放到数据文件中，以CSV Read方式读取。 8、用内网压测，减少其他带宽影响压测结果 9、如果压测大流量，尽量用多几个节点以非GUI模式向服务器施压11、Jmeter图形化HTML压测报告dashboard1、Test and Report informationsSource file：jtl文件名 Start Time ：压测开始时间 End Time ：压测结束时间 Filter for display：过滤器 Lable:sampler采样器名称2、APDEX(Application performance Index)apdex:应用程序性能指标,范围在0~1之间，1表示达到所有用户均满意 T(Toleration threshold)：可接受阀值 F(Frustration threshold)：失败阀值3、Requests Summary 请求总结OK:成功率 KO:失败率4、Statistics 统计数据lable:sampler采样器名称 samples:请求总数，并发数*循环次数 KO:失败次数 Error%:失败率 Average:平均响应时间 Min:最小响应时间 Max:最大响应时间 90th pct: 90%的用户响应时间不会超过这个值（关注这个就可以了） 2ms,3ms,4,5,2,6,8,3,9 95th pct: 95%的用户响应时间不会超过这个值 99th pct: 99%的用户响应时间不会超过这个值 (存在极端值) throughtput:Request per Second吞吐量 qps received:每秒从服务器接收的数据量 send：每秒发送的数据量12、Jmeter图形化HTML压测报告Charts报表讲解1、Over Time（随着时间的变化）Response Times Over Time：响应时间变化趋势 Response Time Percentiles Over Time (successful responses)：最大，最小，平均，用户响应时间分布 Active Threads Over Time：并发用户数趋势 Bytes Throughput Over Time：每秒接收和请求字节数变化，蓝色表示发送，黄色表示接受 Latencies Over Time：平均响应延时趋势 Connect Time Over Time ：连接耗时趋势2、ThroughputHits Per Second (excluding embedded resources):每秒点击次数 Codes Per Second (excluding embedded resources)：每秒状态码数量 Transactions Per Second：即TPS，每秒事务数 Response Time Vs Request：响应时间和请求数对比 Latency Vs Request：延迟时间和请求数对比3、Response TimesResponse Time Percentiles：响应时间百分比 Response Time Overview：响应时间概述 Time Vs Threads：活跃线程数和响应时间 Response Time Distribution：响应时间分布图13、Jmeter压测注意事项the firewalls on the systems are turned off or correct ports are opened. 系统上的防火墙被关闭或正确的端口被打开。 all the clients are on the same subnet. 所有的客户端都在同一个子网上。 the server is in the same subnet, if 192.x.x.x or 10.x.x.x IP addresses are used. If the server doesn’t use 192.xx or 10.xx IP address, there shouldn’t be any problems. 如果使用192.x.x.x或10.x.x.x IP地址，则服务器位于同一子网中。 如果服务器不使用192.xx或10.xx IP地址，则不应该有任何问题。 Make sure JMeter can access the server. 确保JMeter可以访问服务器。 Make sure you use the same version of JMeter and Java on all the systems. Mixing versions will not work correctly. 确保在所有系统上使用相同版本的JMeter和Java。 混合版本将无法正常工作。 You have setup SSL for RMI or disabled it. 您已为RMI设置SSL或将其禁用。 官网地址 http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.html 压测注意事项：一定要用内网IP，不用用公网IP ...

代码检查代码检查要做的事所谓代码检查是以组为单位阅读代码，它是一系列规程和错误检查技术的集合。对代码检查的大多数讨论都集中在规程、所要填写的表格等。代码检查小组成员协调人，协调人应该是个称职的程序员，但不是该程序的编码人员，不需要对程序的细节了解得很清楚程序的编码人员程序设计人员测试专家检查会议进行的活动由程序编码人员逐条语句讲述程序的逻辑结构。在讲述的过程当中，小组的其他成员应提问题、判断是否存在错误。在讲述中，很可能是程序编码人员本人而不是其他小组成员发现了大部分错误。换句话说，对着大家大声朗读程序，这种简单的做法看来是一个非常有效的错误检查方法对着历来常见的编码错误列表分析程序小结这个代码检查过程通常将注意力集中在发现错误上，而不是纠正错误会议结束之后，程序员会得到一份已发现错误的清单要使检查过程有成效，必须树立正确的态度。如果程序员将代码检查视为对其人格的攻击、采取了防范的态度，那么检查过程就不会有效果。正确的做法是，程序员必须怀着非自我本位的态度来对待检查过程，对整个过程采取积极和建设性的态度：代码检查的目标是发现程序中的错误，从而改进软件的质量用于代码检查的错误列表数据引用错误(下标越界，变量未赋值等)数据声明错误(变量类型等)运算错误(除以0，不同类型间的加减运算等)比较错误(有不同数据类型的变量之间的比较运算等)控制流程错误(逻辑上的错误)接口错误(接收参数数量，类型)输入/输出错误代码走查走查概述代码走查的过程与代码检查大体相同，但是规程稍微有所不同，采用的错误检查技术也不一样代码走查小组成员协调人记录人员测试人员程序编写人员程序设计人员走查和检查的区别不同于仅阅读程序或使用错误检查列表，代码走查的参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。在会议期间，每个测试用例都在人们脑中进行推演。也就是说，把测试数据沿程序的逻辑结构走一遍。程序的状态（如变量的值）记录在纸张或白板上以供监视。桌面检查概述桌面检查可视为由单人进行的代码检查或代码走查：由一个人阅读程序，对照错误列表检查程序，对程序推演测试数据。桌面检查的效率是相当低的。其中的一个原因是，它是一个完全没有约束的过程。另一个重要的原因是它违反了本书第 2 章提出的测试原则，即人们一般不能有效地测试自己编写的程序。因此桌面检查最好由其他人而非该程序的编写人员来完成（例如，两个程序员可以相互交换各自的程序，而不是桌面检查自己的程序）。同行评分同行评分是一种依据程序整体质量，可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。该项技术的目的是为程序员提供自我评价的手段。

软件测试的定义测试是为发现错误而执行程序的过程软件测试的心理学通过测试来增加程序的价值，是指测试提高了程序的可靠性或质量。提高了程序的可靠性，是指找出并最终修改了程序的错误。因此不要只是为了证明程序能够正确运行而去测试程序；相反，应该一开始就假设程序中隐藏着错误（这种假设对于几乎所有的程序都成立），然后测试程序，发现尽可能多的错误如果我们的目的是证明程序中不存在错误，那就会在潜意识中倾向于实现这个目标，也就是说，我们会倾向于选择可能较少导致程序失效的测试数据。另一方面，如果我们的目标在于证明程序中存在错误，我们设计的测试数据就有可能更多地发现间题把程序当成病人，要找出病因软件测试的艺术测试用例中一个必需部分是对预期输出或结果的定义程序员应当避免测试自己编写的程序编写软件的组织不应当测试自己编写的软件应当彻底检查每个测试的执行结果测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”应避免测试用例用后即弃，除非软件本身就是一个一次性的软件计划测试工作时不应默许假定不会发现错误程序某部分存在更多错误的可能性，与该部分已发现错误的数目成正比软件测试是一项极富创造性、极具智力挑战性的工作总结软件测试是为发现错误而执行程序的过程一个好的测试用例具有较高的发现某个尚未发现的错误的可能性一个成功的测试用例能够发现某个尚未发现的错误

SegmentFault Web 测试

selenium和appium内部原理总结为什么会有这篇文章？前段时间学习了selenium的使用，今天开始接触appium看到appium的原理后产生了疑惑：现在的selenium是通过webdriver来操作驱动浏览器的，然而appium有一个server的概念那么为什么没有app driver这个东西呢？selenium早期的selenium早期的selenium主要是指selenium1.0的版本，这个版本主要由Selenium IDE + Selenium Grid + SeleniumRC组成seleniumRC就是后来被webdriver取代的一个代理serverRC == Remote Control 远程控制早期Selenium 引入了 Remote Control Server 这样一个代理 Server，JavaScript 脚本注入和与 Server 通讯都通过这个代理 Server 来进行，JavasScript可以获取并调用页面的任何元素，Selenium启动一个Server，将操作Web元素的API调用转化为一段段JavaScript，在Selenium内核启动浏览器之后注入这段JS缺点：但是JS注入速度不理想，稳定性大大依赖于Selenium内核对API翻译成的JS质量高低引入代理Remote Control Server是因为“同源策略”的限制，通过这个代理服务器来“欺骗”远程Server，达到使其以为是从同一个地方load代码以正确返回请求数据的效果seleniumRC的原理Selenium RC Server 启动一个浏览器（或是已经使用中），并注入js代码将测试脚本代码传到客户端的 Selenium-Core 中Selenium-Core 翻译并解析执行用户录制的操作让代理 Server 进行通讯Remote Control Server 负责跟远程 Web 应用服务器进行通讯seleniumRC的组成Selenium Server(Launcher、Http Proxy、Selenium Core)Client Libraries(用来控制server)seleniumRC的工作流程测试用例通过Client Libraries的接口向Selenium Server发送Http请求，要求和Selenium Server建立连接Selenium Server的Launcher启动浏览器，把Selenium Core加载入浏览器页面中，并发浏览器的代理设置为Selenium Server的Http Proxy。测试用例通过Client Libraries的接口向Selenium Server发送Http请求，Selenium Server对请求进行解析，然后通过Http Proxy发送JS命令通知Selenium Core执行操作浏览器的动作Selenium Core接收到指令后，执行操作浏览器收到新的页面请求信息，于是发送Http请求，请求新的web页面。Selenium Server会接收到所有由它启动的浏览器发动的请求Selenium Server接收到浏览器发送的Http请求后，自己重组Http请求，获取对应的web页面Selenium Server的Http Proxy把接收的Web页面返回给浏览器现在的seleniumselenium3.0以后移除了seleniumRC，取而代之的是webdriver用一张图来展示selenium3.0的运行原理这里讲到的是测试脚本和浏览器的交互，客户端开始运行驱动浏览器的脚本的时候，这时浏览器收到请求开始启动并开启侦听端口，并自动创建session，保持浏览器和对应客户端的会话连接,然后客户端运行脚本，向浏览器发送http请求，浏览器解析请求，根据脚本内容做出相应操作，返回response。这时客户端根据response选择结束还是继续执行tips:webdriver操作浏览器、页面采用的协议：the webdriver wire protocolClient和Server的通信协议：HTTPHTTP传输的数据内容为遵循WP协议json格式数据浏览器驱动实现了webdriver协议的apiappiumappium和selenium之间的不同appium本身就是一个server，而selenium废弃了server，用webdriver来驱动浏览器appium工作原理当开启appium服务器的同时就开启了监听端口；我们运行脚本的时候，调用任何的appiumAPI，都会向Appium Server端post一条HTTP请求，请求内容就是根据webdriver wire protocol协议规定的一条JSON格式的数据；Appium Server端接收到请求后，解析出JSON数据并发送到手机端；手机端上已经由BootStrap.jar(iOS为BootStrip.js)开启的socket服务器监听相应的端口，BootStrap.jar在appium每个session第一次访问手机端的时候会自动安装；手机端接收到对应的请求后，通过BootStrap.jar翻译成UIAutomator能执行的命令，然后通过UIAutomator处理并操作APP完成测试。appium的几个概念appium/appium server一般所说的appium其实是一个基于node.js的web服务器，它是测试脚本和设备端交互的桥梁用npm install -g appium 安装的是命令行的没有界面的appium serverappium GUI它是把没有界面的appium server封装出了一个图形界面，方便操作，但是现在已经被appium desktop所取代appium Desktop它是一款适用于Mac，Windows和Linux的开源应用程序，它以美观而灵活的用户界面为您提供appium server的强大功能appium client第1点中说到，appium其实是一个sweb server，server是接收请求来操作设备端的app的，既然有了server那么一定会有client这个client就是我们写测试脚本时导入的包python中可以运行 pip install Appium-Python-Client 来安装Android 和 iOS ...

测试的程序这个程序从一个输入对话框中读取三个整数值。这三个整数值代表了三角形三边的长度。程序显示提示信息，指出该三角形究竟是不规则三角形、等腰三角形还是等边三角形。分析对输入条件可以划分这么几个规则：边长是否为整数是否输入了三边三边是否符合三角形规则边长是否大于0划分等价类编写测试用例有效等价类三边长预期输出1,1,1等边三角形2,2,3等腰三角形2,3,2等腰三角形3,2,2等腰三角形4,5,6不规则三角形4,6,5不规则三角形6,5,4不规则三角形无效等价类三边长预期输出1.5,1.5,1.5请输入整数a,b,c请输入整数不输入请输入完整的三边长1,null,null请输入完整的三边长1,2,null请输入完整的三边长2,2,6三边不符合三角形规则3,3,6三边不符合三角形规则-1,-1,-1请输入大于0的三边长0,0,0请输入大于0的三边长

功能性测试评审需求，多方面考虑，整理出内在外在以及非功能性的直接间接功能点，对比需求，提取测试点根据常用的一些分析方法，等价类边界值判定表因果图场景法等方法，设计测试用例，对提取的功能点进行覆盖测试各个阶段不断跟踪缺陷，做好用例的更新迭代和不断变更需求所带来的业务或者需求的错误运行App安装完成后的试运行，可正常打开软件App打开测试，是否有加载状态进度提示App打开速度测试，速度是否可观App页面间的切换是否流畅，逻辑是否正确注册: 用户名密码长度、注册后的提示页面、前台注册页面和后台的管理页面数据是否一致、注册后，在后台管理中页面提示登录: 使用合法的用户登录系统、系统是否允许多次非法的登陆，是否有次数限制、使用已经登陆的账号登陆系统是否正确处理、使用禁用的账号登陆系统是否正确处理、用户名、口令（密码）错误或漏填时能否登陆、删除或修改后的用户，原用户登陆、不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆、登陆后，页面中登陆信息、页面中有注销按钮、登陆超时的处理注销: 注销原模块，新的模块系统能否正确处理、终止注销能否返回原模块，原用户、注销原用户，新用户系统能否正确处理、使用错误的账号、口令、无权限的被禁用的账号进行注销应用前后台切换APP切换到后台，再回到 app，检查是否停留在上一次操作界面APP切换到后台，再回到 app，检查功能及应用状态是否正常app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候当App使用过程中有电话进来中断后再切换到app，功能状态是否正常当杀掉app进程后，再开启app，观察app能否正常启动出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃免登录很多应用提供免登录功能，当应用开启时自动以上一次登录的用户身份来使用app考虑无网络情况时能否正常进入免登录状态切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示app切换到后台，再切回前台的校验密码更换后，检查有数据交换时是否进行了有效身份的校验支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误检查用户主动退出登录后，下次启动app，应停留在登录界面数据更新需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新确定哪些地方从后台切换回前台时需要进行数据更新根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试检查有数据交换的地方，均有相应的异常处理离线浏览在无网络情况可以浏览本地数据退出app再开启app时能正常浏览切换到后台再切回前台可以正常浏览锁屏后再解屏回到应用前台可以正常浏览App更新当客户端有新版本时，有更新提示当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷定位、照相机服务App有用到相机，定位服务时，需要注意系统版本差异有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务测试定位、照相机服务时，需要采用真机进行测试时间测试客户端可以自行设置手机的时区、时间，因此需要校验该设置对app的影响中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好推送测试检查push消息是否按照指定的业务规则发送检查不接受推送消息时，检查用户不会再接收到push如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH、在非免打扰时间段，用户能正常收到 push当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。测试push时，需要采用真机进行测试兼容性测试android版本的兼容性手机分辨率兼容性网络的兼容性：2G3G4GWIFI,弱网下、断网时app跨版本的兼容性各种设备品牌机型系统版本等兼容与本地及主流App是否兼容性能测试压力测试电量流量测试cup、内存消耗app启动时长crash率内存泄漏压服务器端接口及客户端在不同网络环境下响应速度极限测试：各种边界情况下验证app的响应能力，如：低电量、储存满。弱网等情况响应能力测试：验证各种情况下不同操作能否满足用户响应需求，比如App安装、卸载的响应时间、App各类功能性操作的影响时间压力测试：反复长期操作下，系统该资源的使用情况，比如App反复进行安装卸载，查看系统资源是否正常、其他功能反复进行操作，查看系统资源是否正常网络测试外网测试主要现实模拟客户使用网络环境，检验客户单程序在实际网若环境中使用情况及进行业务操作外网测试主要覆盖到wifi2G3G4G,.netwap、电信移动联通、所有可能的组合进行测试尽可能全面覆盖用户的使用场景，测试用例中需要包含不同网络排列组合的各种可能还有模拟信号被屏蔽时候。客户端的影响等。还有做外包场景测试，在高山、丘陵、火车上等特殊环境下进行全面测试接口性测试client端和service端的交互client端的数据更新和service端的数据是否一致client端更新时连接中断client端更新时service端宕机业务逻辑测试主要测试客户端业务能否正常完成异常测试交互异常性测试：客户端作为手机特性测试，包括被打扰的情况；如来电、来短信、低电量测试等，还要注意手机端硬件上，如：待机，插拔数据线、耳机等操作不会影响客户端异常性测试：主要包含了断网、断电、服务器异常等情况下，客户端能否正常处理，保证数据正确性回归测试Bug修复后且在新版本发布后需要进行回归测试Bug修复后的回归测试在交付前、要进行全量用例的回归测试升级更新测试每次app版本迭代更新时，配合不同网络环境，及不同更新权限（强制更新，不强制更新），进行下载、安装、更新、启动运行等测试测试升级后的功能是否与需求说明一样测试与升级模块相关的模块的功能是否与需求一致升级安装意外情况的测试（如死机、断电、重启）升级界面的UI测试不同操作系统间的升级测试支付测试支付结果的确认，数据库查询请求报文是否加密不同场景的支付，金额足够、金额不足、重复支付、无网支付、弱网支付、同账号多平台一起支付、余额宝微信信用卡等多种支付方式、不同支付方式的组合、密码正确/错误、支付上限等情况安全测试软件权限扣费风险：包括发送短信、拨打电话、连接网络等隐私泄露风险：包括访问手机信息、访问联系人信息等对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测限制/允许使用手机功能接人互联网限制/允许使用手机发送接受信息功能限制/允许应用程序来注册自动启动应用程序限制或使用本地连接限制/允许使用手机拍照或录音限制/允许使用手机读取用户数据限制/允许使用手机写人用户数据检测App的用户授权级别、数据泄漏、非法授权访问等安装与卸载安全性应用程序应能正确安装到设备驱动程序上能够在安装设备驱动程序上找到应用程序的相应图标是否包含数字签名信息JAD文件和JAR包中包含的所有托管属性及其值必需是正确的JAD文件显示的资料内容与应用程序显示的资料内容应一致安装路径应能指定没有用户的允许,应用程序不能预先设定自动启动卸载是否安全,其安装进去的文件是否全部卸载卸载用户使用过程中产生的文件是否有提示其修改的配置信息是否复原卸载是否影响其他软件的功能卸载应该移除所有的文件数据安全性当将密码或其他的敏感数据输人到应用程序时,其不会被储存在设备中,同时密码也不会被解码输人的密码将不以明文形式进行显示密码,信用卡明细,或其他的敏感数据将不被储存在它们预输人的位置上当应用程序处理信用卡明细,或其他的敏感数据时,不以明文形式将数据写到其它单独的文件或者临时文件中防止应用程序异常终止而又没有侧除它的临时文件,文件可能遭受人侵者的袭击,然后读取这些数据信息当将敏感数据输人到应用程序时,其不会被储存在设备中备份应该加密,恢复数据应考虑恢复过程的异常通讯中断等,数据恢复后再使用前应该经过校验应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全警告如果数据库中重要的数据正要被重写,应及时告知用户应用程序读和写数据正确通讯安全性在运行其软件过程中,如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时,是否能暂停程序，优先处理通信,并在处理完毕后能正常恢复软件,继续其原来的功能当创立连接时,应用程序能够处理因为网络连接中断,进而告诉用户连接中断的情况应用程序将保持工作到通讯超时,进而发送给用户一个错误信息指示有连接错误HTTP、HTTPS覆盖测试人机接口安全性返回菜单总保持可用命令有优先权顺序声音的设置不影响应用程序的功能应用程序必需利用目标设备适用的全屏尺寸来显示上述内容应用程序必需能够处理不可预知的用户操作,例如错误的操作和同时按下多个键安装、卸载测试安装软件在不同操作系统（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7）下安装是否正常软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里软件安装各个选项的组合是否符合概要设计说明软件安装向导的 UI测试软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）安装空间不足时是否有相应提示安装后没有生成多余的目录结构和文件对于需要通过网络验证之类的安装，在断网情况下尝试一下还需要对安装手册进行测试，依照安装手册是否能顺利安装卸载直接删除安装文件夹卸载是否有提示信息测试系统直接卸载程序是否有提示信息测试卸载后文件是否全部删除所有的安装文件夹卸载过程中出现的意外情况的测试（如死机、断电、重启）卸载是否支持取消功能，单击取消后软件卸载的情况系统直接卸载 UI测试，是否有卸载状态进度条提示UI测试用户界面（菜单、对话框、窗口）等布局，风格是否满足用户需求，文字位置，描述是否正确，界面美观程度，文字图片组合是否合理用户友好性、人性化、便于操作等导航测试按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航是否易于导航，导航是否直观是否需要搜索引擎导航帮助是否准确直观导航与页面结构、菜单、连接页面的风格是否一致图形测试横向比较。各控件操作方式统一自适应界面设计，内容根据窗口大小自适应页面标签风格是否统一页面是否美观页面的图片应有其实际意义而要求整体有序美观图片质量要高且图片尺寸在设计符合要求的情况下应尽量小界面整体使用的颜色不宜过多内容测试输入框说明文字的内容与系统功能是否一致文字长度是否加以限制文字内容是否表意不明是否有错别字信息是否为中文显示是否有敏感性词汇、关键词是否有敏感性图片，如：涉及版权、专利、隐私等图片交叉事件测试多个 App同时运行是否影响正常功能App运行时前/后台切换是否影响正常功能App运行时拨打/接听电话App运行时发送/接收信息App运行时发送/收取邮件App运行时切换网络（2G、3G、wifi）App运行时浏览网络App运行时使用蓝牙传送/接收数据App运行时使用相机、计算器等手机自带设备用户体验测试是否有空数据界面设计，引导用户去执行操作是否滥用用户引导是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导菜单层次是否太深交互流程分支是否太多相关的选项是否离得很远一次是否载入太多的数据界面中按钮可点击范围是否适中标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换操作应该有主次从属关系是否定义 Back的逻辑。涉及软硬件交互时，Back键应具体定义是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计硬件环境测试手势操作测试手机开锁屏对运行中的 App的影响切换网络对运行中的 App的影响运行中的 App前后台切换的影响多个运行中的 App的切换App运行时关机App运行时重启系统App运行时充电App运行时kill掉进程再打开网络环境无网络时，执行需要网络的操作，给予友好提示，确保程序不出现crash内网测试时，要注意选择到外网操作时的异常情况处理在网络信号不好时，检查功能状态是否正常，确保不因提交数据失败而造成crash在网络信号不好时，检查数据是否会一直处于提交中的状态，有无超时限制。如遇数据交换失败时要给予提示在网络信号不好时，执行操作后，在回调没有完成的情况下，退出本页面或者执行其他操作的情况，有无异常情况。此问题也会经常出现程序crash服务器宕机或出现404、502等情况下的测试后台服务牵涉到 DNS、空间服务商的情况下会影响其稳定性，如：当出现域名解析故障时，你对后台 API的请求很可能就会出现 404错误，抛出异常。这时需要对异常进行正确的处理，否则可能会导致程序不能正常工作。

输入框字符型输入框字符型输入框：英文全角、英文半角、数字、空或者空格、特殊字符“！@#￥%……&*？[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时，使用“粘贴、拷贝”功能尝试输入长度检查：最小长度、最大长度、最小长度-1、最大长度+1、输入超多的字符比如把整个文章拷贝过去空格检查：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格多行文本框输入：允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）安全性检查：输入特殊字符串（null,NULL, ,javascript,<script>,</script>,<title>,<html>,<td>）、输入脚本函数(<script>alert(“abc”)</script>)、doucment.write(“abc”)、<b>hello</b>）数值型输入框边界值：最大值、最小值、最大值+1、最小值-1位数：最小位数、最大位数、最小位数-1、最大位数+1、输入超长值、输入整数异常值、特殊字符：输入空白（NULL）、空格或"!@#$%^&等可能导致系统错误的字符、禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能，通过剪贴板拷贝到输入框，分页符，分节符类似公式的上下标等、数值的特殊符号如∑，㏒，㏑，∏，+，-等、输入负整数、负小数、分数、输入字母或汉字、小数（小数前0点舍去的情况，多个小数点的情况）、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制，8进制数值、货币型输入（允许小数点后面几位）安全性检查：不能直接输入就copy日期型输入框合法性检查：(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入30、输入非闰年，月输入[2]，日期输入[28、29]、输入闰年，月输入[2]、日期输入[29、30]、月输入[0、1、12、13]异常值、特殊字符：输入空白或NULL、输入~！@#￥%……&（）{}[]等可能导致系统错误的字符安全性检查：不能直接输入，就copy，是否数据检验出错信息重复在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,是否会报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理搜索功能功能实现果支持模糊查询，搜索名称中任意一个字符是否能搜索到比较长的名称是否能查到输入系统中不存在与之匹配的条件用户进行查询操作时，一般情况是不进行查询条件的清空，除非需求特殊说明组合测试不同查询条件之间来回选择，是否出现页面错误（单选框和多选框最容易出错）测试多个查询条件时，要注意查询条件的组合测试，可能不同组合的测试会报错添加、修改功能特殊键是否支持Tab键是否支持回车键提示信息不符合要求的地方是否有错误提示唯一性字段唯一的，是否可以重复添加，添加后是否能修改为已存在的字段（字段包括区分大小写以及在输入的内容前后输入空格，保存后，数据是否真的插入到数据库中，注意保存后数据的正确性）数据 正确性对编辑页的每个编辑项进行修改，点击保存，是否可以保存成功，检查想关联的数据是否得到更新。进行必填项检查（即是否给出提示以及提示后是否依然把数据存到数据库中；是否提示后出现页码错乱等）是否能够连续添加（针对特殊情况）在编辑的时候，注意编辑项的长度限制，有时在添加的时候有，在编辑的时候却没有（注意要添加和修改规则是否一致）对于有图片上传功能的编辑框，若不上传图片，查看编辑页面时是否显示有默认的图片，若上传图片，查看是否显示为上传图片修改后增加数据后，特别要注意查询页面的数据是否及时更新，特别是在首页时要注意数据的更新提交数据时，连续多次点击，查看系统会不会连续增加几条相同的数据或报错若结果列表中没有记录或者没选择某条记录，点击修改按钮，系统是否会抛异常删除功能特殊键是否支持delete键是否支持backup键提示信息不选择任何信息，直接点击删除按钮，是否有提示删除某条信息时，应该有确认提示数据实现是否能连续删除多个产品当只有一条数据时，是否可以删除成功删除一条数据后，是否可以添加相同的数据如系统支持批量删除，注意删除的信息是否正确如有全选，注意是否把所有的数据删除删除数据时，要注意相应查询页面的数据是否及时更新如删除的数据与其他业务数据关联，要注意其关联性（如删除部门信息时，部门下游员工，则应该给出提示）如果结果列表中没有记录或没有选择任何一条记录，点击删除按钮系统会报错注册、登陆模块注册功能注册时，设置密码为特殊字符，检查登录时是否会报错注册成功后，页面应该以登陆状态跳转到首页或指定页面在注册信息中删除已输入的信息，检查是否可以注册成功。登陆功能输入正确的用户名和正确的密码输入正确的用户名和错误的密码输入错误的用户名和正确的密码输入错误的用户名和错误的密码不输入用户名和密码（均为空格）只输入用户名，密码为空用户名为空，只输入密码输入正确的用户名和密码，但是不区分大小写用户名和密码包括特殊字符用户名和密码输入超长值已删除的用户名和密码登录时，当页面刷新或重新输入数据时，验证码是否更新上传功能文件类型正确、大小合适文件类型正确，大小不合适文件类型错误，大小合适文件类型和大小都合适，上传一个正在使用中的图片文件类型大小都合适，手动输入存在的图片地址来上传文件类型和大小都合适，输入不存在的图片地址来上传文件类型和大小都合适，输入图片名称来上传不选择文件直接点击上传，查看是否给出提示连续多次选择不同的文件，查看是否上传最后一次选择的文件查询结果列表列表、列宽是否合理列表数据太宽有没有提供横向滚动列表的列名有没有与内容对应列表的每列的列名是否描述的清晰列表是否把不必要的列都显示出来点击某列进行排序，是否会报错（点击查看每一页的排序是否正确）双击或单击某列信息，是否会报错返回键检查一条已经成功提交的记录，返回后再提交，是否做了处理检查多次使用返回键的情况，在有返回键的地方，返回到原来的页面多次，查看是否会出错回车键检查在输入结果后，直接按回车键，看系统如何处理，是否会报错刷新键检查在Web系统中，使用刷新键，看系统如何处理，是否会报错直接URL链接检查在Web系统中，在地址栏直接输入各个功能页面的URL地址，看系统如何处理，是否能够直接链接查看（匿名查看），是否有权限控制，是否直接执行，并返回相应结果页界面和易用性测试风格、样式、颜色是否协调界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字）操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作）提示界面是否符合规范（不应该显示英文的cancel、ok，应该显示中文的确定等）界面中各个控件是否对齐日期控件是否可编辑日期控件的长度是否合理，以修改时可以把时间全部显示出来为准查询结果列表列宽是否合理、标签描述是否合理查询结果列表太宽没有横向滚动提示对于信息比较长的文本，文本框有没有提供自动竖直滚动条数据录入控件是否方便有没有支持Tab键，键的顺序要有条理，不乱跳有没有提供相关的热键控件的提示语描述是否正确模块调用是否统一，相同的模块是否调用同一个界面用滚动条移动页面时，页面的控件是否显示正常日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX页面是否有多余按钮或标签窗口标题或图标是否与菜单栏的统一窗口的最大化、最小化是否能正确切换对于正常的功能，用户可以不必阅读用户手册就能使用执行风险操作时，有确认、删除等提示吗操作顺序是否合理正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。系统应该在用户执行错误的操作之前提出警告，提示信息.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。兼容性测试兼容性测试不只是指界面在不同操作系统或浏览器下的兼容，有些功能方面的测试，也要考虑到兼容性，包括操作系统兼容和应用软件兼容，可能还包括硬件兼容比如涉及到ajax、jquery、javascript等技术的，都要考虑到不同浏览器下的兼容性问题。链接测试导航测试导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。图形测试在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。验证所有页面字体的风格是否一致。背景颜色应该与字体颜色和前景颜色相搭配。图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到30k以下最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。业务流程测试业务流程，一般会涉及到多个模块的数据，所以在对业务流程测试时，首先要保证单个模块功能的正确性，其次就要对各个模块间传递的数据进行测试，这往往是容易出现问题的地方，测试时一定要设计不同的数据进行测试。安全性测试SQL注入（比如登陆页面）XSS跨网站脚本攻击：程序或数据库没有对一些特殊字符进行过滤或处理，导致用户所输入的一些破坏性的脚本语句能够直接写进数据库中，浏览器会直接执行这些脚本语句，破坏网站的正常显示，或网站用户的信息被盗,构造脚本语句时，要保证脚本的完整性。　document.write(“abc”)　<script>alter(“abc”)</script>URL地址后面随便输入一些符号，并尽量是动态参数靠后验证码更新问题现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。性能测试连接速度测试用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。负载测试负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？压力测试负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。压力测试的区域包括表单、登陆和其他信息传输页面等。负载/压力测试应该关注什么瞬间访问高峰如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟X个用户同时访问测试站点。每个用户传送大量数据网上书店的多数用户可能只订购1-5书，但是大学书店可能会订购5000本有关心理学介绍的课本?或者一个祖母为她的50个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址)系统能处理单个用户的大量数据吗?长时间的使用如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于web的email服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100个人同时点击某个站点。但是同时组织100000个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。采取措施：采用性能测试工具WAS、ACT，LR等协助进行测试测试中应该注意的其他情况在测试时，与网络有关的步骤或者模块必须考虑到断网的情况每个页面都有相应的Title，不能为空，或者显示“无标题页”在测试的时候要考虑到页面出现滚动条时，滚动条上下滚动时，页面是否正常URL不区分大小写，大小写不敏感对于电子商务网站，当用户并发购买数量大于库存的数量时，系统如何处理测试数据避免单纯输入“123”、“abc“之类的，让测试数据尽量接近实际进行测试时，尽量不要用超级管理员进行测试，用新建的用户进行测试。测试人员尽量不要使用同一个用户进行测试提示信息是否完整、正确、详细帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细可扩展性：是否由升级的余地，是否保留了接口稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护运行速度：运行的快慢，带宽占用情况

软件测试工程师是一个历史很悠久的职位，可以说从有软件开发这个行业以来，就开始有了软件测试工程师的角色。随着时代的发展，软件测试工程师的角色和职责也在悄然发生着变化，从一开始单纯的在瀑布式开发流程中担任测试阶段的执行者，到敏捷开发流程中QA（Quality Assurance）角色，为整个团队和产品的质量负责，测试工程师的职责和边界不断的扩大。近年来互联网行业的很多测试工程师被称为是测试开发工程师，也就是要具备自动化测试和测试工具开发能力的测试工程师，可以说是对测试工程师的能力要求达到了一个新的高度。相信有过测试工作经验的同学都会深有体会，不管是瀑布式还是agile模式，测试人员的工作总是被压在产品发布的最后阶段，整个团队的压力似乎都压在测试工程师身上，没有人会理会开发过程中产生的延误，因为那已经过去，可以在retro meeting的时候diss，但是目前最重要的问题是完成产品的发布上线。所以在寻找测试工程师需要什么技能之前，测试工程师的核心问题是什么，这是我们要搞清楚的。测试工程师面临的核心问题如何以最小的投入，最大程度保证产品的质量这个问题相信大家都有所体会，商业社会追求的就是效率，甚至是极致的效率。测试工程师也不能例外，不管是叫测试工程师，QA，或者是听着高大上的测试开发工程师，其实老板们的目标是一致的，就是在尽可能少的投入，最大程度保证产品的质量。说得现实一点，你的薪资水平就取决于你能解决这个核心问题的能力。明确了我们的目标，我们所需要的能力，也是围绕着这一个目标来设定的。概述按照笔者的经验和理解，一个软件测试工程师需要具备以下的技能：测试设计能力代码能力自动化测试技术质量流程管理行业技术知识数据库业务知识测试设计作为一名测试工程师，最基础的能力应该就是根据产品来设计测试用例的能力。最基础的能力往往也是最难做到精通的能力。要设计好的测试用例，需要对产品的特性和业务非常的熟悉，对用户的使用场景有着系统化的思考。除此之外，还有一些科学的测试用例设计方法可以帮助我们设计规范化的用例，而不是仅仅根据经验或者天马行空的想法来设计用例。业界有一些经典的测试用例设计方法需要测试工程师掌握：边界值分析等价类划分因果图判定表正交实验设计上述的这些方法并不是教条，而是帮助我们理清测试用例设计的思路和提高效率的工具。代码能力在传统的思维中，对测试人员的代码能力要求似乎不是很高，在业界确实也是这样的。很多测试工程师基本上不具备代码的能力，更多是测试的执行者。但是在当今这个时代下，要想突破传统功能测试人员的天花板，代码能力是必须的。具备代码能力的测试工程师有这样两个优势：阅读开发代码如果能够具备阅读开发代码的能力，对于提高测试人员的效率是很有帮助的，它可以帮助我们做到这些一些事情通过开发修改的代码预估影响的范围，即测试的范围参加技术评审，预估测试的风险，难点，重点通过代码的逻辑设计测试用例，强化测试用例的覆盖程度对缺陷进行初步的定位其实可以做到的事情还有很多，体现在测试过程的很多细节当中自动化测试的开发自动化测试是测试发展的方向，也是提高效率的有效方法。具备了代码能力，你可以轻松的驾驭各种流行的自动化测试框架和用例开发。自动化测试接着上面关于自动化测试的讨论。在目前的热门公司的招聘中，自动化能力已经是必备的能力，也是大家很关注的一个领域。目前可以粗略的把自动化测试分为这么几类：UI自动化UI自动化实现的目标是模拟人在产品UI界面上的操作，从而观察结果来完成测试的执行。UI自动化也可以从客户端的形态上分为PC端和移动端的自动化测试，有这样一些著名的自动化工具需要我们掌握：SeleniumSelenium是一个很经典的WEB端产品的UI自动化工具，针对不同的开发语言都有很好的支持。它的原理简单来说就是通过WebDriver把脚本产生的操作指令传递到浏览器，执行我们需要的操作并且获取相应的反馈，在脚本中完成校验。Appium从这个名字就可以看出这个工具和Selenium的相似之处。其实Appium可以理解为就是移动端的Selenium。同样也是在移动端模拟人的操作来实现执行测试用例的目的。随着移动互联网时代的到来，更多的业务已经从PC的WEB端转移到了移动端，移动端的自动化测试越来越重要。其实UI的自动化实现的原理都是很类似的，基本的逻辑都是：定位元素操作元素获取反馈最后通过某种测试用例框架来管理测试用例，例如python的unittest，JAVA的TestNG，Ruby的respec等等。所以说了解了某一种UI自动化的框架和工具，很容易的就能触类旁通的学习新的框架和工具。接口自动化在目前SaaS成为主流的情况下，API，即接口，成为了支撑业务的核心部分。前端页面和App里面的业务数据都是通过各种API与服务器进行通信，从而实现业务功能。目前大多数的接口都是基于HTTP协议的，其中Restful的接口又占大多数。而很多语言，例如Python和Ruby都有很好的库来支持HTTP协议的请求，这就为我们设计接口自动化提供了很好的基础。回到我们的核心问题，投入产出比的衡量。UI的自动化无论是从实现的成本还是维护的成本来说都是巨大的，所以业界越来越把重心放到了接口层的自动化实现上。接口的自动化具备这样的优势：运行效率高开发成本低维护成本低可以与开发代码同步开发接口自动化的实现思路也是简单明了的，那就是模拟浏览器，发送HTTP请求来实现对接口的调用，然后比较返回与期望值，达到验证结果的目的。当然，要设计一套真正高效的接口自动化框架也是不容易的。这里面涉及到如何提高用例的开发效率，降低开发维护成本等关键问题。同时还可以把接口测试与性能测试结合起来，丰富接口自动化测试的内涵。质量管理流程在敏捷开发的流程中，测试工程师有了一个新的定义：Quality Assurance Engineer。而测试的执行仅仅是职责中的一部分，更为重要的是要为整个团队的产品质量负责。从整个sprint的周期来看，QA工程师都要始终如一的贯彻质量保证的意识，与开发的关系也从早期的发现bug，转变为如何帮助开发团队一起提高产品的质量。同时还要和产品团队密切的合作，在需求的分析阶段就介入，分析质量保证工作如何规划和设计，而不是在产品发布前的测试执行阶段才介入。这个里面还包含很多Soft skill的要求，包括如何与团队合作，沟通等等，这也是敏捷开发模式的关键之一。行业技术知识这一部分内容其实涵盖的内容是非常丰富的，就以互联网行业举例吧。对于一个互联网产品，测试工程师需要了解的甚至是精通的知识是很多的，从前端页面的技术栈，API的设计，后端服务器的设计，后面会专门提到的数据库，还有整个服务的架构等等，测试工程师都需要有所了解。针对这个问题，其实有一个非常好的问题可以帮助大家去梳理涉及到的知识，这就是：从在浏览器的输入框输入一个网址，到看到网页的内容，这个过程中发生了什么？回答这个问题的深度和广度，基本就能反映一个测试工程师对于互联网产品技术的掌握情况。在这里呢，我简单的罗列一些涉及到的技术和概念，这些内容对于我们测试产品，都是非常有帮助的。DNSTCP/IPHTTPSSLRestfulHTMLDOMCSSRenderXpath服务器nginxSQLCookie&SessionXSS，CSRF这里仅仅是涉及到一部分内容，具体的内容可以根据工作中遇到的场景去深入学习和了解。数据库之所以把数据库单独列出来，是因为数据库的知识对于当今的很多产品都是非常核心的内容。不管是在手动测试还是自动化测试中，都有需要到数据库进行数据校验的时候。目前主要使用的数据库可以分为两类：关系型数据库非关系型数据库关系型数据库关系型数据库是最常见的数据库类型，这类数据库通过RDBMS数据库程序来进行管理和使用，常见的有SQL Server, MySQL等等。关系型数据库中强调一个事务（Transaction）的概念。所谓事务是用户定义的一个数据库操作系列，这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。例如在关系数据库中，一个事务可以是一条SQL语句、一组SQL语句或整个程序。事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。原子性（Atomicity）：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。一致性（Consistency）：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。隔离性（Isolation）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行。持久性（Durability）：一个事务一旦提交，他对数据库的修改应该永久保存在数据库中。对于实际的应用来说，SQL语言是必须要掌握的。能够通过SQL语句在数据库中找到需要的数据，是测试工程师必备的技能。SQL语句的语法大体上比较类似，在一些细节上不同的RDBMS会有些许的差别。对于自动化实现来说，在自动化测试中通过访问数据库来获得期望值也是很常见的场景。不同的语言都有访问数据库的库，整体来说应用也很简单。非关系型数据库随着互联网中大量的非结构化数据的产生，例如社交网络等等应用，用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经正在以几何级数的速率增加，同时还面临大量的数据挖掘工作，传统的关系型数据库已经无法满足。所以NoSQL渐渐的发展了起来。NoSQL最突出的特点就是数据的非结构化，通俗的讲，就是数据不再是以列和行这样的形式存储的。NoSQL存储数据的方式很多：值对存储，列存储，文档存储。例如比较常见的MongoDB就是将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。RDBMS vs NoSQLRDBMS高度组织化结构化数据结构化查询语言（SQL） (SQL)数据和关系都存储在单独的表中。数据操纵语言，数据定义语言严格的一致性基础事务NoSQL代表着不仅仅是SQL没有声明性查询语言没有预定义的模式：键 - 值对存储，列存储，文档存储，图形数据库最终一致性，而非ACID属性非结构化和不可预知的数据CAP定理高性能，高可用性和可伸缩性业务知识对于测试工程师来说，所测试产品的业务知识也是非常重要的。一个测试工程师可能已经具备了上述的所有技能，但是怎么把这些技能用来解决我们最先提到的软件测试的核心问题呢？这个里面的关键，或者说中心点，就是你所测试的产品的业务。测试的方法，规划，实施方法都是多种多样的，如果在这些方法中进行选择，所依赖的正是对产品的业务的深刻理解。这里的产品业务不仅仅指产品的特性，同时还包括了产品的用户特征，用户的使用习惯，以及由此带来的对产品的流量趋势。也可以说，测试人员必须要站在用户的角度来分析产品，而不是产品开发人员的角度。测试人员还需要找到产品的核心功能和核心业务，通过这样的分析来进行测试优先级的划分，以及缺陷的定级。同时对于自动化测试的规划和架构也有着重要的影响。例如在自动化测试中要首先覆盖那些核心的业务和功能，同时根据业务的特性，用自动化的方法去模拟用户的使用场景，把有限的自动化资源投入到最关键的部分。这一块技能听起来可能很虚，好像没有什么具体的知识点，但是在不断的工作和总结中，优秀的测试工程师是能够总结出一套符合某一类产品的测试方法的，甚至还可以提炼出一些更具备通用性的best practice，用到不同的产品中。说在最后或者这样一篇短短的文章无法涵盖软件测试的内涵，但是笔者也只是想抛砖引玉，让读者能够通过这样一种不能算全面的梳理，结合自己的工作经验，对自己所从事的软件测试工作有一个更深的理解。笔者计划根据这篇文章所列出的技能树，分别写文章进行更加细致的梳理和总结，希望能够和各位同行一起学习，一起进步，同时非常欢迎大家指正我的错误和不足。

什么是API　API是Application Programming Interface的简写。　- 实现了两个或多个独立系统或模块间的通信和数据交换能力。什么是API测试　API测试是不同于UI级自动化测试，其主要关注在系统架构的业务逻辑层，所以其主要关注不在于UI操作或用户感观上，更重调用逻辑关系。如果你想学习软件测试的，我给你推荐个群：903217991，里面有从基础开始学习的软件测试学习视频讲解，还有大牛帮你解决疑惑。　与UI级自动化测试通过控制键盘输入和鼠标等操作不同的是：API测试，我们是通过工具或代码方式去调用特定的API，获取输出，并记录系统的响应。　API测试需要与应用程序的API进行交互，为了测试这些API，我们可以：　· 使用测试工具来进行测试　· 自己写代码的方式进行测试API测试准备工作　首先你得获取目标测试系统的API相关文档，例如API对应的参数格式、期望返回结果等（一由开发提供文档，二自己抓包分析）　就我们所处国内的实际情况，在大部分情况下，开发都没有成型的文档。所以作为测试人员，你应该具备以下技能：　· 优先去推动开发生成一份合适的API说明文档　· 掌握抓包分析工具，能够自己去抓包分析形成API文档　· 至少把http协议掌握，了解其报文结构　· 对用户业务熟悉，能把API级业务逻辑和用户业务结合起来API主要测试什么　API级测试至少应该覆盖以下测试要点：　· 验证API所暴露的资源是否恰当的列出、创建、修改、和删除　· 验证API是否功能可用以及用户友好，是否便于与其他平台集成　· 安全测试，验证API是否包含了必要的认证以及敏感数据是否做了脱敏处理，是否支持加密或明码的http访问　· 自动化测试，将API高度业务场景化，实现自动化测试　· 文档，形成足够的文档，确保API质量的可维护行API测试要注意什么　在API测试过程中要重点关注什么呢？　· API测试用例要进行分类分组　· 每个API测试用例都应该参数化　· 在测试执行时，优先执行API测试　· 测试用例应该尽可能做到可独立执行　· 为了确保覆盖率，应该为API的所有可能输入进行测试数据规划API测试能发现什么bug　在API测试时，一般会发现哪类型的bug呢？　· 无法正确处理错误的深入条件　· 缺少或重复功能　· 可靠性问题　· 安全问题　· 多线程问题　· 性能问题　· 响应数据结构不规范问题　· 有效参数值不能正确处理API测试有哪些工具　· SoapUI　· JMeter　· PostMan　· 自己写代码　其他工具不推荐了，笔者首推SoapUI或自己写代码API测试你可能遭遇哪些大坑　· 无效的测试数据规划，导致你的参数穷举组合　· 因为没有界面，开发又不提供文档的情况下，大部分人无从下手，会一脸懵逼　· 平时测试大都关注正常的正常的情况，但要注意异常处理API必须进行测试，你懂的　· 代码你要会点代码，会点HTTP协议，不然没法沟通交流总结如果你想学习软件测试的，我给你推荐个群：903217991，里面有从基础开始学习的软件测试学习视频讲解，还有大牛帮你解决疑惑。 ...

前言：希望你能喜欢，不为别的，只为这份坚持。【背景】最近有些同学因为工作需要，看了我之前的学习笔记，然后跑来问我，说领导让他负责产品的性能测试，但他买了几本书，也安装了相关的工具，看来看去觉得太复杂了，觉得无从下手，就跑来问我：“性能测试是不是很难做？”【你问】性能测试是不是很难做？【我答】我从零距离接触性能测试到今天，也才一年多的时间，在这上面走过的路崎岖蜿蜒，个中滋味只可意会，不可言传。虽然我已经从入门到“放弃”了，但是我一直在思考和寻找，怎么样才能让性能测试不再看上去那么难，不再那么看着“高不可攀”。性能测试其实就是测试的一种类别，那么相应的，它也是有一套标准流程的，无外乎就是需求分析、测试计划制定、测试执行、结果分析等几个环节。所以，针对性能测试流程里的几个环节，我把自己换位到当初的小白，去思考自己当时最希望得到什么样的支持和帮助，再结合产品化的思维，思考出下面这样一个可以被拿来主义“的性能测试框架或指导性体系。1、是什么？性能测试里的常用基本概念、测试方法和标准流程的定义和解释；2、做什么？性能测试需求的分析方法，可以采用 checklist 的问题形式来帮助使用者得出对应需求所需要采用的性能测试种类，是压力测试，是稳定性测试，还是健壮性测试等等；3、怎么做？3.1 对应着上述第2步，得出来的具体的测试种类，每一种都有相应的测试方法说明，包括需要准备什么样的数据、步骤和如何选取相应的脚本进行修改或组装；3.2 有一套对应的样例库，包含脚本（.usr）、参数化文件（.dat）、场景（.lrs），虽然说不可能百分之百通用或者套用，但至少在同类产品的性能测试中都能套用，它们都是相对独立、结构清晰的一个一个的数据包，便于更新和管理；4、怎么样？性能测试完成后，系统都会生成一个报告。针对常用的单分析图和组合分析图，有样图与我实际的图做对比，并告诉我这些数据图，分别代表着性能的哪些指标，这些指标的值，又分别代表着性能是好还是坏；5、怎么办？对于常见的性能问题，罗列出通用的解决方案，比如是应该检查并优化 SQL，还是应该修改服务端 Tomcat 的连接数大小等等。如果你想学习软件测试的，我给你推荐个群：903217991，里面有从基础开始学习的软件测试学习视频讲解，还有大牛帮你解决疑惑。如果能有这样一套产品化的性能测试框架，那么我想，性能测试这种大山对于大多数测试工程师来说，也就不那么”高不可攀“了，对吧？具有指导性的作业文件、测试计划模板、独立的测试数据和测试脚本、分布式测试环境搭建脚本或手册、测试报告和相应的分析模板，能支撑一套完整的性能测试框架迅速落地，快速适应不同的项目，并且能让测试工程师以最小的学习代价完成性能测试任务。不过，这么一套框架不是一朝一夕就能建立起来的，它必须是在性能测试工程师对理论有了很深入地理解，并通过多个项目的实战，从中总结、归纳而形成的一套方法论体系，再辅以相对独立的数据和脚本、计划模板、分析步骤和模板等相关工具。不断地打磨、优化和改进，才能形成一套不论是入门级的小白，还是进行中的老鸟，都可以轻松利用它登上高峰的这样一个产品。

什么是TestCafeA node.js tool to automateend-to-end web testingWrite tests in JS or TypeScript, run them and view results抓几个重点词语：1. E2E Web Testing 2.JSTypeScript 3. Node.js Tool。简单说就是Node.JS编写的Web端UI自动化测试框架。官网：http://devexpress.github.io/t…TestCafe VS Selenium这时我想你跟我都有个疑问，跟Selenium 有啥区别？这里个人简单阅读了下官方文档，写几个粗浅的对比。Selenium毕竟已经是Web自动化测试的W3C标准了，它有非常多的优势，但TestCafe 作为后起之秀我这还想夸夸Demo使用过程的几点优于Selenium的感受。TestCafe 不再像Selenium 通过各个浏览器提供的Driver来驱动浏览器，而是有点类似Selenium RC直接往页面注入JS来操作页面，所以使用过程中再也不用担心因为浏览器版本和Driver版本以及Selenium版本不匹配而照成的Case执行失败。TestCafe是一整套完整的自动化测试框架，不仅提供了Cases的管理，运行，失败自动重跑，错误自动截图，并发等，对页面和页面元素的等待也封装完善而且使用简单，不像Selenium需要借助其他框架或者二次封装智能等待或者使用隐示/显示等待而有点复杂。TestCafe 可以控制整体的执行速度，甚至可以细到某个操作的执行速度（这个有点类似慢放，用起来大家可以感受下，非常魔性）TestCafe 因为只要你的浏览器支持JS，所以支持桌面，移动端平台。TestCafe debug模式，通过代码配置或运行时设置，可以控制执行过程中失败时进入调试模式。PS：当然以上的感受并没有经过项目的积累，纯粹Demo过程中的总结，也不晓得真正用到项目中会有哪些坑得踩。跟大家推荐一个学习资料分享群：903217991，里面大牛已经为我们整理好了许多的学习资料，有自动化，接口，性能等等的学习资料！人生是一个逆水行舟的过程，不进则退，咱们一起加油吧！TestCafe 快速入门安装因为是Node.js 项目，可以直接通过npm安装，全局安装如下npm install -g testcafe快速Demo一个baidu.jsfixture baidu demo .page https://www.baidu.com;test(‘baidu search’, async t=>{ await t.typeText(’#kw’,“hao123”) .click(’#su’)});通过Chrome运行testcafe chrome baidu.js上面代码看不懂没关系，感受下TestCafe就行。Cases管理自动化测试，终归还是测试，是测试就离不开测试用例，那TestCafe如何组织管理测试用例？fixture 和 test一个js文件可以包含多个fixture，一个fixture可以包含多个test。 我们可以理解为fixture是个集合，test标注的每个函数模块是一个case。语法fixture(“测试集描述”)fixture 测试集合描述test(‘用例描述’，fn(t))Demofixture(“cases manage”).page(“https://www.baidu.com”);test(’this case 1’, async I => { console.log(“this is case 1”);});test(’this case 2’, async I => { console.log(“this is case 2”);});test(’this case 3’, async I => { console.log(“this is case 3”);});fixture(cases manage 2).page(https://testerhome.com/#gsc.tab=0);test(’this case 1-1’, async I => { console.log(“this is case 1-1”);});test(’this case 2-1’, async I => { console.log(“this is case 2-1”);});test(’this case 3-1’, async I => { console.log(“this is case 3-1”);});运行结果：其中你会发现每个test 执行之前都会执行fixture打开页面的操作，但只会启动一次浏览器。那这时又会一个新的问题，除了打开页面的前提条件，是否框架自带了更多的前提/后置条件的处理了，也就是各种beforexxx。当然！fixture 的前置条件fixture.beforeEach( fn(t) )：每个test执行之前都会被运行fixture.afterEach( fn(t) )：每个test执行之后都会被运行fixture.before(fn(t))：比beforeEach更早运行，且每个fixture只运行一次fixture.after(fn(t))：比afterEach更晚运行，且每个fixture只运行一次Demojfixture(beforeeach test1) .page(https://www.baidu.com) .beforeEach(async I => { console.log(’this is beforeEach’) }) .before(async I => { console.log(’this is before’) }) .after(async I => { console.log(’this is after’) }) .afterEach(async I=>{ console.log(“this is afterEach”) });test(“test beforeAndafter”,I=>{ console.log(“1111”)});test(“test beforeAndafter”,I=>{ console.log(“2222”)});运行结果：test的前置条件test.before(fun(t))：该test运行之前运行test.after(fun(t))：该test运行之后运行Demofixture(beforeeach test1) .page(https://www.baidu.com) .beforeEach(async I => { console.log(’this is beforeEach’) }) .before(async I => { console.log(’this is before’) }) .after(async I => { console.log(’this is after’) }) .afterEach(async I => { console.log(“this is afterEach”) });test .before(async t => { console.log(this is test's before) }) (“test beforeAndafter”, I => { console.log(“1111”) }) .after(async t => { console.log(this is test's after) });test(“test beforeAndafter”, I => { console.log(“2222”)});运行结果：注意： 从控制台输出看，test的before/after 会覆盖fixture中的beforeEach/afterEach。也就是说如果一个test里面包含了before/after 那么fixture中的beforeEach/afterEach对该test无效。跳过测试fixture.skip ：跳过该fixture下的所有testtest.skip : 跳过该testfixture.only ：只执行该fixture下的所有test，其余的fixture下的test全部跳过test.only ： 只运行该test，其余全部跳过元素定位Demo1.创建Selectorsimport { Selector } from ’testcafe’;2.使用Selectors// 通过css定位 const osCount = Selector(’.column.col-2 label’).count; // 通过id定位 const submitButtonExists = Selector(’#submit-button’).exists;同时因为是JS注入方式，所以定位方式非常灵活，几乎JS中定位元素的方式都支持。 例如import { Selector } from ’testcafe’;fixture My fixture .page http://devexpress.github.io/testcafe/example/;const label = Selector(’#tried-section’).child(’label’);test(‘My Test’, async t => { const labelSnapshot = await label(); await t.click(labelSnapshot);});test(‘My test’, async t => { const secondCheckBox = Selector(‘input’) .withAttribute(’type’, ‘checkbox’) .nth(1); const checkedInputs = Selector(‘input’) .withAttribute(’type’, ‘checkbox’) .filter(node => node.checked); const windowsLabel = Selector(’label’) .withText(‘Windows’); await t .click(secondCheckBox) .expect(checkedInputs.count).eql(1) .click(windowsLabel);});同时还支持自定义扩展选择器，而且针对当前流行的React,Vue,Angular,Aurelia前端框架，还有特点的定位选择器，这里内容很多，有兴趣直接看官方文档：http://devexpress.github.io/t…操作元素操作其实上面例子我们已经用过点击，文本输入等方法了，官方也给了很全的api文档和demo：http://devexpress.github.io/t… ，这里就讲下一些比较特殊的元素或浏览器的操作。- resizeWindow()：设置窗口大小- t.maximizeWindow( )：最大化窗口fixturedemo.page(‘https://www.baidu.com’);test(‘设置win窗口大小’, async I => { await I.resizeWindow(300, 500) ..maximizeWindow( );}); - getBrowserConsoleMessages()：获取页面控制台消息 console.log(await I.getBrowserConsoleMessages())}); - wait()：暂停test(‘暂停’, async I => { await I.wait(3000);});- switchToIframe()：切换到iframe- switchToMainWindow()：返回到主窗体fixtureiframe 处理 .pagehttp://www.w3school.com.cn/tiy/t.asp?f=jseg_alert;test(‘iframe ‘, async t => { await t .click(’#button-in-main-window’) // 切换ifrme .switchToIframe(’#iframe-1’) // 返回主窗体 .switchToMainWindow();});- 下拉框选取:其实就是定位下拉框，再定位到下拉框下的选项，然后点击两次。fixture下拉框选取 .pagefile:///C:/Note/selenium_html/index.html;test.only(‘下拉框选取 ‘, async t => { const phone = Selector(’#moreSelect’); const phoneOption = phone.find(‘option’); await t .click(phone) .click(phoneOption.withText(‘oppe’));});- 三种警告框的处理setNativeDialogHandler(fn(type, text, url) [, options])：fu返回true 点击确定，返回false点击取消，返回文本则在prompt输入文本，这个执行过程中就不会看到警告框弹出，直接处理掉。fixture警告框处理 .pagehttp://www.w3school.com.cn/tiy/t.asp?f=jseg_alert`;test('处理alert ‘, async t => { await t .switchToIframe(“iframe[name=‘i’]”) // return true 表示点击确定 .setNativeDialogHandler(() => true) .click(‘input[value=“显示警告框”]’) .wait(10000);});fixture警告框处理 .pagehttp://www.w3school.com.cn/tiy/t.asp?f=jseg_prompt;test.only(‘处理 提示框 ‘, async t => { await t .switchToIframe(“iframe[name=‘i’]”) .setNativeDialogHandler((type, text, url) => { switch (type) { case ‘confirm’: switch (text) { //false 点击 取消 case ‘Press a button!’: return false; // 返回 true 点击确定 case ‘You pressed Cancel!’: return true; default: throw ‘Unexpected confirm dialog!’; } case ‘prompt’: // 警告框填入值 hi vidor return ‘Hi vidor’; case ‘alert’: throw ‘我是警告框！！’; } }) .click(‘input[value=“显示提示框”]’) .wait(10000);});上传文件setFilesToUpload()，清空上传：clearUpload()：fixtureMy fixture .pagehttp://www.example.com/;test(‘上传图片’, async t => { await t .setFilesToUpload(’#upload-input’, [ ‘./uploads/1.jpg’, ‘./uploads/2.jpg’, ‘./uploads/3.jpg’ ]) // 清除上传 .clearUpload(’#upload-input’) .click(’#upload-button’);});断言TestCafe自带了较为齐全的断言方法。断言都是通过expect()开始;import { Selector } from ’testcafe’;fixture My fixture;test(‘My test’, async t => { // 断言 通过CSS定位到的有3个元素，eql()表示相等，count表示定位元素个数 await t.expect(Selector(’.className’).count).eql(3);});test(‘My test’, async t => {// 断言ok()表示为true，exists表示元素是否存在 await t.expect(Selector(’#element’).exists).ok();});更多APIdemo查看官方文档：http://devexpress.github.io/t…特性在介绍几个TestCafe比较有意思的几个地方。执行速度testcafe 支持测试执行的速度控制。 speed(x)，x支持0.01到1之间，1则表示正常速度执行。全局速度控制可以通过控制台执行命令控制：testcafe chrome xxxx.js –speed 0.1控制某个test的执行速度test(“test setTestSpeed”, I => { I.setTestSpeed(0.1); ……});控制某个步骤的执行速度test(“test setTestSpeed”, I => { I.click("#kw").setTestSpeed(0.5);});Chrome设备模拟在启动Chrome浏览器时，可以设定Chrome提供的模拟器。testcafe “chrome:emulation:device=iphone x” xxx.js设备模拟器更多参数查看：http://devexpress.github.io/t…PageObject demo大家都知道，做UI自动化测试，肯定得使用PO或者PF模式，下面简单Demo个例子看看TestCafe 可以如何组织PO模式。baiduPage.jsimport {Selector, t as I} from ’testcafe’class baiduPage { baiduInput = Selector(’#kw’); baiduButton = Selector(’#su’).withAttribute(‘value’, ‘百度一下’); async searchBaidu(text) { await I .typeText(this.baiduInput, text, { // 清空 replace: true, }) .click(this.baiduButton) };}export default baiduPage = new baiduPage();baiduCases.jsimport baiduPage from ‘./baidu_page’fixturebaidu search.pagehttps://www.baidu.com/;test(‘po demo’, async I => { await I.typeText(baiduPage.baiduInput, “test”); baiduPage.searchBaidu(“testCafe”); await I.typeText(baiduPage.baiduInput,“居于之前的字符串空两个字符中插入”,{ caretPos:2 })});参数化/数据驱动其实就是创建一个对象，用for … of … 循环遍历fixturetodoPage test cases.pagehttp://todomvc.com/examples/react/#/;const testCases = [ { todo: ‘123’, }, { todo: ‘!@#$’, } // 等等可能性的cases，这里随便造两个作为data driver];for (const todoText of testCases) { test(‘create todo list ’ + todoText.todo, async t => { await todoPage.createTodoList(todoText.todo); await t.expect(todoPage.firstTodo.innerText).eql(todoText.todo); });}运行方式RunnerTestCafe 可以通过命令行的方式来执行测试脚本，但是感觉实际过程中肯定不是很方便，特别如果运行时需要跟一堆参数的情况下，那么TestCafe 提供了Runner，更方便配置和运行。如下配置，我需要被运行的Cases，错误自动截图，并发，生成report，智能等待，执行速度，执行的浏览器等全部配到Runner里面，这样我就不需要通过命令行运行，而且在项目中使用非常方便。const createTestCase = require(’testcafe’);const fs = require(‘fs’);let testcafe = null;createTestCase(’localhost’, 1337, 1338) .then(tc => { testcafe = tc; const runner = testcafe.createRunner(); const stream = fs.createWriteStream(‘report.json’); return runner // 需要运行的cases .src( [ ‘../demo/podemo/*.js’, ‘../demo/setWindowsSize.js’ ] ) // 设置需要执行的浏览器 .browsers([ ‘chrome’, ‘firefox’ ]) // 错误自动截图 .screenshots( // 保存路径 ‘../error/’, true, // 保存路劲格式 ‘${DATE}_${TIME}/test-${TEST_INDEX}/${USERAGENT}/${FILE_INDEX}.png’ ) // 生成report格式,根据需要安装对应report模块, // 详细看:http://devexpress.github.io/testcafe/documentation/using-testcafe/common-concepts/reporters.html .reporter(‘json’, stream) // 并发 .concurrency(3) .run({ skipJsErrors: true, // 页面js错误是否忽略,建议为true quarantineMode: true, // 隔离模式，可以理解为失败重跑 selectorTimeout: 15000, // 设置页面元素查找超时时间,智能等待 assertionTimeout: 7000, // 设置断言超时时间 pageLoadTimeout: 30000, // 设置页面加载超时时间 debugOnFail: true, // 失败开启调试模式 脚本编写建议开启 speed: 1 // 执行速度0.01 - 1 }); }).then(failedCount => { console.error(‘Failed Count:’ + failedCount); testcafe.close();}) .catch(err => { console.error(err); });结语：跟大家推荐一个学习资料分享群：903217991，里面大牛已经为我们整理好了许多的学习资料，有自动化，接口，性能等等的学习资料！人生是一个逆水行舟的过程，不进则退，咱们一起加油吧！ ...

“什么是软件测试？”这个看似简单的一个问题，其实也是最难的问题。说它简单，是因为这是一个基本的问题，做软件测试工作多年的小伙伴，自然知道什么是软件测试。说它难，是因为“软件测试”有很多内涵，要了解其全部内涵，并非那么容易。如果我们去问软件研发人员什么是软件测试，得到的答案可能五花八门，人们对软件测试有不同的理解。现在最常见的理解就是:软件测试就是找bug、发现缺陷。但也有人会认为软件测试就是：检查软件产品是否符合设计要求；验证软件产品需求、设计和实现的一致性；确认软件产品是否满足用户的实际需求；对软件产品质量的全面评估；提供软件产品质量信息；揭示软件产品的质量风险；投入较低的保障性成本极大地降低劣质成本；验证与确认；调查、分析和比较；不断探索；……有太多的理解，而且都没有错，只是看问题的角度不一样。虽然回答问题时，也容易脱口而出，不会仔细斟酌，只看到软件测试的一面，没有系统地分析“什么是软件测试”。下面我们就好好讨论“什么是软件测试”，因为有什么理解就有什么行动。有正确的理解，就有正确的操作；相反，有错误的理解，就有错误的操作。所以，先帮助读者对“软件测试”建立正确、全面的认识，构建起一个完整的“软件测试”轮廓，不至于陷入“盲人摸象”的困境，对软件测试有片面的理解。然后，我们再展开流程、方法、技术和实践的讨论。也就是在全面讨论“全程软件测试”之前，咱们需要找到共同语言，即对软件测试的一些基本概念达成共识，为后面的沟通扫除障碍。软件测试基本认知——正反思维什么是软件测试？人们常常回答：软件测试就是发现软件产品中的bug（缺陷）。也有人说，不对，软件测试是验证软件产品特性是否满足用户的需求。实际上，上述回答都没错，是对软件测试的正反两个方面的解释。早期，人们更多的是将“测试”看作是对产品的“检验”，检查软件的每个功能是否运行正常。正如1983年Bill Hetzel将软件测试定义为：“软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。”从这个定义中，至少我们可以看到以下两点。测试试图验证软件是“工作的”，也就是验证软件功能执行的正确性。测试的活动是以人们的“设想”或“预期的结果”为依据。这里的“设想”或“预期的结果”是指需求定义、软件设计的结果。但同时我们知道，软件测试有一条原则：测试是不能穷尽的。测试会面对大量的测试数据、测试场景或代码路径等，测试也只是一个样本实验，不能证明软件是正确的，只能说明发现的缺陷的确是缺陷。但如果没有发现问题，并不能说明问题就不存在，而是至今未发现软件中所潜在的问题。正如《软件测试的艺术》一书作者Glenford J. Myers所说，测试不应该着眼于验证软件是工作的，相反，应该用逆向思维去发现尽可能多的错误。他认为，从心理学的角度看，如果将 “验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。因此，1979年他给出了软件测试的不同的定义：“测试是为了发现错误而执行一个程序或者系统的过程。”从这个定义可以看出，假定软件总是存在缺陷的（事实上也是如此）、有错误的，测试就是为了发现缺陷，而不是证明程序无错误。从这个定义延伸出去，一个成功的测试是发现了软件问题的测试，否则测试就没有价值。这就如同一个病人（因为是病人，假定确实有病），到医院去做相应的检查，结果没有发现问题，那说明这次体检是失败的，浪费了病人的时间和金钱。以逆向思维方式引导人们证明软件是“不工作的”，会促进我们不断思考开发人员对需求理解的误区、不良的习惯、程序代码的边界、无效数据的输入等，找到系统的薄弱环节或识别出系统复杂的区域，目标就是发现系统中各种各样的问题。人类的活动具有高度的目的性，建立适当的目标具有显著的心理作用。如果测试目的是为了证明程序里面没有错误，潜意识里就可能不自觉地朝这个方向去做。在进行测试的过程中，就不会刻意选择一些尽量使程序出错的测试数据，而选择一些常用的数据，测试容易通过，而不容易发现问题。如果测试的目的是要证明程序中有错，那我们会设法选择一些易于发现程序错误的测试数据，这样，更早、更快地发现缺陷。毕竟开发人员力求构造软件，以正向思维方式为主，所以逆向思维方式可以提升我们的测试效率。逆向思维也有不利的一面，容易陷于局部的深度测试，缺乏广度。因为觉得某个地方有缺陷，就对这个地方进行测试，然后不断深入下去，这样容易忽视一些区域。虽然那些地方产生的缺陷不多，但如果产生了严重缺陷，也是我们不能承受的。所以正向思维也是有价值的，它会督促针对软件系统的所有功能点，逐个验证其正确性，哪个功能越重要越要进行检验。正向思维会让我们的测试更有广度——良好的测试覆盖面。为了做好测试，既要有深度，又要有广度；既要有效率，又要有测试工作自身完整的质量。所以，我们应该将正向思维和逆向思维有机地结合起来，做到效率和质量的平衡。换句话说，当我们需要效率时，更多采用逆向思维，当我们需要测试广度来确保完整的测试质量时，则多采用正向思维。这种平衡还体现在不同的应用领域，例如国防、航天、银行等关键性软件系统，承受不了系统的任何一次失效。因为这些失效完全有可能导致灾难性的事件，所以强调验证（verify），以保证非常高的软件质量。而一般的商业应用软件或服务，质量目标设置在“用户可接受水平”，以降低软件开发成本，加快软件发布速度，有利于市场的扩张，则可以强调逆向思维，尽快找出大部分缺陷。从狭义测试到广义测试前面提到Glenford J. Myers，他早期给软件测试的简单定义是：“程序测试是为了发现错误而执行程序的过程”，也体现出当时对软件测试的认识非常具有局限性。这也是受软件开发瀑布模型的影响，认为软件测试是编程之后的一个阶段。只有等待代码开发出来之后，通过执行程序，像用户那样操作软件发现问题，这就是“动态测试”。对于需求阶段产生的缺陷，在不同阶段发现和修复的成本是不一样的。如果在需求阶段发现需求方面的缺陷并进行修复，只要修改需求文档，其成本很低。需求阶段产生的缺陷，如果在需求阶段没有发现，等待设计完成之后才被发现，就需要修改需求和设计，成本增大。需求阶段产生的缺陷，如果在需求和设计阶段都没有发现，等待代码写完之后才被发现，就需要修改需求、设计、代码，成本就更大。设计上的问题，在设计阶段被发现，只要修改设计，如果在后期发现，返工的路径就变长了，其修复的成本自然就增大。缺陷发现得越迟，其修复的成本就越高，如图1-1所示，呈现了不同阶段产生的缺陷在不同阶段修复的成本，所以这要求我们尽早发现缺陷。图1-1　不同阶段产生的缺陷在不同阶段修复的成本为了尽早发现缺陷，我们有必要将软件测试延伸到需求、设计阶段，即对软件产品的阶段性成果——需求定义文档、设计技术文档进行评审或验证。这不同于软件质量保证（Quality Assurance，QA），虽然QA侧重评审，但它重点评审流程、评审管理，包括对需求、设计、编码和测试过程规范性的评审。而这里提到的需求和设计的评审依旧是对软件产品的检验或验证，只是需求文档和设计文档只是软件产品的阶段性产品。如果按照“软件=程序+文档+数据结构”这样的定义，需求文档和设计文档等也属于软件的组成部分，软件测试自然也包括需求和设计的验证。基于上述考虑，将早期的动态测试延伸到静态测试，即从狭义的软件测试发展到广义的软件测试。狭义的软件测试：动态测试——运行程序而进行的测试，测试只是编程之后的阶段，这也是由传统的瀑布模型而决定的。广义的软件测试：动态测试+静态测试，将需求评审、设计评审、代码评审（含代码的静态分析）等也纳入软件测试工作之中。这也使“软件测试”不再停留在编程之后的某个阶段上，而成为贯穿整个软件研发周期的质量保证活动，这也是本书“全程软件测试”的最早立意所在。静态测试就是在不运行软件系统时对软件或阶段性成果进行评审，包括需求评审、设计评审、代码评审等。引入静态测试，就可以尽早地发现问题，把问题消灭在萌芽之中，将每个阶段产生的缺陷及时清除，极大地提高产品的质量，有效地降低企业的成本。不管你是刚入门的小白、还没入门的群众、已经入门很久的前辈，不满足现在的工作情况，你想升值加薪，想弯道超车，都可以加我的群：903217991，咱们会提供一套专门的测试学习路线规划，带领你实现人生逆袭，财富自由。当然，咱们也有免费的资料可以提供给喜欢自学的小伙伴，所以欢迎大家踊跃加群我会一一为大家通过的。基于质量的认知软件测试虽然不能等同于软件质量保证（SQA），但它是软件质量保证的主要手段之一。当我们讨论软件测试时，绝对离不开“质量”。基于质量的认识，软件测试就是对软件产品的质量评估，提高软件产品有关的质量信息。即使从1.1节中我们认为软件测试就是发现软件产品中的bug（缺陷），哪什么是“缺陷”呢？简单地说，缺陷就是质量的对立面，一切违背质量的问题都可以看作软件缺陷（虽然从专业术语来仔细辨析的话，会将问题分为“内在错误，外部失效”等）。所以要理解软件测试，就必须理解软件质量。说起“质量”这个概念，我们都很熟悉，会说“坏的质量会怎样怎样，好的质量会怎样怎样”，但让我们给出质量的正式定义，可能不是容易的事情。我们也可以查国际标准，了解如何给质量下定义。例如IEEE Std 829-2008定义质量就是系统、组件或过程满足特定需求的程度，满足客户/用户需求或期望的程度。满足程度越高，质量就越好。例如，从软件需求定义文档来看，它所描述的需求和客户实际业务需求越吻合，将来实现的软件越有可能满足客户的业务需求，也意味着需求文档的质量越高。但这样说，还是比较宽泛，很难衡量质量。那究竟如何评估质量？从哪些维度来衡量质量呢？这就引出质量模型。基于质量模型，我们可以清楚质量有哪些属性（或维度），然后针对这些属性逐个地进行评估，不需要对软件质量进行整体评估，相当于按质量的各个维度来进行评估、各个击破。过去将软件质量分为内部质量、外部质量和使用质量，像代码的规范性、复杂度、耦合性等可以看作是内部质量，内部质量和外部质量共用一个质量模型。现在国际/国家标准将内部质量和外部质量合并为产品质量。产品质量可以认为是软件系统自身固有的内在特征和外部表现，而使用质量是从客户或用户使用的角度去感知到的质量。因为质量是相对客户而存在，没有客户就没有质量，质量是客户的满意度。过去认为，内部质量影响外部质量、外部质量影响使用质量，而使用质量依赖外部质量、外部质量依赖内部质量。今天可以理解为产品质量影响使用质量，而使用质量依赖产品质量。1．产品质量根据国际标准IEEE 24765-2010，产品质量是指在特定的使用条件下产品满足明示的和隐含的需求所明确具备能力的全部固有特性。而根据ISO 25010:2011标准，质量模型从原来的6个特性增加到8个特性，新增加了“安全性、兼容性”。如图1-2所示，蓝色标注的内容属于新增加或改动的内容。这里的安全性是指信息安全性（Security），原来放在“功能性”下面，但现在绝大部分产品都是网络产品，安全性越来越重要，所以有必要作为单独的一个维度来度量。今天系统互联互通已经很普遍，其次终端设备越来越多，除了传统的PC机，还有许多智能移动设备，如手机、平板电脑、智能手环、智能手表等，这些都要求系统具有良好的兼容性。这些特性就对应着测试类型，如功能测试、性能测试（效率）、兼容性测试、安全性测试等。图1-2　ISO 25010 2016 产品质量模型功能适应性（functional suitability）：软件所实现的功能达到其设计规范和满足用户需求的程度，强调正确性、完备性、适合性等。效率（efficiency）：在指定条件下，软件对操作所表现出的时间特性（如响应速度）以及实现某种功能有效利用计算机资源（包括内存大小、CPU占用时间等）的程度，局部资源占用高通常是性能瓶颈存在；系统可承受的并发用户数、连接数量等，需要考虑系统的可伸缩性。兼容性（compatibility），涉及共存和互操作性，共存要求软件能给与系统平台、子系统、第三方软件等兼容，同时针对国际化和本地化进行合适的处理。 互操作性要求系统功能之间的有效对接，涉及API和文件格式等。易用性（usability）：对于一个软件，用户学习、操作、准备输入和理解输出所做努力的程度，如安装简单方便、容易使用、界面友好，并能适用于不同特点的用户，包括对残疾人、有缺陷的人能提供产品使用的有效途径或手段（即可达性）。可靠性（reliability）：在规定的时间和条件下，软件所能维持其正常的功能操作、性能水平的程度／概率，如成熟性越高，可靠性就越高；用平均失效前时间（Mean Time To Failure，MTTF）或平均故障间隔时间（Mean Time Between Failures，MTBF）来衡量可靠性。安全性（security）：要求其数据传输和存储等方面能确保其安全，包括对用户身份的认证、对数据进行加密和完整性校验，所有关键性的操作都有记录（log），能够审查不同用户角色所做的操作。它涉及保密性、完整性、不可抗抵赖性、可审核性、真实性。可维护性（maintainability）：当一个软件投入运行应用后，需求发生变化、环境改变或软件发生错误时，进行相应修改所做努力的程度。它涉及模块化、可复用性、易分析性、易修改性、易测试性等可移植性（portability）：软件从一个计算机系统或环境移植到另一个系统或环境的容易程度，或者是一个系统和外部条件共同工作的容易程度。它涉及适应性、可安装性、可替换性。2．使用质量从ISO/IEC 25010标准看，软件测试还要关注使用质量，如图1-3所示。在使用质量中，不仅包含基本的功能和非功能特性，如功能（有效与有用）、效率（性能）、安全性等，还要求用户在使用软件产品过程中获得愉悦，对产品信任，产品也不应该给用户带来经济、健康和环境等风险，并能处理好业务的上下文关系，覆盖完整的业务领域。图1-3　使用质量的属性描述为了便于理解使用质量，下面举3个例子。【例1-1】我自己亲身经历的例子。我在手机上安装了一个英语学习软件，自动下载该款软件用到的多个语音库（如新概念英语、六级英语等），它在我讲课时，但并没有判断我手机连接的是Wi-Fi还是3G/4G，造成我的流量大大超过套餐额度，产生了额外的300元流量费。从功能上看，自动下载是一个不错的功能，但有很大的经济风险，在使用质量上有明显缺陷。【例1-2】当我们玩游戏，沉醉于某款游戏，从产品本身质量属性看。是一个好产品，没有问题。但从使用质量看，会有损于玩家的健康，有健康风险，所以需要设置防沉迷功能。【例1-3】当我们使用百度地图、滴滴打车等软件时，往往是在大街上。如果站在人行道或安全地方使用没问题，但是如果一面横穿马路一面还在使用，就有安全风险。这类软件应该给予提示，否则它们要承担相应的风险责任。基于风险的认知因为没有办法证明软件是正确的，软件测试本身总是具有一定的风险性，所以软件测试被认为是对软件系统中潜在的各种风险进行评估的活动。从风险的观点看，软件测试就是对软件产品质量风险的不断评估，引导软件开发工作，进而将最终发布的软件所存在的风险降到最低。基于风险的软件测试认知主要体现在两点上：软件测试不仅仅停留在单个缺陷上，要从所发现的问题看到（分析出）某类质量风险或某个具有潜在风险的区域。软件测试被看作是一个动态的质量监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，及时评估新的风险，设置新的监控基准，不断地持续下去。基于风险对测试的认知，会强调测试的持续性，持续地进行测试，写几行代码就要做测试、实现一个功能就要对这个功能进行测试，开发和测试相伴而行。这种认知特别适合敏捷开发模式下的测试——敏捷测试。在敏捷开发中，软件测试就能被解释为对软件产品质量的持续评估。在敏捷方法中，不仅提倡持续集成，而且提倡持续测试，持续集成实际上也是为了持续测试。基于风险对测试的认知还不断提醒我们：在尽力做好测试工作的前提下，工作有所侧重，在风险和开发周期限制上获得平衡。首先评估测试的风险，每个功能出问题的概率有多大？根据Pareto原则（也叫80/20原则），哪些功能是用户最常用的20％功能？如果某个功能有问题，其对用户的影响又有多大？然后根据风险大小确定测试的优先级。优先级高的功能特性，测试优先得到执行。一般来讲，针对用户最常用的20％功能（优先级高）的测试会得到完全地、充分地执行，而低优先级功能的测试（另外用户不常用的80％功能）就可能由于时间或经费的限制，测试的要求降低、减少测试工作量。基于社会的认知软件不同于硬件，软件一般都是应用系统，常常和人们的娱乐、事务处理、商业活动、社区交流等紧密联系在一起，所以软件具有很强的社会性，所以有必要把心理学、人类学和社会学等引入到软件测试中。软件测试不仅仅是技术活动，而且是社会、心理等综合性活动，软件测试是跨学科的（inter-disciplinary）活动，以系统为焦点（systems-focused），通过不断调查（investigative）和讲故事（storytelling）的方式完成软件质量的评估。通过软件测试的社会性认知，强调测试人员的思维能力和探索能力，强调测试的有效性和可靠性，在测试中要理解用户的行为、人们活动的背景和目的（上下文关系），不断观察，不断学习，发现和质量相关的信息（差异或质疑），从客户利益、业务特性出发来守护产品的价值。也正是由于软件测试的社会性，需要对软件产品的易用性、免于风险的程度、上下文覆盖等进行验证。在易用性测试中，人们常常进行A/B测试，给出不同的解决方案（UI布局、功能设计等），向不同的用户群发布产品，来检测哪个解决方案更受用户喜欢。基于经济的认知一般来说，一个软件产品没有经过测试是不会发布（release）、不会部署(deploy)到产品线上，或者说，不敢发布、不敢上线。因为在当前的开发模式和开发技术情况下，人们开发的软件存在严重的缺陷绝对是大概率事件。如果没有经过测试，就发布出去，可能软件根本不能用、不好用，或者用起来出现各种各样的问题，用户满意度很低，给产品造成负面影响，甚至给客户带来严重的经济损失或影响到用户的生命安全。从经济观点看，软件缺陷会给企业带来成本，这个成本就叫劣质成本（Cost of Poor Quality，COPQ）。基于经济的认知，软件测试就是通过投入较低的保障性成本来降低劣质成本，帮助企业获得利润。高质量不仅是有竞争力，而且是带来良好的经济收益的。例如苹果手机就是以其高质量获得比其他品牌手机更高的利润率。据相关媒体统计数据看，苹果智能手机在高端手机市场只占四分之一，但利润占到一半。测试的经济观点就是如何以最小的代价获得更高的收益，这也要求软件测试尽早开展工作，发现缺陷越早，返工的工作量就越小，所造成的损失就越小。所以，从经济观点出发，测试不能在软件代码写完之后才开始，而是从项目启动的第一天起，测试人员就参与进去，尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。基于标准的认知软件测试被视为“验证（Verification）”和“有效性确认（Validation）”这两类活动构成的整体，缺一不可。如果只做到其中一项，测试是不完整的。“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求相一致，即验证软件实现（即交付给客户的产品）是否达到了软件需求定义和设计目标。“有效性确认”是确认所开发的软件是否满足用户实际需求的活动。因为软件需求定义和设计可能就不对，上述一致性不能保证软件产品符合客户的实际需求，而且客户的需求也是在变化的，当需求定义是半年前确定的，这种变化的可能性就比较大。对验证和确认有不同的解释。简单地说，单元测试、集成测试和系统测试都可以理解为“验证”，都是基于需求定义文档和设计规格说明书文档来进行验证；而验收测试则在用户现场、由用户共同参与进行，可以理解为“有效性确认”，因为之前的需求定义和设计都可能存在错误，研发团队没有正确理解用户的原意（用户的真实期望），仅仅根据需求定义文档和设计规格说明书文档来完成测试，并不能代表所实现的功能特性是用户真正想要的。而在验收测试中，用户参与进来，是可以确认所实现的功能特性是否是用户真正想要的。另一种解释是根据图1-4所示的V模型，验证是架构设计评审、详细设计评审和代码评审/单元测试，分别验证架构设计是否和需求一致、详细设计是否和架构设计一致、代码是否和详细设计一致，用左边带箭头的粗虚线表示。而有效性确认则是集成测试、系统测试、验收测试，如中间带箭头的细虚线表示。图1-4　软件研发的V模型另一种解释是根据图1-4所示的V模型，验证是架构设计评审、详细设计评审和代码评审/单元测试，分别验证架构设计是否和需求一致、详细设计是否和架构设计一致、代码是否和详细设计一致，用左边带箭头的粗虚线表示。而有效性确认则是集成测试、系统测试、验收测试，如中间带箭头的细虚线表示。结语不管你是刚入门的小白、还没入门的群众、已经入门很久的前辈，不满足现在的工作情况，你想升值加薪，想弯道超车，都可以加我的群：903217991，咱们会提供一套专门的测试学习路线规划，带领你实现人生逆袭，财富自由。当然，咱们也有免费的资料可以提供给喜欢自学的小伙伴，所以欢迎大家踊跃加群我会一一为大家通过的。

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~本文由腾讯移动品质中心TMQ发表于云+社区专栏背景随着移动设备和系统的碎片化程度越来越高以及复杂的移动网络情况, 兼容性测试以及远程真机测试的重要性越来越突出。根据远程测试机/人员与开发者间的合作方式，可以分为以下几种服务：云测试服务、内测服务以及众测服务，相应的平台支持如下图。云测试平台云测试平台提供了远程租用真机的服务，通常是利用自动化框架来实现真机上的脚本自动化运行，或远程租用真机人工测试，或真人真机测试。由于Android端设备的种类众多，云测试服务在Android端应用广泛。国内外都提供了多种云测试平台。1、Pefectohttp://PerfectoMobile.comPefecto将真实移动设备放到cloud端 , 并提供通过web/Eclipse插件的形式进行访问与测试。同时，Pefecto开放了基于selenium的第三方API：MobileDriver，支持自动化测试人员通过Eclipse访问Perfecto上的真机设备，通过MobileDriver远程识别与调用被测应用，快速实现自动化，并与 RQM结合实现对devops的支持。测试脚本可以跨平台（Android/iOS/Blackberry…）执行。2、LessPainful http://lesspainful.com/LessPainful提供了一个多设备平台自动化测试的服务。用户上传应用(.apk)和用Cucumber编写的测试文件，选择测试运行需要的设备配置，最后测试将自动执行并生成测试报告。它支持的设备包括Garmin Asus，几款HTC，LG，Samsung Galaxy，Sony Xperia和Motorola Motodefy。3、TestDroidhttp://testdroid.com/Testdroid是由Bitbar公司推出的手机应用测试的云端服务。TestDroid云端提供了200多种机型，你可以选择你需要的测试机型进行适配测试。 通过Testdriod的测试，还能收集CPU运转以及内存使用情况，从而帮助工程师们提高应用的表现性能，和以防内存被过多占用。此外，用户还可以选择测试机型的语言测试环境，避免由于跨语言导致的潜在漏洞。Testdriod还有一项app爬虫功能，类似于网页爬虫，对你的应用高频次地查看并同时进行图像输出，来模拟真实的浏览过程。TestDroid应用了Robotium /MonkeyRunner生成系列工具，但需要有被测应用的源代码。4、Testinhttp://www.testin.cn/Testin云测试平台是一个基于真实终端设备环境，基于自动化测试技术的7x24云端服务。Testin在云端部署了300多款1000多部测试终端，并开放这些智能终端给全球移动开发者进行测试，开发者只需在Testin平台提交自己的App应用，选择需要测试的网络、机型，便可进行在线的自动化测试，无须人工干预，自动输出含错误、报警等测试日志、UI截图、内存/CPU/启动时间等在内的标准测试报告。支持Android与iOS，业务较为全面。5、百度MTChttp://mtc.baidu.com/MTC是百度云面向移动和web开发者提供的服务，能够满足一般的测试需求，包括当前的热门机型，还支持云端客户端回放。它还提供一个云众测服务，就是开放者上传App，百度提供给用户下载测试，然后将反馈收集返回给开发者。6、腾讯优测http://utest.qq.com/腾讯优测试专业化的移动云测试平台，为广大开发者提供移动应用一站式测试服务与解决方案。提供缺陷分析、应用测试、云手机等主要功能，用户通过平台上传安装包，就可进行全面的兼容性和性能测试，还并可以在线使用多台云端真机，满足更多开发和测试需要。腾讯优测真机实验室目前已配备上千款手机，覆盖市面98%主流机型，724小时在线运行，覆盖亿级用户。构建的数万个适配问题特征库，可以快速准确定位问题。7、阿里MQChttps://mqc.aliyun.com/MQC是阿里移动质量中心推出的真机测试服务的云平台，拥有大量热门机型，提供7x24全天候服务。MQC可以涵盖Android、iOS、YunOS、H5等不同的平台体系，主要服务阿里系和阿里内部如手淘、天猫、聚划算、支付宝等App。8、易测云http://www.yiceyun.com/易测云由国内知名软件公司东软出品，是一个专业为移动APP产品提供适配测试、性能测试、遍历测试、功能测试等多种服务的真机自动化云测试平台，主要为所有移动APP产品的开发者和测试者、以及需要定制化服务的企业级用户，提供安全、专业、高效、易用的自动化云测试服务；强大的录制脚本插件；详细实用的测试报告；以及简单人性化的操作体验。关于云测试平台对比分析的文章已经很多，这里不作赘述。众测平台众测的目的是利用大众的测试能力和测试资源，在短时间内完成大工作量的产品体验，第一时间将体验结果反馈至平台，再由平台管理人员将信息搜集，交给开发人员；同时是从最前端用户拿到的第一手信息，就能从用户角度出发，改善产品质量。1、uTesthttps://www.utest.comuTest是一家来自以色列的创业公司，该公司主要的业务是通过自己构建的一个全球测试员网络为开发人员和技术公司提供软件测试以帮助这些开发人员更好的找到并解决软件中的问题。拥有来自200多个地域国家超过15万专业测试人员。根据测试人员数量的不同，收费也各异，最低499美元，最高可达1999美元。uTest提供了uTest课堂提供了专业软件测试者授权课程的学习使用方法，还提供了工具平台供测试人员提交测试工具或对已有工具评分。总之，uTest给专业测试人员提供了一个社区的氛围。很多大公司都在使用uTest的服务，包括谷歌、微软、Groupon、AOL和BBC等。要想参与uTest测试任务，需要注册并提供详细的测试环境，比如测试机型、测试工作经验、软硬件环境等信息，便于uTest高效分配任务。2、腾讯teslyhttp://tesly.qq.com/腾讯众测是腾讯公司开发的一款基于众包概念的平台。支持应用、游戏、H5混合应用等。多种产品形态，具有Bug探索、产品调研、数据收集和产品评测四种业务模式。3、百度众测http://test.baidu.com.cn/crow…百度众测也是众包模式的典型应用，它将企业产品的相关测试工作交由网络社区大众来完成。百度众测是百度公司开发的众包在软件和产品测试上面的延伸。百度众测“隶属”百度质量部，是一个使广大的互联网用户能够第一时间体验到百度的新产品，从用户体验的角度出发，对百度的新产品提出改进建议，以及各种bug反馈，以便于百度公司及时地改善产品质量。目前，百度众测包括“外部用户测试平台”，“内部员工测试平台”和“开发者平台云众测”。注册用户达到1500万。4、testinhttp://zc.testin.cn/ http://www.mtestin.com/为开发者提供一种完全开箱即用、按需付费的SaaS服务，不仅提供了测试规划、功能测试、兼容性测试、可用性测试、Beta测试等测试服务，开发者还可以直接使用Testin众测平台的Bug管理、用例管理、项目管理、崩溃监控等在线工具，帮助中小开发者无需招聘专业的测试团队也可以轻松将应用质量管理好。5、乌云众测http://ce.wooyun.org/乌云众测是另一种众测类型，是在专业性很强的领域——安全领域深入的一种众测模式，它对众测人员的专业性要求很高，俗称“白帽子”。在乌云众测，企业可在短时间内组建虚拟的安全团队，通过邀请顶尖白帽子模拟黑客对网站、系统或产品进行测试，企业可迅速排查各种安全隐患。同类型的众测公司还有漏洞盒子、Sobug白帽众测，他们是目前国内最大的三家安全众测平台。众测平台总结：众测平台可以分为三种类型, 一种是大众任务型, 主要利用数量来收集数据或模拟特殊情境,如不同网络环境等, 百度众测和腾讯bugly都属于这一类; 第二类是以具有专业知识的测试人员来定向完成任务的模式, 这类的代表是国外的uTest和国内的Testin；第三类是应用于对测试人员专业度要求更高的某类业务——目前主要是安全业务——的模式, 著名的乌云众测、漏洞盒子、Sobug白帽众测就是利用白帽子的“攻”的水平来实现“防”的目的的。内测平台内测平台允许开发者选择合适的测试人员，并允许其与测试人员进行沟通。IOS应用分发多采用这种方式，以苹果收购的TestFlight为代表。这种模式操作起来稍微繁琐，如果是iOS应用的话需要制作特殊的内测版本，获取内测设备的UDID并制作证书，并且有100人的人数限制。1、TestFlighthttps://developer.apple.com/t…TestFlight提供了iOS App测试分发服务，它主要解决的是iOS应用测试分发困难问题，可向指定的人分发应用，双方需要注册TestFlight账号，以及下载TestFlight App，即可在App里测试应用。TestFlight已被苹果收购，因此其UDID证书限制人数可达到1000人。2、HockeyApphttps://www.hockeyapp.netHockeyApp是以TestFlight的替代者的身份出现的，其集成了TestFlight的所有优点，同时增加了自己的一些亮点功能，比如支持更多的平台，服务稳定性也比TestFlight高，并且能够通过SDK方式帮助开发者获取必要的测试信息。HockeyApp被微软收购，是收费应用。 3、Fir.imhttp://fir.im/Fir.im全名Fly It Remotely ，是一个为移动开发者服务，针对应用开发内测阶段，提供应用托管分发，崩溃分析以及反馈收集等一系列帮助开发者提高开发测试效率服务的平台。它提供了开放API，开发者可以将fir.im集成到开发流程中。此外，fir.im还提供了指令工具CLI， 日志查看工具LogGuru、崩溃分析工具BugHD和网速测试等工具。Android端还提供了AndroidStudio插件，方便Android开发者上传应用。4、蒲公英https://www.pgyer.com/蒲公英也提供了面向IOS和Android平台的内测托管和任务分发服务，同样提供开放API。 它提供了移动端SDK用于应用内测数据收集分析、版本更形提示、数据分析统计等多种功能。除此之外，它还提供了专家测试的选项，提供人工遍历测试，IOS审核加速等服务。并且，蒲公英提供了测试管理的平台，使得开发者在单平台上做到收集内测用户问题并得到问题分析。5、Bugly http://bugly.qq.com/Bugly 是腾讯对外开放使用的移动应用崩溃检测服务，同时支持iOS和Android平台。移动开发者在自己的App中接入Bugly的SDK后，就能在应用崩溃后获得信息上报。目前还推出了内测分发服务，但还没有提供收集用户测试结果的方法。内测平台总结：国内的内测平台都还属于起步阶段，更多应用场景在于帮助IOS应用快速发布。远程移动测试平台正在向综合云测、众测、内测甚至远程数据收集工具的方向发展，比如国内领先的Testin平台，在云测、众测攻占城池之后，也推出了内测平台https://pre.im/。蒲公英平台则在内测的基础之上，将bug管理融入平台。读者互动环节你工作中还有用到其他测试平台吗，期待你能给大家分享一下。问答如何并发JUnit测试？相关阅读Android单元测试kafka安装与测试性能测试知识总结 【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识