工具评估标准

该网页由OWASP中文项目组维护，以帮助OWASP中文项目的领导人和项目参与人员，依据《2.0版评估标准》（Assessment Criteria v2.0），在项目发布以前，对项目开发的工具进行评估。

工具Alpha发布的标准

评估前的检查列表：

1. 该项发布涉及的项目是否至少包含“项目Wiki最少页数内容”信息？
2. 你的工具是否符合一个免费且开源许可证？（参见Guidelines for OWASP Projects的“项目许可”部分）
3. 源代码和文档是否在在线项目提供方中提供下载？（比如：Google Code或Sourceforge网站）
4. 是否有能用的代码？

工具Beta发布的标准

评估前的检查列表：

1. 在Alpha发布中，评估前的检查列表中的项目是否完成？
2. 是否有一个安装文件或者独立运行文件？
3. 在OWASP项目wiki网页中是否有用户文档？
4. 是否有“关于”选项或其他类似“帮助”选项，以例举：
   1. 项目发布名称
   2. 简短的描述
   3. 项目发布领导人和联系方式（比如Email）
   4. 项目发布贡献人员（如果有的话）
   5. 项目发布许可证
   6. 项目发布赞助方（如果有的话）
   7. 发布状态以及以“X年X月”为格式的评估时间，比如：2009年3月
   8. 连接至OWASP项目网页的链接
5. 是否记录了如何将源代码编译建立成工具，以及包括如何从提供代码下载的地方获得源文件？
6. 工具的文档是否和源代码存放在相同的地方？

审核人员检查项目:

1. 是否提供了一个安装文件并简单易用？该安装文件有多么接近于一个完全自动化的安装文件？
2. 终端用户文档在OWASP的wiki网页里是否提供，并且完整和相关？
3. 工具是否含有一个“关于”选项或其他类似“帮助”的选项，以使终端用户对工具的状态有一个大致了解？这些信息是否立马可用并且容易找到？
4. 建立源文件的文档是否提供了重要的信息和细节，以使用户可以建立工具？是否有充足的细节信息提供给目标用户？是否有一些特殊领域的知识被假设或者没有提供？
5. 工具的文档是否和源文件一同提供，并且能否很容易就被一个新的工具使用者发现？

工具稳定发布的标准

评估前的检查列表：

1. 在Alpha和Beta发布中，“评估前检查列表”中的项目是否全部完成？
2. 工具是否包括建立工具的文档？
3. 工具是否包括安装脚本以自动安装？
4. 是否有一个可以公共访问的bug跟踪系统？
5. 工具已有的一些缺陷是否被记录？

审核人员检查项目:

1. 在Beta发布中，审核人员需检查的项目是否都已完成？如果在前一评估阶段没有达到，则必须完成。
2. 工具是否实质性的解决了当初认为需解决的应用程序的安全问题？
3. 工具是否简单易用？
4. 文档是否满足了工具使用者的需求并且很容易被找到？
5. 安装脚本是否按照预期那样运行？你是否可以建立工具？目标是“点击一次”就完成所有的安装。
6. bug跟踪系统是否可用？其是否和源代码放置在相同的地方？（比如：Google Code, Sourceforge）
7. 你是否发现到一些没有被项目发布领导记录的工具限制或缺点？
8. 假设在你的工作中有使用该工具的需要，那么你是否会考虑在你的日常工作中使用它？你是否会将该工具推荐给这一领域中的其他人？为什么会？为什么不会？
9. 如果有的话，缺失哪部分会使这个工具更加有用？缺失的部分，是否会将文档的发布降为Beta等级？