7. ALM的邮件功能需要安装MailDirectPro软件才能够让ALM通过内网向外网的邮箱服务器发邮件。
8. ALM上创建一个bug，默认设置是不会自动发邮件通知相关人员的。需要编写VB脚本才行。
9. ALM的错误提示信息比较简单，没有足够的信息告诉用户到底是什么原因，感觉用户体验很不好，让用户觉得一头雾水。
10.在使用它的版本的时候，发现它不能支持一个大项目里面有多个子项目；目前我的做法是在“管理-->版本”下通过建立文件夹，每个文件夹都代表一个独立的子项目，每个子
文件夹下建立版本，代表子项目的不同版本。这主要做的缺点是，不同子项目有不同的人也能看到其他子项目的信息。可以选择通过ALM的域的概念来代表大项目，建立不同的
项目来对应不同的子项目。我没有这么做的原因是这个大项目还有同级的其他项目，而ALM的域不能重叠。
好了，说了ALM的几大"罪状"，现在说说它的独到之处：
1. 它能够把需求、测试、缺陷三者联系起来，他们三者形成一个闭环，从任意一方，都能够找到关联的其他两方；如从需求，能找到覆盖到这个需求的测试用例有没有，和关联的缺陷bug有没有；其余的同理；
2. 提供的周期概念比较让人困惑，开始把周期当作测试周期来做，每个周期关联测试集， 后来发现这样做的话，项目经理觉得ALM就是只能看到测试的情况，而看不到开发的
状态。后来经过探讨，我们认为我们错误的理解了周期的概念；ALM设计周期的概念是以测试为结果的理念，也就是说周期的开始不代表一轮测试的开始，它代表的是某项任务
的开始，比如是开发任务的开始；而周期的结束是要以测试结果为结尾的，否则在ALM的这个周期里看不到进度和质量，没有实际的意义。
3. 建立版本是第一项任务，由项目经理来做；录入需求是第二项任务，由产品经理来做。
用好ALM确实是件很重要的事情，使用好了，ALM是好工具；使用不好，ALM仍然是个好工具，但是我们会骂他为什么做的这么狗屎。 哈哈，个人意见，欢迎拍砖。
