大话测试数据（二）：概念测试数据的获取

在大话测试数据（一）文章中，我提到，获取数据的第一步是获取概念上数据。这一步看起来简单，其实不是那么容易。获取概念数据和获取需求的过程是交织在一起的，事实上，它们其实是一个事儿，因为数据是需求中最重要的组成部分。 需求工程是个大话题，目前有很多种流派和实践方式来来搞定需求，但它们的思想都比较一致，那就是：不断的由粗到精的迭代（如下图）。关于需求这里不再展开，如果大家有兴趣的话，推荐两本我觉得还不错的书：德国人写的《需求工程，基础原理和技术》和国人写的《软件需求最佳实践》，大家读后结合工作实践会很有收获。

由上述文字可知，（测试）数据获取也是一个迭代的过程。实际上在项目早期，我们就能获得概念数据。概念数据是什么呢？用大白话说就是：这种数据叫什么，大体啥样子，是干嘛用的。

举个例子： 如果你的项目是一个信用卡项目，项目有一个功能就是，每月给用户发送“电子对账单”。对于80后，甚至90后的你，一秒钟你就知道这个“电子对账单”大概将会是个什么东西了。“不就是一封电子邮件里放一个网页，里边告诉用户：尊敬的某某先生/小姐！您本月消费了几笔，每笔多少钱，都是哪一天花的。最重要的是，您在本月X日前必须把钱还了。“这样你就建立了对“电子对账单”这种测试数据的概念，也就是说得到了“电子对账单”这种概念的测试数据。 Pretty easy？事实没有那么简单的。事情的本质是：你有一个超级聪明的大脑，能瞬间把你的经验综合起来对需要识别的东西作一判断，并给出一个大致的评估。但如果你大脑没有相关的知识，你就没有那么幸运了。不信，请读一下下图中的文字：

脂多糖是神马？膜蛋白复合体是神马？神马是beta链？桶壁是神马？？？？这特么的都是神马？如果你没有一些生物学知识、高中生物又不幸光睡觉了的话，这段选自《环球科学》的文字不会让你觉得比读日文简单。

因此识别概念上的测试数据，你脑子里还得有点儿货才行，这些货是：“技术层面的知识”，“业务层面的知识（领域知识）”，“对于产品本身的认识”，还有“你的常识”。这四点的总结是从测试大师 James Bach 的课程中获取的，你可以尝试获取他关于快速软件测试的 PDF 文件。 你说了，没有这些知识怎么办？答案特别简单，“学啊”！。勤学勤问勤练勤观察，入行几年后，如果不是特别懒惰，前三项都会提高到一个不错的高度。这些都变成了你的价值。经过一段时间爬坡，你就可以很快的获取概念测试数据了。

你说了，废话，我也知道要学，但有没有更具体点儿的？干货，有么？要能咯掉牙的！ 好吧，可以参考下面的干货资料（英文版，也正好练习下英文），你就当它是个 checklist，按图索骥吧：关于测试数据的获取（不仅仅是概念测试数据的获取），测试思路的获取，甚至是需求的获取，你一定会有收获。 ‎我们建议从各种信息源持续收集测试想法。

‎ ‎考虑以下几点，并考虑价值观，风险，机遇;找到快捷方式来涵盖重要内容。

‎ ‎ 1.功能。‎

‎第一个显而易见的测试想法涉及产品应该做什么。一个好的开始是需求，示例和其他规范，或者从实际软件创建的功能列表。但也要尝试识别隐式需求，即用户期望尚未记录的内容。警惕不需要的功能。‎

‎ 2.故障模式。‎ ‎软件可能以多种方式失败，因此请询问“假设”问题以制定测试想法，以揭示内部/外部，预期/意外，（非）故意，现实/挑衅失败的处理。挑战系统的容错能力;任何对象或组件都可能中断。‎

‎ 3.质量特点。‎ ‎质量特征对于项目的成功始终很重要，尽管OK区可能很容易到达，或者困难而关键。我们的定义包括功能，可靠性，可用性，魅力，安全性，性能，IT可用性，兼容性，可支持性，可测试性，可维护性，可移植性以及大量子类别。‎ ‎其中许多可以用作您脑后的持续测试想法，免费执行，但可以识别违规行为。‎

‎ 4.使用场景。‎ ‎用户希望使用软件完成或体验某些事情，因此请创建以多种方式模拟产品行为序列的测试，而不是孤立地使用功能。‎ ‎您知道的可信使用模式越多，您可以执行的测试就越真实。古怪的肥皂剧测试扩大了覆盖范围。‎

