第二部分-测试技术及实例介绍.pptVIP

* * * * * * * * * * * * * * 查询条件 查询条件数据项正确 查询条件单个查询正确 查询条件多个组合查询正确 模糊查询功能正确 查询列表 列表数据项正确 列表信息展示正确 信息记录对应的链接字段，链接信息正确 查询测试（一） 准备数据的方法 系统走业务 数据库导入数据 测试方法：灰盒测试 查询测试（二） 目录（二） 第二部分 测试实例分析及实践 留言板需求 测试过程文档模板 测试计划 测试用例 测试缺陷 测试报告 留言板测试实施 留言板需求 留言板需求说明书 分析测试关注要点 WEB页面(对需求、风格、布局） 操作按钮（功能、人员操作权限） 业务逻辑关系 系统内接口 系统外接口 测试过程文档模板 测试计划 测试用例 测试缺陷 测试报告 留言板测试实施 留言板测试计划 留言板测试用例 留言板测试缺陷 留言板测试报告 要求每个学生都要动手写且提交评审 目录（三） 第三部分 测试工具介绍及实践 功能测试自动化QTP 性能测试自动化LR 留言板实践 谢谢大家！ * * * * * * 显示项：显示值正确。 必输项：参考公共要点。 系统自动生成项：生成规则。 输入项：文本框、单选框、复选框、下拉选择 页面必须有标题，且标题与页面信息一致。 * 数据类型：输入非法数据、输入特殊数据 数据长度：输入超长 下拉选择项和单选项：保存到数据库中的值多为代码，可以通过查询页面验证数据的正确性，也可以通过查数据库的方法验证正确性。 * * * * * * * * * * ? ? 1、确保流程通畅，符合流转规则。? ? 正向规则最基本的一点是，按照流程走，到哪个节点哪个节点能够看到待办件，没传递到的节点不能看到待办件。现在很多工作流节点，调用的页面是同一个，在底层工作流应用中控制显示情况，有时设置错误，本来不应该看到该件的节点，有时候会看到。? ? 比较常见的正向规则还有会签流转原则，如流程是A上报给B、C，B上报给D，C上报给E，D、E上报给F，这样的流程我们需要确认，在什么情况下，F应该看到待办件。是D、E都结束，还是有一方结束了，F就可以看到。如果是单个通过，F就可以看到，我们要尝试分别走2边的情况，流转结果是否正确。还要尝试F已经通过了，没审核的一方才审核（审核包括审阅、审批）是否影响流转。? ? ? ? 逆向流转规则，检查是否每一部退回都退回到了需求定义的节点，收到退回件的人是否能够正确处理退回件。这个根据需求定义，有的要直接打回上报人，有的要打回到上一个审批人，有的要打回上一个节点。我们要检查每一个退回是否将待办任务打到了需求定义的正确节点上。? ? 2、状态查看，在每个节点显示正确的状态。? ? 起草人上报了自己的待办任务，他希望知道当前审批情况如何，各级已经审核过的人也关注上面领导是否同意。我们要在每一部操作后，关注已经经历过的每个节点，状态显示是否正确。尤其是多次退回和通过的情况，之前的节点可能会有显示状态不正确的情况。? ? 3、信息传递正确完整? ? 首先是待办任务的基本信息，从发起人填写上报，每个节点可以正确看到（有特殊权限定义的除外）全部信息，要特别关注附件等特殊信息，在传递过程中较容易出现问题。另外一些字段也可能出错，我遇到过这样的问题，审核人看到的信息，手机号码显示在了传真里面，审核人的页面调用的数据库字段写错了（这里说个题外话，有时候我们测试执行，要填写的字段太多，我们可能会输入一些没有意义的信息，比如111111111111，这样。但是我每次都会跑一条我自己的真实数据，开始时觉得好玩----给自己的信息写在了一个局长的提干申请里面，后来发现这么干的好处很多，后期对字段我很容易看出来他们取数据错没错，或者完整不完整，尤其交互页面，如果用没有意义的字段，要对比可能需要2个页面都看，写自己的数据就简单很多。还有页面检查设定的约束是否能够容纳一个正常数据等。? ? 其次是各级审核信息，每级审核领导会填写自己的意见，正项流转下一结点要看到上面结点所有人填写的意见，逆向流转收到退回件的人，也需要知道上面领导退回原因。给每级领导审核时能填写意见的都写上意见，这样在各级检查的时候能够保证检查的完整性。? ? 有时候流转较复杂，像“1”中第四种，可能本级已经审批过了，退回去，给下级了，下级再次上报上来，本级再次审批，然后上报。上级拿到后，看到的审批信息，要是最新的，而不是上次退回的。尤其是上级看到的审批日期等信息，如果读取的是第一次审批的时间，领导会认为下级办事时间过长。? ? 4、审核中可以对原件编辑的情况? ? 有时候需求要求审核人有修改发起人填写的信息权利，这时候我们要注意需求未特殊定义情况下，字段和值的约束条件应该前后保持一致。发起人必填项到审核人修改处也必须是必填项，