启发式测试模型

The Heuristic Test Strategy Model is a set of patterns for designing and choosing tests to perform. The
immediate purpose of this model is to remind testers of what to think about during that process. I encourage
testers to customize it to fit their own organizations and contexts.
启发式测试策略模型是用于设计和选择要执行的测试的一组模式。**这该模型的直接目的是提醒测试人员在此过程中要考虑的问题。**我鼓励测试人员可以对其进行自定义，以适合自己的组织和环境。

一、Project Environment

Creating and executing tests is the heart of the test project. However, there are many factors in the project environment
that are critical to your decision about what specific tests to create. In each category, below, consider how that element
may help or hinder your test design process. Try to exploit every resource.
创建和执行测试是测试项目的核心。但是，项目环境中有很多因素这对于您决定要创建哪些特定测试至关重要。在下面的每个类别中，请考虑该元素如何可能会帮助或阻碍您的测试设计过程。尝试利用每种资源。

Mission. Your purpose on this project, as understood by you and your customers.

• Why are you testing? Are you motivated by a general concern about quality or specific and defined risks?
  你为什么要测试？您是否出于对质量或已定义风险的普遍关注的动机？
• Do you know who the customers of your work are? Whose opinions matter? Who benefits or suffers from the work you do?
  您知道工作的客户是谁吗？谁的意见重要？你的测试工作对谁有好处或有什么影响（以用户利益为出发点的测试才有价值）
• Maybe the people you serve have strong ideas about what tests you should create and run. Find out.
  也许您所服务的人员对应该创建和运行哪些测试有很强的想法
• Have you negotiated project conditions that affect your ability to accept your mission?
  你为什么要测试？您是否出于对质量或已定义风险的普遍关注的动机？

Information. Information about the product or project that is needed for testing.

• Whom can we consult with to learn about this project?
  我们可以向谁咨询了解这个项目?
• Are there any engineering documents available? User manuals? Web-based materials? Specs? User stories?
  有任何工程文件可用吗?用户手册吗?基于web的材料?规格吗?用户故事?
• Does this product have a history? Old problems that were fixed or deferred? Pattern of customer complaints?
  这个产品有历史吗?历史问题是修复了还是被遗留了?有客户投诉、反馈吗
• Is your information current? How are you apprised of new or changing information?
  你的信息是最新的吗?你是如何得知新的或不断变化的信息的?
• Are there any comparable products or projects from which we can glean important information?
  是否有可比较的产品或项目来收集重要的信息?

Developer Relations. How you get along with the programmers.

• Rapport: Have you developed a friendly working relationship with the programmers?
  亲和力:你是否与程序员建立了友好的工作关系?
• Hubris: Does the development team seem overconfident about any aspect of the product?
  傲慢:开发团队是否对产品的某个方面过于自信?
• Defensiveness: Is there any part of the product the developers seem strangely opposed to having tested?
  防御性:产品中是否有哪一部分是开发者奇怪地反对测试的?
• Feedback loop: Can you communicate quickly, on demand, with the programmers?
  反馈循环:你能按需与程序员快速沟通吗?
• Feedback: What do the developers think of your test strategy?
  反馈:开发者对你的测试策略有什么看法?

Test Team. Anyone who will perform or support testing.

• Do you know who will be testing? Do they have the knowledge and skills they need?
  您知道谁将要测试吗？他们是否拥有所需的知识和技能？
• Are there people not on the “test team” that might be able to help? People who’ve tested similar products before and might have advice? Writers? Users? Programmers?
  有没有那种不在你测试团队但可能对你的测试有帮助的人员？曾经测试过类似产品的人
• Are there particular test techniques that someone on the team has special skill or motivation to perform?
  团队是否有特殊的技能、动力、测试技术
• Who is co-located and who is elsewhere? Will time zones be a problem?
  有第三方的开发资源需要沟通交流吗

Equipment & Tools. Hardware, software, or documents required to administer testing.

• Hardware: Do you have all the physical or virtual hardware you need for testing? Do you control it or share it?
  硬件：您是否拥有测试所需的所有物理或虚拟硬件？您控制还是共享它？
• Automated Checking: Do you have tools that allow you to control and observe product behavior automatically?
  自动化：您是否具有可以自动控制和观察产品行为的工具？
• Analytical Tools: Do you have tools to create test data, design scenarios, or to analyze and track test results?
  分析工具：您是否具有创建测试数据，设计方案或分析和跟踪测试结果的工具？
• Matrices & Checklists: Are any documents needed to track or record the progress of testing?
  检查表：是否有文档来跟踪或记录测试进度？

Schedule. The sequence, duration, and synchronization of project events

• Test Design: How much time do you have? Are there tests better to create later than sooner?
  测试设计：您有多少时间？晚点设计会不会更好（比如：多些时间了解需求后设计）
• Test Execution: When will tests be performed? Are some tests performed repeatedly, say, for regression purposes?
  测试执行：什么时候进行测试？是否重复执行某些测试，比如回归测试
• Development: When will builds be available for testing, features added, code frozen, etc.?
  开发：构建可以用于测试的版本、添加特性、代码冻结等这些任务的时间计划
• Documentation: When will the user documentation be available for review?
  文档：什么时候可以查看用户文档？

Test Items. The product to be tested.

• Scope: What parts of the product are and are not within the scope of your testing responsibility?
  范围：产品的哪些部分属于和不属于您的测试职责范围？
• Availability: Do you have the product to test? Do you have test platforms available? Will you test in production?
  可测性：您有要测试的产品吗？您有可用的测试平台吗？您会在生产中进行测试吗？