‎ 5.创意。‎ ‎所有产品都是独一无二的，需要一些以前从未见过的测试想法。尝试横向思维技巧（例如Edward De Bono的Six Thinking Hats，挑衅性运算符，相反，随机刺激，Google Goggles）来提出创造性的测试想法。‎ ‎隐喻和类比是让你开始新方向的好方法。‎

‎ 6.型号。‎ ‎状态模型有助于识别围绕状态、转换和路径的测试想法。系统解剖图显示可以测试的内容，并可以突出显示相互作用。使用启发式测试策略模型中的 SFDPOT 等结构创建自定义模型。‎ ‎可视化模型更容易沟通，建模活动通常会带来理解和新想法。‎

‎ 7.数据。‎ ‎通过识别有意和无意的数据（总是有噪音），你有一堆测试想法的良好开端。通过应用程序跟踪简单而棘手的数据，进入边界内外，使用CRUD（创建，读取，更新，删除），利用依赖关系，并在许多地方查看数据。‎

‎ 8.周围环境。‎ ‎环境兼容性（硬件、操作系统、应用程序、配置、语言）是一个重要的测试问题，但也会调查产品附近的活动。通过了解大型系统，您可以获得可靠的测试想法，这些想法在孤立地查看功能时是牵强附会的。‎

‎ 9.白盒。‎ ‎通过将测试人员的破坏性思维方式放在开发人员对架构，设计和代码的角度上，您可以挑战假设，也可以发现错误。特别注意从黑匣子角度可能无法理解的决策和路径。代码覆盖率并非毫无价值，它可以用来查找尚未测试的内容。‎

‎ 10.公共收藏。‎ ‎利用一般或特定的错误列表、编码错误或测试想法。当您构建适合您的情况的清单时，请尝试以下操作：‎

‎ •测试计算机软件的附录A（Kaner，Falk和Nguyen）‎ ‎•Boris Beizer Taxonomy（Otto Vinter）‎ ‎•购物车分类法（Giri Vijayaraghavan）‎ ‎•测试启发式备忘单（Elisabeth Hendrickson）‎ ‎•您尚未完成（Michael Hunter）‎ ‎ 从书籍，博客，会议中学习一些测试技巧或技术;搜索测试设计启发式方法，或为您发明最好的方法。‎

‎ 11.内部收藏。‎ ‎使用或创建在您的上下文中通常很重要的事物列表，有些人称之为质量/测试模式。

‎ ‎ 12.经营目标。‎ ‎公司（和部门分解）的首要目标是什么？是否有任何要求与这些目标相矛盾？您是否了解大局、产品愿景和价值驱动因素？‎

‎ 13.信息目标。‎ ‎测试的显式和隐式目的是您工作的重要指南。如果您没有它们，则可以创建质量目标，以指导任何功能的测试想法。‎

‎ 14.产品图片。‎ ‎产品旨在显示的行为和特征可能是明确的或隐含的，在生产或消费软件的人的墙壁和思想中。‎ ‎如果您知道并能够显示对产品形象的威胁，您将能够撰写引人注目的问题报告，例如通过指出违反营销材料的行为。‎

‎ 15.产品恐惧。‎ ‎利益相关者真正担心的事情比风险要强得多，他们不需要优先考虑，他们需要测试。典型的难以验证但对测试有用的担忧是：图像丢失，错误的决策，损坏，人们不会喜欢该软件。不同的人有不同的恐惧;找出哪个最重要。‎

‎ 16.项目风险。‎ ‎项目中的一些困难可以通过测试来解决。您想知道开发人员在哪些功能方面遇到了问题，并且您将根据首先需要缓解的风险调整您的日程安排。

‎ ‎ 17.谣言。‎ ‎通常有很多关于质量和问题的讨论。有些损害了产品和组织。使用谣言本身作为测试想法。杀死他们或证明他们是正确的是你的任务。‎

‎ 18.产品历史。‎ ‎旧问题可能会以新的形式出现。搜索您的错误/支持系统或创建错误目录，记住关键故障和根本原因分析。使用旧版本的软件作为灵感和预言机。‎

‎ 19.测试工件。‎ ‎不仅您自己的测试想法，日志和结果可用于子连续测试，还可以尝试其他项目的测试结果，Beta测试报告，可用性评估，第三方测试结果等。您希望在未来‎ ‎的状态报告中能够回答哪些问题？‎

