『壹』 aAPP测试用例怎么写
测试用例的设计方法和编写
1.如何设计编写测试用例？
对各个功能模块进行测试点分析提取测试点再堆测试点进行用例编写
【测试点：通过需求分析后对得出的需要进行测试的具体内容】
比如对PC端QQ账号的登录模块，提取测试点就有：
①正常登陆 ②账号为空时点击登录 ③密码为空时点击登录 ④账号密码都为空时点击 登录 ⑤密码错误时点击登录 ⑥找回密码功能是否有效 ⑦记住密码功能是否有效 ⑧ 自动登录功能是否有效
2.编写测试用例该注意什么？
①根据项目的实际情况设计测试用例表格
②用例格式不要生搬硬套
③根据具体情况编写
3.编写测试用例的常用方法：
①等价类划分法：等价类是输入的集合，比如在注册时，密码规定为6-16位英文字母或数字及下划线，那么小于6位的一串字符就是一个等价类，大于16位的一串字符是另一个等价类，在6-16位之间且符合规范的一串字符也是一个等价类，在6-16位之间的但包含除英文字母和数字和下划线之外的字符是另外一个等价类。
在每个等价类中选取一定数目的值作为代表。等价类分为有效等价类和无效等价类，输入符合条件的值对功能进行检验，输入无效等价类中的值可以找出程序错误的地方。
②边界值分析法：对输入的边界值或稍大（小）于边界值的值进行分析。比如某公司在招聘时筛选简历时对年龄的要求是20岁到35岁，那么19、20、21、34、35、36都是边界值，对其进行输入测试观察结果是否符合要求。
③场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提升测试效果。场景法一般分为基本流和备用流，覆盖所有的场景。
④错误猜测法：通过直觉和经验对结果进行分析。
『贰』 软件工程设计导论:过程、原理与模式(UML2.0版)目录
软件工程设计导论:过程、原理与模式(UML2.0版)的目录详细介绍了多个核心章节，旨在帮助读者理解软件设计的各个方面。
第1部分，简介，涵盖软件设计学的基础概念。第1章从软件设计的概念出发，解释了设计的本质——它是问题的解决方案，强调了抽象化和模型在设计中的关键作用。设计的多样性被进一步探讨，包括产品设计、工程设计以及软件工程设计团队的协作。此外，软件设计在生命周期中的重要性，如软件生命周期、跨生命周期的设计和“做什么”与“如何做”的区别，也做了深入讨论。
第2章深入解析软件设计过程和管理，使用UML活动图展示了设计过程的可视化表示。这部分内容有助于读者理解设计方法和历史，以及其在实践中的应用。
第II部分详细介绍了软件产品设计，从设计的上下文开始，然后逐步深入到产品设计分析、解析以及用例驱动的设计。
第III部分重点转向软件工程设计，包括工程设计分析、解析、体系结构设计和各种设计解析，如静态中级面向对象设计和动态设计的交互作用模型、状态模型等。
第IV部分深入探讨软件设计模式，如体系结构风格、面向对象和中级设计模式，以及代理者、生成器和反应器等具体模式的介绍。
最后，附录部分提供了术语表、AquaLush案例分析和参考文献，为深入研究和实践提供了补充资源。
本书是国际知名软件工程专家Christopher Fox教授关于软件工程设计的一本大学教程，着重描述如何理解软件问题以及如何设计用来解决这些问题的方案。为了便于大家理解和应用，书中采用了常用的UML2表示法进行设计，并提供大量的示例，本书适用于具有面向对象编程基础并熟悉基本的数据结构和算法知识的大学高年级学生和软件开发人员。
『叁』 如何有效地管理测试用例
刚在51testing上看到一个人发帖，说自己写测试用例没有很好的思路，对于一些复杂的功能点，有没有比较好的测试覆盖方法，比如高级查询等等，非要列出来那么详细的测试用例吗？～～～～看完之后，我就忍不住发言了，作为一个测试人员，设计测试用例那是本职工作，如果我们连写用例的基本耐心都丢弃了，还谈什么测试。那开发总不能说因为写代码很麻烦，而不写吧。很多事情没有捷径，必须要做的事情，那是没有办法去逃避，不然我们就失去了工作的意义了。
其实说来，也是由于最近对于测试用例的设计，让我产生了一些反思。如何设计测试用例，如何评审测试用例，最后如何管理测试用例，这都是我们测试工作中必须要去改进的问题。在之前的公司，由于团队工作任务繁忙，我们没有太多的时间去管理和优化测试用例，也因此对用例方面少了太多的思考，而且虽然有对于用例的评审，但一直以来，我认为是做得不够好的，毕竟每次评审下来，感觉效果没有预期的那么好，主要还是没有足够的时间去管理，所以无法引起重视。不过，现在我想我需要花大量的时间来管理用例了，而且要保证有序的进行，最后输出让团队中各个成员都认为满意而且高效的测试用例。对于用例管理的根本问题，我个人认为是分类上，如何有效的维护和优化用例，就是需要前期明确的分类规划，根据分类的优先级一步一步地来完成就可以了，到最后，我们也可以有效把控的测试覆盖度。
当前，我们大致可以把测试用例分称三个方面，分别是功能、UI和业务流程，从这三个角度来进行设计。
1、从功能的角度，功能是每个项目测试的重点，通常在测试人员得到需求文档的时候，我们就开始设计测试用例，那么这个时候需求文档上列出都是功能以及部分一些业务逻辑等，所以在测试用例的第一阶段就是完成功能的用例设计。不过这里，肯定会让很多人疑惑，其实功能、业务还有UI，都是有关联的，而且很多时候无法分解的。这里后面我会举个例子说明哈，但绝非都是可以分类，只是谈谈如何分解的方法，最重要的就是不要遗漏就行。
2、从UI的角度，UI通常是指界面测试，这个应该不难理解，但要想与功能点进行分解，也不是那么容易区分的，所以我们来直观的说明哈。界面测试，注重样式，外观、整洁、摆放以及易用性，还包括用户体验等。
下面通过一个证券交易平台上的买入和撤单业务，进行具体说明：
业务说明：买入业务包括股票代码、当前价格、买入价格，买入股票数量、确定买入按钮和取消按钮；
撤单业务包括选择撤单的未成交业务、撤单成功、撤单失败以及取消撤单按钮；
以上只是大致列举了一部分。
功能点：买入按钮、取消按钮、选择撤单、撤单按钮和取消撤单按钮等
UI界面测试：股票代码、当前价格、买入价格、买入股票数量，所有的文本框；买入成功/失败的提示框；撤单成功/失败的提示框；撤单成功/失败的业务状态等
业务测试：买入业务，从输入买入表单的数据，到提交表单，到最后买入的表单显示的位置，以及买入提交但未成交，可以撤单，完成撤单的业务，到撤单成功或者失败等，这一连串的工作组合就是一个业务流程。
其实这里就存在一个争议性的问题，对于买入和撤单，既可以作为功能点，也可以作为一个业务逻辑来设计，但从本质上来讲，功能点注重单独的操作，而业务流重的在是一个流程，还需要具体业务去甄别。功能点的设计更主要对这个买入和撤单的按钮本身进行用例设计；而业务则是需要从买入和撤单之前的输入到最后输出这样一个过程来设计。
以上也只是大概的一个简单的说明，具体的操作还得根据自己的实际流程来执行，毕竟测试用例的管理是一个长期的积累和沉淀的过程，好的方法都是总结出来的。对于测试来说，用例是基础，对于回归测试、自动化、性能等等都是根本，管理好测试用例，也就是提高测试的工作质量。