第二个挑战是确定测试什么，为何要测试，以及如何测试。
　　在团队中或和不明白测试目的和目标的人一起工作时，这变得非常具有挑战性的（有时候争权夺利的）。开发生命周期及利益相关者和团队的成熟度或许会成为在设计好测试时有创意的主要障碍。确定测试的内容要在分析需求时提出正确问题。根据我的经验，将这些问题基于ISO / IEC 25010:20113标准文档中所提到作为一个起点的软件质量特点是正确方向上迈出的一步。我觉得把这些特性包括问题中是一种非常有效的收集信息并阐明规格（尤其是与敏捷团队合作时），因为它提供了一个机会来定义超出原所有者认为的需求细节。他们也许之前没有专家帮助确定可测试的细节。试着预测使用这些高水平质量特点时可能出现的客户需求和经验方面的问题：
　　1. 功能
　　2. 可靠性
　　3. 可用性
　　4. 效率
　　5. 可维护性
　　6. 便携性
　　这些高水平特点有子特点，如：精度，性能，可变性，可安装性等等。现在，你应该能够根据计划，预算和可用资源去选择合适的测试技术了。
　　我认为软件开发中不常被提到的一个特点是可测试性。如果你曾经设计过电子电路和组件，那么你会明白DFT （为可测试性而设计）的惊人效益，或当工程师把BIST （内建自测试）包含到他们的设计能力中时。许多软件产品是以一种非常耗时的，容易出错的且很难测试方式设计的。
　　理论上，DFT将在设计阶段从测试专家考虑输入，以便早早地设计出更好地测试。可测试性的一个简单的例子是，如果配置设置被存储在数据库中，但它仅在系统启动时加载。在某些环境中执行重启可能挺麻烦。可测试性将通过轻击开关或点击按钮来实现配置设置的动态重载。通过询问“我们如何测试，间隔多久需要回归一次呢？”开始测试性的讨论。团队成员更频繁地考虑简单性和自动化是非常令人兴奋的。研究为一般软件设计问题提供指导及技巧以帮助发现问题的测试模式是有益处的。“我们长期辛苦去打造一个天堂，结果却发现它填充了恐怖。 ”——选自Alan Moore的《守望者》
　　第三，测试内容需是明确且“可测量的”。
　　这可能并不占设计测试多大部分，测试过程中需被测量的内容及测试过程的测试控制活动有望被定义。测试像团队的照明灯。测试活动应该指导团队使他们能够避开障碍。奇怪的是，这是后一件需要考虑的事。所以，我只是想把它作为一个提醒。在某些时候，你会想提供反馈，例如：
　　1. 测试工作。
　　2. 改进测试重点。
　　3. 向别人证明一些事。
　　4. 提高覆盖率和技术。
　　看一个测试用例需要什么信息的良好的开端是读取IEEE 8292标准文件。从这里你可以排除那些从长远看来无关紧要的项目，或根据需要添加更多项目。确定需要什么样的报告，然后寻找能够尽快产生这些报告的佳工具。不幸的是，测试往往是非常依赖工具来处理大量信息，但工具也可能对测试形式有影响，并需要流程去确保信息准确。（你是否曾经被要求“调整”数据，掩盖报告中“无效”数据，或收到过了一份其结果不稳定到甚至斯蒂芬?霍金都站起来含泪走出房间的报告？）记得用和审查代码一样的方式经常检查测试。这样能持续改进。我希望这篇短短的文章为提供了一些理论或实践指导并引起对设计好测试用例的讨论。