‎ 20.债务。‎ ‎由于所有的捷径，债务在不断增长。这可能是项目债务，管理债务，技术债务，软件债务，测试债务或任何你想称之为的东西。如果团队跟踪债务清单上的内容，您可以针对这些项目映射一组测试想法。‎

‎ 21.业务知识。‎ ‎如果您了解该软件的目的及其运行环境，您就可以了解它是否会为客户提供价值。如果你无法获得这些知识，请与了解需求，逻辑和环境的人合作。‎

‎ 22.字段信息。‎ ‎除了了解客户故障，他们的环境，需求和感受之外，您还可以花时间在错误和成功模式下了解您的客户。面试售前，销售，营销，顾问，支持人员，甚至更好的：在那里工作一段时间。‎

‎ 23.用户。‎ ‎想想不同类型的用户（你认识的人，角色），不同的需求，不同的感受和不同的情况。‎ ‎找出他们喜欢和不喜欢什么，以及他们在您的软件旁边做什么。在测试实验室中设置一个场景，在其中分配测试人员扮演不同的用户角色，由此触发了哪些测试想法？最好的当然是直接来自用户的未经过滤的信息，在他们的上下文中。‎ ‎请记住，两个相似的用户可能对同一区域的看法截然不同。

‎ ‎ 24.对话。‎ ‎您从人们那里获得的非正式信息可能包含比规范中包含的内容更重要的内容。很多人可以帮助你进行测试设计，有些人是更好的重要判断者，你能从MIP：s（顺便提到）中得到什么？‎ ‎如果开发人员知道你可以找到有趣的东西，他们可能会给你关于软件可疑部分的内幕信息。对开发人员的一系列问题可能是无辜的“你认为我们应该测试什么？”或者“你希望代码的哪个部分做得更好？”‎

‎ 25.实际软件。‎ ‎通过与软件交互，您将获得很多关于容易出错，连接，有趣的想法。如果你能吃自己的狗粮（委婉的说法：喝自己的香槟），你就能更好地理解软件的重要之处。如果“质量对某些人有价值”，那么如果那个人是“我”就很好了。‎

‎ 26.技术。‎ ‎通过了解软件运行所采用的技术的内部工作原理，您可以看到有问题的领域和容易出错的地方;了解可能性和安全方面;更改哪些参数，以及何时更改。您可以进行正确的更改，并与开发人员进行技术讨论。‎

‎ 27.标准。‎ ‎挖掘相关的商业标准、法律法规。阅读并理解用户界面标准、安全合规性和策略。有一些文章描述了即使它符合标准，你也可以打破它，你能把他们的测试想法包含在你的测试中吗？‎

‎ 28.参考资料。‎ ‎各种参考资料是预言机和测试灵感的良好来源，例如地理产品的地图集。所有类型的一般知识都很方便，维基百科足以快速了解统计方法。‎

‎ 29.竞争对手。‎ ‎通过查看类似问题的不同解决方案，您可以获得直接的测试想法，还可以了解最终用户可能关注哪些特征。可能有内部解决方案（例如Excel工作表）可以受到启发，并且通常存在用于类似目的的模拟解决方案。您能否从竞争对手的支持、常见问题解答或其他材料中获得任何有见地的测试想法？‎

‎ 30.工具。‎ ‎如果某件事可以非常快地完成，那么尝试一下是个好主意。工具不仅是达到目的的手段，还可以作为探索的起点。‎

‎ 31.上下文分析。‎ ‎在当前情况下，还有什么应该影响你测试的东西，以及如何？您了解市场力量和项目驱动因素吗？是否有任何变化应该导致新的测试方法？其他人测试了什么？‎

‎ 32.法律方面。‎ ‎您是否需要考虑合同、处罚或其他法律义务？在法律问题上，公司付出的最大代价是什么？你有没有律师可以给你提示必须避免什么？‎

‎ 33.许多可交付成果。‎ ‎有很多东西需要测试：可执行文件，安装工具包，编程接口，扩展，代码和注释，文件属性，帮助，其他文档，发行说明，自述文件，营销，培训材料，演示等。所有这些都包含您可以用作灵感的信息。‎

‎ 34.你！‎ ‎您的经验，知识，技能，感受，主观性和对问题的熟悉程度。您要测试什么？‎ ‎顺便说一句‎，在接下来的文章中，我将会着重讲解如何获取细化的测试数据。