- Make sure the Orchard project can be deployed as individual .NET-based CMS application.
1.确保可以将Orchard项目部署为基于.NET的单独CMS应用程序。
- Make sure it is easy for 3rd party developer to customize Orchard through extensions and themes.
2.确保第三方开发人员可以通过扩展和主题自定义Orchard。
- Make sure it is easy for 3rd party developers to build similar applications by re-usable components provided by Orchard.
3.确保第三方开发人员可以通过Orchard提供的可重用组件轻松构建类似的应用程序。
- Avoid any security and spam holes.
4.避免任何安全和垃圾邮件漏洞。
Component Overview
组件概述
The component overview and specs are listed on:
组件概述和规格列于:
http://docs.orchardproject.net/Documentation/Source-code-organization
http://docs.orchardproject.net/Documentation/Source-code-organization
Test Methodology
测试方法
We'll use Visual Studio Team Test edition as the major platform for testing. We try to automate as much test cases as possible, so VSTT is used to support the following test:
我们将使用Visual Studio Team Test版作为测试的主要平台。我们尝试尽可能多地自动化测试用例,因此VSTT用于支持以下测试:
- Code coverage
1.代码覆盖率
The instrumented build of Orchard is going to be created by VSTT, we can get code coverage information by running automation tests and manual tests on instrumented build.
Orchard的仪表化构建将由VSTT创建,我们可以通过运行自动化测试和仪表化构建的手动测试来获取代码覆盖率信息。
- Functionality & unit testing
2.功能和单元测试
Existing unit test cases are automated by NUnit framework. Creating unit test of actions in all controllers, to verify correct view data is passed to views.
现有的单元测试用例由NUnit框架自动完成。在所有控制器中创建操作的单元测试,以验证是否将正确的视图数据传递给视图。
Model validation logics are also tested by NUnit tests.
模型验证逻辑也通过NUnit测试进行测试。
- Data driven tests
3.数据驱动测试
A MVC application are driven by data, for e.g. url requests are routed to correct actions, views are bound to correct models.
MVC应用程序由数据驱动,例如, url请求被路由到正确的操作,视图绑定到正确的模型。
In order to randomize the test scenarios with correct data, a data driven test approach is applied to perform test. There are two approaches to generate test data:
为了使用正确的数据随机化测试场景,应用数据驱动的测试方法来执行测试。生成测试数据有两种方法:
a) Save predefined data in an Excel file, and utilize data driven test features in VSTT to perform tests.
a)将预定义数据保存在Excel文件中,并利用VSTT中的数据驱动测试功能来执行测试。
b) Randomly generating test data by a data generating tool, and combine with the power of pair-wise generation. We are able to generate as many valid data as possible on the fly.
b)通过数据生成工具随机生成测试数据,并与成对生成的功率相结合。我们能够动态生成尽可能多的有效数据。
We'll use the approach a) to perform data generating operation, because we are not able to share tools to public community yet.
我们将使用方法a)来执行数据生成操作,因为我们还无法与公共社区共享工具。
- Controller test
4.控制器测试
Actions in all controllers have unit tests. Parameters of action methods are generated based on approach described in "Data driven tests".
所有控制器中的操作都有单元测试。动作方法的参数基于“数据驱动测试”中描述的方法生成。
- Manual test.
5.手动测试。
Manual tests are designed to perform usability testing, to see whether the operation work flow make sense to users. These manual tests documents are maintained in VSTT, in this way we are able to combine manual & automation test result in a single test pass.
手动测试旨在执行可用性测试,以查看操作工作流程是否对用户有意义。这些手动测试文档在VSTT中维护,这样我们就可以在单个测试过程中结合手动和自动化测试结果。
- Stress test & Performance test
6.压力测试和性能测试
Communication Plan
沟通计划
Bugs are tracked in "Issue Tracker" of http://orchard.codeplex.com. Everyday testers get latest code from codeplex by subversion, and perform the tests. Since bugs are tracked in codeplex, we are able to export bug status to Excel, view the bug trends, and make the sign-off decision.
在http://orchard.codeplex.com的“问题跟踪器”中跟踪错误。日常测试人员通过subversion从codeplex获取最新代码,并执行测试。由于在codeplex中跟踪错误,我们可以将错误状态导出到Excel,查看错误趋势,并做出签署决定。
In the beginning few iterations, testers are not familiar with product features. Testing are started 1 iteration behind development, that is, testers perform testing on features finished, while developers work on features in next iteration. Latest finished features are fed to testers in iteration post-mortems. In the later iterations, while testers get familiar with product features, testers should be able to work in the same iteration as developers. Ideally, testing works just 1 or 2 days behind development.
在开始的几次迭代中,测试人员不熟悉产品功能。测试开始于开发后的一次迭代,即测试人员对已完成的功能执行测试,而开发人员则在下一次迭代中处理功能。最新完成的功能将在迭代后的测试中提供给测试人员。在后面的迭代中,当测试人员熟悉产品功能时,测试人员应该能够在与开发人员相同的迭代中工作。理想情况下,测试仅比开发时间短1或2天。
Stress Test Methodology
压力测试方法
1) Use VSTT WebTests to record key scenarios.
1)使用VSTT WebTests记录关键场景。
2) Create two databases. One contains normal volume of data, another contains huge data.
2)创建两个数据库。一个包含正常数据量,另一个包含大量数据。
3) Use VSTT LoadTests to configure web browser, User Count, network bandwidth, run time.
3)使用VSTT LoadTests配置Web浏览器,用户计数,网络带宽,运行时间。