Backbone.js是什么东西
2012年5月17日 by 大慈大悲大晕僧
Backbone的确是个好东西，他有着很多优点：
- underscore完整实用的编程API支持
- 各类型组件良好的封装接口
- 集合化对象操作，这方面跟underscore配合是神器
- 全事件化操作，发挥JS的优势
- 默认对RESTFUL接口的全面支持与扩展接口
- 对微框架支持很好，主要是jQuery和mootools。 （而且可以随便进行扩展与改写，里面的模块化与解耦是做得很赞的 ）
软件测试中不需要测试的八件事
2012年5月15日 by 大慈大悲大晕僧
不要测试它
做为一名测试人员，我们也许会问我们自己很多问题：
● 我们可以立即执行的最好的测试是什么？
● 我将要使用的测试方法是什么？
● 这是一个Bug吗？
● 我已经测试完成了吗？
但是我们之中会有多少人提出以下的这些问题呢？
● 这个组件需要一直被测试到吗？
● 需要由我来测试它吗？
● 如果它不工作，谁会去在意它呢？
在我看来，我们提出的问题中和以上三个问题类似的还远远不够。可能这是因为我们已经被告知要测试一切东西。甚至我们的一部分人会在其质量团队中有一个流程，要求某个人把每一个组件都贴上“已测试”的标签。我们对待测试就像一个常规的工厂程序，我们甚至有时候引以自豪的说…
“我是测试工程师。因此，所有的东西都需要被测试…由我来做…即使非测试人员已经测试过了…即使我已经知道它将会通过测试…即使需要一个程序员告诉我怎么去测试…我必须测试它，没有例外！”
这类想法可能会让测试人员有一个坏名声。由于欠缺思考的过程导致它强调了测试的重要性，而不是给一些人提供最有价值信息的服务。
James Bach 带着以下的测试观点出现:
基本的观点：“如果它存在，我就要去测试它”
正如前面内容和我经常发布的文章中，我不同意这个观点。尽管如此，我完全同意James 在2006年8月7日，他在博客发布的完整版本中关于这部分的介绍：
“如果它存在，我就要去测试它（唯一的例外是我有更重要的事情要做）”
第二句话是可以有很多的理解方式！为什么呢？因为我们经常会有更重要的事情去做，通常是另外的测试工作！不幸的是，重要性往往不是区分的很明显。所以与其衡量重要性，我更喜欢提出上面的三个问题，去寻找那些可能不值得浪费我的时间去测试的东西。下面八个例子是我讨论的内容：
0. 不会在产品中出现的组件- 我的团队中在每次迭代中都有这些内容。例如增强功能中的错误记录表或者跟踪生产活动中的审查报告。在敏捷开发的团队中这些被归入开发者用户故事（Developer User Stories）。这些内容不会随便的在产品中出现并且由于其本质不会直接影响到用户。
1. 关键产品问题的补丁不会很糟糕 – 一天下午客户给我们的技术支持打电话，由于我们的产品的一个阻塞性质的bug导致他们处于错过一个关键最后期限（DeadLine）的边缘。我们只有一个小时交付修复的产品。程序员很快的修复了问题，由于当前的产品是无效的，所以对修复之后进一步的产品存在的风险来说这是微不足道的。想要当英雄吗？不要让事情慢下来。快速的让产品通过测试。如果需要以后再去测试。
2. 界面问题修复要有适度的准备时间 – 我们修复了一个在屏幕上出现的用户错误消息中的拼写错误。用户并没有察觉到拼写错误但是我们无论如何修复了问题。很快而且简单。触发这个错误消息需要30分钟的准备时间，值得吗？
3. 直接了当的配置改变 – 去年我们产品开始偶尔出现很大的作业不能处理的问题。一个程序员尝试改变通用配置修复问题。但在QA的环境中没有一个简单的方法去创建一个足够大的作业超过这个临界值，很难去测试。我们在产品中修改了配置然后用户很高兴的为我们做了测试。
4. 技术性的需要非程序员的测试 – 测试部分功能时需要实施某种行为而在代码中设置断点来复现竞态条件.有时测试人员与工具和程序员精通产品代码的知识并不匹配。讨论这个测试但是回避它。
5. 非测试人员借用 – 如果团队中一个非测试人员帮忙去做测试工作，或者更重要的，想帮忙测试某一组件，让他去做吧。跟他分享测试的思路并且跟他要测试报告。如果你觉得满意，不需要再去测试它了。
6. 没有复现步骤- 程序员偶尔会尝试某些东西。经常会出现一些错误报告，但是没有人能对这些错误给出确切的重现步骤。我们也许想对修改的区域做回归测试，但是我们发布的时候不会阻止这种明显的修复，因为我们不知道它管不管用。
7. 不足的测试数据或硬件 – 让我们面对它吧。在我们QA的环境中，根据产品中所需要，大部分情况我们没有足够多负载平衡服务器。当一个有效的测试需要的资源在产品使用环境之外不可用时，我们可能无法对其进行测试。
很多人也许尝试想像上面这些如果不去测试会导致的问题。我也会做这些。记住，这些事情也许不值得花费我们的时间去测试。再次权衡你所做的事情，如果在不是很清楚的时候，去问问利益相关者。
如果你选择不去测试某些东西，很重要的是，不能被我误导。这是在我的团队中使用到方法。在我们进行组件审查时，我们的（测试人员）说，“我们将不会去测试这些”。如果有人反对，我们会改变我们的想法并且测试它。如果没有人反对，我们就“未经审查即批准（rubber stamping）”。即表明没有被测试就让它通过这样可以让他进入到最终产品。
所以下次你发现你自己正在着手做的测试，感觉比其他你应该做的事情更不重要时，你应该需要考虑…不去测试它。逐渐的，你的团队将会尊重你的决定并受益于更少的瓶颈，以及在你实际增加的价值的地方增长的覆盖率。
（转摘，出处不详）
程序员的一个笑话和另一个笑话
2012年5月15日 by 大慈大悲大晕僧
（转摘自一个word文件，出处不知）
有一个笑话是这样的：
1. 程序员写出自认为没有Bug的代码。
2. 软件测试，发现了20个Bug。
3. 程序员修改了10个Bug，并告诉测试组另外10个不是Bug。
4. 测试组发现其中5个改动根本无法工作，同时又发现了15个新Bug。
5. 重复3次步骤3和步骤4。
6. 鉴于市场方面的压力，为了配合当初制定的过分乐观的发布时间表，产品终于上市了。
7. 用户发现了137个新Bug。
8. 已经领了项目奖金的程序员不知跑到哪里去了。
9. 新组建的项目组修正了差不多全部137个Bug，但又发现了456个新Bug。
10. 最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职。
11. 公司被竞争对手恶意收购。收购时，软件的最终版本包含783个Bug。
12. 新CEO走马上任。公司雇了一名新程序员重写该软件。
13. 程序员写出自认为没有Bug的代码。
要我说，如果真有这样的公司，不倒闭对不起人民。
这个笑话从程序员开始，到程序员结束，从头到尾都在说程序员的不是。但是我要说的是，这完全是管理者的失败，从整个过程中，看不到任何管理工作。这种管理者不但无知无能，还很无耻——将自己的失败责任推给程序员。
1. 程序员凭什么证明他的代码没有Bug？有Test case吗？有Code review吗？这个环节管理缺失。
2. 测试发现Bug有进行Bug管理吗？有跟踪吗？这个环节管理缺失。
3. 凭什么证明程序员已经把那10个Bug修改好了？另10个又为什么不是Bgu？Bug的评价标准难道是程序员说了算？这个环节管理缺失。
4. 5个不能工作的Bug修改问题有没有追究责任？增加新Bug是修改过程中不可避免的事情，但是如果有有效的单元测试机制，可以大大减少这种情况。这个环节管理缺失。
5. 迭代是正常的，但是问题处理于发散而不是收敛发展，可见没有有效的管理调控。这个环节管理缺失。
6. 过于乐观的时间表和不可能达到的最后期限，都表现出管理者的无知和无能。而在这样的情况下强行推出产品，那就是无知者无畏了。
7. 这是对用户的不负责任，管理者要负最大的责任。
8. 这样的情况还能发项目奖金，只能说管理者不是一般的愚蠢。
9. 管理工作没有任何的改进，问题仍然处于发散迭代状态。管理工作依然没有到位。
10. 拖欠测试部门工资体现出管理者对质量管理工作的忽视以及对人力资源管理方面一无所知。
11. 送被收购者两个字：活该。送收购者两个字：瞎眼。
12. 可见新管理者与原管理者半斤八两，都没有认识到问题的根本所在。不过也只有这样的管理者才会作出收购这种公司的决策。
13. 历史的重演是必然的。
Google+界面的改版
2012年4月12日 by 大慈大悲大晕僧
Google+对他的界面布局做了最新的调整和改版。 此次改版中，最大的变化是：他把上面横向的菜单条，改成了左侧纵向的。
他为什么这么做？
关于LIMS新产品的预研
2012年4月7日 by LIMSer
本月任务中，有启动新一代LIMS产品预研的工作。但太过笼统，问题是：
1， 新是针对旧而言。那么，旧的有什么问题？ 为什么要展开新一代的预研？
2， 新一代主要解决什么问题？达成什么目标？
3， 预研主要解决什么问题？能够有多少资源（时间、资金，等）？
4， 动手之前，需要有个针对性的报告（技术方案？）。没靶子，打什么靶？
我的感觉是，针对大多数管理软件来说，大多是业务问题不是技术问题。我们在研发什么新技术吗？更多的是学习、消化理解和应用新技术。“搞科研”是斯坦福、硅谷、微软研究院和中科院干的事儿，不适合大多数公司。
互相保密协议书（范本）
2012年4月7日 by LIMSer
新版本LIMS剩余的界面问题
2012年4月6日 by LIMSer
差不多可以发布了，BUG还剩余10个左右未关闭，记录在TD中。界面表现方面，剩余这些。
1。DX列表的分辨率自适应问题
2。模态窗口的层级错乱模板嵌套错误的问题需要加载正确的模板，并且修正其中的引用
3。弹出模态窗的公用方法的调用问题，需要按详细的页面进行分离不能偷懒用一个
4。首页登陆和菜单还有后台管理
5。模态窗口上的地址栏隐藏
6。页面顶端加操作人和具体的主流程名称
7。具体个别页面IE9下可能错位的问题没对齐【这个IE8是对齐了的I9未知问题】
8。叉叉州计量页面老框架的剥离
9。那个很痛苦的页面标准管理，大概2天吧
10。可能会有极个别的页面需要微调
11。列表小图标
一个股票辅助决策软件的意见
2012年4月1日 by 大慈大悲大晕僧
一个同事做了一个股票辅助决策的软件，以捐助的形式放出来供大家免费用。与丹田讨论了一下，他有这样几个建议。三个问题：
1， 竞争。 已经有类似的，较多，已成体系，像军队，，而这个只是一个子弹。
飞狐（和信收购），分析家，东方财富，等。
2， 功能上。线太多，反而没了。应可取舍，选择。
角度线、黄金线。
3， 介绍的，和程序里的不相符。
四方形、轮中轮、江恩理论绝对是好东西。。。但有个问题，真的能把这些搞懂的，，，一般也不是省油的灯，他们会用这个吗？会为此捐赠吗？
需要再打磨，，做成“插件“如何？
基于ArchestrA的Wonderware 系统平台的优势
2012年3月31日 by LIMSer
OA：趋势和瞎想
2012年3月29日 by LIMSer
现在，OA有两个趋势：融合+移动应用
1，融合
与ERP融合，与其它业务系统融合。。。这个对头。真碰到那样的大客户，他自然会要求。需求实在。
2，移动应用。
智能手机今非昔比，的确方便。这个实在。
取舍：手机不是电脑。OA的功能全部照搬肯定不行，需取舍。
客户体验：如果在OA上丑了吧唧的东西，难用的东西因为功能够好还可以生存的话，在手机上就难了。在此领域更注重客户体验。
3， 还有更多的吗？ 怎样才能在竞争中脱颖而出呢？ 我认为有三：
3.1. 模式创新。不在卖软件上竞争，也不只是在服务上的竞争。 什么样的模式呢？ 我不知道。但想一想360当时的杀毒软件市场、以及苹果当时的手机市场。肯定会有聪明的脑袋想出聪明的办法；
3.2. 客户体验。 不只是手机端，，目前OA的客户体验通常都那样，不够好。不管是仪表盘的问题。
3.3. 结合物联网的概念？这个更像忽悠。但如果能把传真机等集成如OA呢？
博客分类
文章列表
最新评论
热文推荐
标签列表
最新留言
博客统计
- 文章总数:1090
- 评论总数:110
- 引用总数:0
- 浏览总数:45620
- 留言总数:3