model

Just seen a movie named "Bridge to Teribithia", it is a good one, simple, touching, and relax.

In children's eyes, everything is so good, just using their powerful imagination. The things are really different, if you change the way to look at the world. In everyday's life, people are working under big pressure, and they become unhappy, even if th...

是否立项，不是我们拍出来的，我们需要广泛的调研。

首先了解行业背景知识，然后分析市场与用户，知道这个蛋糕目前多大，将来可能会有多大。现在都有哪些player，他们各自的优势有哪些？我们能否进入市场，我们的优势有哪些？

然后分析进入的风险，哪些东西是有准的，哪些东西是没准的，如果都没准，而且是短期行为，那干脆就不做了，否则只有交学费的份；如果是长期的投资，那就另当别论。

美国人真的很擅长做市场调研与分析。从问题出发，做定量的分析；寻找大量的数据作为支撑，如果没有现成的，就自己冲过去做调研，哪怕做基本的问卷调查。然后站在不同角度，做各种分析，得出结论。当问题清楚后，再调研市场，调查现有的产品及其问题，定位自己将研发产品的卖点，预计自己产品对于用户的价值，如果不清晰，必要时做一个原型，进一步调研（前后的差异）。形成产品后，一方面推向市场，另一...

不知不觉，发现自己已经从测试走到了评估，并且慢慢的走向标准的开发。

在一次次决策中，不再只考虑兴趣，而更关注工作的价值。为了高价值的东西，我们有时不得不放弃一些自己擅长的技能，而那可能是“化蝶”的必由之路。别人为你提供薪水，也是看重了你的价值，看重了你能够给公司带来更多的回报。工作角色不同，价值不等，所需技能也不一样；将大脑清空，让有限的记忆存放更值得的内容，虽然知道“放下”比“拿起”更加的困难。

清空不是绝对的，它将留下必要的东西完成现在的任务。复用是要坚持的，懂知识、有经验而不用，等于没有知识。复用，对于high level的知识可以直接完成；但对于low level的知识，则需要refine后完成。

舍弃并复用，还要选择，快速的知道自己该学什么，这是水平。搞清...

测试被大家认为是旁门左道，主要因为两点：第一测试工作的门槛太低，极端的讲，只要会用键盘和鼠标就可以测试；第二，测试工作的重复性，一次又一次反复的执行，让人们的好奇心与新鲜感一点点的丧失；而最后支持测试工作完成的只剩下责任感。

好，我们想真正的让测试发生一些变化。门槛太低，很难改变，也不去改变。为了解决测试重复性的难题，我们不知不觉想到了测试自动化，也就是利用计算机的技术解决测试的难题。我们想：机器能够完成的就让机器去做吧，将有价值的思考留给有智力的人完成。测试自动化一直是我们追求的目标，很多人也尝试着去做，但终究败下阵来。

我想测试自动化是需要一些条件的。如果一项测试只执行一次，我想手工完成没有什么不好。如果一项测试需要迭代很多次，这也就让“偏爱重复工作”的机器有了用武之地。OK，当满足了最基本的条件之后，我们看看如何让测试自动化工作变得可行。第一条：当然就是编程技能，如果自己没有，就让领导给配备一个吧，逻辑不是很复杂，1－2个人就够用。

最主要的测试逻辑是“比较”，即期望输出与实际输出之间的比较。当然前提是提取出让计算机能够理解的“结果”，用合适的方式进行表示。期间很可能涉及到一些量化的工作，也可以理解成是一次建模的工作。

另外一个让测试自动化的条件是，需要“待测试程序”的配合，需要程序输出一些方便提交的中间结果。格式的设计最好由测试人员一手设计。

以上想的，主要针对黑盒测试的逻辑。白盒测试，如单元测试，已有自己的一套方案。

最后想提一下测试自动化之后的感受：痛苦（创新）一次，受用一生。

1、让对方首先提问——考查提问的能力（软件测试即是不断提出问题的过程）

2、对测试的理解——基本的测试知识，对测试是否认可？

3、谈一谈过去自己的工作——了解经历、提供进一步提问的素材，表达能力

4、了解TDD吗？如何学习？——对新技术的敏感程度、以及学习方法的运用

5、测试技能
。测试设计的方法并举例说明——测试技术的使用
。测试工具——熟悉程度，能否与当前工作匹配？
。如何带领新人？——测试管理技能

6、如何做计划？如何跟踪计划？——日常工作能力

7、如果开发人员提供的版本不满足测试的条件，如何做？——与开发人员协作的能力

8、熟悉unix系统、oracle数据库吗？——是否具备系统知识

9、做过开发吗？写过哪些代码？——开发技能

10、阅读英语文章，给出理解说明？——部分英语能力

11、文档的意义——是否善于思考？（最简单的概念，不同层次的理解...

1、做事有两种方式：
 。第一个：疲于应付，到处救火
 。主动寻找问题，防患于未然

2、人们都喜欢将软件的维护放到软件释放之后做，没错，那是一个很明显的话题；
而想想，其实还有另外一种维护，就是项目的维护，它将在项目的开发过程中完成，维护的内容：
。搜集现象或者数据，充分了解项目当前所处的状态；
。分析当前状态，可能导致的风险，进行下一步风险控制；
项目维护从项目启动后，就要开始，而且由专门的合格人员来做这件事情；其实这就是PM（PSM）的事。

而我们的PSM要不不合格，他压根不了解“该搜集哪些数据”，要不不清楚“搜集哪些数据做什么”，更不知道“怎么做”，那些都是不合格的pm（psm），他们需要培训。

而分离出去的pm角色，他们只想了解进度，知道一些问题，忽略了太多的东西，如：质量，而且往往他们都是一种高高在上的姿态，了解项目的途径也非常的单一，得到的数据没有多大...

1、配置管理的误区
 按照所谓的配置管理过程进行工作，由很多人填一堆表格，格式看上去很优美，好像配置管理做的不错。期间耗用了很多的人力、物力，真的达到效果了吗？还是得不偿失？
 
2、配置管理的目的
 。配置管理的引进，是为了解决问题的；单纯的为了符合某个规范而进行配置管理没有意义
 。配置管理解决的问题是什么呢？先举个例子看看。
 
3、配置问题举例：
 。开发人员A对开发人员B讲：我的接口早已经改了，你的程序怎么还是原来的呢？
 。某版本的测试过程中，开发人员对测试人员讲：我的代码已经修改了，你去cvs checkout新的吧；开发人员对测试人员讲：你的问题在我这无法重现，你测的是哪个版本？
 。开发人员对技术支持讲：xxx省的版本已经找不到了，你去yyy省down一个吧；开发人员讲：我知道了，现场的问题是版本升级错了
 
4、配置管理的本质：
 。当配置项...