很多测试用例设计很少或根本不费什么力（只需搜索我们社交媒体上的所有建议），但设计好的测试用例是复杂且极具挑战性的。为设计好的测试提供资源这一点往往很容易被对编写和执行测试不负责的人所忽视。更不要说为获得足够的使我们能够衡量我们测试工作成效的报告需要了解哪些信息了。然后还需要有可以定义（或有时甚至强制执行）所需测试的组织，开发团队，测试团队，流程及工具。搜索讨论板时，很多人在上面寻找通用解决办法的并不意外。
　　互联网上和书中有足够多的信息介绍：如何分析需求，应用测试设计技术，并将它们实施和执行。我建议去看看Cem Kaner写于2003年的题为《什么是好的测试用例？》的一份简短却详细的研究报告。它引用一大堆参考文献，提供了充足的信息让你能基本了解。
　　在这篇简短的文章中，我不会解释如何应用测试技术，而会分享信息作为需要考虑的因素的入门指南，使我们能够设计出好的测试，我希望我能为读者创造一个分享他们经验的平台。这里的内容是基于我的解决呈现在我面前的挑战的测试经验。我也是假设读者有一些正式的测试经验且已对测试设计技术有了理解才写的这篇文章。
　　在阅读这篇文章时，我不断查阅测试设计的高层次目标和因素：
　　1. 合并测试分析中定义的执行状态。
　　2. 建立特定输入。
　　3. 根据输入和规范定义预期结果。
　　和一些基本因素：
　　1. 覆盖范围。
　　2. 有效性。
　　3. 弹性和维护。
　　4. 执行者的技能。
　　我们遇到的影响设计出好测试的第一个挑战是使每个人都了解测试原则。
　　ISEB / ISTQB
　　软件测试基础突出七项原则。这些原则提醒我们并降低（一些）成员对有时会超出我们控制的各种挑战的期望。解释并使参与的每个人都了解到这些原则将导致现实的结果和一个更愉快的合作环境。
　　1 .测试将显示出缺陷的存在。开始设计更多将显示缺陷的测试。 “幸福路径”应该会起作用，当然，除非你质疑交付测试的代码质量。
　　2 . 许多情况下都不可能测试一切。建议使用风险分析并优先关注测试工作的重点。接受一个事实：没有一个各种组合和排列的测试会降低压力水平和期望。有时候会错过一些事。如果你想要20个测试，好设计100个测试，再从中挑选出好的20个 。
　　3. 开发生命周期中尽可能早地开始测试活动。别以为测试只是一旦产品可执行时用来确认和验证产品的功能的。相比后来在SDLC这样做，在验收前正在审核要求时设计测试，比起在SDLC中晚点这么做，可以获得很高的投资回报率。
　　4.缺陷很集中。测试执行后不要停止设计新测试。如果时间够的话，审查被排除在（与在其中新发现的缺陷被确定的组成部分相关的）初范围外的测试集合中的一些测试。
　　5.在某些时候，系统会对被多次反复的测试“免疫”。再次强调，在设计好的测试停止寻找缺陷后不要停止设计新测试。审查被排除在初范围外的测试集合，或者利用更多测试技巧拓宽缺陷类型。
　　6.你如何设计测试受到正在开发的系统的环境和业务领域的形式影响。不是每个人都在建桥梁。此外，根据测试水平去设计测试。
　　7.如果你曾经用代码设计了很多测试，后来实现了代码并不能解决用户的需求和期望，那一刻像在经历一次史诗级的失败。如果规范欠缺，根据用户期望系统如何工作以及它将如何满足他们的需要去考虑设计测试。不要依赖代码作为规范的来源。