积极心态、目标明确、要事第一、双赢思维、知彼解己、统合增效、不断更新

摘要-测试的相关问题

上一篇 / 下一篇  2010-10-26 09:26:33 / 个人分类:软件安全测试的理论知识

1.基于WEB信息管理系统测试时应考虑的因素有哪些?

  1)功能测试
  
    ① 链接测试

    ② 表单测试

    ③ Cookies测试

    ④ 设计语言测试

    ⑤ 数据库测试

  2)性能测试

    ① 连接速度测试

    ② 负载测试

    ③ 压力测试

  3)可用性测试

    ① 导航测试

    ② 图形测试

    ③ 内容测试

    ④ 整体界面测试

  4)客户端兼容性测试

    ① 平台测试

    ② 浏览器测试

  5)安全性测试

  2.软件本地化测试比功能测试都有哪些方面需要注意?

 3.软件测试项目从什么时候开始,?为什么?

  软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势. 缺陷发现的越晚,修复它所花费的成本就越大.

 4.需求测试注意事项有哪些?

  一个良好的需求应当具有以下特点:

  ● 完整性:每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。

  ● 正确性:每一项需求都必须准确地陈述其要开发的功能。

  ● 一致性:一致性是指与其它软件需求或高层(系统,业务)需求不相矛盾。

  ● 可行性:每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

  ● 无二义性:对所有需求说明的读者都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户性的语言表达出来。

  ● 健壮性:需求的说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错处理。

  ● 必要性:“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入,如Use Case或别的来源。

  ● 可测试性:每项需求都能通过设计测试用例或其它的验证方法来进行测试。

  ● 可修改性:每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外,使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

  ● 可跟踪性:应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好(f i n e - g r a i n e d )的方式编写并单独标明,而不是大段大段的叙述。

    5.分析测试用例注意(事项)?

  1)为什么要写用例:

  我们编写测试用例,有如下的好处:

  便于团队交流:假如说一个测试团队有10个成员,大家测试的时候都各自为政,没有统一的标准,测试的效率无疑会大打折扣;如果大家都遵循统一的 用例规范去写,就会解决这一问题。

  便于重复测试 :大家知道,软件在实际开发过程中是会有不同版本的,比如会从1.0升级到10.0,那么如果不写测试用例的话,在测试10.0版本的时候,你能完全记得 1.0版本时你做过哪些测试吗?测试用例就像一个备忘录一样,便于重复测试。

  便于跟踪统计:这一点是针对测试经理或是项目经理来说的,项目负责人通过看测试用例的执行情况,就能了解到项目目前的概况,比如已经执行了哪些 测试,还有哪些测试没有执行,测试没有通过的地方主要集中在哪些模块等。

  便于用户自测:尤其是项目软件,有的时候用户希望自己测试一下软件产品,但是用户大都是非专业人士,他需要根据你写好的用例来更好的检验产品的 质量

  说了这么多编写测试用例的优点,那它有没有缺点呢?有一个明显的缺点就是需要花费大量的时间,通常编写测试用例的时间比实际执行测试的时间还要 长,这一点大家会在实际工作中有深刻的体会

  2)什么时候写用例:

  什么时候写用例?这个问题没有统一的标准答案,但有一点可以肯定,就是测试用例要尽早编写。 大家认为在哪个阶段开始写用例比较好呢?

  通常,我们都会在测试设计阶段来写用例,即《需求规格说明书》和《测试计划》都已完成之后

  


TAG: web Web WEB 分析测试

 

评分:0

我来说两句

Open Toolbar