什么？这怎么跟平时的风格完全是两个套路？嗯~我就知道各位看官是被标题吸引进来的。人啊就是不知道，自己的命运就是不能预料。我是怎么都想不到我一个做测试的怎么就当起小编了呢？当时领导同志就跟我讲说：“小组已经决定了，由你来发文章”；我说还是另请高明吧，我也实在不是谦虚，但是领导同志就说大家都研究决定了……当时我就念了两句……噢不对，写了这篇文章，就分享给大家。好了，话不多说，上货。这次我们一起讨论一个
前期回归敏捷测试世界里面有一种重要的测试方案：探索式测试。关于探索式测试的定义、基本过程、价值，我们之前有一篇文章已作初步介绍，若有小伙伴感兴趣，详见文章：【敏捷测试】初窥探索测试。那探索式如何测试呢？——探索式测试的指导方法主要有局部探索式测试法和全局探索式测试法，今天小编将了解到的局部探索式测试法分享给大家~~什么是局部探索式测试局部探索式测试法是辅助测试人员在执行测试中即时做出决定，注重指导
bug分析在整个测试阶段是非常容易被忽视的一个点，而就这样的一个被忽视的点真正利用起来之后发现“前辈再也不用担心我掉坑了”学会分析bug，获取更大破解bug的信息，从质量走向卓越1.建立一套分析bug用的工具箱正所谓，“工欲善其事，必先利其器”，分析bug有一套得心应手的工具很重要。我的工具箱里就有：网络抓包工具（用来分析网络相关问题的），读取、解析日志的工具、获取设备运行状态的工具，另外，还配有
今天看到Twitter上的一个帖子，有关科学的，测试也是在一次次地做实验，怎样让测试结果更可靠，也许可以从这个实验环中每一步可以改进的地方思考：文章的原文，比较长，可以快速略读即可：http://www.nature.com/articles/s41562-016-0021摘几段与测试相关的话：Thecombinationofapophenia(thetendencytoseepatternsin
去年写了一篇《容器化时代对测试的机遇》的文章，提到了一些分布式自动化测试和容器化技术结合的架构设想。但是目前来说，分布式运行并不是难点，亟需解决的问题是针对特殊平台和复杂场景下的测试，例如复杂业务场景下iOS平台的自动化测试。移动应用特点是简单易用和UI简洁，以便用户在移动端完成一件事的路径尽可能短。所以一般情况下，我们遇到的iOSAPP场景相对于Web应用要简单一些。所以一般情况下iOS自动化测
jenkinsjenkins是基于java开发的一款持续集成工具，用于监控持续重复的工作，多用于搭建持续集成环境。相信各位测试同学对jenkins并不陌生。monkeyMonkey是google提供的一个命令行工具，可以运行在模拟器或者物理设备中。monkey通过向系统发送按钮、手势、触摸屏输入等伪随机用户事件，对软件进行稳定性与压力测试。从事移动端测试的同学，想必对monkey工具的使用也轻车熟
介绍为方便流媒体服务端的压力测试，向大家推荐一套流媒体的压力测试工具（St-load），希望对从事流媒体测试或者对流媒体感兴趣的同学有所帮助~St-load1.支持RTMP推流测试，一个进程支持500个并发。执行程序：./objs/sb_rtmp_publish2.支持RTMP拉流测试，一个进程支持5k并发。执行程序：./objs/sb_rtmp_load3.支持HTTP负载测试，所有并发重复下载
上周，Versionone发布了第11届敏捷状态调研报告。笔者深夜加班，给大家翻译和解析几个重点。总览企业的敏捷性在迅速发展，并且敏捷遍布各个行业。笔者认为，虽然遍布的行业很广泛，但是参与调研的人也许是这些行业里的IT部门或软件相关项目。敏捷在范围和成熟度上仍旧有很大的提升空间。94%的调研者反馈他们所在的组织实践过敏捷，同时，这些人反映在他们的组织里有超过60%的团队还没有实践敏捷。44%的调研
DevOps方法有时候会被认为是软件测试人员的一个线程，因为它可能是可以缩短测试流程的一个小方法。在这篇文章中，TomGilmore解释了DevOps被认为是软件质保人员的机会的原因，因为它将推动自动化测试的进程。在大多数QA信息论坛上，你会看到自动化测试与手动测试的话题被一次又一次的讨论。我不会参与这些讨论，因为我相信这个压倒性的证据，行业方向和自然规律要求QA去认可，我们应该向自动化测试的方向
为了能够在产品发布前，对产品质量能够做出比较准确的判断，需要清楚质量的属性，这就需要建立质量模型，如McCall质量模型、Boehm模型、ISO9126模型等。传统质量管理更强调过程质量、内部质量，其关系如图1所示，过程质量影响内部质量、内部质量影响外部质量、外部质量影响使用质量，而使用质量依赖外部质量、外部质量依赖内部质量......图1过程质量、内部质量、外部质量、使用质量之间的关系个人认为，
热门文章