测试陷阱是指不必要的并且可能意外导致测试不那么有效，高效或者更令人沮丧的表现的决策、思维、行为或不作为。基本上，测试陷阱是一个经常发生的搞砸测试的方式，当测试人员、管理人员、需求工程师和其他测试利益相关者犯了测试相关的错误，并由此产生意想不到的负面后果时，项目就陷入了测试陷阱。
从某种意义上说，测试陷阱的描述构成了测试反模式。然而，术语“陷阱”是专门选择，为那些粗心大意或外行的人唤起隐蔽或不易识别的陷阱的形象。与任何陷阱一样，最好是避免测试陷阱，而不是陷入陷阱后将自己和项目挖出来。
服务端测试中，被测服务通常依赖于一系列的外部模块，被测服务与外部模块间通过REST API调用来进行通信。要对被测服务进行系统测试，一般做法是，部署好所有外部依赖模块，由被测服务直接调用。然而有时被调用模块尚未开发完成，或者调用返回不好构造，这将影响被测系统的测试进度。为此我们需要开发桩模块，用来模拟被调用模块的行为。最简单的方式是，对于每个外部模块依赖，都创建一套桩模块。然而这样的话，桩模块服务将非常零散，不便于管理。Mock Server为解决这些问题而生，其提供配置request及相应response方式来实现通用桩服务。本文将专门针对REST API来进行介绍Mock Server的整体结构及应用案例。
Easy mocking of any system you integrate with via HTTP or HTTPS
For any system you integrate with via HTTP or HTTPS MockServer can be used as:
When MockServer receives a request it matches the request against active expectations that have been configured, if no matches are found it proxies the request if appropriate otherwise a 404 is returned.
For each request received the following steps happen:
An expectation defines the action that is taken, for example, a response could be returned.
测试员有很多不同的背景，测试团队是多元化的集体，但是大多数人都同意：测试员的思考方式是不同的。怎么不同？有人说测试员是“消极”思维者。测试员会抱怨这种说法，认为自己喜欢征服，他们在报告坏消息时有一种特别的兴奋感。这是一种普遍观点。我们提出另一种观点。测试员并不抱怨，他们提供的是证据。测试员并不喜欢征服，他们喜欢打破产品没有问题的幻觉。测试员并不喜欢发布坏消息，他们喜欢把客户从虚假信念中解放出来。我们的观点是，按测试员的方式思考意味着实践认识论。测试运用的是认识论，不是靠傲慢或谦卑。
认识论研究如何认识所了解的东西：研究证据和推理。这是科学实践的基础。研究认识论的人有科学家、教育家和哲学家，当然还有精英级的软件测试员。学习认识论的学生研究科学、哲学和心理学，目标是了解怎样才能改进我们的思维。我们使用的术语比经典定义要宽，以便能够更多地利用批判性思维的最新成果。将认识论运用于软件测试，要问与以下类似的问题：
直接与软件测试有关的认识论问题包括：
研究认识论可帮助测试员设计有效的测试策略，更好地意识到自己工作中的错误，理解自己的测试能够证明什么、不能证明什么，并编写出无懈可击的测试报告。
一个角色就是一种关系。这意味着人们不能控制自己的角色，但可以协商。别人期望从测试员那里得到的可能并不合理。当测试员由于低质量的产品受到指责时（这种事时有发生），不管是谁指责，可能都存在分不清角色的问题。也许他们认为测试员的工作，就是在产品交付之前使用“质量魔术棒”敲打产品，他们也许认为测试员敲打得还不够狠。
当测试员清楚了自己的角色之后，在协商角色内容时，就有了在可能出现的任何情况下确立对自己预期的基础。但是，即使是清晰和恰当的测试角色也是一种苛求。
测试员的使命，可能要取决于自己的行业、公司、项目或团队的个性，测试项目也千差万别。把测试作为一种工艺发展的挑战，一直是建立测试实践对话所面临的困难，这种测试实践要跨越我们之间的文化和技术差异。这些差异中的很多内容，决定了测试团队的不同使命。以下任何要求都可能决定测试员的使命。
如果测试员将时间和精力都投入到客户并不关心的需求上，就会冒做无关工作或生产率低的风险。测试员要与自己的经理协商使命问题，并明确使命，如果不能就使命达成一致意见，就不会有做任何工作的好基础。
如果测试员不知道该做什么怎么办？一种回答是评审使命。这样做可以找出自己的核心问题。如果测试员明确自己的测试使命，就可以为自己的工作辩护，并明确地确定下一步要做什么。测试员还可以用简单的描述，向其他人解释自己的角色。如果由于某种原因不能完成自己的使命，应该立即把这个问题汇报给管理层。
如果测试员确切地知道要做什么该怎么办？经常重新考虑自己的使命，保证自己的计划不会由于过于偏重测试问题的一个方面，而忽略其他方面。
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式。同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。
通俗的讲：就是把整个测试流程的操作步骤用按照一定的格式用文字描述出来。
*测试*用例是测试执行的指导；是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；是团队内部交流以及交叉测试的依据，便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；在测试执行工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。
1、 理清思路，避免遗漏测试点
理清思路是我们认为最重要的一点，有的系统本来就是一个大而复杂的项目，我们需要把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。
2、 跟踪测试进度进展
通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度，方便跟踪我们的测试进度。
3、 回归测试
首先我们的系统不是测一遍就完了的，我们需要在开发环境上测试，测试环境上还要进行回归，其次还有可能涉及到合并测试，而且也有可能会有不同的人在不同的阶段进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。
4、 历史参考
在我们所做项目的各个版本中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。
另外如果产品发布后出现了发布缺陷，测试用例也是分析发布后缺陷的依据之一。
August 15, 2016 by typora.io
Typora supports some Markdown extensions for diagrams, once they are enabled from preference panel.
When exporting as HTML, PDF, epub, docx, those rendered diagrams will also be included, but diagrams features are not supported when exporting markdown into other file formats in current version. Besides, you should also notice that diagrams is not supported by standard Markdown, CommonMark or GFM. Therefore, we still recommend you to insert an image of these diagrams instead of write them in Markdown directly.
This feature uses js-sequence, which turns the following code block into a rendered diagram:
For more details, please see this syntax explanation.
This feature uses flowchart.js, which turns the following code block into a rendered diagram:
Typora also has integration with mermaid, which supports sequence diagrams, flowcharts, Gantt charts, class and state diagrams, and pie charts.
For more details see these instructions.
%% Example of sequence diagram
sequenceDiagram
Alice->>Bob: Hello Bob, how are you?
alt is sick
Bob->>Alice: Not so good :(
else is well
Bob->>Alice: Feeling fresh like a daisy
end
opt Extra response
Bob->>Alice: Thanks for asking
end
For more details see these instructions.
graph LR
A[Hard edge] -->B(Round edge)
B --> C{Decision}
C -->|One| D[Result one]
C -->|Two| E[Result two]
For more details see these instructions.
classDiagram
Animal <|-- Duck
Animal <|-- Fish
Animal <|-- Zebra
Animal : +int age
Animal : +String gender
Animal: +isMammal()
Animal: +mate()
class Duck{
+String beakColor
+swim()
+quack()
}
class Fish{
-int sizeInFeet
-canEat()
}
class Zebra{
+bool is_wild
+run()
}
For more details see these instructions.
stateDiagram
[*] --> Still
Still --> [*]
Still --> Moving
Moving --> Still
Moving --> Crash
Crash --> [*]
pie
title Pie Chart
"Dogs" : 386
"Cats" : 85
"Rats" : 150
More https://mermaid-js.github.io/mermaid/#/
1 | cd "$(brew --repo)" |
brew install pyenv
或者
Python 3.7 依赖 OpenSSL 1.0.2e
或更高版本，手动安装OpenSSL或者直接安装3.6最新版本
1 | git clone https://github.com/pyenv/pyenv.git ~/.pyenv |