在大話測(cè)試數(shù)據(jù)（一）文章中，我提到，獲取數(shù)據(jù)的第一步是獲取概念上數(shù)據(jù)。這一步看起來簡(jiǎn)單，其實(shí)不是那么容易。獲取概念數(shù)據(jù)和獲取需求的過程是交織在一起的，事實(shí)上，它們其實(shí)是一個(gè)事兒，因?yàn)閿?shù)據(jù)是需求中最重要的組成部分。
需求工程是個(gè)大話題，目前有很多種流派和實(shí)踐方式來來搞定需求，但它們的思想都比較一致，那就是：不斷的由粗到精的迭代（如下圖）。關(guān)于需求這里不再展開，如果大家有興趣的話，推薦兩本我覺得還不錯(cuò)的書：德國人寫的《需求工程，基礎(chǔ)原理和技術(shù)》和國人寫的《軟件需求最佳實(shí)踐》，大家讀后結(jié)合工作實(shí)踐會(huì)很有收獲。

由上述文字可知，（測(cè)試）數(shù)據(jù)獲取也是一個(gè)迭代的過程。實(shí)際上在項(xiàng)目早期，我們就能獲得概念數(shù)據(jù)。概念數(shù)據(jù)是什么呢？用大白話說就是：這種數(shù)據(jù)叫什么，大體啥樣子，是干嘛用的。舉個(gè)例子：

如果你的項(xiàng)目是一個(gè)信用卡項(xiàng)目，項(xiàng)目有一個(gè)功能就是，每月給用戶發(fā)送“電子對(duì)賬單”。對(duì)于80后，甚至90后的你，一秒鐘你就知道這個(gè)“電子對(duì)賬單”大概將會(huì)是個(gè)什么東西了?！安痪褪且环怆娮余]件里放一個(gè)網(wǎng)頁，里邊告訴用戶：尊敬的某某先生/小姐！您本月消費(fèi)了幾筆，每筆多少錢，都是哪一天花的。最重要的是，您在本月X日前必須把錢還了?！斑@樣你就建立了對(duì)“電子對(duì)賬單”這種測(cè)試數(shù)據(jù)的概念，也就是說得到了“電子對(duì)賬單”這種概念的測(cè)試數(shù)據(jù)。

Pretty easy？事實(shí)沒有那么簡(jiǎn)單的。事情的本質(zhì)是：你有一個(gè)超級(jí)聰明的大腦，能瞬間把你的經(jīng)驗(yàn)綜合起來對(duì)需要識(shí)別的東西作一判斷，并給出一個(gè)大致的評(píng)估。但如果你大腦沒有相關(guān)的知識(shí)，你就沒有那么幸運(yùn)了。不信，請(qǐng)讀一下下圖中的文字：

膜蛋白復(fù)合體是神馬？神馬是beta鏈？桶壁是神馬？？？？這特么的都是神馬？如果你沒有一些生物學(xué)知識(shí)、高中生物又不幸光睡覺了的話，這段選自《環(huán)球科學(xué)》的文字不會(huì)讓你覺得比讀日文簡(jiǎn)單。

因此識(shí)別概念上的測(cè)試數(shù)據(jù)，你腦子里還得有點(diǎn)兒貨才行，這些貨是：“技術(shù)層面的知識(shí)”，“業(yè)務(wù)層面的知識(shí)（領(lǐng)域知識(shí)）”，“對(duì)于產(chǎn)品本身的認(rèn)識(shí)”，還有“你的常識(shí)”。這四點(diǎn)的總結(jié)是從測(cè)試大師 James Bach 的課程中獲取的，你可以嘗試獲取他關(guān)于快速軟件測(cè)試的 PDF 文件。

你說了，沒有這些知識(shí)怎么辦？答案特別簡(jiǎn)單，“學(xué)啊”！。勤學(xué)勤問勤練勤觀察，入行幾年后，如果不是特別懶惰，前三項(xiàng)都會(huì)提高到一個(gè)不錯(cuò)的高度。這些都變成了你的價(jià)值。經(jīng)過一段時(shí)間爬坡，你就可以很快的獲取概念測(cè)試數(shù)據(jù)了。

你說了，廢話，我也知道要學(xué)，但有沒有更具體點(diǎn)兒的？干貨，有么？要能咯掉牙的！

