博文
(转）如何用正确的方法写出高质量软件的75条体会 (2007-02-10 10:12:00)
摘要：1. 你们的项目组使用源代码管理工具了么？MVM：应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
2. 你们的项目组使用缺陷管理系统了么？MVM：应该用。ClearQuest太复杂，我的推荐是BugZilla。
3. 你们的测试组还在用Word写测试用例么？MVM：不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
4. 你们的项目组有没有建立一个门户网站？MVM：要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。
5. 你们的项目组用了你能买到最好的工具么？MVM：应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。
6. 你们的程序员工作在安静的环境里么？MVM：需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。
7. 你们的员工每个人都有一部电话么？MVM：需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。
8. 你们每个人都知道出了问题应该找谁么？MVM：应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。
9. 你遇到过有人说“我以为…”么？MVM：要消灭“我以为”。Never assume anything。
10. 你们的项目组中所有的人都坐在一起么？MVM：需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。
11. 你们的进度表是否反映最新开发进展情况？ MVM：应该反映。但是，应该用Ba......
功能测试(2007-02-10 09:30:00)
摘要： 功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下： 1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。（补充，前进和返回必须对应） 2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。 （删除是否可以回滚） 3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。（批量提交时，要考虑到部分操作成功的情况，是否对剩余的操作进行保存，并再次提交） 4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错. 5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.（字符编码格式） 6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确. 7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错. 8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致 9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理. 10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错; 然后选择一个和多个信息,进行删除,看是否正确处理. 11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填; 添加规定为整型的项,修改也必须为整型. 12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错. （是否支持重命名） 13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。 14. 检查多次使用back键的情况: 在有bac......