认识达内从这里开始

测试用例是软件测试程序员在工作中会经常用到的一个测试工具，而本文我们就通过案例分析来简单了解一下，测试用例设计都需要关注哪些问题。

一、ISEB/ISTQB

软件测试基础突出七项原则。这些原则提醒我们并降低(一些)成员对有时会超出我们控制的各种挑战的期望。解释并使参与的每个人都了解到这些原则将导致现实的结果和一个更愉快的合作环境。

1.测试将显示出缺陷的存在。开始设计更多将显示缺陷的测试。“幸福路径”应该会起作用，当然，除非你质疑交付测试的代码质量。

2.许多情况下都不可能测试一切。建议使用风险分析并优先关注测试工作的重点。接受一个事实：没有一个各种组合和排列的测试会降低压力水平和期望。有时候会错过一些事。如果你想要20个测试，好设计100个测试，再从中挑选出好的20个。

3.开发生命周期中尽可能早地开始测试活动。别以为测试只是一旦产品可执行时用来确认和验证产品的功能的。相比后来在SDLC这样做，在验收前正在审核要求时设计测试，比起在SDLC中晚点这么做，可以获得很高的投资回报率。

4.缺陷很集中。测试执行后不要停止设计新测试。如果时间够的话，审查被排除在(与在其中新发现的缺陷被确定的组成部分相关的)初范围外的测试集合中的一些测试。

5.在某些时候，系统会对被多次反复的测试“免疫”。再次强调，在设计好的测试停止寻找缺陷后不要停止设计新测试。审查被排除在初范围外的测试集合，或者利用更多测试技巧拓宽缺陷类型。

6.你如何设计测试受到正在开发的系统的环境和业务领域的形式影响。不是每个人都在建桥梁。此外，根据测试水平去设计测试。

7.如果你曾经用代码设计了很多测试，后来实现了代码并不能解决用户的需求和期望，那一刻就像在经历一次史诗级的失败。如果规范欠缺，就根据用户期望系统如何工作以及它将如何满足他们的需要去考虑设计测试。不要依赖代码作为规范的来源。

二、确定测试什么，为何要测试，以及如何测试。

在团队中或和不明白测试目的和目标的人一起工作时，这就变得非常具有挑战性的(有时候争权夺利的)。开发生命周期及利益相关者和团队的成熟度或许会成为在设计好测试时有创意的主要障碍。确定测试的内容就要在分析需求时提出正确问题。根据我的经验，将这些问题基于ISO/IEC25010:20113标准文档中所提到作为一个起点的软件质量特点是正确方向上迈出的一步。我觉得把这些特性包括问题中是一种非常有效的收集信息并阐明规格(尤其是与敏捷团队合作时)，因为它提供了一个机会来定义超出原所有者认为的需求细节。他们也许之前没有帮助确定可测试的细节。试着预测使用这些高水平质量特点时可能出现的客户需求和经验方面的问题：

1.功能

2.可靠性

3.可用性

4.效率

5.可维护性

6.便携性

这些高水平特点有子特点，如：精度，性能，可变性，可安装性等等。现在，你应该能够根据计划，预算和可用资源去选择合适的测试技术了。

我认为软件开发中不常被提到的一个特点是可测试性。如果你曾经设计过电子电路和组件，那么你就会明白DFT(为可测试性而设计)的惊人效益，或当工程师把BIST(内建自测试)包含到他们的设计能力中时。许多软件产品是以一种非常耗时的，容易出错的且很难测试方式设计的。

理论上，DFT将在设计阶段从测试考虑输入，以便早早地设计出更好地测试。可测试性的一个简单的例子是，如果配置设置被存储在数据库中，但它仅在系统启动时加载。在某些环境中执行重启可能挺麻烦。可测试性将通过轻击开关或点击按钮来实现配置设置的动态重载。通过询问“我们如何测试，间隔多久需要回归一次呢?”开始测试性的讨论。团队成员更频繁地考虑简单性和自动化是非常令人兴奋的。

三、测试内容需是明确且“可测量的”。

这可能并不占设计测试多大部分，测试过程中需被测量的内容及测试过程的测试控制活动有望被定义。测试就像团队的照明灯。测试活动应该指导团队使他们能够避开障碍。奇怪的是，这是后一件需要考虑的事。所以，我只是想把它作为一个提醒。在某些时候，你会想提供反馈，例如：

1.测试工作。

2.改进测试重点。

3.向别人证明一些事。

4.提高覆盖率和技术。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。