1.完整：是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？
2. 准确：既定解决方案正确吗？目标明确吗？有没有错误？
3. 精确：不含糊，清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？
4. 一致：产品功能描述是否自相矛盾？与其他功能有没有冲突 ?
5. 贴切：描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ?
6. 合理：在特定的预算和进度下，以现有人力，物力和资源能否实现 ?
数据库简单吗 7. 代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 ?
8. 可测试性：特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ?
产品说明书用语检查清单
说明：对问题的描述通常表现为粉饰没有仔细考虑的功能 ---- 可归结于前文所述的属性。从产品说明书上出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱 , 也可能含糊其词 ---- 无论是哪一种情况都可视为软件缺陷
9. 总是，每一种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可以着手设计针锋相对的案例
10. 当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。
11. 某些，有时，常常，通常，惯常，经常，大多，几乎。这些话太过模糊， " 有时 " 发生作用的功能无法测试。
12. 等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。
13. 良好，迅速，廉价，高效，小，稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。
14. 已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。
15. 如果 ... 那么 ...( 没有否则 ) 。出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则 " 结构的陈述，想一想 " 如果 " 没有发生会怎样。
简明性、明确性：在软件开发各个阶段所编写的各种文档的语言表达清晰、准确、简练，适合各种文档的特定读者即提供的用户手册要对系统中每部分的在各个阶段的功能有明确。
描述，对于工作流程也有明确叙述，让用户很清楚的知道自己处于流程中的什么位置，在做什么，接下来该做什么或者应该怎么做。
内容完整性：按照软件开发流程编制相应的文档，提供用户操作手册及在线帮助。
用户操作手册要全面、细致的每个模块
操作步骤以及每步所要达到的目标。
在线帮助要详细列出用户在工作中可能遇到的问题，并针对每个问题提出详细的解决方案，要充分起到“实时”给予帮助的目的。
准确规范性、可读性：用户手册、用户操作手册以及在线帮助要做到用语规范，准确，可读性，符合客户要求的编写规范标准，使用户操作起来简单明了，例如在某环节出现了问题，用户能够利用在线帮助很快且顺利的到相应的帮助文档，最终达到解决的目的 。
可追踪性：指在不同文档的相关内容之间或则同一文档某一内容在本文档中的涉及范围可追踪性。
自说明性：各个阶段中的文档能独立、清楚的表达出对应于该文档所处的阶段而开发出的软件产品所具有的功能。
测试用例：
测试用例编写规范
一、测试用例编写准备
从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
二、测试用例制定的原则
测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：
1、 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2、 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3、 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4、 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5、 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
7、 压力测试：输入10条记录运行各
个功能，输入30条记录运行，输入50条记录运行。。。进行测试。
8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
12、可移植性：在不同操作系统及硬件配置情况下的运行性。
13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员 已经解决，进行下一轮的测试。
14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较 。
说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同。
1、 其中第1、2、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、系统测试都涉及并重点测试的方面。
2、 单元（模块）测试（组件、控件）测试：重点测试第5项。
3、 组合（集成）测试：重点进行接口间数据输入及逻辑的测试，即第4项。
4、 系统测试：重点测试第3、7、10、11、12、14项。
5、 其中压力测试和可移植性测试如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试即可。
6、 GMPS基础测试用例设计完成后，其他的测试项目只编写设计与之不同部分的测试用例。
7、 对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。
三、测试用例的填写
一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。
测试用例主要分为五部分：
1.测试用例对需求覆盖的完整性：明确需求，理顺业务路径，从全局上把握住需求
2.测试用例的有效性
3.测试用例的可理解性：描述清晰，不能出现模棱两可的词语
4.测试用例的清晰性：用例清晰重点突出
5.测试用例的可维护性：注意测试用例的有效性，通用性。产品说明书属性检查清单
发表评论