1、王雯佳,文档测试方法,软件开发过程,需要进行文档测试的部分,本讲要点,为什么需要进行文档测试 采用什么测试方法测试文档 测试人员参与文档测试的必要性 文档测试组织方式,为什么需要进行需求测试？,在软件开发过程中，需求分析是最开始的工作，需求分析如果做得不够详细或者是偏离用户需求的话，往往会给项目带来灭绝性的灾难。 用户的表达和需求工程师的理解有时间并不会一致，这样会导致用户所想的和需求说明书上所描述的有偏差。 50%以上的缺陷其实是在软件需求阶段被引入的。由于需求编写存在问题，不明确，不清晰，不正确、需求遗漏导致的。,按照尽可能早的测试原则，测试人员应该在需求阶段就介入，并贯穿软件开发的全过程
2、。,为什么需要进行需求测试？,测试项目周期,需求测试阶段,测试计划阶段,测试设计阶段,测试执行阶段，缺陷跟踪,总结评估阶段,需求评审,回想上节课的测试方法介绍，你认为应该采用什么方法呢？,静态测试-评审,需求评审的目的,需求评审员就是需要让需求明确起来，让测试，开发，需求方都能对需求（这里的需求当然也包括需求实现方式）达成一致。,测试人员为什么需要参加需求评审,在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵 软件经历了需求，设计，编码，测试，不同的阶段有专业人士配合完成，由于下游技术人员对于上游技术人员的理解偏差，将导致不同阶段的产物之间存在不一致的现象。 测试人员参与需求评审，充分
3、地理解需求，确保对需求的理解与需求分析人员是一致的； 测试人员参与需求评审，从可测试的角度，努力发现用户需求说明书中不可测试的需求，从而提醒需求分析人员尽早修改； 测试人员参与需求评审，从测试人员的角度努力发现用户需求说明书中的不完整性，从而提醒需求分析人员及时补充遗漏掉的这部分用户需求。,需求规格说明书的检查步骤,获取最新版本的软件需求规格说明书，同时尽量获取用户原始需求文档 阅读和尝试理解需求规格说明书中描述的所有需求项 对照需求规格说明书检查列表进行检查和记录 针对检查结果进行讨论，修订需求规格说明书,需求规格说明书检查列表example,举例1-1,举例1-2,以上需求存在的问题是：
4、（1）“当前时间10日范围内”描述模糊，没有明确的描述。 （2）“未来一段时间”是多长时间？ （4）“若出现异常”，异常是怎样的情况？,举例2-1,“产品应在不少于每60秒的正常周期内提供状态信息”,存在问题：需求不可测产品的哪个模块 在哪个位置提供 具体哪些状态信息 一定要每六十秒，误差允许?,修改建议 后台任务管理器应该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息 如果后台进程处理正常，那么应该显示任务已完成的百分数/比 任务完成时，应显示相关的信息 后台任务出错应该显示错误信息,举例2-2,“产品应瞬间在显示和隐藏不可打印字符间切换”,存在问题：需求不可行产品的那
5、个模块 瞬间？ 不可打印字符？ 产品自动切换？有无触发条件？,修改后 用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换,举例2-3,“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”,存在问题：需求模糊 可能？,举例2-4,用例：业务单据查询 典型过程： 打开查询界面 键入查询条件 确定并提交查询 系统返回相关信息,存在问题：不可测试输入的查询条件包括哪些 提交查询之前是否会验证输入数据的正确性 输入数据的单位，范围有无限制 所有条件都不输入是否意味着能查询出所有业务单据 返回业务单据包含哪些信息？,需求点,正确性：对照原始需求规格说明书
6、必要性：不能回朔到出处的需求项可能是多余的 优先级：恰当地划分并标识 明确性：不能使用含糊的词汇 可测性：每项需求都必须是可验证的 一致性：内容前后一致 可修改性：良好的组织结构 具体详看（检查单）,测试需求的分析和确定,检查需求规格说明书 开展方式 审查过程的主持人需要根据项目的计划以及质量管理的计划对此次的审查会议制定一个详细的计划。（审查对象，审查组人员组成以及职责）审查准备：文档作者向相关人员发布文档；审查人员尽可能发现一些问题；文档作者修正问题；确定会议时间、地点、设备； 审查会议：文档作者与审查人员做深入交流 回归审查 总结，VSS归档（VSS版本控制器）,课堂任务,小组之间相互展开评审 依据：需求检查列表,
