软件测试员需要注意那些但是最容易被忽略的非软件部分：
帮助文件、用户手册、
样本和示例、标签和不干胶、
产品支持信息、图标和标志、
错误信息、广告和宣传材料、
安装、说明文件
文档测试
注意：如果安装指导有误，或者不正确的错误提示信息把用户引入歧途，他们就会认为是软件缺陷——软件测试员应该发现。
审查文档需要找什么？
如果非代码，测试就是执行静态测试；
如果文档与代码紧密联系，测试就要执行动态测试。
文档测试的分类：开发文件、用户文件、管理文件。
1开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、
数据库设计说明书、模块开发卷宗。
2用户文件：用户手册、操作手册
3管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
产品说明书属性检查清单
完整. 是否有遗漏和丢失 完全吗 单独使用是否包含全部内容
准确. 既定解决方案正确吗 目标明确吗 有没有错误
精确. 不含糊,清晰.描述是否一清二楚 还是自说自话 容易看懂和理解吗
一致. 产品功能能描述是否自相矛盾,与其他功能有没有冲突
贴切. 描述功能的陈述是否必要 有没有多余信息 功能是否原来的客户要求
合理. 在特定的预算和进度下,以现有人力,物力和资源能否实现
代码无关. 是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码
可测试性. 特性能否测试 测试员建立验证操作的测试程序是否提供足够的信息
产品说明书用语检查清单
说明 对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.
总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.
某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.
等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.
如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样