• Interoperable Systems: Are any third-party services required for your product that must be mocked or made available?
  系统间交互：您的产品是否需要任何第三方服务，这些服务必须被模拟或可用？
• Volatility: Is the product constantly changing? How will you find out about changes?
  易变性：产品是否在不断变化？您将如何了解变化？
• New Stuff: Do you know what has recently been changed or added in the product?
  新东西：您知道产品中最近进行了更改或添加的内容吗？
• Testability: Is the product functional and reliable enough that you can effectively test it?
  可测试性：产品的功能和可靠性是否足以有效测试它？
• Future Releases: What part of your testing, if any, must be designed to apply to future releases of the product?
  将来的版本：测试的哪一部分（如果有）是可以被复用到将来的版本？

Deliverables. The observable products of the test project.

• Content: What sort of reports will you have to make? Will you share your working notes, or just the end results?
  内容：您将要进行哪种报告？您会分享您的工作笔记，还是仅分享最终结果？
• Purpose: Are your deliverables provided as part of the product? Does anyone else have to run your tests?
  目的：您的可交付成果是否作为产品的一部分提供？还有其他人要运行您的测试吗？
• Standards: Is there a particular test documentation standard you’re supposed to follow?
  标准：您是否应该遵循特定的测试文档标准？
• Media: How will you record and communicate your reports?
  媒体：您将如何记录和传达报告？

二、Product Elements

Ultimately a product is an experience or solution provided to a customer. Products have many dimensions. Each category,
listed below, represents an important and unique element to be considered in the test strategy.
Structure. Everything that comprises the physical product.
• Code: the code structures that comprise the product, from executables to individual routines.
• Hardware: any hardware component that is integral to the product.
• Non-executable files: any files other than multimedia or programs, like text files, sample data, or help files.
• Collateral: anything beyond software and hardware that is also part of the product, such as paper documents, web links and content,
packaging, license agreements, etc.
Function. Everything that the product does.
• Application: any function that defines or distinguishes the product or fulfills core requirements.
• Calculation: any arithmetic function or arithmetic operations embedded in other functions.
• Time-related: time-out settings; periodic events; time zones; business holidays; terms and warranty periods; chronograph functions.
• Security-related: rights of each class of user; protection of data; encryption; front end vs. back end protections; vulnerabilities in sub-systems. • Transformations: functions that modify or transform something (e.g. setting fonts, inserting clip art, withdrawing money from account).
• Startup/Shutdown: each method and interface for invocation and initialization as well as exiting the product.
• Multimedia: sounds, bitmaps, videos, or any graphical display embedded in the product.
• Error Handling: any functions that detect and recover from errors, including all error messages.
• Interactions: any interactions between functions within the product.
• Testability: any functions provided to help test the product, such as diagnostics, log files, asserts, test menus, etc.
Data. Everything that the product processes.
• Input/Output: any data that is processed by the product, and any data that results from that processing.
• Preset: any data that is supplied as part of the product, or otherwise built into it, such as prefabricated databases, default values, etc.
• Persistent: any data that is expected to persist over multiple operations. This includes modes or states of the product, such as options settings,
view modes, contents of documents, etc.
• Interdependent/Interacting: any data that influences or is influenced by the state of other data; or jointly influences an output.
• Sequences/Combinations: any ordering or permutation of data, e.g. word order, sorted vs. unsorted data, order of tests.
• Cardinality: Numbers of objects or fields may vary (e.g. zero, one, many, max, open limit). Some may have to be unique (e.g. database keys).
• Big/Little: variations in the size and aggregation of data.
• Invalid/Noise: any data or state that is invalid, corrupted, or produced in an uncontrolled or incorrect fashion.
• Lifecycle: transformations over the lifetime of a data entity as it is created, accessed, modified, and deleted.
Interfaces. Every conduit by which the product is accessed or expressed.
• User Interfaces: any element that mediates the exchange of data with the user (e.g. displays, buttons, fields, whether physical or virtual).
• System Interfaces: any interface with something other than a user, such as other programs, hard disk, network, etc.
• API/SDK: Any programmatic interfaces or tools intended to allow the development of new applications using this product.
• Import/export: any functions that package data for use by a different product, or interpret data from a different product.
Platform. Everything on which the product depends (and that is outside your project).
• External Hardware: hardware components and configurations that are not part of the shipping product, but are required (or optional) for the
product to work: systems, servers, memory, keyboards, the Cloud.
• External Software: software components and configurations that are not a part of the shipping product, but are required (or optional) for the
product to work: operating systems, concurrently executing applications, drivers, fonts, etc.
• Embedded Components: libraries and other components that are embedded in your product but are produced outside your project.
• Product Footprint: The resources in the environment that are used, reserved, or consumed by the product (memory, filehandles, etc.)
Operations. How the product will be used.
• Users: the attributes of the various kinds of users.
• Environment: the physical environment in which the product operates, including such elements as noise, light, and distractions.
• Common Use: patterns and sequences of input that the product will typically encounter. This varies by user.
• Disfavored Use: patterns of input produced by ignorant, mistaken, careless or malicious use.
• Extreme Use: challenging patterns and sequences of input that are consistent with the intended use of the product.
Time. Any relationship between the product and time.
• Input/Output: when input is provided, when output created, and any timing relationships (delays, intervals, etc.) among them.
• Fast/Slow: testing with “fast” or “slow” input; fastest and slowest; combinations of fast and slow.
• Changing Rates: speeding up and slowing down (spikes, bursts, hangs, bottlenecks, interruptions).
• Concurrency: more than one thing happening at once (multi-user, time-sharing, threa