通常，测试是创造性和墨守成规的组合。但是，由于软件开发周期中出现的复杂性和时间紧迫，我们很容易忘记了什么才是一个软件产品需要被验证的。
这把我们带到了本文的主题：上下文。如果软件测试的目的是保持信心和基于风险的报告的话，测试员必须问正确的问题以保证把产品在合适的时间推向正确的方向。测试员以此来帮助改进产品的质量。显而易见，测试很大程度上是一种上下文依赖的活动。
对于一些测试老手，他们可能已经把这点给忘记了，或者默守某些用例，建议他们重温一下本文的内容。
What Is Testing?什么是测试？
这个问题的答案有很多。James Bach，“Lessons Learned in Software Testing：A Context-Driven Approach”的作者，他把测试定义成“为了评估产品而进行的盘问”。
Cem Kaner，与Bach一起合作写书的作者，测试的一代宗师，在他们的黑盒测试教程中把测试定义为“为利益相关方提供质量相关的信息而进行的产品技术调查(www.testingeducation.org/BBST.)
在2004年的Software Test and Performance会上，他的主题“The Ongoing Revolution in
Software Testing,”，Kaner说：“测试是调查。作为调查员，我们必须充分利用有限的时间和资源，从大量的潜在任务中做聪明的抽样调查。大部分的调查是探索-我们边学习边调查，我们不断地设计测试以反映我们不断增长的知识。部分这些所设计的测试的可以重用的。”
Context Counts 重要的是上下文
在www.context-driven-testing.com上的“Lessons Learned”有两个样例项目。
Safety-critical applications和Data-safe applications
在第一个例子，你将测试一个飞机控制程序。在这个上下文里，“正确的行为”是关键。
你所做的任何事或不做的任何事，都有可能导致灾难。这个项目的开发组必须像工程师一样地小心、精确、重复、互相代码审查。这类软件必须通过严格的认证程序。
在第二个例子，你开发一个在线使用的文字处理程序，在这个上下文里，可靠的文档处理和把大量的用户从Microsoft的Word引诱过来是关键。
没有什么需求可言，可用性、可靠性、市场发布的及时性等特性要比“在10纳秒内完成任务”的特性更为重要。这个项目组的成员所需的技能、开发方法等要求与第一个项目的有很大的不同。
你作为测试员的工作就是决定采用什么样的测试活动来帮助你肯定地说：“这个产品已经可以交付给用户使用了”。基于不同项目的上下文，可能采用完全不同的测试策略。
表一可以帮助你决定什么时候你需要基于风险报告有用的信息给你的项目负责人。在不同的上下文有可能采用表中不同的测试方法。
Table1：TESTING LAUNDRY LIST
Type | Purpose |
Unit tests | Determine if regressions are caused and estimate thread safety and code coverage |
Build verification tests | Quick “smoke” tests designed to ensure that the product is ready for further testing |
Full functional tests | Determine if all product functions work as intended |
UI tests | Can root out interface errors and help with user friendliness |
Regression tests | Determine consistent functionality across builds |
Load tests | Ensure that product isn’t overwhelmed by masses of users or data |
Benchmarks | Either by build or platform, can help a team set and adhere to performance goals |
Installation tests | Verify successful deployment on a variety of operating systems and platforms |
Change Is The Only Constant 永恒不变的只有变化
通常很难预料项目随着时间进展的情况，实际上，在项目开发和测试中，变化可能才是最可靠。
最好不要徒劳试图改变的需求不断变化、测试计划永远无法完成的事实。最好把你的时间花在设计和执行测试上，而不要花在不断地更新测试计划上。
Value-Added Testing 增值测试
好的软件测试是富有挑战性的智力活动。要做到这点，你需要在开发生命周期中的适当时间点切入，然后尽早获取测试代码。关注你处在哪个阶段，你在这个阶段扮演的角色是什么。
如果你的角色是自动化测试，要记住你不是简单地把手工测试自动化。测试执行和自动化工具非常重要，但是不能忘记要测试的是什么、如何去测试它，这些其实才是重点。
测试的最后阶段是验收测试(acceptance testing)，也叫QA测试或beta测试。在这个阶段，决定软件的可接受程度，测试通常包括软件的目标用户、项目组的其他成员。
为了避免曲解测试结果，由参与测试的人以及决定软件可接受性的人来记录测试结果的上下文非常重要。
Are We There Yet?
往往受迫于市场压力，产品提前发布。
那么这时候软件产品是否处于可发布状态呢？下面是几个判断依据：
1. All critical and high-priority bugs are fixed.
是否所有关键的和高优先级的bug都已经fix？
2. All critical functions of the product have been implemented and tested.
v是否所有关键的功能都已经开发出来并且已经测试？
可使用www.satisfice.com/presentations/dashboard.pdf上的测试矩阵表的方法来判断。
3. Automation reports proper results.
自动化测试结果是否理想？
如果你在项目中使用自动化测试，确保自动化测试关注在软件程序的适当的区域。
4. Requirements are verified.
需求是否得到测试验证。
确保测试用例覆盖了每个需求项。
5. Metrics.
度量。算一下有多少个用户问题被成功地解决了。项目过程中的缺陷率也能提供一些预测信息。
6. Test case coverage.
测试用例覆盖率。注意当程序在不断变化，测试资源在不断变化的情况下。这个度量方法可能会使一些不懂测试的人把不好的软件当成好软件看待。
7. Ask your team.
直接问一下项目组中的成员，问一下他们是否认为是发布的适合时候，他们是否有信心交付给用户使用。
Keeping an Eye on Risk 关注风险
不管你付出多少努力，你的项目还是有可能碰到风险。这种不幸还有可能有不同的出现方式。也许你的组员没有找到一个重大的bug，但是你的用户在软件发布后发现了。
也许你发布得太早了。软件发布要在测试覆盖的广度和宽度之间取得平衡。但是往往，是否发布不是由开发组决定的，而是市场决定的。
也许你发布得太晚了。如果你选择了错误的度量方法，或者关注于错误的功能特性上，你的进度会停顿，版本发布会delay。
为了避免这些陷阱，在你定计划的时候、执行测试的时候，记住上下文。个性化你的测试过程以满足不同项目的个性化要求，可以增加成功的机会并减少风险。
