幽然木香、清雅墨香, 云鬓高绾、高跟套裙。 木香小园、键盘鼠标, 代码变换、七彩纷呈。 调试性能、测试功能, 高跟奏响、不让须眉。 ——于二零零九年元月八号,午后有感而作,见笑。 博主简介:从事测试行业8年整,曾有多次大型软件项目的测试,擅长于功能测试及系统测试,丰富的各种用例及场景设计、测试环境配置等经验。对各种流行的软件测试工具均有不同程度的学习,目前正潜心学习性能测试、测试管理。今已我学我用我心得以文字方式记录,欢迎同行一起学习、指导。

发布新日志

  • 找工作,这个很好使的

    2008-12-25 15:35:22

  • 关于文档测试

    2008-11-05 14:17:32

    产品说明书属性检查清单

    1.完整:是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?

    2. 准确:既定解决方案正确吗?目标明确吗?有没有错误?

    3. 精确:不含糊,清晰。描述是否一清二楚?还是自说自话?容易看懂和理解吗?

    4. 一致:产品功能描述是否自相矛盾?与其他功能有没有冲突 ?

    5. 贴切:描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ?

    6. 合理:在特定的预算和进度下,以现有人力,物力和资源能否实现 ?

    7. 代码无关:是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码 ?

    8. 可测试性:特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ?


    产品说明书用语检查清单

      说明:对问题的描述通常表现为粉饰没有仔细考虑的功能 ---- 可归结于前文所述的属性。从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱 , 也可能含糊其词 ---- 无论是哪一种情况都可视为软件缺陷

    9. 总是,每一种,所有,没有,从不。如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例

    10. 当然,因此,明显,显然,必然。这些话意图诱使接受假定情况,不要中了圈套。

    11. 某些,有时,常常,通常,惯常,经常,大多,几乎。这些话太过模糊, " 有时 " 发生作用的功能无法测试。

    12. 等等,诸如此类,依此类推。以这样的词结束的功能清单无法测试,功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论。

    13. 良好,迅速,廉价,高效,小,稳定。这些是不确定的说法,不可测试。如果在产品说明书中出现,就必须进一步指明含义。

    14. 已处理,已拒绝,已忽略,已消除。这些廉洁可能会隐藏大量需要说明的功能。

    15. 如果 ... 那么 ...( 没有否则 ) 。找出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则 " 结构的陈述,想一想 " 如果 " 没有发生会怎样。

        简明性、明确性:在软件开发各个阶段所编写的各种文档的语言表达清晰、准确、简练,适合各种文档的特定读者即提供的用户手册要对系统中每部分的在各个阶段的功能有明确描述,对于工作流程也有明确叙述,让用户很清楚的知道自己处于流程中的什么位置,在做什么,接下来该做什么或者应该怎么做
        内容完整性:按照软件开发流程编制相应的文档,提供用户操作手册及在线帮助
    用户操作手册要全面、细致的每个模块操作步骤以及每步所要达到的目标
    在线帮助要详细列出用户在工作中可能遇到的问题,并针对每个问题提出详细的解决方案,要充分起到“实时”给予帮助的目的
        准确规范性、可读性:用户手册、用户操作手册以及在线帮助要做到用语规范,准确,可读性,符合客户要求的编写规范标准,使用户操作起来简单明了,例如在某环节出现了问题,用户能够利用在线帮助很快且顺利的找到相应的帮助文档,最终达到解决的目的
        可追踪性:指在不同文档的相关内容之间或则同一文档某一内容在本文档中的涉及范围可追踪性。
        自说明性:各个阶段中的文档能独立、清楚的表达出对应于该文档所处的阶段而开发出的软件产品所具有的功能。

Open Toolbar