摘要：企业管理人员在做绩效考核时，如何对测试团队中成员的测试工作效率予以界定和考评，是个很值得讨论的问题。因为关系到员工的切身利益，所以要做到公平公正，还需要不断的进行探索。 前言：绩效考核和测试人员测试效率两个具体是否需要进行联...
在一些软件大会上，人们常常会问这样一个问题：测试人员与开发人员的比例究竟多少是合理的？而这样的问题，很难直接给出一个答案。为什么会有这样的问题，可能来自于两方面的压力： 许多公司领导总是希望得到一个合理的比例，然后按这个比例分配招...
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁。 回归测试包的选择：软件生命周期中，即使一...
同行在来信中提到的问题现象是： 问题现象1：测试完成后，出现需求变更（如：增加、修改、删除），此时的测试该如何做（如：测试执行该如何做、测试文档该如何写）？ 问题现象2：开发人员和用户直接交互，出现需求变更，开发修改后没有经过Q...
真正决定测试停止的是什么？是软件自身的质量！只有当软件达到一定的质量要求时才可能被发布！ 这句话还是蛮有技巧的，一定的质量，本身就是一个弹性的概念，基于测试成本考虑测试要在恰当的时间终止。很自然的想起公司的项目发布规则。相对的，项...
曾经看过一篇文章题目头叫做soa测试人员的恶梦？我在阿里软件从事Saas软件试一年多了，之前也在传统软件多年从事传统软件的测试和开发工作。也想针对Saas软件的特性探讨一下，软件测试人员如何根据Saas软件的特性，寻找到其中的需求点，找到其中的机遇...
对于出色技术团队的关键要素可以从下图中找到。下面让我来对其进行解读。 这幅图首先映入眼帘的是，它是一个三角形，而其顶点则是求精。求精离不开下面三个要素的支持，即分享、责任和合作。求精应是技术团队所追求的最高目标，只有拥有求精的精...
以前也经常看一些文章，谈到测试多么多么的重要，其实对于重要性来看，自己也已经略有了解，只是一直以来对如何采用单元测试，编写测试样例之类还没有太深的感触，直到手头的项目再一次面临结项的时候…… 这个版本已经是第三个版本了，前面的两个...
我对这句话的理解是： 1）任何一次提交新的代码都需要添加针对这些新功能的测试用例 2）无论设计函数还是类，对外暴露的接口都应该做到明确，清晰，不会给人模棱两可的感觉，提供的功能点尽可能的单一，doonething，doitwell。 简而言之...
1. 测试过程中不加思考的机械性测试执行。测试就像建筑一样，先打好图纸，然后在施工。测试的过程中应该多思考，而不是闷头呆板的执行。测试的过程中，虽然我们宏观上有三轮的指导，但是我们应该将任务加以细化，具体到功能模块，每天分配合理的任务量...
这个问题在每一本测试书上都有提到，光拿出来列也没多大意思，就归纳一下吧： 1、组织级的强制退出： - 项目中止，通常是项目出现了严重的问题或人力不可抗拒因素 - 经费用尽，通常是项目经费没有得到很好的控制，弹尽粮绝，这种情况现...
测试计划 最近在一个接一个的做项目，每做一个项目都有不同的感受，我想按照测试计划，测试设计，测试执行三个方面梳理一下，和大家谈谈感受 。 最初做测试计划的时候会根据测试工作量来估评测试时间和资源，然后对三轮测试的时间点做一个细...
1、明确项目背景 ● 项目刚刚启动要明确以下几个问题： 大概何时开始&结束，关键时间点或者说里程碑是何时？ 大概需要多少人，需要什么样的人？咱有什么样的人？ 需要什么样的技术支持？是否需要前期学习和调查？...
软件项目从开始到结束，始终都贯穿着频繁的沟通。但是一个很普遍的现象就是沟通成本往往会远远超出了预期，从而大大降低了工作的效率。 认识沟通成本 沟通是必须的，但是沟通存在“巨大”成本。这个成本表现在： 1. 沟通无法实现100%的...
问题描述：测试人员驱动开发人员，可否？ 精彩答案： 会员 rolei ： 1、测试和开发什么关系？ 独立？依赖？ 合作，才是正道。 软件过程发展了这么多年，每一个岗位的职责定义已经很详尽，如何何作也有详细描述。 为什么执...
为什么要进行基于需求的测试？ 对于测试人员而言，有个老生常谈，但不争的事实，那就是：测试人员最重要、最根本的职责和使命是在软件生命周期中保证软件产品质量满足客户需求。 所以，测试组采用RBT会使测试更加有效，因为它使测试专注于质...
什么是静态测试？ 起初的时候，我并不知道什么基于需求的测试，只知道静态测试。 静态测试，很多测试书籍中的定义是：相对动态测试而言，不需要运行代码，针对文档进行的测试。我们知道，一份软件产品包含三个部分，其一是代码，其二是数据，...
这一篇文将结合一个案例谈谈解决随机BUG的一些经验。我这里说的随机BUG是指那些你没法通过一些确定的步骤可靠地重现的BUG。我想做软件开发的人都会同意，即使不是最难，随机BUG应该也是最难解决的BUG类型之一。有人也许说，只要找到问题的根源就一定能...
