文档测试

产品说明书属性检查清单
完整.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?
准确.既定解决方案正确吗?目标明确吗?有没有错误?
精确,不含糊,清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗?
一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突?
贴切.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?
合理.在特定的预算和进度下,以现有人力,物力和资源能否实现?
代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码?
可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息?

产品说明书用语检查清单
说明 对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.
总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
当然,因此,明显,显然,必然.

总结上一次写用例的教训

——就是用测试用例找到的bug数占得比例很小，测试用例很多，但是真正找到bug的用例很少

——测试用例大多数都是从通用用例中复制而来，很多都是界面上的东西

——关于业务的用例较少，但是关于业务流程的用例找到的都是严重级别的bug

所以这一次，我们的用例需要改进

1. 今天将这个项目的业务流程进行分析了一下。做了一个业务流程图。按理说这个工作是业务需求的人员画，但是他们可能没有时间，所以只能由我们来做。为什么非要做这个流程图。因为有了这样的流程图，做用例的时候，就可以非常容易。

2. 第二点是写用例的形式。以前是用的excel。有个工具，tesklink，准备在明天考虑使用

3. 另外就是用例设计的问题。这个问题其实才是核心，别的都是辅助的功能。