三、漏洞利用 在这个阶段，测试者必须制定测试计划，其目的是为了对源代码进行深入分析，查找是否存在常见的不安全编码方法。然后，重点检查移动应用的特定安全机制。测试者还要查找、检查代码中的架构安全问题。 验证所确认的问题 测试团队要分析来自漏洞扫描的结果，去掉那些似是而非的信息，并着手构建可利用漏洞的案例。 利用移动应用的独有功能 灰盒测试方法的主要好处是能够最大限度地利用漏洞。在此阶段中，测试者要尝
二、漏洞确认 在应用程序的评估过程中，应当重点检查前一阶段所确认的热点源码。除了要检查源代码检查不易发现的应用程序漏洞，企业还应当执行黑盒类的评估，用以确认网络或主机层的漏洞。为了补充应用程序组件的人工检查，这个测试阶段应当采用自动化的扫描。 代码分析和扫描 自动化扫描工具可以分析全部源代码，从而初步发现安全问题。在此阶段，测试者应当利用商业类工具和私有工具来扫描有安全问题征兆的代码和可导致漏洞的
所谓移动设备应用的灰盒测试是指，将传统的源代码检查(白盒测试)与前期测试(黑盒测试)结合起来的一种技术。测试人员必须检查应用程序的代码库，审查关键功能代码，审查常见的错误编码或非法编码方法。此外，测试人员还可以执行黑盒测试来审查应用，并根据所确认的漏洞定位找到代码库中的目标代码。 为什么要执行移动应用的灰盒测试与评估呢?答案很简单：找到高风险代码;确认漏洞的根本原因。 灰盒测试应当遵循如下三大步骤
XSS漏洞按照攻击利用手法的不同，有以下三种类型： 类型A，本地利用漏洞，这种漏洞存在于页面中客户端脚本自身。其攻击过程如下所示： Alice给Bob发送一个恶意构造了Web的URL。 Bob点击并查看了这个URL。 恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在Bob电脑上。 具有漏洞的HTML页面包含了在Bob电脑本地域执行的JavaScript。 Alice的恶意
微博上抛出一个讨论话题：下午一test lead问到，有些测试的 bug会在A版本里出现，然后记录它；但开发人员在当前B版本试图重现时发现不能重现，故reject它。那么测试就郁闷了，待到下一轮回归测试可能是C 版D版本，如果再出现自然reopen，但如果不复现是否真的应该关掉它吗？各位对这种sometimes bug怎么处理的啊？ 这个问题可能每个测试人员都会遇到，我说说我个人观点，供大家
继续深挖一下开发测试比的问题。如果一个公司说，我们今年的开发测试比要达到5:1，或者7:1，甚至10:1，目的是什么呢？可能是为了缩短项目周期，节约交流成本，提高开发的质量意识，大家是否同意？那么我们就这几个目的，谈一谈提高开发测试比是否能够达到这些目的。首先，提高开发测试比，只是提高开发人员和测试人员的比例，并不是提高了开发工作和测试工作的比例，对不对？测 试工作花费的时间并没有因为开发人员做测
在现在的公司里，常常会听到开发测试比这个词。这个词也许很多老大的理解是：开发人员个数和测试人员个数的比例。一次高P开会的时候，我记得一个技术团队的老大曾经说过，开发测试比嘛，当然是越高越好。那好，作为一名一线的测试人员，我想谈谈我对开发测试比的一个理解。首先，我要问，为什么要有测试呢？测试的目的是什么？记得有一本书里曾经说，有一个硬件人员转去做软件，他写的代码从来都没有bug，后来有人问他为什么写
不久之前，我们的一个程序员疯了，而且疯的很有气势， 他走进经理的办公室大喊大叫，说着一些奇怪的东西。 如果我不是像了解自己一样了解他，我会以为他是嗑了药。 但实际上他并不是短暂的精神失常。 他是我在编程业界里见过的最勤奋的程序员。他经常晚上在公司加班， 当周末有紧急工作要处理时，他总能随叫随到。目前这个阶段公司并不挣钱， 老板希望项目能尽可能往前赶，于是，任何客户急催的任务都会自动的分配到他那里。
周末抽空看完了“中国合伙人”，不得不说看完了还是有很多共鸣，正面的负面的，很多很多。我听说很多人去电影院看完了之后都站起来鼓掌。是的，我们需要鼓掌，仅仅是为了他们的成功，他们的坚持。但是我们还需要深入的去思考，我们这一代中很多创业者往往觉得我们能够体会，能够理解，能够坚持，能够熬过去，但是真正体会的时候却是另外一番滋味。 我自己毕业以来，所待的全部是创业公司，人数从10人
从前面的描述，我们可以看到， 性能测试的参数， 输入场景， 关键性能指标都是和性能测试的目的密切相关。 比如， 为了验证是否满足一个重要客户的性能要求， 性能测试可以很复杂， 测试环境包括应用服务器Cluster， DB Cluster， 专用的存储服务器，测试耗时一个月； 为了验证是否在版本之间有性能下降， 性能测试也可以很简单， 所有软件都部署在同一个机器上， 且测试集成在DailyBuild