好吧，可以參考下面的干貨資料（英文版，也正好練習(xí)下英文），你就當(dāng)它是個(gè) checklist，按圖索驥吧：關(guān)于測(cè)試數(shù)據(jù)的獲?。ú粌H僅是概念測(cè)試數(shù)據(jù)的獲?。瑴y(cè)試思路的獲取，甚至是需求的獲取，你一定會(huì)有收獲。

We recommend collecting test ideas continuously from a variety of information sources.

Consider the following, and think about values, risks, opportunities; find shortcuts to cover what is important.

1.Capabilities.

The first and obvious test ideas deal with what the product is supposed to do. A good start is requirements, examples and other specifications, or a function list created from actual software. But also try to identify implicit requirements, things users expect that haven’t been documented. Be alert to unwanted capabilities.

2.Failure Modes.

Software can fail in many ways, so ask “what if” questions to formulate test ideas that expose the handling of internal/external, anticipated/unexpected, (un)intentional, realistic/provoked failures. Challenge the fault tolerance of the system; any object or component can break.

3.Quality Characteristics.

Quality characteristics are always important for the project to be successful, although the OK zone can be easy to reach, or difficult and critical. Our definition includes capability, reliability, usability, charisma, security, performance, IT-bility, compatibility, supportability, testability, maintainability, portability, and a plethora of sub-categories.

Many of these can be used as ongoing test ideas in the back of your head, executed for free, but ready to identify violations.

4.Usage Scenarios.

Users want to accomplish or experience something with software, so create tests that in a variety of ways simulate sequences of product behavior, rather than features in isolation.

The more credible usage patterns you know of, the more realistic tests you can perform. Eccentric soap opera tests broaden coverage.

5.Creative Ideas.

All products are unique, and require some test ideas not seen before. Try lateral thinking techniques (e.g. Edward De Bono’s Six Thinking Hats, provocative operators, the opposite, random stimulation, Google Goggles) to come up with creative test ideas.

Metaphors and analogies is a good way to get you started in new directions.

6.Models.

A state model helps identify test ideas around states, transitions and paths. A system anatomy map shows what can be tested, and can highlight interactions. Create a custom model using structures like SFDPOT from Heuristic Test Strategy Model.

A visual model is easier to communicate, and the modeling activity usually brings understanding and new ideas.

7.Data.

By identifying intentional and unintentional data (there is always noise), you have a good start for a bunch of test ideas. Follow easy and tricky data through the application, be inside and outside boundaries, use CRUD (Create, Read, Update, Delete), exploit dependencies, and look at the data in many places.

8.Surroundings.

Environment compatibility (hardware, OS, applications, configurations, languages) is an important testing problem, but also investigate nearby activities to your product. By understanding the big system you can get credible test ideas that are far-fetched when looking at functionality in isolation.

9.White Box.

By putting a tester’s destructive mindset on developers’ perspective of architecture, design and code, you can challenge assumptions, and also find mistakes. Pay special attention to decisions and paths you might not understand from a black-box perspective. Code coverage is not worthless, it can be used to find things not yet tested.

10.Public collections.

Take advantage of generic or specific lists of bugs, coding errors, or testing ideas. As you are building your own checklist suitable for your situation, try these:

? Appendix A of Testing Computer Software (Kaner, Falk, and Nguyen)

? Boris Beizer Taxonomy (Otto Vinter)

? Shopping Cart Taxonomy (Giri Vijayaraghavan)

? Testing Heuristics Cheat Sheet (Elisabeth Hendrickson)

? You Are Not Done Yet (Michael Hunter)

Learn some testing tricks or techniques from books, blogs, conferences; search for test design heuristics, or invent the best ones for you.

11.Internal Collections.

Use or create lists of things that often are important in your context, some call these quality/test patterns.

12.Business Objectives.

What are the top objectives for the company (and department break-downs) ? Are there any requirements that contradict those objectives? Do you know the big picture, the product vision and value drivers?

13.Information Objectives.

Explicit and implicit purposes of the testing are important guides to your effort. If you don’t have them, you can create quality objectives that steer test ideas for any feature.

14.Product Image.

The behavior and characteristics the product is intended to display might be explicit or implicit, inside the walls and minds of the people producing or consuming the software.

You will be able to write compelling problem reports if you know and can show threats to the product’s image, e.g. by pointing to a violation of marketing material.

15.Product Fears.

