检查产品说明书

第一部分——软件测试基本概念:我是传送门,可以点我
第二部分——软件开发过程:我是传送门,可以点我
第三部分——软件测试的实质:我是传送门,可以点我


这种方式适合在项目早期介入,并且有权修改初期的产品说明书。
在此阶段极有可能为项目节省大笔开销和时间。

开始测试

    在第二部分——软件开发过程所讲述的四种开发模式中,除了大爆炸模式,每一种模式中开发小组都需要根据需求文档编写一份产品说明书,用以定义软件是什么样的。
    所以,编写详细产品说明书的另一个好处是软件测试可以将其作为测试项目的书面材料。据此可以写编写代码之前找出软件缺陷。

黑盒测试

    先输入,然后观察输出结果。不必明白程序是如何做的,也不需要程序为什么这样做,只需要知道程序做了什么。
    因此黑盒测试有称为功能性测试或者行为测试。
    举例来说,假如产品说明书告诉你按下ON键可以开机,那么你就执行这个操作,观察是否可以开机。当执行求和运算时,输入6+9,观察结果,这个过程你无需知道程序如何实现这个加法,也不用关心为什么会出现这个结果,只需要观察这个结果。

白盒测试

    可以访问程序员的代码
    因此也被称为透明盒测试
    白盒测试要冒一定的风险,因为要以适应代码操作来定制测试,所以很容易形成偏见而无法进行客观测试。

静态测试

    测试不运行的部分,即,只进行检查和审核。
    举例来说是开车前绕行一周,检查一下车的轮胎、车漆等
    测试产品说明书就属于静态黑盒测试。
    如果产品没有测试产品说明书,那么总会有人知道产品是什么,这个人可能是开发人员,可能是项目经理,或者销售人员。走路、谈话和产品说明书一样都使用同样的技术来评估”大脑中的“说明书。记下收集到的信息并反复斟酌就可以得到更详细的资料。

动态测试

    这个就是我们通常意义上的测试,使用或者运行软件。
    举例来说就是打开引擎,听听发动机的声音,上路行驶等。

对产品说明书进行高级审查

    软件测试不应该是盲目的,需要有条理的进行,需要站在一定的高度进行。把握下面的一些原则,会很有帮助

假设自己是客户

    研究一下客户会是什么人,和市场人员或销售人员聊一下,了解他们对最终用户的认识。如果是一个内部使用的软件项目,找到使用它的人谈一谈。
    了解客户所想的是什么重要的。
    需要特别注意:如果审查说明说中,有不懂的地方,正确是做法不是放过不管,而是最好现在就搞懂或者请教别人。举例来说,假设这款软件是医学处理软件,相关的专业知识你并不是很了解,对于你不了解的部分不应该直接放过不进行测试,而应该想办法补充相关知识完成测试。
    还有一个问题:对于安全性来说,客户可能会假设软件是安全的,但是对于进行测试的你来说,不能做这样的假定。必须学汇正确处理安全问题。

研究现有的标准和规范

下面的一些例子是可以考虑作为标准和规范的例子,但不是明确规定。
    公司管惯用语和约定
    行业要求
    政府标准
    图形用户界面
    安全标准

标准和规范的区别:
标准比规范更加严格。标准应该严格遵守,规范是可选的,应该遵守。

审查和测试类似软件

    了解软件最终结果的最佳方法就是研究类似软件。类似软件有助于设计测试条件和测试方法,还可能暴露意想不到的潜在的问题。
需要注意以下问题:
    规模
    复杂性
    测试性
    质量和可靠性
    安全性

产品说明书的低层次测试技术

    完成产品说明书的高级审查之后,就可以很好的了解产品以及影响其设计的外部因素。

    一个优秀的说明书应该有如下8各属性:
完整、准确、清晰、一致、贴切、合理、代码无关、可测试性。

    注意一些说明书术语,例如:

  •     总是、每一种、所有…:注意,你需要考虑违反这些情况的例子。
  •     当然,因此、明显…:注意,你需要知道他在视图说服你接受这种情况,不要上当!
  •     某些、有时、常常…:注意,这太模糊了!
  •     良好、迅速、廉价…:注意,这是无法测试的,说明清单应该说明清楚的。
  •     处理、进行、拒绝…:注意,这是无法量化的,必须进一步确定准确定义和含义
  •     如果…那么…:注意,想一想没有”如果“会发生什么。

猜你喜欢

转载自blog.csdn.net/weixin_44895666/article/details/108699465
今日推荐