已有 183957 人访问
白云 ID.10203
阅读(6)
博客(233)
白云的博客
一.  前言远程测试的优点已经无需赘述，在产品开发项目周期短暂，来回实验室时间及路费成本高昂，用户遍布全国各地难以邀约的情况下，远程可用性测试正在成为“实现传统可用性测试80%好处和70%效果”的最佳替代品。在远程测试的实际可行操作中，第一步所要做的就是搭建一个稳定，安全，且满足测试需求的测试环境。 中文站用研组最近在这方面进行了积极尝试，并得到一定成果。   &nb
406°/4060 人阅读/0 人点赞/0 条评论
   在开篇中提到了屌丝开发和高富帅开发之间有不同，这篇简单论述一下不同点之——屌丝们压力太大。   球迷都知道世界杯决赛不好看，那些平时怎么踢都挡不住的球星到了决赛就找不着门，有时要靠点球决出胜负，伟大的巴乔连点球都踢不进。为啥球星发挥失常？对的，压力。   作为开发人员，要面对时间压力、技术压力、需求不确定性的压力，所有这些都会让开发
305°/3059 人阅读/0 人点赞/0 条评论
    这几天本来在安心写东西，但是无意中就有人转了几篇文章（《我们需要专职的QA吗？》）给我看，言辞恳切的说：“小柴你看看，咱还忙个啥，人家都说，马上所有专职测试都下岗。” 于是我就抽空看了看，嗯，不出意外，又是那些精英们写就的一手好文字，大意就是，开发做测试就足够了，要那么多测试妹子做什么？    好吧，虽然我没有他们那么高端精英，但
391°/3880 人阅读/0 人点赞/3 条评论
       做benchmark测试的过程中，总是会涉及到linux操作系统底层的设置导致无法充分利用机器的性能，在调试的过程中，不少资料没能和linux kernel版本对应上导致一些参数的设置错误。根据现有服务器的硬件条件和软件版本做相关优化，把一些实践的心得分享出来。Kernel version ： 2.6.32-71.el6.x
435°/4340 人阅读/0 人点赞/1 条评论
       左耳朵耗子发表了《我们需要全职的QA吗？》后，一石激起千重浪，赞成者有之，激烈反对者有之；有人说文中对QA的定义不对，还有人说以偏概全……的确，在需不需要专职的QA角色这个问题上，很难用一个简单的“需要”或“不需要”来回答。前两天我写了一篇对该文的回应文章，但由于文章写就得比较仓促，很多观点来不及完整表述，因此，在“真理越辩
316°/3162 人阅读/0 人点赞/0 条评论
    最近一直有写这样一篇文章的想法，因为自己工作的变动，都是些零散的思路和想法，这里稍作整理，贴出来。正好假期的时候有朋友问到这方面的话题，希望也是一个参考。    其实说实话，觉得自己不是很够资格来写这个，毕竟开始做互联网测试的时间不长，很多方面还在摸索和catch up中。但是另一个方面，如果真都习以为常了反倒没有对比的新鲜感了也
389°/3894 人阅读/0 人点赞/0 条评论
1、前言LoadRunner最重要也是最难理解的地方是----测试结果的分析。其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了。针对Results Analysis我用图片加文字做了一个例子，希望通过例子能给大家更多的帮助。这个例子主要讲述的是多个用户同时接管任务，测试系统的响应能力，确定系统瓶颈所在。客户要求响应时间是1个人接管的时间在5S内。2、系统资源2.1硬件环境CPU：
1448°/14484 人阅读/1305 人点赞/0 条评论
需求描述：在OVI地图查找项中，输入完全地址和模糊地址能查找出地址；输入错误地址或不输入地址则提示错误信息或不显示。原因和结果：原因：1-----输入精确地址；2-----输入模糊地址；3-----输入非正常地址；4-----不输入地址；结果：21-----出现地址；22-----不出现地址；23-----给出错误信息；因果图和具有约束的因果图：考虑到原因之间必须有一个且仅有一个为1，因此在因果图
733°/7323 人阅读/70 人点赞/1 条评论
34、刚刚从事软件测试职业，如何快速掌握编写测试用例的方法？该怎样编写测试用例呢？专家分析：1、根据需求文档，完全按照需求文档框架/功能描述，根据自己的理解整理为用例。简单来说，就是将需求文档描述的内容，重新按照用例的格式编辑一次，把能想到的各种可能性添加进去。2、搜索其他测试人员编写的同类型功能用例，先理解，再根据项目实际需求的较小差异，重新新增/删/改，组成满足需求的用例组。快速掌握用例其实没
543°/5422 人阅读/9 人点赞/1 条评论
B/S架构的系统，都会使用如下的基础软件架构：数据访问层：实现对数据的访问功能，如增加、删除、修改、查询数据。业务逻辑层：实现业务的具体逻辑功能，如学生入学、退学、成绩管理等。页面显示层：将业务功能在浏览器上显示出来，如分页显示学生信息等。 在实际项目中，可能会根据情况在业务逻辑层增加层级，对于软件测试，也无非是针对这3层架构进行的测试或者测试过程中都会涉及到这3层架构。 数据访问层： 1. 常出
378°/3789 人阅读/0 人点赞/0 条评论