Software Engineering

[Rod Johnson] 框架的设计没必要太XP

他说: The XP advice of "Writing the simplest thing that could possibly work" isn ‘t always appropriate It’s impossible to refactor the interfaces exposed by a framework without breaking code that uses it and severely reducing its usefulness. Even within an organization, the cost of incompatible changes to a framework can be very large (on …

[Rod Johnson] 框架的设计没必要太XP Read More »

我对文档的要求:必要的、最小的冗余

    软件文档究竟应该怎么写?写多细?要不要写?有很多不同的看法。有人认为文档应该完备和优雅,并且总是应该用作下一个阶段的驱动;有人认为文档是要写的,但不必区分文档性质,文档间的组织结构也无所谓;有人则认为文档除了浪费时间之外没有任何意义,尤其在中国这个以“中档质量低档价格”的营销环境下,文档只会影响快速交付,降低竞争力,最终让股东很不高兴。      我个人的观点是: 文档应该用作代码的 必要的、最小的冗余。也就是说,          1.文档是代码的冗余,因为文档里有的东西,代码里其实都有          2. 这个冗余是必要的,否则无法保障软件质量          3. 冗余应该是最小的,否则它会项目进度,并且让项目成员很不快乐           首先,文档里的东西代码里都有,这个不必说。      既然文档是冗余的东西,是不是应该去掉? 如果项目成员能够牢记功能和代码的对应关系,并且能够飞速地扫描代码找到自己所需要的东西,那文档的确可以去掉;否则,还是应该把某些东西成文归档,记个笔记,尤其是需求文档,它是软件产品的最终参考,并且充当了需求人员和开发人员之间的契约,必须做的完备。      但是,中国的软件公司都有普遍现状:文档超乱!最主要的原因有:         1.项目太紧,没时间写         2.文档格式很臃肿,不想碰它         3.文档评审很麻烦         4.我习惯在编码的过程中把设计做好,不想先写文档         5.更新文档,有一种返工的感觉,超烦      所以,要尽量在质量和进度以及烦恼指数上达到平衡。我的建议是,只写“最小的”文档。它包括:         1. 文档工作量尽量地少。我只觉得三个文档是必须的:需求规格说明书,概要设计文档和测试用例。而且,概要设计文档没必要太细致。         2. 抛弃文档模板,只写有必要写的东西。现在很多设计文档里都喜欢把“需求背景”复述一便,换了我写一个“略”字带过         3. 确立开为人员作为文档的主导者,改了代码后自己迅速修改文档,由于自己熟悉文档,在评审时也可以与业务分析人员迅速沟通。         4. 完全可以在开发完成后再补充文档。你完全可以在快速编码的过程中通过调试实现最优设计,这种设计往往比预先的设计要少很多漏洞。         5. 文档不要再建副本。一个组织就一份文档,其版本通过版本工具来维护,不要用邮件发来发去,副本太多是引发混乱的前奏。

软件版本术语:alpha、beta、gamma

广义上对测试有三个传统的称呼,alpha、beta、gamma,用来标识测试的阶段和范围。 alpha 是指内测,即现在说的 CB,指开发团队内部测试的版本或者有限用户体验测试版本。 beta 是指公测,即针对所有用户公开的测试版本。 然后做过一些修改,成为正式发布的候选版本时(现在叫做 RC – Release Candidate),叫做 gamma。

通用测试用例_输入

一、不合格式 1. 长度超过规定的最大值 2. 长度小于规定的最小值 3. 将非数值的字符串输入数值型字段中 4. 数值正负不合要求 5. 数值的大小超过规定的最大值 6. 数值的大小小于规定的最小值 7. 必填字段为空 二、trim   包括 left trim ,right trim, both trim 三、输入特殊字符   1. 使用单引号   2. 双引号   3. 百分号,下划线

[体会]一个项目中可能用到的种种管理平台

这些管理平台有时候不能彻底相互区分,但实质上各不相同 1.需求管理。 如Doors 2.任务管理。 如XXX 3.项目计划与进度控制。 如MS Project 4.测试管理。 如Mercury,TestLink,可以将它与需求管理平台挂钩,即将用例与需求挂钩 5.缺陷追踪。这个东西常常与测试管理平台一起使用,或者自身就充当测试管理平台的测试执行部分。如Bugfree, Bugzilla