㈠ 请问各位大侠，Web测试和App测试有什么区别
Web测试和App测试区别为：监测不同、更新不同、回归测试不同。
一、版监测不同
1、Web测试：Web测试需监测响应时间、权CPU、Memory。
2、App测试：App测试除了需监测响应时间、CPU、Memory外，还需监测 流量、电量等。
二、更新不同
1、Web测试：Web测试只要更新了服务器端，客户端就会同步会更新。
2、App测试：App测试更新需要手动更新客户端。
三、回归测试不同
1、Web测试：Web测试不需要进行回归测试。
2、App测试：App测试所有核心版本都需要进行回归测试。
㈡ 如何去测试一个 app 是否存在安全问题
身为测试答一个，这类安全性测试，是app专项测试中必须要做的一环，简单列举下目前常做的测试类别1. 用户隐私检查是否在本地保存用户密码，无论加密与否检查敏感的隐私信息，如聊天记录、关系链、银行账号等是否进行加密检查是否将系统文件、配置文件明文保存在外部设备上部分需要存储到外部设备的信息，需要每次使用前都判断信息是否被篡改2. 文件权限检查App所在的目录，其权限必须为不允许其他组成员读写3. 网络通讯检查敏感信息在网络传输中是否做了加密处理，重要数据要采用TLS或者SSL4. 运行时解释保护对于嵌有解释器的软件，检查是否存在XSS、SQL注入漏洞使用webiew的App，检查是否存在URL欺骗漏洞5. Android组件权限保护禁止App内部组件被任意第三方程序调用。若需要供外部调用的组件，应检查对调用者是否做了签名限制6. 升级检查是否对升级包的完整性、合法性进行了校验，避免升级包被劫持7. 3rd库如果使用了第三方库，需要跟进第三方库的更新
㈢ 软件测试包含什么内容啊
软件测试的工作内容主要包括“验证”和“确认”，具体内容如下。
一、验证：保证软件正确地实现了一些特定功能的一系列活动， 即保证软件以正确的方式来做了这个事件。
1、确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程。
2、程序正确性的形式证明，即采用形式理论证明程序符合设计规约规定的过程。
3、评审、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
二、软件测试的主要目标
1、发现一些可以通过测试避免的开发风险。
2、实施测试来降低所发现的风险。
3、确定测试何时可以结束。
4、在开发项目的过程中将测试看作是一个标准项目。
参考资料来源：网络——软件测试
㈣ 软件测试大概分为几个方向零基础学习的话需要多长时间呢
软件测试大体上可分为自动化测试、性能测试、接口测试、功能测试等几个方向。
零基础学习的话，取决于你所学的内容，大致需要2-4个月。
但你需要知道的是：
从目前招聘网上企业发布的招聘信息总结来看，传统的手工测试和基础的功能测试、性能测试人员岗位需求不是很多，且就业薪资不是很高（除非你很精通某一类测试，高级测试人员级别）。
你应该学习的内容：
1、测试基础、计算机基础、测试理论、Linux操作系统-CentOS、计算机网络、shell脚本、数据库-MySQL+Redis、APP专项测试、应用框架等
2、Python基础语法、Python高阶语法、Python+selenlum实现web自动化、web自动化测试框架搭建
3、http协议详解与接口的基本概念、Python+requests实现接口自动化、JMeter工具详解、使用postman工具测试接口、接口自动化框架搭建、性能测试-JMeter
以上课程内容， 完全根据企业用人需求进行制定，你想要，咋们也能免费为你提供！希望能给想要入行的各位小伙伴，带来一点点光亮！
㈤ 如何针对app crash进行专项测试，测试中用到了哪些辅助工具
一、如何获得crash日志当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息（低内存闪退日志例外），对于开发人员定位问题很有帮助。如果设备就在身边，可以连接设备，打开Xcode – Window – Organizer，在左侧面板中选择Device Logs（可以选择具体设备的Device Logs或者Library下所有设备的Device Logs），然后根据时间排序查看设备上的crash日志。这是开发、测试阶段最经常采用的方式。如果应用程序已经提交到App Store发布，用户已经安装使用了，那么开发者可以通过iTunes Connect（Manage Your Applications – View Details – Crash Reports）获取用户的crash日志。不过这并不是100%有效的，而且大多数开发者并不依赖于此，因为这需要用户设备同意上传相关信息，详情可参见iOS: Providing Apple with diagnostics and usage information摘要。考虑到并不是所有iphone用户都允许自动发送诊断报告（crash日志），而且对于部分提交到Apple得crash日志，开发者还需要手动去拉取，然后找到对应的符号文件进行解析——这是一件很繁琐的事情。所以实际项目开发中，通常接入现有的crash收集工具（参考1，参考2），或者自己编写一个进行自动化收集、解析和统计汇总。二、如何解析crash日志当获得一份crash日志时，我们需要将初始展示的十六进制地址等原始信息映射为源代码级别的方法名称和代码行数，使其对开发人员可读。这个过程称为符号化解析。要成功地符号化解析一份crash日志，我们需要有对应的应用程序二进制文件以及符号（.dSYM）文件。如果处于开发调试阶段，通常Xcode都能匹配到crash日志对应的二进制文件和符号文件，所以能够帮我们自动解析。如果处于测试阶段，测试人员已经安装了不同的版本（比如alpha、beta版本），那么需要保存好对应版本的二进制文件和符号文件，以便在应用程序崩溃时对crash日志进行解析。对于这种场景下产生的crash日志，只需要将.crash文件、.app文件和.dSYM文件三者放在同一个目录下，然后将.crash文件拖放到Xcode – Window – Organizer中左侧面板Library下的Device Logs中，即可进行解析。如果要提交发布，那么我们通常会先执行Clean，再Build，最后通过Proct – Archive来打包。这样，Xcode会将二进制文件和符号文件归档在一起，可以通过Organizer中的Archives进行浏览。这里是一份关于如何解析crash日志的讨论：http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports 。三、如何分析crash日志在分析一份crash日志之前，如果开发人员对于常见的错误类型有所了解，那定是极好的。crash日志的产生来源于两种问题：违反iOS策略被干掉，以及自身的代码bug。1. iOS策略1.1 低内存闪退前面提到大多数crash日志都包含着执行线程的栈调用信息，但是低内存闪退日志除外，这里就先看看低内存闪退日志是什么样的。我们使用Xcode 5和iOS 7的设备模拟一次低内存闪退，然后通过Organizer查看产生的crash日志，可以发现Process和Type都为Unknown：而具体的日志内容如下：第一部分是崩溃信息，包括识别标识、软硬件信息和时间信息等。第二部分是内存页分配信息，以及当前占用内存最多的进程，上图中为crashTypeDemo。第三部分是具体的进程列表，描述着每个进程使用内存的情况以及当前状态。在较早的版本中可以在某些进程后面看到“jettisoned”字样，表明这些进程使用过多内存被终止了，而现在我们看到的是“vm-pageshortage”字样。当iOS检测到内存过低时，它（的VM系统）会发出低内存警告通知，尝试回收一些内存；如果情况没有得到足够的改善，iOS会终止后台应用以回收更多内存；最后，如果内存还是不足，那么正在运行的应用可能会被终止掉。所以，我们的应用应该合理地响应系统抛出来的低内存警告通知，对一些缓存数据和可重新创建的对象进行释放，同时要避免出现内存泄露等问题。低内存闪退是由iOS策略决定终止应用程序运行的，同样基于iOS策略的还有Watchdog超时和用户强制退出。1.2 Watchdog超时Apple的iOS Developer Library网站上，QA1693文档中描述了Watchdog机制，包括生效场景和表现。如果我们的应用程序对一些特定的UI事件（比如启动、挂起、恢复、结束）响应不及时，Watchdog会把我们的应用程序干掉，并生成一份响应的crash报告。这份crash报告的有趣之处在于异常代码：“0x8badf00d”，即“ate bad food”。如果说特定的UI事件比较抽象，那么用代码来直接描述的话，对应的就是（创建一个工程时Xcode自动生成的）UIApplicationDelegate的几个方法：所以当遇到Watchdog日志时，可以检查下上图几个方法是否有比较重的阻塞UI的动作。QA1693举的例子是在主线程进行同步网络请求。如果我们是在公司的Wifi环境下使用则一切顺利，但当应用程序发布出去面向很大范围的用户，在各种网络环境下运行，则不可避免地会出现一片Watchdog超时报告。另一种可能出现问题的场景就是数据量比较大的情况下进行的数据库版本迁移（同样是在主线程上），这也是促使我写这篇总结的一个直接因素。
㈥ app测试流程是什么
移动App的测试流程与传统软件的测试流程大体相同，在测试之前分析软件需求并对需求进行测试，需求测试完成后制订测试计划等，但移动App测试的要点与传统软件测试要点不同，因此在具体实施细节上也不相同。
移动App测试基本流程如下
(1)接受测试版本：由开发人员提交给测试人员。
(2) App版本测试：主要检查App开发阶段对应的版本是否一致。
(3)UI测试：检查App界面是否与需求设计的效果-致。
(4)功能测试：核对项目需求文档，测试App功能是否满足客户需求。
(5)专项测试：对移动App进行专项测试。
(6)正式环境测试：模拟实际使用环境进行测试。
(7)上线准备：测试通过后，对测试结果进行总结分析，为App上线做准备。
移动App开发完成后，提交给测试人员。测试人员首先对当前App版本进行检查，通过后进行基本的UI测试，检查界面效果是否与需求设计相符合，之后依据需求文档进行功能测试，完成这些工作后进行专项测试等。最后在实际运行环境中进行测试，测试通过后做上线准备工作。
㈦ 手机app如何全方位测试
安全性测试，是app专项测试中必须要做的一环，简单列举下目前常做的测试类别：1. 用户隐私检查是否在本地保存用户密码，无论加密与否检查敏感的隐私信息，如聊天记录、关系链、银行账号等是否进行加密检查是否将系统文件、配置文件明文保存在外部设备上部分需要存储到外部设备的信息，需要每次使用前都判断信息是否被篡改2. 文件权限检查App所在的目录，其权限必须为不允许其他组成员读写3. 网络通讯检查敏感信息在网络传输中是否做了加密处理，重要数据要采用TLS或者SSL4. 运行时解释保护对于嵌有解释器的软件，检查是否存在XSS、SQL注入漏洞使用webiew的App，检查是否存在URL欺骗漏洞5. Android组件权限保护禁止App内部组件被任意第三方程序调用。若需要供外部调用的组件，应检查对调用者是否做了签名限制6. 升级检查是否对升级包的完整性、合法性进行了校验，避免升级包被劫持7. 3rd库如果使用了第三方库，需要跟进第三方库的更新
㈧ app测试和web测试的区别， web测试和app测试的区别
一、测试方式不同
1、app测试：指对移动应用进行测试，包括自动化测试版和人工测试等。权
2、web测试：是软件测试的一部分，是针对Web应用的一类测试。
二、测试内容不同
1、app测试：模拟用户操作对应用程序进行黑盒测试，并使用Cucumber作为自然语言来编写测试用例。还会对应用测试操作进行记录，以帮助开发者进行测试回顾。
2、web测试：包括内容测试、界面测试、功能测试、性能测试、兼容性测试、安全性测试等。
三、特点不同
1、app测试：可通过增加预先测试环节来确认环境已经测试就绪，同时还能知道哪些错误是环境不稳定引起的，哪些是一般的测试用例错误。
2、web测试：通过测试可以尽可能地多发现浏览器端和服务器端程序中的错误并及时加以修正，以保证应用的质量。
㈨ APP测试的关注点都有哪些
APP作为WEB产品之外的另一大类型的产品，我们往往需要关注以下两方面的测试点：首先测试小伙伴必须将目光聚焦在APP产品本身的功能性需求；其次我们应当将重点关注在APP产品的专项测试，如兼容性测试、安装、卸载、升级测试，交叉事件测试、push消息推送测试、性能测试、用户体验测试、边界测试、权限测试等。APP测试，我之前不懂的内容都是看黑马程序员社区，社区里面有很多关于软件测试的文章，文章内容都还不错的。
㈩ 软件测试是如何分类的有多少种
测试人员一般分为如下三种（当然还有很多其它的分类方法，如感兴趣可以再查找）：黑盒测试：黑盒测试，指的是把被测的软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。主要是针对软件界面和软件功能进行测试。 白盒测试：白盒测试，指的是完全了解产品的源代码和程序结果。按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作 灰盒测试：灰盒测试介于黑盒测试与白盒测试之间。可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。 这三种测试方式各有各的优点，楼主可以根据需要去选择——“搜狗测试”