Things that stakeholders are really worried about are much stronger than risks, they don’t need prioritization, they need testing. Typical hard-to-verify, but useful-for-testing fears are: loss of image, wrong decisions, damage, people won’t like the software. Different people have different fears; find out which matters most.

16.Project Risks.

Some of the difficult things in a project can be addressed by testing. You want to know about which functionality developers are having trouble with, and you will adjust your schedule depending on risks that need mitigation first.

17.Rumors.

There are usually lots of talk about quality and problems floating around. Some hurt the product and the organization. Use the rumors themselves as test ideas. It is your mission to kill them or prove them right.

18.Product History.

Old problems are likely to appear in new shapes. Search your bug/support system or create an error catalogue, remember critical failures and root cause analysis. Use old versions of your software as inspiration and oracle.

19.Test Artifacts.

Not only your own test ideas, logs and results can be used for sub-sequent tests, also try out test results from other projects, Beta testing reports, usability evaluations, 3rd party test results etc. What questions do you want to be able to answer in future

status reports?

20.Debt.

The idea that a debt is constantly growing because of all the shortcuts being made. This could be project debt, managerial debt, technical debt, software debt, testing debt or whatever you wish to call it. If the team keep track on what is on the debt list, you can map a set of test ideas against those items.

21.Business Knowledge.

If you know the purpose of the software, and the context it operates in, you can understand if it will provide vale to customers. If you can’t acquire this knowledge, co-operate with someone who knows the needs, logic and environment.

22.Field Information.

Besides knowledge about customer failures, their environments, needs and feelings, you can take the time to understand your customers both in error and success mode. Interview pre-sales, sales, marketing, consultants, support people, or even better: work there for a while.

23.Users.

Think about different types of users (people you know, personas), different needs, different feelings, and different situations.

Find out what they like and dislike, what they do next to your software. Setup a scene in the test lab where you assign the testers to role play different users, what test ideas are triggered from that? Best is of course unfiltered information directly from users, in their context.

Remember that two similar users might think very differently about the same area.

24.Conversations.

The informal information you get from people may contain things that are more important than what’s included in specifications. Many people can help you with your test design, some are better judges of importance, what can you gain from MIP:s(Mention In Passing)?

If developers know you can find interesting stuff, they might give you insider information about dubious parts of the software. A set of questions to a developer might be an innocent “what do you think we should test?” or “what part of your code would you have liked to do better?”

25.Actual Software.

By interacting with the software, you will get a lot of ideas about what is error-prone, connected, interesting. If you can eat your own dog food (euphemism: sip your own champagne), you are in much better position to understand what is important about the software. If “Quality is value to some person”, it is pretty good if that person is “me”.

26.Technologies.

By knowing the inner workings of the technology your software operates in, you can see problematic areas and things that tend to go wrong; understand possibilities and security aspects; which parameters to change, and when. You can do the right variations, and have technical discussions with developers.

27.Standards.

Dig up relevant business standards, laws and regulations. Read and understand user interface standards, security compliance, policies. There are articles out there that describe how you can break something even if it adheres to the standards, can you include their test ideas in yours?

28.References.

Reference material of various kinds is a good source for oracles and testing inspiration, e.g. an atlas for a geographic product. General knowledge of all types can be handy, and Wikipedia can be enough to get a quick understanding of a statistical method.

29.Competitors.

By looking at different solutions to similar problems you can get straightforward test ideas, but also a feeling of which characteristics end users might focus on. There might be in-house solutions (e.g. Excel sheets) to be inspired by, and often there exists analogue solutions for similar purposes. Can you gain any insightful test ideas from your competitors support, FAQ or other material?

30.Tools.

If something can be done very fast, it is a good idea to try it. Tools are not only the means to an end, they can also be used as the starting point for exploration.

31.Context Analysis.

What else in the current situation should affect the things you test, and how? Do you know about the market forces and project drivers? Is there anything that has changed that should lead to new ways of testing? What is tested by others?

32.Legal aspects.

Do you need to consider contracts, penalties or other legal obligations? What would cost the company the most in a legal issue? Do you have lawyer that can give you hints on what must be avoided?

33.Many Deliverables.

There are many things to test: the executable, the installation kit, programming interfaces, extensions, code & comments, file properties, Help, other documentation, Release Notes, readme:s, marketing, training material, demos etc. All of these also contain information you can use as inspiration.

34.YOU!

Your experience, knowledge, skills, feelings, subjectivity, and familiarity with problems. What do you want to test?