?
 |
Nicolaas Kotze是一个有着离奇扭曲幽默感（这种幽默感讽刺地与墨菲定律及对详细解释质量是如何被感知的人类行为的理解很好结合了起来）的自信的现实主义悲观者。他在英国伦敦时开始接触游戏行业的测试，并头冠不少AAA级称号。 他的测试职业生涯正式开始于回到南非测试(使用用来自荷兰客户公共服务交付领域的谷歌地图的)GIS软件系统，再后来他转移到繁忙的零售信贷和金融服务业。他选择测试为职业道路是因为它使人们能够将创造性思维融入常规程序或规定中，且仍有“打破”东西的令人振奋的快感。测试与许多其他学科和专业交织在一起这件事是：主要驱动力让事情一直有趣且充满挑战。 目前他担任动态可视化技术（ DVT）开普敦的一名SQA的Competency 领导的职责是：将其热情和精力投入指导，激励，帮助，并使人们了解测试及改进更有效测试流程的好处。已经从正在打印取得了经验，数码影像制作/销售/支持/培训/特效，及在接触测试前成为一名办公自动化领域的技术人员赋予他技巧去理解挫败人们的问题及能有效支持人们所需要的。 欲了解更多详情，可以访问za.linkedin.com/in/nicolaasjkotze查看他的LinkedIn个人资料。 ? |
?
很多测试用例设计很少或根本不费什么力（只需搜索我们社交媒体上的所有建议），但设计好的测试用例是复杂且极具挑战性的。为设计好的测试提供资源这一点往往很容易被对编写和执行测试不负责的人所忽视。更不要说为获得足够的使我们能够衡量我们测试工作成效的报告需要了解哪些信息了。然后还需要有可以定义（或有时甚至强制执行）所需测试的组织，开发团队，测试团队，流程及工具。搜索讨论板时，很多人在上面寻找通用解决办法的并不意外。
互联网上和书中有足够多的信息介绍：如何分析需求，应用测试设计技术，并将它们实施和执行。我建议去看看Cem Kaner写于2003年的题为《什么是好的测试用例？》的一份简短却详细的研究报告。它引用一大堆参考文献，提供了充足的信息让你能基本了解。
在这篇简短的文章中，我不会解释如何应用测试技术，而会分享信息作为需要考虑的因素的入门指南，使我们能够设计出好的测试，我希望我能为读者创造一个分享他们经验的平台。这里的内容是基于我的解决呈现在我面前的挑战的测试经验。我也是假设读者有一些正式的测试经验且已对测试设计技术有了理解才写的这篇文章。
在阅读这篇文章时，我不断查阅测试设计的高层次目标和因素：
1. 合并测试分析中定义的执行状态。
2. 建立特定输入。
3. 根据输入和规范定义预期结果。
和一些基本因素：
1. 覆盖范围。
2. 有效性。
3. 弹性和维护。
4. 执行者的技能。
?
我们遇到的影响设计出好测试的第一个挑战是使每个人都了解测试原则。
ISEB / ISTQB
软件测试基础突出七项原则。这些原则提醒我们并降低（一些）成员对有时会超出我们控制的各种挑战的期望。解释并使参与的每个人都了解到这些原则将导致现实的结果和一个更愉快的合作环境。
1 .测试将显示出缺陷的存在。开始设计更多将显示缺陷的测试。 “幸福路径”应该会起作用，当然，除非你质疑交付测试的代码质量。
2 . 许多情况下都不可能测试一切。建议使用风险分析并优先关注测试工作的重点。接受一个事实：没有一个各种组合和排列的测试会降低压力水平和期望。有时候会错过一些事。如果你想要20个测试，最好设计100个测试，再从中挑选出最好的20个 。
3. 开发生命周期中尽可能早地开始测试活动。别以为测试只是一旦产品可执行时用来确认和验证产品的功能的。相比后来在SDLC这样做，在验收前正在审核要求时设计测试，比起在SDLC中晚点这么做，可以获得很高的投资回报率。
4.缺陷很集中。测试执行后不要停止设计新测试。如果时间够的话，审查被排除在（与在其中最新发现的缺陷被确定的组成部分相关的）最初范围外的测试集合中的一些测试。
5.在某些时候，系统会对被多次反复的测试“免疫”。再次强调，在设计好的测试停止寻找缺陷后不要停止设计新测试。审查被排除在最初范围外的测试集合，或者利用更多测试技巧拓宽缺陷类型。
6.你如何设计测试受到正在开发的系统的环境和业务领域的形式影响。不是每个人都在建桥梁。此外，根据测试水平去设计测试。
7.如果你曾经用代码设计了很多测试，后来实现了代码并不能解决用户的需求和期望，那一刻就像在经历一次史诗级的失败。如果规范欠缺，就根据用户期望系统如何工作以及它将如何满足他们的需要去考虑设计测试。不要依赖代码作为规范的来源。
?
? 第二个挑战是确定测试什么，为何要测试，以及如何测试。
在团队中或和不明白测试目的和目标的人一起工作时，这就变得非常具有挑战性的（有时候争权夺利的）。开发生命周期及利益相关者和团队的成熟度或许会成为在设计好测试时有创意的主要障碍。确定测试的内容就要在分析需求时提出正确问题。根据我的经验，将这些问题基于ISO / IEC 25010:20113标准文档中所提到作为一个起点的软件质量特点是正确方向上迈出的一步。我觉得把这些特性包括问题中是一种非常有效的收集信息并阐明规格（尤其是与敏捷团队合作时），因为它提供了一个机会来定义超出原所有者认为的需求细节。他们也许之前没有专家帮助确定可测试的细节。试着预测使用这些高水平质量特点时可能出现的客户需求和经验方面的问题：
1. 功能
2. 可靠性
3. 可用性
4. 效率
5. 可维护性
6. 便携性
这些高水平特点有子特点，如：精度，性能，可变性，可安装性等等。现在，你应该能够根据计划，预算和可用资源去选择最合适的测试技术了。
我认为软件开发中不常被提到的一个特点是可测试性。如果你曾经设计过电子电路和组件，那么你就会明白DFT （为可测试性而设计）的惊人效益，或当工程师把BIST （内建自测试）包含到他们的设计能力中时。许多软件产品是以一种非常耗时的，容易出错的且很难测试方式设计的。
理论上，DFT将在设计阶段从测试专家考虑输入，以便早早地设计出更好地测试。可测试性的一个简单的例子是，如果配置设置被存储在数据库中，但它仅在系统启动时加载。在某些环境中执行重启可能挺麻烦。可测试性将通过轻击开关或点击按钮来实现配置设置的动态重载。通过询问“我们如何测试，间隔多久需要回归一次呢？”开始测试性的讨论。团队成员更频繁地考虑简单性和自动化是非常令人兴奋的。研究为一般软件设计问题提供指导及技巧以帮助发现问题的测试模式是有益处的。“我们长期辛苦去打造一个天堂，结果却发现它填充了恐怖。 ”——选自Alan Moore的《守望者》
?
第三，测试内容需是明确且“可测量的”。
这可能并不占设计测试多大部分，测试过程中需被测量的内容及测试过程的测试控制活动有望被定义。测试就像团队的照明灯。测试活动应该指导团队使他们能够避开障碍。奇怪的是，这是最后一件需要考虑的事。所以，我只是想把它作为一个提醒。在某些时候，你会想提供反馈，例如：
1. 测试工作。
2. 改进测试重点。
3. 向别人证明一些事。
4. 提高覆盖率和技术。
看一个测试用例需要什么信息的良好的开端就是读取IEEE 8292标准文件。从这里你可以排除那些从长远看来无关紧要的项目，或根据需要添加更多项目。确定需要什么样的报告，然后寻找能够尽快产生这些报告的最佳工具。不幸的是，测试往往是非常依赖工具来处理大量信息，但工具也可能对测试形式有影响，并需要流程去确保信息准确。（你是否曾经被要求“调整”数据，掩盖报告中“无效”数据，或收到过了一份其结果不稳定到甚至斯蒂芬?霍金都站起来含泪走出房间的报告？）记得用和审查代码一样的方式经常检查测试。这样就能持续改进。我希望这篇短短的文章为提供了一些理论或实践指导并引起对设计好测试用例的讨论。
版权声明：本文出自 SPASVO泽众软件测试网：http://www.spasvo.com/news/html/201456140230.html
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
原文：http://my.oschina.net/spasvo/blog/293777