WilsonWei的软件测试专栏

昨晚听珠江经济电台的“心灵地图”节目，主持人陈SIR说了句：“这个世界没有公平，唯一可以做的是改变自己”。真的是太经典了！曾经有一位同事在离职前，我们一起去吃饭，他跟我说了很多不公平的事情，如辛苦做了事情，而且同事的评价是很好的，但他的直接领导却没有对他有任何的认可，而且还把一些责任归咎于他，这令他很难接受。作了一番“无用”的努力后，最后他选择了离开。。。。离开对他来说可能是一种逃避或“解脱”的表

 旁述：测试过程中如何应对频繁的版本变更？对于这个问题，其实要视实际的情况，如企业、团队、项目、产品、市场等等多个方面的因素，不能一概而论，所以，解决的办法有多种。今天我没有回答”如何应对“频繁的版本变更这个问题，下面的内容，当作提醒，呵呵。1、为什么会有频繁的变更？2、多少变更可以集成为一个“版本”？测试的对象如何确定？3、从“应对”转为“避免”一、为什么会有频繁的变更？

软件质量的保证付出/回报曲线我就不多说了，我们始终坚持一个原则：在最合适的时间段里做最合适的事情！这是能够解决众多质量管理上的问题的一个有效解决策略。我们通常在代码编写阶段就忽略或者故意地“偷工减料”行为，必定会在以后的产品生命周期内被突显出来。这就导致一个缺陷在产品的生命周期后段被放大若干倍，所带来的维护成本是及时修复的若干倍。目前解决这个问题最好的途径有两种，一种是动态的单元测试，另一种是静态

单元测试其实难在测试策略上,对于一个上百行代码量的软件系统,要完成所有单元模块的测试对于国内大多数企业来说几乎是不可能的.所以,如果制定一个好的,有效的测试策略是至关重要的,也是能够有效地进行单元测试活动的途径!        经过一段时间以来的实践,总结出了以下几个原则:1. 做重点模块2. 做底层模块3. 做使用频率最多的模块具体的事情就不再展开了,等有时间再详细地说一说单元测试经验. 睡觉先

通常是等到情况坏到无可救药时，项目经理才会明白“政治”只是合法的借口。  对于这类项目经理的挫折感，我见过很多不同类型的反应。最常见的一种是项目经理开始对他真正的角色--领导--做出负面的、反叛性的行为，这种行为通常是通过对“政治垃圾”(political bullshit)的厌来表现。除了对科技要有一定的知识之外，软件开发团队的领导人还得具备对人性高度敏锐的观察力，必须能够看出在团队外在行为背后

今晚，我的一位同事跟我谈到软件工程的一些他的观点，他是个追求前沿技术人，而且是个活泼的人！其实他的观点也没错：“1、很多软件不是制造出来的，是创造出来的；”“2、为了文档而文档，管理者又无能力检查文档的真正价值”“3、真正每一个步骤都做到了吗？答案是没有，那么你就失败吧，也怪不得人家软工理论了。”我是比较喜欢务实一些的人，但有时会做出让别人觉得“理想主义”的事情。不可否认，创意在软件行业中可以说是

纵观国内软件测试行业，从2001年开始，测试人员及测试主管经常研究测试用例的编写方法。以为编写了测试用例就可以做好测试工作。其实不然。测试用例只是用来达到测试覆盖和进行测试经验积累的一种手段。      我们部门从2002年开始开始测试用例的编写任务，但直至2004年，测试用例对实际的测试工作并没有带来明显的效果，反而造成工作量上的增加和资源浪费。因为，一直以来，已经编写好的测试用例并没有认真地执

一篇非常不错的管理文章，点点滴滴不罗嗦，给我们联系自身的空间。我喜欢经验，更喜欢浓缩版。现在分享给大家，希望大家喜欢。 一、 素养 蓝斯登原则：在你往上爬的时候，一定要保持梯子的整洁，否则你下来时可能会滑倒。 提出者：美国管理学家蓝斯登。 点评：进退有度，才不至进退维谷；宠辱皆忘，方可以宠辱不惊。 卢维斯定理 ：谦虚不是把自己想得很糟，而是完全不想自己。 提出者：美国心理学家卢维斯 点评：如果把自

"After a slip, hit the next milestone,no matter what"我们必须明白，每一次的延误，就是你和团队信心的一次受挫，所以，延误这个里程碑时，最好的补救办法就是无论如何绝不延误下一个里程碑。团队必须挽回对自己的信心和对理想的承诺；因些，下一个任务必须准时完成的意义更重大，团队需要重建信心。　　你知道进度落后的情形有多严重，也知道是什么原因造成，你知道该如

项目经理是软件开发团队的一份子，他的职责是：×领导大家定义出一个成功的产品。×引导大家对产品注入深切的期望和信念。×带领团队将理想实现，变成可预见的产品诞生。要定义“项目经理是什么”，倒不如从定义“项目经理不是什么”，还比较简单一些。一位项目经理实际所扮演的角色并不是一般人直觉上想到的工作性质而已。　　项目经理并没有（或只有很少的）正式的权力或地位，至少刚开始时是如此，所以项目经理通常会为此感到非

单元测试关注构成软件系统的最小单元：程序员所创建的的函数、类和方法。大多数经理都要求自己的程序员做单元测试，而且程序员也声称做了单元测试。但是在实践中变数非常大，而且很难确认。  真正的单元测试要孤立地测试单元。要创建桩处理对外调用，创建驱动器提供对内调用。构建这些桩需要很大工作量。  自动化单元测试最常见的形式，通过在语境中测试单元来避免开发桩。我们也许可以把它叫做单元集成测试。对于自底向上构建

测试工具并不能教测试员如何测试。如果测试出现问题，则测试工具会加重问题。在实现测试过程自动化之前，应首先解决测试过程中的问题。　　有些测试工具带有测试策略的建议。但是这种建议很少能够描述得很清楚，并不能针对具体情况，而且往往过于强调他们那种自动化测试的重要性。　　我们接触过一些测试经理，他们想采购测试工具，而不是聘用测试员。（我们也接触过一些助长这种思想的工具提供商。）我们从来没有见到这种想法行得

当我在开发一个新的工具软件的时候，在时间的压力下，往往一开始就写代码，虽然对系统的结构模型自己有了初步把握，但一般都没有把这些结构以文档的形式记录下来。在写了一些代码之后，极有可以出现头脑不清晰的问题，比如，经常写着写着就停了下来，不知所措。也不知道自己写到哪个地步了。。。。后来，我尝试着把系统结构图用VISIO画出来，同时也把系统的工作流程图也画出来，发现在写代码的时候，无论从宏观上可以知道自己