测试要点需要怎么写( 三 ) _要点

12、召开测试用例评审会议，在会议上大家可以提问互答，对模糊不清的地方可以进行讨论。这样可以站在不同的角度，站在很多人的思维和思考方式下设计用例。
13、站在用户的角度来设计用例，以用户的使用逻辑及操作习惯为出发点，从用户实际可能的操作场景考虑，一定要脱离系统提供功能。
14、测试用例需要不断更新和维护，不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。并且需要在测试执行时利用发散思维不断的构造和完善测试用例。
总的来说，写出好的测试用例需要我们不断的积累和完善，需要我们不断的在工作中去总结。写出好的测试用例没有简单的公式或规定可以遵循。即使是多年以来在测试方面感兴趣的人也很难做到这一点。
5.如何写测试策略” 。
你要在测试策略中很明确的提出你进行测试时所使用的方法和步骤。我看到过很多公司严格地按照一些测试策略模板来写。
但是，其实不用模板，你也可以并且更高效地写测试策略。下面是一些简单的写测试策略的技巧，1）在测试策略中要包括产品的背景信息。
在测试策略文档的第一段回答- stakeholder（项目利益相关者）为什么要开发这个产品？回答这个问题会帮助你更好更快地理解项目，并为所做的事情优先级排序。2）测试环境，它应该包括你在那个操作系统平台上做测试，系统是基于那些补丁和安全更新。
例如，一个测试环境可能必须包含Window XP SP2 3）列出你将要测试的所有重要特征。如果你认为有些特征不属于本次发布的一部分，那么就标注“不会被测试的特征” 。
4）写下在此项目测试中将应用到的测试方法。清楚的列出你将以那些类型的测试作为测试引导。
例如：功能测试，用户交互界面测试，集成测试，压力测试，安全测试等等。5）回答以下问题：你如何进行功能测试？手动还是自动化？测试工具是什么？你将执行在测试管理工具中的所有测试用例吗？ 6）用什么作为测试错误报告跟踪工具？当测试人员发现一个新的bug之后，流程应该是什么？ 7）测试进入和结束的标准分别是什么？ 8）如何去跟踪测试进度？什么度量可以用来记录测试结束？ 9）任务分布 – 定义每个组员的角色和职责，包括测试组长，测试员，项目经理等。
测试战略将由开发人员review，确保测试的覆盖率全面且没有重叠处。测试经理和部门经理都要同意测试策略之后，测试工作才能展开。
测试小组的划分及分工。10）有哪些风险会阻碍测试的完成？例如，代码的依赖性，测试工具的局限性等等。
要提前想到风险发生的解决办法。11）测试日程表- 每个测试计划都应该包含一个预估时间来估计完成测试所需要的时间。
这需要几个阶段：一，测试人员必须至少完成一次的执行全部用例。二，如果一个错误被测试人员发现，开发人员将修复此错误。
测试员重新测试此用例，直到其功能正确为止。最后，但很重要的一点是测试员必须对修改过的地方执行回归测试以保证开发人员在修复一个错误的时候没有引入另外的代码错误。
测试日程表要包含每个测试部分涉及的测试人员。时间往往很难估计，因为测试中有很多不确定性的事情发生。
其中一个比较好的办法是参照前一个发布来估计。12）回归测试的方法- 一个错误被修复后，必须要保证产品功能按用例标准运行。
回归测试是为了在修复一个问题时不引入另外的错误。因此相关的测试用例要在被执行一次，从而确保没有特殊的东西被引进。