首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >QA测试过程

QA测试过程
EN

Stack Exchange QA用户
提问于 2014-03-23 13:59:51
回答 4查看 392关注 0票数 1

我们目前使用以下过程进行测试:

  1. 编写测试计划(当前存储在中)
  2. 执行测试计划
  3. 一旦被测试的功能提升到生产,使用Borland SilkTest自动化测试计划,以便进行未来的回归测试

问:对于使用自动化的商店来说,这是一个典型的过程吗?随着对原始测试计划的更改(由于将来的修改),您是否继续同时维护手动测试计划和自动化测试计划?

谢谢!

EN

回答 4

Stack Exchange QA用户

回答已采纳

发布于 2014-03-23 16:42:06

对于每个组织/团队/产品/流程,这可能是不同的,但下面是我使用过的一个典型流程(从新功能开始):

  1. 确定关键的测试参数,如预言、表面(如平台、输入、输出等变量)和风险区域。
  2. 使用多个手动测试会话,探索当时正在仔细检查的功能。
  3. 开发自动化,使测试更快地发挥作用,或确定哪些功能可以很好地添加到烟雾测试(完全自动化)套件中。
  4. 将自动化集成到回归测试自动化套件中,作为烟雾测试或独立的计算机辅助测试模块,帮助设置或检查应用程序的特定区域。这个步骤是作为每周或每两周周期的一部分来完成的,而它是新鲜的。
  5. 只有足够的文档才能识别每个回归测试区域要使用的自动化。脚本的功能记录为脚本本身中的注释。

这里的关键是回归自动化将打破常规,因此自动测试和手动回归测试的智能混合是最好的,使它尽可能有用,但仍然是可维护的。随着时间的推移,自动化的范围将根据可用于实现和维护的时间自行确定。

希望这能帮上忙!

票数 2
EN

Stack Exchange QA用户

发布于 2014-03-24 08:21:51

首先,每一家公司都有自己的测试流程,但都是典型的。其次,每个公司都有不同的开发生命周期,因此测试过程也不同。我可以与大家分享我们目前的测试过程:

  1. 概述项目结构
  2. 需求概述图
  3. 获取软件需求规范文档
  4. 编写一个测试计划,包括:目的和范围、要测试的功能、不需要测试的功能、测试方法、测试通过/失败标准、回归测试策略、工具(测试用例管理、错误跟踪、性能测试工具、自动化测试框架等)、测试计划、风险管理。
  5. 准备烟雾试验
  6. 根据上一步中创建的软件测试计划创建一个功能测试套件。
  7. 准备自动化测试套件
  8. 然后是敏捷过程(在每次迭代结束时验证特性),开发和更新自动回归测试套件。
票数 1
EN

Stack Exchange QA用户

发布于 2014-03-24 11:34:23

正如其他答案所说,没有“典型的”过程。每个人都以自己的方式处理事情。

尽管如此,也有一些共同的因素:

  • 大多数地方都有某种形式的测试计划存储库。我看到了所有的东西,从共享目录结构中的文档和电子表格到高美元的专业工具。
  • 大多数地方都会认为测试计划是手动执行的。自动化手动测试计划很少是个好主意--什么是好的手动测试并不一定是自动化的好选择。
  • 大多数实现自动化的地方都有一种方法来识别自动化测试,并有一种将目标测试添加到回归代码库中的策略。确切的策略大不相同。
  • 对于自动化的认真对待的地方将不会使用记录/回放,不管他们的工具是否支持它。
  • 认真对待自动化的地方会把它们的自动化代码库当作代码来处理。
  • 对自动化非常重视的地方将把它们的自动化代码库保存在版本控制存储库中。它可能与应用程序代码版本控制存储库不匹配,但如果它与应用程序代码库版本控制不匹配,则将以允许针对所需应用程序代码库的任何版本运行回归的方式标记它。
  • 认真对待自动化的地方将确保有时间用于维护自动回归。
  • 在新特性稳定之前,将不会构建新功能的自动回归。

从你所说的听起来,你已经涵盖了大部分这些要点,所以你可能在正确的轨道上你的过程。最重要的是它适用于你的情况。

票数 1
EN
页面原文内容由Stack Exchange QA提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://sqa.stackexchange.com/questions/8108

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档