• 0
  • 0
分享

读者提问:
软件测试行业是如何发展起来的,软件测试的定义是什么呢 ?

阿常回答:

从软件开发一开始就有软件测试了,起初的软件测试严格来说,不能算作真正的软件测试,是由开发人员完成的 “调试”。

1975年《软件数据选择的原理》将软件测试定义为 :“ 证明软件测试工作是正确 ” 的活动,即 “ 证实 ”。
1979年《软件测试艺术》将软件测试定义为 :“ 发现错误而执行的活动 ”,即 “ 证伪 ”。

1983年《软件测试完全指南》将软件测试定义为:“ 测试是以评价一个程序或者系统属性为目标的任一活动,测试是对软件质量的度量。”,即 “ 预防 ”。
2002年《系统的软件测试》将软件测试定义为:“ 测试是为了度量和提高被测软件的质量,对测试软件进行工程设计、实施和维护的整个生命周期过程。”,进一步丰富了软件测试的内容。

阿常碎碎念:

软件测试的核心是 “ 测试策略 ”,包括 “ 测什么 ” 和 “ 怎么测 ”。


1、测试的对象和范围;

2、测试的目标;

3、测试的重点和难点;

4、测试的深度和广度;

5、先测试什么,后测试什么;

6、如何评估测试效果。

这就需要我们基于 “ 产品的质量目标 ”,基于 “ 风险 ”,充分考虑 “ 产品研发状况 ” 前提下安排各种测试活动,在有限的时间里进行 “ 刚刚好 ” 的测试。

测试架构师修炼之道

看完今天的分享对你是不是有所启发呢,有任何想法都欢迎大家后台私信阿常,一起探讨交流。

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   大多数的性能测试工作人员分为以下三个阶段:  1、出了问题看资源,资源占用如果很高,报以窃喜的心态,恩,发现了,原理是资源瓶颈。  2、资源没有出现瓶颈,通过一些技术手段分析,发现是组件的配置文件有问题,例如:server的并发策略有问题,带宽有问题,找到了线路短板性能中的短板,到了这个阶段在我看来是比较牛的测试。  3、以上均无问题的情况下,考虑数据结构和算法我个人接触到的来说,现在大多数的人员都是在仰望第二阶段,摸索第三阶段,希望从代码级发现出性能的问题,进行问题的发现和解决,也符合我们的bug越早发现修复的成本越低的理论。同时,也是一名性能测试工程师高薪的象征。  性能测试调优哪些方...
            0 0 805
            分享
          •   有道是:“观史知今当思进退,读书养志可识春秋”。  列数最近十年的重要进展,其目的还是要我们带着发展的眼光,来预测未来几年测试领域的发展,提前做好准备。  所以为了让大家阅读此文后有尽可能强烈的获得感,本文行文结构如下:  一、回顾软件测试发展的五个重要时期:  ·1957之前 - 以调试为主:独自承担需求分析,设计,研发,调试,也就是Debug。  · 1957-1978 - 以证明为主:确保程序解决它该解决的问题,证明软件是否符合需求,证明确实是有缺陷的。  · 1979-1982 - 以破坏为主:在符合需求的情况下,通过异常测试的方法,明确软件应该做什么,不应该做什么。  · 198...
            0 0 1373
            分享
          •   及时同步信息  在工作中,出现问题时应及时跟进并向关键人员同步进展。但实际工作中,比较常见的是问题出现后,你跟进得可能很及时,但问题产生的原因、影响、进展情况等信息的同步往往比较滞后,通常是主管或项目干系人询问你,你才反馈出来。如果你存在这样的情况,那么本文就是为你准备的。  一个问题的生命周期大体包含问题出现、问题发现、问题分析,问题定位,问题解决或改进几个环节,发现问题时就应该同步,而不是问题解决或改进了再同步。对于QA来说,日常工作的信息同步有两大类场景,一类是线上问题的同步,一来是项目进展的同步。  关于线上问题的同步  发现线上问题时,应第一时间反馈给你的主管。大体上包含如下几块...
            0 0 623
            分享
          •   似乎这个问题看起来应该挺简单的,但是根据我所遇到的问题,有时候遇到的问题看起来是后端缺陷,但其实是前端缺陷。  有时候遇到的问题,看起来是前端缺陷,但却是后端缺陷。  问题  【项目管理】下车金融项目增加产品,提交成功后,再进入页面发现没有增加的产品。  原因分析  新增产品后,再次进入产品信息页面没有展示新增产品问题的可能原因有:  问题排查  F12,查看增加产品点击【提交】后,是否有触发接口。如果没有触发接口,查看控制台是否有异常。没有触发接口,可以判断为前端缺陷。  如果触发了接口,查看日志是否有异常。  在我们不熟悉日志的情况下,我们有可能留意不到没有抛出异常的日志。  留意不到...
            0 0 899
            分享
          • 突变测试突变测试是一种白盒测试,其中一个程序的源代码被更改并验证现有的测试用例是否可以识别系统中的这些缺陷。程序源代码的变化很小,不会影响整个应用程序,只有有影响的特定区域和相关的测试用例才能识别出系统中的那些错误。负面测试测试人员的心态是“打破系统/应用程序”,它是通过负面测试来实现的。使用不正确的数据、无效数据或输入执行否定测试技术。它验证系统是否抛出无效输入错误并按预期运行。加载任何页面或系统不应花费太多时间,并且应在峰值负载期间持续。不同的性能和负载工具用于执行此测试。恢复测试这是一种测试,用于验证应用程序或系统从崩溃或灾难中恢复的程度。恢复测试确定系统在灾难后是否可以继续运行。假设应...
            0 0 1428
            分享
      • 51testing软件测试圈微信